If you’re a CTO or CDO based outside the European Union, you’ve probably glanced at headlines about the EU AI Act and filed it under “European regulatory stuff.” Maybe you figured your legal team would deal with it, or that it simply doesn’t apply to a company headquartered in the US, Australia, or Singapore.
That assumption is wrong, and it’s going to be expensive for the companies that don’t correct it in time.
The Scope Surprise
The EU AI Act has extraterritorial reach. If your AI system’s output is used in the EU – even if your servers are in Virginia and your company is incorporated in Delaware – you’re potentially in scope. This applies if you have European customers, European employees whose data feeds AI systems, or products and services available in EU markets.
Sound familiar? It should. This is the same playbook as GDPR, which theoretically only applied to EU data but in practice became the global privacy standard because it was easier to build one compliant system than maintain separate ones for different regions.
The EU AI Act is following the same trajectory. And the companies that figure this out early will spend less money and face less disruption than the ones that treat it as somebody else’s problem until a regulator comes knocking.
What the Act Actually Requires
I’m going to skip the legal jargon and explain this the way I’d explain it to a CTO over coffee.
The EU AI Act classifies AI systems into four risk tiers. The tier your system falls into determines what obligations you face.
Minimal risk
Most AI systems fall here. Think spam filters, AI-powered search, recommendation engines for content. Minimal obligations – basically just don’t be deceptive about the fact that AI is involved.
Limited risk
Systems that interact directly with people. Chatbots, for example. The main requirement is transparency – users need to know they’re interacting with an AI system. Deepfakes and AI-generated content also fall here with labelling requirements.
High risk
This is where it gets serious. High-risk classification applies to AI systems used in:
- Employment and HR (recruitment tools, performance evaluation, workforce management)
- Credit scoring and financial services
- Critical infrastructure (energy, transport, water)
- Education (admissions, grading, proctoring)
- Law enforcement and border control
- Public services and benefits administration
High-risk systems face mandatory requirements: risk assessments before deployment, human oversight mechanisms, transparency obligations (you need to be able to explain how the system makes decisions), data governance standards for training data, detailed technical documentation, and ongoing monitoring after deployment.
If you’re running AI in HR, lending, insurance, or critical infrastructure, pay close attention. Most enterprise AI that touches actual business decisions falls into this category.
Unacceptable risk
Some AI applications are simply banned. Social scoring systems (ranking citizens based on behavior, like China’s social credit system). Real-time biometric surveillance in public spaces (with narrow exceptions for law enforcement). Manipulative AI that exploits vulnerable people. Emotion recognition in workplaces and schools.
If you’re not doing any of these things, you don’t need to worry about this tier. But check your vendors – you’d be surprised what some HR tech and surveillance products are doing under the hood.
The Timeline You Need to Know
This isn’t theoretical future regulation. It’s happening now, on a staggered schedule.
Already in effect (February 2025): Prohibited AI practices are banned. If you’re using any of the unacceptable risk applications, you should have stopped already.
August 2025: Obligations for general-purpose AI models kick in. If you’re building or deploying foundation models or large language models, transparency and documentation requirements apply. This matters for companies using models from OpenAI, Anthropic, Google, or others – depending on how you’re deploying them, you may have obligations.
August 2026: High-risk system requirements are fully enforced. This is the big one. If you’re running AI systems classified as high-risk, you need risk assessments, documentation, human oversight, and monitoring in place by this date.
That gives you roughly fifteen months from now for the high-risk requirements. Fifteen months sounds like a lot until you consider the scope of work involved.
What This Means Practically for a CTO
Let me translate the regulatory requirements into technical work items. Because that’s what this is – work. Significant work.
You need an AI inventory
You cannot govern what you cannot see. And in most organisations, AI is everywhere – embedded in vendor products, built by individual teams, running in notebooks that nobody’s reviewed in months. The first step is cataloguing every AI system in your organisation. Not just the ones your team built. The ones in your HRIS, your CRM, your marketing automation, your customer support tools. All of them.
If you’ve been following the shadow AI conversation, you know this is harder than it sounds. Teams adopt AI tools without going through procurement. Individuals use ChatGPT for tasks that technically involve customer data. Getting visibility into all of this is a project in itself.
You need risk classification for each system
Once you have the inventory, classify each system according to the EU AI Act risk tiers. This isn’t just a legal exercise – it requires technical understanding of what each system does, what data it uses, and what decisions it influences. Your legal team can’t do this without you.
You need documentation
For high-risk systems, you need technical documentation covering: the intended purpose, how the system works, what data it was trained on, how it was tested and validated, known limitations, and instructions for human oversight. If you’ve been building AI systems without this kind of documentation (and let’s be honest, most companies have), you’re looking at a retroactive documentation effort that will take months.
You need human oversight mechanisms
High-risk AI systems cannot operate as pure black boxes making autonomous decisions. There needs to be a human in the loop – or at minimum, a human on the loop with the ability to override, intervene, or shut down the system. This has design implications. If your AI system was built to automate a decision end-to-end, you may need to re-architect it to include human review steps.
The GDPR Playbook Is Repeating
When GDPR was announced, plenty of non-European companies said the same things they’re saying about the EU AI Act. “It’s a European regulation.” “Our legal team will handle it.” “We’ll deal with it when we have to.”
Then GDPR became the de facto global standard. Companies built GDPR-compliant systems because it was cheaper than maintaining separate standards for different markets. California passed CCPA. Brazil passed LGPD. The global regulatory floor was set by Brussels.
The same pattern is emerging with AI regulation. Canada’s Artificial Intelligence and Data Act draws on EU AI Act concepts. Brazil’s AI framework reflects similar risk-based approaches. Various US states are pursuing their own AI legislation that echoes the EU’s classification system. Building to EU AI Act standards now means you’re ready for whatever regulatory framework arrives in your home market.
The CDO and CAIO Angle
Here’s something that doesn’t get discussed enough: the EU AI Act is creating an enormous amount of work that sits squarely in the domain of the Chief AI Officer or Chief Data Officer.
Data quality requirements. Training data documentation. Bias auditing. Model governance. Monitoring for drift and degradation. This isn’t legal work. It’s data leadership work. And it’s the kind of work that requires someone with both technical depth and organisational authority to drive.
If your organisation is debating whether it needs a CAIO or a CDO with AI governance responsibilities, the EU AI Act may tip the balance. The compliance requirements are substantial enough that they need dedicated leadership, not a part-time effort from someone whose day job is something else.
An AI governance framework that you build proactively is cheaper, more effective, and less disruptive than one you build reactively under regulatory pressure. Every time.
What To Do If You’re Starting From Zero
If you’re reading this and realising you haven’t started any of this work, don’t panic. But do start. Here’s a practical sequence.
Month 1: Build the AI inventory. Survey every department. Identify every AI system, including vendor-provided AI features embedded in existing tools. You will find more than you expected. Document what each system does, what data it uses, and what decisions it influences.
Month 2: Classify risk. Map each system to the EU AI Act risk tiers. Work with legal counsel to confirm classifications, but lead the effort from the technology side because you understand what the systems actually do.
Month 3-4: Prioritise high-risk systems. For any system classified as high-risk, begin the documentation and compliance work. Start with the system that has the highest business impact or the most direct exposure to EU users.
Month 5-6: Build processes. Create standardised processes for AI risk assessment, documentation, and human oversight. These processes should apply to new AI deployments going forward, not just existing systems. You want compliance to be built into your development lifecycle, not bolted on after the fact.
Ongoing: Monitor and update. The regulatory landscape is still evolving. Enforcement guidance will clarify ambiguities. New interpretations will emerge. Assign someone to track developments and update your approach accordingly.
The Cost of Inaction
The EU AI Act includes fines of up to 35 million euros or 7% of global annual turnover for the most serious violations. Those numbers are designed to get the attention of large multinationals, and they do. But the bigger cost isn’t the fine – it’s the disruption.
Imagine discovering six months from now that your AI-powered recruitment tool is classified as high-risk and you have no documentation, no risk assessment, and no human oversight mechanism. You either have to shut it down while you build compliance infrastructure, or you continue running it and accept the regulatory risk. Neither option is good. Both are avoidable with advance planning.
IBM’s analysis of the EU AI Act provides a useful overview of the business implications if you want a second perspective on the compliance requirements.
This Is a Leadership Problem, Not a Legal Problem
The most important thing I can say about the EU AI Act is this: it’s a technology leadership challenge disguised as a regulatory requirement. The legal team can advise on interpretation. The compliance team can build checklists. But the actual work – inventorying systems, classifying risk, documenting models, designing oversight mechanisms, building governance processes – that’s engineering and data leadership work.
If your organisation’s response to the EU AI Act is to hand it to the legal department and move on, you’re going to end up with a compliance framework that doesn’t reflect how your AI systems actually work. And that’s worse than having no framework at all, because it creates a false sense of security.
Own this. Lead it. Do it right. Your future self, and your future compliance auditors, will thank you.
Ben is a full-time data leadership professional and a part-time blogger.
When he’s not writing articles for Data Driven Daily, Ben is a Head of Data Strategy at a large financial institution.
He has over 14 years’ experience in Banking and Financial Services, during which he has led large data engineering and business intelligence teams, managed cloud migration programs, and spearheaded regulatory change initiatives.