
Summary
The EU AI Act (Regulation (EU) 2024/1689) is directly applicable across all 27 Member States and already reaches non-EU companies whenever their AI outputs are used in the EU. Prohibited practices and AI literacy obligations have been enforceable since February 2025, high-risk obligations phase in through 2027, and top-tier fines reach 35 million euros or 7 percent of global turnover. CIOs, CROs, and legal teams share accountability for documentation, risk classification, conformity, monitoring, and enforcement response.
What This Article Covers
-
What the EU AI Act Actually Is (and Why It Lands on Your Desk): How the Act works as a directly applicable regulation, who falls in scope, and the four-tier risk model.
-
Compliance Timeline: What Is Already in Force and What Comes Next: The compliance timeline from February 2025 prohibitions through 2027 high-risk deadlines and the Digital Omnibus deferral.
-
Prohibited AI Practices: What Must Be Switched Off Now: The seven Article 5 prohibitions already in force and the 2026 bans on nudifier tools and AI-generated CSAM.
-
High-Risk AI Classifications: Does Your AI Stack Qualify?: How Annex III categories, profiling rules, and provider versus deployer roles determine if your AI stack is high-risk.
-
What the EU AI Act Requires of CIOs: Documentation, Conformity, and Technical Governance: The documentation, conformity assessment, logging, and Quality Management System duties CIOs must operationalize.
-
What the EU AI Act Means for CROs: Risk Classification, Monitoring, and Liability: How CROs integrate the Act's risk categories, monitoring, and liability into the enterprise risk framework.
-
What Legal Teams Must Understand: Enforcement, GDPR Overlap, and Product Liability: What legal teams must understand about enforcement, GDPR overlap, and product liability.
-
What a Compliant AI Governance Program Looks Like in Practice: What a practical, compliant AI governance program looks like in operation.
-
EU AI Act: Frequently Asked Questions from CIOs, CROs, and Legal Teams: Answers to common questions from CIOs, CROs, and legal teams on scope, vendors, fines, and first steps.
What the EU AI Act Actually Is (and Why It Lands on Your Desk)
The most expensive mistake being made right now is treating the EU AI Act as a distant piece of European lawmaking that someone will worry about later. It is already partly in force, it already reaches companies with no office in Europe, and it already assigns responsibility to people who never built a single model. If you sit in the CIO, CRO, or legal seat, this is an operational governance obligation on your desk today, not a future legislative abstraction.
A regulation, not a directive: what that means for enforcement
Regulation (EU) 2024/1689 entered into force on 1 August 2024, and the word "regulation" matters. Unlike a directive, which each Member State must translate into its own national law, a regulation is directly applicable across all 27 Member States without national transposition. There is no waiting for your local legislature to act, and no patchwork of country-by-country implementations to hide behind. The obligations apply as written, and enforcement authorities in every Member State can act on them directly.
Who is in scope: providers, deployers, importers, and non-EU companies
Here is the misconception that does the most damage: "We're not an EU company, so this doesn't apply." Scope extends to non-EU organizations whenever their AI outputs are used in the EU, regardless of where the company is headquartered or incorporated. Physical presence in Europe is not the trigger. The Act also regulates both providers (the builders) and deployers (the users), alongside importers and distributors. Buying a "compliant" vendor tool does not transfer all obligations to that vendor, since deployers carry their own duties around human oversight, monitoring, and record-keeping.
The four-tier risk model in plain language
The Act sorts AI into four tiers: prohibited practices that are banned outright, high-risk systems carrying the heaviest documentation and oversight requirements, limited-risk systems subject to transparency obligations, and minimal-risk systems left largely untouched. CIOs, CROs, and legal teams share accountability across documentation, risk management, oversight, and enforcement response. Building that shared operating model early is the point of a mature AI governance program.
Compliance Timeline: What Is Already in Force and What Comes Next
One of the most damaging misconceptions about the eu ai act is that enforcement sits comfortably in the future. It does not. Parts of the regulation have been legally binding since early 2025, and any organization waiting for every delegated act and standard to be finalized is already behind on obligations that are live today. Here is the timeline you can take straight into a board or leadership meeting.
February 2025: prohibited practices and AI literacy obligations are live
Since 2 February 2025, the prohibited AI practices in Article 5 have been enforceable. That includes social scoring, untargeted facial-image scraping, biometric categorization for sensitive attributes, and emotion recognition in workplaces and schools. If you are running or piloting anything in these categories, governance is not the answer. Decommissioning or redesign is. The same date brought the Article 4 AI literacy obligation into force, which is a binding legal requirement to build AI awareness across your staff, not a best practice you can defer.
August 2025: general-purpose AI model rules apply
From 2 August 2025, the obligations for general-purpose AI (GPAI) models apply, and the associated governance and penalty framework became active. This affects providers of foundation models and large language models, and it matters for any enterprise embedding third-party GPAI into its stack. Existing GPAI models placed on the market before this date have until 2 August 2027 to reach full compliance.
August 2026 onward: the Act is broadly applicable
The AI Act became generally applicable on 2 August 2026, subject to the phased exceptions in the regulation and the 2026 AI Omnibus. Organizations should now treat the governance, enforcement, and role-mapping framework as operational, while tracking the later dates that apply to high-risk systems.
How the AI Omnibus changes high-risk deadlines
The AI Omnibus entered into force on 27 July 2026. It moves the main obligations for Annex III standalone high-risk systems to 2 December 2027 and the obligations for Annex I high-risk systems embedded in regulated products to 2 August 2028. Those dates provide implementation time, but they do not postpone obligations that are already applicable, including prohibited practices and AI literacy. See the official European Commission framework for the current timeline. Building an evidence-driven AI governance program now is what keeps the inventory, classifications, evidence, and ownership ready for each phase.
Prohibited AI Practices: What Must Be Switched Off Now
Most of the EU AI Act phases in over several years, but the prohibitions do not. Since 2 February 2025, Article 5 has made a specific set of AI practices illegal across the EU, and the top penalty tier reaches €35 million or 7 percent of global annual turnover, whichever is higher. This is not a future compliance project. If your organization is running any of these systems today, they need to come out of production now.
The seven core prohibitions under Article 5
Article 5 bans the following outright:
-
Subliminal or manipulative techniques that materially distort behaviour and cause or are likely to cause significant harm, for example a system that nudges vulnerable users into risky financial decisions without their awareness.
-
Exploitation of vulnerabilities based on age, disability, or socioeconomic situation, such as profiling financial distress to push manipulative credit offers.
-
Social scoring by public or private entities that evaluates people over time and leads to detrimental or unjustified treatment in unrelated contexts.
-
Biometric categorisation that infers sensitive attributes such as political opinion, religious belief, sexual orientation, or race.
-
Untargeted scraping of facial images from the internet or CCTV to build or expand recognition databases.
-
Emotion recognition in workplaces and educational settings, except for medical or safety purposes.
-
Real-time remote biometric identification in public spaces for law enforcement, with narrow, strictly regulated exceptions.
Workplace emotion recognition and biometric scraping: higher risk than most realize
There is a persistent misconception that high-risk and prohibited AI only concerns extreme, sci-fi scenarios. The emotion recognition ban proves otherwise. A call-centre platform that analyses employee tone or facial expressions to score performance, or a classroom camera monitoring student attention, is already illegal unless it serves a genuine medical or safety function. These are mainstream enterprise tools, often bundled into HR analytics and workforce monitoring suites. This is why an immediate inventory review matters: many organizations do not realize they are running prohibited systems until they map what their vendors' features actually do. A structured AI governance program starts by surfacing exactly these blind spots.
Upcoming 2026 bans on nudifier tools and AI-generated CSAM
A further prohibition takes effect on 2 December 2026. "Nudifier" tools that generate sexualised imagery from existing photos, and any AI systems that create or facilitate AI-generated child sexual abuse material, must be withdrawn or remediated by that date, subject to the same €35 million or 7 percent fines. Any existing tool or pilot touching these categories requires immediate review and, in most cases, decommissioning rather than redesign.
For the full legal text, see Article 5 of the EU AI Act.
High-Risk AI Classifications: Does Your AI Stack Qualify?
Here is the uncomfortable truth for most enterprises: you are almost certainly already running high-risk AI, and you may not have classified it as such. The eu ai act does not reserve the high-risk label for exotic or futuristic systems. It reserves it for the mundane, business-critical tools that regulated companies deploy every day. The question is not whether high-risk AI applies to you, but how many of your systems qualify and whether you have documented that fact.
Annex III categories CIOs and CROs must know
Annex III automatically classifies AI systems across a defined set of domains as high-risk: safety components in critical infrastructure, employment, education, access to essential services, law enforcement, migration, and biometric identification. Critical infrastructure covers AI acting as a safety component in critical digital infrastructure, road traffic, and the supply of water, gas, heating, and electricity. This is a purpose-based list. If your system is used for one of these functions, it is high-risk regardless of how the vendor markets it.
Employment, credit scoring, and insurance: the high-risk categories most enterprises are already running
This is where the recognition moment tends to land. CV screening, candidate shortlisting, performance evaluation, promotion decisions, and workforce allocation tools are explicitly high-risk. So are credit scoring and lending decisions, insurance underwriting and risk scoring, and systems determining access to housing, social security, or public benefits. Financial services firms running automated credit models and manufacturers using AI-assisted hiring are, in most cases, already deployers of high-risk AI. The "advanced analytics" framing does not change the classification.
Profiling rules that catch more systems than organizations expect
The profiling provisions widen the net considerably. AI systems that profile individuals through automated processing to assess work performance, economic situation, health, preferences, reliability, behaviour, or location are always considered high-risk. That sweeps in fraud detection, customer risk scoring, and behavioural analytics tools that many teams never thought of as regulated AI. Remember too that a single system with multiple functions may need feature-by-feature assessment.
How to determine if you are the provider, the deployer, or both
Providers carry obligations under Articles 9 to 16: risk management, data governance, technical documentation, conformity assessment, and CE marking. Deployers carry separate obligations under Article 26, including human oversight, logging, and monitoring. Vendor CE marking does not satisfy your deployer duties, and if you substantially modify or repurpose a system, you become a provider yourself. Mapping these roles across your AI governance inventory is the first defensible step.
What the EU AI Act Requires of CIOs: Documentation, Conformity, and Technical Governance
Here is the uncomfortable truth for technology leaders: the eu ai act does not just ask you to write a policy. It asks you to run an operating system for compliance. For providers and deployers of high-risk AI, the Act imposes documentation, conformity, logging, and quality management obligations that look far more like software quality controls than legal boilerplate. If your team already runs an SDLC and MLOps pipeline, these requirements should live inside those workflows, not in a slide deck.
Annex IV technical documentation: what must be in the file
Under Article 11 and Annex IV, providers of high-risk AI systems must have a complete technical file in place before the system is placed on the market or put into service. This is not a document you assemble the week before an audit. The file must cover the general system description and intended purpose, the development and lifecycle process, data governance and data management, performance and robustness metrics, cybersecurity controls, the risk management system, human oversight mechanisms, and the post-market monitoring plan. CIOs need centralized, version-controlled documentation for each high-risk system, with engineering and data science teams producing this content as a byproduct of how they already build, not as an afterthought.
Conformity assessment: no high-risk system goes live without it
No high-risk AI system may launch into a production environment serving EU users without a completed conformity assessment and an EU declaration of conformity. Article 16 requires providers to ensure the system undergoes the relevant conformity assessment procedure under Article 43, draw up a machine-readable declaration of conformity, affix CE marking, and meet registration obligations. Treat this as a hard release gate. Deployers carry their own duties: verify the system was properly registered, confirm it arrived with a declaration of conformity and instructions for use, and implement the provider's human oversight requirements in practice.
Logging and record retention obligations
Technical documentation, quality management records, and conformity documents must be retained for at least 10 years after the system is placed on the market. Logs automatically generated by high-risk AI systems must be retained for at least six months by both providers and deployers, longer where sectoral law demands it. Your logging infrastructure must capture relevant events securely and link them back to the system's technical file.
Quality Management System requirements under Article 17
Article 17 requires providers to operate a documented Quality Management System covering design control, development quality assurance, testing and validation, data management, risk management, post-market monitoring, and incident handling. This is not a parallel bureaucracy. Embed it in your existing IT governance, source control, model registries, and observability stack. The end state is a central AI governance registry linking classifications, Annex IV files, conformity documents, and deployment context in one place.
What the EU AI Act Means for CROs: Risk Classification, Monitoring, and Liability
For a Chief Risk Officer, the eu ai act does something subtle but consequential: it converts AI from a technology concern into a formal risk category that belongs in the enterprise risk framework, governed with the same discipline as credit, market, or operational risk. The Act supplies the classification rules, the lifecycle controls, and, through its penalty structure, the financial reference point that gets boards to act.
Integrating EU AI Act risk categories into your enterprise risk taxonomy
Start by treating the Act's four tiers—prohibited, high-risk, transparency or limited-risk, and minimal-risk—as entries in the enterprise risk taxonomy rather than labels owned only by IT. For each system, record the legal role, intended purpose, affected people, geography, data sensitivity, business criticality, model and vendor dependencies, and applicable date. Prohibited uses require decommissioning or redesign; high-risk systems require a funded control plan; transparency duties need product and communications owners.
Monitoring, incidents, and liability belong in existing risk processes
CROs should connect AI controls to model risk, operational risk, third-party risk, cyber, privacy, conduct, and product governance. Define key risk indicators for overrides, drift, bias testing, complaints, incidents, and overdue controls. Escalation thresholds should identify when a system must be suspended, when a provider or authority must be notified, and who owns remediation. Financial exposure includes regulatory penalties, contractual claims, litigation, product liability, and the cost of withdrawing a system from use.
What Legal Teams Must Understand: Enforcement, GDPR Overlap, and Product Liability
Legal teams need a defensible position on scope, role, and evidence for every material AI system. Provider, deployer, importer, and distributor obligations differ, and a company can become a provider by placing a system under its name or substantially modifying its purpose or operation. Contracts should allocate documentation, logging, incident support, change notification, audit rights, data access, and cooperation with authorities without pretending that contractual language transfers statutory duties.
The AI Act operates alongside GDPR, consumer protection, employment, equality, sectoral regulation, cybersecurity, and product-liability law. It creates no new lawful basis for personal-data processing. A system can therefore satisfy an AI Act control and still breach GDPR or discrimination law. Legal review should connect the AI inventory to data-protection impact assessments, employment consultation, customer terms, insurance, and litigation hold requirements.
What a Compliant AI Governance Program Looks Like in Practice
A practical program begins with a complete AI inventory and an intake gate for new systems and material changes. Each record should identify the system owner, vendor, model, intended purpose, users, affected people, jurisdictions, legal role, risk classification, and applicable obligations. Classification decisions need reasons and evidence, not only a dropdown value.
Controls then follow the lifecycle: approved data and testing before release; technical documentation and human-oversight design; conformity and registration where required; deployment instructions and training; logging, performance and incident monitoring; vendor change review; and controlled retirement. A central evidence register should link policies, assessments, approvals, test results, logs, contracts, incidents, and corrective actions so CIO, CRO, legal, and audit teams work from the same record.
EU AI Act: Frequently Asked Questions from CIOs, CROs, and Legal Teams
Does the EU AI Act apply to companies headquartered outside the EU?
Yes, in more cases than most executives assume. Under Article 2, the Act reaches providers, importers, distributors, and deployers whose AI systems are placed on the EU market or put into service in the EU. Critically, it also applies to non-EU organizations when the output of their AI system is used in the EU, regardless of where the company is incorporated. The common belief that "we don't process EU personal data, so we're safe" misreads the trigger. Output used in the EU, not data residency, is what pulls you into scope.
We buy AI from vendors who claim to be compliant. Are we covered as a deployer?
No. A vendor's CE marking and declaration of conformity satisfy the provider's obligations, not yours. Under Article 26, deployers of high-risk systems have independent duties: using the system according to the provider's instructions, implementing human oversight, monitoring operation in your specific context, retaining logs for at least six months, and informing workers and their representatives before a high-risk system that affects them is used. Those obligations do not transfer with a purchase order.
Which of our existing AI systems are most likely to be classified as high-risk?
For enterprise readers, the usual suspects sit in Annex III: credit scoring and lending decisions, insurance underwriting and risk scoring, CV screening and candidate shortlisting, employee performance and workforce management tools, and safety components in industrial or infrastructure systems. Any system that profiles individuals by automated processing to assess work performance, economic situation, health, reliability, or behaviour is treated as high-risk. Structured AI governance starts with mapping each system against these categories.
What documentation must we have ready before our high-risk AI systems go live?
If you are the provider, you need a complete Annex IV technical file, a passed conformity assessment, an EU declaration of conformity, and a functioning Quality Management System (Article 17). If you are the deployer, you need verified provider registration, the declaration of conformity, instructions for use, evidence of human oversight implementation, and retained logs.
What are the actual fines for non-compliance, and how do they compare to GDPR?
Prohibited practice violations under Article 5 carry up to €35 million or 7% of global turnover. Most high-risk obligation failures carry up to €15 million or 3%. Providing misleading information to authorities carries up to €7.5 million or 1%. The top tier exceeds GDPR's 4%/€20 million ceiling.
How does the EU AI Act interact with our existing GDPR compliance program?
They are complementary. GDPR governs personal data processing and creates no new lawful basis under the AI Act, while the AI Act layers AI-specific obligations on top. A single incident, such as a discriminatory credit-scoring outcome, can trigger both simultaneously. The practical answer is one evidence set that supports both programs.
What should we do first if we have no formal AI governance program in place today?
Build a full AI system inventory, classify each system against the risk tiers, identify which obligations are already in force, and assign named owners for every high-risk system. That inventory becomes the backbone everything else attaches to.