Why AI pilots stall at the security review

An AI pilot that fails on model quality fails in week three, cheaply, and everyone learns something. That is not the common failure.

The common failure is a pilot that works. The demo lands, the sponsor is pleased, a business case gets written, and then the thing enters the security review and does not come out. Six months later it is described as "on hold pending architecture", which is the organizational phrasing for dead.

The reason is structural rather than political. A pilot is optimized to prove that something is possible. A security review asks a different question: what happens when this is wrong, or abused, or when the person who built it has left. Almost nothing that makes a pilot fast is admissible as an answer.

The four shortcuts every pilot takes

Each of these is entirely reasonable in a pilot and fatal at review, and the pattern is consistent enough to predict.

• Broad access. The pilot was given a credential that can read more than it needs, because scoping it precisely would have taken a fortnight and the point was to find out whether the idea worked. At review this is the first finding, and it is usually the one that requires the most rework, because the design has quietly come to depend on the breadth.
• Undefined data classification. Nobody wrote down what class of data the pilot handles, so nobody can say whether the destination it was sent to is approved for it. The reviewer cannot approve what has not been characterized, and characterizing it after the fact often reveals that the answer is no.
• No boundary between analysis and action. The pilot's most impressive moment is usually the one where the system does something rather than suggests something. That is precisely the capability that will not survive contact with a control function unless the gate was designed in.
• Debug-grade observability. Full prompts and outputs captured to whatever was easiest, in a system chosen for developer convenience, retained indefinitely. That is a privacy finding, and it is one that cannot be closed by a config change because the data has already been retained.

None of this is a criticism of pilots. It is an argument about sequence. The cheapest moment to answer these questions is before the pilot, when the answers cost a conversation, not after it, when they cost a rebuild and a sponsor's credibility.

The eight questions

These are the ones we have seen decide a review, roughly in the order a reviewer reaches them. Answer them in writing before the pilot and the review becomes a formality. Answer them afterwards and each one is a rebuild.

1. What class of data does this handle?

Public, internal, personal, sensitive, or contractually restricted to named infrastructure or a named jurisdiction. Everything downstream depends on this answer, and it is the answer least likely to have been written down. If your organization has no classification scheme, classify conservatively and say what you assumed, rather than leaving it implicit.

2. Where does that data go, and is that destination approved for that class?

Name the destination. "The API" is not a destination. And note that this is where the two independent axes get conflated: whether a model's weights are open says nothing about where the data goes, and a hosted endpoint is not private because the model is open-weight. Hosted, private endpoint, or self-hosted is the long version.

3. What is the minimum access this needs, and does it have exactly that?

Per-domain roles, per-purpose credentials, and no shared identity across boundaries. Expect the reviewer to ask what this credential could reach if the process were compromised, and to be unimpressed by an answer that begins "in practice it only".

4. Which actions can execute without a human, and which cannot?

Draw the line explicitly and put it in the design rather than in the prompt. A prompt instruction not to do something is not a control; it is a request. The gate belongs on execution, so the system stays free to assemble and draft, and a person approves the commit.

5. What is recorded, and could you reconstruct a decision a year from now?

Actor, action, inputs, decision, timestamp, provider and model, and the configuration version in force at the time. This is the question that separates a system that can be defended from one that can only be explained. What a defensible audit trail looks like.

6. What is retained, for how long, and who decided?

Prompts and completions are user data. Treat retention as a decision with a stated period and a stated reason, not as whatever the default was. "We kept everything in case it was useful" is the answer that generates the finding.

7. What happens when the provider is unavailable, changes, or withdraws?

Reviewers increasingly ask this, and the wrong answer is that the system automatically uses a different provider. Silent substitution means data with one approved destination went to another, which converts an availability event into an incident. Resolution is not policy.

8. Who operates this after handover, and with what documentation?

A system that only its builder can run is a finding in its own right, and it is the one that most often turns an approval into a conditional approval that never gets closed. Runbooks and training are deliverables with acceptance tests, not a phase to compress when the timeline slips.

The reframe that unblocks it

Most stalled pilots are stalled because the security review is treated as a gate at the end rather than an input at the beginning. The teams that get to production are not the ones with better models. They are the ones who ran the compliance review before building anything, and then built the thing the review would approve.

That sequence has a cost, and it is worth naming honestly: it makes the first six weeks feel slower, and it produces documents rather than demos. It also means the demo that eventually gets built is the one that ships, which is a considerably better trade than it appears when the sponsor is asking why there is nothing to show yet.

The other reframe worth making: sometimes the right answer at question one is that the work should not be done. A pilot that reveals the data cannot lawfully go where the design needs it to go has produced a genuinely valuable result for the price of a conversation. That is a good outcome badly framed, and framing it correctly at the start is most of what keeps a programme credible.

How we sequence it

Briefing, then a compliance review before anything is built, then a pilot with a success rubric agreed in advance, then rollout and handover. The compliance review is stage two rather than stage four specifically because of everything above. We would rather tell a client in week one that the answer involves less AI than they expected than bill them for six months of finding that out.

The engagement model in detail, and the regulated-institution version of the same argument on AI integration for financial services.

Nothing on this page is legal, regulatory, or compliance advice. What a review at your institution will require is a question for the people who run it.