A distributor wants to use AI to extract order details from customer emails. Its existing order system already checks product codes, calculates prices, reserves stock, and records approvals. The proposed application would reduce manual entry by turning an email into a draft order that staff can review.
The extraction model is only one part of that change. A customer may use an old product name, omit a delivery address, or refer to a discount agreed in a previous conversation. A timeout may occur after an order has been saved. An email attachment may contain instructions that the application should treat as customer content. Integration has to account for these conditions before an apparently convenient feature becomes part of daily operations.
Established systems can support AI without being replaced. The work involves understanding the rules and constraints they already enforce, then designing a controlled route between generated information and business actions.
Identify the Business Boundary First
Start by mapping the existing order process. Identify which application owns customer details, product availability, prices, credit status, and the final order record. Document where staff make judgements and which checks must pass before an order becomes binding. An integration should preserve these responsibilities unless the business explicitly decides to change them.
For the distributor, the AI service could extract a proposed product description, quantity, and delivery request. The order application would remain responsible for resolving product codes, checking current terms, and accepting a transaction. This keeps the model’s interpretation separate from the authority to commit stock or money.
The distinction is more useful than assuming legacy software is deterministic and AI is probabilistic. Many trained models produce repeatable outputs under fixed conditions. Established applications can vary with time, external services, or database state. A probabilistic forecast can itself be computed deterministically. Integration needs a clear account of state, uncertainty, and change across both systems.
Use an Adapter to Protect Existing Rules
An integration layer can translate between the AI application’s proposed data and the established system’s interface. Microsoft’s Anti-Corruption Layer pattern describes isolating systems with different models and semantics through such an intermediary. This is particularly useful when the older application cannot easily adopt a new interface.
The distributor’s adapter could accept an extracted order proposal, resolve recognised fields, and return validation results without creating an order. Staff could then review unresolved details in the existing workflow. The adapter should expose only the operations needed for that use case, rather than provide general database access.
Where no supported API exists, options may include controlled file exchange, scheduled imports, or an interface built around existing application capabilities. Screen automation may be necessary in some settings, but it adds dependence on interface behaviour and requires its own monitoring. The team should investigate supported routes before choosing a fragile shortcut.
An adapter also creates another component to operate. It needs ownership, access controls, capacity planning, and error handling. Its value comes from containing coupling and preserving rules, rather than making integration complexity disappear.
Define Meaning as Part of the Data Contract
A response schema can require a quantity and product identifier, but it cannot establish that the extracted values are correct. The contract should define what each field means, which values are permitted, how uncertainty is represented, and what evidence accompanies the proposal.
For example, a blank delivery date might mean the customer did not provide one. It should not silently become today’s date. A quantity of zero might be invalid rather than a useful substitute for a missing quantity. Product names need a documented mapping to catalogue identifiers, with ambiguous matches returned for review.
Separate structural validation from business validation. A date can be correctly formatted yet fall outside an available delivery window. A product code can exist yet be unavailable to that customer. The established application should continue to enforce the relevant business rules before accepting the transaction.
The contract also needs error states. Distinguish an incomplete customer request, a failed model call, an unavailable catalogue, and an invalid proposal. Sending all four to the same generic retry path obscures the corrective action and can create repeated work for staff.
Keep Identity and Permissions Through the Workflow
An AI interface should not give employees broader access than the systems it connects. The application needs to establish who is asking, which customer records they may use, and which actions they may perform. Service credentials should be limited to the operations required for the integration.
Customer emails and attachments are input material. They may contain misleading or malicious instructions, including requests to ignore rules or send data elsewhere. The application should treat their contents as untrusted information and enforce permissions independently of what the model proposes.
OWASP’s guidance on excessive agency identifies risks from giving language-model applications excessive functionality, permissions, or autonomy. For this workflow, an extraction service does not need permission to change customer credit limits or send arbitrary messages. Keeping those capabilities unavailable reduces the consequences of an incorrect tool request.
Privacy review should establish which email content must reach the model, where it is processed, and how it is retained. Existing customer records should be retrieved only where necessary, and sensitive information should not be copied into logs merely because it passed through the workflow.
Design for Delays, Retries, and Duplicate Work
The team needs a latency budget for the complete path: receiving the email, processing attachments, calling the model, validating the proposal, and presenting it for review. If extraction cannot finish reliably within an interactive session, background processing may suit the work better.
Asynchronous processing requires visible state. Staff need to know whether an email is waiting, being processed, ready for review, or blocked. Failed work should have an owner and a route back into the queue. An unattended collection of failed messages is an operational backlog, even if the model service itself appears healthy.
Retries are particularly important around writes. If a request times out after the order system has saved an order, repeating it blindly could create a duplicate. Microsoft’s Retry pattern guidance highlights the need to consider whether an operation is idempotent: whether repeating it has the same effect as carrying it out once.
The distributor could use a stable request identifier that the order system recognises, or a supported duplicate-detection mechanism. If the older system offers neither, the integration needs a reconciliation process for uncertain results. A fresh model call is not a reliable way to determine whether the original order was committed.
Preserve Evidence Across the Transaction
An investigation should be able to connect the incoming request, extracted proposal, validation results, reviewer changes, and accepted order. Use a correlation identifier across services so staff can follow that sequence without relying on timestamps alone.
Record the relevant model and application versions, along with prompt or extraction configuration where applicable. Retain the proposal that staff actually reviewed. Regenerating it later may produce a different result and does not establish what happened at the time.
Evidence retention should be proportionate. The organisation may need a controlled source reference and a redacted operational log rather than another unrestricted copy of the entire email. Access, retention, and deletion rules should cover investigation data as well as the live order system.
The review interface also needs to distinguish extracted values from confirmed values. Staff should be able to compare a disputed quantity with the customer’s message and correct the draft. That change should reach the final order through the normal validation path.
Release Behavioural Changes Deliberately
A model update can alter extraction results while leaving the response schema intact. Prompt changes, catalogue mappings, document parsers, and preprocessing rules can do the same. These changes need evaluation before they affect live orders.
Maintain representative examples covering ordinary requests, ambiguous quantities, unfamiliar product references, and previously observed errors. Compare the proposed version with the current workflow. Examine whether improvements in one area introduce regressions elsewhere, such as better product matching accompanied by missed delivery restrictions.
A shadow deployment can process real requests without writing to the order system, provided data use is authorised. This reveals proposed behaviour under realistic conditions while staff continue using the established process. A limited release can then test the review interface and operational handling. Shadow results alone cannot show whether staff will notice and correct mistakes.
Recover the Service and the Affected Records
Restoring a previous model or prompt may stop a new error from spreading, but it does not repair orders already created. Recovery should identify the affected window, find relevant transactions, and establish who checks quantities, stock commitments, and customer communications.
The distributor also needs a workable fallback when extraction is unavailable. Manual entry may be sufficient if staff capacity and queue priorities have been considered. If the new process handles much more volume than the team can enter manually, the fallback needs explicit limits and customer expectations.
This is the operational side of retaining control during AI adoption. A team should be able to stop automated processing, understand outstanding work, and continue the most important service functions. Those capabilities deserve testing alongside extraction quality.
A pilot of the integrated workflow can expose these assumptions before wider rollout. The resulting architecture should let AI contribute useful interpretations while established systems retain the controls that make an order valid, traceable, and recoverable.
