Oct 9, 2026
The hard part of connecting AI to your systems is no longer the engineering
Connecting AI to your systems has never been easier, yet 58% of leaders say they are still not ready, and the reasons have stopped being technical ones.
Why is connecting AI to your systems still so hard?
Connecting AI to your core systems and processes comes apart in one of four places, and usually in some combination of them.
The technical setup. Far easier than most plans assume, which is why the section below is the shortest one here.
Assurance and the law. Proving a supplier is safe, and answering what the regulator asks.
Adoption. Whether anyone opens the thing twice.
The first is largely solved, and that is what most plans have not caught up with. In our experience working inside these estates, IT is not the limitation any more.
Why has the technology stopped being the major bottleneck for AI adoption?
CRM, service desk, data warehouse and document store, each with MCP access, connecting to your AI
The first reason is that the industry agreed a standard. The Model Context Protocol gives a model one consistent way into the places where the work happens, and the company that wrote it handed it to the Agentic AI Foundation, with the major platforms behind it. This means that your CRM, your service desk, your data warehouse and your document store will most likely have MCP access already, so there is a documented route in.
Accenture found 58% of UK and Ireland executives saying they are not ready to connect AI agents to their core systems, and puts it down to the complexity of their legacy IT estates. The second change answers that: the last mile got cheap. Someone competent with an AI coding assistant builds a working connector in an afternoon, and some of what your teams already use was built that way. Vibe coding gets plenty of criticism, and on this job it has removed the excuse. Ask your own engineers what a read-only connector to your CRM would take them now, and the answer usually comes back in days.
How do you pick the best provider for AI solutions in the market?
You ask for the assurance work, because that is where the real limitation sits now. There are a lot of AI startups, and a buyer looking at four of them cannot tell from the websites which one has put the work in. The questions are the dull ones:
ISO 27001 for information security, and if it is in progress, how far it has got and who is auditing
ISO 42001, the standard written for managing AI
Cyber Essentials Plus, and the system security checks behind it
SOC 2, if they sell into the United States
Who holds the keys, where your data physically goes, and what happens to it when the contract ends
The vendor security assessment now runs on top of the normal software review, and it asks better questions than procurement ever asked about software: can this be wrong, would we know, what is logged, who can overrule it. Underneath all of that is UK data protection law. The moment a model can reach a system holding personal data, the questions the Information Commissioner's Office asks start to apply: what is your lawful basis, how much of the data does the model need, and did you assess the risk before you started rather than after.
A provider might hold one of these or several, and the aim is a balanced match for the data you are trusting them with. For instance, Unloq is Cyber Essentials Plus certified and working towards ISO 27001, ISO 42001 and SOC 2. For the best protection, that combination is widely considered the strongest.
What are the risks of connecting your data to an LLM?
Without permissions everyone sees everything; with permissions checked on every query each person sees their own. Once an AI model is connected to your systems, the risk shifts to what it does with that access.
One risk is a wrong answer that sounds right. A model that can read your CRM and your data warehouse can still give you a confident, well-written answer that is wrong, and unless every answer is logged, nobody finds out. So before you connect anything, ask the supplier how they handle hallucinations, what gets logged, who can override an answer, and whether there is a record when somebody does.
The other is access, and most projects get to it last. If the model can read every record regardless of who is asking, then anyone who can ask it a question can see everything it can see. It needs the controls every other route into the business already has: single sign-on, permissions checked on every query, and an audit trail somebody can read afterwards. In our experience, the question that stops these projects comes from whoever signs off the risk, and it is usually a version of "what can it see, and who said it could?"
Why do teams stop using an AI tool a few weeks after launch?
The same figure twice: one traceable to its query, document and page, one not traceable
Usually because they cannot see where its answers come from. People will not act on a number they cannot trace, and in our experience that decides more deployments than accuracy does. A tool that is right nine times in ten and shows where each answer came from gets used. A tool that is right a bit more often and cannot explain itself gets opened twice and then left, because the first time somebody has to defend one of its numbers in a meeting, they go back to the spreadsheet they already trust.
You can test for this in ten minutes. Take one answer the system gave somebody last week and work backwards from the number: the query that produced it, the document it came from, the page. Time how long that takes. If it runs past a minute, or needs the person who built the tool in the room, the answer cannot be checked and the tool will not survive its first disagreement. Run the test before you buy, and again ninety days after you deploy, because the second result tells you whether the licence gets renewed.
Making answers traceable takes longer to build than the connector does, and it is what Unloq is built around: every answer carries the plan it followed, the query it ran, and the documents it used, down to the page and the excerpt.
Why does the same question get different answers from different systems?
How many active customers? CRM says 1,204, finance 1,890, operations 940. A traceable answer only helps if everyone agrees on what it is counting. Every system you connect brings its own vocabulary. Your CRM holds one view of an active customer, finance holds another, and operations counts a lapsed account differently again, each for good reasons in its own context. A model reaching all three gets three answers to one question and no way of knowing which one you meant.
MCP can carry data between systems, but it cannot make them agree on what the data means. Those shared definitions are what Unloq builds, across the curated tables you already have and the documents that never made it into those tables, so an active customer means one thing in every answer. You do not have to model the whole business before any of it is useful. The definitions still have to be agreed by your people, and that part of the work is yours.
If you want a second read on where your own estate is strong and where it is thin, bring us a question your business argues about. We will show you what answering it properly takes: the definitions it rests on, the evidence underneath it, and what the platform does when it cannot be sure.
