Frequently Asked Questions

Five sets of obligations are currently in force.

Prohibited AI practices under Article 5 have been enforceable since 2 February 2025. AI literacy obligations under Article 4 also applied from that date. GPAI model obligations under Articles 51–56, along with the governance framework (the AI Office, the European Artificial Intelligence Board, and national competent authorities) and the general fine mechanism under Article 99, became applicable on 2 August 2025. The Act reached its general application date on 2 August 2026, bringing the Article 50 transparency obligations into force. The remaining high-risk obligations under Annex III now apply from 2 December 2027, and Annex I embedded systems from 2 August 2028, following the Digital Omnibus's entry into force on 27 July 2026.

The Digital Omnibus on AI, Regulation (EU) 2026/1744, was approved by the European Parliament on 16 June 2026 and by the Council on 29 June 2026, published in the Official Journal in July 2026, and entered into force on 27 July 2026.

It defers the deadline for standalone Annex III high-risk systems to 2 December 2027, and for Annex I product-embedded systems to 2 August 2028. These are now the legally binding dates, replacing the original 2 August 2026 deadline for both categories.

It does not defer the Article 50 transparency obligations, which applied as planned from 2 August 2026, and it adds new prohibitions on AI-generated non-consensual intimate imagery and child sexual abuse material, taking effect on 2 December 2026.

The Digital Omnibus is now in force, so the deferred deadlines (2 December 2027 for standalone Annex III systems, 2 August 2028 for Annex I embedded systems) are confirmed rather than provisional. That said, the Article 50 transparency obligations, the Article 5 prohibited practice rules, and the GPAI obligations remain unaffected and unchanged. Organisations that use the additional time to build their AI inventory, complete risk assessments, and establish governance structures will still be in a far stronger position than those that wait until the new deadlines approach.

Article 50 applies from 2 August 2026 and is not affected by the Digital Omnibus. From that date, deployers must inform users when they are interacting with a chatbot, providers must ensure AI-generated content is machine-detectable, and deployers must disclose when emotion recognition or biometric categorisation systems are being used.

Yes. AI systems placed on the market before the relevant applicability date are generally required to comply only when they undergo a significant change to their design. Public authority deployers have until 2 August 2030.

No. Article 95 encourages providers and deployers of non-high-risk systems to adopt voluntary codes applying some of the high-risk requirements on their own initiative, but there is no enforcement consequence for not doing so.

Yes. If the system is redeployed for a use covered by Annex III, or substantially modified in a way that changes its risk profile, the classification must be reassessed. Minimal-risk status is not permanent.

Yes. The AI Act not applying to a system does not exempt it from GDPR, consumer protection law, product liability rules, or sector-specific regulation, all of which apply independently of AI risk classification.

Effectively one: Article 4's AI literacy duty, which applies to every provider and deployer regardless of risk tier. The Chapter III high-risk requirements, risk management, documentation, conformity assessment, and the rest, do not apply.

Spam filters, recommendation engines, AI-enabled games, and most internal process automation are common examples, provided they are not repurposed into one of the Annex III high-risk domains or embedded in an Annex I regulated product.

There is no external sign-off for minimal-risk classification. The provider or deployer determines this itself, based on the same Article 6 classification logic used for every other tier, and should document that reasoning in case it is ever questioned. A risk tier self-assessment can be conducted through this tool: https://deeploy.ai/eu-ai-act-hub/self-assessment/

There are two routes to high-risk classification. Under Article 6(1), an AI system that is a safety component of a product covered by EU harmonised legislation (such as medical devices or machinery) is high-risk, provided its failure or malfunction would endanger health or safety. Following the Digital Omnibus, AI used solely for non-safety purposes, such as user assistance, optimisation, service efficiency, automation, convenience, or non-safety quality control, no longer qualifies under this route.

