“We meant to” won’t hold up in an audit.

There’s a rule in the EU AI Act that’s easy to skim past because it doesn’t sound like a rule. Article 4 requires “AI literacy.” Supervision and enforcement kick in on August 2, and it doesn’t get a lot of press compared to the high-risk stuff.

Here’s what it actually means.

If your organization uses AI in the EU, in any capacity, you have to take steps so the people using it (staff, plus contractors and vendors acting on your behalf) actually understand what the tool does, what it gets wrong, and what harm it could cause. This isn’t limited to high-risk systems. A marketing team using a chatbot counts. A support desk using a copilot counts.

Subscribe now

The tricky part is that the law doesn’t say how. No mandated training hours, no certification body, no requirement to hire an AI compliance officer. Just “to their best extent.” That flexibility sounds convenient until you realize it hands regulators discretion to judge your effort after something’s already gone wrong, not before.

Worth documenting whatever training you’re doing now. “We meant to” won’t hold up in an audit.

NOT ADVICE

The information is intended to be helpful but is in no way a substitute for seeking professional advice for your specific situation or intent. This applies to business, financial, legal, or other matters discussed herein. Please read the full DISCLAIMER

Nobody Reads the Impact Assessment. That's the Problem.

A partner at a Berlin infrastructure fund is looking at a term sheet on a Friday afternoon. The company: a sovereign cloud platform, EU-owned, EU-operated, selling itself as the compliant option once the Cloud and AI Development Act kicks in. One slide shows a hockey-stick chart. “Addressable public sector spend.” Big number. She’s spent two weeks trying to figure out if it’s real.

This is where a lot of European infrastructure investing sits today. A real law meets a founder story that ran way ahead of what the law says.

CADA publishes in the EU’s Official Journal on July 15 and takes effect August 4. It’s the centerpiece of the Commission’s Tech Sovereignty Package, adopted in early June. The goal: triple EU data center capacity in five to seven years, cut reliance on non-EU cloud and AI providers.

Here’s how it works. Four sovereignty tiers. Public bodies run their own risk assessments and decide which tier a contract needs. Level 1 just means you’re an EU entity, and the Commission has said outright that EU subsidiaries of US companies clear that easily. Level 2 wants proof of independence from third-country influence and a transparent supply chain. Level 3 wants EU ownership and control, down to citizenship requirements for personnel. Level 4, the “Strategic Autonomy Cloud” tier, is for defense: full transparency, zero third-country interference.

Now the part nobody puts in a pitch deck. The Commission’s own impact assessment says about 20% of public contracts will need Level 2. Under 10% will need Level 3. About 1%, mostly defense, needs Level 4. Everything else, the bulk of public cloud spend, clears at Level 1. AWS, Microsoft and Google’s European subsidiaries meet that bar without changing much about how they run.

Subscribe now

So the founder pitch since June has basically been: the EU just handed European cloud providers a protected market. That’s not what happened. The law hands them a protected sliver. Real, growing, but nowhere close to the bulk of public procurement. Price a Series B off “broad market capture” and the actual numbers will come in short, because most agencies have no legal reason to go past Level 1 or 2, and the hyperscalers can hit both.

That doesn’t kill the sovereign cloud thesis. It just means you underwrite it tier by tier, not off the headline. A company that can genuinely clear Level 3 or 4, real EU ownership, EU staff, demonstrable independence, is fighting for a small pool. But it’s a pool the hyperscalers can’t enter without restructuring they’ve shown zero interest in doing. That’s a real moat. It just covers maybe 10% of addressable public contracts, and none of the private sector, which isn’t bound by any of this.

There’s a second problem, and it’s the one that gets skipped when people only read the regulation. Tripling data center capacity takes serious money. CADA tries to help, faster permitting, better access to energy, land and financing, but European VC is still structurally smaller than the US market at every stage past Series A. And the Delaware flip hasn’t gone anywhere. Founders still reincorporate in the US to reach deeper capital pools. A company that flips to raise its Series C stops qualifying for the sovereignty tiers it was built to serve in the first place. That’s not a hypothetical. Several portfolio companies will face that exact choice in the next 18 months, and it runs straight against what CADA is trying to accomplish.

Subscribe now

The law builds the demand side. It does nothing for the supply side. Brussels can write four tiers into a regulation. It can’t manufacture the growth-stage capital that lets a startup clear Level 3 while competing on price with a hyperscaler that’s had fifteen years to optimize everything. CADA assumes qualified providers will just show up because the demand exists. Investors have to answer whether the supply actually shows up. Right now, that only happens if later-stage European capital gets a lot deeper, a lot faster, and that’s a harder problem than passing a procurement law.

Watch two things this year. How individual member states turn the four tiers into actual procurement guidance, because that’s where the real market gets drawn, country by country. And whether the first tenders under the new rules go to genuinely EU-native providers, or whether hyperscaler subsidiaries figure out how to check the Level 2 box without changing anything real about who owns or runs them. If that second thing happens at scale, the sovereignty premium funds are paying for today shrinks fast.

The term sheet isn’t wrong to exist. It’s wrong if it’s priced off a slide claiming 100% of public cloud spend is addressable, when the Commission’s own numbers say it’s closer to 30%, and the truly defensible piece is under 10%. Read the tier breakdown before the growth chart.

