The ICO's Code of Practice on AI is now a statutory instrument. From May 2026, any B2B operation using AI for recruitment, credit assessment, or customer profiling has to align with the Code or face regulatory exposure. This is no longer guidance you can bookmark and forget. It is law, and it applies to the scoring models and enrichment pipelines most outbound teams run without thinking.
What actually changed on May 1
Before May, the Code was advisory. You could read it, nod along, and carry on running your lead scoring in Apollo or your enrichment in Clay without documenting a thing. Regulators could point to it. They could not enforce it.
That gap closed. The Code is now a statutory instrument under the Data Protection Act. The ICO can investigate, issue enforcement notices, and levy fines against organisations that process personal data through automated systems without meeting the Code's standards.
The practical trigger is automated decision-making. If your system scores a prospect, ranks them, filters them out, or profiles them without meaningful human review, you are in scope. If a human reviews every output before it affects the person, you are probably not.
Most outbound stacks sit somewhere in the middle. That is the problem. A sequence tool that auto-enrols contacts based on a scoring threshold is making a decision, even if a rep technically "owns" the account. A Clay table that enriches and routes leads by inferred fit is profiling, even if nobody calls it that. The Code does not care what you name the workflow. It cares whether an automated process materially determines how a person is treated, and whether you can evidence the safeguards around it.
What changed in practice is the burden of proof. Under the advisory regime, you could argue intent after the fact. Under the statutory regime, you need records before the ICO asks: the logic behind the decision, the significance of the outcome for the individual, and the human oversight actually applied. "A rep glances at it" is not oversight. Documented, meaningful review is.
For small teams, the exposure is not the fine itself. It is the enforcement notice that forces you to rebuild your pipeline logic mid-quarter, with no revenue running through it while you do.
Where outbound teams are exposed
We have looked at how teams actually run their pipelines. Three patterns come up again and again.
Lead scoring that nobody audits. You build a model in HubSpot or a custom script. It assigns points based on job title, company size, tech stack, engagement history. A rep sees a score of 87 and treats it as a green light. The score influenced a decision about a person. Was that decision automated? If the rep would have contacted them anyway, maybe not. If the score was the reason they got the email and someone else did not, you have a documented decision made by a system.
Enrichment that infers things. Tools like Clay, Apollo, and Clearbit do not just append a job title. They infer seniority, budget authority, likely pain points. Some of that inference is probabilistic. If you use it to segment or prioritise, you are profiling. The Code requires you to tell people you are doing it, and to give them a way to object.
AI-drafted emails that never get read. The Code does not care that a human pressed send. It cares whether a human meaningfully reviewed the content. If your workflow is "AI drafts, rep clicks approve without reading," you have automated the decision to contact. That is the exposure.
We wrote about the ICO's AI Code when it was still guidance. The scoring model liability piece covered the £20k fine risk. That risk is now enforceable.
The compliance check we would run this week
You do not need a lawyer to do a first pass. You need two hours and a spreadsheet.
List every tool in your outbound stack that touches personal data. For each one, answer three questions.
- Does it make a decision about a person without a human reviewing that specific decision?
- Does it infer or predict something about a person that you then act on?
- Can the person see what you inferred, and can they object?
If you answer yes to the first two and no to the third, you have a gap. That gap is what the Code targets.
Two details in the framing matter more than they first appear. The first is the word specific. A human reviewing a sample of outputs, or reviewing the system's design once at procurement, does not satisfy the test. The review has to attach to the individual decision before it takes effect. The second is that the Code reaches inferences, not just decisions. A lead score, a churn prediction, a "likely to buy" flag — if you route a person differently because of it, that is in scope, even if no automated system ever rejects anyone outright.
So the spreadsheet needs a fourth column: what happens to the person if the inference is wrong. That column tells you where to spend your time. A mis-scored cold prospect is a wasted send. A mis-scored inbound lead who gets deprioritised is a person who never hears back, and that is the kind of outcome the Code is built around.
The fix is usually not ripping out the tool. It is adding a human checkpoint that is real, not theatrical. A rep who reads the AI draft and edits it before sending is a human checkpoint. A rep who clicks approve on 200 emails in a batch is not. The distinction is whether the person has the time, context and authority to change the outcome. If they do not, the checkpoint is decoration.
We built MiraReach so that no message sends without a human pressing the button. That was a product decision before it was a compliance one. It turns out the two align.
What this means for your prospect lists
Your list is now a compliance artefact. If you enriched it with inferred data, you need to know what you inferred and why. If you scored it, you need to know what the score meant and who reviewed it. That means the provenance of every field matters: whether a job title was scraped, purchased, or guessed from a pattern, and whether a "likely to buy" flag was a human judgement or a model output. Under an enforceable code, "we don't track that" is not a defence — it is an admission that no one was accountable for the decision.
We covered the prospect list liability angle after July 2026's compliance fines. The same logic applies here, but the mechanism is different. Fines punish an outcome after the fact; an enforceable code shapes the process you are expected to have followed beforehand. The practical question shifts from "was this list lawful?" to "can you reconstruct how each decision on this list was made?" If the answer depends on a tool you no longer use or a colleague who has left, the list is effectively undocumented.
The teams that will struggle are the ones running high-volume, low-touch outbound, where scoring and enrichment happen automatically and no one inspects individual records. The ones that will be fine are the ones already doing manual review, already documenting their ICP logic, already treating prospects like people rather than rows. The gap is not budget or headcount — it is whether a human can explain any given entry on request.
If you are in the first group, you have a choice. Change the workflow, or accept the risk. The Code does not offer a third option.
What we would do next
Run the three-question check on your stack. For every tool that touches a prospect or customer record, ask: does it make a decision, or does it merely assist one? Is that decision consequential — does it determine who gets contacted, scored, ranked, or excluded? And can a human meaningfully intervene before the outcome takes effect? Document what you find. The documentation itself matters: under an enforceable code, being able to show your reasoning is often as important as the reasoning being correct.
If you are using AI to score or enrich, add a human review step that actually reviews. A nominal approval click is not oversight; it is theatre, and it will not survive scrutiny. The reviewer needs enough context to disagree with the model, and the authority to act on that disagreement. If you cannot build that, consider whether the tool belongs in your pipeline at all.
Then work through the operational gaps most teams discover only after an audit request:
- Inventory and ownership. Assign a named owner to each automated decision point. Shared responsibility is no responsibility.
- Logging. Record inputs, outputs, and the human decision at each review gate. Without a trail, you cannot demonstrate compliance after the fact.
- Vendor terms. Confirm what your AI vendors do with your data and whether their processing sits inside your compliance boundary or outside it.
- Review cadence. Set a recurring date to re-examine each tool as models, prompts, and use cases drift.
The legislation is live. The enforcement window is open. The teams that treat this as a product problem rather than a legal one will move faster — because the fix is usually a workflow change, not a legal one.
If you want to see how MiraReach handles human-in-the-loop outbound, give MiraReach a try.
— Mira