Under Article 6(2), standalone AI systems listed in Annex III are high-risk. Annex III covers eight sectors: biometric identification, critical infrastructure, education, employment, essential services, law enforcement, migration and asylum, and administration of justice.

Almost certainly yes. Annex III Point 4 covers AI systems used for recruitment, candidate selection, CV screening, task allocation, performance monitoring, and promotion or termination decisions. If your tool performs any of these functions, it falls within scope and is subject to the full high-risk requirements.

Yes. Annex III Point 5 covers AI systems used to evaluate the creditworthiness of individuals or establish their credit score. This applies whether the system is built in-house or procured from a third party.

Not automatically. Classification depends on use case, not technology. A product recommendation engine on a retail website is typically minimal risk. The same algorithmic logic applied to determining access to essential services, or to allocating workers to tasks, would be high-risk under Annex III.

Both. The Act covers AI systems regardless of whether they face customers or are used solely for internal operations such as HR, finance, or IT management. Internal employee monitoring or performance evaluation tools are explicitly within Annex III scope.

The Commission's guidance defines a significant change as one that affects the intended purpose of the system, its performance on safety-relevant tasks, or the nature of risks it poses. A model retrained on substantially different data, or repurposed for a new use case, is likely to qualify. Minor parameter updates typically do not.

A provider is any organisation that develops an AI system and places it on the market, or has it developed under its direction. Providers carry the heaviest obligations: technical documentation, risk management system, conformity assessment, CE marking, and post-market monitoring.

A deployer is any organisation that uses an AI system in a professional context under its own authority. Deployers must use systems as intended, ensure human oversight, monitor operation, and report serious incidents.

You are a deployer of OpenAI's GPAI model, but a provider of your own AI system built on top of it. If your system is classified as high-risk, you carry provider obligations for that system, including conformity assessment and technical documentation, even though you did not train the underlying model yourself.

Potentially. If your fine-tuning constitutes a "substantial modification" to the original model, you may be reclassified as a provider and take on the associated obligations. The AI Office has provided partial guidance on this boundary but it remains a grey area. Extensive fine-tuning that changes the system's intended purpose or performance profile carries the higher risk of triggering provider status.

Yes, and many organisations are. A company that builds an AI-powered HR tool for internal use is both the provider (it developed the system) and the deployer (it operates the system). In that case, the full set of obligations from both roles applies.

Under Article 26, deployers must: use the system in accordance with the provider's instructions for use; assign a human oversight person with the authority and capability to intervene; monitor the system's operation; inform employees or their representatives where AI is used in the workplace; conduct a Fundamental Rights Impact Assessment where required; keep logs for the periods specified; and report serious incidents to the relevant authority.

Providers of high-risk AI systems must supply instructions for use covering the system's intended purpose, performance characteristics, limitations, maintenance requirements, and the level of human oversight required. Without adequate documentation from your provider, you cannot demonstrate compliance with your own deployer obligations. This is a contractual point worth addressing before deployment.

A General-Purpose AI (GPAI) model is a model trained on large amounts of data that can perform a wide range of tasks and be integrated into many downstream applications.

Examples include GPT-4, Claude, Gemini, Llama, and Mistral. GPAI models are regulated under a parallel track in the Act (Articles 51–56), distinct from the high-risk system framework. All GPAI providers must publish technical documentation and a training data summary, and must comply with EU copyright rules.

GPAI models trained using more than 10²⁵ floating point operations (FLOPs) are presumed to carry systemic risk. Providers of such models must additionally conduct model evaluations, perform adversarial testing, track and report serious incidents, ensure cybersecurity protections, and report energy consumption. As of mid-2026, the frontier models from OpenAI, Google, Anthropic, and Meta all fall into this category.

Partially. Providers of free and open-licence GPAI models are exempt from most documentation and transparency obligations. They are not exempt from the obligation to comply with EU copyright rules or to publish a training data summary. Crucially, the exemption does not apply if the open-source model is classified as having systemic risk; in that case, all obligations apply in full.

