Most AI projects do not fail at the model. They fail at the seam — the place where something clever has to read from, and write back into, the software a business already depends on. The demo works because a person pastes the input in by hand. The production version has to go and get it, from an ERP that was configured in 2014, a shared mailbox, a field-service app with no documented API, and a folder of PDFs that three people maintain by convention rather than by rule.
That seam is the actual engineering work. It is also where the cost sits, which is why estimates that only account for the model are usually wrong by a wide margin. Published industry surveys of enterprise AI programmes tend to put integration and data plumbing somewhere between half and three-quarters of total build effort — a range, not a figure, and it varies enormously with how tidy the underlying systems are. The useful thing about that range is what it implies: if a proposal treats integration as a line item at the end, it has not been costed.
This is the step after readiness. If you have not yet worked out which workflow is worth automating first, start with the readiness checks — this page assumes you already know what you are connecting and why.
There are only four ways in
Whatever the vendor’s architecture diagram looks like, a system exposes itself in one of four ways, and which one you get decides almost everything about effort, reliability and ongoing cost.
A documented API. The best case. Authentication is specified, the data model is published, rate limits are known, and breaking changes come with notice. Modern accounting platforms, most CRMs, the major cloud storage providers and the newer field-service tools all sit here. Integration becomes a question of mapping fields correctly and handling failure well, which is ordinary software work with predictable effort.
A database you can reach. Common with on-premise ERPs and line-of-business systems. You can read reliably, which is often all you need. Writing directly to a vendor’s database is a different matter — it bypasses the application’s own validation and business rules, and it is the fastest way to create data that the application itself considers corrupt. Read directly, write through the application wherever an interface exists.
Scheduled file exchange. A nightly export to SFTP, a CSV dropped in a folder, a report emailed to a distribution list. Unfashionable and genuinely underrated. It is simple, it is debuggable, it leaves an audit trail, and for any process that runs daily rather than instantly it is frequently the right answer. The failure mode is quiet: a file that stops arriving looks exactly like a day with no data unless you check for the file’s absence rather than its contents.
Nothing at all. No API, no database access, no export — just a screen a person operates. Here the options narrow to browser automation, which is brittle and breaks whenever the vendor ships a UI change, or a conversation with the vendor about whether an interface exists that is not advertised. Surprisingly often one does. Ask before you build.
Work out which of the four you are dealing with before anyone estimates anything. A project that assumed the first case and discovered the fourth is not a project that ran over; it is a different project.
The data is the schedule
Clean, well-structured, consistently labelled data turns an integration into a short piece of work. Everything else is where the weeks go, and the gap between the two is wider than most plans allow for.
Three problems account for most of it. The first is the same entity recorded differently in different systems — a customer who is “Acme Ltd” in the CRM, “ACME LIMITED” in the accounting system and “Acme” in the delivery notes. Reconciling that is not an AI problem and AI will not solve it for you; it needs a decision about which system is authoritative, and then it needs that decision applied.
The second is missing history. A model that classifies, routes, extracts or predicts needs examples of the thing being done correctly. If nobody recorded the outcome — if the correct answer lived in someone’s judgement and was never written down — then the examples have to be created before anything can be trained or evaluated. Published guidance on practical fine-tuning and evaluation set sizes generally lands between thirty and a few hundred examples for narrow, well-defined tasks, and that work is ordinary labelling effort on a calendar.
The third is structure that is really convention. A spreadsheet where column H means one thing above row 400 and something else below it, because the process changed in March and nobody migrated the old rows. This is extremely common and almost never documented. It is also the reason a pilot that worked on last quarter’s data fails on the full set.
None of this is a reason not to proceed. It is a reason to look at the data before committing to a date.
Write paths need more care than read paths
Reading from a system is low-risk: if the integration is wrong, you get a wrong answer and you can see it. Writing into a system changes the record of the business, and a wrong write propagates into invoices, stock levels, customer communications and reports before anyone notices.
So write paths get treated differently. Four things carry most of the weight.
A human approves anything consequential, at least at first. Not forever — the point of automation is that eventually it runs — but the first weeks of any write path should queue its output for a person rather than commit it. This is also the cheapest way to measure accuracy honestly, because every item the person corrects is a labelled error.
Every write is idempotent and traceable. If the same instruction arrives twice, the second one must not create a second record. And every record the system touched should be identifiable afterwards, so that a bad batch can be found and reversed without reconstructing it from logs.
Failures are loud. The dangerous outcome is not a crash; a crash gets noticed. It is a process that silently stops, or that writes something plausible but wrong. Alert on absence — no file, no run, no records processed — not just on errors.
There is a way back. Before the first write goes live, someone should be able to answer how a day’s output would be reversed. If the answer involves a database restore, the design is not finished.
A concrete example
Consider an operations team that receives supplier confirmations by email — perhaps seventy a morning, each a PDF with a reference number, a set of line items and a delivery date. Someone opens each one, finds the matching order in the ERP, and updates the date.
The model work here is the easy part: extracting three fields from a structured PDF is well-trodden. The integration work is where the project actually lives. The mailbox needs reading without losing messages or reprocessing them. The reference number has to match an order, and some will not match because the supplier uses their own reference. The date has to be written into the ERP, which may or may not have an interface for that field. And the roughly one in ten that is ambiguous has to go to a person rather than being guessed at, which means a queue, and a screen for the queue, and a decision about what happens to an item nobody picks up.
That shape — easy model, demanding seam, a human path for the residue — is what most of this work looks like in practice. It is unglamorous and it is the difference between a demonstration and something the business can lean on. Our approach runs it as discover, architect, build and validate, then improve with evidence, for exactly this reason: the architecture step exists because the seam is the risk.
What to ask before you commit
Five questions, answerable in an afternoon, that tell you most of what the estimate depends on.
Which of the four access routes does each system actually offer, confirmed rather than assumed? Which system is authoritative when two of them disagree? Does the history needed to evaluate the output exist, or does it have to be created? What is the approval path for the first few weeks of writes? And how would a bad day be reversed?
If those answers are clear, the integration is scopeable. If several are unknown, that is the first piece of work, and it is worth doing as a short discovery rather than as a surprise halfway through a build.
If you run through them and conclude that the systems are not ready to be connected yet — that the data needs tidying first, or that the authoritative source is genuinely undecided — that is a real answer and it has saved you the more expensive version of finding out. We are happy to talk it through either way, and happy to say so if the honest answer is not yet. If the answer is that it is scopeable, what we build starts from the seam rather than the model.