AI governance through the privacy function: from intake to DPO oversight

A public implementing agency, fourth quarter. Customer contact is testing an AI assistant that summarises emails. HR has bought a recruitment system with a matching feature that is switched on by default. The data team is building a model that flags applications with a higher likelihood of errors. Communications wants a chatbot on the website that answers questions from citizens. Four initiatives, four owners, and nobody with the overview. The board asks who is going to "do the AI Act". The reflex: a new programme, with an AI board, an AI officer, a separate register and a separate assessment form. (The example is fictional, but recognisable.)

In my analysis, that reflex is usually wrong. An organisation that takes the GDPR seriously already has most of the machine in place: a register, a risk assessment, a moment before procurement, often an independent supervisor in house, agreements with vendors and a process for reporting incidents. AI governance works best when you extend that machine into a target operating model (TOM) for AI, instead of building a second machine next to it. This article shows how, and also where that machine falls short.

Why the privacy officer is the logical home for AI governance

The AI Act and the GDPR overlap in two ways. They often concern the same object: almost every AI application in an organisation processes personal data, from prompts containing names to models that assess applicants. And they use the same method: risk-based, assess in advance, document, demonstrate. The legislator drew that connection itself. Article 26(9) of the AI Act provides that a deployer uses the information from the provider to carry out its DPIA under Article 35 GDPR. Article 27(4) provides that the fundamental rights impact assessment (FRIA) complements the DPIA where some of the obligations have already been met through the DPIA. That is an invitation to build on the existing privacy machine.

How that works out per instrument:

There is also a practical reason. The privacy function already has what a new AI programme first has to build: a mandate, a line to procurement and information security, an annual cycle with reporting to the board, and people who are used to asking a project lead awkward questions in good time. Organisations that want to set up AI governance ask, in practice, for the same four things again and again: roles and ownership, risk classification, an AI register and controls. In privacy roles, knowledge of the AI Act is increasingly listed as an advantage. That hybrid role, a privacy officer who knows the AI Act, is exactly what this operating model requires.

Where the privacy function is not enough

The chassis is not the whole car. If you put AI governance entirely in the privacy corner, you miss four things.

AI without personal data. A maintenance predictor for pumps is usually not high risk, but an AI component that acts as a safety component in managing a drinking water or energy network can be (Annex III, point 2). Neither processes personal data. An intake that starts with "does it process personal data?" lets such applications through. The first question must therefore be: is it AI?

Product safety and provider obligations. If you develop an AI system yourself and put it into service under your own name, you are a provider (Article 3(3)). That also applies to your own chatbot or assistant built on a vendor's language model, with the transparency obligations of Article 50(1) and (2) that already apply. In addition, a deployer becomes the provider of a high-risk system if it puts its name on it, substantially modifies it, or changes its intended purpose in such a way that it becomes high risk (Article 25(1)(a), (b) and (c); see the three routes to becoming a provider). For high-risk systems, obligations with a product safety logic then apply: a quality management system (Article 17), technical documentation (Article 11), a conformity assessment (Article 43) and post-market monitoring (Article 72). That is work for development and quality assurance. The privacy function flags it, but does not carry it out.

AI literacy across the whole organisation. Article 4 requires the organisation to take measures for everyone who operates or uses AI systems on its behalf, whether or not personal data are involved. Since the Digital Omnibus (Regulation (EU) 2026/1744, in force since 27 July 2026), it is a duty to take measures that support the development of AI literacy, without the organisation having to guarantee a specific level for each individual. The line organisation carries out those measures, the AI lead is accountable and HR or learning and development organises them; the privacy officer does not own them. The privacy officer can, however, bundle the evidence (see the scorecard for Article 4 evidence).

Fundamental rights beyond privacy. A FRIA also covers equal treatment, access to services and the effects on vulnerable groups. A privacy officer can organise that assessment, but needs domain knowledge from the process for it, and sometimes the people it is about.

So the boundary is this: the privacy function runs the process (intake, register, assessment, monitoring cycle) and safeguards coherence. The substance of obligations that are not about data protection lies with the system owner, development, information security or HR. Put that distinction on paper, otherwise the privacy officer silently becomes responsible for everything labelled "AI".

The AI governance operating model: from AI intake to AI register

The operating model below is my recommended set-up, not a form prescribed by law. The AI Act does not prescribe a register, an intake form or an AI officer; these do make the obligations demonstrable.

The triage worked out: four fictional requests