Yes. AI agents are not a separate category but fall under the existing definitions of AI systems and GPAI models depending on their architecture. If an agentic system classifies as high-risk, the full Chapter III obligations apply. The AI Office has indicated it is monitoring agentic developments closely and may issue further guidance.

No. Under Article 43(2), high-risk systems listed in Annex III, points 2 to 8, which cover employment, education, essential services, law enforcement, migration, and justice, use self-assessment only. A notified body is required only for certain biometric systems under Annex III, point 1, and for AI embedded in products already regulated under Annex I.

No. Under Article 43(4), a substantial modification to a high-risk system after assessment triggers a new conformity assessment, regardless of which route was originally used.

Yes. Stand-alone Annex III obligations now move to 2 December 2027, and Annex I embedded high-risk systems move to 2 August 2028. The Digital Omnibus, Regulation (EU) 2026/1744, entered into force on 27 July 2026, so these are now the legally binding dates.

For biometric systems under Annex III, point 1, that are intended for use by law enforcement, immigration, or asylum authorities, or by EU institutions, bodies, or agencies, the relevant market surveillance authority performs the notified body role itself, rather than a private notified body.

A notified body is an accredited third-party organisation authorised to independently assess whether a high-risk AI system meets the EU AI Act's requirements, rather than the provider checking its own work.

No, not all high-risk systems need one. Under Article 43(2), systems listed in Annex III (points 2 to 8) which cover employment, education, essential services, law enforcement, migration, and justice, use self-assessment only. A notified body is required only for certain biometric systems under Annex III, point 1, and for AI embedded in products already regulated under Annex I.

Annex VI is the internal control, or self-assessment, procedure: the provider checks its own quality management system and technical documentation against the Act's requirements. Annex VII is the notified body procedure: an accredited third party reviews the same material and issues a certificate.

Under Article 43(1), a provider of a biometric system listed in Annex III, point 1, can choose self-assessment only if it has fully applied the relevant harmonised standards or common specifications. If those standards do not yet exist, have not been fully applied, or only partially cover the requirements, notified body assessment under Annex VII is mandatory.

A conformity assessment is the process by which a provider of a high-risk AI system demonstrates that the system meets the Act's requirements before placing it on the market. For most Annex III systems, providers can conduct a self-assessment based on internal documentation. Third-party assessment by a notified body is required for biometric identification systems and AI systems used as safety components of Annex I regulated products.

Annex IV of the Act specifies eleven mandatory documentation elements, including: a general description of the system and its intended purpose; a description of the development process; details of training, validation, and testing data; the risk management measures applied; the human oversight measures built in; performance metrics and known limitations; and post-market monitoring arrangements.

CE marking is required for high-risk AI systems that are either safety components of Annex I regulated products or standalone systems as listed in Annex III. The CE mark indicates conformity with the EU AI Act's requirements. Before affixing it, providers must complete the conformity assessment and sign a declaration of conformity.

Deployers must retain automatically generated logs for at least six months. Providers must retain technical documentation for ten years after the system is placed on the market. These periods may overlap with GDPR retention obligations and should be reconciled in your data governance policy.

Mostly no. Only one of the eight prohibited practices, real-time biometric identification by law enforcement, has narrow, tightly conditioned exceptions built in. The rest are banned without exception.

Generally yes. The Commission's guidelines indicate that research and development work has room to experiment with functionality that might otherwise look manipulative, since the prohibition attaches once the system is placed on the market or put into service, not during internal testing.

 It depends which route applies. The manipulative and deceptive route requires the technique to be deployed purposefully. The subliminal route is written without that same explicit intent requirement, focusing instead on whether the technique operates beyond a person's conscious awareness.

No. It only bans real-time remote biometric identification used in publicly accessible spaces for law enforcement purposes. Facial recognition used by private companies, or used after the fact rather than live, or used outside a publicly accessible space, falls under different rules, typically the high-risk framework in Annex III, point 1, rather than this prohibition.

