Data Protection Officer for AI, in depth: when a DPO is mandatory, independence and conflicts, an AI intake gate with DPIA screening, and the AI Act interplay

When the GDPR requires a DPO

Article 37(1) requires controllers and processors to designate a DPO in three cases: the processing is carried out by a public authority or body (courts acting judicially excepted); the core activities consist of processing operations that require regular and systematic monitoring of data subjects on a large scale; or the core activities consist of large-scale processing of special categories of data (Article 9) or criminal convictions data (Article 10). Member state law can add more cases; Germany, for example, has its own thresholds.

AI products hit the second and third tests more often than teams expect. Behavioural personalisation, fraud scoring, productivity analytics and location-based recommendations are systematic monitoring; a health chatbot or a model trained on medical records processes special category data. 'Core activities' means the processing is inseparable from the business, not an ancillary function like payroll. A group can appoint one DPO if they are easily accessible from each establishment (Article 37(2)), the DPO can be an employee or a contractor (37(6)), and their contact details must be published and communicated to the supervisory authority (37(7)). Even where a DPO is optional, appointing one voluntarily brings the same Article 38 and 39 rules with it, so decide deliberately.

What the role is, and what it is not

Article 39 lists the minimum tasks: inform and advise the organisation and its staff; monitor compliance, including assignment of responsibilities, awareness raising, training and audits; advise on data protection impact assessments and monitor their performance; cooperate with the supervisory authority and act as its contact point. Article 35(2) requires the controller to seek the DPO's advice when carrying out a DPIA.

Article 38 protects the role. The DPO must be involved properly and in a timely manner; must receive the resources needed; must not receive instructions on how to perform those tasks; must not be dismissed or penalised for performing them; and reports directly to the highest level of management. What the DPO is not: the person accountable for compliance. Article 24 puts that on the controller, and the Article 29 Working Party's DPO guidelines (WP243, endorsed by the EDPB) say expressly that DPOs are not personally responsible for non-compliance.

Independence and conflicts in AI organisations

Article 38(6) allows other duties only if they do not create a conflict of interest. In X-FAB (C-453/21, 9 February 2023) the Court of Justice held that a conflict may arise where the DPO is given tasks that lead them to determine the purposes and means of processing, because they would then be monitoring their own decisions; whether one exists is assessed case by case. In Leistritz (C-534/20, 2022) it held that member states may give DPOs stronger protection against dismissal than the GDPR itself, provided it does not undermine the regulation's objectives.

In an AI organisation the people who determine purposes and means are easy to name, and that makes the conflict test concrete:

Architecture: the AI intake gate

The practical fix for late involvement is an AI intake record that every new model, feature, vendor or material change must file before design is frozen, with a screening step that decides whether a DPIA is needed and routes the case to the DPO. The Article 29 Working Party guidelines on DPIAs (WP248) list nine criteria indicating likely high risk; meeting two or more usually means a DPIA is required, and each supervisory authority also publishes an Article 35(4) list of operations that always need one.

WP248 = {
    "evaluation_or_scoring", "automated_decision_legal_effect", "systematic_monitoring",
    "sensitive_or_highly_personal", "large_scale", "matching_or_combining_datasets",
    "vulnerable_subjects", "innovative_technology", "prevents_exercising_rights",
}

def screen(intake: dict, national_list: set[str]) -> dict:
    hits = sorted(c for c in WP248 if intake["criteria"].get(c))
    on_list = sorted(set(intake["operation_tags"]) & national_list)
    dpia = len(hits) >= 2 or bool(on_list)
    return {
        "intake_id": intake["id"],
        "criteria_met": hits,
        "national_list_matches": on_list,
        "dpia_required": dpia,
        # A documented "no DPIA" is still a decision the DPO should see.
        "route_to_dpo": True,
        "reason": "two or more WP248 criteria" if len(hits) >= 2 else
                  "national Article 35(4) list" if on_list else "screened out; record kept",
    }

Note that route_to_dpo is always true: the DPO should see screened-out cases too, because monitoring compliance includes checking that screening is honest. Generative AI used with personal data almost always ticks 'innovative technology', so one more criterion pushes it into a DPIA. The DPIA mechanics themselves are covered in GDPR for LLM applications.

Questions specific to models

Generic privacy reviews miss model-specific risks. A DPO advising on AI should ask, and expect written answers to, at least these:

