The UK's Statutory Code on AI and Automated Decision-Making becomes legally enforceable in May 2026. If you use AI to score leads, rank prospects, or automate any part of your outreach pipeline, the ICO can now hold you to account. This isn't guidance anymore. It's law.
What changed and why it matters for your pipeline
The Information Commissioner's Office (ICO) published its Code of Practice on AI as a statutory instrument. That's a quiet way of saying it moved from "best practice" to "you must comply or face regulatory exposure." The shift is more than procedural. A statutory code carries direct legal weight in tribunal and court proceedings, meaning non-compliance becomes evidence of a breach. For founders running B2B outbound, the practical impact lands in three places: recruitment, credit assessment, and customer profiling. If your tooling scores an inbox, ranks a lead by likelihood to convert, or segments prospects by firmographic data, you're profiling. The ICO now has teeth to ask how you did it—and crucially, they can demand an audit trail of your model's logic, training data provenance, and the specific steps you took to prevent bias. The burden of proof shifts: you must demonstrate fairness, not merely assert it.
This is where the operational reality bites. Most sales stacks are a patchwork of third-party enrichment APIs, predictive scoring models, and CRM automations. Under the new code, you are accountable for the outputs of every tool in that chain, even if you didn't build the algorithm. You need documented human oversight at each decision point—someone who can explain why a lead was deprioritised or why a prospect received a particular outreach sequence. We built MiraReach to keep a human in the loop precisely because this was coming. The EU AI Act set the tone. The UK just followed with a statutory instrument that doesn't need parliamentary debate to carry weight. The practical takeaway: if your pipeline relies on automated decisions that materially affect individuals, you now have a legal obligation to map, document, and justify those decisions. That's not a compliance exercise—it's a competitive filter. Teams that adapt will build trust and defensibility; teams that ignore it will face regulatory exposure and reputational damage.
The three areas that will trip you up
Most sales teams aren't running credit checks. But the profiling angle is broad enough to catch standard outbound operations. Here's where we see the risk concentrated:
- Lead scoring models that rank prospects by behavioural data or firmographic fit
- Inbox scoring tools that predict deliverability or engagement probability
- Automated personalisation that drafts messages based on inferred attributes like company size or tech stack
If any of these feed into decisions about who you contact, how you contact them, or what you say, the Code applies. The ICO's position is that individuals have a right to know when AI is making decisions about them. That includes the decision to send them a cold email. The practical consequence is that your stack's "black box" logic—proprietary scoring weights, model training data, or even simple threshold rules—now becomes auditable documentation. You will need to explain, on request, why a specific prospect received a particular score and how that score influenced outreach. That is not a one-time privacy policy update; it is a shift in how you architect your sales infrastructure. The second trip-up is the distinction between solely automated decisions and those with "meaningful human involvement." A rep clicking "send" on a pre-generated list does not count as human oversight if the substantive decision—who to contact and what to say—was made by the model. The ICO has signalled that rubber-stamping automated outputs fails the test. You need a documented review point where a human actually evaluates the model's recommendation before it becomes an action. The third area is data provenance. Your lead scoring likely relies on third-party enrichment (firmographics, technographics, intent data). Under the Code, you are responsible for the accuracy and lawfulness of that underlying data, not just your use of it. If a vendor's dataset contains outdated or inferred attributes that drive a negative scoring decision, you carry the liability. This means contractual audits of your data suppliers and a clear internal record of where each attribute originated. Most teams will discover their current stack fails at least one of these three tests—and the May 2026 deadline is closer than it looks.
What the Code actually requires from you
The statutory Code doesn't ban AI use in sales. It requires transparency, accountability, and human oversight. Concretely, that means three things you can action this quarter.
First, document your AI tools. Write down what each one does, what data it processes, and what decisions it influences. You don't need a 40-page privacy impact assessment. A one-page inventory per tool is enough to show you've done the work. But be precise about the distinction between tools that merely assist (e.g., drafting subject lines) and those that make autonomous decisions (e.g., suppressing leads or prioritising accounts). The ICO will treat those categories differently, and your documentation should reflect that hierarchy of risk.
Second, build a human review step into any AI-driven outreach. The Code explicitly favours systems where a person can override or veto automated outputs. If your stack auto-sends emails based on AI scoring, you're already outside the spirit of the law. If a human presses send, you're inside it. The nuance here is that the review must be meaningful, not performative. A reviewer who rubber-stamps 500 AI-generated emails in a batch hasn't exercised oversight in any defensible sense. You need a documented checkpoint where the reviewer can actually assess the reasoning behind a recommendation, not just confirm the email looks grammatically correct.
Third, be ready to explain your logic. The ICO can ask how your scoring model works, what data it uses, and how you prevent bias. If you're using a black-box vendor tool, you need to know enough about it to answer those questions. That's a procurement issue, not just a compliance one. When you renew any AI vendor contract, ask for model documentation, training data summaries, and bias-testing results. If the vendor can't provide them, that's a red flag for your legal exposure. The Code effectively shifts the burden onto you as the controller, regardless of where the model was built. You can't outsource accountability, only the computation.
How this changes your cold email setup
We wrote about the EU AI Act's August 2026 enforcement and the 7% global turnover fines for high-risk systems. The UK Code is less punitive on paper, but it's more immediate. May 2026 is closer than August, and the ICO has a track record of enforcing data protection law with fines that sting. The key distinction is that the UK Code doesn't just regulate the model's output; it regulates the entire decision-making pipeline, including the human review layer. That means your "human-in-the-loop" process must be substantive, not performative. If a sales rep merely clicks "approve" on a lead score without the ability to override or interrogate the underlying rationale, the ICO could view that as a rubber-stamp, not meaningful oversight. You need documented evidence that a human can and does challenge the system's recommendation.
For your outreach stack, the practical changes are manageable. If you use tools like Apollo, Clay, or Instantly to enrich and score leads, check whether they expose the logic behind their scoring. If they don't, you can't document it. That's a compliance gap. More importantly, you need to map where automated decision-making actually occurs. A simple enrichment lookup that pulls a company's employee count is likely low-risk. But a tool that auto-segments prospects into "high intent" or "likely to churn" categories, and then triggers a sequence based on that classification, is making a decision with legal effect. That's where you need transparency. Request model documentation from your vendors now, not in April 2026. If they can't provide it, consider whether the convenience outweighs the regulatory exposure.
If you're building your own scoring models in-house, keep the feature set simple. The more variables you feed in, the harder it is to explain. A model that scores on company size, industry, and recent hiring activity is defensible. One that scrapes social media sentiment and predicts personality traits is not. The ICO's guidance emphasizes that you must be able to explain why a particular prospect received a low score, not just how the model works in aggregate. That means you need feature-level attribution. If your model uses 40 variables, you'll struggle to articulate why prospect A scored 20 and prospect B scored 80. Simplify your feature set, and you'll have a defensible audit trail. Also, consider your data retention policy for training data. If you're using historical outreach responses to retrain a model, you're processing personal data for a new purpose. That requires a lawful basis under UK GDPR, separate from your original outreach purpose. Document that basis now, or you'll be retrofitting compliance under pressure.
What we'd do next
Start with an audit of every AI tool in your sales stack. Write down what it does, what data it touches, and whether a human can override its output. That's a half-day job, not a project. But go deeper than the spreadsheet. Map each tool against the Code's specific provisions: which ones qualify as "automated decision-making" that produces legal or similarly significant effects? Which ones merely assist a human decision? The distinction matters because the Code's most onerous transparency and review obligations attach to the former. If you're using a lead-scoring model that automatically deprioritises certain prospects, that could easily fall within scope. If you're using a CRM that merely flags suggested next steps for a rep to accept or reject, you're likely on safer ground — but only if the human genuinely exercises independent judgement, not rubber-stamping.
Then check your email sending flow. If anything sends without a human pressing the button, change it now. The Code's emphasis on human oversight is the clearest signal we've seen that the regulator wants people in the loop, not just policies on paper. That means documenting when and how the human review happens, not just that it exists. A sales rep who clicks "approve" on a batch of 200 personalised emails without reading them is not meaningful oversight. You need a workflow that forces genuine engagement — perhaps a queue that surfaces the reasoning behind each recommendation, or a threshold above which a manager must sign off. The regulator will likely ask for evidence of this process, not just a screenshot of a toggle.
If you want to see how MiraReach handles this, we built the platform so every email waits for your approval. No auto-send, no black-box scoring you can't explain. Give MiraReach a try and close the compliance gap before May 2026.
— Mira