NOT ADVICE

The information is intended to be helpful but is in no way a substitute for seeking professional advice for your specific situation or intent. This applies to business, financial, legal, or other matters discussed herein. Please read the full DISCLAIMER

The companies that will have the hardest time when the rules are clarified are the ones that used the uncertainty as a reason to do nothing.

If you’re running a business in the US and trying to build a sensible AI compliance programme, you’re working without a stable target. The rules keep shifting, and they’re shifting in different directions at the same time.

There’s no federal AI law. The Biden administration’s 2023 executive order, which at least gave companies something concrete to work toward, was revoked on the first day of the Trump administration in January 2025. The replacement executive order, signed in December 2025, is primarily focused on telling states to back off rather than telling companies what to do. And the White House’s March 2026 legislative framework, which outlines what a federal AI law might eventually look like, is a recommendation to Congress, not a law.

Meanwhile, states are moving fast. Colorado, California, Texas, Illinois, and others have passed or are implementing AI-specific statutes, and more are coming. The federal government is actively trying to preempt some of those laws, but courts haven’t settled the question of whether executive orders can actually do that. So you may be complying with a state law that the federal government is simultaneously trying to nullify, and no one knows yet who wins.

This is not a comfortable place to build a compliance programme. But it’s the place you’re in, and waiting for the picture to clear is not an option. Companies that haven’t started are already behind.

Understand what enforcement actually looks like right now

The absence of a federal AI law doesn’t mean there’s no federal enforcement.

The FTC has been bringing AI-related enforcement actions since 2024 under Section 5 of the FTC Act, which prohibits unfair or deceptive acts or practices. It doesn’t need an AI-specific law to do this. Its Operation AI Comply campaign brought five cases in September 2024 alone, targeting companies that made false claims about AI capabilities, used AI to generate fake reviews, or misrepresented what their AI products could actually do. In 2025, the agency brought at least a dozen more cases along the same lines, covering companies that overstated AI sophistication, attributed capabilities to AI systems that the technology couldn’t support, and made earnings claims tied to AI tools without substantiation. The FTC’s position has been consistent across administrations: there is no AI exemption from existing consumer protection law.

The same logic applies across the regulatory stack. The CFPB has applied existing credit and consumer financial protection rules to AI-driven decision-making. The EEOC has issued guidance on AI in hiring, and the SEC has pursued AI-washing cases against public companies. State attorneys general are using broad unfair and deceptive acts and practices statutes to investigate AI-related conduct, and those statutes are powerful tools because they often allow per-violation penalties without needing to prove individual harm.

The picture is the same regardless of which agency you’re looking at: even with no federal AI law, you face real enforcement exposure from multiple directions, under legal authorities that have been in place for decades.

Read more

Plus, the In Focus piece on why the AI Act's watermarking rule asks companies to do something no technology on the market can actually do yet, and what that means if you're small and don't have a compliance team to hide behind.

Read more

The phrase “meaningful human oversight” is everywhere in AI governance right now, and it’s being used to mean two very different things.

There’s a phrase that appears in almost every AI governance document produced in the last two years: “meaningful human oversight.” It’s in the EU AI Act, in board-level AI policies, in vendor contracts, compliance checklists, and press releases from companies that have just had something go wrong.

The problem is that most organisations use it as a destination rather than a description. They write it into a policy, assign someone a job title with “AI” in it, and consider the box ticked. What they’ve actually built is a rubber-stamp process dressed up as governance.

Where the requirement comes from

The EU AI Act’s Article 14 is the most detailed legal statement of what human oversight of AI systems should involve. It applies to high-risk AI systems, and its requirements fall on both providers (the companies that build the systems) and deployers (the organisations that put them to use).

The split matters. Providers must create the technical and operational conditions for effective oversight. Deployers must assign qualified personnel with appropriate authority, competence, and support. In other words, the vendor has to build a system that can be overseen, and you have to make sure the right people are actually doing the overseeing.

The goal of human oversight is to prevent or minimise risks to health, safety, or fundamental rights. Oversight measures should match the risks and context of the system’s use, and can be built into the system by the provider or implemented by the deployer.

The Act doesn’t demand a single approach. What it demands is that the oversight is proportionate, real, and assigned to people who are actually equipped to do it.

The three things oversight persons must be able to do

Article 14 sets out what the people assigned to oversight must be able to do. They must be able to properly understand the system’s capabilities and limitations, detect and address anomalies. They must remain aware of the tendency to automatically rely on or over-rely on the system’s output (automation bias). They must be able to correctly interpret the system’s output. And they must be able to decide, in any particular situation, not to use the system or to disregard its output.

The requirement isn’t that a human can see what the AI is doing. It’s that a human can understand it, question it, override it, and actually has the practical means to do all of those things without friction. Understanding, intervening, and halting are distinct capabilities, and organisations frequently conflate them.

What automation bias is, and why it’s explicitly in the law

Automation bias is the tendency of humans to defer to an AI system’s recommendation even when they have good reason not to. It’s well documented in fields where people work alongside decision-support tools: radiology, credit underwriting, recruitment, and criminal sentencing. The pattern is consistent. When a system produces a confident output, humans tend to go along with it, even when the output is wrong.

