EU AI Act: a complete guide to obligations, liability and data

The EU AI Act is not a technical standard for specialists. It is the framework that decides which artificial intelligence systems a company can place on the market or use in Europe, under which controls, and with which chain of accountability. This guide brings together in one place the definitions, the risk classification, the obligations by role, the treatment of data and people's rights, the application calendar and the penalties. It is written for the people who make decisions: executive management, legal, compliance, data protection, IT and the business owners of AI projects.

1. What the AI Act is and who it applies to

Regulation (EU) 2024/1689 is the world's first horizontal legal framework on artificial intelligence. It does not regulate one specific technology: it regulates how AI systems are placed on the market, put into service and used, applying obligations proportionate to the risk they create for health, safety and fundamental rights.

Definition of an AI system. A machine-based system designed to operate with varying levels of autonomy, that may exhibit adaptiveness after deployment, and that infers from the input it receives how to generate outputs such as predictions, content, recommendations or decisions that can influence physical or virtual environments. Inference is the discriminating element: software applying deterministic rules written by a person falls outside the scope, a model that learns relationships from data does not.

General purpose AI models (GPAI). Large generative models have their own chapter, with obligations covering technical documentation, information provided downstream, a copyright compliance policy and a public summary of training data. Models presenting systemic risk add adversarial evaluation, risk mitigation, serious incident tracking and reinforced cybersecurity.

Extraterritorial scope. The regulation applies to providers established outside the Union when the output of the system is used within the Union. An Italian or UK-based company integrating a model developed in the United States does not transfer the risk to the provider: it takes on its own obligations as a deployer and, in certain cases, becomes a provider itself.

What stays outside. Systems used exclusively for military, defence or national security purposes; research and development activity before market placement; strictly personal non-professional use; components released under free and open source licences, unless they fall into prohibited or high-risk categories.

Relationship with the Digital Omnibus. The simplification package recalibrated timing and some requirements, but it did not change the architecture: prohibitions, risk classification, high-risk obligations and the GPAI regime remain the core of the law. We covered the detail in our analysis of the Digital Omnibus and in the note on what became binding on 2 August 2026.

2. The four risk classes

Classification is the first operational exercise. Without it, every subsequent assessment is arbitrary.

Class	Business examples	Consequence
Unacceptable risk	Social scoring, emotion recognition in the workplace, manipulative techniques, untargeted scraping of facial images to build biometric databases	Outright prohibition, already applicable
High risk	Candidate screening and selection, performance evaluation and promotion, credit scoring, life and health insurance pricing and underwriting, safety components of regulated products, systems used in education, essential services and justice	Full conformity regime, conformity assessment, CE marking, registration
Limited risk	Customer-facing chatbots, synthetic content generation, deepfakes, systems interacting with natural persons	Transparency and content marking obligations
Minimal risk	Spam filters, internal logistics optimisation, non-determinative product suggestions	No specific obligations, voluntary codes of conduct

Two clarifications account for most classification errors. First: a system listed as high risk can be derogated if it performs a narrow procedural task, improves the result of a human activity already completed, only detects deviations from decision patterns without replacing human assessment, or performs a preparatory task. The derogation must be documented, not presumed, and it falls away whenever the system performs profiling of natural persons. Second: the class depends on the intended purpose, not on the technology. The same language model is limited risk in an informational chatbot and high risk when it filters CVs.

Classification belongs in an AI system inventory, with owner, purpose, data processed, company role and risk class. It is the starting point of our AI Assessment and the base on which we build the AI Rating.

3. Roles and accountability along the chain

The AI Act distributes obligations across five roles. A company can hold more than one at the same time, for different systems or even for the same system in different markets.

Role	Who it is	Main obligations
Provider	Develops the system, or has it developed, and places it on the market under its own name or trademark	Quality and risk management system, technical documentation, conformity assessment, CE marking, registration in the EU database, post-market monitoring, serious incident reporting
Deployer	Uses the system under its own authority in a professional activity	Use in line with instructions, human oversight by competent staff, control over input data quality where applicable, log retention, information to workers and affected persons, fundamental rights impact assessment where required
Importer	Places on the EU market a system from a non-EU provider	Conformity verification, documentation, traceability, cooperation with authorities
Distributor	Makes the system available on the market without being provider or importer	Verification of marking and documentation, suspension of distribution when non-conformity is found
Authorised representative	Entity in the Union appointed by a non-EU provider	Custody of documentation, interface with authorities

