AI system integration: how to put AI inside the systems you already run

There are six common patterns, and a project often uses two or three together. The pattern decides what the AI can touch, so choose it before you choose a model.

The table gives each pattern, when it fits and the main risk. Start with the pattern that gives the AI the least reach for the job. A search over documents reaches less than an agent that updates records.

For the last row, our guide to AI for ERP and CRM sets the vendors' built-in AI against a layer of your own. If the work today runs on a no-code tool, our guide to when Zapier is not enough sets out the signs it has reached its limit. Choosing which process to start with is covered in our guide to AI workflow automation.

A common integration failure is an AI system that can see or change more than the person using it. It happens when a project connects with one shared service account that can read everything, because that is the quickest way to make a demo work.

Four rules keep access where it belongs. The first is single sign-on, so people reach the AI tool through the identity system you already control. The second is automated provisioning through SCIM, the System for Cross-domain Identity Management. It is an HTTP and JSON protocol for creating, reading, updating and deleting users and groups in another system, and RFC 7644 defines it with /Users and /Groups as the main endpoints. Joiners and leavers then follow your HR record, and nobody keeps access by being forgotten.

The third rule is to act as the user. Where the source system supports delegated identity, the AI calls it with the person's own token, so the source system decides what that person may see. OWASP's guidance on excessive agency backs this. It says to run extensions in the user's context, give them the least privilege the task needs, and enforce authorisation in the downstream system.

The fourth rule is a human approval for high-impact actions. OWASP names human-in-the-loop approval as a control for exactly that case.

Retrieval needs one more check. If documents are copied into a search index, their permissions have to be copied and kept current, or the index becomes a way around the source system. Our checklist for Microsoft 365 Copilot oversharing shows what to fix in the source before an assistant reads it.

The Model Context Protocol is an open standard for connecting AI applications to data and tools. Its specification, in the version dated 28 July 2026, describes hosts that start connections, clients inside the host and servers that offer resources, prompts and tools. Messages use JSON-RPC 2.0.

The point for an enterprise is reuse. One well-built server for your ticketing system can serve a chat assistant, a coding agent and a workflow, and one team owns its permissions.

The specification says authorisation is optional. Where an HTTP-based server supports it, it follows OAuth 2.1, and a client must name the server a token is for, using the resource parameter from RFC 8707. A server must accept only tokens issued for itself. The specification also says tools represent arbitrary code execution, that descriptions of tool behaviour should be treated as untrusted unless they come from a trusted server, and that hosts must get explicit user consent before invoking a tool.

OpenAI's documentation for remote MCP servers and connectors says it asks for approval before sharing data with a connector by default. It also says data sent to an MCP server is subject to that server's own retention and residency policies, so you are the one to confirm it meets yours. It warns that remote servers have not been verified by OpenAI and that a malicious one can take sensitive data from anything that enters the model's context. It advises using official servers from the service provider.

Anthropic's MCP connector for the Messages API was in beta when we read it. It supports tool calls only, needs a server reachable over HTTP, and lets you allowlist or denylist individual tools. Anthropic recommends denylisting write or destructive tools for read-only assistants. The page lists the feature as not eligible for zero data retention.

From these pages, the steps are to expose the fewest tools that do the job, start read-only, name who runs each server and review it again when it changes.

Every integration moves data in at least two places: to the model provider, and to any retrieval index or connector in between. Draw that path before the build. For each hop, write down who runs it, where it runs, what is kept and for how long.

Settle three things for each hop. Find out whether the prompt leaves your cloud region, whether the provider keeps the request and for how long, and whether a connector or server in the chain keeps its own copy under its own policy. OpenAI's documentation is plain that its zero data retention and data residency controls do not extend to what a third-party MCP server does with the data it receives.

Where the answers do not fit your rules, there are three routes. Pick a model offering with the retention and region terms you need. Move the model closer to the data, which our guide to private LLMs covers. Or send less, by redacting or tokenising personal data before the call and restoring it after. For the Gulf, the country rules are in our Gulf data residency guide.

Our guide to preparing data for AI covers the checks on the data itself: access, quality, ownership and personal data.

An integration has to be right often enough on your cases, and you have to see when it stops being right.

Before the integration, build a test set of real cases from the workflow, with the correct outcome written beside each. Agree pass marks with the process owner before any result is seen. Run it on every change to a prompt, model, tool or rule. Include the awkward cases: missing fields, duplicates, a document in the wrong language, a tool that returns an error.

In production, keep one structured record per request. It should show what came in, which model and prompt version ran, which tools were called with what arguments, what the checks said, who approved and what was written to which system. That record is how you explain later why the system did what it did. The tests, checks and records around the model are what our guide to the AI harness describes.

Add cost to the record. Token counts and run counts per workflow, with an alert and a ceiling, stop a loop from becoming a bill. Model versions retire on the vendor's timetable, so keep the test set ready to prove a replacement.

The system that holds the data is often the oldest one, with no API or a poor one, and the integration layer has to work around that.

Use a supported API if there is one. Otherwise use a scheduled export or a file drop, read the database through a replica or a view, or put a thin service in front of the system that exposes only the operations you need. Each route can carry the same guarantees as a modern API: writes that are safe to repeat, a preview before changes land, a log of what changed and a way back.

Be cautious about driving a system's screens with a bot to write into it. Our guide to RPA versus AI automation sets out when to keep a bot, extend it with an AI step or replace it with an integration.

For the first release, let the AI read from the legacy system and propose changes that a person approves. Let it write only once its proposals have held up against your test set.

A platform vendor sells a model or a product that works inside its own boundary. An AI system integrator works across the boundaries between your systems and delivers what lets the whole thing run in production. Many organisations use both.

Ask any integrator for five things at the end: the code and configuration in your repositories, a test set that reruns, the access map (which identity touches which system and with what scope), the runbook, and the monitoring that tells you when it drifts. Our guide to taking an AI pilot to production sets out the stages, and our guide on maintaining AI systems covers what happens after the build.

Good first integrations have one owner, data in a known place and a result somebody can check. The first two are 1AYM builds, and the other two are common patterns.

If your AI has to work inside systems that already run the business, bring in 1AYM. Our AI integration and automation work puts AI into the tools your teams use, such as NetSuite, Xero, Slack and Notion, and your HR and identity feeds. Every change that writes to your systems can be checked before it runs, undone if it goes wrong and traced afterwards, and it never has more access than the person it acts for.

For a workflow that needs a full production build, our Enterprise AI Platform & Agentic Workflows engagement is a fixed-scope architecture plus production build, with evaluation, human review paths and audit logging, and a runbook and handover documentation for your team. Fixed-scope work can start within a day of the scope being signed. Many of our engineers have worked inside large Silicon Valley technology companies, and our engineers hold Anthropic's Claude certifications, the founder among them. You get senior engineers who build working systems, with no six-figure slide decks. We take small fixed-scope statements of work as well as larger builds.

Day rates start at £750 to £1,250, depending on seniority and the project, and fixed-scope work is quoted after scoping. Book a 30-minute call and bring the system list. We will tell you which pattern fits and where the access risk sits. Or email enquiries@1aym.com.