Article 14(4)(b) of the EU AI Act specifically requires that AI providers deliver their systems in a way that oversight persons are enabled to remain aware of the possible tendency of automatically relying on or over-relying on the system’s output.

The fact that automation bias has its own named provision in the law tells you something about how seriously regulators take it. An oversight process that puts a human in the loop but doesn’t address the conditions that produce automatic deference isn’t compliant, and it won’t work.

One researcher put it plainly: “Too many people perceive human oversight as a panacea. They go, ‘If there’s a human who looks over it, then I don’t have to worry about AI anymore.’ When in reality, that of course is absolutely not true, and it just opens a whole new box of problems.”

The rubber-stamp problem

This is where most organisations currently are.

Many organisations claim human oversight but implement it as a rubber-stamp process. An operator clicks “approve” on every AI decision within five seconds without genuinely reviewing it. Regulators look at override rates: if an operator never overrides the AI, their “oversight” is not meaningful.

Think about what that means in practice. If your oversight person reviews 200 AI decisions a day and overrides zero of them, that’s not a sign that the AI is performing perfectly. It’s a sign that the oversight process isn’t functioning. A genuine review process will produce disagreements. Some of them will be edge cases. Some will be errors. If the override rate is zero, you’ve built a process that generates paperwork rather than one that catches problems.

Oversight procedures should create genuine friction. It should take a moment of reflection, not a reflexive click. That friction is the point.

The halt mechanism problem

Article 14 also requires that oversight persons be able to stop the system. This sounds obvious. In practice, it often isn’t.

A halt mechanism that requires IT intervention doesn’t meet the standard. An Article 14-compliant halt mechanism must be accessible to designated oversight persons without requiring them to call IT, submit a support ticket, or log into a separate administrative console. If the halt procedure takes more than five minutes to execute, it doesn’t meet the requirement.

I’ve spoken to organisations where the person nominally responsible for AI oversight has no ability to stop the system in question without escalating to a technical team. That’s a governance fiction. The law requires the ability to halt, which means the person doing the overseeing needs the actual authority and the actual access to do it.

What the deployer’s obligations actually involve

Under Article 26(2), deployers of high-risk AI systems must assign human oversight to persons with the necessary competence, training, and authority, as well as necessary support. Those four things are distinct, and all of them have to be present.

Competence means the person understands the domain well enough to evaluate the AI’s output. A credit officer reviewing an AI-generated lending recommendation needs enough financial knowledge to assess whether the recommendation is reasonable. A recruiter reviewing an AI-shortlisted candidate pool needs to understand what the system was optimising for and whether that’s actually what the organisation wants.

Training means the person understands how the specific system works, what its known limitations are, and what failure modes look like. Training must include case studies of AI errors in the specific domain, exercises where participants must justify their agreement or disagreement with AI outputs, and regular review of override rates. Training should be tailored to the oversight person’s role, and must be documented and refreshed when the AI system significantly changes.

Authority means the person can act on their judgment. An oversight person who has to get manager sign-off before overriding an AI recommendation, or who faces pushback when they do override it, doesn’t have genuine authority. The override mechanism has to be accessible and its use has to be culturally acceptable, not treated as a sign that the process has broken down.

Support means the person isn’t doing this alone and without resources. Adequate time, access to the system’s documentation, a clear escalation path, and a way to flag patterns rather than just individual decisions.

The “instructions for use” requirement

There’s a less-discussed part of Article 14 that has real compliance implications. Providers of high-risk AI systems are required to include human oversight measures within the “instructions for use” for the system.

This creates a direct due diligence question for any organisation buying or licensing a high-risk AI system. Do the vendor’s instructions actually address how oversight should be implemented? Do they describe the system’s limitations clearly enough that an oversight person could detect when it’s producing unreliable outputs? Do they specify what training the oversight person needs?

If the vendor’s documentation doesn’t address these things, that’s a gap you need to flag and resolve before deployment, not after something goes wrong.

What meaningful oversight looks like when it’s working

For each high-risk AI deployment, named individuals should be designated as responsible for oversight. Their mandate should include critically reviewing AI outputs, exercising override authority when warranted, initiating halt procedures when required, and completing regular oversight activity logs. These responsibilities should appear in job descriptions and performance objectives.

A few other markers of oversight that are actually functioning:

• The override rate is non-zero and tracked. Someone reviews it regularly and asks why the number is what it is.

• Oversight persons have documented training specific to the system they’re overseeing, and that training is refreshed when the system changes.

• The halt mechanism has been tested. Not described in a policy document. Actually tested, with a record of when it was tested and by whom.

• There’s a process for escalating patterns, not just individual decisions. If an oversight person notices the system is producing a particular type of error repeatedly, there’s somewhere for that observation to go.

• Oversight is treated as a substantive role, not an administrative one. The person doing it has enough time to do it properly.

A note on scope

Everything above applies specifically to high-risk AI systems as defined by the EU AI Act. That covers a specific list of use cases in Annex III: AI used in hiring and workforce management, credit scoring, educational assessment, access to essential services, law enforcement, border control, and the administration of justice, among others.

If your organisation deploys AI in any of these areas and you’re operating in the EU (or deploying to EU residents), Article 14 applies. The question isn’t whether human oversight is good practice. For high-risk systems, it’s a legal requirement, with penalties for non-compliance running up to €15 million or 3% of global turnover, whichever is higher.

