What Does Your AI Actually Need to Know About You?
As AI systems become more personal and connected, privacy increasingly depends on how much information reaches the model at the point of inference.
AI is becoming deeply personal.
People use generative AI to interpret medical letters, review contracts, analyze financial documents and draft responses to private emails. As assistants evolve into agents, they also interact with calendars, customer records, enterprise applications and other sources of sensitive information.
This creates an architectural challenge.
Useful AI requires context. But completing a task does not necessarily require exposing every personal identifier contained within that context.
Consider an AI system analyzing an insurance dispute. It may need the policy wording, the insurer’s reasoning, relevant dates and the chronology of events. It may have little reason to receive the customer’s name, email address, home address or policy number in their original form.
That distinction matters because every unnecessary piece of information introduced into the model’s processing environment creates additional privacy exposure.
AI adoption is expanding the privacy surface
The tension between AI adoption and privacy is already visible.
Deloitte’s Digital Consumer Trends 2025 based on 2,000 consumers across the UAE and Saudi Arabia, found that around 58% had used generative AI applications. Among those who used GenAI less than once a month, 25% cited concerns about data privacy as a reason for not using it more frequently.
A wider 2025 study by the University of Melbourne and KPMG, covering more than 48,000 respondents across 47 countries, found that 66% used AI with some regularity, while only 46% were willing to trust AI systems.
This gap becomes increasingly significant as AI interactions involve information about health, finances, legal problems, employment and other sensitive areas of people’s lives.
The more useful AI becomes, the more likely it is to encounter information that requires careful handling.
This raises an important architectural question: does every component involved in completing a task need to receive that information in its original form?
Context does not always require identity
Imagine a customer asking an AI assistant to review an insurance claim rejection.
The document might contain the customer’s:
- name;
- policy and claim numbers;
- email address;
- telephone number;
- home address;
- medical information;
- policy wording; and
- the insurer’s explanation for rejecting the claim.
For the reasoning task, only some of this information may matter.
The model may need the policy terms, dates, factual circumstances and insurer’s reasoning. The identity of the customer may have no bearing on the analysis.
Yet a conventional AI workflow may send the entire document to the model simply because the application treats it as a single unit of context.
That design choice deserves scrutiny.
Software systems already separate information according to function. Authentication systems establish identity without distributing credentials throughout an application. Payment systems use tokenization to reduce repeated exposure of card information. Access-control systems rely on permissions rather than circulating complete identity records.
AI systems can apply a similar principle.
The application can retain information necessary for the wider workflow while limiting what is exposed to the component performing the reasoning.
Data minimization at inference
Data minimization is a longstanding privacy principle. Under the GDPR, personal data should be adequate, relevant and limited to what is necessary for the purposes for which it is processed.
For AI systems, this principle also applies at the point of inference.
An important control point is therefore the information included in the request sent to the model.
The UK Information Commissioner’s Office addresses this directly in its guidance on AI and data minimization. At the inference stage, the ICO identifies techniques including converting personal data into more abstract formats, making inferences locally and using privacy-preserving query approaches. These approaches can reduce the information revealed in a query while still allowing a system to return a useful prediction or classification.
The OECD’s work on privacy-enhancing technologies provides a broader supporting framework. Its 2025 paper on PETs and AI identifies data minimization and confidentiality as two important privacy objectives and examines technologies that can limit the collection, disclosure and processing of sensitive information in AI systems.
The European Data Protection Board has similarly emphasized that data minimization applies across the development and deployment of AI models, requiring personal data to be adequate, relevant and necessary in relation to the purpose of the processing.
Together, these approaches support a useful architectural principle:
Sensitive information should be transformed or minimized before reaching a component that does not require the original value.
This brings data minimization closer to the point at which information is actually used.
A privacy boundary before the model
Consider a simple instruction:
Send the revised insurance claim to Sarah Khan at sarah@example.com and reference policy 87429361.
A privacy layer positioned before the model could identify information that the reasoning process does not require in its original form.
The model might instead receive:
Send the revised insurance claim to <PERSON_1> at <EMAIL_1> and reference policy <ID_1>.
The structure and meaning of the task remain intact.
The model still understands that the workflow involves a person, an email address and a policy identifier. It can draft the correspondence and determine how the information should be organized.
The original values can remain inside a controlled system boundary and be restored only when the workflow genuinely requires them.
This creates a useful separation between task context and raw identity data.
The model receives the information necessary to perform its role. The wider application retains responsibility for the sensitive values.
What this DOES - and DOES NOT - solve
Inference-time minimization should not be overstated.
Reversible masking does not automatically make information anonymous. Where an organization retains the ability to restore or link information to an identifiable person, pseudonymized data may still constitute personal data and remain subject to applicable privacy law.
Identity may also be revealed indirectly.
A rare medical condition, specific job title, unusual transaction or sufficiently detailed factual chronology can make an individual identifiable even after obvious identifiers such as names and email addresses have been removed.
Inference-time minimization therefore belongs within a broader privacy architecture incorporating access control, purpose limitation, retention rules, security controls, provider governance and appropriate authorization.
Its purpose is narrower:
to reduce the unnecessary exposure of information that the model did not need to receive in the first place.
That is a limited objective, but a practical one.
Building the model boundary into ZeroH
This is one of the architectural problems being addressed in ZeroH.
The ZeroH Privacy Gateway is designed to operate at the model boundary. It reversibly masks personally identifiable information using typed placeholders, stores the corresponding mappings within a tenant-scoped vault and maintains a privacy audit trail.
Masking and resolution are separated so that downstream components do not independently interpret or restore placeholder mappings.
The architecture is built around a simple principle:
Personal information should remain in its original form only where that form is necessary to the task.
That changes the questions system designers need to ask.
Which component actually needs the original information? At what stage? For what purpose? For how long? Could the model perform the same reasoning using a placeholder, category or transformed representation instead?
These questions translate data minimization from a policy principle into system behavior.
Privacy as an architectural property
AI systems will continue to become more connected.
Personal assistants will interact with richer stores of information. Enterprise agents will work across email, documents, CRM platforms, databases and external tools. Healthcare, financial services and professional applications will increasingly involve information whose sensitivity is inseparable from the task itself.
Preventing AI from interacting with sensitive information altogether is therefore unlikely to be a sufficient privacy strategy.
A more useful objective is to control how much information each component of the system receives.
The most mature AI systems may eventually be defined partly by what they are designed not to receive.
At every model boundary, there is a simple question worth asking:
What does the model actually need to know to perform this task?
The answer will often be less than the full record. Designing for that difference is likely to become an important part of trustworthy AI.
