Policy governs intent. Infrastructure governs behaviour.

Policy documents do not stop a rogue agent. What actually enforces governance is the infrastructure layer and this is what building it looks like in a mission-first organisation.

I spent ten years as Head of Data at the RNLI. For most of that time, the governance conversation was about data: what we collected, how we stored it, who could see it and under what conditions. The technology moved fast. The structures to govern it moved slower. That pattern has not changed. What has changed is the stakes.

This is the first of three articles on AI governance in mission-first organisations. The second walks through a working implementation in code. The third shows how this publication practises what it preaches.

The problem is already here

AI is not arriving at the frontline of mission-driven organisations in a controlled, well-planned sequence. It is already there, often in forms nobody signed off on. A caseworker summarising a messy client file in ChatGPT because the internal system is too slow. A fundraiser drafting grant applications with a public LLM. A volunteer coordinator running beneficiary lists through a free tool that nobody has checked the data processing terms on. Not malice. Pragmatism.

The governance response to this, almost universally, is a policy document. An acceptable-use policy. A guidance note on AI tools. These are not useless, but they are not sufficient. A policy document cannot intercept a prompt. It cannot redact a phone number before it leaves the building. It cannot rate-limit an agent that is making a hundred API calls a minute because someone left it running overnight.

Policy governs intent. Infrastructure governs behaviour.

When I was trying to introduce data tooling at the RNLI, the question I kept getting was a reasonable one: what happens when it goes wrong? Not what is the policy if it goes wrong. What actually stops it going wrong.

The honest answer, for most of the AI tools being deployed in mission-first contexts right now, is: nothing technical. There is a prompt that says be careful, and there is a policy that says use it responsibly, and beyond that the system will do whatever it does.

That is not governance. That is hope.

What the infrastructure layer actually does

The governance wrapper -- the control plane that sits between AI systems and everything they access -- is not complicated conceptually. Every API call, every LLM request, every agent tool invocation goes through it. You may not be the person who builds this. You are almost certainly the person who needs to commission it.

The wrapper does six things that a policy document cannot.

It enforces authentication and authorisation before anything else. OAuth 2.0, OpenID Connect, API keys, mutual TLS -- identity is verified at the gateway before a request reaches the agent. The agent never handles credentials. The gateway decides who is allowed in.

It redacts before data leaves. Before a prompt hits a public model, personally identifiable information is stripped at the infrastructure layer. The agent never had the option to send it.

It enforces rate limits in real time. Not a guideline about reasonable use. An actual limit that fires when exceeded. Useful for controlling costs as well as preventing runaway agent behaviour.

It screens inputs and outputs. Injection attacks, toxicity, off-topic requests -- these are caught before they reach the agent or before the response reaches the user, using classifiers running locally inside the infrastructure. Nothing leaves the building for classification.

It gates access by plan or role. The same agent asking the same question gets a different answer depending on who is asking. A volunteer gets less data. A credentialed clinician gets more. The agent does not reason about this. The gateway decides.

It logs everything with context. Not just that a request happened, but what plan it was on, what was returned, whether it was blocked and why. Auditable by design, not by accident.

Why this matters now, not later

The EU AI Act is coming into force in stages through 2025 and 2026. High-risk AI systems require logging, traceability and human oversight by law, not by preference. The categories directly relevant to mission-first work include systems used in employment decisions, access to public services, emergency response and education. If your organisation uses AI in any of those contexts, the accountability requirement lands at the infrastructure layer, not the policy level.

A document cannot produce an audit trail. A gateway can.

Most charities and public sector bodies are not ready for this. Not because they are careless but because the sector has been told, repeatedly, that governance is a board and policy function. It is. And it is also an engineering function.

This is not as expensive as it sounds

The immediate objection is cost. Infrastructure costs money. Developers cost money. Most charities do not have either in abundance.

Two things are worth saying to that. First, the cost of a data breach, a regulatory finding or a serious AI-assisted error in a high-stakes context is substantially higher than the cost of building this properly. Second, this does not have to be built from scratch. The governance wrapper described here is a configuration challenge as much as a build challenge. The technical primitives exist. The gap is usually in knowing what to configure and why.

Governance in a document is a statement of intent. Governance in the wiring is a statement of fact.

Sam Prodger is Field CTO at Gravitee and spent ten years as Head of Data at the RNLI.