AI Integration Services: How to Connect AI to the Systems You Already Run

Most AI projects do not fail because the model is wrong. They fail at the seams - the points where the model has to read from your CRM, write to your ticketing system, respect your permissions, log its decisions, and behave predictably when an upstream API returns a 503. That work is integration, and it is where AI integration services earn their fee.

This guide explains what AI integration services cover, how to scope one without burning six months on a proof of concept that never ships, what the work typically costs in the UK mid-market, and what to look for in a partner. It is written for CTOs, heads of operations, and engineering leaders who are past the "should we use AI" stage and need the next system in production.

What AI integration services actually do

AI integration is the engineering work that connects a language model, embedding model, or ML service to the systems where your business already runs - your CRM, ERP, helpdesk, data warehouse, document store, identity provider, and customer-facing applications. The model itself is rarely the hard part. GPT-4o, Claude Sonnet, and Gemini 2.5 are all commodity APIs now. The hard part is everything around them.

A realistic AI integration scope covers six things:

• Authentication and identity - service accounts, OAuth flows, scoped tokens, and respecting the permissions of the human on whose behalf the AI is acting. If your AI assistant can see documents the user cannot, you have a data breach waiting to happen.
• Data access and retrieval - connectors to your sources of truth, vector stores for unstructured content, structured queries for relational data, and hybrid retrieval where both matter.
• Orchestration - the control flow that decides which model to call, when to call a tool, how to handle failures, and where to escalate. This is where frameworks like LangChain, LlamaIndex, or n8n earn their keep, and where bespoke code is often justified.
• Write-back and side effects - the actions the AI is allowed to take. Creating a HubSpot ticket, updating a Salesforce opportunity, posting to Slack, triggering a Zapier workflow. These need idempotency, audit trails, and circuit breakers.
• Evaluation and monitoring - automated evals against a golden set, production logging, drift detection, cost monitoring. Without this you cannot tell if a model upgrade has improved or regressed your system.
• Governance - PII handling, retention rules, refusal patterns, and the audit logs your compliance team will eventually ask for. Under UK GDPR, automated decision-making that has legal or similarly significant effects on individuals carries specific obligations - see the ICO's guidance on AI and data protection.

A vendor who only talks about prompts and models is selling you a demo. A vendor who talks about all six is selling you a system.

The integration patterns that come up most often

Across mid-market projects, four integration patterns cover roughly 80% of the work.

RAG over your own content

Retrieval-augmented generation grounds a model in your documentation, knowledge base, policy library, or product catalogue. The integration work is the pipeline: ingesting source documents, chunking, embedding, storing in a vector database (pgvector, Pinecone, or Weaviate), and exposing a retrieval API the model can call. The interesting decisions are about hybrid retrieval (combining vector search with BM25 or metadata filters), re-ranking, and handling updates to source documents without rebuilding the whole index.

AI inside a workflow automation

A model is one node in a longer automated pipeline. A support ticket arrives in Zendesk, gets classified by a model, routed to the right queue, drafted with a suggested reply, and held for human review. Tools like n8n, Make, and Zapier handle the orchestration; the integration is connecting them to the model provider, your data, and your downstream systems. This is usually the cheapest, fastest, and most reliable pattern for back-office automation.

Conversational interfaces over multiple systems

An internal assistant that can answer "what is the renewal date on the Acme contract, when did we last raise prices, and who is the account owner?" needs tool-calling against your CRM, contract store, and pricing history. The integration work is defining the tool surface, writing reliable schemas, and handling the cases where the model picks the wrong tool or hallucinates an argument.

Predictive or classification models in production

Lead scoring, churn prediction, document classification, fraud signals. These usually need a small ML model rather than an LLM, plus the pipeline to train it, deploy it behind an API, monitor its predictions, and retrain on a schedule. Integration here looks more like MLOps - feature stores, model registries, and CI/CD for models.

How to scope an AI integration project that actually ships

The single biggest predictor of whether an AI project reaches production is scope discipline at kickoff. The pattern that works:

Start with one workflow, one business outcome, one user group. Not "AI for customer support" - that is a programme. "Auto-draft replies to billing queries in Zendesk for the EMEA team, reviewed by an agent before sending" is a project. The first has no edge; the second has a measurable before-and-after.

Write the success metric before you write any code. "Reduce average handle time on billing tickets by 30% within 90 days of launch, with quality score maintained at 4.2 or above." If you cannot write that sentence, you do not have a project, you have a hope.

