AI governance that doesn't slow the build

Ask anyone who has tried to bring AI into a regulated or risk-averse part of a business what actually stalled the project, and the answer is rarely the model. The model worked. What stopped things was the security review, with its reasonable and entirely fair questions: where does the data go, who can see the answers, and can you show us what the system did last month? Those questions deserve serious answers, and the encouraging part is that the answers turn out to be mostly a matter of engineering rather than paperwork. They are things you build into the system, not documents you write about it.

Four practices cover the great majority of the reviews we have been through.

The first is least privilege, enforced in the plumbing rather than the prompt. The system should answer using exactly what the person asking is allowed to see, with those permissions inherited from the source systems themselves. The distinction matters because a prompt is a request, not a control: whatever the instructions say, the real guarantee is that the retrieval layer physically cannot reach records the user could not open themselves.

The second is an audit trail by default. Every question, every answer, and every source that fed into it, recorded. This is not bureaucracy for its own sake; it changes the character of every future conversation about the system. When somebody asks what the AI told a customer in March, and why, the answer is a lookup rather than an investigation, and that difference is felt immediately by whoever has to sign the system off.

The third is human checkpoints wherever the system acts rather than informs. Drafts rather than sends. Suggestions rather than commits. This is not timidity, it is sequencing. Autonomy in a narrow, well-understood workflow can be earned with evidence over time, and starting with human review in the loop is how that evidence gets produced.

The fourth is a plain-English data map: one page saying what flows where, which providers touch it, and what is retained for how long. Its job is to let a non-specialist understand the shape of the system in a few minutes. If reconstructing that picture takes a lawyer a week, the conversation is usually lost before it begins, not because anyone did anything wrong, but because the system cannot be seen clearly enough to be trusted.

There is a reasonable objection to all of this, which is that it sounds like overhead. My experience is the opposite, for a simple reason: businesses already do all of these things for people. Joiners and leavers, access reviews, records of decisions and who made them. Doing the same for software is a familiar instinct rather than a new burden. And doing it early changes what governance is for. Rather than a brake applied by the security team after the build, it becomes part of the reason the build is allowed to happen at all, because the systems that pass review are the ones that get used.

We map the data flows and controls in a short workshop, which is a fast, actionable way to start. If you'd like help getting a system through your own security review, get in touch.

Author: Michael Wells