AI Integration

When AI integration goes wrong: lessons from the field

20 April 2026

When AI integration goes wrong

Every category of software implementation has its failure stories. AI integration has its own set, and they share common patterns. The failures documented here are drawn from real project patterns: what went wrong, what the warning signs looked like before the failure occurred, and what the teams that recovered did differently.

None of these failures required novel technical solutions to fix. They required earlier attention to the things that were already known to matter.

The forty thousand dollar integration that broke on the first update

A mid-size distribution company spent forty thousand dollars on a custom AI integration connecting their order management system to an outbound communication tool. The integration read new orders, classified their urgency, and triggered appropriate customer communications based on order status.

Three months after launch, the order management software released a major version update. The update changed the data structure of the order records the integration was reading. The integration began misclassifying orders. Customers received incorrect status updates for six days before anyone identified the integration as the source of the problem.

What went wrong: the integration was built against a specific API response structure with no error handling for unexpected formats. The update changed the format. The integration continued to run silently, misclassifying on changed data rather than failing and alerting.

The warning sign: the provider had not configured any monitoring or alerting on integration outputs. A run that returned unexpected data was indistinguishable from a successful run.

The recovery: the company hired a different provider to rebuild the integration with format validation on every input, alerting on any output that fell outside expected parameters, and a documented process for checking the integration health after any platform update.

The lead qualification system nobody used

A professional services firm built an AI lead qualification integration for their inbound enquiry process. The integration classified incoming website enquiries by service type and urgency and routed them to the appropriate team member. The build took three weeks. The system was technically functional on launch day.

Six months later, the team reported they were not using the integration. They had reverted to manually reading and routing all inbound enquiries. The AI classifications were ignored.

What went wrong: the team was not involved in the scoping session. The integration was built based on how management believed the enquiry process worked, not how the team actually handled it. The classification categories did not match the team's mental model of urgency. The routing logic sent enquiries to inboxes the team did not regularly check.

The warning sign: the person who owned the workflow day-to-day was not in the room when the integration was scoped.

The recovery: the team rebuilt the classification criteria with input from the people who handled the enquiries. The routing logic was changed to match actual inbox behaviour. The integration was relaunched with a two-week period where the team validated classifications manually before trusting them automatically. Adoption reached near-one hundred percent within a month of the relaunch.

The invoice extraction that fabricated data

A finance team deployed an AI invoice extraction integration that read PDF invoices from an email inbox, extracted key fields including supplier name, invoice number, total amount, and due date, and populated a spreadsheet used for accounts payable processing.

The integration worked reliably for two months. A subsequent audit found fourteen invoices where the extracted total amount did not match the PDF. In eight cases the AI had hallucinated a plausible-looking number that was not present in the document. The discrepancies totalled six thousand pounds.

What went wrong: the integration was deployed without a human review step on the extracted amounts. The assumption was that document extraction was reliable enough to skip validation.

The warning sign: the accuracy testing during development used a sample of twenty invoices from a single supplier with consistent formatting. The production environment included invoices from forty-seven suppliers with varying formats, including several where totals appeared in non-standard locations.

The recovery: the team added a mandatory human review step for any invoice above five hundred pounds. Below that threshold, the extraction confidence score was used to gate automatic processing: high-confidence extractions processed automatically, low-confidence extractions flagged for human review. The error rate on reviewed invoices was zero. The error rate on automatically processed invoices, after the confidence gate was applied, was under zero point two percent.

The patterns that predict failure

Across these and similar cases, four patterns predict integration failure before any code is written.

First: the scoping session does not include the people who will use the integration daily. Second: there is no human review step on AI outputs in the period immediately after launch. Third: no monitoring is configured on integration runs before the system goes live. Fourth: the integration runs in provider-owned infrastructure with no documented handover process for when the provider relationship ends.

Each of these patterns is a choice, not an inevitability. They occur when providers optimise for build speed over delivery quality, and when clients do not ask the right questions before signing.