For systems outside the high-risk category, the legal obligation is lighter. But the practical argument for genuine oversight doesn’t disappear. The conditions that produce automation bias don’t check which regulatory category a system falls into before they operate.

The phrase “meaningful human oversight” is everywhere in AI governance right now, and it’s being used to mean two very different things. Used honestly, it describes something specific and demanding. Used as cover, it’s a way of appearing to take responsibility without actually taking it. The gap between those two readings is where most of the compliance risk currently sits.

NOT ADVICE

The information is intended to be helpful but is in no way a substitute for seeking professional advice for your specific situation or intent. This applies to business, financial, legal, or other matters discussed herein. Please read the full DISCLAIMER

The classification question isn’t a one-time exercise.

The EU AI Act doesn’t treat all AI systems the same way. It sorts them into categories based on the risk they pose to people’s safety, rights, and wellbeing, and the category your system lands in determines almost everything: what you have to do, how much it costs to comply, and what happens if you get it wrong.

Most of the confusion about the Act comes from not understanding this sorting process. People read about prohibited AI and assume the rules apply to them. Or they assume the rules don’t apply because their product isn’t obviously dangerous. Both mistakes lead to the same place: a compliance programme built on the wrong foundation.

The four categories

Every AI system in the scope of the EU AI Act falls into one of four categories. The smallest group faces the most restrictions. The largest group faces almost none.

Unacceptable risk: banned outright. A small number of AI applications are prohibited entirely because the EU has decided no legitimate use case justifies them. These include social scoring systems that rate citizens based on their behaviour and personal characteristics, real-time remote biometric identification in publicly accessible spaces (with narrow exceptions for law enforcement), AI systems that manipulate people through subliminal techniques in ways that cause harm, and systems that exploit vulnerabilities of specific groups such as children or people with disabilities. These bans have been in force since February 2025. If your system falls into one of these categories, there is no compliance path. The activity is simply not permitted.

High risk: permitted but heavily regulated. This is where most of the Act’s compliance obligations live. High-risk systems can be used, but they must meet a demanding set of requirements covering technical documentation, risk management, human oversight, data governance, logging, and transparency. The full set of what qualifies is covered below.

Limited risk: transparency obligations only. Systems in this category don’t face the full compliance burden, but they do have to be honest about what they are. Chatbots must tell users they’re talking to an AI. Systems that generate synthetic images, audio, or video must label them as AI-generated. Emotion recognition systems must disclose when they’re being used. The obligations are lighter but real.

Minimal risk: no specific obligations. The majority of AI applications in commercial use sit here. Spam filters, AI-powered video games, recommendation engines, and most productivity tools. No specific requirements apply under the Act, though general EU law (GDPR, consumer protection rules, and so on) still does.

How a system gets classified as high risk

This is the question most organisations get wrong.

A system can become high-risk in one of two ways.

The first is if it’s a safety component of a product that already falls under existing EU product safety legislation. This covers a wide range of physical goods: machinery, medical devices, toys, lifts, vehicles, and aviation equipment. If your AI system is embedded in any of these products and performs a safety function, it’s high risk under Article 6(1) of the Act, regardless of what the AI itself does.

The second is if it falls into one of the use cases listed in Annex III. This is the list that catches most business applications, and it covers eight areas:

1. Biometrics, including remote identification systems and AI used to categorise people based on sensitive attributes like race, political opinion, or sexual orientation.

2. Critical infrastructure management, where AI influences the operation of systems like electricity, water, gas, or transport networks.

3. Education and vocational training, covering AI that determines access to institutions, evaluates students, or monitors behaviour during tests.

4. Employment, workforce management, and access to self-employment. This is one of the most practically relevant categories for most businesses. It covers AI used to recruit or select candidates, make decisions about promotion or termination, allocate tasks, or monitor performance.

5. Access to essential private and public services, including credit scoring, insurance risk assessment, emergency service dispatch, and the evaluation of benefit entitlements.

6. Law enforcement uses, covering predictive policing tools, lie detectors, and systems that assess the risk an individual poses.

7. Migration, asylum, and border control, including tools that assess travel document authenticity or the risk posed by individuals at borders.

8. Administration of justice and democratic processes, covering AI used to assist courts or influence elections.

If your system’s intended use falls into any of these areas, it’s presumed high risk. The question then becomes whether any exemption applies.

The Article 6(3) exemption

Read more

Your pilot passed. Now the real work starts. A 30-day post-pilot checklist for leaders who want it to stick.

Passing a pilot is the easy part.

I know that sounds backwards. Pilots take months; they involve procurement cycles, vendor negotiations and internal sign-offs, and when the results come back positive, everyone exhales and treats it like the hard work is done. But the pilot is a controlled environment. A small team, a scoped use case, and someone paying close attention to the outputs. The real test starts the moment you decide to scale.

Most AI deployments that fail don’t fail in the pilot. They fail in the 90 days after it. The handover from “this worked in a test” to “this is now how we operate” is where the gaps show up, and most organisations aren’t prepared for how quickly those gaps compound.

What follows is a 30-day plan for the period immediately after a pilot sign-off. It covers six areas: workflow redesign, team communication, risk monitoring, success measurement, vendor management, and data governance. It also covers something most post-pilot plans ignore entirely: what to do if things go wrong and you need to stop.

