AI Governance and Data Boundaries

Use AI on regulated data, and prove how.

Talk to us
Runs against
Every model call your product makes
Enforced at
The gateway, not a policy document
You get
A registry, a routing policy, an audit trail

Permission is not a policy document

Healthcare, education and telecommunications sit on the strict side of every permissibility question. The blocker is rarely capability; it is the inability to show a regulator, a customer or a procurement team exactly which model saw which class of data, and under what control.

Most organisations answer that question with a document. A document does not stop a request. Somewhere between a developer’s convenience and a model gateway’s default route, protected data reaches an endpoint nobody approved for it, and the first anyone knows is when they are asked to prove it did not.

So the control has to sit where the request does. We design and implement the boundary in the gateway, and the evidence trail that lets you reconstruct any decision it made.

Where the data boundary is enforced in the request path Requests enter carrying a data class: regulated on the left, internal on the right. Both pass through a policy and provenance router, which tags the class and logs the decision. The router sends regulated work only to an approved, US-hosted tier, and internal work to a self-hosted open-weight tier. A bar between the two tiers marks where regulated data stops: it never reaches the cheaper tier. Every decision from both tiers lands in one evidence store holding the prompt, the model version, the data class and the outcome. The star marks the router: the routing policy you keep. Every request carries its data class Regulated Internal Policy and provenance router Approved tier Open-weight tier Evidence The boundary is enforced, not documented. PHI, student data tooling, dev, test tags the class, logs the decision US-hosted, BAA self-hosted only regulated data stops here prompt, model version, data class, outcome Where the data boundary is enforced in the request path Requests enter carrying a data class: regulated on the left, internal on the right. Both pass through a policy and provenance router, which tags the class and logs the decision. The router sends regulated work only to an approved, US-hosted tier, and internal work to a self-hosted open-weight tier. A bar between the two tiers marks where regulated data stops: it never reaches the cheaper tier. Every decision from both tiers lands in one evidence store holding the prompt, the model version, the data class and the outcome. The star marks the router: the routing policy you keep. Every request carries its data class Regulated Internal Policy and provenance router Approved tier Open-weight tier Evidence The boundary is enforced, not documented. PHI, student data tooling, dev, test tags the class, logs the decision US-hosted, BAA self-hosted only regulated data stops here prompt, model version, data class, outcome
The router is the control. A data class that may not reach the cheaper tier cannot reach it, and every decision either tier makes is reconstructable from one identifier.

What we put in place

Six controls, each of which someone outside the engineering team can be shown.

  • A model registry Origin, licence, version and approved data classes recorded for every model in use, so the question “what is running” has one answer.
  • A hard data firewall Regulated data classes blocked at the gateway rather than by policy document. No PHI, student or subscriber personal data leaves the approved tier.
  • A policy and provenance router Every request tagged with its data class and routed only to endpoints permitted for that class, with the decision logged as it is made.
  • A tiered model estate An approved tier for clinical, customer-facing and government-adjacent workloads; a cheaper self-hosted tier for internal tooling, development and test.
  • Defined re-evaluation triggers Named events — an export-control designation, a procurement restriction, a new customer class — each with an owner, so a review is forced rather than waited for.
  • An evidence trail Prompt, model version, data class and outcome joined under one task identifier, so reconstructing a decision is a query rather than an investigation.

How the engagement runs

Four stages, each ending in something a regulator or a procurement team can be shown. No weeks are attached: the last stage is event-driven by design, and the first cannot be estimated before the data classes are known.

  1. Stage 1 Permissibility map Every data class your product handles, mapped to the endpoints permitted for it, and signed off by whoever actually owns the risk rather than by whoever owns the code. You get: a data-class-to-endpoint map, with a named owner against each row.
  2. Stage 2 Registry and policy The registry populated for every model already in use, the routing policy written against the map, and the re-evaluation triggers named along with who acts on them. You get: a populated model registry and a written routing policy.
  3. Stage 3 Enforcement The boundary implemented in the gateway, and then tested the only way that counts — by attempting the blocked routes and confirming they fail. You get: the boundary live, and a test that demonstrates it holding.
  4. Stage 4 Evidence Routing decisions logged and queryable, so the answer to “which model saw this?” is a query someone can run in front of the person asking. You get: an audit trail, and the query that reads it.

What you leave with

A boundary you can point at: enforced in the gateway, recorded in the registry, and evidenced in the logs.

  • The permissibility map — the document the others are built from, and the one a procurement questionnaire answers from.
  • The model registry — origin, licence, version and approved data classes, maintained rather than reconstructed.
  • The routing policy, enforced — in the gateway, with the blocked-route test that proves it.
  • The evidence trail — and the query that turns it into an answer.

The method, published

How an agent is kept inside the boundary is argued in Layer 6 of the production agent stack: an agent inherits no more authority than the user, and irreversible actions are gated before the side effect.

Tell us which data classes you handle and which endpoints they can reach today. If you cannot answer the second half, that is the engagement.

Talk to us

Related services

AI and Agent Engineering

Agent Production Readiness

Assess an agent system against the eight layers a production stack needs, and get a ranked plan to close the gaps.

Tell me more
AI and Agent Engineering

Agent Evaluation and Cost per Task

Instrument what your agents actually complete, and what each completed task costs once retries and review are counted.

Tell me more
AI and Agent Engineering

LLM Gateway and Model Routing

One vendor-neutral gateway in front of every model, so routing, cost and failover are yours to change.

Tell me more