The EU AI Act, explained for the people who have to implement it

What the EU AI Act is

The EU AI Act is Regulation (EU) 2024/1689. It is the first comprehensive statutory framework for artificial intelligence in a major economy, and it is structured like product-safety law rather than like data protection law: obligations attach to a system, in a defined role, at a defined level of risk, across its lifecycle from design through post-market monitoring.

That structure has a practical consequence that most organisations underestimate. Compliance is not a legal opinion produced once. It is a repeatable operating process that has to be evidenced for every AI system you develop, buy, embed or allow into use — and re-evidenced whenever that system materially changes.

Who it applies to

The Regulation reaches organisations that develop, supply, import, distribute or use AI systems in the Union, including organisations established in third countries where a system is placed on the Union market, put into service in the Union, or where the system's output is used in the Union. For Irish enterprises the live question is almost never whether the Act is relevant, but which systems fall in scope, in which role, and at which classification.

Certain activities sit outside the Act's scope, including defined military, national security and purely scientific research contexts, and the Act interacts with rather than replaces existing law such as the GDPR and sectoral regulation. Scope conclusions should be recorded with reasoning, not assumed.

• AI developed in-house, including internal tooling and automations
• AI bought as software, embedded inside licensed platforms and vendor APIs
• AI reached through third-party APIs and model providers
• Agentic systems that hold tool permissions and act on your behalf
• AI adopted by staff without approval — the shadow AI estate

Provider, deployer, importer, distributor

Role determines the obligation set, and role is determined per system rather than per organisation. Most enterprises hold several roles at once: deployer of a licensed assistant, provider of an internally built classifier, and — after materially modifying or rebranding a bought system — provider of something they believed they were only using.

Getting this wrong is the most expensive early mistake in an AI governance programme, because every downstream artefact you produce is scoped to the role you assumed.

• Provider — develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark
• Deployer — uses an AI system under its own authority
• Importer — places a system from a third-country provider on the Union market
• Distributor — makes a system available in the supply chain
• Material modification, rebranding or repurposing can shift you into provider duties

The four risk tiers

The Act regulates by risk. Understanding the four tiers is the fastest way to understand what the law will ask of any given system.

• Unacceptable risk — prohibited practices under Article 5; these cannot be risk-managed into acceptability
• High risk — systems within Article 6 and Annex III areas, or safety components of regulated products; the heaviest documentation, data governance, oversight, logging and monitoring duties
• Transparency risk — uses caught by Article 50, such as interacting with people or generating or manipulating content, where disclosure or marking is required
• Minimal risk — the large remainder, unregulated by the Act itself but still subject to GDPR, sectoral rules and your own internal control expectations

Prohibited practices (Article 5)

Article 5 places certain AI practices outside risk management altogether. The areas addressed include manipulative or deceptive techniques that materially distort behaviour and cause significant harm, exploitation of vulnerability, certain social-scoring uses, specified predictive-policing uses, untargeted scraping to build facial recognition databases, emotion inference in workplace and education contexts, certain biometric categorisation, and defined uses of real-time remote biometric identification in publicly accessible spaces — each subject to precise conditions and exceptions in the legal text.

Operationally, prohibited-practice screening belongs at intake, before design effort is spent, and the screening outcome must be recorded rather than assumed. A favourable risk score cannot cure a prohibited use.

High-risk systems (Articles 6, 26, 27)

High-risk classification is where the Act becomes an engineering and operating burden rather than a policy statement. Providers face requirements spanning risk management, data and data governance, technical documentation, record-keeping, information for deployers, human oversight design, accuracy, robustness and cybersecurity, quality management, conformity assessment and registration.

Deployers of high-risk systems face their own duties: use in accordance with instructions, assignment of competent human oversight, control of input data within their remit, monitoring and cooperation, retention of logs, informing workers where relevant, and in defined public-interest cases a fundamental rights impact assessment under Article 27.

• Employment, worker management and access to self-employment
• Education and vocational training decisions
• Access to essential private and public services, including creditworthiness
• Risk assessment and pricing in life and health insurance
• Biometrics, critical infrastructure, law enforcement, migration and justice contexts
• Safety components of products already covered by Union harmonisation law

Transparency obligations (Article 50)

Article 50 catches uses that are not high-risk but still require honesty with the people affected. People should know when they are interacting with an AI system unless it is obvious; emotion recognition and biometric categorisation subjects should be informed; and synthetic or manipulated audio, image, video and text content should be marked in machine-readable form and, in defined cases such as deep fakes, disclosed.

For most enterprises this is the obligation that touches the largest number of live systems, because it lands on customer service assistants, marketing content generation and internal knowledge tools rather than on a small number of regulated models.

General-purpose AI models

The Act sets a distinct regime for general-purpose AI models, including technical documentation, information for downstream providers, a copyright policy and a public summary of training content, with additional obligations where a model is deemed to present systemic risk. Enforcement of the model layer sits with the European Commission's AI Office.

Most organisations are not model providers, but almost all are downstream deployers of general-purpose models. The practical duty that follows is supplier assurance: capturing what the model provider documents, what it commits to, and what your own use adds on top.

Application dates

The Regulation entered into force in 2024 and applies in phases: prohibitions and AI literacy expectations first, general-purpose AI model obligations next, then the substantive high-risk regime, with longer transitions for systems embedded in products already covered by Union harmonisation law and for certain systems already on the market. Because the binding date depends on the system, its classification and your role, the applicable date should be confirmed against the legal text.

Planning advice that survives every schedule change: build the inventory and the assessment process now, because every phased obligation consumes the same two inputs.

Penalties

The Act provides for tiered administrative fines, with the highest ceiling attached to prohibited practices, a lower tier for other infringements of obligations, and a further tier for supplying incorrect, incomplete or misleading information to authorities. Ceilings are expressed as a fixed amount or a percentage of total worldwide annual turnover, whichever is higher, with specific treatment for SMEs and start-ups and separate provision for general-purpose model providers.

In practice the commercial exposure often arrives earlier than any fine: enterprise customers, insurers and procurement functions ask for the evidence first, and an organisation that cannot produce it loses the deal long before a regulator calls.

What evidence looks like

A defensible EU AI Act record answers six questions without reconstruction: what the system is and who owns it, what was assessed and under which ruleset version, which obligations and controls applied and whether their evidence is complete, who approved it and on what conditions, what monitoring has run since, and what has changed.

If those answers live in spreadsheets, email threads and slide decks, they are an argument. If they are generated from append-only history with version-controlled criteria, they are evidence.

• One authoritative register of AI systems, models, agents and embedded features
• Per-system role determination with retained reasoning
• Deterministic, versioned classification with a readable explanation trace
• Derived obligations and controls with owners, dates and evidence completeness
• Independent human review, separated from the assessor
• Monitoring, incident handling and material-change reassessment triggers
• Exportable assessment and decision packs

A twelve-step implementation sequence

Order matters more than speed. This is the sequence we see work in regulated organisations starting from a partial position.

• 1. Name an accountable executive owner for AI governance
• 2. Build the inventory, including embedded, vendor and staff-adopted AI
• 3. Assign a named owner to every entry
• 4. Screen Article 5 prohibited practices and close out the record
• 5. Determine role per system, on evidence
• 6. Classify risk under one approved ruleset version
• 7. Derive applicable obligations and controls, and expose evidence gaps
• 8. Design human oversight that can actually intervene and stop
• 9. Implement Article 50 disclosure and content marking where caught
• 10. Stand up logging, monitoring, incident handling and reassessment triggers
• 11. Establish role-based AI literacy and retain completion records
• 12. Rehearse the evidence export before a regulator or customer asks