Comment évaluer la conformité à la loi européenne sur l'IA des logiciels d'IA européens

The EU AI Act is not a product certification scheme that stamps a tool as "compliant" after a one-time assessment. It is a horizontal regulatory framework that applies across industries and assigns obligations based on what a system does and how it is used – regardless of its marketing label or product category.

Legally, an "AI system" is defined functionally: it is a machine-based system designed to operate with varying levels of autonomy and to infer from inputs how to generate outputs such as predictions, content, recommendations, or decisions. Conventional software that merely executes rules fully specified by humans does not fall within this definition solely because it performs scoring or automation. What matters is how the system actually works – the marketing label "AI-powered" is irrelevant to the classification.

The Act is often explained using a four-level risk model, although these categories do not fully reflect every regulatory regime contained in the legislation:

1. Unacceptable risk – Practices that are prohibited outright, including certain forms of social scoring and biometric categorisation based on particularly sensitive characteristics.
2. High risk – In particular, systems used in certain areas listed in Annex III, as well as AI systems that serve as safety components of products covered by specific EU product legislation. These systems are subject to the most extensive documentation and conformity requirements.
3. Limited risk – Certain systems, such as chatbots, are primarily subject to transparency obligations toward end users. Emotion recognition systems may also be subject to transparency requirements, although their use is generally prohibited in certain contexts, including workplaces and educational institutions.
4. Minimal risk – Most everyday AI applications fall into this category, including many internal analytics tools and standard SaaS automations. They are not subject to the extensive requirements that apply to high-risk systems. However, general obligations such as measures relating to AI literacy may still be relevant for providers and deployers.

The Act also distinguishes between several operator roles with different responsibilities, including the provider (which develops an AI system, or has one developed, and places it on the market under its own name), the deployer (which uses an AI system in a professional context), as well as importers, distributors, and authorised representatives. A company may hold more than one role at the same time – for example, if it develops an AI feature and also uses that feature internally.

How Can a Company Determine Whether Its Software Qualifies as "High-Risk AI"?

High-risk classification depends primarily on a system's intended purpose and the context in which it is used – not on whether it uses machine learning or whether the term "AI" appears in the product description.

In principle, two separate routes need to be considered. First, an AI system may qualify as high risk if it is a safety component of a product covered by Annex I, or if the AI system itself is such a regulated product. Second, certain intended uses listed in Annex III may result in high-risk classification.

Annex III covers areas including biometric systems, the management of critical infrastructure, education and vocational training, employment and workforce management (including recruitment, promotion, and termination), access to essential private and public services, including certain creditworthiness assessments, law enforcement, migration and border control, as well as the administration of justice and democratic processes.

However, a use case listed in Annex III is not automatically considered high risk in every circumstance. Under certain conditions, a system may be exempt if it does not pose a significant risk to the health, safety, or fundamental rights of natural persons. Systems that carry out profiling of natural persons are subject to stricter rules in this regard.

A common misconception is that every B2B SaaS product with an embedded AI feature is automatically high risk. That is not the case. Classification depends on the specific function within the product, not on the overall product category. A CRM system with AI-based lead scoring, for example, is not automatically high risk – unless that scoring is used in a regulated context to make decisions affecting natural persons.

A practical classification process might look like this:

• Step 1 – Assess the function, not the product. Identify the specific feature that performs an inference-based task and describe its output and potential impact on natural persons.
• Step 2 – Check both high-risk routes. First determine whether the system falls within the product-related rules of Annex I, then assess whether its intended purpose matches a category listed in Annex III.
• Step 3 – Consider possible exemptions. For systems falling within Annex III, determine whether the conditions for an exemption from high-risk classification may apply.
• Step 4 – Document the reasoning. A written, dated self-assessment is a sensible first step and provides a traceable basis for future reviews.
• Step 5 – Reassess after material changes. If the system's intended purpose, functionality, or deployment context changes significantly, its classification should be reviewed.

Practical examples include a SaaS analytics dashboard with a forecasting function, which would typically not qualify as high risk; an embedded machine-learning model used to assess the creditworthiness of natural persons on a fintech platform, which may qualify as high risk; and certain AI components used in industrial control hardware, provided they constitute relevant safety components under the product safety legislation referenced by the Act.

What Are the Compliance Deadlines Under the EU AI Act?

The obligations under the EU AI Act take effect in stages. The applicable date depends on the specific requirement and the role of the company concerned. Since the Act entered into force, some transition periods have also been adjusted.

The applicable deadlines also vary by operator role. Providers generally carry more extensive obligations because they are responsible for areas such as technical documentation, conformity, and system design. Deployers, by contrast, have operational responsibilities such as human oversight and monitoring where these are required for the system concerned. Importers and distributors are subject to their own verification and information obligations.

Special transitional provisions may apply to systems and models that were already in use or on the market before the relevant requirements became applicable. Teams should therefore assess which rules apply to their specific existing products. As the regulatory framework continues to be clarified through guidance and supplementary measures, current deadlines should also be checked against the Official Journal of the European Union or the European Commission's Digital Strategy portal.

What Documentation Must Software Providers Maintain for EU AI Act Compliance?

Documentation requirements vary considerably depending on the system's risk classification and the role of the organisation. High-risk systems are subject to the most extensive requirements. For systems that are primarily subject to transparency obligations, the documentation burden is significantly lighter.

Required for providers of high-risk systems:

• Technical documentation in accordance with Annex IV, covering areas such as system design, intended purpose, relevant data, and performance metrics.
• Records relating to the risk management system, documenting identified risks, mitigation measures, and decisions regarding residual risk throughout the system's lifecycle.
• Data governance documentation, where training, validation, and testing data are relevant to the system.
• Human oversight provisions, defining how responsible individuals can appropriately monitor the system and intervene where necessary.
• Evidence relating to conformity assessment, including the declaration of conformity and, where required, the involvement of a notified body.

Ongoing requirements include:

• Post-market monitoring to track the system's performance and identify potential issues after deployment.
• Records of serious incidents, where corresponding reporting obligations apply.
• Change logs documenting material modifications to the model, system, or intended purpose.

For systems subject to transparency obligations:

• Transparency notices, for example where users must be informed that they are interacting with an AI system.
• Depending on the system, additional requirements may apply to the labelling or detectability of AI-generated or manipulated content.

Minimal-risk software generally does not require the full technical documentation set out in Annex IV. Nevertheless, maintaining a short internal record of the classification rationale can still be useful. Companies should also assess whether more general requirements, such as AI literacy obligations, apply to their role.

Providers of general-purpose AI models are subject to a separate regulatory and documentation regime.

Does the EU AI Act Apply to Software Providers Outside the EU?

The EU AI Act also has extraterritorial reach. A company does not need to have a legal presence in the EU to fall within its scope. Relevant triggers may include placing an AI system or model on the EU market, putting an AI system into service in the EU, or using within the EU an output generated by a system.

This is broadly comparable to the extraterritorial logic of the GDPR, although neither regime is based on EU citizenship. What matters are the territorial connecting factors defined by the relevant legislation.

For US or UK SaaS providers, this means that offering an AI system on the European market may bring the company within the scope of the Act even if it has no local office. The precise extent of its obligations will then depend on the type of system, its intended use, and the company's role.

Providers established outside the EU must generally appoint an authorised representative within the EU before making a high-risk AI system available on the European market. Certain non-EU providers of GPAI models are also subject to representative requirements. Providers of other types of systems, however, are not automatically subject to a general obligation to appoint an EU representative.

Companies that have already established a GDPR compliance framework – including documented data flows, clear responsibilities, and established governance processes – may have a structural advantage, as a number of organisational requirements overlap.

What Penalties Apply for Non-Compliance With the EU AI Act?

Penalties under the EU AI Act are tiered according to the seriousness of the violation. The amounts below are statutory maximums, not automatic fines.

• Violations involving prohibited AI practices may result in fines of up to €35 million or 7% of worldwide annual turnover.
• Other breaches of obligations under the AI Act may result in fines of up to €15 million or 3% of worldwide annual turnover.
• Providing incorrect, incomplete, or misleading information to competent authorities may result in fines of up to €7.5 million or 1% of worldwide annual turnover.
• Treatment of SMEs: For small and medium-sized enterprises, the applicable maximum is generally the lower of the fixed amount and the percentage of annual turnover. For other undertakings, the higher amount generally applies.

The actual penalty depends on the nature, severity, duration, and other circumstances of the specific infringement. Providers of general-purpose AI models are also subject to a separate enforcement and penalty regime.

For smaller SaaS providers, however, this does not mean that compliance can simply be ignored. A traceable classification process, clearly documented responsibilities, and appropriate monitoring procedures can help identify regulatory risks early and provide a defensible record of how compliance decisions were made.

How Software Teams Can Approach EU AI Act Compliance in a Structured Way

The most sensible first step for a software provider is a documented and dated self-classification of its AI system – not immediately purchasing a third-party certification service or compliance software subscription. Both the product-related route to high-risk classification and the Annex III categories should be assessed.

Even a short internal memo mapping individual product features and intended uses to the relevant regulatory categories can create a clear and traceable basis for future reviews as the product or regulatory guidance evolves.

Classification, documentation, and deadline tracking should be treated as a recurring internal process linked to material product changes rather than as a one-off compliance project tied to a single deadline. If a system's intended purpose, functionality, or deployment context changes substantially, teams should reassess whether the existing classification remains valid.

Questions fréquemment posées

Does Using Open-Source AI Models Create Additional Liability Under the AI Act?

Integrating a third-party or open-source AI model into a product does not automatically exempt an organisation from regulatory obligations. A company may still qualify as the provider of its own AI system even if the underlying third-party model is integrated without modification.

At the same time, the AI Act includes specific provisions and, in some cases, exemptions for freely licensed and open-source systems and models. These exemptions do not apply without limitation, particularly in relation to certain high-risk systems or GPAI models with systemic risk. Providers should therefore document which components originate from third parties and determine their own role within the AI value chain.

Is a Chatbot Automatically Classified as Limited Risk?

Many chatbots are primarily subject to transparency requirements and may, for example, need to inform users that they are interacting with an AI system.

However, if a chatbot is used to make decisions in a high-risk context – such as assessing job applicants or determining access to certain public or private services – the underlying function may itself qualify as high risk. What matters is therefore not the chat interface, but the actual intended purpose of the system.

Can a Company Self-Certify a High-Risk AI System Without an External Audit?

An internal conformity assessment is possible for various high-risk use cases. In certain situations, however – particularly for specific biometric systems or systems linked to regulated products – other conformity assessment procedures or the involvement of a notified body may be required.

The applicable procedure therefore depends on the specific system and the relevant regulatory route.

How Does the EU AI Act Relate to ISO 42001 or the NIST AI RMF?

ISO 42001 and the NIST AI Risk Management Framework are voluntary management and risk-management frameworks, while the EU AI Act is binding legislation with enforceable obligations and penalties.

Organisations that have already implemented such management systems will often find significant overlap in areas such as risk management, governance, and documentation. This can reduce the additional effort required for AI Act compliance, but it does not replace an assessment of the specific legal requirements.