# Governed AI in the Enclave: Grounding Assistants on Data People Are Cleared to See

**A Project 82 white paper for CISOs, DPOs, and AI-governance leads**

---

## Executive summary

Generative AI adoption in regulated organisations has stalled — not for lack of appetite, but for two well-founded fears. The first is that data leaves the perimeter: prompts, context windows, and retrieved documents flowing to a third-party inference endpoint your organisation neither controls nor audits. The second is that models invent answers: an assistant that fabricates a transaction, a sanctions match, or a sensor reading is worse than no assistant at all, because it manufactures confidence without evidence.

Project 82 takes the position that both fears are legitimate, and that the answer is architectural, not contractual. Its assistant is designed so that neither failure mode can occur by construction:

- **Nothing leaves the perimeter.** Every model runs on infrastructure you operate. The deployment knob has three positions — `none`, `local`, `hosted` — and you choose. In an air-gapped enclave, only the local position exists, and prompts never cross the boundary. You can turn AI off entirely and lose nothing else.
- **The assistant sees exactly what the caller sees.** It is grounded strictly on the governed ontology, evaluated under the calling user's identity — tenant scoping, role, classification ceiling, and purpose grants all apply. There is no privileged model account and no side channel.
- **Findings are computed, not generated.** Every number, match, and lineage trace the assistant presents is produced deterministically by the platform's query layer from versioned, governed data. The model narrates and navigates; it does not invent facts.
- **Everything is logged; nothing is written without a human.** Every tool call, query, and proposal lands in the same append-only assurance log as any other platform action, and any change to the world requires explicit human confirmation.

This paper sets out that operating model in detail, maps it to the themes regulators consistently care about — residency, access control, auditability, human oversight, explainability — and closes with an evaluation checklist your organisation can apply to any AI assistant, including this one.

---

## 1. Why AI adoption stalls in regulated settings

The pattern is familiar. A team pilots an assistant against a public inference API; results are impressive; the pilot reaches the risk function; the pilot dies. The objections are usually some combination of:

1. **Residency and confidentiality.** The prompt is the data. Sending a question about a customer, a vessel, or a transaction to an external endpoint is a disclosure event, whatever the provider's terms say. For organisations under data-residency obligations, classification regimes, or sectoral secrecy duties, this alone is disqualifying.
2. **Access-control collapse.** Most retrieval-augmented deployments index documents into a vector store queried by a single service account. The model can then surface content to a user who was never cleared to read the source. Years of careful entitlement design are undone by one embedding pipeline.
3. **Fabrication.** Language models are fluent under uncertainty. In consumer settings that is an annoyance; in a regulated decision — a compliance disposition, an operational intervention — a fabricated fact is a governance failure with a name attached.
4. **Unaccountable actions.** An assistant that can act — file, flag, update, notify — without a human decision point creates an audit trail that ends at "the model did it".

Policies and vendor assurances mitigate none of these structurally. What does is an architecture in which the objectionable behaviour is not possible. That is the design brief Project 82's assistant was built against.

## 2. The platform underneath: governed data first, AI second

The assistant is not a bolt-on. It is the seventh pillar of a platform whose first six exist precisely to make data governable:

- **Integrate.** Connector agents sit inside your networks beside source systems and speak outbound-only to a single URL. Data lands as versioned, immutable datasets.
- **Transform.** Pipelines as code, with full lineage: every dataset version records its inputs and the exact transform version that produced it.
- **Model.** An ontology maps datasets onto business objects and links — people, sites, sensors, transactions — with object-level and property-level access policy and classification markings.
- **Analyse and act.** Operators explore objects, links, and time series; defined actions carry mandatory audit and approval workflows.
- **Govern.** Purpose-based access, marking ceilings, and an append-only audit of every read of marked data, exportable as evidence packs.

Two properties of this foundation matter for AI governance. First, **security is enforced at the object layer, in depth**: tenant isolation and classification ceilings are applied non-bypassably in the database itself, with role, purpose, and property-level policy evaluated above. Second, **everything is versioned and provable**: a dataset version is immutable, content-hashed, and traceable to its sources. An assistant grounded here inherits both properties. An assistant grounded on a copied document index inherits neither.