• Lawful basis per purpose: is training on user data based on consent, contract or legitimate interest, and if the last, where is the balancing test?
• Training data provenance: which sources, scraped or licensed, and was special category data filtered or deliberately included?
• Memorisation and extraction: can the model reproduce personal data, and was that tested? See membership inference for the attacks.
• Rights across every store: can access, rectification and erasure reach prompts, logs, vector indexes, evaluation sets and fine-tuning data? Erasure for LLMs shows how.
• Article 22: does any output produce a legal or similarly significant effect without meaningful human review?
• Vendors and transfers: is the model provider a processor, what does it retain, and where?
• Retention: how long are prompts and outputs kept, and why that long?

Where the EU AI Act touches the role

The EU AI Act does not create a DPO requirement or an 'AI officer' role that replaces the DPO. It does create work the DPO should advise on. Article 26(9) tells deployers of high-risk systems to use the information the provider supplies under Article 13 when carrying out their DPIA. Article 27 requires certain deployers, including public bodies and private entities providing public services, plus deployers of credit scoring and life and health insurance pricing systems, to carry out a fundamental rights impact assessment, which can complement an existing DPIA. Article 10(5) permits exceptional processing of special category data to detect and correct bias in high-risk systems, subject to strict safeguards, which is precisely the kind of processing a DPO must scrutinise.

After the 2026 Omnibus amendment, high-risk duties apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I products; see EU AI Act in depth. Many organisations give the DPO a seat on the AI governance board for this reason, while keeping ownership of AI Act compliance with the product or risk function to avoid the conflict above.

Worked example: a support assistant with sentiment scoring

A European online retailer proposes an LLM customer support assistant. Transcripts would be embedded into a vector store for retrieval, and a sentiment model would score each conversation; customers repeatedly scored 'abusive' would be restricted to email support.

The intake record screens four WP248 criteria: evaluation or scoring (sentiment profiling), large scale (millions of customers), innovative technology (generative AI) and arguably systematic monitoring. A DPIA is required. The DPO's written advice makes four points. First, restricting support channels based on an automated score may be a similarly significant effect; put a human review step before any restriction and tell customers how to contest it. Second, set transcript retention at a stated period, with the vector store deleted on the same schedule and covered by the erasure workflow. Third, confirm the LLM vendor acts as a processor with no training on customer data and record the transfer mechanism. Fourth, update the privacy notice before launch.

Product accepts the first three and defers the notice update by a sprint; the DPO records that launch should wait for it and reports the disagreement to the board under Article 38(3). The controller decides; the DPO's job was to make sure it decided knowingly, with a record.

Running the role: evidence and reporting

A DPO who only reacts to requests cannot monitor an AI estate that changes weekly. The role scales when it runs on the same evidence the engineering teams already produce. Three data sources do most of the work: the AI intake records and their screening results, the model and vendor registry, and the ticket history for data subject requests and incidents. From them the DPO's office can compute a small set of indicators that show whether compliance is real rather than asserted.

Report these to top management each quarter alongside any open disagreements, as Article 38(3) intends. Keep the DPO's access read-only: they need to see registries and logs, not to change them, which also keeps the monitoring function clear of the decisions it monitors. Where the volume justifies it, a small team of privacy engineers reporting to the DPO can run screening, chase actions and test erasure paths, leaving the DPO to advise on the hard cases.

Failure modes

• DPO as approver: sign-off language makes the DPO look accountable and invites the conflict X-FAB describes. Record advice, and record the controller's decision separately.
• Late involvement: the first time the DPO sees a model is a launch review. Make intake a gate in the delivery pipeline, not a calendar invite.
• Under-resourcing: one part-time DPO for dozens of AI features fails Article 38(2). Fund privacy engineers who report to the DPO.
• Dual-hatted platform lead: the person deciding retention also monitors it.
• Stale screening: a model gains a new purpose and nobody re-files. Trigger re-screening on registry changes to purpose, data sources or vendors.

What to do next

1. Test your organisation against Article 37(1) and national law, and record why a DPO is or is not mandatory.
2. Check the DPO's other roles against the X-FAB test and fix any role that sets purposes or means.
3. Create an AI intake record and make filing it a precondition for model registration or vendor onboarding.
4. Encode WP248 screening plus your authority's Article 35(4) list, route every result to the DPO, and keep the output.
5. Give the DPO a standing AI question set and require written answers before DPIA sign-off.
6. Add a quarterly DPO report to top management covering AI DPIAs, rights requests across AI stores and open disagreements.