Most UK mid-market businesses now have at least one AI deployment in production. Most do not have the audit trail, governance documentation, or regulatory accountability to defend it.
This is not a future problem. The compliance landscape that AI deployments now sit inside has tightened materially in the last eighteen months, and the next eighteen months will tighten it further. Boards that have been told their AI engagements are compliant should — politely, urgently — find out who decided that, on what basis, and whether that decision would survive a regulatory inspection. In a meaningful number of cases, it will not.
I founded Cybix to help UK businesses move AI into real operations. What I did not anticipate, two years in, is how often the engagements Cybix is now asked to recover are not technical recoveries. They are compliance recoveries — AI systems that work fine but cannot be defended. This article is for the boards and operating committees that have not yet had this conversation, and who probably need to.
The compliance landscape has changed
Three regulatory shifts have happened in parallel, and most mid-market AI deployments were scoped before they all landed.
The EU AI Act came into force in August 2024 and its prohibitions and high-risk obligations are now phasing in. UK businesses that sell into the EU, employ EU-based staff, or process EU-resident data are within scope, regardless of where the AI itself runs. The Act introduces specific obligations on transparency, human oversight, and post-deployment monitoring that most production AI systems do not currently meet.
The Information Commissioner’s Office has tightened its expectations on AI under UK GDPR. Models trained on personal data, agents that make decisions affecting individuals, and systems that retain user inputs in any form are now subject to scrutiny that, candidly, did not exist when most current deployments were specified.
Sector regulators have moved independently. The FCA has been increasingly explicit about AI accountability in financial services. The MHRA has published guidance on AI as a medical device. Ofcom and the CMA are both watching AI uses in their domains. None of them are accepting “the model decided” as an answer.
At Cybix we now treat compliance as a build-time concern, not a deployment-time concern. The reason is simple: by the time you find out a regulator is interested, retrofitting compliance into a live AI system is expensive, slow and sometimes structurally impossible.
The risk classes Cybix is already seeing
Across the engagements Cybix has been called into recover, the same handful of risk patterns recur.
Model bias in regulated decisions. AI systems making or influencing credit decisions, insurance pricing, hiring shortlists, medical triage or benefits eligibility have all triggered regulatory questions in the UK in the last year. Most of those systems have no documented bias testing, no demographic monitoring, and no rollback plan. The deployment was specified to optimise for an operational metric and went live before anybody asked the protected-characteristic question.
Sensitive data leaking through LLM logs. A surprising number of production deployments using language models log every prompt and every output, in plain text, to an unrestricted log destination. Those logs contain customer PII, internal financial data, and increasingly, regulated health or legal content. Log access is rarely scoped to the same standard as the underlying production data. The regulators are starting to notice.
Unaccountable agentic systems. Multi-step AI agents that take actions across systems are particularly hard to defend, because there is no single decision point to audit. Without explicit per-step logging and a human-readable explanation trail, the business cannot answer the basic regulatory question: who decided this, and why.
Supplier chain opacity. A mid-market AI deployment typically depends on three to seven third-party vendors — model providers, vector databases, embedding APIs, monitoring tools, RAG components. Most contracts do not address regulatory accountability cleanly. When a regulator asks who is responsible for a specific decision, the answer is too often a diagram, not a name.
Data residency drift. AI suppliers move infrastructure. Personal data that was processed in the EU last quarter may be processed in the US this quarter, with no notice and no contractual breach. Most deployments have no monitoring for this and no remediation plan.
Each of these risks is fixable in principle. None of them are fixable cheaply once the system is live and the audit is on the calendar.
Why this requires engineering, not policy
The temptation, when faced with a compliance gap, is to fix it with policy. Write a governance framework. Appoint a Head of AI. Run a workshop. Update the privacy notice.
These are necessary and they are not sufficient. AI compliance is, ultimately, an engineering property of the system. Either the audit trail exists or it does not. Either the bias testing runs or it does not. Either the prompts are versioned or they are not. Either log access is scoped or it is not. No amount of policy fixes a system that was not built to be compliant.
This is where Cybix’s positioning has shifted in the last year. Where most AI consultancies treat compliance as a wrap-around — a separate workstream, a separate document, a separate deliverable — Cybix engineers compliance into the build. Audit logging is a first-class feature in every Cybix engagement. Bias monitoring runs from day one. Prompt versioning is a deployment requirement. Log access is scoped before the model goes live. The Cybix model is, in effect, that a system which cannot be defended in front of a regulator is not finished, regardless of what it can do operationally.
It costs more upfront. It costs catastrophically less when something goes wrong.
What every UK board should ask this quarter
If you are sitting on a UK mid-market board with one or more AI deployments in production, here is the short list worth asking your CTO, CIO or AI lead before the next meeting.
Can we produce, on demand, a complete decision trail for any individual AI-driven decision made in the last 90 days?
Have we run documented bias testing against protected characteristics on any AI system that influences decisions about people?
Where do our LLM input and output logs live, who has access to them, and have they been reviewed against our data classification policy?
Do we know which third parties are in the data flow of every AI deployment, and where each of them processes data?
If a regulator wrote to us next week asking about a specific automated decision, who would answer — and would we be confident in that answer?
If your team cannot answer four of these five quickly, the AI deployments in your business are sitting on a compliance position you have not actually evaluated. The right time to fix that is now, while the regulators are still in scoping mode. The wrong time is the morning the letter arrives.
At Cybix, this conversation is now the second most common one we have with new clients. The first is about delivery. The second, increasingly, is about defending what was delivered — and the Cybix answer is the same in both cases: build the system so it can be operated and defended, from day one.
—
Dan Spence is the CEO of Cybix, a London-based AI consultancy that helps UK and international businesses move AI into live operations and keep it defensible. The Cybix engineering team — drawn from former Apple and Google language-model engineers alongside compliance, automation, recruitment and software specialists — has built compliance-by-design into Cybix engagements across banking, healthcare, telecoms, retail, oil and gas, and fashion. Cybix measures success by operations automated, audit trails intact, and regulators answered. More at cybix.ai.