## 3. Sovereignty by construction: the deployment knob

Project 82 runs entirely inside your perimeter — a single host, a sovereign cloud, or a fully air-gapped enclave. In enclave deployments the only external channel is an architecturally one-way import path for signed bundles; nothing leaves, by design rather than by policy. The assistant is subject to the same invariant.

Inference has exactly three configurations:

- **`none`.** The assistant is off. The platform is fully functional without it — analysis, actions, and governance do not depend on a model. Where narration is useful (summarising a result set, describing a lineage graph), a deterministic no-model fallback produces it from the same computed facts. Turning AI off is a first-class configuration, not a degraded mode.
- **`local`.** Models run on your own hardware, inside the perimeter, using open-weight artefacts you have reviewed and approved. In air-gapped installs, model weights arrive through the same signed one-way import path as reference data and platform updates — versioned, verified, and recorded. This is the only permitted mode in an enclave.
- **`hosted`.** For organisations whose risk appetite permits it, an external endpoint may be configured explicitly. This is a deliberate, auditable choice by your administrators — never a default, never silent.

The governance consequence is simple to state to a regulator or an audit committee: **the location of inference is a configuration you control and can evidence**, not a property of a vendor's infrastructure. Under `none` and `local`, prompts, context, and outputs never cross your boundary.

## 4. The assistant sees what the caller sees

The single most consequential design decision is this: **the assistant holds no data and no privilege of its own.** It is a stateless intermediary that operates strictly through the platform's governed query interfaces, under the identity of the calling user.

- There is no separate AI index. No embedding store containing a flattened copy of your data outside the entitlement model. Grounding is performed at question time against the live ontology.
- Every retrieval the assistant makes is evaluated through the full authorisation stack — tenant, role, classification ceiling, purpose grant, object- and property-level policy — exactly as if the user had run the query in the console themselves. The coarse layers are enforced in the database and cannot be bypassed by any application code, the assistant's included.
- If a user is not cleared to see a property, the assistant cannot retrieve it, and therefore cannot leak it, summarise it, or be tricked into revealing it. Prompt injection against the assistant cannot escalate privilege, because the assistant has no privilege to escalate.
- Two users asking the identical question receive answers grounded on their respective visibility. This is not a filtered output; it is a difference in what was ever retrieved.

For a DPO, this collapses a hard problem into a familiar one. You do not need a new access-control regime for AI; the assistant is simply another client of the regime you already govern, and the same reviews that assure your entitlements assure your assistant.

## 5. Computed findings, narrated answers

Project 82 draws a hard line between two roles the assistant plays:

**Navigation and narration — the model's job.** Interpreting a question, choosing which governed queries to run, and expressing computed results in clear prose: "these three sites share a supplier; the linking records arrived in last Tuesday's ingest".

**Findings — the platform's job.** Every fact in that narration — the object identifiers, the link, the counts, the dates — is produced deterministically by the query layer from immutable, versioned datasets. The model is not the source of any factual claim; it is the interface to facts computed elsewhere.

Answers are grounded in referenced objects and dataset versions the user can open and inspect. Because datasets are immutable and lineage is complete, every fact traces to the exact dataset version and transform that produced it — the answer to "why does the assistant say this?" is a provenance graph, not a probability. If the governed data cannot support an answer, the honest response is "the data does not show this", and an assistant with nothing to retrieve has nothing to embellish.

This is the practical meaning of explainability here: not interpreting model internals, but ensuring the model is never the authority. You explain the answer by inspecting the data and the query — artefacts your organisation already knows how to audit.

## 6. Every step on the record

The assistant writes to the same append-only audit trail as every other platform component. For each interaction, the assurance log captures:

- the calling user and the effective authorisation context;
- every tool call and governed query the assistant issued, and against which dataset versions;
- every read of classification-marked objects (audited identically whether a human or the assistant performed the retrieval);
- every proposal the assistant made, and its outcome.