When a deployer becomes a provider. This is the most underestimated scenario and the most frequent in companies that adopt AI without developing it. You become a provider when you put your own name or trademark on a high-risk system already placed on the market, when you substantially modify a high-risk system already in use, or when you change the purpose of a system so that it becomes high risk. A concrete example: a general purpose model embedded in a candidate evaluation flow and re-exposed internally as the company's HR tool turns the deployer into a provider, with the full obligation set that follows.

On this point governance matters more than technology: you need an internal rule stating who authorises integrations and modifications, and on the basis of what review. That is the work we do in the AI Governance track and in defining the AI Strategy.

4. Operational obligations for high-risk systems

For systems in the high class, the regulation requires a permanent compliance system, not a one-off exercise.

Risk management system. An iterative process covering the entire lifecycle: identification of reasonably foreseeable risks to health, safety and fundamental rights, estimation of risks under intended use and foreseeable misuse, adoption of mitigation measures, testing against metrics and thresholds defined in advance.

Data governance. Training, validation and testing datasets must be relevant, sufficiently representative and, to the extent possible, free of errors and complete for their purpose. Possible biases affecting health, safety and rights must be examined, with detection and correction measures. This is the chapter that connects the AI Act directly to the data work covered in AI Data.

Technical documentation and automatic logging. Documentation must demonstrate conformity before market placement and stay current. Systems must automatically record events across the lifecycle, with logs kept for a period appropriate to the purpose and in any case no shorter than six months unless otherwise provided.

Transparency towards the deployer. Clear instructions for use, covering characteristics, capabilities, performance limitations, expected accuracy levels, conditions that may create risk, the human oversight measures foreseen and the expected lifetime.

Human oversight. The system must be designed so that a person can understand its capabilities and limits, correctly interpret its output, decide not to use it, disregard the result or interrupt operation. Human oversight is not a signature at the end of an already formed output: if the person supervising lacks the time, the information and the authority to disagree, the obligation is not met.

Accuracy, robustness and cybersecurity. Adequate and consistent levels across the lifecycle, with resilience against errors, faults, inconsistencies and attempts to manipulate data or the model, including data poisoning and adversarial attacks.

Conformity assessment and CE marking. Depending on the case, internal control or the involvement of a notified body, followed by the EU declaration of conformity, CE marking and registration in the European database.

Post-market monitoring. Systematic collection and analysis of real-world performance data, with an obligation to report serious incidents to the authorities within tight deadlines.

5. Data and people's rights

The AI Act does not replace the GDPR: it overlaps with it. Every system processing personal data must satisfy both regimes, and in practice this is where disputes and internal challenges concentrate.

Legal basis and minimisation. Before any technical assessment you need a valid legal basis for training, for fine tuning and for inference, with distinct and documented purposes. Reusing data collected to deliver a service in order to train a model is a change of purpose that must be justified, not a natural continuation.

Automated decisions. Article 22 GDPR restricts solely automated decisions producing legal effects or similarly significantly affecting a person. Adding a formal reviewer is not enough: meaningful human involvement is required. We examined this in the article on GDPR Article 22 and automated decisions inside the enterprise.

DPIA and fundamental rights impact assessment. The DPIA remains a GDPR obligation when processing presents high risk. The FRIA is the AI Act obligation for certain deployers of high-risk systems, in particular public bodies and entities providing essential public services, plus specific cases in credit and insurance. They are distinct instruments with largely shared evidence: design them as one file with two views, not as two parallel exercises.

Transparency towards people. People interacting with an AI system must be told, unless it is obvious from the context. Synthetic content must be marked in a machine-readable format. Deepfakes and text published to inform the public on matters of public interest require explicit disclosure. In the workplace, workers and their representatives must be informed before a high-risk system is put into service.

Right to explanation. A person subject to a decision taken by a high-risk system producing legal effects or significantly affecting them has the right to obtain from the deployer clear and meaningful explanations of the role of the system in the decision and of the main elements behind it. Translated into a technical requirement: you need decision-level logs, versioning of the model and rules, and an explanation understandable without statistical jargon.

Data inside models and data subject rights. Erasure, rectification and objection must be handled even when the data has flowed into training. The workable routes are upstream filtering, separation between a retrievable knowledge base and model weights, and the architectural choice of document retrieval over fine tuning when personal data is involved.

6. AI literacy and cross-cutting obligations