Not inherently. The European Commission's guidelines state that personalising ads based on user preferences is not automatically manipulative, so long as the system does not deploy subliminal, purposefully manipulative, or deceptive techniques that subvert autonomy or exploit vulnerabilities.

Yes. Both providers and deployers are bound directly, each within their own responsibilities. Using a system built by someone else does not exempt a deployer if the system's actual behaviour meets the four-part test and is characterised by using manipulative AI techniques.

The Act does not set a numeric threshold. What has to be shown is that the material distortion of a person's decision-making causes, or is reasonably likely to cause, significant harm to that person, another person, or a group, assessed in the context of the specific technique and decision involved.

Locations that are open to the public, such as streets, squares, train stations, or stadiums. The prohibition is specifically tied to this kind of space.

It falls into the highest fine tier under Article 99: up to €35 million or 7% of global annual turnover, whichever is higher, the same tier that applies to every other prohibited practice under Article 5.

Both providers and deployers. Building a banned system or simply using one someone else built are both violations.

Eight categories of AI practice have been prohibited since 2 February 2025 under Article 5. They are: subliminal manipulation techniques that bypass conscious awareness; exploitation of vulnerabilities of specific groups; social scoring by public or private actors; real-time remote biometric identification in publicly accessible spaces (with narrow law enforcement exceptions); biometric categorisation by sensitive attributes such as race or political opinion; inference of emotions in workplace or educational settings; untargeted scraping of facial images to build recognition databases; and predictive policing based on individual profiling.

The EU AI Act prohibits the use of emotion recognition systems in the workplace and in educational settings. The ban covers inferring emotional states from physiological signals, facial expressions, or behavioural data. Tools that monitor physical health metrics without inferring emotional states may fall outside the prohibition, but the boundary is narrow and legal advice is warranted before deployment.

The manipulation ban targets techniques that operate below conscious awareness to distort behaviour in ways that harm the individual. Standard personalisation and recommendation systems that operate transparently and within user expectations are not automatically prohibited. The closer a system comes to exploiting psychological vulnerabilities or operating subliminally, the greater the risk of falling within Article 5.

Yes, at the top tier. The AI Act's Article 5 tier of €35 million or 7% of the global annual turnover is higher than GDPR's highest tier of €20 million or 4% of the global annual turnover. The AI Act's second tier of €15 million or 3% is broadly comparable to GDPR's lower tier of €10 million or 2%.

The Act's market surveillance framework is built for cross-border coordination between national authorities, with the AI Office and the Board coordinating consistent practice across the EU, though the specific procedural mechanics depend on where the operator is established.

No. Under Article 99(6), SMEs and startups are fined the lower of the fixed amount or the percentage of turnover, rather than the higher. The Digital Omnibus extends this same treatment to a new "small mid-cap" category of companies with up to 750 employees and €150 million in annual revenue.

Not necessarily. Member states can appoint existing public bodies, such as a data protection authority, competition authority, or accreditation body, to act as their notifying authority or market surveillance authority, based on their own administrative structure.

No. The Article 5 prohibitions have applied since 2 February 2025 regardless of national implementing legislation, and the AP has been preparing to supervise them since before that date. What the draft law settles is the formal legal basis for which authority issues fines and takes enforcement action nationally.

Not in the sense of a substantive AI law. The EU AI Act is directly applicable. The Netherlands is finalising an implementation law, the Uitvoeringswet AI-verordening, that designates which national authorities can supervise it and issue fines, rather than writing new substantive AI rules of its own.

No. The Digital Omnibus does not amend the €35 million or 7% global annual turnover, €15 million/3%, or €7.5 million/1% figures in Article 99, or the €15 million/3% figure in Article 101. It changes the compliance timeline for stand-alone Annex III high-risk systems, extends SME-style proportionality to small mid-cap companies, and gives the AI Office expanded enforcement powers.