The four requests from the opening, run through the triage. The example is fictional and the outcomes are my own analysis; in a real case, the class depends on the intended purpose and the actual use.

Three details in the triage make the difference. First, the prohibited practices: Article 5 has applied since 2 February 2025, and the new prohibitions on AI for child sexual abuse material and non-consensual intimate imagery apply from 2 December 2026. Second, the exception in Article 6(3): a system in an Annex III area is not high risk if it does not pose a significant risk and only performs one of four tasks: a narrow procedural task, improving the result of a previously completed human activity, detecting decision-making patterns or deviations from them without replacing the human assessment, or a preparatory task. An Annex III system that performs profiling of natural persons always remains high risk (Article 6(3), last subparagraph). The provider documents that assessment and also registers a system it considers exempt in the EU database (Article 6(4) with Article 49(2)); as a deployer, you request the assessment and check the registration. Third, the role: Article 50(1) and (2) rest on the provider, paragraphs 3 and 4 on the deployer.

When the FRIA joins in, and what applies to systems already running

The FRIA is added when three things coincide. The system is high risk under Annex III, except point 2 (critical infrastructure). You are a body governed by public law, a private entity providing public services, or a deployer for creditworthiness or life and health insurance (Annex III, point 5(b) and (c)). And the date of application has been reached: 2 December 2027. After the assessment, you notify the market surveillance authority of the results using the AI Office template (Article 27(3)), and you update the FRIA when circumstances change (Article 27(2)). Make it one document, with the DPIA as its basis (see DPIA and FRIA compared and the FRIA template).

For a system that was already placed on the market or put into service before 2 December 2027, the high-risk obligations, including the FRIA, only apply on a significant change in its design. If the system is intended to be used by public authorities, it must comply by 2 August 2030 at the latest (Article 111(2)). Article 4 and Article 50 already apply to those systems now.

Controls and the link to information security

A CISO or auditor does not want to read an operating model, but to test controls. The six building blocks translate into six controls that fit into the existing risk and control cycle of ISO 27001 or, for Dutch government bodies, the BIO2 (the Baseline Information Security for Government). ISO/IEC 42001 is a useful framework for an AI management system, but not an obligation under the AI Act.

The AI register next to the record of processing activities: the fields

This is the minimum set I recommend. Most fields already exist in a good record of processing activities; the AI fields are added next to them.

Roles and ownership: the RACI for AI governance

AI governance rarely fails on knowledge and often on ownership. The RACI below is a starting point, drawn up by me for a mid-sized organisation; adapt it to your own structure. R is responsible, A accountable, C consulted, I informed. Owner stands for the process or product owner, PO for the privacy officer, IM for the information manager, and AI lead for the AI lead, CDO or whoever coordinates the AI process.

Three choices in this table are deliberate. The process owner is accountable for the DPIA and the deployment, not the privacy officer; under the GDPR the obligation rests on the organisation as controller, and internally it belongs with whoever runs the process. The board decides on deployment, at least for high risk; for light applications you can delegate that. And the DPO is nowhere the owner of a decision. Two rows need explanation. The board's A for monitoring of compliance means that the board is accountable for compliance itself, not that it steers how the DPO monitors: the DPO does not receive instructions. And next to the AI lead, the DPO reports along its own line directly to the highest management level (Article 38(3) GDPR). HR is not in the table, but organises the AI literacy measures that the line organisation carries out.

In practice I see most friction on one row: who signs the DPIA. The process owner sees the DPIA as something belonging to the privacy officer, the privacy officer sees themselves as the writer of someone else's risk assessment. Agree in advance that the privacy officer drafts the DPIA and the owner accepts and signs off the residual risk. An editable version is in the RACI matrix AI governance, and a broader set-up in the AI governance framework.

What the DPO does on AI: advise and monitor, not decide

The DPO is the linchpin of this set-up, precisely because the DPO is not an owner. A DPO is mandatory for public authorities and for organisations whose core activities consist of large-scale monitoring or large-scale processing of special categories or criminal offence data (Article 37 GDPR). If you have no DPO, place the reviewing role with an independent function, such as compliance or internal audit, or with an external DPO; a privacy officer is not automatically a DPO. If you appoint a DPO voluntarily, the same regime of Articles 38 and 39 applies.