The literacy obligation applies to all providers and deployers, regardless of the risk class of the systems in use: staff dealing with the operation and use of AI systems must have a sufficient level of competence, taking into account the context and the people affected. It is not a one-off course but a programme proportionate to the role: those who select vendors, those who supervise outputs and those who design processes have different training needs. That is exactly the logic of our AI Training tracks and of the corporate courses and workshops.

7. Penalties and calendar

Infringement	Cap
Prohibited practices	EUR 35 million or 7% of total worldwide annual turnover
Breach of high-risk, transparency or GPAI obligations	EUR 15 million or 3% of turnover
Incorrect, incomplete or misleading information to authorities	EUR 7.5 million or 1% of turnover

The higher of fixed amount and percentage applies, with reduced thresholds for SMEs. The calendar is staggered: prohibitions and literacy obligations already apply, the GPAI regime entered into force in the second phase, high-risk obligations follow on differentiated timelines between systems listed in the annexes and those that are safety components of already regulated products. In Italy there is an additional national layer, with Law 132/2025 and the extension of corporate administrative liability through the new Article 25-vicies of Legislative Decree 231/2001: a profile that moves the topic from the compliance budget to the board agenda.

8. From the law to internal governance

Compliance is not achieved with a document: it is achieved with a management system that produces evidence repeatably. ISO/IEC 42001 is today the most effective instrument for that, because it provides the organisational structure (policy, roles, objectives, controls, internal audits, management review) on which the AI Act requirements can rest. The detailed comparison between the two is in our guide to AI governance frameworks.

The minimum elements of a governance setup that survives an inspection are five: an AI policy approved at the top, a system inventory with reasoned classification, an authorisation process for new use cases with explicit gates, logs and documentation retained per system, and a periodic review cycle with named owners. Everything else is implementation detail. If you want to measure the distance from that point, start with our AI compliance track.

9. A phased operating plan

First phase, inventory and classification. A census of every AI system in use, including those bought as features inside third-party software and those introduced by individual teams without authorisation. For each: purpose, company role, data processed, risk class, owner. The output is the AI system inventory and a priority list.

Second phase, gap analysis and decisions. Comparison between applicable obligations and existing evidence, system by system. Explicit decisions on what to retire, what to bring into conformity, what to renegotiate with vendors. This is where the AI policy is written and the authorisation process is defined.

Third phase, remediation and proof. Closing priority gaps, activating logging, formalising human oversight, launching the AI literacy programme, testing the process on a real case. How long each phase takes depends on the number of systems in use, the maturity of existing processes and the availability of evidence: what matters is the sequence, not the calendar. By the end you must be able to answer three questions with documents in hand: which systems we use, who is accountable for them, how we demonstrate they are under control.

On the adoption side the principle is symmetrical: no system reaches production without validation. That is the logic of the AI Adoption path, of fast validation with PROTOT.AI and of running AI agents in production.

10. Frequently asked questions

Does the AI Act apply if we only use third-party tools? Yes. Anyone using an AI system in a professional activity is a deployer and has their own obligations, which cannot be contracted away to the provider.

Is an internal chatbot high risk? Usually not, if it answers questions and does not contribute to decisions about people. It becomes high risk when it enters recruitment, evaluation, access to essential services or credit processes.

Is adding a human reviewer enough to leave the high-risk class? No. Human oversight is a requirement for high-risk systems, not an exit from the classification. Derogation is possible only in the typified cases and must be documented.

What is the difference between a DPIA and a FRIA? The DPIA covers data protection risks and is a GDPR obligation. The FRIA covers the impact on fundamental rights and is an AI Act obligation for certain deployers of high-risk systems. They share most of the underlying evidence.

If we modify a purchased model, do we become providers? If the modification is substantial on a high-risk system, or if it changes the purpose so that the system becomes high risk, yes. Applying your own trademark has the same effect.

How long does it take to become compliant? For a company with a few non-critical systems, a structured quarter is enough to close the framework. For portfolios with high-risk systems, timing depends on the conformity assessment and on the documentation already available.

Do SMEs get a lighter regime? They are not exempt, but they benefit from reduced penalty caps, simplified documentation in some cases and priority access to national regulatory sandboxes.

The next step

The organisations that handle the AI Act well are not the ones that read more articles of the regulation: they are the ones that turn the text into an inventory, an authorisation process and a set of maintained evidence. It is a governance job, not a paperwork job.

If you want to understand where your company stands against this picture, the fastest route is a thirty-minute conversation or an AI Rating, our structured assessment of maturity and regulatory exposure. From there you build a plan that holds compliance and the ability to put AI into production together.