Yes, in two respects. The AI Office now holds exclusive competence over AI systems built on a general-purpose AI model where the model and the system come from the same provider, and over AI systems integrated into, or constituting, very large online platforms or very large online search engines. National authorities keep their existing competence in law enforcement, border management, judicial authorities, and financial institutions.

No. The draft went out for public consultation on 20 April 2026 and was expected to reach the House of Representatives in the fourth quarter of 2026, but had not been adopted as of July 2026.

No. The Dutch AI draft law splits supervision across eight existing sector-specific authorities rather than creating a new one, so organisations continue to deal with the regulator they already know for their sector.

That can be fined on its own, independent of whether the underlying AI system was actually non-compliant, under the third tier of Article 99: up to €7.5 million or 1% of global annual turnover.

A notifying authority sets up and runs the procedures for assessing, designating, and monitoring notified bodies, the organisations that carry out third-party conformity assessments. A market surveillance authority investigates and enforces compliance directly, including issuing fines. A member state can assign both roles to the same body or to two different ones.

Article 99, the general fine mechanism, has applied since 2 August 2025, alongside the GPAI obligations and the governance chapter. Article 101, the fine specific to providers of general-purpose AI models, is the one exception: it applies a year later, from 2 August 2026. Either way, a fine for a specific obligation, such as a high-risk system requirement, can't attach until that obligation itself becomes binding, regardless of when the fine article itself took effect.

Chapter VII, covering the AI Office, the European Artificial Intelligence Board, and the national competent authority framework, applied from 2 August 2025, alongside the GPAI obligations and most of the penalties chapter.

The Authority for the Financial Markets (AFM) and the Dutch Central Bank (DNB) are designated to supervise high-risk AI, prohibited practices, and transparency obligations in financial services.

National market surveillance authorities enforce most violations, including high-risk system and Article 50 transparency breaches. The European Commission, through the AI Office, enforces fines against providers of general-purpose AI models directly, under Article 101.

The AI Office, part of the European Commission, enforces these obligations directly under Article 88 and issues fines under Article 101, rather than national market surveillance authorities.

The Dutch Authority for Digital Infrastructure (RDI) is designated as the single point of contact under Article 70(2), working jointly with the Dutch Data Protection Authority (AP) to coordinate the overall system.

The Act sets three fine tiers. Violations of the prohibited practices under Article 5 carry fines of up to €35 million or 7% of global annual turnover, whichever is higher. Violations of high-risk system obligations carry fines of up to €15 million or 3% of global annual turnover. Providing incorrect or misleading information to authorities carries fines of up to €7.5 million or 1% of turnover. For SMEs, the lower of the two thresholds applies in each case.

For most AI systems, enforcement sits with national Market Surveillance Authorities designated by each member state. Under Article 99, the general fine mechanism has applied since 2 August 2025. For providers of general-purpose AI models, the AI Office holds primary enforcement authority and can impose fines directly under Article 101, which applies from 2 August 2026. The Digital Omnibus also gives the AI Office exclusive competence over AI systems built on a general-purpose AI model where the model and the system are developed by the same provider, and over AI systems integrated into, or constituting, very large online platforms or very large online search engines.

A serious incident is any incident that results in, or could plausibly result in, the death of a person, serious injury, significant damage to property, or a significant disruption to critical infrastructure. It also covers situations where fundamental rights are seriously and irreversibly affected. Providers and deployers of high-risk AI systems must report serious incidents to the relevant national authority without undue delay.

The Act does not specify a single reporting window but requires reporting "without undue delay." Guidance and national implementations are converging on 15 working days as the operative standard for most serious incidents, with shorter windows (72 hours in some national interpretations) for the most severe cases. Organisations should treat this as an operational planning constraint and build detection and escalation processes accordingly.