Inventory the integration surface honestly. List every system the project touches, who owns it, what the auth model is, whether the API is documented, and whether anyone has integrated with it recently. The systems nobody wants to talk about - the legacy AS/400, the bespoke ERP, the Excel sheet on a shared drive - are where projects die. Surface them in week one.

Design for the failure modes. What happens when the model API is down? When the CRM is rate-limited? When the document store returns nothing? When the user asks something out of scope? A production-grade integration handles all four. A demo handles none.

Plan the rollout, not just the build. Who tests it? Who trains the users? Who owns the runbook when it breaks at 3am? Who decides when to upgrade the model? These questions decide whether the system is still running six months later.

What AI integration services cost in the UK mid-market

Pricing varies more by scope than by vendor, but the ranges are reasonably consistent.

Discovery and architecture (£8k-£20k, 2-4 weeks). A fixed-fee engagement that produces a technical design, integration map, evaluation plan, and costed build proposal. Worth doing as a standalone phase before committing to a build - it surfaces the awkward systems and lets you commission the build with confidence.

First production build (£25k-£120k, 8-16 weeks). Most mid-market AI integrations land here. The range depends on the number of systems integrated, whether RAG is involved, the complexity of the orchestration, and the evaluation rigour required. A single-system workflow automation with a model in the middle sits at the lower end. A RAG-grounded assistant integrated with a CRM, a document store, and a ticketing system sits at the upper end.

Multi-agent or platform-scale builds (£100k-£400k, 4-9 months). Systems where multiple AI components coordinate, where the AI is customer-facing at scale, or where the integration touches half a dozen systems. Reserved for organisations that have already shipped a smaller AI project and know what they want next.

Ongoing operation (£3k-£15k per month). Most clients retain their build partner for monitoring, evaluation, prompt and model updates, incremental features, and incident response. Running an AI system without an operations layer is the equivalent of deploying a web app and never patching it.

Token costs are usually the smallest line item. A well-designed RAG system serving 10,000 queries a month on GPT-4o costs roughly £200-£600 in model spend. Anyone telling you to worry about token costs before you worry about integration costs has the priorities backwards.

In-house, agency, or platform: who should build it

Three viable paths, each with a clear shape.

In-house build. Right when you have a strong engineering team with spare capacity, a long-term AI roadmap that justifies hiring, and a tolerance for the 6-12 months it takes to build the first system well. Wrong when AI is one of fifteen priorities and the team is already at capacity. Hiring a single "AI engineer" into a team that has never shipped AI rarely works - they spend their first six months building plumbing that an experienced agency would have done in six weeks.

Agency or specialist consultancy. Right when you want the first system in production in 8-16 weeks, you want the integration patterns informed by other clients' mistakes, and you are comfortable with the agency operating the system on retainer until your team is ready to take it over. Wrong when you want to build deep in-house AI capability from day one - though the better agencies do knowledge transfer explicitly.

Platform or product (Microsoft Copilot, Salesforce Einstein, HubSpot Breeze). Right when your need maps cleanly to what the platform offers and you are already deep in that ecosystem. Wrong when you need bespoke retrieval over your own content, when you need to integrate systems the platform does not natively support, or when you need control over the model, prompt, and evaluation harness. Platforms are excellent for the 60% of use cases they cover; they are frustrating for the 40% they do not.

The pragmatic answer for most mid-market organisations is hybrid: use the platform features where they fit, commission an agency to build the integrations the platform cannot, and grow the in-house capability over 18-24 months by working alongside the agency rather than replacing them on day one.

What good looks like: a checklist for evaluating providers

When you are shortlisting AI integration partners, ask for evidence on these points. The answers separate practitioners from pitch decks.

• Show me a system you built that is still running 12 months later. Anyone can ship a demo. Operating a system through model upgrades, schema changes, and shifting business requirements is the actual skill.
• How do you evaluate model outputs? The answer should mention a golden set, automated evals run on every change, and a process for human review of edge cases. "We test it manually" is not an answer.
• How do you handle UK GDPR and data residency? Look for a clear position on data processing agreements, sub-processor management, regional model endpoints (Azure OpenAI UK South, AWS Bedrock EU), and how PII is handled in prompts and logs.
• What does your handover look like? Documentation, runbooks, access to source code, evaluation suites, and a knowledge-transfer plan. If the answer is "we keep the IP," walk away.
• What is your position on model lock-in? A serious partner builds with an abstraction layer that lets you swap GPT-4o for Claude or Gemini without rewriting the system. Lock-in to a single provider is a commercial risk.
• Who runs it after launch? If the answer is "you do, good luck," you are buying a build, not a system. Ongoing operation matters.