Why the post-pilot window is where deployments break

A pilot succeeds on a narrow brief. You tested whether the AI could do a specific thing in a specific context, and it could. What you didn’t test is whether your existing workflows were designed to absorb it, whether your team understands what changes and what doesn’t, or whether you have any visibility into what the system does on a bad day.

Scaling without addressing those things doesn’t spread the pilot’s success. It spreads its blind spots.

The 30-day window matters because it’s when habits form. The team is paying attention, the tool is new, and the decisions made in this period tend to stick. Get the structure right now, and you’re building on solid ground. Let it drift, and you’re correcting embedded problems six months later, which costs more in time, money and goodwill than most leaders budget for.

Week one: workflow redesign

Before anyone outside the pilot team touches the tool, the workflows need to change. This is the step most organisations skip, and it’s the reason so many AI deployments get quietly abandoned rather than formally cancelled. The tool gets bolted onto an existing process that wasn’t designed for it, creates friction, and gradually stops being used.

Workflow redesign doesn’t mean rebuilding everything. It means mapping the specific points where the AI output enters the existing process and asking whether that process still makes sense. If the AI now produces a first draft of a weekly report in 20 minutes that previously took four hours, the approval and review process probably needs to change too. If it doesn’t, you’ve saved four hours of writing time and added two hours of unnecessary checking, and the net gain is smaller than it should be.

The checklist for week one:

• Map every workflow that touches the AI output, not just the ones that were part of the pilot

• Identify where human review is genuinely needed versus where it’s been carried over from the old process by default

• Reassign the time freed up by the tool to specific tasks, with specific owners, before the tool goes live at scale

• Document the new workflow clearly enough that someone who wasn’t in the pilot can follow it on day one

• Set a single point of contact for process questions during rollout, so confusion doesn’t become rumour

Week two: team communication

The people most affected by an AI deployment are rarely the ones who had the most input into the decision to run it. That gap creates anxiety, and anxiety that doesn’t get addressed directly tends to fill itself with whatever story feels most plausible, which is usually the worst-case one.

Week two is about getting ahead of that. Not with a company-wide email that announces the rollout and thanks everyone for their flexibility, but with direct conversations that answer the questions people actually have: what is changing about my role, what is staying the same, who do I go to if something doesn’t work, and what happens if the system produces something wrong while my name is on the output?

That last question matters more than most leaders realise. If a team member doesn’t know whether they’re accountable for an AI-generated output they reviewed and approved, they’ll either over-check everything (eliminating the time saving) or under-check everything (creating risk). Neither is the outcome you want.

The checklist for week two:

• Brief every affected team directly, not just managers. People make better decisions when they understand the context

• Answer the accountability question explicitly: who is responsible for AI outputs at each stage of the process

• Create a clear and low-friction way to flag errors or unexpected outputs, and make clear it won’t be treated as a complaint

• Set realistic expectations about the learning curve. The tool will produce better outputs as the team gets better at using it, and that takes time

• Identify the people most resistant to the change and have a direct conversation rather than hoping the general briefing lands with them

Week three: risk monitoring and the rollback plan

This is the area most post-pilot plans treat as an afterthought, usually because the pilot produced clean results and it’s tempting to assume that continues. It doesn’t always. Models drift. Inputs change. Edge cases that didn’t appear in a controlled pilot appear regularly in production, and if nobody is looking for them, nobody finds them until the damage is done.

Risk monitoring at this stage doesn’t require a dedicated team or expensive tooling. It requires someone with a clear remit to look at the outputs regularly and ask whether anything has changed.

The checklist for week three:

• Assign a named owner for output quality monitoring. Not a committee, a person

• Define what a problematic output looks like before one appears, so the response isn’t improvised

• Set a weekly review cadence for the first month, dropping to monthly once the system is stable

• Log every error or unexpected output, however minor. Patterns in that log are early warning signs

• Check whether the inputs the AI is working from have changed since the pilot. New data sources, new formats, and changed internal processes all affect output quality in ways that aren’t always obvious

The rollback plan deserves its own conversation because almost nobody has one. If the deployment needs to stop, whether because of a serious error, a regulatory question, or simply because the tool isn’t performing as expected at scale, what happens? Who makes the call? How do you revert operations without chaos?

The answers don’t need to be elaborate. You need a named decision-maker, a defined trigger (what level of error rate or what type of incident warrants a pause), and a documented plan for reverting to the pre-AI process in the short term. A deployment with no exit ramp isn’t a sign of confidence. It’s a gap in planning.

Week four: success measurement

A pilot has defined success criteria. The production deployment needs them too, and they’re usually different ones. The pilot asked, “Can this work?” The production deployment asks, “Is this working, consistently, at scale, and is the return worth the ongoing cost?”

Most organisations don’t set those criteria explicitly, which means they have no basis for answering the question when it comes up in a budget review or a board meeting. “It seems to be going well” is not a defensible position.

The checklist for week four:

• Define two or three specific metrics that will tell you whether the deployment is delivering at scale. These should connect directly to the KPIs that justified the pilot in the first place

• Set a baseline now, before the data gets muddied by the rollout period, so you have something clean to measure against

• Decide how often you’ll formally review performance and who will see the results

