Enterprise AI pilots do not fail because the model underperformed. They fail because the architecture could not answer five questions, and those answers are decided long before anyone opens a security questionnaire.
The pattern is consistent enough to be predictable. A team builds a convincing prototype in six weeks. Leadership is impressed. Then the project meets the security architect, the data governance lead, and the compliance officer — and stops. Eighteen months later there is a working demo, a stack of documentation, and nothing in production.
From the standard
“Zero trust (ZT) is the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources.”
The reflex is to blame the review process. That is the wrong diagnosis. The objections are almost always correct, and the reason they cannot be resolved is that each one is a property of the system's shape rather than a setting inside it.
The five questions
1. Where is our data processed?
A prototype calls a vendor API from a developer laptop. Production means regulated data, a data residency clause in a customer contract, and an architecture where proprietary information crosses your perimeter to be inferenced on infrastructure you do not control.
This is rarely negotiable, and it is not solved by a data processing agreement. If your contracts commit you to keeping certain data in a jurisdiction, no vendor assurance changes where the packets go. The decision belongs at the start: either the execution plane runs inside your own cloud account, or the project is limited to data that may leave.
The reversibility test
Ask which of the five decisions below you could change in week ten without rewriting the system. Deployment topology and identity model usually cannot be changed at all. Those are the ones to settle first.
2. What is the agent permitted to write?
Read-only assistants clear review easily and deliver correspondingly little. The value arrives when the system can file the test, update the opportunity, or publish the dashboard — and that is exactly the capability that turns a routine review into a hard one.
A confirmation dialog is not an answer. Reviewers want to know what changes, how many records it reaches, and what prevents an approval granted against one plan from being executed against a different one. If the pilot has no gate, adding a real one late means rebuilding the execution path, because approval state has to be threaded through every tool call.
3. Whose identity does it act under?
Most prototypes run on a single service account with broad access, because that is the fastest way to get a demo working. The consequence is that every user effectively inherits the union of everyone's permissions, and the system cannot answer who was allowed to see what.
Retrofitting real authorization is not a matter of adding a check. The tools available on a given turn have to be the intersection of what the platform supports, what the tenant is entitled to, and what that specific user's role permits — evaluated per turn, and re-validated when someone opens an old session. A system designed around one service account has no place to put that logic.
4. What can an auditor reconstruct?
Six months after go-live, someone will ask why the system changed a particular record. "The model decided" does not survive that conversation, and neither does a log that captures the prompt and the final answer but nothing in between.
What is needed is the causal chain: which turn triggered which tool call, with what arguments, what came back, who approved the resulting write, and against which version of the plan. That requires distributed tracing threaded through the system from the beginning. It cannot be reconstructed afterward from application logs.
5. How do we know the answer is real?
A model produces a confident number. Nobody can say which query produced it, whether the join was correct, or whether the model invented it. In a regulated forecast or a safety argument, an unverifiable answer is worth less than no answer, because it carries the authority of a system without the accountability of one.
Asking the model to cite its own sources does not solve this. It is asking the component that hallucinates to certify that it did not. Citations have to be generated by the backend from the actual record of tool calls, and markers the model invents on its own have to be stripped before anything renders.
Why late review is structurally too late
Every one of those five is load-bearing. Deployment topology determines what data the system may touch. The identity model determines what authorization can even be expressed. Tracing has to be present at every call site or the chain has gaps. The approval gate has to sit in the execution path, not beside it.
None of them is a feature that can be added in a hardening sprint. That is the whole problem with treating security review as a gate at the end: by the time the review happens, the answers are already fixed by decisions nobody realized they were making.
A cheaper sequence
Put the security architect in the first working session, before there is code to defend. Two weeks of their attention at the start costs less than a quarter of remediation at the end, and the output — a threat model and a deployment diagram your reviewers have already seen — is what makes the eventual review a formality instead of a negotiation.
What a passing architecture looks like
The five answers that clear review are unglamorous and specific. Execution runs inside the customer's own cloud account, with agent-generated code isolated at the hypervisor level and outbound traffic denied by default. Every write halts at a gate showing a blast-radius diff, with the approval pinned to a concurrency token so it cannot be replayed against a modified plan. Authorization is the three-way intersection of platform, tenant, and role, compiled per turn. Every action is traced end to end. Every factual claim resolves to the tool call that produced it.
None of that is exotic. It is simply expensive to add later and nearly free to design in. The pilots that reach production are not the ones with the better model — they are the ones where somebody asked the five questions in week one.
Axionalytics
Production agentic AI for enterprise engineering, data, and revenue teams.