Ask why an AI deployment stalled and the answer is rarely about the model. It could not see the customer's order. It could not tell which user was asking. It answered from data that was three days old. It had permission to read one system and not the adjacent one that held half the answer.

Those are integration failures, and they are the reason a capable system sits in a pilot environment for a year. The order in which the connections get built therefore matters more than the count, and the right order is unintuitive because the connections that unblock production are not the ones that demonstrate well.

Identity, then permissions, then events, then everything else.

The Environment These Projects Enter

Some context on the terrain, because it explains why sequencing matters at all.

MuleSoft's benchmark research reports organizations managing an average of 957 applications while only 27% are connected, with 82% of IT leaders naming data integration among their biggest obstacles to using AI, and 94% saying AI agents will require architecture to become more API-driven. The same study finds 27% of enterprise APIs ungoverned and only 54% of organizations operating a centralized governance framework.

Read together, those figures describe a common starting position. Most systems are unreachable, most of the reachable ones were connected for a specific purpose years ago, and the governance to tell one from the other is patchy.

An AI project entering that environment has two options. Build a set of point connections that get one use case working, which is fast and leaves the next project exactly where this one started. Or establish the four layers below once, which is slower for the first use case and makes the second and third substantially cheaper.

First: Identity, Because Everything Depends on It

Identity answers a question every subsequent layer needs: on whose behalf is this system acting?

Three models exist, and choosing between them is an architectural decision rather than a configuration.

Acting as the requesting user means the system inherits exactly what that person may see, which is the safest default and the one that satisfies auditors most easily. It requires token propagation through every hop, which is real engineering and is where most implementations cut a corner.

Acting as a service account means the system has fixed permissions regardless of who asks, which is simple and dangerous, because a broadly-permissioned service account will eventually return data to someone who should not see it.

Acting as itself, with its own identity and its own permission grants, sits between the two and works well where the system performs a defined function rather than answering arbitrary questions.

Settle this in week one and document the choice with its rationale. Teams that defer it end up with a mixture, where some tools propagate user context and others do not, and the resulting behavior is impossible to reason about or to explain to a security reviewer.

Two practical requirements follow. Every call the system makes should carry a traceable identity into the logs. And the system's own credentials should rotate on the same schedule as any other service credential, which sounds obvious and is frequently missed on systems built by data teams rather than platform teams.

Second: Permissions as a Designed Artifact

Permissions built by accumulation produce the two failures nobody wants at once: too much access somewhere and too little somewhere else.

Design them instead. Write a matrix listing every object or resource the system may read, every action it may take, the identity under which each occurs, and the justification. Review it when a new capability is added rather than granting access ad hoc to unblock a sprint.

The under-granting failure is the subtler of the two. A system that lacks access to a needed field does not usually raise an error a business user understands; it returns an incomplete answer, apologizes vaguely, or fills the gap with something plausible. Diagnosing that from a transcript is slow, because the symptom looks like a model problem.

Test the negative case deliberately. Ask the system something requiring data outside its scope and confirm it declines cleanly rather than improvising. Ten minutes of this before launch prevents a category of incident.

Proportionality matters as the estate grows. Gartner warns that applying uniform governance across AI agents regardless of autonomy leads to failure, either throttling simple systems or under-supervising consequential ones, and expects 40% of enterprises to demote or decommission autonomous agents by 2027 over governance gaps found only after production incidents. Agree the tiers once and apply them per system rather than writing one policy for everything.

Third: Event Plumbing, Because Freshness Decides Usefulness

A correct answer about yesterday's state is a wrong answer to a customer standing at a counter.

Freshness requirements vary by use case and should be stated explicitly rather than assumed. An assistant answering order status needs minutes. One summarizing quarterly performance tolerates a daily batch. Designing everything for real time costs money the business rarely needs to spend; designing everything for batch produces systems that are quietly useless.

Where currency matters, the source system needs to publish changes rather than being polled. Publishing is the harder engineering and the more durable arrangement, because the next consumer subscribes rather than adding another scheduled job.

