The Compliance Layer Most UK AI Products Quietly Skip

## Grep your codebase for "sk-"

Do it now. Open every repo your product touches and search for API keys — OpenAI, Anthropic, Google, whoever. If you're like most AI startups we talk to, you'll find them in half a dozen places: a `.env` file here, a serverless function there, one hardcoded in a Slack bot nobody remembers deploying. Each one billed separately, rotated never, and monitored by absolutely no one.

This works fine right up until it doesn't. Someone leaves. A key leaks in a public repo. A customer asks what happens to their prompts after they hit the model. An enterprise procurement team sends over a security questionnaire with a question like "describe your data processing controls for third-party AI services" and you realise the honest answer is: we don't really have any, we just call the API.

## The gap nobody budgets for

Most AI products are built the way most software used to be built before anyone cared about infrastructure-as-code: fast, scrappy, and structurally incapable of answering a simple question — **what did our AI actually do, for whom, and can we prove it?**

There's no central place to:

- Kill a feature instantly if a model starts misbehaving or a provider has an incident - See spend by tenant, by feature, by day - Enforce a guardrail once and have it apply everywhere - Rotate a compromised key without a deploy - Produce an audit trail when a regulator, auditor, or enterprise customer actually asks for one

Every one of these gaps is invisible until the moment it isn't. And the moment it isn't is usually the worst possible moment: a breach, a bad output that reaches a customer, or a due diligence process ahead of a funding round or acquisition.

## Why this matters more in the UK than founders think

UK GDPR hasn't gone anywhere, and the ICO's accountability principle is specific: you have to be able to demonstrate compliance, not just assert it. In practice that means keeping records of your processing activities and being able to show how personal data moves through your systems. GDPR doesn't say "log every prompt" — that's not a statutory requirement — but if your AI product touches personal data, and most do even indirectly through user inputs, "we called an API and didn't keep track" is a weak answer when someone asks you to account for it.

The EU AI Act is worth reading precisely, because it's easy to over-read. It tiers systems by risk. The heavy duties — record-keeping and logging (Article 12), human oversight and the ability to intervene (Article 14) — are legal requirements for high-risk systems (the Annex III categories) and certain general-purpose model providers. Most LLM-wrapper products aren't in that bracket: they sit at limited risk, where the main obligation is transparency (Article 50 — telling people they're interacting with AI), or at minimal risk with no specific statutory duty at all. So, to be clear: the Act does not mandate an audit trail and a kill-switch for every startup with an API call, and anyone telling you otherwise is overstating it.

Here's why the capability still matters. The direction of travel is unmistakable, and enterprise buyers have already moved ahead of the letter of the law. Security questionnaires now routinely ask about model governance, prompt logging, and kill-switch capability — not because a regulation forces your specific product to have them today, but because your customers' risk teams want them. Founders without answers lose deals, not because their AI is bad, but because they can't demonstrate control over it. Building the capability early is a commercial advantage now and a compliance head-start if your product ever moves up a risk tier.

## The fix is boring, which is the point

The obvious answer — the one most teams reach for under pressure — is to bolt monitoring onto each integration individually. This is a mistake. It multiplies the problem instead of solving it: now you have a dozen half-implemented governance layers instead of one missing one.

The better pattern is a gateway. Every product routes its AI calls through one governed layer instead of embedding provider keys directly. Done well, that single layer is where you get:

- **One place to enforce policy** — guardrails on prompts and responses apply centrally, not per-app - **Per-tenant metering and spend caps** — you know what each customer or feature is costing, and you can cap it before it becomes a surprise invoice - **Key rotation without touching product code** — rotate a compromised or expiring key at the gateway, not across every repo that references it - **Per-tenant isolation** — whitelabel tenants share a model layer without bleeding into each other's data or limits - **An audit trail** — a record of what was sent, what came back, and when, so when someone asks "prove it," you can

That's the target spec of the pattern, and it's what we're building our own gateway, Sol AI, toward. In honesty about where it actually is: Sol AI is a preview, not a finished platform. What's working and verified today is the core of it — AI calls routed through one central layer instead of per-product keys, central guardrails that block unsafe prompts (including child-safety escalation) before anything reaches a model, and metered cost per call. The rest of that list — per-tenant spend caps, full tenant isolation, a complete audit log, hands-off key rotation — is architecture we're extending it toward, not a shipped feature set I'm going to pretend is done. The pattern is the point; our implementation of it is honest work in progress. That distinction is exactly the one this post is asking you to make about your own product.

None of this is exciting. It won't feature in a product demo. But it's the difference between a pile of AI features and a system you can stand behind in front of a regulator, an auditor, or an enterprise buyer's security team — the difference between saying "we think it's fine" and being able to show why.

## The founders who skip this aren't lazy

They're moving fast, which is rational early on. The mistake is assuming this layer can be added later without cost. It can't. Every repo that embeds a raw key today is a repo you'll need to refactor tomorrow, under more scrutiny and less patience, usually right when you can least afford the distraction.

Build the boring layer while it's still cheap to build.

If you want to compare notes on how the gateway pattern works in practice — including the parts we've finished and the parts we haven't — get in touch. We're happy to walk through it honestly.