An employee opens their company’s internal assistant at 11.40 at night and types a question they would not ask a colleague. It concerns leave, and the fear that their manager will find out why they are asking. To put it well they have to give some detail: that for six months they have been sleeping four hours a night, that they have stopped finding a reason to get up, that they arrive later and later in the morning.
That assistant runs on an API contract with Zero Data Retention. Which means the conversation is not retained after processing, that nobody at the provider will be able to read it, that it will land in no training dataset. Half a second later nothing of the exchange exists. From a retention standpoint we are very close to the ideal: the data passed through and left no residue.
And yet, as it passed, the system concluded something about him.
I will not say what yet, because that is precisely the point. The question we have learned to ask in thirty years of data protection is: who can see this conversation? The answer here is nobody. It is an excellent answer, and it is insufficient.
On 19 August, yesterday, OpenAI announced something that makes that insufficiency concrete rather than philosophical.
What was announced yesterday
On 19 August OpenAI communicated two distinct things, and it helps to keep them apart, because the first is a commercial confirmation and the second is an architectural idea.
The first: Zero Data Retention will continue to be offered to eligible API customers on frontier models too. Under ZDR, in the company’s own definition, prompts and responses are not retained after the request is processed, customer content is not available to staff for review, and enterprise customer data is not used to train models absent explicit opt-in. It is a promise aimed at businesses, not consumer users, and the difference matters: anyone typing into a public chatbot is not buying this guarantee.
The second: a preview of Private Safety Processing. It comes from a problem that is real and that frontier companies did not invent for marketing. As models take on longer and more autonomous work, safety systems have to recognise risks that are invisible in a single request but visible in the shape of a sequence. An isolated question is almost always harmless. Thirty questions across two days, taken together, may not be. Except that to look at a sequence you have to retain it, and retaining it is precisely what ZDR promises not to do.
Private Safety Processing tries to separate the two. Under ZDR configurations the content stays on infrastructure the customer controls, or sits on OpenAI servers encrypted with keys the customer holds and the provider has no copy of. Pattern analysis happens in there. When something trips, what leaves the boundary is a narrow signal indicating the type and severity of the activity without exposing the underlying prompts and responses. The customer investigates the alert on their own systems, and may then decide to hand over material voluntarily, to challenge a decision or to help an abuse investigation.
Rollout is announced for September, along with a technical white paper. Until that document appears it would be wrong to draw strong conclusions: we do not know exactly where the classifier runs, what the granularity of the signal is, what happens to false positives. Anyone who assesses vendors has learned to tell an architecture from a press release, and for now this sits halfway between the two.
Even so, the interesting part is already legible. The provider can know: this sequence probably belongs to category X. Without knowing: here are the sentences the user wrote. The two kinds of knowledge are not the same, and it is the second that data protection law has learned to govern well.
It is worth noting that the industry is splitting on this point. Anthropic retains prompts and outputs from its Covered Models for thirty days, the category to which it applies its strictest policies, avowedly to support its safety work, and it does so on every platform where those models are offered. Two different answers to the same tension, and neither is obvious.
Grant the objection in full
Before arguing that something new is happening, one has to avoid a very common overreach: presenting as today’s discovery something the law has known for a long while.
Inference does not begin with language models. Behavioural advertising has been inferring interests for twenty years. Credit scoring infers economic reliability. Anti-fraud algorithms infer the probability of unlawful conduct. Profiling is by definition the production of personal characteristics from behaviour other than those characteristics.
The GDPR was written broadly enough to cover all of it. Article 4(4) defines profiling as any form of automated processing aimed at evaluating personal aspects, and European guidance has for years distinguished between data provided by the data subject, data observed, and data derived or inferred, that is, produced by the controller by analysing other data.
But the strongest defence of the law as it stands is not in the definitions. It is in three judgments of the Court of Justice, and they are more radical than the usual summaries suggest.
On 4 July 2023, in Meta v Bundeskartellamt, the Court held that the prohibition on sensitive data requires no explicit declaration. If an operator collects a user’s visits to sites and apps linked to special categories of data and ties them to their account, it is processing sensitive data, regardless of whether that information was ever declared. Revealing, for the Court, includes inferring. It is exactly the principle the world of inference needs, and it was written three years ago.
On 7 December 2023, in SCHUFA, the Court went deeper still. The automated calculation of a probability rate concerning a person’s ability to meet future payment commitments itself constitutes automated decision-making under Article 22, where the conclusion, performance or termination of a contractual relationship by the third party to whom it is communicated depends decisively on that rate. Not the bank’s resolution: the score. European law has already recognised that the inference can be the real decisive act, and that whoever produces it cannot hide behind whoever uses it.
On 4 October 2024, in Schrems v Meta, the Court held that the minimisation principle prevents aggregating, analysing and processing for advertising purposes the data collected on and off the platform without time limit and without distinction of type. And it added that having publicly disclosed one’s sexual orientation on one occasion does not authorise processing other data relating to that orientation.
Finally there is EDPB Opinion 28/2024, adopted on 17 December 2024, which carries a similar intuition applied to models. For a model trained on personal data to count as anonymous, the Board says, both the likelihood of directly extracting personal data from it, taking account of attacks such as membership inference and model inversion, and the likelihood that queries return identifiable personal data, even unintentionally, must be insignificant.
It would therefore be wrong to write that we have suddenly discovered a category unknown to law. European law has the conceptual tools and has already used them. Those who claim otherwise have usually not read the judgments.
The change is something else, and it is more uncomfortable because legislating does not fix it.
What actually changes
Three things change together: scale, cost and temporality.
Scale. A credit scoring system infers one thing. An advertising system infers a few dozen attributes from a catalogue defined in advance. A foundation model has no catalogue. A single conversation can simultaneously suggest education level, emotional state, occupation, financial capacity, probable geography, political leaning, medical condition, family situation and future intentions, and not because anyone built nine classifiers. The capacity to produce those categories exists in the same model that is answering a question about holiday entitlement. It does not need switching on: it needs, if anything, preventing.
Cost. For years data protection could rely on an implicit and reasonable assumption: knowing costs. You had to accumulate observations, build a profile, keep it current, and every step left traces that could be regulated. With highly capable models that relationship weakens. Ten weak signals can produce a strong inference. A photograph reveals more than it shows. A temporal pattern reveals a routine. A sentence allows far more to be estimated than its explicit semantic content.
Temporality, which is the genuinely new piece. Classical profiling produced a profile, that is, a state: a record somewhere saying this person belongs to segment 47. That state could be inspected, challenged, deleted. A general-purpose model may never store the proposition this person belongs to category X. It can rebuild it, identical, every time it is asked.
This formulation is worth keeping, because it is the centre of the whole argument: knowledge stops being a persistent state and becomes a persistent capacity to produce a state.
This is not a philosophical nicety. It has immediate practical consequences for erasure, rectification and retention.
The empty room paradox
Picture an ideal machine, built by someone in perfect good faith.
It receives a person’s private diary. It processes it. No human being can read it. It is never written to disk. It is not used to train anything. Immediately afterwards it is irreversibly deleted, and the deletion is verifiable.
Before deleting it, though, the machine produces one line: 92% probability that this person belongs to category A. And it keeps only that.
Have we protected the data? Technically yes, and not cosmetically: almost every risk metric we use today would come back clean. Have we protected the person? That depends entirely on what A is and on what happens next.
A system can minimise possession of data superbly and simultaneously maximise the knowledge it extracts from it. They are two different minimisations, and we have treated them as one because in the world of databases they almost always were.
Suppose an insurer never receives a medical record. It receives only a health score, computed locally on the person’s phone, with an architecture no cryptographer would fault. The insurer possesses no clinical data. It possesses the only information it actually wanted, in the most convenient possible form.
And this is where inference becomes, in some cases, more dangerous than the data. A purchase history needs interpreting, and interpretation costs something, can be wrong, can be argued with. The label «likely financial distress» is ready to be used by anyone, without expertise and without friction. A set of messages is ambiguous. A score for «propensity to leave the job» turns that ambiguity into a decision, and delivers it in a form the recipient has no incentive to question.
An inference, very often, is data already converted into operational power.
A wrong inference cannot be corrected
There is a second problem: inferences do not even have to be accurate to produce effects.
When a database holds a wrong address, the law has a simple and working answer: correct the address. The right to rectification presupposes a recorded fact, identifiable and replaceable.
When a system concludes, combining thousands of variables, that a person has a high probability of default, what gets rectified? Which field? Which weight? Which correlation? Which latent representation? There is no wrong box. There is a produced judgment, and a produced judgment does not have the grammatical structure of a factual error.
European law has noticed and is taking a different route, one that runs through contestability rather than correction. On 27 February 2025, in Dun & Bradstreet, the Court of Justice held that Article 15(1)(h) of the GDPR obliges the controller to explain, concisely, transparently and intelligibly, the procedure and principles actually applied to obtain a given result from that person’s personal data. Not the formula, not the source code: the procedure genuinely followed. And it added that trade secrecy is not an absolute objection, because that information exists to let the person obtain human intervention, express their point of view and contest the decision.
It is a serious answer, and it remains far harder to apply to a general-purpose model than to a scoring system. A scoring system has variables, weights and a threshold. You can explain, laboriously, what weighed. A model that produces a classification as a side effect of its linguistic understanding has no procedure in that sense, and the temptation to answer with a generic description of the architecture will be enormous.
Let me add something that complicates matters further. The right to erasure is built on the idea that there is something to erase. If the system never stored the proposition about me, but can reproduce it on demand, there is nothing to remove and nothing that remained. Deleting a state is possible. Deleting a capacity is not.
Apple had already moved the boundary
Anyone who looked at Private Cloud Compute when it was presented saw the same frontier arriving from another direction.
Apple set five requirements for PCC, and they are worth reading as a document of political engineering rather than of security. Personal data must be used exclusively to fulfil the request and must not be available to anyone other than the user, not even Apple staff, nor retained, including through logging or debugging. The guarantees must be enforceable technically, meaning every component must be constrainable and analysable. There must be no privileged interfaces allowing operational staff to bypass the guarantees. An attacker must not be able to target a specific person without attempting to compromise the entire system. And security researchers must be able to verify that the guarantees match the public promises.
The most eloquent technical consequence is the one usually mentioned in passing: PCC nodes include no remote shells and no interactive debugging mechanisms, and the system does not even contain a general-purpose logging mechanism. Only predefined, structured and audited logs and metrics can leave the node.
Pause on that sentence, because it contains the whole novelty. Apple did not promise not to look. It removed the instruments with which one normally looks, and made the set of things that can leave the node a closed list, decided in advance and verifiable.
The trust boundary has moved. Before, I had to trust the system administrator who promised not to read. Now I trust an architecture that establishes which computations are permitted and which information may cross the perimeter. It is a far stronger promise than any privacy policy, because it is falsifiable.
OpenAI, with a different architecture and for a different problem, is exploring the same conceptual frontier: inside the boundary you compute, outside the boundary a closed list of signals emerges.
Privacy, in this form, stops being a promise and becomes a property of the system. And if it becomes a property of the system it also becomes verifiable, negotiable, certifiable. For anyone working on compliance as architecture that is enormous news, and for once it is good news.
With one consequence nobody has yet faced squarely: the list of what may leave the enclave is the real governance document of the whole architecture, and it is the part we discuss least.
From confidentiality to computability
Information security has always spoken of confidentiality: an unauthorised party must not be able to read the data. It is a clear property, defined on an object.
With systems that compute inside a closed boundary we need a subtler property, defined not on the object but on the operations: an unauthorised party must not be able to obtain certain computations on the data.
Possessing a medical record and possessing an oracle I can ask questions about the medical record are not the same thing. But the results can resemble each other far more closely than it suits us to admit.
If I cannot download the company salary table but I can query a system asking whether a given person earns more than €80,000, then more than €90,000, then more than €95,000, after a few questions I have reconstructed a significant part of the information without ever receiving a single record. It is the old problem of statistical disclosure control, the one that produced differential privacy, and language models make it immensely worse: because the query no longer has to be numerical, because you do not need to know the database schema, and because the number of sensible questions you can ask is no longer enumerable in advance.
The property to govern, then, is not only access. It is computability: which functions can be computed on that data, with what precision, how many times, with what outputs, on whose behalf.
It is a question almost no compliance checklist asks today, and one any systems architect recognises immediately as the right question.
Purpose limitation applied to what can be known
Here the GDPR turns out to be surprisingly contemporary, because the principle that best withstands the impact is also one of the oldest: purpose limitation.
Data is collected for a purpose. The trouble is that a foundation model is precisely a machine capable of reusing the same input for an enormous number of different purposes, and of doing so without anyone having programmed it to.
A conversation supplied for customer support can technically serve to infer sentiment. Sentiment can become churn propensity. Propensity can become commercial priority. The same conversation can suggest financial vulnerability, and financial vulnerability is the kind of information on which different prices for different people get built. None of these steps requires a fresh collection of data, and the technical capacity exists even when the organisation has no intention of using it.
It follows that privacy by design has to shift its object. No longer only preventing data from ending up in the wrong system, but preventing unauthorised computations from running inside the right system.
Call it, cautiously, inference minimisation. It is not a standalone GDPR category and there is no need to invent it as one. It is an architectural requirement flowing from the combination of principles already in place, and it has the merit of being a question you can ask at design time: which inferences are strictly necessary?
An assistant for booking medical appointments needs the speciality requested, the availability and the identity required to complete the booking. From the conversation it can deduce the person’s anxiety, their financial situation, the perceived seriousness of the problem, the likelihood they will cancel. It should not, and the practical difference is exactly here: not using those inferences is not enough. Certain classifiers, outputs, persistence layers and tools should be inaccessible to the application function, not merely disabled by a policy someone can change in an afternoon.
Anyone who thinks this is regulatory fantasy should reread Article 5 of the AI Act, applicable since 2 February 2025. It prohibits systems that infer a person’s emotions in the workplace and in education institutions from biometric data, subject to narrow medical and safety exceptions. And it prohibits biometric categorisation that deduces race, political opinions, trade union membership, religious or philosophical beliefs, sex life or sexual orientation.
These are two prohibitions that do not concern collection. They concern what it is lawful to deduce, and they apply regardless of how the data got there and how long it stays. The European legislator has already written, in a single article, the first rule that prohibits specific inferences by name. The Court of Justice had reached the same conclusion by interpretation; here it is text. It chose the narrowest possible perimeter, and rightly, because prohibiting inference in general would make much of artificial intelligence unusable. But the conceptual precedent exists.
The right question, then, is not whether an inference is prohibited. It is: was this inference necessary, foreseeable and legitimate with respect to the purpose the data was supplied for? It is purpose limitation applied to the space of producible knowledge.
Not being recognised, being classified
One might think the problem dissolves once identity is removed. It is a comfortable illusion and it needs dismantling.
A system can not know who I am and know enough to treat me differently. An advertising algorithm has no need of my name if it holds a pseudonymous identifier hooked to a sufficiently precise profile. An agent can not know my legal identity and still conclude that I belong to a risk category, adjusting the service accordingly: more cautious answers, a lower limit, one more verification step, a different price.
Anonymity answers the question: do they know who I am? Inferential privacy answers a different one: what can they decide that I am?
There is one last temporal asymmetry that makes retention an insufficient metric. The data can live two hundred milliseconds. The consequence can last years.
The conversation is not retained. During processing it generates a score. The score alters a decision. The decision enters the CRM, the ticketing system, the file, the history of the relationship. The prompt vanished at the moment the contract required. Its consequence became institutional history, and nobody will ever be able to trace how it got there.
If we draw that chain, the most sensitive item in the whole process is not the first element. It is the second.
Safety and privacy pull in opposite directions
Back to OpenAI, because the conflict it is trying to resolve is genuine and should not be charged to the company as a fault.
The more capable models become, the more their builders need to notice when someone is trying to use them to do harm. To notice, they have to observe behaviour. But the more they observe, the more information about people they accumulate. Safety pushes towards monitoring, data protection towards minimisation, and it is a tension that neither side’s good intentions dissolve.
The interesting answer is not choosing between privacy and safety. It is turning the choice into an architectural problem: run part of the monitoring inside a boundary where the provider does not receive the content, and let only what the safety function needs cross that boundary. It is the same logic as secure enclaves, confidential computing, private information retrieval and privacy-enhancing technologies generally. They do not remove the trade-off: they change its shape, and a different shape is sometimes all you need.
One detail of the announcement deserves more attention than it is getting, and it concerns who receives the alert. In OpenAI’s design the narrow signal reaches the company, the customer investigates on their own systems, and may then decide to share material. This is not only a privacy choice. It is a reallocation of responsibility: the provider keeps the classification, the customer keeps the enforcement. Anyone buying these services would do well to notice before signing, because it means part of the security work they thought they had bought remains theirs.
Not seeing is not the same as not deciding
Now the counterweight, without which everything above becomes a sales argument.
It is extremely easy to turn these architectures into a new generation of privacy washing, and even those who built them in good faith will be tempted, because the sentence is too good not to use: we never see your data.
It can be literally true. And it can be irrelevant to what is happening to the person. If the system can classify, filter, refuse, limit, flag or alter a service according to what it has deduced, the company continues to exercise substantial power over that person. The fact that no human being read the sentence does not reduce by one gram the effect of the category that came out of it.
The question therefore cannot stop at confidentiality. It has to reach: what effects can the inference produce?
A privacy-preserving system that discriminates is still discriminatory. A cryptographically impeccable system that wrongly infers a sensitive condition is still a problem, and for the person on the receiving end it is exactly the same problem as before. A secure enclave protects the data from administrators. It does not protect the person from the function running inside the enclave.
This is the distinction that holds the two halves of the problem together: security of processing does not coincide with its lawfulness.
Picture the perfect machine. Nobody can observe its inputs, nobody can alter its code, nobody can extract its data. And the machine makes unjust decisions. Its cryptographic perfection solves nothing, and in fact makes challenge harder, because every request to look inside will meet a technically impeccable answer: looking inside is precisely what the system was designed to prevent.
The privacy of the coming years will therefore have to hold together two properties we treat separately because they pull in opposite directions. Confidentiality of inputs, which demands opacity. Accountability for inferences, which demands transparency. We must stop unauthorised parties from seeing the data, and at the same time know which inferences are produced, for what purpose and with what consequences. It is a formidable tension and I know nobody who has resolved it.
The same goes for the transfer of trust these architectures involve, which should be said honestly. Before, I had to trust the administrator. Now I have to trust the hardware, the attestation, the code, the supply chain, the function being run, the correctness of the output and the policy establishing what may leave. Trust has not disappeared. It has been distributed across a wider surface and, this is the good part, across a surface that can be inspected.
From the data diagram to the inference diagram
From here comes the part that is useful to practitioners, and it is a change of form before it is a change of content.
I wrote in April that a DPIA is a genre, not a form, that is, a kind of writing with a recognisable structure rather than a template to fill in. If it is a genre, it can evolve, and for AI systems it must.
A DPIA for an artificial intelligence system cannot stop at describing categories of data, legal basis, recipients, retention periods, processors and international transfers. All of it is necessary and all of it is built around the idea that risk lives in an archive.
It has to start modelling the flow of inferences. On the input: who can read it, where it is decrypted, how long it survives. On representations: whether embeddings are created, whether they persist, whether they are linkable to a person, which is anything but obvious given that an embedding is neither raw data nor a declared inference. On the inference: which classifications are produced, which are necessary to the declared purpose, which constitute personal data and which touch special categories. On the action: whether the inference alters the system’s behaviour, whether it produces a decision, whether it is shown to a person. And finally on retention, at the end and not at the beginning: which part of the chain outlives the request.
From the data flow diagram to the inference flow diagram. It is not an academic exercise: it is the only way to notice that a system’s risk may sit entirely in an element that no DPIA template in circulation today asks anyone to describe.
A different vendor assessment follows, and this is the part immediately usable by anyone buying software. The classic question, do you use our data to train the model, remains necessary and is no longer sufficient.
At least three families of questions have to be added. Where the inference runs and who can access the input during processing, which is a question about architecture and not about intentions. What data is logged, which derived representations persist and for how long, and whether they are linkable to an identity. And finally which automated classifications are produced, which signals may leave the processing boundary, whether they feed decisions or enforcement, and by what mechanism a person can contest a wrong inference.
The last is the one almost no contract provides for today, and the one that, if the judgments of the past three years point anywhere, will be litigated.
Saying blandly that we do not retain data becomes ambiguous unless we have defined what counts as data. Raw input, derived representations, inferences, safety classifications, telemetry, human-readable logs, output, persistent state: that is eight different things, they can have eight different fates, and in almost every contract I have read two of them get named.
The second territory
There is one last place where this distinction changes the picture, and it is digital sovereignty.
We talk constantly about sovereignty over data: where it is stored, in which jurisdiction, on which cloud, run by which company. Those are indispensable questions and I have spent months writing that they are not enough, because sovereignty does not live in the data centre.
Run the experiment. All the data of a European hospital stays physically in Europe, inside a confidential computing environment operated by a European provider. An American model runs inside it. The inputs never leave the territory, the model provider cannot read them, the attestation is verifiable and the register of permitted computations is public.
Have we achieved sovereignty? Over the data, plausibly yes. Over the logic that turns that data into a clinical category and that category into a waiting-list priority, not necessarily.
Because five questions remain open that no localisation resolves: who controls the model, who establishes the categories the model may produce, who can update the function and with what notice, who verifies that the inferences are correct on a European population, and who decides what may leave the boundary.
Call it sovereignty over inferences, and set it alongside sovereignty over data rather than in its place. In recent years we have built an entire European technology policy around the localisation, control and availability of data, and it was not wrong. Artificial intelligence adds a second territory, which is the production of judgment.
A model receives facts and produces interpretations. It receives signals and produces categories. It receives history and produces prediction. That is where a growing share of digital power will be exercised, and that power can exist even when no human being ever saw the original data.
It is not only where the data lives that counts. It is where judgment is formed.
What we never told it
Someone who has read this far might object that I am building an overly abstract problem, and that all of this is simply the existing GDPR applied with more precision.
They would largely be right, and it is worth conceding fully because it is the strongest position of all. We do not need a new right to privacy. We do not need a GDPR for inferences. Purpose limitation, minimisation, accuracy, transparency, necessity, the rules on profiling and automated decisions, privacy by design: the tools exist, and the judgments I have cited show they work better than we thought. Those calling for a new law are usually asking, without knowing it, to restart from scratch a discussion Europe has already won.
The gap is probably not regulatory. It is architectural.
We go on designing compliance and information systems around databases, while informational value has moved inside computations that last two hundred milliseconds and leave nothing behind. We go on asking where the data is of systems whose principal risk is what they can deduce. The problem is not writing a new law. It is updating what we consider a processing surface.
Back to the employee at 11.40 at night.
For years we have thought about privacy through the metaphor of the door. Our data sits in a room, and the question is who holds the key. Cryptography made the door stronger. Minimisation tried to put fewer things in the room. The GDPR established who could come in, for how long and for what reason. These are real achievements and they should not be sold off for fashion.
Artificial intelligence puts a machine in the room. We can close the door perfectly and let nobody in. We can destroy everything that was inside a few milliseconds later, and we can prove it. But before doing so we can ask the machine that is in there to tell us what it understood.
And what comes out can matter more than everything we were trying to protect.
This does not make the achievements of traditional privacy useless. It makes them insufficient if we read them in a purely material way, as though risk were made of files.
The privacy of the database world protected above all what we had disclosed. The privacy of artificial intelligence will have to protect also what a machine can deduce without our ever having told it. It is a shift from possession of data to governance of knowledge, and it changes who has to answer for what.
The employee asked how leave works. The system, in the half second his sentence existed, established a probability about a condition he had not declared, and nobody was asked whether that probability served any purpose at all.
Nobody read it. It was not retained. It will train nothing.
And now it is the only thing left of that conversation.
Key takeaways
On 19 August 2026 OpenAI confirmed Zero Data Retention on frontier models and previewed Private Safety Processing. Under ZDR the content stays on infrastructure the customer controls, or encrypted on OpenAI servers with keys the customer holds; when automated analysis detects an abuse pattern, OpenAI receives a narrow signal carrying the type and severity of the activity, while the customer investigates the alert on their own systems. Rollout and a technical white paper are announced for September, so final judgment should be suspended.
Inference is not a recent discovery and European law already governs it. In July 2023, in Meta v Bundeskartellamt, the Court of Justice held that the prohibition on sensitive data applies even where the protected characteristic was never declared but is inferable from data collected and linked to the account. In December 2023, in SCHUFA, that the calculation of a probability rate is itself automated decision-making where the conclusion, performance or termination of a contractual relationship by the third party it is communicated to depends decisively on that rate. In February 2025, in Dun & Bradstreet, that access must supply the procedure and principles actually applied, not a formula.
What changes with foundation models is scale and above all temporality. Traditional profiling built a persistent profile by accumulating observations; here the inference can arise the moment the data crosses the system and be produced again, identical, on the next request. Knowledge is no longer a stored state: it is a capacity to rebuild one. You cannot delete a capacity.
The practical paradox: a system can minimise possession of the data perfectly and maximise the knowledge extracted from it. An insurer who never receives a medical record but only a health score computed on the phone possesses no clinical data and possesses the one thing it wanted. An inference is often data already converted into operational power: a purchase history needs interpreting, the label «likely financial distress» is ready to use.
The operational consequence is that a DPIA for an AI system cannot stop at the data flow diagram. It needs an inference flow diagram: which derived representations persist, which classifications are produced, which are necessary to the purpose, which signals leave the processing boundary, whether they are tied to an identity, whether they trigger a decision, and how a wrong inference can be challenged. The question of whether our data trains the model remains necessary and is no longer enough.
Questions & answers
What exactly did OpenAI announce on 19 August 2026?
Two distinct things. The first is confirmation that Zero Data Retention will remain available to eligible API customers on frontier models too: prompts and responses are not retained after processing, are not accessible to staff for review, and enterprise customer data is not used to train models absent explicit opt-in. The second is a preview of Private Safety Processing, a mechanism designed to recognise abuse patterns across several linked interactions without giving OpenAI staff access to the underlying content. Under ZDR configurations the content stays on infrastructure the customer controls, or on OpenAI servers encrypted with keys the customer holds; when automated analysis detects something, OpenAI receives a narrow signal indicating the type and severity of the activity, and the alert is investigated by the customer on their own systems. Rollout and a technical white paper are expected in September.
Doesn't the GDPR already cover inference and profiling?
It does, and more robustly than people assume. Article 4(4) defines profiling as automated processing aimed at evaluating personal aspects; European guidance has for years distinguished data provided, observed, and derived or inferred. The case law has gone further. On 4 July 2023, in Meta v Bundeskartellamt, the Court of Justice held that the prohibition on sensitive data bites even where the protected characteristic is merely inferable. On 7 December 2023, in SCHUFA, that the automated calculation of a probability rate is already automated decision-making under Article 22 where the conclusion, performance or termination of a contractual relationship depends decisively on that rate. On 4 October 2024, in Schrems v Meta, that minimisation forbids aggregating data without time limit and without distinction of type. The gap, if there is one, is not in the rules. It is in how we design systems and write impact assessments.
What does «inference minimisation» mean?
It is not a standalone GDPR category and the term deserves caution. It expresses an architectural requirement flowing from existing principles: if purpose limitation binds the use of data to the purpose it was collected for, and minimisation requires processing only what is necessary, then a system able to produce twenty classifications about a person when the purpose calls for one is already in tension with both. The practical difference is that not using the other nineteen is not enough: they should be inaccessible to the application function, not merely switched off by policy. The AI Act already contains an example of this logic, because Article 5 prohibits certain inferences regardless of how the data was collected.
If an inference is wrong, how do you exercise the right to rectification?
This is the hardest part technically. Rectification presupposes a recorded fact: a wrong address gets corrected. A probabilistic judgment produced by combining thousands of variables has no field to correct, and in a general-purpose model it may not even exist as a stored state, because it is rebuilt on each query. The route European law is taking runs through contestability rather than correction: the Dun & Bradstreet judgment of 27 February 2025 held that Article 15(1)(h) requires explaining the procedure and principles actually applied, concisely and intelligibly, and that trade secrecy is not an absolute defence, because that information must let the person obtain human intervention and express their point of view.
Does an architecture like Private Cloud Compute or Private Safety Processing solve the problem?
It solves an important piece and leaves another exposed. Apple designed Private Cloud Compute by removing remote shells and general-purpose logging from the nodes, admitting only predefined, structured and audited logs and metrics, and making the software inspectable by researchers. It is a far stronger promise than a privacy policy, because it moves trust from an operator who promises not to look to an architecture that technically does not let them. But the function running inside the enclave still computes on the data: that is its purpose. A secure enclave protects the data from administrators, it does not protect the person from the function running inside. Security of processing does not coincide with its lawfulness, which is why confidentiality of inputs and accountability for inferences have to be held together.
The author
