The pilot works. Everyone in the room agrees on that. The demo lands, the use case is obvious, and the team that built it is ready to ship. Then it sits there for another two quarters, because someone, usually legal or security, asks a question nobody prepared an answer for: what happens the first time this is wrong, and can you prove what it did afterward. That question is not a technicality. It's the actual gate between a pilot and a production system, and most teams hit it with nothing ready to show.
Most pilots don't die from a bad model. They die from an unanswerable question.
MIT's Project NANDA studied 300 AI deployments, interviewed 150 executives, and surveyed over 350 employees across enterprise generative AI programs. Its finding, published in July 2025: 95% of organisations saw no measurable profit-and-loss return from their generative AI pilots, against $30-40 billion in enterprise genAI spend.[1] The report's own framing is specific - the failure sits in organisational workflow and integration, not model quality. S&P Global Market Intelligence's enterprise survey found the same pattern getting worse: 42% of companies abandoned most of their AI initiatives in 2025, up from 17% the year before, citing cost, data privacy, and security risk as the leading reasons, not capability.[2] If the model were the problem, better models would have closed this gap by now. They haven't, because the model was never what was missing.
The checklist nobody hands you at kickoff
Every pilot eventually meets four questions it was never built to answer: who approved this action before it happened, can you prove what the system actually did, what was it allowed to touch, and what happens when it's wrong. Answer all four before someone asks, and production is a configuration change. Answer none of them, and production is a six-month retrofit done under pressure.
Question one: who approved this, before it happened
A pilot usually runs with a human watching every output, which quietly answers this question without anyone noticing it was being asked. Production removes that human, and the question comes back due immediately. An agent that can send an email, modify a record, or call an API needs an authority ceiling set before it ever runs, not a review after the fact - and anything above that ceiling needs to stop and wait for a person to approve it, every time, not just the first time.
Question two: can you prove what it did
"We have logs" is not the same answer as "we can prove this." Logs that can be edited, logs with gaps, logs that were never designed to be shown to an auditor, all fail the moment someone actually needs them. What production requires is a record committed at the moment the decision was made, tamper-evident, and complete enough to reconstruct exactly what happened and why it was allowed - not a best-effort reconstruction stitched together after someone asks for it.
Question three: what was it allowed to touch
Pilots are usually scoped narrowly enough that this question never gets stress-tested. Production exposes it immediately: what happens the day a user pastes a document with a customer's data into the exact same workflow that worked fine in the demo. If the answer depends on every user remembering not to do that, the answer is no. Sensitive content needs to be identified and handled before it ever reaches a model, as a property of the system, not a policy someone is trusted to follow.
Question four: what happens when it's wrong
Every pilot is right often enough to look ready. Production is the environment where the exceptions start to matter, because now a customer, a regulator, or a dollar amount is attached to the output. The honest version of this question isn't "will it ever be wrong" - it will be. It's whether there's a containment boundary in place before that happens: a ceiling on what a wrong decision can actually do, and a record of it the moment it happens, instead of a postmortem three months later.
“Nobody fails a production review because their model was bad. They fail it because they can't answer what happened, who let it happen, and what it was allowed to touch. Those are governance questions, and they have governance answers - you just have to build them in before the question gets asked, not after.”
- OBEL GTM Team
Answer the checklist before you write the proposal
This is the actual difference between an AI program that moves from pilot to production in weeks and one that stalls for two quarters arguing with its own security team: the governance layer exists before the review, not in response to it. Scrubbing and classification before a prompt reaches a model, an authority ceiling and human approval on every consequential agent action, and a tamper-evident audit record from the first interaction, not the first incident, turn all four questions above into things you can point at instead of things you have to promise.
If your pilot already works and the only thing standing between it and a green light is the ability to answer these four questions with evidence instead of assurances, that's a solvable gap, and it's the one OBEL is built to close.
Where to look
OBEL's governance architecture, including scrubbing, sovereign classification, agent authority levels, and the audit ledger referenced here, is detailed at useobel.ai/security and useobel.ai/argus-i.
This piece was prepared by the OBEL go-to-market team at ninthLABS Ventures, drawing on MIT Project NANDA's 2025 State of AI in Business report and S&P Global Market Intelligence's enterprise AI survey data.
References
More in Perspective