• Build a simple dashboard or reporting process that makes the metrics visible without requiring someone to manually compile them each time

• Set a six-month review date in the diary now. Not to decide whether to cancel, but to make a considered decision about whether to expand, adjust, or consolidate based on real data

Vendor management in production

The vendor relationship changes once you’re in production. During the pilot, the vendor is motivated to be responsive, helpful, and present. Once you’re a paying customer running at scale, that dynamic shifts, and the gaps in the original agreement become more visible.

Before the end of the first 30 days, the commercial and operational relationship needs to be clearly defined.

• Confirm your SLAs in writing: uptime guarantees, response times for support requests, and what compensation applies if those commitments aren’t met

• Establish a named contact on the vendor side for operational issues, separate from the sales relationship

• Get the vendor’s model update schedule on your radar. A routine update from their side can change output behaviour overnight, and you want advance notice, not a surprise

• Understand the vendor’s own compliance and security posture, especially if you’re in a regulated sector. Their certifications and audit history matter to your regulators as well as theirs

• Agree a process for communicating changes on both sides. If your data inputs or use case changes, they need to know. If their model or infrastructure changes, you need to know

Data governance

This is the area that creates the most expensive surprises in regulated industries. Once AI is in production, data flows that didn’t exist before the pilot now exist at scale, and the compliance picture changes accordingly.

The questions to answer before the end of day 30:

• What data is the AI accessing, processing, or storing, and does that match what was assessed during the pilot?

• Has any personal, sensitive, or commercially confidential data entered a workflow it wasn’t explicitly cleared for?

• If you’re operating under the EU AI Act, UK AI governance guidance, or sector-specific regulation in financial services or healthcare, does the production deployment require additional documentation, transparency obligations, or human oversight requirements beyond what the pilot established?

• Who owns data governance for this deployment on an ongoing basis? If the answer is “whoever is closest to the problem at the time,” that’s a gap

• Do your contracts with the vendor address data residency, retention, and deletion clearly enough to satisfy your legal team and, if relevant, your regulators?

Getting data governance right in the first 30 days is far less painful than correcting it after an audit, a breach, or a client question you can’t answer.

One thing worth saying plainly

A 30-day plan implies the work is done at day 31. It isn’t. What the first 30 days should produce is a stable operating baseline: workflows that make sense, a team that understands its role, a monitoring process that will catch problems early, and a commercial and compliance foundation solid enough to build on.

From there, the questions shift from “is this working?” to “what else could this do, and should it?” That’s a better place to be making decisions from than the post-pilot enthusiasm that tends to drive the first wave of scaling choices.

The organisations that get sustained value from AI treat the post-pilot period as seriously as the pilot itself. The ones that skip it tend to find out why that matters when the next budget cycle comes around, and nobody can clearly explain what the deployment actually delivered.

NOT ADVICE

The information is intended to be helpful but is in no way a substitute for seeking professional advice for your specific situation or intent. This applies to business, financial, legal, or other matters discussed herein. Please read the full DISCLAIMER

August 2 is 45 days away. If your product generates AI content or operates any interface where EU users interact with something AI-powered, that date is your compliance problem. Article 50 of the AI Act hasn’t moved. The Digital Omnibus extended the high-risk system deadline to December 2027. It left Article 50 exactly where it was.

The EU AI Office published the final Code of Practice on transparency of AI-generated content on June 10. It’s the practical guide to what August 2 requires. The short version: chatbots and virtual assistants interacting with EU users must identify themselves as AI at the start of the interaction. Systems generating synthetic text, images, audio or video for EU users must mark that content in a machine-readable format. For deepfakes, a visible label is also required.

The machine-readable marking obligation - embedded C2PA metadata, invisible watermarks - lands slightly later. The Article 50(2) marking requirement for generative AI output applies from December 2, with grandfathering for systems already on the market before August. But the user-facing disclosure obligation is August 2, and that one is live in 45 days.

What to check now: does your chatbot or AI assistant tell EU users they’re talking to an AI at the start of the session? Does any deepfake or synthetic video output carry a visible label? Is your consent basis current against what you’re actually doing in those flows?

The Code of Practice is 30 pages and it’s on the Commission’s digital strategy site. Read it before July.

Action: Map every EU-facing AI interface in your product and confirm it meets Article 50’s user-disclosure requirements before August 2.

🟡 Heads up

🇪🇺 EU | High-risk classification consultation - 5 days left

Read more

Before any AI programme gets board sign-off, seven questions need to be answered. Most leadership teams skip all of them.

Most AI transformation programmes run into trouble for the same reason. The organisation approved a strategy without first answering some prior questions about who they are. Six months in, they find themselves looking at an AI system that technically works but creates obligations, risks, or decisions they’re not comfortable owning. By then, unwinding it is expensive.

Regulators won’t ask you these questions. The EU AI Act, the UK’s emerging AI oversight regime, and the various US federal guidance documents are built around what your AI systems do, not who you are as an organisation. What your AI systems should do, and where they shouldn’t operate at all, depends almost entirely on the answers you need to find before anyone writes a line of code or signs a vendor contract.

The questions below aren’t a workshop exercise. They’re what a board or leadership team needs to have on the record before signing off on anything significant.

Why identity questions are governance questions

