Skip to content

Privacy by Design Applied to an AI Feature (Article 25)

10 min read · updated August 11, 2026

Article 25 is usually paraphrased as “think about privacy early”, which is advice rather than an obligation. The provision is more specific than that: it requires measures designed to implement the data protection principles in an effective manner, taken at the time the means of processing are determined, and it separately requires that the defaults process only what is necessary. For an AI feature, both halves have concrete answers.

What Article 25 actually requires

Article 25(1) obliges the controller, taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms, to implement appropriate technical and organisational measures — such as pseudonymisation — which are designed to implement data-protection principles such as data minimisation in an effective manner and to integrate the necessary safeguards into the processing. It says this must be done both at the time of the determination of the means for processing and at the time of the processing itself. The text is at EUR-Lex, Regulation (EU) 2016/679.

Article 25(2) is a separate obligation and the more demanding of the two. The controller must implement measures ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed — and it states that the obligation applies to the amount of data collected, the extent of their processing, the period of their storage and their accessibility. It closes with a specific requirement: such measures shall ensure that by default personal data are not made accessible without the individual’s intervention to an indefinite number of natural persons.

This is a description of a statutory obligation, not legal advice. “Appropriate” and “necessary” are judgements about your specific processing and your specific risks; take advice on your own facts, particularly where the feature processes special category data or serves minors.

The EDPB’s Guidelines 4/2019 on Article 25, adopted in final form in October 2020 and available from the EDPB’s document register, add the criterion that does most of the work in assessment: effectiveness. A measure counts only if it actually achieves the protective outcome for the specific processing, which means a control that exists but is off, or that is documented but unenforced, is not a measure at all. Breaches of Article 25 sit in the lower fine tier under Article 83(4)(a).

The timing rule is the hard part

“At the time of the determination of the means for processing” is the clause that makes Article 25 different from every other obligation in the Regulation, because it attaches to a moment that has already passed by the time most compliance work starts. Once the feature ships, the means have been determined. Retrofitting a retention limit is a good idea and it does not undo the fact that the obligation applied at design time.

In practice this makes Article 25 a design-review obligation with a paper trail, and the paper trail is usually the DPIA under Article 35 — which for a generative feature is very often mandatory anyway. The sequence that satisfies both is: identify the processing before building it, run the assessment, record the design decisions and the alternatives rejected, then build. The order is the compliance artefact; a DPIA written after launch documents a decision rather than informing one. For the assessment itself see the structure of a DPIA for generative AI.

There is a real limit worth stating plainly. Article 25 binds the controller. A company buying a model API cannot redesign the provider’s system, and the state-of-the-art and cost-of- implementation qualifiers exist partly to acknowledge that. What it can determine is everything on its own side of the API — what is sent, what is stored, for how long, who can see it, and which vendor terms it accepts. Vendor selection is itself a design decision under Article 25, and choosing a provider whose defaults cannot be configured is a choice the controller made.

Article 25(2): the four dimensions of default

The provision names four dimensions and it is worth taking each against a generative feature, because they fail in different ways.

  • Amount of data collected. A free-text prompt box collects whatever the user types. The default-minimising design is to shape the input — structured fields where the task allows them, explicit guidance about what not to include, and server-side removal of identifiers that the task does not need before the call goes out.
  • Extent of processing. Serving the answer is one extent. Storing the conversation, indexing it, sampling it into an evaluation set and using it to improve a model are four more, and each is an extension that has to be justified on its own rather than carried by the first.
  • Period of storage. The default should be the shortest window that makes the feature work, with longer windows attached to named purposes. “Indefinitely, until the user deletes it” is not a default that satisfies Article 25(2), even though it is what most chat products ship.
  • Accessibility. The explicit prohibition on making data accessible without the individual’s intervention to an indefinite number of natural persons is the one AI products break most visibly. A share link that generates a public URL is exactly the mechanism the sentence is about, and a share feature whose output is crawlable converts a private conversation into an indefinite audience without further intervention by the user.

The design choices, concretely

The following are the decisions where an AI feature either satisfies Article 25 or does not. None of them is expensive; most are a default value.

  • Training use is opt-in, not opt-out. This is the clearest reading of Article 25(2): if training on a user’s content is not necessary to deliver the feature the user asked for, then by default it should not happen. An opt-out design processes unnecessary data by default and relies on the user to stop it, which is the shape the provision was written against.
  • A finite default retention window on conversation history, set in the product rather than in a policy, with the longer window available to users who want it.
  • Prompt bodies excluded from application logs and traces by default, with sampling behind an explicit switch. Log capture is the single most common route by which prompt content reaches systems and audiences nobody assessed.
  • Zero or minimal retention selected at the vendor where the vendor offers it, and recorded contractually so that it is not a settings page an administrator can change — see DPA clauses specific to AI sub-processing.
  • Personal data kept out of the system prompt. System prompts are frequently logged, cached, versioned in source control and shared for debugging. Anything in them inherits all of those exposures.
  • Retrieval scoped by tenant and by user at the index layer, not by instructions in the prompt. A model told not to reveal something is not an access control, and treating it as one is a design defect that produces the fact pattern in breach notification when an AI system leaks personal data.
  • Sharing defaults to private and non-indexable, with any public option requiring a distinct, informed action.
  • Deletion that propagates. If a user deletes a conversation, the embedding derived from it and the evaluation sample taken from it should go too — which is a schema decision made early or an impossible migration made late.

Showing you did it

Article 5(2) accountability means the obligation is to be able to demonstrate compliance, not merely to comply. For Article 25 the demonstrable artefacts are unglamorous and specific: a design record naming the alternatives considered and why the chosen defaults are the minimising ones; the DPIA where one was required; the configuration values themselves, which should be readable from the system rather than asserted; and the contractual terms that fix the vendor-side defaults.

Article 25(3) allows an approved certification mechanism to be used as an element in demonstrating compliance, which in practice means little today because few such mechanisms have been approved. Do not treat a SOC 2 report or an ISO certificate as evidence of Article 25 compliance: they are evidence about a control environment, and Article 25 is about decisions taken for a specific processing operation. The two overlap much less than a procurement questionnaire suggests. The retention side of the same question, for training corpora specifically, is in retention limits for training data, and the minimisation principle it implements is worked through in data minimisation in AI training.