The demo works because someone uploaded three documents. Production is different: the documents live in a content system with inherited folder permissions, the customer records sit in a CRM that a partner administers, the transaction history is in an ERP whose vendor charges for API access, and the status field everyone actually trusts is maintained in a spreadsheet on a shared drive.
That gap is where most AI projects lose their schedule. The model was never the hard part. Getting reliable, current, permission-aware data into it — and getting its output safely back into the systems where work happens — is a distinct engineering discipline with its own failure modes.
This guide covers what that work involves: taking inventory of the systems of record, dealing with applications that predate modern APIs, choosing sync patterns that match how fresh the data needs to be, carrying authorization through to retrieval, writing back without corrupting anything, and designing for the days when an upstream system is unavailable.
Start With the Systems of Record, Not the Systems Available
The first mistake in integration planning is connecting to whatever has the easiest API rather than whatever holds the truth.
For each data element the AI system needs, establish which system is authoritative. This sounds trivial until you discover that employee status exists in the HR platform, the identity provider, and the badge access system, and that all three disagree for anyone who changed roles in the last month. An AI system grounded in the wrong one produces answers that are internally consistent and externally wrong.
Document three things per element: the authoritative source, how quickly it changes, and how quickly a change must be reflected for the AI system to behave correctly. That last item is a design input, not a detail. A policy document that changes quarterly and a credit limit that changes hourly demand entirely different architectures, and building both to the stricter requirement wastes money while building both to the looser one produces incidents.
Also note ownership. Every integration is a dependency on a team that will change something without telling you. Knowing who runs each system is what makes it possible to be warned rather than surprised.
Legacy Systems Without a Usable API
Nearly every organization has at least one important system with no modern interface. There are four workable approaches, in descending order of preference.
Database read replicas. Where the vendor permits it, a read-only replica gives clean, complete access without touching the production application. The cost is that you are coupled to an internal schema that can change during upgrades without notice, so schema drift monitoring is mandatory.
File-based extracts. Scheduled exports to a landing location are the most common legacy pattern and the most robust. They are also the least fresh, which makes them appropriate for reference data and inappropriate for anything transactional. Build them with explicit completion markers so a partially written file is never processed as though it were complete.
Middleware and integration platforms. If an ESB or iPaaS already exists, it may already have a connection to the legacy system. Reusing it is faster than building a new path and inherits whatever monitoring already exists. It also adds a hop, which adds latency and another owner.
Screen or terminal automation. Robotic process automation against a UI is the last resort, and occasionally the only resort. It works, and it breaks whenever a screen changes. If you go here, isolate the automation behind a stable internal interface so the fragility is contained to one component rather than spread through the system.
What to avoid is the fifth option teams reach for under time pressure: a manual export someone runs weekly. It works during the pilot and quietly stops when that person is on leave, and the AI system continues answering confidently from stale data.
Sync Patterns and the Freshness Question
There are three patterns, and most real deployments use all three for different data.
Batch synchronization runs on a schedule and moves everything changed since the last run into your own store. It is simple, resilient to source downtime, and cheap. Its weakness is staleness bounded by the interval.
Event-driven synchronization has the source system push changes as they happen, through webhooks or a message queue. Freshness is excellent and load on the source is minimal. The complications are real: events arrive out of order, get delivered twice, or get missed entirely during an outage. Any event pipeline needs idempotent handlers and a periodic reconciliation batch to repair drift. Treating events as reliable without that safety net is the most common source of silent divergence.
On-demand retrieval queries the source at the moment the AI system needs the data. Freshness is perfect and nothing is stored, which is often the right answer for sensitive records. The costs are latency added to every interaction and load added to a system that may not tolerate it. Rate limits are usually what force a hybrid.
The practical architecture that emerges: batch for large reference corpora, events for state changes that need to be reflected quickly, and on-demand for the handful of sensitive or highly volatile fields. Decide per data element using the freshness requirement recorded during inventory, and the pattern choice becomes mechanical rather than contested. The same layered thinking underpins durable HR automation architectures.
Carrying Authorization Through to Retrieval
The single most consequential integration decision is how permissions travel.
An AI system that indexes content with a service account holding broad access has effectively created a search index over everything, and any user of the system can potentially reach any indexed document through a well-phrased question. The exposure is not theoretical — it is the most frequently reported failure in enterprise deployments.
Two approaches work. The first captures source permissions alongside content at index time and filters retrieval against the requesting user's identity, which requires that permission changes propagate promptly and that group membership resolution is kept current. The second, more conservative approach queries the source system on behalf of the user at request time, so authorization is enforced by the system that owns it. This is slower and heavier, and it is correct for the most sensitive material.
Two further details matter. Service accounts should hold the minimum scope required, not the administrative access that made setup convenient. And deletion has to propagate: when a document is removed or a permission is revoked at the source, the index must reflect it within a defined window, and that window should be a documented commitment rather than an emergent property of the sync schedule.
Writing Back Without Breaking Anything
Read integrations are forgiving. Write integrations are not, because a bad write persists.
Every write path needs idempotency, so that a retry after a timeout does not create a duplicate record. This is usually implemented with a client-generated key the target system deduplicates against, and it is far easier to build in from the start than to add after the first duplicate incident.
Multi-step writes need a defined behavior for partial failure. If the sequence is create record, attach document, notify owner, and step two fails, the system must either complete a compensating rollback or leave the partial state in an explicitly flagged condition that a human can resolve. Silent partial completion is how data quality erodes invisibly.
Writes should also be attributable. Actions taken under a shared service account cannot be traced to the request that caused them, which becomes a problem the first time an auditor asks. Where the target system supports it, act under a delegated user identity; where it does not, log the originating request identifier in a field the target retains. Audit expectations here are the same ones covered in our guide to HR compliance audits: who did what, when, and on whose authority.
Finally, stage autonomy. New write integrations should begin in a mode where the system proposes and a human confirms, then move to automatic writes for cases below a defined risk threshold, with everything above it still routed for approval.
Designing for Failure
Upstream systems go down, get slow, change their schemas, and enforce rate limits at inconvenient moments. Integration quality is mostly determined by what happens then.
Timeouts should be explicit on every call, with retry using exponential backoff and jitter, and a circuit breaker that stops hammering a struggling system after repeated failures. Without a breaker, one slow dependency cascades into a queue backlog that takes hours to drain after the dependency recovers.
Degraded operation should be designed rather than improvised. If the ERP is unavailable, can the AI system still answer from cached data while clearly labeling it as of a particular timestamp? A stale answer marked stale is useful. A stale answer presented as current is a liability.
Schema drift needs active detection. A field renamed in a source system typically manifests as quietly missing data rather than an error, and quietly missing data produces subtly wrong outputs for weeks. Validate the shape of incoming data on every sync and alert when it changes.
Monitoring should cover integration health specifically — last successful sync per source, record counts against expectations, error rates by endpoint, and reconciliation differences. Application uptime dashboards will show green while an integration has been failing for three days.
What Good Integration Work Looks Like
Judged from the outside, a well-integrated AI system is unremarkable. Answers reflect current data. Users see exactly what their role permits. Writes land once, in the right place, attributed correctly. When a source system has an outage, the AI degrades visibly rather than lying.
Getting there is engineering rather than configuration, and it is usually the largest single line item in an AI project that touches real operations. Scoping it honestly at the start — system by system, with freshness and permission requirements written down — is what keeps a project from stalling at the ninety percent mark.
Workisy provides AI integration services that begin with exactly that inventory: which systems hold the truth, what they can expose, and how current the data has to be. If you are working out whether your existing stack can support the AI capability you have in mind, the architecture guidance in our AI tech stack guide is a useful starting point, and a scoping conversation will surface the constraints faster — get in touch.
