We built ALLDOQ - a medico-legal SaaS that processes sensitive case documentation used in HM Courts proceedings. That context shapes how we think about AI implementation. When your system touches legal evidence, clinical records, or any data that lives inside a regulated workflow, the compliance architecture isn't an afterthought. It's the architecture.
What follows is a structured look at the questions that get skipped in most UK AI implementation engagements - and what the answers need to cover.
GDPR and the "we use OpenAI" problem
OpenAI's enterprise API (like most major LLM providers) processes data in US-based data centres. Under UK GDPR - retained post-Brexit with amendments - you're permitted to transfer personal data to the US under the UK-US data bridge framework, provided the recipient is on the approved list and you've documented the basis for transfer in your Record of Processing Activities.
That's manageable. The problem is that most AI implementation projects don't document it. The API call gets made, the data goes somewhere in AWS us-east-1, and nobody has written down why that's lawful, what data categories are involved, or what happens if the vendor changes their data processing agreement.
// minimum required documentation for LLM data transfer
1. Legal basis for processing (Art 6 / Art 9 for special category)
2. Transfer mechanism (adequacy decision / UK-US bridge / SCCs)
3. Data minimisation: what fields actually need to reach the model?
4. Retention: does the vendor log prompts? For how long?
5. DPA signed with vendor, covering processor obligations
Points 3 and 4 are the ones most commonly ignored. On data minimisation: you almost never need to send a full name and date of birth to get a useful summarisation output. Pseudonymisation at the application layer - before the API call - is not complex to implement and significantly reduces your exposure. On retention: OpenAI's zero data retention (ZDR) option exists for enterprise customers. Most implementations don't use it because nobody asked.
Data residency: when "UK only" is a real requirement
For some sectors - government contracts, NHS-adjacent work, certain financial services - "data must not leave UK jurisdiction" is a hard requirement, not a preference. The practical options for AI implementation in the UK under this constraint are:
option A: Azure OpenAI with UK South region
Microsoft's Azure OpenAI service allows data residency selection. UK South (London) is available for GPT-4 class models. Data stays in-region. This is the most practical path for enterprise deployments with hard residency requirements.
option B: Self-hosted open models
Running Llama 3, Mistral, or similar on your own infrastructure (or a UK-based VPS) gives you full control. Capability is lower for general tasks but adequate for many specific, narrow use cases. Latency and cost profiles are different - worth modelling for your specific workload.
option C: Purpose-built UK AI infrastructure
Providers like Aleph Alpha (European-headquartered) or Cohere (with EU data processing agreements) offer alternatives to the US-centric default. Capability trade-offs vary significantly by use case.
The right choice depends on your actual requirements - most organisations don't need full data residency and are better served by well-documented transfers to a major provider. But "we just use the OpenAI API" is not a residency strategy; it's the absence of one.
Regulated industries: the integration problem
AI implementation in regulated UK industries - legal, financial services, healthcare, insurance - has a specific integration challenge that generic automation tools don't handle well: your AI system needs to act inside workflows that have their own audit, validation, and regulatory reporting requirements.
An AI agent that can read case notes and draft correspondence is useful. An AI agent that drafts correspondence and sends it, without a human-in-the-loop checkpoint, inside a system where outbound communications are subject to FCA or SRA rules - that's a different category of thing. One of these requires careful integration design. The other requires you to have read the regulator's current guidance on AI-assisted communications.
// integration that actually touches your stack
When an AI agent connects to your real systems - your CRM, your document management, your ERP - it's not an integration in the sense of "a webhook." It's a new actor with write access to production data. That means:
- →Permission scoping: the agent should have the minimum access it needs, not admin credentials
- →Audit logging: every action the agent takes should be attributable, timestamped, and retrievable
- →Rollback paths: for any write operation, there should be a defined process for reversing it when the agent gets it wrong
- →Rate and scope limits: hard constraints on how much the agent can do in a given period, to bound the blast radius of failures
The "AI wrapper" vs. the real integration
A large proportion of what's sold as "AI implementation" in the UK is a wrapper: your data goes to an LLM, a result comes back, the result is displayed somewhere. That's useful for content generation, summarisation, and classification tasks where the output is for a human to review and act on.
It becomes insufficient the moment the AI output triggers an action without human review - and that's where most of the interesting, valuable use cases live. Automated document routing, compliance flag generation, contract anomaly detection with downstream workflow triggers. These aren't wrappers; they're systems. They require the same engineering discipline as any other system that touches production data.
The question to ask any AI implementer: does your system output to a human, or does it act on a system? The answer determines what the engineering, compliance, and testing requirements actually are. Many agencies have only built the former. They'll agree to build the latter without fully understanding the difference.
ICO guidance and what's actually enforceable
The ICO's guidance on AI and data protection (updated in 2025) is more specific than it used to be. Key points relevant to implementation:
Automated decision-making that produces legal or similarly significant effects on individuals requires a documented lawful basis under Article 22, and individuals must have the right to request human review. If your AI system is making decisions that affect customers - credit, insurance, access, prioritisation - this applies to you, and "the model decided" is not a compliant response to a subject access request.
Explainability is not required to be technical - you don't need to expose attention weights - but you do need to be able to give a "meaningful explanation" of how a decision was reached. For complex models, this means building an explanation layer into the system at implementation time, not retrofitting it when a complaint arrives.
None of this is a reason not to implement AI. It's a reason to implement it properly.