Dear Reader,
Industry estimates consistently put AI project failure rates above 80% — roughly twice the failure rate of non-AI IT projects. In August 2024, RAND Corporation investigated why through structured interviews with 65 data scientists and engineers, identifying five root causes: miscommunication about project intent, inadequate data, insufficient infrastructure to deploy completed models, lack of integration planning, and missing governance. In March 2026, the Stanford Enterprise AI Playbook examined 51 successful deployments across 41 organisations and nine industries, and concluded that absolute majority of failures trace to organisational factors — workforce unpreparedness, missing governance, lack of executive ownership — not to model quality.
Both investigations point to the same place: the AI works, the organisation around it does not.
This issue is about one specific version of that failure: what happens when AI built for clean, API-first environments meets enterprise infrastructure that predates APIs. The brownfield trap.
The greenfield illusion#
Every AI vendor demo runs on clean data, modern APIs, and a fresh database. The pilot works because the pilot environment was built for it. Then the project moves to production, and the team discovers what the enterprise actually looks like.
The average large enterprise runs hundreds of discrete applications, with roughly two-thirds unintegrated. Deloitte has estimated that 57% of the average enterprise IT budget goes to supporting existing operations. Sixteen percent goes to innovation.
Core banking platforms in many large banks are 20 to 30 years old. 240 billion lines of COBOL still run in production globally, processing 95% of ATM transactions and 80% of in-person transactions. Manufacturing execution systems, insurance policy administration platforms, and ERP cores are overwhelmingly on-premise and pre-API. This is the infrastructure into which AI products are being sold.
The vendor assumes an API. The enterprise has a batch file transferred overnight via SFTP. The gap between those two realities is where AI projects go to die.
The integration tax#
When organisations budget for AI, they budget for the AI. The model, the inference costs, the platform licence. In practice, that covers 20 to 30 percent of the total cost. The remaining 70 to 80 percent is hidden: data preparation, integration engineering, custom development to connect the model to existing systems, testing against real production data, change management, training, and ongoing maintenance.
Data preparation alone consumes up to 45% of total AI project effort. Deloitte found that 70% of organisations faced budget overruns in AI projects due to unforeseen complexities.
The pattern is consistent: the model is the cheapest part of the project. Integration with legacy systems is the most expensive part, and it is the part that was not in the original business case. This is the integration tax — and it explains why pilots that cost €50,000 turn into production deployments that cost €500,000 without delivering expected value.
The expertise gap#
Sixty percent of AI leaders surveyed by Deloitte in 2026 identified integrating with legacy systems as their primary challenge in adopting AI. Seventy percent of organisations in a Kyndryl survey reported struggling to find the skills required for mainframe modernisation. These are not the same skill shortage. They are two shortages meeting in the middle — with nothing in the middle.
On one side: ML engineers who know Python, transformers, cloud-native APIs, and modern data stacks. On the other: enterprise architects and mainframe engineers who know COBOL, SAP ABAP, batch processing, and the undocumented logic that keeps thirty-year-old systems running.
The average COBOL programmer is 58 years old, according to IBM. Roughly 10% retire each year. An estimated 84,000 mainframe positions are unfilled. Only around 24,000 COBOL programmers remain in the United States. The people who understand the legacy estate are leaving the workforce.
The role that most AI projects need — someone who understands both sides well enough to design the integration — barely exists as a defined job. Some organisations have tried to solve this with “translators”: people embedded between analytics teams and business operations to ensure models reflect operational needs. Aviva, the UK insurer, used this model explicitly. In most organisations, the ML team builds the model, the enterprise architecture team builds the integration, and the two conversations happen separately. That is the gap where projects fail.
How brownfield succeeds#
Aviva deployed over 80 AI and ML models across claims operations on top of existing legacy policy and claims systems. They did not replace the core — they used APIs and microservices as an adapter layer, allowing AI models to query existing policy systems, historical claims data, third-party services, and fraud databases simultaneously. The result: liability assessment time cut by 23 days, claim routing accuracy improved by 30%, complaints reduced by 65%, and £60 million saved in 2024 alone. McKinsey documented the case as part of their “Rewired in Action” series.
Commonwealth Bank of Australia runs 55 million AI-driven decisions daily across over 2,000 models and 157 billion data points. They migrated 61,000 data pipelines to AWS and moved their SAP core banking system, an 18-month project. But the insight is what they did during the migration, not after it: they deployed AI on the legacy estate while simultaneously modernising it. They did not wait for the modernisation to finish. Their internal AI programme, Project Coral, reduced application assessment time from six weeks to under one hour and modernisation cycles from sixteen weeks to one week. Scam losses dropped 50%. Customer complaints dropped 30%.
The pattern across both cases and across the client engagements I have observed: brownfield AI works when the organisation treats integration as the primary engineering challenge, not as a secondary step after the model is built. The approach that survives contact with production is modular and incremental: wrap legacy systems in API facades, run AI as an overlay that reads from legacy but writes to a modern data layer, deploy use cases one at a time rather than attempting a portfolio.
The architectural patterns#
Three patterns are emerging for brownfield AI integration.
The Strangler Fig. Named after the tropical tree that grows around an existing tree until it replaces it. In software, this means routing requests through a facade that gradually shifts traffic from legacy services to modern replacements. Combined with event streaming and change data capture, organisations can sync legacy databases with modern data stores in real time. Incremental migration fails substantially less often than “Big Bang” rewrites. Generative AI tools are now being used to analyse legacy code logic and accelerate creation of replacement microservices — the strangler approach is getting faster.
The Anti-Corruption Layer. A translation layer between new AI services and legacy systems that isolates the AI domain model from legacy technical debt. The AI system sees a clean interface, not the complexity of the old system. The legacy system sees standard requests, not the AI domain model.
The Overlay. Deploy AI as a layer that reads from legacy systems (via change data capture or batch extraction) but writes to a modern data layer. Legacy remains the system of record. AI operates on a parallel plane. This is effectively what modular deployment looks like: incremental, non-destructive, reversible.
All three share a principle: do not replace the legacy system. Build around it.
AI as the brownfield tool#
The brownfield problem contains a specific irony. AI is simultaneously the technology that is hardest to integrate with legacy infrastructure and the most capable tool available for understanding and managing that infrastructure.
The most immediate application is legacy code comprehension. Large language models can read and explain undocumented COBOL, ABAP, or PL/SQL — not perfectly, but enough to make integration planning possible in codebases that have not been documented in decades. When the last engineer who understood the batch logic retired, the code became a black box. AI can open it.
Beyond comprehension, there is a more structural capability: persistent knowledge capture. One of the defining problems of brownfield estates is that institutional knowledge about legacy systems lives in people’s heads, not in documentation. AI can build and maintain a persistent knowledge layer alongside the codebase, mapping dependencies, capturing decisions, documenting integration points as they are discovered. When someone leaves, the knowledge stays. Each project that touches the legacy estate adds to this layer rather than starting from zero. The knowledge compounds.
CBA’s Project Coral demonstrates this at scale, cutting modernisation cycles from sixteen weeks to one week through agentic code assessment and replacement generation. The incremental approach is the mechanism: each migration improves the system’s understanding of the estate, making subsequent work faster.
A further benefit that most organisations overlook: when AI assists in code modernisation, it can generate compliance-ready documentation as the work happens: audit trails, change logs, dependency maps. Evidence as a byproduct, not as an afterthought.
The speed gain from AI-assisted brownfield work does not come from faster code generation. It comes from less rework, fewer misunderstandings, and knowledge that accumulates across projects instead of being lost between them. This only works if the organisation treats it as a deliberate workstream with its own tooling and governance — not as an experiment someone runs on the side.
What to ask your vendor#
The governance angle matters here. Most AI governance frameworks were designed for greenfield — clean systems with documented data flows, clear ownership, and API-based architecture. Apply them to brownfield and you get governance theatre: ticking compliance boxes on systems that nobody fully understands.
Before signing with an AI vendor, four questions expose the integration risk:
What does your product assume about the data infrastructure it connects to? If the answer mentions APIs, modern data lakes, or cloud-native architecture, and your core systems are none of these, you have a gap that will become the most expensive part of the project.
What integration work is required, and who does it? If the vendor’s answer is “your team” and your team does not include people who understand both the legacy estate and the AI stack, the project will stall at integration.
Has this product been deployed on infrastructure older than ten years? If the reference customers all run modern cloud stacks, the product has not been tested in your environment.
What is the total cost of the project, including integration — not the licence cost? If the vendor cannot answer this, they have not done a brownfield deployment.
Briefing#
CIOs caught between AI layers and legacy platforms
InformationWeek reported on 23 April that enterprises are deploying AI-native workflow agents above legacy systems rather than replacing them. The pattern: AI startups deliver automation “one workflow at a time,” connecting to CRM, ERP, and compliance systems through APIs the legacy platforms were never designed to provide. Most enterprises “haven’t stress tested what happens when an AI dependency disappears.” For Polish banks and insurers under KNF oversight, this pattern creates a demonstrability gap under EU AI Act Article 26 that the market is not yet naming: deploying an AI layer above a core banking system you do not fully control, on infrastructure without documented data flows, does not satisfy the article’s requirements for monitoring in accordance with instructions for use (InformationWeek, 23 April 2026).
AI-assisted legacy migration becomes a commercial product
Syntax launched AI CodeGenie Suite on 24 April, targeting companies running SAP Apparel and Footwear Solution before its 2027 end-of-support deadline. The tool reads legacy SAP code, extracts business logic, and generates S/4HANA replacements with documentation and test scripts. The first documented deployment: Peerless Clothing migrated a complex available-to-promise function in days rather than months, saving an estimated $250,000. The question the launch does not answer: when AI generates the migration code, who owns the audit trail? SAP AFS is not widely deployed in Polish industry, but the question travels to every legacy ERP modernisation now in progress (TechEdge AI, 24 April 2026).
Questions for your leadership team#
What percentage of your core operational systems — the ones that process transactions, manage policies, or serve customers — were built before 2015? For each of those systems, who in the organisation understands both the legacy architecture and what an AI integration would require?
When your AI team presents a business case, does the cost include integration with existing systems (data preparation, API development, testing against production data, change management) or only the model and platform licence?
If you asked your AI vendor today “has this product been deployed on infrastructure older than ten years?”, what would the answer be? And what would that answer mean for your deployment timeline and budget?
Do you have anyone in the organisation — a person, not a team, not a committee — whose job is to sit between the AI engineers and the enterprise architects? For KNF-supervised institutions and other regulated entities, this person’s absence is not just an operational gap; it is a governance gap that will surface in any AI Act Article 26 review.
The trap#
The brownfield trap is not a technology problem. The models work. The cloud platforms work. The vendor products work — in the environments they were designed for. The trap is the assumption that enterprise infrastructure looks like the demo environment. It does not. It looks like 900 applications, two-thirds unintegrated, maintained by a workforce that is retiring, governed by frameworks designed for systems that no longer exist.
The organisations that escape the trap — Aviva, Commonwealth Bank, the handful of others documented in the Stanford research — share one trait: they treated integration as the project, not as a step in the project.
Stay balanced,
Krzysztof Goworek