Frequently asked questions

How long does an AI integration project typically take?

For a well-scoped first integration, expect 8-16 weeks from kickoff to production. The first two to three weeks are discovery, architecture, and integration mapping. Weeks four to twelve are build and iteration, with working software demonstrable from week four or five. The final two to four weeks cover evaluation, user acceptance testing, and rollout. Projects that try to compress this into four weeks usually skip evaluation and end up in production with no way to tell if the system is working. Projects that stretch beyond five months are almost always suffering from scope creep rather than genuine complexity.

What is the difference between AI integration and workflow automation?

Workflow automation connects systems and moves data between them using deterministic rules - when X happens, do Y. AI integration adds a probabilistic component: a model that classifies, summarises, generates, or decides as part of the flow. In practice the two overlap heavily. A modern customer support workflow might use n8n for orchestration, a language model for classification and drafting, and Zendesk and Slack as the systems of record. The integration work covers both the deterministic plumbing and the AI-specific concerns of evaluation, prompt management, and refusal handling.

Do we need a data warehouse before we can do AI integration?

Not always. RAG systems work directly against document stores. Workflow automations work against transactional systems. Conversational assistants call APIs directly. You need a warehouse when the AI use case is analytical - predictive scoring, cohort analysis, forecasting - or when the data you need is scattered across systems and needs unification first. For most first AI integration projects, you can ship without a warehouse and revisit the question when the second or third use case demands it.

How do we handle GDPR when our data goes to a model provider?

Three things matter. First, choose a model endpoint with appropriate data residency and contractual terms - Azure OpenAI, AWS Bedrock, and the enterprise tiers of OpenAI and Anthropic all offer no-training-on-your-data commitments and EU or UK regions. Second, minimise PII in prompts where possible through redaction or tokenisation. Third, document the processing in your records under Article 30 and update your privacy notice. The ICO has published specific guidance on AI and data protection that is worth reading before you scope the project, not after.

What happens if the model provider changes their API or pricing?

This is why serious integrations are built with an abstraction layer between your application code and the model provider. Libraries like LiteLLM, or a thin internal wrapper, let you swap providers with a configuration change rather than a rewrite. Pricing changes happen - OpenAI has cut prices on most models several times since 2023, and Anthropic and Google have followed - but breaking API changes are rare and usually well-telegraphed. The bigger risk is model deprecation; build your evaluation harness so you can re-test on a new model version in hours, not weeks.

Can we start small and expand later?

Yes, and this is the right approach for almost every mid-market organisation. Pick one workflow with a clear before-and-after metric, ship it in 8-12 weeks, operate it for three months, learn what broke and what worked, then commission the next one. The organisations that try to launch an "AI platform" in their first six months almost always end up with an expensive framework and no production users. The organisations that ship one useful system, then another, then another, end up with a platform by accident - and a team that knows how to operate it.

Who owns the system after the agency leaves?

You should. A well-structured engagement transfers source code, documentation, evaluation suites, runbooks, and credentials to your team. The agency may continue to operate the system on retainer because that is operationally efficient, not because you are locked in. Before signing, confirm in writing that the IP transfers to you, that you have full access to all source repositories from day one, and that there is a clear off-boarding process. Any agency that resists these terms is not selling you a system, they are selling you a dependency.

How do we measure ROI on an AI integration?

Tie the project to a single operational metric measured before and after. Average handle time, conversion rate, cycle time, error rate, cost per ticket, hours saved per week. Measure for at least 90 days post-launch to account for the learning curve and any drift. Soft benefits - employee satisfaction, customer experience scores, capacity unlocked for higher-value work - matter, but they should support the hard number rather than replace it. If you cannot tie the system to a hard number after 90 days, that is a signal to either re-scope or shut it down.

Getting started

The fastest path from "we should do something with AI" to a system that is genuinely changing how the business runs is to pick one workflow, scope it tightly, ship it in a quarter, and operate it for long enough to learn what the next one should be. The technical work is well-understood now; the discipline of scoping and shipping is what separates organisations with AI in production from organisations with AI in slide decks. If you are weighing up where to start or want a second opinion on a scope already in flight, the AI Advisory team builds and operates systems like these for UK mid-market clients - get in touch and we will work through your shortlist with you.

Further reading

Sources referenced for context not directly cited in the body:

Ready to put this into production? book a discovery call.

• ICO guidance on AI and data protection