The tasks are set out in Article 39 GDPR: to inform and advise, to monitor compliance, to provide advice where requested on the DPIA and monitor its performance, to cooperate with the supervisory authority and to act as its contact point. That DPIA question is not optional: the organisation must seek the advice of the DPO (Article 35(2)). In performing the tasks, the DPO has due regard to the risk associated with processing operations (Article 39(2)): a good reason to give AI applications priority in the monitoring plan. The position is set out in Article 38: the DPO does not receive instructions on the exercise of those tasks, is not dismissed or penalised for performing them and reports directly to the highest management level (paragraph 3). A DPO may have other tasks, but the organisation ensures that they do not result in a conflict of interests (paragraph 6). Whether that is the case is assessed case by case, as the Court of Justice confirmed in X-FAB (C-453/21, 9 February 2023).

The guidelines of the European supervisory authorities on the DPO (WP243, endorsed by the EDPB) make that concrete: a DPO cannot hold a position in which they determine the purposes and means of processing. For AI, in my analysis, that means:

• The DPO does not decide whether an AI application goes into use, and does not own the AI programme.
• The DPO does not write the DPIA; the organisation carries it out, the DPO advises and monitors its performance.
• The DPO may maintain the register under the responsibility of the organisation (WP243 does not rule this out), as long as the substantive choices lie with the owners.
• A combined role as DPO and "AI supervisor" can work, provided that AI role is also advisory and reviewing. A DPO who is also the AI lead and decides on deployment reviews their own work.

In its questions and answers on AI literacy, the European Commission was asked exactly whether an AI officer is needed as under the GDPR, and whether a DPO and an AI officer can be the same person. Its answer: Article 4 does not require any specific governance structure, so no AI officer and no AI board. Nor does the AI Act require an AI officer anywhere else (own analysis). The choice to give the DPO a reviewing AI role therefore lies with the organisation. In its principles for positioning the DPO (2021), the Dutch DPA stressed that the organisation must involve the DPO early, agree with the DPO what happens with the DPO's advice and safeguard the DPO's independent position. With AI that matters even more, because the pressure to start quickly is high. So involve the DPO in the triage, not only at the signature. If you have no DPO or an overloaded one, the role can also be filled as an external DPO with AI oversight.

The Dutch public sector as an example: algorithm register, IAMA and a coordinating supervisor

For Dutch municipalities and public implementing agencies, an extra layer sits on top, and it fits the same machine well. Other member states have their own equivalents; the Dutch case shows how one internal register can feed several publications.

The algorithm register. Registration in the algorithm register of the Dutch government is not a legal duty for any public body; the register itself states that submitting entries is not yet mandatory. It is, however, policy: the Algoritmekader (the Algorithm Framework of the Dutch Ministry of the Interior, BZK) asks public bodies to publish impactful algorithms and high-risk AI, and the Autoriteit Persoonsgegevens (AP, the Dutch Data Protection Authority) argues for a statutory registration duty. It is also the standard by which citizens, councils and the supervisor measure you. Keep it internally in your own register and publish from there. Do not confuse it with registration in the EU database, which is mandatory: a public authority that uses a high-risk system from Annex III must register itself, the system and its use there from 2 December 2027 (Article 49(3) and Article 26(8); for systems already running: Article 111(2)), except for critical infrastructure. One internal register therefore feeds two publications. See registering AI systems and the overview of what Dutch public bodies already register.

IAMA and the Algoritmekader. The IAMA (Impact Assessment Mensenrechten en Algoritmes, the Dutch human rights and algorithms impact assessment) was renewed in February 2026: shorter, with a separate explanatory document, and aligned with Article 27, with the questions that relate directly to the AI Act clearly marked. Use the IAMA as the method for the FRIA where Article 27 applies, but check for each part whether all elements of Article 27(1) are covered; use it voluntarily for other impactful algorithms. The Algoritmekader bundles requirements and measures per phase of the life cycle and is a useful checklist next to your own operating model. More in the FRIA for municipalities.

The Dutch DPA as coordinating algorithm supervisor. The AP has been the coordinating supervisor for algorithms since January 2023 and publishes a work agenda for that supervision. The formal designation of the Dutch supervisors under the AI Act runs through the Uitvoeringswet AI-verordening (the Dutch AI Act Implementation Act), which is still a bill. Until it is adopted, no Dutch supervisor can impose an AI Act fine, but the AP can already act under the GDPR where personal data are at stake; see who enforces what in the Netherlands. For the privacy function that makes the conversation simpler: the GDPR supervisor is also the party coordinating algorithm supervision. Which documents you must then be able to put on the table is covered in the article on a regulator's document request.

