Key Takeaways
- Gartner expects more than 60% of early agentic AI implementations to miss performance or cost expectations, largely because enterprises underestimate integration, governance and talent needs.
- Ask four questions of every system the AI touches: what the workflow needs, which door the AI uses, what it may change, and who notices when it breaks.
- Prefer stable routes first: APIs or MCP connectors, then read-only database views, then scheduled exports, and screen automation only as a bridge.
- Start read-only, grant write access one reversible action at a time, and give the AI its own narrowly scoped service identity.
- Present integration to the CFO as a staged investment tied to one workflow, with a clear decision gate to expand, pause or stop.
A logistics group in Kwai Chung has an AI pilot that drafts replies to shipment enquiries in seconds. Then a customer asks where their container actually is, and the AI has no idea, because the answer lives in a warehouse system installed in 2009 that nobody has touched since the original vendor exited Hong Kong.
This is where most enterprise AI programmes stall: not at the model, but at the join between new intelligence and old systems of record. This guide gives you a four-question framework for deciding how AI connects to each legacy system, what it should be allowed to change, and how to put the plan in front of your CFO.
Why do AI projects stall at legacy system integration?
AI projects stall at integration because the answers that matter sit inside systems of record never designed for outside access: ERPs, warehouse systems, policy platforms and core banking. A model can reason well, but without reliable, permitted access to current data it can only produce generic drafts or confident guesses.
Gartner's research note How to Enable Agentic AI via API-Based Integration (January 2026) puts the problem bluntly: by 2030, more than 60% of early agentic orchestration implementations will fail to meet performance or cost expectations, because enterprises underestimate the integration, governance and talent requirements.
The data layer tells the same story. Dun & Bradstreet's AI Momentum survey of 10,000 businesses found that only 6% describe their enterprise data as fully ready to support AI at scale, even though more than three-quarters report some measurable return.
Hong Kong mid-market firms face a specific version of this. Many run heavily customised ERPs, on-premise servers in a Kwun Tong or Tsuen Wan data room, and line-of-business systems whose original developer no longer supports them. None of that is a reason to wait. It is a reason to plan integration deliberately rather than discover it in month four of a pilot.
What is the four-question integration readiness framework?
Ask four questions of every system the AI must touch: what exactly does the workflow need from it, through which door can the AI reach it, what may the AI change, and who notices when it breaks. The answers set the integration route, the permission level and the monitoring, one system at a time.
1. What does the workflow need from this system?
List the specific fields the AI must read and the specific actions it must take. Most first-phase workflows need far less than teams assume: a shipment status, a contract clause, an outstanding balance. Writing this down usually removes half the systems from scope.
2. Through which door can the AI reach it?
Every system has a most stable available route, from a documented API down to the screen itself. The route decides build cost, run-time reliability and how much maintenance you are signing up for. The next section compares the options.
3. What may the AI change?
Separate reading from writing, and reversible writes from irreversible ones. Drafting a reply is not the same decision as updating a credit limit, and the framework forces that distinction before anyone builds a connector.
4. Who notices when it breaks?
Legacy systems change without notice: a patch, a new screen layout, a renamed field. Each integration needs a named business owner, logging of every AI action, an alert when data stops flowing, and a documented way to switch the AI off without stopping the business process.
Which integration route fits each legacy system?
Choose the most stable route the system already supports. Documented APIs or MCP connectors come first, then read-only database views, then scheduled file exports, and only then screen automation. Each step down is faster to start but more fragile to run, so match the route to how critical the workflow is.
| Route | Best when | Speed to start | Run-time risk |
|---|---|---|---|
| API or MCP connector | The system or its vendor offers a documented interface | Medium | Low |
| Read-only database view | On-premise system, no API, IT controls the database | Medium | Low to medium |
| Scheduled export (CSV or SFTP) | The workflow can tolerate data that is hours old | Fast | Medium: stale data |
| Screen automation (RPA or computer-use agents) | No API, no database access, vendor no longer available | Fast | High: breaks when screens change |
| Human handoff | The action is too sensitive to automate yet | Immediate | Low, but slow |
Gartner's guidance favours a hybrid approach: use protocols such as MCP where agents need to discover tools dynamically, and deterministic APIs where actions must run the same way every time. In practice, that means letting the AI look things up flexibly, while routing anything that changes a record through a fixed, tested path.
One architectural rule saves a great deal of pain later: put a thin integration layer between the AI and your systems instead of wiring each model directly into each database. When you change models, which most enterprises now do every few quarters, the connectors stay put.
How should permissions work when AI can write to core systems?
Start every integration read-only, then grant write access one action at a time, beginning with reversible actions and keeping irreversible ones behind human approval. Give the AI its own service identity with the narrowest possible scope, never a shared staff login, so every change is attributable and can be revoked instantly.
- Level 1, read: the AI looks up records to answer questions or prepare work.
- Level 2, draft: the AI prepares a change or a message; a person approves and executes it.
- Level 3, reversible write: the AI makes changes that can be undone, such as tagging a ticket or booking a provisional slot.
- Level 4, irreversible write: payments, credit decisions, contract changes. Keep these closed or human-approved until the earlier levels have a clean track record.
This mirrors the least-privilege principle Gartner recommends for agent access, and it fits Hong Kong's privacy expectations. The PCPD's Artificial Intelligence: Model Personal Data Protection Framework asks organisations to set human oversight in proportion to risk and to minimise the personal data an AI system processes. In integration terms: the AI should see only the fields its task needs, not the whole customer table.
What does this framework look like in a Hong Kong enterprise?
In practice, the framework turns one vague project to connect AI to everything into a short list of system-by-system decisions. A logistics group might give AI a read-only view of its warehouse system, an API link to its transport platform, and draft-only access to customer email, then widen access after review.
Back to the Kwai Chung logistics group. The workflow is shipment enquiries, and it touches three systems:
- Warehouse management system (on-premise, 2009, no API): IT creates a read-only database view exposing order number, location and status. Nothing else.
- Transport management platform (SaaS): connected through the vendor's documented API for live delivery status.
- Customer email: the AI drafts replies; customer service staff review and send.
After eight weeks of clean logs and an accuracy review, the team moves status-only replies to Level 3 auto-send during office hours, while anything involving claims, charges or delays stays at draft. The legacy warehouse system was never replaced. It simply gained a narrow, governed door.
A financial services firm would run the same exercise with more caution: an overnight export from the policy administration system rather than live access, every customer-facing write held at human approval, and an audit trail designed with compliance before the build begins.
What mistakes do enterprises make when integrating AI with old systems?
The common mistakes are integrating everything before proving one workflow, defaulting to screen automation because it demos quickly, giving the AI a staff member's login, and treating data freshness as an IT detail. Each looks efficient at the pilot stage and becomes expensive once the system runs at volume.
- Boiling the ocean: connecting six systems for a workflow that needed two. Scope from the workflow, not the architecture diagram.
- Screen automation as the default: it impresses in a demo, then breaks after the next software update. Use it as a bridge with a maintenance budget, not a foundation.
- Shared credentials: an AI working under a staff login makes every action unattributable and every audit painful.
- Ignoring freshness: an AI answering from last night's export will confidently quote yesterday's stock level. Decide how old the data may be before choosing the route.
- No off-switch: if the only way to stop a misbehaving integration is to call the vendor, the design is not finished.
How do you present an AI integration plan to the CFO or board?
Present integration as a staged investment tied to one workflow's measurable outcome, not as an infrastructure programme. Show the systems involved, the route and permission level for each, the build and run cost of each route, the risk controls, and the date on which you will decide to expand, pause or stop.
A one-page structure that works in most boardrooms:
- The workflow and its baseline: volume, handling time and error rate today.
- The system map: each system, its integration route and its permission level, in a single table.
- Cost by phase: one-off build, monthly run cost, and an honest maintenance line for fragile routes such as screen automation.
- Risk controls: identity, logging, data minimisation and the off-switch.
- The decision gate: the metric and date that trigger expansion to the next workflow.
CFOs tend to approve plans that show what will not be built yet. A plan that leaves irreversible writes closed in phase one signals discipline, and it gives you a credible reason to return for phase two funding.
Integration is the strategy, not the plumbing
The organisations getting value from AI in 2026 are rarely the ones with the newest systems. They are the ones that decided, system by system, how AI may read, what it may change and who is watching. Legacy systems are not a barrier to AI; an unexamined integration plan is.
Pick one workflow, run the four questions against every system it touches, and start read-only. That is a plan your CFO can approve and your IT team can support.
Empowering AI. Centered on you.
Map your first AI integration with a partner who knows legacy systems
Now that you have the framework, the next step is choosing one workflow and the systems it touches. Start with a free AI employee configuration assessment, and we'll walk you through every step: mapping your systems of record, choosing integration routes and permission levels, deployment and performance tracking. Your data stays on Hong Kong servers or your private cloud, in line with the PDPO, with $0 setup fee.
Book a Free AI Staff Assessment
Frequently Asked Questions
Do we need to replace legacy systems before adopting AI?
No. Most enterprises connect AI to existing systems through APIs, read-only database views or scheduled exports. Replacement makes sense only when the long-term cost of integrating and maintaining a system exceeds the cost of replacing it.
Is RPA a bad choice for connecting AI to old software?
Not always. Screen automation is a sensible bridge when a system has no API and no database access, but screen changes break it, so budget for maintenance and keep it away from irreversible actions.
How long does it take to connect AI to a legacy ERP?
It depends on the route. Systems with a documented API or vendor connector are usually quickest to connect reliably, while systems without one need a database view or export first, which depends on IT access and vendor contracts.
Does connecting AI to internal systems create PDPO risk?
It can if the AI sees more personal data than the task needs. Apply data minimisation, keep data in approved locations, log every access, and follow the PCPD's Model Personal Data Protection Framework for AI.