The Act does not name agents as a separate category. An agent is governed according to the risk classification of the system it belongs to. In practice, an agent operating in a high-risk use case inherits the Article 9 to 15 requirements, and its deployer inherits the Article 26 duties.

It's best to have a structured compliance checklist in place: start with a complete inventory of every agent and model, classify each by risk, and attach model-level monitoring, explainability, human oversight, and automatic audit trails mapped to the Act's requirements. A dedicated governance platform such as Deeploy centralises this so the evidence exists before an audit asks for it.

Traditional automation follows fixed logic with predictable execution paths. Agents reason probabilistically, adapt their behaviour and select tools dynamically. Governance therefore has to assess not only what an agent is configured to do, but how it decides to act as conditions change.

Estimates vary by definition. Salesforce's 2026 Connectivity Benchmark puts the average large enterprise at about 12 visible agents today, rising to roughly 20 by 2027. Gartner forecasts more than 150,000 agents at the average Global Fortune 500 firm by 2028 once fine-grained sub-agents are counted. The counts differ because "an agent" is not a standardised unit across sources.

AI agent governance is the structured approach an organisation uses to define how autonomous AI agents operate, what they can access and how their actions are monitored and recorded. It covers registration, identity and access boundaries, runtime controls, audit trails and lifecycle management, so that agents remain accountable enterprise assets rather than unmanaged exposure.

AI agent sprawl is the uncontrolled growth of AI agents across an organisation, where new agents are created faster than they can be inventoried, governed, or retired. It typically results from low-code tools letting business units deploy agents without informing IT, security, or data governance, leaving no single record of what exists.

What's the minimum obligation that applies even to a low-risk AI system? Article 4 AI literacy. It applies to every provider and deployer of any AI system, regardless of risk tier, and is the one item on this checklist with no exceptions.

It is cross-functional. The CISO or Head of AI usually sponsors it, while operational ownership spans security architecture for policy enforcement, identity governance for delegation boundaries, platform teams for integration oversight, and AI enablement teams for the deployment lifecycle. Clear accountability prevents supervision fragmenting across departments.

The most commonly recommended first step is a complete AI system inventory. Without knowing every AI system in use across the organisation, including tools adopted by individual teams without central approval, you cannot complete risk classification, assign roles, or identify which obligations apply.

More than 80% of workers use unapproved AI tools in their jobs, making shadow AI one of the most significant compliance risks for organisations that have not yet mapped their AI landscape.

Shadow AI refers to AI tools used by employees without organisational approval or governance oversight. Examples include personal subscriptions to ChatGPT, AI browser extensions, and department-level tool procurements outside IT review. If any of these tools are used for high-risk purposes, the organisation carries compliance exposure it is not aware of. National authorities will ask what AI systems an organisation operates, not just what it has officially approved.

A Fundamental Rights Impact Assessment (FRIA) is a structured assessment of the impact of a high-risk AI system on fundamental rights, required under Article 27. It applies to deployers who are bodies governed by public law, or private entities providing public services such as banking, insurance, or education. It must be completed before the system is first put into use and updated if deployment conditions change materially. It is distinct from a DPIA but should be conducted in parallel where both apply.

The two frameworks are complementary and share significant infrastructure. Records of Processing Activities, DPIAs, data subject rights workflows, and consent management are all relevant to AI systems that process personal data. Organisations with mature GDPR programmes have a head start, but should not assume GDPR compliance equals EU AI Act compliance. The EU AI Act adds obligations that go beyond data protection, including risk management systems, human oversight requirements, and post-market monitoring that have no direct GDPR equivalent.

The Act does not mandate a named AI compliance officer role, but it does require deployers to assign a human oversight person with sufficient authority and competence to intervene in the operation of high-risk AI systems. In practice, organisations are creating AI governance functions that combine this oversight role with broader compliance responsibilities.