Three questions establish what is actually possible. Can each source system emit an event on change, and if not, what is the cheapest approximation? What is the acceptable staleness per data element, agreed with the business rather than assumed by the architect? And what happens when the event stream stops, since silent staleness is worse than a visible outage?

Instrument the answer. A freshness indicator, showing the age of the underlying data, costs almost nothing and converts an invisible failure into a visible one.

Fourth: What AI Integration Solutions Connect After the Foundations

With identity, permissions, and events established, remaining connections become routine and can be prioritized by what they unblock.

1. The system of record for the primary entity, since almost every question resolves to a customer, an order, a policy, or a case.
2. The transactional systems the primary entity touches, which supply the state that makes answers specific.
3. Unstructured content, meaning documents, knowledge, and correspondence, with an explicit decision about which of it is eligible to be surfaced.
4. Action endpoints, which are the write operations, approved separately and later because they attract more scrutiny and are needed less often in a first release.
5. Enrichment and third-party sources, last, and only where a specific use case depends on them.

Two cautions apply to the third item. Unstructured content frequently contains material that should never reach a customer, including internal notes and pricing exceptions, so eligibility is a policy decision rather than a technical one. And the corpus needs a maintenance owner, since retrieval will surface superseded documents with complete confidence.

AI integration services that follow this order tend to reach production with fewer surprises, because the items most likely to be refused by security have been raised first.

Judging AI Integration Services on the Unglamorous Work

Capability decks describe connectors. The questions that matter describe what happens around them.

Ask how they establish the identity model and whether they propagate user context. A provider who has not thought about this will describe a service account without noticing that they have made a significant decision.

Ask what they instrument. Credible artificial intelligence integration services describe logging every call with its identity, latency, and outcome, plus a freshness measure per source. Weak ones treat monitoring as a client concern.

Ask how they retire a connection. Removing an integration safely requires knowing who consumes it, which requires observability most estates lack, and a firm that has done it describes traffic analysis and a deprecation period rather than switching it off and waiting.

Then ask what they would refuse to connect in a first release. Ai integration solutions scoped by a provider with production experience always exclude something, usually the write operations and the third-party enrichment, and the exclusion is a sign of judgment rather than reluctance.

What to Do When a System Cannot Be Connected

Every estate contains at least one system that resists connection: a mainframe application with no interface, a vendor product whose API costs more than the project, a database nobody will grant access to.

Four options exist, in rough order of preference.

Build a narrow interface in front of it, exposing only the specific reads the use case needs. This is more work than it sounds and less than a full integration, and the resulting interface serves every future consumer.

Replicate the needed subset into a location the system can reach, on a schedule matched to the freshness requirement. Acceptable where the data changes slowly, and a trap where it does not, since a stale replica produces confident wrong answers.

Redesign the use case to avoid the data. Frequently the right answer, and rarely considered, because the requirement was written before anyone checked what was reachable.

Leave a human in that step. An assistant that handles the parts it can reach and hands off the rest still removes most of the effort, and it ships this quarter rather than after an integration program.

The one option to avoid is scraping a user interface. It works in a demonstration, breaks on the next release of the target system, and produces an outage nobody can diagnose because the failure is a changed page layout.

Where the Trust Problem Sits

One further consideration shapes the whole program. Salesforce research reports that only 53% of IT leaders fully trust the accuracy of their organization's data, which is a reasonable estimate of how much of a connected estate anyone is willing to let an AI system answer from unexamined.

That figure argues for two habits. Connect the systems whose data quality is known and defensible before connecting the ones nobody has audited, since an early wrong answer sourced from a bad system damages confidence in the whole deployment. And record provenance with every answer, so a disputed response can be traced to the record it came from and the argument becomes about the data rather than about the technology.

For AI integration services for enterprises operating across many business units, that provenance record is also what makes federated adoption possible. A second business unit will adopt a system it can audit and will refuse one it cannot.

AI integration services earn their fee on identity, permissions, and event plumbing rather than on connector counts, because those three decide whether anything reaches production and whether the second use case is cheaper than the first. Professionals sequence engagements in that order, and teams planning a first deployment can begin with an AI integration readiness review. Before writing a design, list every system your intended use case must reach and note, for each, who approves access and how fresh the data has to be.