Private & Secure Enterprise AI
Eventually somebody asks a simple question: who can send what data to which model, and what is that model allowed to do with it. This is the layer that makes the answer explicit — routing, identity, boundaries, audit and cost attribution in one place.
- Who
- Founder holds the engineering leadership seat; the delivery team executes underneath it.
What you're seeing
- Nobody can produce a list of which models the company sends data to.
- Usually means Adoption outpaced procurement, which is the normal sequence. It becomes urgent at the first customer security questionnaire, because the honest answer is currently distributed across expense claims.
- Each project invented its own approach to approvals and data handling.
- Usually means There is no reusable pattern, so every team pays the governance cost from scratch and reaches a different answer. The variance is the risk, more than any individual decision.
- A customer has asked where their data is processed and by whom.
- Usually means The model provider is a subprocessor and is being treated as a tool. That distinction is the one their auditor will make, and it usually arrives attached to a contract.
- AI spend cannot be attributed to a team or a product.
- Usually means Keys are shared and usage is not tagged, so cost control has to be exercised as a blanket limit rather than as a conversation with whoever is spending. Blanket limits break the wrong things first.
- A team was told to stop using a tool and given no alternative.
- Usually means Security acted because it had no way to say yes safely. That produces shadow usage rather than compliance, and the next occurrence will be harder to see.
Adoption is already distributed
AI does not arrive centrally. A team buys a product. A developer calls a provider directly. An internal tool grows an agent. A department signs up for something on a card. None of it is wrong, and by the time anyone looks, sensitive information is crossing boundaries nobody designed.
The question that eventually forces the work is narrow and hard to answer after the fact: who can send what data to which system, and what can that system do with it.
One layer, several controls
Employees, products and agents reach models through one path. That path authenticates against your identity provider, applies policy by role and data classification, routes to the appropriate model, handles provider fallback, redacts or blocks what should not leave, records the interaction, and attributes the cost to whoever incurred it.
Around it sit the pieces that make it defensible: private retrieval environments, permissions for agents that act on their own, controls for personal and sensitive data, evaluation so a model swap is a measurement, and deployment inside a VPC or on your own hardware where a requirement genuinely demands it.
The reason it usually gets funded
Rarely a risk register. Usually a deal.
An enterprise customer sends a security questionnaire asking which subprocessors handle their data, what those subprocessors retain, and what human oversight exists. Answering that with a list assembled from expense reports is the moment the architecture conversation becomes concrete, and the cost of answering it properly is lower before the deal than during it.
The same work makes the second and third AI initiative substantially cheaper, because they inherit an approved pattern instead of negotiating their own.
Where it sits
This is the platform underneath AI & Automation rather than one of its workflows. Every other page in the category eventually depends on it — the knowledge layer in enterprise RAG needs permission-aware access as a first-class property, and agents that act need identity and an audit trail.
It overlaps directly with certification work. Where a SOC 2 or ISO 27001 programme is already running, the model provider enters vendor review like any other subprocessor and the logging requirements are shared — that programme is SOC 2 readiness, and doing both at once is cheaper than doing them a year apart.
Sequencing
This is platform work, and platform work has a failure mode: it gets built completely before anything uses it, and the first real workload turns out to need something the design did not anticipate.
So it runs the other way round. The first application through the gateway is chosen before the gateway is built, and it is a real one with a real deadline. That application decides which controls ship first, and it gives the platform a user whose complaints are worth listening to. Policy, redaction rules and the approval workflow follow the workloads rather than preceding them, and each subsequent team either fits the existing pattern or produces a specific reason to extend it.
What that avoids is the governance layer that arrives finished, describes a set of controls nobody asked for, and is quietly bypassed by the team with the deadline. Every organisation has one of those somewhere, and it is usually the reason the current AI usage is invisible.
What this covers
Each of these is a capability with its own page, its own order of work and its own outputs.
| Capability | What it means |
|---|---|
| Observability Stack | Enough signal to answer a question you did not anticipate. Metrics, logs and traces joined by a common identifier, with the cost of collection under deliberate control. |
| Security Audit | An assessment of where the system is exposed, ranked by what an attacker would actually reach. Findings written so they can be fixed rather than filed. |
| Vendor Risk Management | Both directions of the same problem: assessing the vendors you depend on, and answering the questionnaires your own enterprise buyers send. One evidence base serves both. |
How we decide
Access is granted by policy against identity, not per project
Costs It requires the identity work to be done before the first team is onboarded, which feels like overhead for one use case.
Per-project approval scales linearly in effort and produces inconsistent outcomes, because each review is a different person's judgement on a Thursday. A policy expressed against roles and data classifications is reviewable as a whole, reusable by the next team without a meeting, and answerable in one artefact when an auditor asks.
Cost is attributed before it is capped
Costs Attribution is more work than a global spend limit and it delays the moment there is any control at all.
A cap with no attribution fails indiscriminately — the first workload to hit it is not the one causing the spend. Tagging by team, product and call path turns cost into a conversation with the owner, which is the only mechanism that changes the design decisions actually driving the bill.
Self-hosting is justified case by case, never adopted as a posture
Costs It leaves some data on hosted providers, which is uncomfortable to defend in the abstract.
Running open-weight models yourself trades a per-token bill for fixed infrastructure, an operations burden and a quality gap that changes every quarter. It is the right answer for genuinely regulated data or for volume high enough that the fixed cost undercuts per-token, and the wrong answer as a default, where it produces an expensive cluster serving workloads that had no residency requirement.
Four ways organisations handle AI risk
Three of these are chosen and one is arrived at by not choosing. The last is the most common state.
| Approach | What it controls | What it costs | When it fits |
|---|---|---|---|
| A central gateway | Routing, identity, data boundaries, audit and spend | Platform work up front, then ongoing ownership | Several teams using AI, with regulated or customer data in scope |
| Per-project governance | Whatever each review happened to catch | A review cycle per initiative, repeated indefinitely | One or two initiatives, and no plan for more |
| A single-vendor agreement | Everything, as long as nobody needs another model | Concentration risk and no leverage at renewal | A small estate with a strong preference for one provider |
| Prohibition | Nothing — it relocates usage rather than stopping it | Shadow adoption you cannot see or audit | Nothing, at any size |
The fourth row is where most organisations start, usually without a decision having been made. It is the only one of the four that makes the risk less visible rather than smaller.
Is this you?
- AI adoption happened per team and nobody owns the total
- A customer or auditor has asked where their data is processed
- Regulated data is in scope and the deployment model has to be defensible
- A single AI feature, where the boundary is a design decision inside it
- Organisations wanting a policy document rather than an enforced control
- Anyone whose answer to AI risk is to prohibit it and hope
How we run it
The gateway is the only path, or it is decoration
A routing layer that teams can go around gets gone around, and the traffic that avoids it is exactly the traffic worth seeing. Egress controls, credential management and a genuinely better developer experience are what make the central path the easy one — the policy is downstream of that.