Adding AI to an existing enterprise system — an ERP, a CRM, a warehouse management platform, a procurement system — does not require replacing the system. The AI sits alongside it, reads its data, makes decisions, and feeds those decisions back. The architecture of that integration determines everything: whether the project takes 8 weeks or 8 months, whether it costs $50K or $300K, and whether the AI actually gets used in production or sits in a demo environment collecting dust.
What are the three integration patterns for AI in enterprise systems?
Pattern 1: Read-only advisory. The AI reads data from the existing system and produces recommendations in a separate interface — a dashboard, an email, a Slack notification. The existing system is unchanged. This is the lowest-risk pattern: the AI can be wrong and nothing breaks, because humans decide whether to act on its recommendations. Best for: initial deployments, decision support, analytics augmentation.
Pattern 2: Write-back with approval. The AI reads data, makes a decision, and stages the action in the existing system — but a human approves before it executes. A lead scoring agent scores the lead and pre-fills the routing, but the sales manager clicks "approve" before it goes to the rep. This is the mid-risk pattern: the AI accelerates the process without removing human judgment.
Pattern 3: Autonomous action. The AI reads, decides, and acts without human intervention. The call quality agent scores every call and flags deviations in real time. The order routing engine splits orders across warehouses automatically. This is the highest-value pattern but requires the highest confidence in the AI's accuracy and the most investment in monitoring and error handling.
Most projects should start at Pattern 1 and graduate to Pattern 2 or 3 as confidence builds. Starting at Pattern 3 with untested AI is the most common cause of enterprise AI project failure.
How does the AI connect to a legacy system?
The connection method depends on what the legacy system exposes. Modern systems (last 10 years) usually have REST APIs. Older systems may only expose a database or flat file exports. The integration approach matches the available surface:
API integration is the cleanest path. The AI service calls the system's API to read data and (for Patterns 2–3) write decisions back. This is the fastest to build and the most maintainable. If the system has a documented API, use it.
Database integration reads directly from the system's database. This bypasses the API layer and gives the AI access to all stored data, but it creates a dependency on the database schema — if the system vendor changes the schema in an update, the integration breaks. Use this when no API exists and the data volume is too large for file-based transfer.
File-based integration uses scheduled exports (CSV, XML, EDI) from the legacy system, processed by the AI, with results imported back. This is the oldest pattern and works for batch processing scenarios where real-time decisions aren't required. It's also the only option for some older systems that expose neither API nor direct database access.
What does the AI layer actually look like?
The AI layer is a separate application — typically a web service — that sits between the data sources and the decision consumers. It has four components: a data ingestion pipeline that normalises input from the legacy system, the AI model (LLM, ML model, or rules engine depending on the use case), a decision output layer that formats results for the target system, and a monitoring dashboard that tracks accuracy and throughput.
For LLM-based agents (document analysis, natural language processing, content generation), the model runs as an API call to OpenAI, Anthropic, or a self-hosted model. The custom code is the integration and prompt engineering, not the model itself. For ML-based agents (prediction, classification, anomaly detection), the model is trained on your data and deployed as a microservice.
The architecture is deliberately decoupled from the legacy system. If the legacy system changes, only the data ingestion pipeline needs updating. If the AI model needs improvement, only the model layer changes. This separation is what makes the approach sustainable — the AI software can evolve without touching the production system it augments.
What are the common failure points?
Data quality at the boundary. The legacy system stores data in formats the AI doesn't expect: inconsistent date formats, nullable fields that shouldn't be null, free-text fields where structured data should be. The data normalisation step is where most integration time goes — and where most projects underestimate the effort.
Rate limiting and latency. The legacy system's API can handle 10 requests per second. The AI needs to process 10,000 records. Without batching and queuing, the integration hammers the legacy system and degrades its performance for all users. Design for throughput, not just correctness.
Error handling at the write-back point. When the AI makes a decision and tries to write it back to the legacy system, what happens if the write fails? Does the decision get lost? Retried? Queued? The error handling architecture at the write-back point determines whether the system is production-grade or demo-grade.
Where to start
Pick one decision the legacy system can't make well. Build a read-only advisory layer (Pattern 1) that makes that decision based on the system's data. Deploy it. Measure it. If the accuracy meets the threshold you defined, graduate to Pattern 2 (write-back with approval). The entire Pattern 1 build, for a single well-scoped decision, can be delivered in 6–8 weeks.
The legacy system doesn't need to be replaced to become intelligent. It needs a layer that reads what it knows and adds what it can't do on its own.
Building something complex?
Start a project with Madgeek