The AI Project That Was Late, Over Budget, and Still Got Blocked
None of the companies in this story exist. All of them will feel familiar. It is a composite, stitched together from conversations with teams building AI inside large organizations: insurers, banks, retailers, and one logistics company that would rather not be named. The same three problems keep showing up, in the same order. They deserve a closer look than they usually get.
- 1
Register at intake
Use case enters the registry; overlap gets flagged
- 2
Fit for Purpose
Risk class and requirements known before build
- 3
Build with guardrails
Approved models and tools; policy checks run as code
- 4
Fit for Use
Evidence reviewed once, not re-litigated
- 5
Monitored in production
Drift triggers re-review automatically
First, the story
An insurer decides to build a claims-triage agent. The business case is tight: fewer handoffs, faster settlement, a pilot in one region by summer. Kickoff is in January. By June, three things have happened, and none of them were in the plan. A second team in another business unit has started building nearly the same agent, against the same claims data, with a different vendor. The security team has frozen the pilot after finding that the agent calls a document-retrieval tool nobody on the review board had heard of. And compliance has asked a simple question: which model version is actually running, and what exactly was it approved for? Answering it takes eleven days and four meetings. The pilot finally ships in November, in one region, at roughly triple the original estimate. The steering deck still calls it a quick win.
Where the money actually went
Not the model bill. API invoices are visible, so they get all the attention, but here they were a rounding error. The real money went to three places. Two teams built the same thing for five months, and the duplication only came to light when an architecture review stumbled over it. Access controls and logging were retrofitted after review findings, at several times what building them in would have cost. And the freeze itself burned budget, because the vendor contract kept billing through eight idle weeks. None of this shows up in a budget line called governance. All of it is governance cost. The fix is unglamorous: catch duplication at intake, when it costs almost nothing. That is what AIXYRA's Semantic Duplicate Detection is for. When a team registers a new use case, the platform compares it against everything already in the registry and flags the overlap before anyone starts building. Shadow AI Discovery covers the other blind spot. It scans your AWS environment for AI models and services running outside governance, which is how that second team's stack would have surfaced in weeks instead of months. Neither feature makes the call for you. Someone still has to tell one team to stand down. But that conversation happens in week two instead of month five, and the difference is most of the money.
Why the dates kept slipping
The delay was not engineering. The agent worked in March. What consumed the calendar was governance arriving late and as a surprise. Requirements discovered at review time mean rework, and rework means another review. Then the committees ran in sequence: security, then risk, then compliance, each with its own template asking overlapping questions. None of this is unusual. 38% of organizations cite regulatory compliance as the top barrier to AI deployment (Deloitte, 2025). The structural fix is to put the requirements at the front, and this is exactly what AIXYRA's two-phase governance does. Fit for Purpose happens before anything is built: what risk class is this, which frameworks apply, what will approval require. Fit for Use happens before deployment and checks the evidence against those same requirements. Because the checkgates are configurable, a team can see on day one what reviewers will ask in month four. The compliance work collapses too. One assessment in AIXYRA maps to the EU AI Act, NIST AI RMF, and ISO/IEC 42001 at the same time, replacing three questionnaires run in parallel. And rules written as policy-as-code, using OPA and Rego, are checked automatically on every change rather than re-argued in every meeting. The delay does not disappear. It moves to the start of the project, where it is measured in days and costs almost nothing.
The security team was right
It is worth saying plainly: freezing that pilot was the correct call. An unvetted retrieval tool holding credentials to a claims database is not a hypothetical risk. 86% of organizations reported at least one AI-related security incident in the past year (Cisco, 2025), and the average organization now logs 223 generative-AI data policy violations per month (Netskope, 2026). Agent tool access is where this bites hardest, because an agent's risk is mostly the risk of what it can touch. A registry changes the economics of review. In AIXYRA, the tools an agent may call are registered and approved in the MCP Server Registry before any agent gets access to them, so security reviews each tool once, not once per incident. Risk Scoring with Dependency Propagation handles the bookkeeping that no spreadsheet keeps up with: when a service deep in the stack turns out to be vulnerable, the elevated risk automatically appears on every agent and use case that depends on it. Continuous Governance and Health Monitoring then watches production behavior and triggers a re-review when drift crosses thresholds you define, instead of relying on someone remembering to ask. The security team says no less often. Not because standards dropped, but because surprises did.
What a system of record won't fix
Honesty requires the caveat. A platform will not settle a funding fight between business units, staff an understaffed review board, or make two teams talk when their incentives say otherwise. If your governance committee takes six weeks to convene, a registry will not convene it faster. What it removes is the archaeology: who owns this, which version is running, what tools can it call, what was approved and when, what has changed since. In the story above, most of the money and most of the delay was archaeology. That part has a straightforward fix, and next to the bill it quietly runs up, a cheap one.
Key takeaways
- Duplicate builds, late-review rework, and freeze-time burn are all governance costs. They just never appear under that budget line.
- Put requirements at the front: Fit for Purpose before build, Fit for Use before deploy, and surprise gates become a day-one checklist.
- Agent tool access is the sharpest new surface. Vet tools once in a registry, not once per incident.
- A platform won't fix incentives or staffing. It removes the archaeology that quietly eats budgets and quarters.