Amazon spent three years building an AI hiring tool, from 2014 onwards, designed to score job applicants and surface the best candidates automatically. By 2015, the company’s own engineers had discovered the system was penalising CVs that included the word “women’s” and downgrading graduates of all-women’s colleges. The tool had been trained on a decade of historical CVs submitted to Amazon, the majority from men, and had learned to treat male candidates as the default standard for a good hire. Amazon scrapped the project by early 2017.

Amazon had public commitments to diversity and workplace equality. Nobody had asked, before the tool was built and tested internally, whether training a hiring algorithm on historical data from a male-dominated industry was consistent with those commitments. The system was working exactly as designed. The design was the problem. A governance process that asked the right identity questions upfront would have caught this before three years of engineering time went into it.

Under the EU AI Act, AI systems used in recruitment and employment decisions are classified as high-risk (Annex III). That classification triggers obligations around human oversight, data governance, and transparency. Those obligations assume your organisation has already decided it wants to operate in this space and has thought through what that means. If your values or public commitments say something different from what the system is actually doing, technical compliance doesn’t fix it.

The same applies in financial services, healthcare, legal services, and media. The rules tell you what you must do if you deploy. Whether you should deploy is a question only you can answer, and most organisations leave it implicit until something goes wrong.

The questions

What decisions are we comfortable letting AI make without a human reviewing the outcome?

Many leadership teams skip this entirely. They approve an AI programme at a high level and leave the question of human oversight to the technical teams, who reasonably interpret silence as permission to automate as much as possible. That’s not negligence on their part. It’s a predictable response to an absent instruction.

You need a position on this before any deployment decision gets made. In financial services, automated decisions about credit, insurance pricing, or fraud flags have direct regulatory consequences under GDPR Article 22 (right not to be subject to solely automated decisions) and under the EU AI Act’s high-risk framework. In HR, the same automated decision-making rules apply to hiring and performance management tools. Your position on human-in-the-loop requirements shapes every downstream design choice, and if you don’t set it, someone else will.

“We will always have a human review any decision that affects a customer’s access to our core product or service” is a position. “We believe in responsible AI” is not.

What do we stand for publicly, and does our AI strategy match it?

Your ESG commitments, your D&I statements, your published customer values. Do they constrain anything you’re planning to do with AI? If you’ve publicly committed to fair and explainable decisions, deploying a black-box model for customer triage is a problem regardless of whether it’s technically legal. The gap between stated values and actual system behaviour is exactly what investigative journalists and regulators look for first.

The EU AI Act’s transparency obligations under Article 50 now create a legal floor for certain disclosures. The reputational exposure starts well below that floor. A journalist doesn’t need to cite Article 50 to write a damaging story.

Who are our customers, and what power do we have over them?

This question makes some leadership teams uncomfortable, which is usually a sign it needs asking. Some organisations have genuine choice relationships with their customers. Others operate in contexts where the customer has limited or no alternatives, where decisions carry serious consequences, or where the population served is vulnerable in ways that matter legally and ethically.

The EU AI Act treats these contexts differently. Systems that manage or assess people in employment, education, essential services, or law enforcement are high-risk by default. The more useful question for your leadership team is sharper than the regulatory classification: if your customers can’t easily go elsewhere, and a wrong decision significantly affects their life or livelihood, your AI programme needs more oversight and caution. That’s true whether or not the regulator has caught up with your specific use case yet. Regulation tends to follow harm. You don’t want to be the case study.

Where does our liability actually sit?

AI systems create legal exposure that many leadership teams haven’t mapped properly. Under GDPR, you remain the data controller regardless of which third-party AI vendor you’re using. Under the EU AI Act, if you deploy a general-purpose AI model in a high-risk context, you take on obligations previously reserved for developers. Product liability law in both the EU and UK is moving toward treating AI outputs as products, which creates exposure most legal teams haven’t fully worked through yet.

If the answer to this question is “our vendor indemnifies us,” check that indemnity carefully before relying on it. Most vendor contracts don’t cover the scenarios where liability is actually likely to arise. I’ve seen organisations sign enterprise AI contracts where the indemnity clause, read carefully, covers almost nothing that matters.

What won’t we do, and have we written it down?

Prohibited practices under Article 5 of the EU AI Act include social scoring by public authorities and manipulation of vulnerable groups. These are absolute bans with no compliance pathway. The more useful question for most commercial organisations is the softer version: what AI applications are you capable of deploying but have decided you won’t?

A media company that decides it won’t use AI to generate synthetic content without disclosure has made a governance decision, not just a product decision. A financial services firm that decides it won’t use AI to price insurance products based on inferred behavioural data (even where that inference is technically legal) has made a governance decision. These decisions need to be written down, owned by someone senior, and revisited when strategy changes.

Without this list, the default answer to every “can we do this?” question is yes, because nobody has formally said no. That’s how organisations end up surprised by their own AI systems.

How will we know when an AI system is doing something we didn’t intend?

This belongs in the governance conversation before it gets delegated to the technology team. AI systems drift. Models trained on historical data start producing different outputs as the world changes. A hiring tool trained on five years of successful employee data starts screening out good candidates the moment the labour market shifts. A fraud detection model trained before a recession starts flagging legitimate behaviour that simply looks different from the pre-recession norm.