Copilot as the first test. The AP's advice on Microsoft 365 Copilot at the municipality of Haarlemmermeer shows why the chassis approach holds. The first block of measures is not about AI at all, but about the basics: an up-to-date record of processing activities, labelling documents, access rights and the cloud environment. The second block concerns purpose limitation, accuracy, automated decision-making and information to citizens. That is privacy work. The third block concerns Copilot itself, with the firm condition that Microsoft is sufficiently transparent about service data and retention periods; you do not solve that internally, but through procurement and contract (building block 5). Whoever has their privacy machine in order has therefore already done much of the groundwork. The details are in the Copilot DPIA after the Dutch DPA's advice and the Copilot DPIA pack; for human intervention in decisions about citizens, see meaningful human oversight in practice and human oversight in the public sector.

A 90-day starting plan

Three months is enough to get the operating model running, not to have everything finished. This is the order I recommend. In practice, the first quarter mostly gets stuck on the inventory: departments report what they bought themselves, but not what a vendor switched on in existing software. So start with the licence and vendor lists, not with the survey.

Days 1 to 30: agree and make visible. Have the board record on one page that AI governance runs through the privacy function, who the AI lead is and which boundary applies for what is not about privacy. Adopt the RACI. Make a first inventory: the licence lists, the list of vendors with AI features in existing software and a short survey of departments. Put the request form live and add the AI fields to the register.

Days 31 to 60: assess what is already running. Triage the inventory and select the three to five applications with the highest risk. Carry out the AI addendum to the DPIA on those, or update the existing DPIA, and send out the vendor questions. Adopt the AI use policy. Check the transparency obligations that already apply: a chatbot that talks to citizens or customers (the disclosure duty of Article 50(1) rests on the provider; check that your vendor has built it in, or whether you are the provider yourself), and, as a deployer, deepfakes and AI-generated text you publish to inform the public (paragraph 4; see Article 50 applies now). Record the AI literacy measures per role (Article 4 evidence dossier).

Days 61 to 90: close the cycle. Add AI incidents to the reporting process and test it with one exercise case. Deliver the first quarterly report to the board: number of requests, risk distribution, open measures, decisions. Have the DPO carry out a first monitoring round on the AI process and report on it. For every application that comes out of the triage as high risk, make a plan towards 2 December 2027: the deployer's file (high-risk AI file template) and the FRIA where it applies. A system that is already running falls under Article 111(2); for every planned model or design change, assess whether it is a significant change, and for systems intended for public authorities, keep 2 August 2030 as the final date.

If you want this starting plan not just to read but to run, you can hire me as an AI and privacy lawyer to set it up together with your privacy officer.

Seven mistakes that undermine the operating model

1. A second register next to the record of processing activities. Two registers drift apart within a year, and then neither is right.
2. Letting the intake depend on personal data. Then you miss exactly the AI without personal data that can be high risk, and the AI literacy that applies to every system.
3. Making the DPO the owner of AI decisions. That creates a conflict of interests (Article 38(6) GDPR), undermines the DPO's independent position (Article 38(3)) and takes responsibility away from the owner.
4. Skipping built-in AI features. An update that switches on an AI assistant in your case management system or office software is a new application, even without a tender.
5. The FRIA everywhere or nowhere. Article 27 does not apply to every deployer of a high-risk system, not to critical infrastructure and only from 2 December 2027 (for systems already running: Article 111(2)); but whoever is in scope and waits will soon have a file without a foundation.
6. Keeping pilots outside governance. The Copilot advice concerned a pilot with 15 to 20 employees, and the AP rejected the idea that such a pilot does not amount to a new processing operation: "ook een pilot aan de AVG moet voldoen" ("a pilot must also comply with the GDPR", our translation). A pilot is also the cheapest moment for the intake.
7. Ticking off Article 4 with one course. The duty requires measures that fit role, knowledge and context. Record what you do per group, not just who has watched a video.

Having AI governance set up by an AI and privacy lawyer

This operating model is deliberately built on what a privacy function can already do. The difficult steps are in the transitions: the triage between the GDPR and the AI Act, the line between advice and decision, and the first assessments of what is already running. That is where I help organisations. If you want someone who knows both laws to set this up together with your privacy officer and DPO, you can hire me as an AI and privacy lawyer, on an interim basis or per project. If you have no DPO or an overloaded one, it can also be done as an external DPO with AI oversight. And if you want an independent opinion on a DPIA, FRIA or classification, with my name on it, see the signed assessment.