Nothing in the GDPR requires a data protection officer because a company builds AI. The trigger is the processing pattern, and two of the three statutory limbs turn on words — “core activities”, “large scale” — that the Regulation does not define.
The three limbs of Article 37(1)
Article 37(1) of Regulation (EU) 2016/679 requires a controller or processor to designate a DPO where:
- (a) the processing is carried out by a public authority or body, except courts acting judicially;
- (b) the core activities of the controller or processor consist of processing operations which, by virtue of their nature, scope or purposes, require regular and systematic monitoring of data subjects on a large scale; or
- (c) the core activities consist of processing on a large scale of special categories of data under Article 9 or of criminal conviction and offence data under Article 10.
Every AI-company question lands on (b) or (c), and the operative guidance is the Article 29 Working Party’s Guidelines on Data Protection Officers (WP243 rev.01), endorsed by the EDPB. Note that the duty attaches to processors as well as controllers, so an AI vendor operating as its customers’ processor can be caught by its own processing patterns even though the purposes are somebody else’s.
Not legal advice. Several Member States impose additional DPO requirements and the analysis differs by establishment; this describes the Regulation’s own test only.
“Core activities” for an AI company
The WP243 guidance describes core activities as the key operations necessary to achieve the controller’s objectives — distinguished from support functions such as payroll or standard IT, which are ancillary even though they involve personal data. Its own example is instructive: a hospital’s core activity is healthcare, which cannot be provided without processing health data, so that processing is core rather than ancillary.
Applied to AI businesses, the answer separates cleanly along one line: is the processing of personal data inseparable from what you sell?
- Almost certainly core. A consumer assistant whose product is a conversation with users. A personalisation or recommendation company. A people-search, identity-verification or enrichment product. A tenant-, candidate- or credit-screening vendor.
- Usually not core. A developer-tools company whose models process code, where user personal data is limited to accounts and billing. A vertical AI product operating on machine telemetry or documents that happen to contain incidental personal data.
- Genuinely arguable. A B2B assistant embedded in a customer’s product, where you process end-user conversations at volume as a processor. The processing is central to the service you deliver, which points at core, even though the purposes are your customer’s.
What makes processing large scale
The Regulation does not define large scale. Recital 91 gives directional help — it speaks of processing a considerable amount of personal data at regional, national or supranational level which could affect a large number of data subjects — and expressly excludes processing by an individual professional such as a doctor or lawyer. The WP243 guidance sets out four factors: the number of data subjects, either as a specific figure or as a proportion of the relevant population; the volume and range of data items being processed; the duration or permanence of the processing; and its geographical extent.
Two things about AI products push on these factors in ways a conventional SaaS product does not. The range of data is unusually wide: a free-text prompt field collects whatever a user decides to put in it, so the categories of data a chat product processes are not bounded by its schema. And the duration is often permanent by default, because conversation logs are retained for quality and evaluation with no deletion path anyone specified. A product with modest user numbers can be processing a very wide range of data indefinitely, which is a stronger large-scale argument than the headcount suggests.
The same free-text point drives limb (c). A company that never deliberately collects health data will nonetheless receive it, at volume, the moment users type medical questions into a general assistant. Whether that constitutes processing special-category data on a large scale as a core activity is arguable — the guidance’s “core” filter is what stops the answer being automatic — but a company whose position is that it does not process Article 9 data because it did not ask for any is not describing its own system accurately.
Regular and systematic monitoring
WP243 reads “regular” as ongoing or occurring at particular intervals over a period, recurring at fixed times, or constantly taking place; and “systematic” as occurring according to a system, pre-arranged, organised or methodical, taking place as part of a general plan for data collection, or carried out as part of a strategy. The guidance is explicit that this is not limited to the online environment, and its examples include behavioural advertising, profiling and scoring for risk assessment, location tracking, loyalty programmes and connected devices.
Any continuously running inference over user behaviour meets both words without difficulty: a recommendation model scoring every session, a fraud model scoring every transaction, an engagement model updating a profile on every event. What does not meet them is a batch analysis run occasionally, or a generative feature that transforms a document the user supplies and retains nothing about the person.
National rules that lower the threshold
Article 37(4) permits Union or Member State law to require a DPO in further cases, and at least one Member State has done so in a way that catches small companies. Germany’s Federal Data Protection Act requires a DPO where a controller or processor constantly employs at least twenty persons in the automated processing of personal data — a headcount test with no core-activity or large-scale filter, which many AI startups with a German establishment meet long before they would meet Article 37(1). Check the national law of every establishment rather than the Regulation alone; the answer is not uniform across the EEA.
Separately, and independently of the GDPR, the AI Act imposes its own organisational duties that often land on the same person — the AI literacy obligation and the deployer duties in Article 26 among them. Neither creates a DPO requirement, and neither is discharged by having one.
If you do appoint one
The position is regulated, not just the appointment. Article 37(5) requires designation on the basis of professional qualities and expert knowledge of data protection law and practice. Article 37(6) allows the DPO to be a staff member or to fulfil the tasks under a service contract. Article 37(7) requires you to publish the contact details and communicate them to the supervisory authority — a step frequently missed, and trivially checkable by that authority.
Article 38 then protects the role: the DPO must be involved properly and in a timely manner in all issues relating to personal data protection, must not receive instructions regarding the exercise of their tasks, must not be dismissed or penalised for performing them, must report to the highest management level, and may fulfil other duties only where those do not result in a conflict of interests. That last point rules out the appointments companies most like to make: the head of engineering, the CTO, or anyone who determines the purposes and means of the processing they would be supervising. Article 39 lists the tasks, which include advising on and monitoring DPIAs — connecting directly to the Article 35 screening question and to maintaining the records described on the record of processing activities for an AI system.
Where you conclude no DPO is required, write down why. The analysis is the evidence, and Article 5(2) puts the burden of demonstrating compliance on you rather than on the authority that asks.
Top comments (0)