Key Takeaways
- Most generative AI pilots never reach production - MIT's 2025 research found 95% of enterprise generative AI pilots deliver no measurable P&L impact, and S&P Global Market Intelligence found the average organisation scraps 46% of AI proof-of-concepts before they go live.
- A stalled pilot doesn't disappear. It leaves behind live API connections, data pipeline jobs, service accounts and vendor access grants that keep running - invisible to the asset registers and access reviews built for human users.
- Separate research into enterprise identity sprawl shows the scale of the underlying problem: 38% of identity-provider accounts sit dormant and 8% are fully orphaned (no owner in HR or IT systems), with machine identities now outnumbering human users roughly 17 to 1.
- OWASP's first Non-Human Identity Top 10 ranks "improper offboarding" - credentials that never expire when a project ends - as the number one risk category for exactly this kind of exposure.
- sourceCode's position: every AI pilot kickoff document should carry a decommissioning plan with the same weight as its scaling plan - because the pilots that get killed quietly are the ones that cost the most, later.
Introduction
Most conversations about AI pilots focus on one failure mode: the pilot that never scales, and the opportunity cost of the time and budget spent chasing it. That framing is correct, but incomplete. On 25 September this engine examined that cost from the CFO's chair - the price of delay, the compounding cost of indecision on AI investment.
>> Read more: A CFO's Guide to the Real Cost of an AI Pilot That Never Scales
This piece looks at the same event - a stalled or abandoned AI pilot - from the other side of the ledger: engineering's. When a pilot is quietly shelved, nobody schedules a decommissioning sprint. The steering committee moves on to the next priority. The project code goes into an archived repository, if it goes anywhere at all. But the things that made the pilot technically possible - the API integration into the policy administration system, the nightly extract from the claims warehouse, the service account with read access to customer records, the sandbox environment with a live connection to a core banking API - do not get decommissioned by default. They get forgotten. And forgotten infrastructure in a regulated BFSI environment is not a tidiness problem. It is an audit finding waiting to be discovered, usually by someone outside the organisation.
This is not a hypothetical. It is the predictable, measurable byproduct of how enterprises run AI pilots today - and it is largely untracked, because most organisations account for a pilot's cost at its creation and never return to account for its cleanup.
The Scale of the Problem: How Many Pilots Actually Die
The starting assumption behind this piece - that a large share of AI pilots stall before reaching production - needed independent verification before anything else could be built on it. Three separate pieces of research converge on the same conclusion, from different angles.
Gartner predicted in mid-2024 that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, citing poor data quality, unclear business value, inadequate risk controls, and escalating costs - with deployment approaches often running US5milliontoUS20 million (Gartner, 2024).
A year later, MIT's NANDA initiative went further. Its 2025 study, drawing on 150 leadership interviews, a 350-employee survey and analysis of 300 public AI deployments, found that 95% of enterprise generative AI pilots showed no measurable profit-and-loss impact - only around 5% achieved the kind of rapid value capture that justified the investment (Challapally et al., 2025).
Separately, S&P Global Market Intelligence's 2025 survey of over 1,000 organisations in North America and Europe found the average organisation scrapped 46% of AI proof-of-concepts before they reached production, and that the share of companies abandoning most of their AI initiatives entirely had jumped to 42%, up from 17% the year before (S&P Global Market Intelligence, cited in CIO Dive, 2025).
These are three different research houses, three different methodologies, and three different ways of counting - and none of them agree on an exact number, which is itself the honest finding. What they agree on is the order of magnitude: somewhere between a third and the overwhelming majority of AI pilots do not survive contact with production. For an industry running dozens of parallel AI pilots across claims, underwriting, fraud, servicing and compliance, that means a steady, recurring stream of dead pilots - and a steady, recurring stream of the infrastructure they leave behind.
What Actually Gets Left Behind
A pilot is not just a model. To get a proof of concept running against real (or realistically representative) data inside a regulated institution, engineering teams typically stand up:
- Integration code connecting the pilot to core systems - policy administration, claims, CRM, payments rails - usually built fast, under pilot timelines, with fewer code review and documentation standards than production-grade work.
- Data pipelines that extract, transform and stage production or production-adjacent data into a sandbox, data lake zone or vendor environment for model training or testing.
- Service accounts and API keys issued to the pilot team, the vendor, or the model provider, often with broader read/write scope than the pilot strictly needed, because narrowing scope takes time nobody allocated.
- Access grants for the pilot team itself - vendor consultants, data scientists, system integrators - into environments that may hold customer data.
- Documentation that exists, if at all, in the heads of the two or three engineers who built the integration, rather than in a central registry.
When the pilot is formally killed, the model and the dashboard get switched off because someone notices they're not being used. The five items above do not get switched off, because nobody owns the decision to switch them off. This is the structural reason "zombie" infrastructure accumulates: decommissioning requires an owner and a trigger, and a quietly abandoned pilot has neither.
This pattern has a name in security research now. NETSCOUT's 2026 analysis of shadow AI describes exactly this mechanism: forgotten systems - "zombie servers, zombie APIs, or orphaned resources" - that keep running with no clear owner, frequently originating from abandoned AI workloads, and invisible to asset databases and conventional monitoring because nobody flagged them for tracking in the first place (Cote, 2026). The same analysis notes that when projects supporting autonomous agents are abandoned, the agents themselves can keep running and retain live connections to internal tools and data - a risk category it labels "Shadow MCP."
The Evidence on Orphaned Access and Dormant Credentials
The pilot-specific research is thinner than the pilot-failure research - vendors and analysts have been much more active measuring whether AI projects succeed than measuring what they leave behind when they fail. But the adjacent, well-measured field of enterprise identity and access security tells us what happens to credentials and service accounts in general once their original purpose lapses, and the mechanism is directly transferable.
Veza's 2026 State of Identity & Access Report, published December 2025, measured identity sprawl across real enterprise environments and found that machine identities - service accounts, API keys, tokens, automation credentials - now outnumber human users roughly 17 to 1. More pointedly: 38% of identity-provider accounts had shown no activity for 90 days or more while remaining able to authenticate, and 824,000 active identities (around 8% of the total measured) had no owner recorded in HR systems at all - orphaned, but still live, and that orphaned-account figure had grown roughly 40% year over year (Veza, 2025).
This is not an AI-pilot-specific statistic - it is a whole-of-enterprise identity measurement. But it is the clearest available evidence that the underlying failure mode sourceCode is describing - access granted for a defined purpose that outlives that purpose because nobody owns the shutdown - is already a large, growing, measured problem at enterprise scale, with AI pilots as one of its most prolific and least-governed sources. OWASP's first Non-Human Identity Top 10 risk list makes the same point from the standards side, ranking "Improper Offboarding" - credentials and service accounts that never expire when the project or employee they supported is gone - as its number one non-human identity risk (OWASP NHI Top 10, 2025, cited in Aembit, 2025).
Gartner has since quantified where this trajectory leads for AI specifically: by 2030, more than 40% of global organisations are predicted to experience security or compliance incidents caused by unauthorised or ungoverned AI tools and access (Gartner, cited in Infosecurity Magazine, 2025).
Why This Is Technical Debt, Not Just a Security Gap
It's tempting to file orphaned pilot access purely under "cybersecurity hygiene." That undersells the problem. McKinsey Digital's research on technical debt - based on a survey of 50 CIOs at financial services and technology companies with revenue over US$1 billion - found that those CIOs estimated technical debt at 20% to 40% of the value of their entire technology estate, and that for 30% of respondents, more than a fifth of the budget earmarked for new products was being absorbed resolving technical debt instead. One large multinational insurer in McKinsey's sample found technical debt consuming between 15 and 60 cents of every IT dollar it spent (Blumberg et al., 2022).
Orphaned pilot infrastructure is technical debt in the textbook sense McKinsey describes: an off-balance-sheet liability - work the organisation will eventually have to do, interest accruing in the meantime in the form of security exposure, audit remediation cost, and the compounding difficulty of untangling what a long-dead integration actually touches once the two engineers who built it have left the company. The difference between pilot debt and ordinary technical debt is that ordinary technical debt usually comes with a working system still earning its keep. Pilot debt comes with no system in production, no business owner answering for it, and often no one left on the payroll who remembers it exists.
The Pilot Sunset Protocol
Scaling plans get board attention. Decommissioning plans get none - because nobody writes one in the first place. sourceCode's view is that the asymmetry itself is the root cause, and the fix is structural rather than heroic: build the shutdown plan into the pilot's kickoff documentation, with the same formality as its success criteria.
We call this discipline the Pilot Sunset Protocol - five checkpoints, owned from day one, not improvised at the end:
- Integration Inventory. At kickoff, log every system the pilot will touch, every data flow direction, and every credential that will be issued - in the organisation's central asset register, not a project wiki. No integration gets built without an inventory entry.
- Access Time-Boxing. Every service account and API key issued for the pilot carries an explicit expiry date tied to the pilot's review milestone, not an indefinite grant. Renewal requires an active decision, not inaction.
- Data Retention Decision. Before the pilot starts moving production or production-adjacent data, the team documents what happens to that data, and to any derived or trained artefacts, if the pilot is discontinued - deletion, archival, or formal retention under a named owner.
- Documentation Handback. If the pilot clears its go/no-go review and scales, the integration documentation transfers to a production engineering owner under standard change management. If it doesn't clear that review, the documentation package is what the decommissioning team executes against - not a scramble to reconstruct what was built from memory.
- Decommission Sign-off. A named individual - not a committee, not "the vendor" - signs off that every credential, pipeline and access grant tied to the pilot has been revoked, deleted or formally transferred, with that sign-off itself logged as an auditable record.
None of these steps materially slow down a pilot that is genuinely worth running. What they prevent is the far more expensive failure mode: a pilot that dies the way most pilots die - quietly, by attrition, under cost or priority pressure - without anyone formally deciding to turn off what it built.
Counterargument: Isn't This Over-Engineering a Throwaway Experiment?
The strongest objection to this framework is a reasonable one: pilots are supposed to be fast and disposable, and imposing formal decommissioning governance on every experiment risks recreating the slow, change-managed delivery process that pilots exist to escape. If every three-week proof of concept needs a sign-off matrix, engineering teams will route around it - or worse, stop running pilots at all, which has its own opportunity cost.
This objection has real force, and the honest answer is that the Pilot Sunset Protocol should be proportionate, not uniform. A pilot running entirely on synthetic data in an isolated sandbox with no production connectivity genuinely carries low decommissioning risk, and a lightweight version of the checklist - essentially just the Integration Inventory and a hard expiry on any credentials issued - is proportionate. The governance should scale with what the pilot actually touches: real customer data, core system write access, or third-party vendor credentials each raise the stakes and justify the fuller protocol. The failure mode worth avoiding is not "too much governance" in the abstract - it's zero governance applied uniformly to pilots that quietly accumulate production-grade access while still being managed with proof-of-concept informality. The data on orphaned and dormant accounts suggests that failure mode, not over-governance, is the one actually occurring at scale today.
What This Means for the Buying Committee
For the CTO and engineering leadership, the implication is direct: pilot technical debt should appear as a tracked line item, separate from the pilot's original budget, with its own remediation backlog - not absorbed silently into "general security hygiene" where it has no visibility and no owner.
For the CFO and risk committee, the implication is that the true cost of a stalled AI pilot includes a tail of ongoing security and audit exposure that the original business case never priced in - the pilot's budget line closes, but the liability it created does not.
For the Chief Risk Officer and compliance function, orphaned service accounts and stale data-access grants from dead pilots are precisely the kind of finding that surfaces, often badly, in a regulatory technology risk review or a third-party penetration test - better to surface and close them on your own schedule than theirs.
The sourceCode’s Perspective
Across two decades delivering inside BFSI engineering teams - through insourcing and offshore delivery centre models spanning Australia, Malaysia and Vietnam - the pattern behind this piece is one we see on the ground constantly: it is rarely the pilots that succeed that create the mess. It's the ones that quietly stop mattering. A pilot that scales gets a production owner, a budget line and a support model almost by definition - success forces the governance conversation. A pilot that limps along for two quarters and then simply stops being discussed in steering meetings gets none of that, and its access, data pipelines and integration code sit exactly where they were left.
We don't have a published client case study to cite here, and we won't invent one - but the shape of the problem is consistent enough across the institutions we've worked inside that it doesn't need one to be credible: engineering teams can usually name their current AI pilots without hesitation, and struggle far more to name the ones that were quietly shelved eighteen months ago, let alone confirm what access those pilots still hold.
That gap between "what we're running" and "what we once connected" is where the risk actually sits, and closing it is an inventory and governance discipline, not a new piece of technology. If there is one adjustment we'd make to how most engineering organisations run pilots, it's this: write the shutdown plan on day one, while someone still remembers what was built, rather than trying to reconstruct it from scratch once the project team has moved on and the person who holds the context has left.
Conclusion
The evidence is consistent across independent sources, even where the exact figures differ: a large share of AI pilots - somewhere between a third and the clear majority, depending on how you count - will not reach production. That is a known, researched, and arguably unavoidable feature of experimenting with a fast-moving technology, not a scandal in itself. The scandal, if there is one, is in what happens next by default: nothing. Integration code sits live. Data pipelines keep running. Service accounts keep their credentials. And the organisation discovers the cost not when the pilot ends, but months or years later, when an audit, a penetration test, or a breach notification forces the discovery that should have happened at decommissioning.
A pilot kickoff document that specifies success criteria but not shutdown criteria is only half a plan. The other half - the Pilot Sunset Protocol - costs very little to write at the start and a great deal to reconstruct at the end.
If your engineering organisation is running more AI pilots than it can currently account for, that is worth finding out precisely, and on your own terms. sourceCode works with CTOs and engineering leaders across BFSI to run a structured audit of current AI pilot inventory against exactly this checklist - integrations, access grants, data pipelines and documentation - and to size the cleanup before someone else does it for you. If that's a conversation worth having, we're glad to start with a specific challenge on your current pilot inventory rather than a generic pitch. Talk to us here!
FAQ
What percentage of AI pilots actually fail or get abandoned? Estimates vary by methodology and definition. Gartner predicted at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025 (Gartner, 2024). MIT's 2025 NANDA research found 95% of generative AI pilots showed no measurable profit-and-loss impact (Challapally et al., 2025). S&P Global Market Intelligence found organisations scrapped an average of 46% of AI proof-of-concepts before production in 2025 (S&P Global Market Intelligence, cited in CIO Dive, 2025). The exact number depends on what's being measured - but all three independent sources agree a substantial share of pilots do not reach production.
What exactly is "pilot technical debt"? It's the integration code, data pipelines, API connections, service accounts and access grants built to run an AI pilot that remain active after the pilot is paused or abandoned, because no one owns the decision or process to decommission them. It accrues as both a maintenance burden and a security/audit liability.
Isn't this just a cybersecurity issue, not a technical debt issue? It's both. The access and credential exposure is a security issue in the near term. But the broader pattern - unresolved work the organisation will eventually have to do, accumulating cost over time - is technical debt in the sense McKinsey's research describes: an off-balance-sheet liability on the technology estate (Blumberg et al., 2022).
Who should own decommissioning a stalled AI pilot? A single named individual, agreed at the pilot's kickoff - not a committee and not the vendor by default. The Pilot Sunset Protocol outlined in this piece assigns that ownership explicitly as part of the pilot's initial documentation, rather than leaving it to be assigned retroactively once the pilot has already stalled.
How do we find out what pilot-related access and integrations we already have sitting dormant? Start with an integration and credential inventory cross-referenced against your current active-pilot list - anything with system access that isn't tied to a currently active, named pilot or production system is a candidate for review. This is the starting point of the audit sourceCode runs with engineering teams against their current AI pilot inventory.
Reference List
Aembit (2025) OWASP's Top Security Risks for Non-Human Identities and How to Address Them. Available at: https://aembit.io/blog/owasps-top-security-risks-for-non-human-identities-and-how-to-address-them/ (Accessed: 16 October 2026).
Blumberg, S., Das, R., Lansing, J., Motsch, N., Münstermann, B. and Patenge, R. (2022) Demystifying digital dark matter: A new standard to tame technical debt. McKinsey Digital, 23 June. Available at: https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/demystifying-digital-dark-matter-a-new-standard-to-tame-technical-debt (Accessed: 16 October 2026).
Challapally, A. et al. (2025) The GenAI Divide: State of AI in Business 2025. MIT NANDA / Project NANDA, August. Reported in: Fortune, 18 August 2025. Available at: https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo (Accessed: 16 October 2026).
CIO Dive (2025) 'AI project failure data from S&P Global', CIO Dive, 14 March. Available at: https://www.ciodive.com/news/ai-project-fail-data-spglobal/742590/ (Accessed: 16 October 2026).
Cote, A. (2026) How Shadow AI Creates Zombie Infrastructure. NETSCOUT, 2 April. Available at: https://netscout.com/blog/how-shadow-ai-creates-zombie-infrastructure (Accessed: 16 October 2026).
Gartner (2024) Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept By End of 2025. Press release, 29 July. Available at: https://www.gartner.com/en/newsroom/press-releases/2024-07-29-gartner-predicts-30-percent-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025 (Accessed: 16 October 2026).
Infosecurity Magazine (2025) 'Gartner: 40% of Firms to Be Hit By Shadow AI Security Incidents', Infosecurity Magazine, 20 November. Available at: https://www.infosecurity-magazine.com/news/gartner-40-firms-hit-shadow-ai (Accessed: 16 October 2026).
OWASP (2025) Non-Human Identity (NHI) Top 10. Open Worldwide Application Security Project. As cited in Aembit (2025).
Veza (2025) 2026 State of Identity & Access Report. Press release, 11 December. Available at: https://veza.com/company/press-room/veza-identity-access-research-report-reveals-identity-permissions-sprawl-has-reached-critical-levels-amid-explosion-of-machine-and-ai-agent-identities-across-the-enterprise/ (Accessed: 16 October 2026).