Connecting AI to Your Business Systems

The first AI pilot inside a company usually works. Someone connects a model to a set of documents, asks questions, and gets useful answers. The demo is convincing and the budget follows.

The second phase is where projects stall. The model needs the CRM. Then the ERP. Then the ticketing system, the document store, the data warehouse, and the internal tool that three people maintain. Each connection is built separately, each has its own authentication, its own data shape and its own failure modes, and the integration work grows faster than the value it delivers.

This is the integration problem, and it is the actual engineering content of enterprise AI. The model is a commodity. The connections are not.

Why this grows faster than expected

A company with a handful of AI features and a handful of systems does not have a handful of integrations. It has the product of the two, because each feature needs its own access to each system, usually written separately by whoever built the feature.

That is the arithmetic that turns a successful pilot into a stalled programme. Every new feature multiplies the integration surface rather than adding to it, and every system that changes its API breaks several things at once.

The structural fix is the same one that has worked for every other version of this problem: a single layer that connects systems to a common interface, so that features talk to the layer rather than to each system directly. New feature, no new integrations. New system, one integration that every feature can use.

The difference with AI is what that common interface has to expose.

What a model needs that a normal client does not

A conventional API client is written by a developer who reads documentation, understands the domain, and encodes correct behaviour once. A model has none of that. It reads the interface at the moment of use and decides what to call based on what it sees.

That changes the requirements.

Descriptions are the contract. A model selects a capability by reading its description. Two capabilities with overlapping descriptions produce inconsistent selection, and the result looks like model unreliability when it is interface ambiguity. Descriptions written for a human reader who already knows the system are insufficient.

Responses are context, and context is finite. A conventional client can fetch a large payload and extract one field. Every token a model receives occupies space that later reasoning needs, and costs money on every subsequent step. Interfaces for models should return what the next decision requires, with a separate path to fetch more.

Errors have to teach. A generic failure gives a model nothing to act on, so it retries the same call. An error that states what was wrong and what a valid call looks like lets the model correct itself in one step. Error text is part of the interface, not an implementation detail.

Calls get retried. Models retry on ambiguity and on transient failure. Any capability with side effects needs an idempotency key or a natural uniqueness constraint, or a network timeout becomes a duplicate record in the CRM.

Permissions cannot live in the prompt. An instruction in a prompt is a request. A check in code is a control. The access a model has must be enforced at the interface layer, scoped to the user on whose behalf it acts, regardless of what any instruction says.

An integration layer built for AI is therefore not the same artefact as an internal API. It is an interface designed for a caller that cannot ask a clarifying question.

The three things to expose

Most enterprise AI integrations reduce to three kinds of capability, and separating them clarifies the design.

Data to read. Records, documents, configuration, reference data. Read access is the lowest-risk category and delivers most of the early value, because the majority of useful AI features are questions about data the company already holds.

Actions to take. Creating a record, updating a status, sending a message, generating a document. Actions are where value compounds and where risk appears, because they change the world.

Context to apply. The company's own conventions: how a deal stage is defined, what the approval threshold is, which fields matter in this organisation. This is the category most often skipped, and its absence is why generic AI features feel generic. The model has the data and not the rules the data is read under.

Separating these matters operationally. Read capability can be deployed broadly and early. Action capability needs confirmation, audit and scoping. Context is configuration that changes per customer and should be editable without a deployment.

Standardisation is the current direction

The industry response to this has been to standardise the interface between AI applications and the systems they call, so that an integration written once is usable by any compliant client. The Model Context Protocol is the most visible example: an open protocol that defines how a client exposes tools, data resources and reusable prompts to a model, over a defined transport.

The value of a standard here is not technical elegance. It is that the integration a company writes for its ERP becomes an asset usable by every AI feature it builds afterwards, and that vendors can ship a connector once rather than once per AI platform.

Whether a specific protocol prevails matters less than the architectural point, which is stable regardless: build the integration layer separately from the feature that uses it. A company that writes its system access as part of a chatbot has to rewrite it for the next thing. A company that writes it as a reusable interface does not.

Authentication is the part that gets underestimated

The question that stops most enterprise AI projects at the security review is simple to ask and difficult to answer: when the AI reads a record, whose permissions apply?

There are two models, and the choice has consequences.

Service account. The integration authenticates as itself, with broad access, and the application filters results by user. This is simple to build and places the entire burden of correctness on application code. One missing filter is a data exposure, and the system's audit log shows the service account rather than the person.

Delegated access. The integration acts on behalf of the requesting user, carrying their permissions into the underlying system. The source system enforces access as it always has, the audit trail names the actual person, and a bug in the AI layer cannot exceed what that user could already see.

Delegated access is more work to implement and is the right default for anything touching personal or commercially sensitive data. Where a service account is unavoidable, the scoping it skips has to be reimplemented and tested deliberately rather than assumed.

Either way, every call should be logged with the user, the time, the inputs and the result. This is what makes an AI deployment auditable, and auditability is usually the precondition for deploying it against real systems at all.

Sequencing that works

The pattern that survives contact with a real organisation:

Start with read, in one system. Pick the system that holds the data people ask about most. Deliver a feature that answers questions against it. This proves the access pattern, the permission model and the evaluation approach on something low-risk.

Add the second system before adding actions. The second integration is where you discover whether your layer is actually reusable or whether you built a one-off with a layer-shaped name. Better to find that out while everything is still read-only.

Introduce actions narrowly, with a human at the point of consequence. One action, in one workflow, with confirmation and full logging. Expand once the error profile is understood rather than once the demo impresses someone.

Add organisational context deliberately. The step that converts a competent generic assistant into something that reflects how this company actually works.

The failure mode to avoid is the reverse order: an impressive agent with broad action permissions across several systems, built before anyone knows how often it is wrong.

What this means for software vendors

For companies selling business software, the integration question has inverted. The expectation now is not whether a product has an API, but whether an AI system can use it — read the data, take the actions, and do so under the right user's permissions with an audit trail.

That is a different design target from a REST API written for a developer. It requires descriptions written for a reader with no prior knowledge, responses sized for a context window, errors that teach, and permission enforcement that does not depend on the caller behaving well.

Products that offer this become components in their customers' AI systems. Products that do not become data silos that customers work around, and working around a silo usually means exporting from it.

How we build it

Clavix360, our AI CRM and ERP platform, covers sales, operations, human resources and finance in one system, which removes a large part of this problem rather than solving it — the data an AI feature needs is already in one place, under one permission model, rather than spread across systems that have to be joined at query time. Each organisation runs on its own instance with its own database, so scoping is enforced by a boundary that is physical rather than logical.

Where our platforms do reach outward, the same rules apply that this post describes: capabilities are defined separately from the features that call them, access is scoped to the acting user at the interface layer, and every call is logged.

The summary for anyone planning this work: the model is the least of the engineering. The integration layer, the permission model and the audit trail are what determine whether an AI pilot becomes a system the organisation can rely on.