Where the AI Value Actually Lives
Most enterprise AI investments target use cases that depend on data and workflows already running in legacy systems. The data in the ERP from 2008. The workflow in the claims platform that was last meaningfully updated in 2015. The customer information in the CRM that has been integrated and re-integrated through three reorganizations.
Productive AI work in 2026 is usually one integration away from a legacy system that nobody wants to touch. The teams that can navigate that integration ship. The teams that cannot are bottlenecked by infrastructure that predates the AI category.
Forrester's 2024 enterprise integration research found that AI integration projects spend 60-70 percent of their effort on integration with legacy systems rather than on the AI work itself (Forrester, "Enterprise Integration Trends 2024"). The ratio is uncomfortable and accurate. Knowing the integration modes available before the project starts compresses the path.
The Five Integration Modes
Five modes describe how AI capabilities connect to legacy systems. Each mode has different latency, complexity, and risk characteristics. The mode that fits a given workload depends on the legacy system's interfaces, the latency requirements, and the regulatory constraints.
The first mode is direct API integration. Where the legacy system has working APIs (REST, SOAP, even older interfaces), the AI capability calls the APIs directly. Lowest complexity when the APIs work. The challenge is that many legacy APIs were designed for a different era of integration and have undocumented behavior, rate limits, or reliability characteristics that make production integration nontrivial.
The second mode is database integration. Where the legacy system stores data in a queryable database, the AI capability reads from the database directly, bypassing the application layer. Faster than API calls. Carries risks: the database schema becomes part of your contract with the legacy system; schema changes break your integration; transactional consistency may be compromised.
The third mode is event-driven integration. Where the legacy system can emit events (often through change data capture from the database or message queues bolted on later), the AI capability subscribes to events and reacts. Decouples the AI capability from the legacy system's response times. Adds complexity in event handling, ordering, and replay.
The fourth mode is screen scraping or RPA integration. Where the legacy system has no usable API or database access, automation tools interact with the system's UI as a human would. Brittle. Slow. Sometimes the only option. Has improved meaningfully with AI-assisted RPA but remains the integration mode of last resort.
The fifth mode is replication and read-only mirror. Where direct access to the legacy system is too risky or slow, data is replicated into a separate analytical or operational store that the AI capability accesses. Decouples the AI capability entirely from the legacy system's operational reliability. Adds data freshness considerations: the mirror is stale by some amount that the workload has to tolerate.
A workload assigned to the wrong mode produces operational pain. A workload assigned to the right mode usually integrates cleanly within the integration budget.
When Each Mode Fits
Direct API integration fits when the APIs are robust, documented, and have acceptable performance. Modern enterprise applications (post-2018 versions of major ERP, CRM, and core banking platforms) often qualify. Older systems usually do not.
Database integration fits when the schema is stable, the AI capability needs more performance than APIs deliver, and the legacy system owner agrees to formalize the schema as a contract. Many enterprises run database integration in practice without the formal agreement, which produces brittle integrations that break unexpectedly.
Event-driven integration fits when the workload tolerates some latency, the legacy system can emit events reliably, and the operational complexity of event handling is justified. Often the best mode for AI workflows that augment legacy processes rather than replacing them.
RPA integration fits when no other mode is available. The cost is high relative to the alternatives and the reliability is lower. Justified for high-value workflows where the legacy system genuinely cannot be modified or extended.
Replication integration fits when freshness above some threshold is acceptable, when direct access risks are too high, or when the AI capability has analytical rather than transactional requirements. The most common mode for AI workloads that consume legacy data without changing it.
The Failure Modes That Repeat
Three failure modes repeat across legacy AI integration projects.
The first is overestimating legacy system stability. Teams scope integrations assuming the legacy system will continue behaving as documented. The actual behavior deviates from documentation in ways that emerge only under integration load. Integrations that survive this discovery had built fallback and detection from the start.
The second is underestimating legacy owner's bandwidth. The team that owns the legacy system has its own roadmap, its own constraints, and its own resistance to changes that benefit other teams. Integration projects that did not budget for the legacy team's involvement usually stall.
The third is underestimating regulatory and audit implications. Adding AI to a workflow that touches regulated data adds compliance overhead even when the legacy system already handles the compliance for the underlying workflow. The AI capability inherits the regulatory framework of the systems it integrates with.
Anticipating these failure modes during scoping makes them manageable. Encountering them during integration is more expensive.
The Architectural Pattern That Survives Both Sides
Integration architectures that survive long enough to deliver value share recognizable structure.
The AI capability does not depend on the legacy system's runtime availability. Failures of the legacy system degrade the AI capability gracefully rather than catastrophically. The integration point is contained.
The integration uses bounded interfaces that the team controls. The team's code does not call internal legacy interfaces directly. An adapter layer sits between, translating from internal legacy specifics to a clean interface the AI capability can rely on.
Data flowing through the integration is logged with sufficient context to support forensics. When something goes wrong, the team can reconstruct what happened on both sides of the integration boundary.
The integration is documented in terms that the team owning the legacy system can review and agree to. The integration is not a unilateral imposition; it is a contract.
These properties are usually missing from accidental integrations and present in deliberate ones. The deliberate ones survive longer.
What Logiciel Does Here
Logiciel works with enterprise engineering teams whose AI work is bottlenecked by integration with legacy systems. The work is typically structured around the five-mode assignment exercise followed by architecture and implementation for the assigned mode.
The Legacy System Risk in Software Delivery framework covers the three-tax-line analysis for prioritizing legacy modernization that integration projects often surface. The Software Architecture in the AI Era framework covers the boundary design that integration architectures depend on.
A 30-minute working session is enough to assess your candidate legacy integration against the five-mode framework.
Frequently Asked Questions
Should I modernize the legacy system before integrating AI?
Sometimes, but usually not as a precondition. The integration project often surfaces what specifically needs to be modernized and produces the business case for the modernization. Sequencing integration first and modernization second is usually more efficient than the reverse.
What is the right team for a legacy integration project?
Engineers familiar with the legacy stack, engineers fluent in the AI stack, and a tech lead who can bridge the two. The bridge role is what most projects under-staff. The skills required are unglamorous and high-leverage.
How do I handle the legacy team that does not want to cooperate?
Through executive alignment that gives the legacy team explicit reasons to engage. Without that alignment, integration projects either work around the legacy team (producing worse outcomes) or stall at the legacy team's queue priority. The executive conversation is the unblock.
How does this work for COBOL or mainframe systems?
The five modes apply. APIs (if MTM/CICS APIs exist), database integration (DB2 or VSAM with appropriate connectors), event-driven (often through change data capture), RPA (3270 screen scraping), or replication. The mode that fits depends on the specific system and workload more than on the era of the underlying technology.
What is the right success metric for legacy AI integration?
Two metrics. Functional correctness of the integration (does it deliver what the workflow needs) and operational reliability (does it stay running under realistic load). Integration projects that hit only one metric usually fail in production. Sources: - Forrester, "Enterprise Integration Trends 2024" - McKinsey, "Cloud's trillion-dollar prize is up for grabs," 2024
