The attractive promise of personal AI is not better chat. It is continuity of thought. A capable system could understand a principal’s commitments, retrieve the history behind a decision, compare advice across disciplines, prepare a meeting from private records and notice when today’s instruction conflicts with yesterday’s constraint. That value requires context. Context is also where the danger begins. The more useful the system becomes, the more it knows about relationships, assets, health, travel, disputes, strategy and authority. A generic procurement question—“Is the model secure?”—is therefore nowhere near sufficient. Personal AI needs a private architecture: an explicit design for where information lives, how it is retrieved, what the model may infer, who can administer the system and what survives after the interaction.
Private is not a product tier
A vendor may offer consumer, business and enterprise plans with different promises around training, retention and administration. Those differences matter. They do not resolve the architecture. Privacy is an end-to-end property. A supposedly private model can still receive over-broad context from a connector, write sensitive output into an exposed workspace, retain logs longer than expected or depend on administrators with excessive access. Conversely, a hosted model can sometimes be used within a strong private design when the data flow, contractual terms and control surface are understood. The correct question is not “cloud or local?” It is: what can every component see, retain, combine and cause?
Start with information domains
Do not pour the private office into one giant corpus. Divide information by domain and consequence.
- Personal: identity, health, family, travel and private communications.
- Institutional: governance, finance, operations, advisers and staff.
- Transactional: live deals, disputes, payments and diligence.
- Research: licensed sources, public information and working analysis.
- Restricted: material that must not enter an AI workflow without a specific approval.
For each domain, define permitted users, models, purposes, locations, retention and export. The AI should retrieve only the minimum context needed for the task, not everything available to the user.
The private AI control plane
A credible architecture needs at least seven controls:
- Identity: every person, service and agent is separately authenticated; shared accounts do not become the default.
- Authorisation: access is evaluated for the specific resource and action, not inferred from being “inside” the office.
- Retrieval: source documents are filtered before they enter the model context.
- Provenance: material answers show which records and versions support them.
- Retention: prompts, outputs, embeddings, logs and temporary files have explicit lifetimes.
- Administration: model administrators, data custodians and security operators do not silently inherit one another’s powers.
- Execution: the ability to draft or recommend is separated from the ability to send, sign, transfer, publish or delete.
NIST’s zero-trust guidance is useful here because it rejects implicit trust based on network location or ownership. For private AI, the same principle should apply to context: a document is not safe to disclose to the model merely because it sits inside the same workspace.
Memory must be governed
Personalisation often depends on memory. But “remember this” can mean several different things: preserve a preference, store the full conversation, update a profile, create an embedding or retain a generated summary. Make the memory classes visible. A user should know what is transient, what becomes durable, who can read it and how it can be corrected or removed. High-consequence facts—beneficial ownership, medical conclusions, legal positions, identity evidence—should not silently become model memory. When a system produces a profile or summary, treat it as a derived record with its own provenance and review date. Inaccurate memory is not merely an inconvenience; it can distort every later answer.
Design for administrators and vendors
Private architecture must include the people who can change it. List who can add a connector, alter a retention rule, inspect logs, export data, reset accounts and change the model. Require strong authentication and independent approval for consequential configuration changes. Then document vendor boundaries: subprocessors, regions, support access, incident notice, deletion mechanics, model-improvement terms and exit procedures. Marketing statements belong in the evidence file, not in the threat model.
A minimum deployment sequence
- Choose two or three narrow use cases with clear value and bounded information.
- Classify the data and prohibit restricted domains by default.
- Map the full request path from source record to model to output and logs.
- Test whether permission changes in the source propagate to retrieval.
- Test prompt injection and cross-domain retrieval with deliberately adversarial content.
- Create a human approval boundary before any external or irreversible action.
- Define incident response, export and deletion before inviting the principal to depend on the system.
Only then should the architecture absorb more context.
Capability without surrender
The point is not to build a sealed machine that nobody uses. It is to create enough control that the system can become genuinely useful without requiring the principal to donate the whole institution to an opaque memory. Personal AI will become consequential when it can see continuity across private life. That is precisely why its architecture must be private before its answers become indispensable.