Because dataset versions are immutable, the log supports genuine reconstruction: you can determine after the fact not only what the assistant answered, but what it could see at that moment and what it looked at. AI interactions appear in the same exportable evidence packs as the rest of the platform's audit record — one trail, one review process, no AI-shaped gap in it.

## 7. The human stays in the loop for anything that touches the world

The assistant's write path is proposal-only. It may draft an action — flag an object, assign a case, annotate a record, propose a writeback to a source system — but execution requires a human decision, taken by a user authorised for that action, through the same approval workflow that governs manually initiated actions.

Beneath the workflow sit structural limits. Actions are predefined, typed operations on ontology objects — there is no free-form execution surface for the assistant to reach. Writebacks to source systems travel as cryptographically signed jobs restricted to allow-listed statement templates; even a fully compromised control plane, let alone a misbehaving model, cannot make a connector agent execute arbitrary statements. The blast radius of a bad proposal is a rejected proposal.

Accountability therefore never transfers to the model. Every consequential act has a named human approver, recorded alongside the assistant's proposal in the assurance log.

## 8. An operating model for AI under regulation

Regulatory frameworks for data and AI differ in detail but converge on themes. The architecture above answers each structurally:

| Regulatory theme | Project 82 mechanism |
|---|---|
| **Data residency & sovereignty** | Inference location is your configuration (`none`/`local`/`hosted`); enclave deployments are architecturally incapable of egress; prompts never leave under `none`/`local` |
| **Access control & minimisation** | Assistant operates under the caller's identity through the full entitlement stack; no shadow index; retrieval limited to what the question requires and the caller may see |
| **Auditability** | Append-only assurance log of every tool call, query, marked-data read, and proposal; exportable evidence packs; immutable versions enable reconstruction |
| **Human oversight** | Proposal-only writes; typed actions with approval workflows; signed, allow-listed execution path; a named approver for every consequential act |
| **Explainability & accuracy** | Facts computed deterministically from governed data with full lineage; the model narrates but is never the source of a factual claim |

The general principle: where a regulation demands an assurance, prefer a mechanism that makes the violation impossible over a process that promises to detect it.

## 9. Can we actually deploy an AI assistant here? An evaluation checklist

Apply these questions to any candidate — including Project 82. A defensible deployment should answer yes to all of them, with evidence.

**Residency and control**
1. Can inference run entirely on infrastructure we operate, and can we prove no prompt or context leaves our perimeter?
2. Can we turn the AI capability off completely without losing the underlying platform?
3. If we permit hosted inference, is it an explicit, logged administrative choice rather than a default?

**Access control**
4. Does the assistant query live governed data under the calling user's identity, or a copied index under a service account?
5. Will two differently cleared users asking the same question receive answers grounded only on their respective entitlements?
6. Is the coarse access layer enforced somewhere the assistant's application code cannot bypass?
7. If the assistant is manipulated through its prompt, what privilege can it escalate? (The right answer is none.)

**Grounding and accuracy**
8. Is every factual claim in an answer computed deterministically from governed data, with a reference the user can open?
9. Can we trace any statement to the exact data version and transform that produced it?
10. What does the assistant do when the data cannot support an answer?

**Auditability**
11. Is every tool call, retrieval, and proposal recorded in an append-only log we can export as evidence?
12. Can we reconstruct, after the fact, what the assistant could see and did see for a given interaction?
13. Do reads of classified or specially marked data by the assistant appear in the same audit trail as human reads?

**Oversight and action**
14. Can the assistant change anything in the world without a named human approving it?
15. Are the actions it can propose drawn from a typed, predefined set, with execution paths constrained independently of the model?

**Model supply chain**
16. Are model weights versioned, licence-reviewed, and delivered through a verified channel we control?
17. Can we substitute or retire a model without altering the governance properties above?

If a candidate assistant fails these questions, no acceptable-use policy will close the gap: the risks your governance function fears are properties of its architecture. Project 82 was built to pass them by construction — the assistant is a governed client of a governed platform, and the AI question reduces to one your organisation already knows how to answer: is the data governed, is access enforced, is every action on the record, and does a human decide?