Article 4 requires both providers and deployers to ensure that staff involved in the operation and use of AI systems have a sufficient level of AI literacy, taking into account their role and the specific systems they work with. The Act does not prescribe a specific training format or number of hours. What it requires is demonstrable, role-appropriate understanding; which means you need to document what training was given, to whom, and when.

Yes, though the obligation sits with whoever builds and places the resulting application on the market, not with the GPAI model provider. A company building a high-risk system on top of a third-party model such as GPT-4 or Claude is the provider of that high-risk system, even though it is only a deployer of the underlying GPAI model, and remains responsible for monitoring the system's real-world performance under Articles 9, 15, and 72 regardless of whether the underlying model itself changes. If the GPAI provider updates the model in a way that affects the application's behaviour, that is exactly the kind of change this monitoring is meant to catch.

At least six months, under Article 26(6), for logs generated automatically by the system and under the deployer's control.

When does model drift become a reportable serious incident? Only when it results in, or could plausibly result in, death, serious injury, significant property damage, a significant disruption to critical infrastructure, or a serious and irreversible infringement of fundamental rights obligations under Article 73. Ordinary performance decline below that threshold is a monitoring finding, not a reporting event.

It isn't named directly. The Regulation doesn't use the term ‘model drift’ anywhere. What it does contain are several separate provisions, Article 9's continuous risk management duty, Article 15's accuracy requirement, and Article 72's post-market monitoring plan, that describe the same underlying problem without naming it.

Both, with different duties. The provider builds the monitoring capability and runs the post-market monitoring plan under Article 72. The deployer monitors the system in its own environment under Article 26(5) and reports what it sees back to the provider.

Post-market monitoring is the ongoing obligation to track how a high-risk AI system performs once it is deployed. Under Article 72, providers must establish a post-market monitoring plan before deployment covering the metrics to be tracked, the data to be collected, the review frequency, and the conditions that would trigger corrective action or re-assessment. Deployers must monitor the system's operation and report relevant findings back to the provider.

Any significant change to the AI system's design, intended purpose, or risk profile can trigger the need for a new conformity assessment. This includes retraining on substantially different data, modifications that affect the system's performance on safety-relevant tasks, or repurposing the system for a new use case. Routine maintenance and minor updates that do not affect the system's fundamental behaviour generally do not require re-assessment.

Model drift, where a system's performance degrades over time due to changes in the input data distribution, is a compliance concern under Article 9(7), which requires risk management to be continuous throughout the AI system's lifecycle.

Organisations are expected to detect drift, assess whether it affects the system's compliance with the EU AI Act's requirements, and take corrective action where necessary. This requires ongoing monitoring infrastructure, not just point-in-time audits.

Yes. SMEs benefit from several provisions. They are entitled to free access to national AI regulatory sandboxes, can prepare simplified technical documentation and quality management systems for high-risk AI, and are subject to the lower of the two fine thresholds in each penalty tier. Under the Digital Omnibus, Regulation (EU) 2026/1744, these concessions are extended to small mid-cap companies, potentially covering an additional 8,250 businesses across Europe.

Yes. The Act has extraterritorial reach. Any organisation that places an AI system on the EU market or whose AI system produces outputs used in the EU is in scope. Non-EU providers placing high-risk AI on the EU market must either designate an EU-based authorised representative or ensure an EU-based importer takes on the relevant obligations.

AI systems used exclusively for research, development, and prototyping before they are placed on the market are generally exempt. Once a system moves from a testing environment into operational deployment, even internally, the relevant obligations apply. GPAI models used before release for research activities are also explicitly excluded from the GPAI definition.

The scope of Annex III Point 4 is broad and covers AI used at any stage of a recruitment or selection process, including initial CV filtering. The purpose of the system, not the extent of its involvement in the final decision, determines whether it is high-risk. A tool that filters out candidates before a human ever reviews them has a direct and consequential effect on those individuals and sits squarely within the high-risk category.