An AI system that doesn’t access operational data stays an exercise. The value appears when it reads and writes into the systems the company already uses.
The distance between the two conditions is almost entirely integration work. And it’s the line item that, in initial estimates, gets undersized most consistently.
Not out of carelessness. Because it’s invisible in demos, where the data is static and the systems involved are simulated.
Why integration is the most underestimated line item
Three recurring reasons.
The cost isn’t in the connection, it’s in the domain. Technically connecting to a business system is rarely the problem. The problem is understanding what the data means: which field holds the actual status of a case, which codes are still in use, which master records are duplicated, which unwritten rules govern how a value gets updated. It’s analysis work, and it requires the time of the people who know the system.
The systems in use weren’t designed to be queried from outside. Many business systems, especially vertical or heavily customized ones, expose partial interfaces or none at all. The alternatives — direct database access, periodic exports, building an intermediate layer — have different implications for reliability, permissions and maintenance, and need to be weighed at the start.
Organizational dependencies move slower than technical ones. Access to a system requires authorizations, the involvement of the vendor who maintains it, sometimes a contract review. These timelines don’t depend on the project team and need to be planned for.
A useful check at estimation time: if the project plan devotes less time to integration than to building the AI system itself, the estimate is probably wrong.
APIs, connectors and emerging standards
There are three ways to connect, in order of preference.
Application interfaces exposed by the system. This is the right solution when it exists: contracted, documented, with permission and error handling. Check that it also covers write operations, not just reads, if the project needs them.
Intermediate connectors. A layer that exposes heterogeneous systems uniformly, handling authentication, data transformation and call logging. It adds a component to maintain, but it isolates the AI system from the specifics of each business system, which simplifies later replacements.
Direct data access or file exchange. The solution to use when the first two aren’t available. It creates tight coupling with the system’s internal structure, which can change without notice during an update.
On the standards side, recent years have seen a trend toward common protocols for connecting tools and data sources to language models, reducing the need to build one-off integrations. It’s a useful development and the direction looks settled, but it doesn’t eliminate the domain analysis work: a standard uniforms how you connect, not what the data means.
Permissions, logs and reversibility
Three requirements that need to be defined before development, because they shape the architecture.
Permissions. The system has to operate with the identity and rights of the user working with it, not a technical account with broad privileges. It’s the most common choice and the riskiest one: a single account with full access turns any error or abuse into a problem of uncontainable scope.
Logs. Every read and every write need to be logged, with who triggered the operation, when, and with what outcome. This is needed for audit and for diagnosis: without logging, reconstructing why a record was updated incorrectly is impracticable.
Reversibility. Every write operation needs an undo path, or alternatively a constraint that blocks it without human confirmation. This is the criterion that guides which operations to expose: writing an internal status is reversible, sending a communication to a customer is not.
A general principle: the operations available to the system should be defined by inclusion, not exclusion. You enable what’s needed, you don’t ban what isn’t.
An example: from the customer’s email to the recorded order
A company receives orders by email, in free form, often with attachments.
The integrated flow works like this.
The system reads the incoming message and identifies its nature. It identifies the customer by matching the data against the business system’s records. It extracts the order lines from the text and attachments, mapping the descriptions to product codes through the catalog. It checks availability and the commercial terms that apply to that customer, querying real data. It flags unrecognized or ambiguous lines, with a reference to the point in the message they come from. It prepares a draft order in the business system, in unconfirmed status.
And it stops there. Confirmation stays with the sales operator.
The value isn’t in automating data entry. It’s in the fact that the operator receives an order that’s already decoded, with anomalies flagged, and spends their time on exceptions instead of transcription.
Every step in this flow is an integration: master records, catalog, availability, price lists, order management. The AI component is one part of the work, and not the largest one.
What integration doesn’t solve
It doesn’t improve the quality of data in the connected systems. Duplicate records and obsolete codes become visible, not corrected.
It doesn’t eliminate dependency on the vendors of the business systems. An update that changes an interface requires intervention, and needs to be accounted for in the maintenance contract.
It doesn’t reduce application security requirements. A system that writes into business systems needs more attention to how it handles content coming from outside, which has to be treated as untrusted input.
And it doesn’t compensate for an undefined process. If the rules for accepting an order vary by informal practice, the system can’t apply them.
In closing
Integration isn’t the secondary part of an AI project. In many cases it’s the main part, and it’s the one that determines whether the system enters daily work or stays on the margins.
It’s worth addressing at the start: inventory the systems involved, check what they expose, estimate the time authorizations will take.
If you have a process that spans multiple systems, we’re available for a technical conversation about that case: what interfaces exist, what operations would be needed, and where the human confirmation points would sit.