Your governance structure needs to specify who is responsible for monitoring each deployed AI system, what they’re watching, what threshold triggers a review, and who has the authority to pause or pull a system if something looks wrong. The EU AI Act requires this for high-risk systems. The standard is worth adopting broadly regardless, because an AI system running unchecked creates reputational and legal consequences that aren’t confined to systems the Act formally classifies as high-risk.

If this decision made the front page, would we be comfortable explaining it?

Old question, new context. The test works because it forces specificity. “Our AI hiring tool screens out candidates who haven’t followed a linear career path, because our training data reflects our existing workforce” is a defensible position if you’ve thought it through, disclosed it, and built human review into the process. It becomes very hard to explain if you haven’t done those things, and you’re explaining it to a journalist rather than a regulator.

Reporters covering AI failures in 2025 and 2026 are specifically looking for the gap between what organisations claim their AI does and what it actually does. Close that gap in the boardroom, not in a press statement.

Getting the answers on the record

These questions don’t need a separate governance workstream or a six-week consulting engagement. They can be addressed in a single board or leadership team session before an AI programme is approved. What matters is that the answers are documented, attributed to the people who gave them, and referenced when specific deployment decisions come up later.

The organisations that get into trouble aren’t usually the ones that made bad decisions. They’re the ones that made no decision at all, left the questions implicit, and then found themselves defending choices nobody formally owned.

If your leadership team can answer these questions with enough specificity to be held to account for the answers, your AI strategy probably reflects who your organisation actually is. If the answers are vague enough that nobody would be embarrassed by them, they’re not answers yet.

NOT ADVICE

The information is intended to be helpful but is in no way a substitute for seeking professional advice for your specific situation or intent. This applies to business, financial, legal, or other matters discussed herein. Please read the full DISCLAIMER

🇬🇧 UK | 8 days to have a data protection complaints process

The Data (Use and Access) Act 2025 added Section 103: a statutory requirement for all data controllers to maintain a formal comp…

Read more

AI risk assessment for managers - a step-by-step workshop for non-technical teams

There’s a job that almost every mid-sized organisation has quietly handed to people who weren’t asked if they wanted it: AI gatekeeper. Someone has to say yes or no when a team member wants to start using an AI writing tool, or an AI scheduling assistant, or an AI that reads CVs. In most companies right now, that someone is a mid-level manager with no technical background, a full diary, and no training whatsoever for the decision they’re being asked to make.

I’ve started thinking about what a genuinely useful one-hour workshop for that person would look like. Not a compliance lecture. Not a slide deck about large language models. Something that would actually change how they make the next approval decision.

Here’s what I’d build.

Read more

On June 2, President Trump signed a new AI executive order. Two weeks after the White House killed a near-identical order under pressure from tech executives, a narrower version went throug…

Read more

Forget Industry Readiness. Who's Asking About the Regulators?

On May 8, the European Commission published draft guidelines on AI transparency obligations. Eighty-six pages covering how companies must …

Read more

The FTC settled with Cox Media Group and two smaller marketing firms for just under $1 million this week. The charge: CMG told clients its AI service could target ads using conversations ca…

Read more

Read more

Issue 04 is now available: AI governance in HR and Hiring

Most agencies using AI to screen candidates have not run a bias audit. Most have not mapped where candidate data goes when it hits a third-party LLM. Most have not built the contestation routes the UK’s DUAA required from February 2026.

And that’s just the hiring side.

AI tools used to monitor placed workers, allocate tasks, evaluate performance, or influence contract renewals sit in exactly the same high-risk category under the EU AI Act as CV screening tools. Annex III covers both. The obligations, risk management, human oversight, audit trails, candidate and worker notification, apply to the full employment lifecycle, not just the point of hire.

The ICO’s March 2026 recruitment ADM report named 16 organisations that have since committed to change how they operate. The New York Comptroller’s audit found at least 17 instances of potential non-compliance at companies DCWP had already reviewed and cleared. Both reports looked at hiring. The next wave of regulatory attention is likely to look further along the employment chain.

The AI Governance Playbook’s HR edition covers what the rules require across the EU, US, and UK, for agencies and in-house teams running the process, and for the founders building the tools.

The PDF is linked below [if you are a free subscriber, you can upgrade to access the report.]

Previous Reports…

1. AI Regulation for Creators - Spring 2026

2. AI Governance in EdTech - Spring 2026

3. AI governance in FinTech

Note that this briefing is for informational purposes only and doesn’t constitute advice of any kind. For questions specific to your work, talk to a qualified lawyer in your jurisdiction.

Here is the link ….

Read more

The ICO’s consultation on automated decision-making closes in eight days, at 23:59 on May 29.

Two editions ago, this was in “Heads up” with 22 days to go. It’s here now because eight days go…

Read more

Three questions every business leader should ask before going all-in on AI

There’s a pattern I keep seeing in boardrooms right now. Someone presents a slide deck showing what a competitor is doing wit…

Read more

If your app lets users post things and an AI decides what stays up, you're regulated. Here's what that means in the US, UK and EU.

If your product lets users post things, you’re probably already doing…

Read more

The EU Digital Omnibus deal closed on May 7. After months of failed trilogues, the European Parliament and Council reached a provisional agreement. A lot changed. But one thing didn’t: if y…

Read more