Connecting AI to Systems That Have No API

Every AI architecture diagram assumes a clean REST API on the other end. Then you meet the actual business: an ERP from 2009, an industry portal with a login page and nothing else, a shared inbox where the real process lives, and a spreadsheet that one person understands. This is not the exception. For most small and mid-sized companies, this isthe systems landscape — and it's exactly where AI projects quietly stall.

Why this is the real bottleneck

When Gartner lists why GenAI projects get abandoned, the reasons — poor data quality, escalating costs, unclear business value — all trace back to the same root: the data the AI needed was trapped somewhere the team couldn't reliably reach. A model with no access to the systems where work actually happens can only produce suggestions. Suggestions don't show up in the P&L.

The good news: "no API" almost never means "no access." It means you have to work down a ladder.

The integration ladder

Rung 1: The API that officially exists

Always check first, and check harder than the vendor's marketing page — plenty of legacy systems have partner APIs, undocumented endpoints their own web frontend calls, or a paid "integration module" nobody activated. An hour in the browser's network tab has saved me weeks of workarounds.

Rung 2: File exports and SFTP

Deeply unfashionable, extremely reliable. If the system can schedule a CSV or XML export to a folder, you have an integration — one that survives UI redesigns and doesn't care about session cookies. Much of the world's banking infrastructure still runs on exactly this pattern, which tells you something about its durability.

Rung 3: The database underneath

On-premise systems usually sit on a normal SQL database. A read-only connection gets you clean, real-time data with zero UI fragility. It needs the vendor's or IT's blessing and careful scoping — read-only, specific tables, nothing else — but when it's available, it's the best-kept secret in legacy integration.

Rung 4: Browser automation

When there is truly nothing else — government portals, banks, industry platforms that will never ship an API — a Playwright script logs in, navigates, and reads or submits data exactly like the human who does it today. I've used this in production for a Danish accounting firm against skat.dk, replacing a paid robot subscription with an in-house automation the firm actually controls.

Browser automation earns its "last resort" label: it breaks when the UI changes, so it must be built like production software — explicit waits, screenshots on failure, alerting, and a human fallback path. Built that way, it's not a hack. It's a bridge with a maintenance contract.

The architecture that makes it sane

The pattern that keeps this maintainable: AI never talks to the legacy systems directly. Each system gets one small connector — API client, file watcher, or browser script — whose only job is to move data into a clean layer: a normal database with normal schemas. Every AI workflow builds on that layer.

This buys three things:

• Stability. When the portal redesigns its UI, you fix one connector. The extraction pipelines, reconciliation jobs, and reports on top never notice.
• Auditability. Every record in the data layer knows where it came from and when. In finance and compliance contexts, that lineage is the product.
• A future. The day the company migrates off the 2009 ERP, the AI investment survives — it was never coupled to the old system, only to the bridge.

The takeaway

"Our systems are too old for AI" is almost never true. The systems are too old for naiveAI — the kind that assumes a friendly API and gives up without one. With an integration ladder and a clean data layer in between, the age of the systems stops mattering. The companies with the messiest legacy stacks often have the most to gain, precisely because so much of their teams' time goes into manually bridging gaps that a connector could close.