AI Act in 2026: how to decide whether an AI system triggers obligations, what evidence to gather, and when a person must intervene

Scope of this guide: a traceable decision, not a legal opinion

This guide is for product, security, compliance, procurement, and technology teams that develop, integrate, distribute, or use AI systems connected with the European Union market. Its purpose is to turn a use case into an auditable record: what the system does, who participates in the supply chain, where it is used, which category may be relevant, which obligations are in force, and what evidence exists.

It is not intended to conclusively resolve the legal classification of a particular product. Application of the AI Act depends on the facts, intended purpose, actual configuration, the actors making decisions and, in certain sectors, additional rules. Privacy, employment, credit, medical devices, aviation, biometrics, and the delivery of public services may require assessment under separate frameworks.

Dates matter, but there is no single application date for the entire Regulation. The European Commission presents a phased timetable: some rules, including those on prohibited practices and AI literacy, became applicable before the general regime. In addition, a subsequent legislative amendment changes the timetable for certain obligations concerning high-risk systems.

Use this article as a governance procedure. To explore operational controls, see the Safety section; to assess technical and provider alternatives, see Compare; and to put capabilities and use cases into context, see Discover.

Step 1: define the use case before assessing risk

The unit of analysis should not be only a tool’s commercial name. It may be a specific function, a model version, an automated workflow, or an integration. The same product can contain functions with different levels of exposure: summarising internal documents is not equivalent to ranking people for a benefit, or to making changes in an external account.

Document the intended purpose stated by the party offering the system and the effective purpose that your organisation configures or permits. Include territories where the system is placed on the market, used, or where its results are made available; potentially affected groups; the operating environment; lifecycle stage; interfaces; and enabled downstream actions. Retain configuration captures, contracts, instructions, assessments, and versions.

Also identify whether this is a general-purpose AI model, a system built on such a model, or both. The Commission’s guidelines on general-purpose AI models are interpretative and help distinguish the obligations of the model provider from those of an actor offering or deploying a downstream system. They do not replace the Regulation or judicial interpretation.

Step 2: identify the role by activity, not by the contract label

An organisation can perform more than one role in relation to different products or components. A contract label—for example, “customer”, “partner”, or “reseller”—does not by itself determine the outcome. What matters for the analysis is which actor develops, commissions development of, markets, puts into service, imports, distributes, modifies, or uses the system under its authority.

As an operational framework, treat as a possible provider the actor that develops an AI system or model, or has it developed, and markets it or puts it into service under its name or trademark. Treat as a possible deployer the actor that uses an AI system under its authority, except for personal non-professional use. Importer and distributor are commercial-chain roles that require review of how the system is introduced or made available in the Union. An authorised representative requires verifiable designation and mandate.

A substantial modification, a change of purpose, or marketing under your own brand are signals to stop the automatic workflow and request specialist review. Available guidance on the scope of obligations for providers of general-purpose AI models addresses, among other matters, identification of the provider, placing on the market, and modifications; its status as interpretative guidance should be recorded in the file.

Step 3: classify the use and keep non-interchangeable categories separate

Start by ruling out whether the case may relate to a prohibited practice. Prohibited practices have an application regime that predates the general timetable. The Commission has published guidelines on these practices; they are useful for structuring questions and examples, but final authoritative interpretation belongs to the competent courts of the Union.

Then assess, without assuming the answer, four distinct dimensions: whether the system could qualify as high-risk because it is a safety component of a regulated product or because of another regulated circumstance; whether its use case could fall within high-risk categories; whether it triggers transparency duties; and whether a general-purpose AI model is involved. A system may require transparency without being high-risk. A general-purpose AI model does not automatically amount to a high-risk system deployed by a third party.

Do not turn a sector list into a diagnosis. The specific purpose, impact on people, operational autonomy, deployment context, and applicable exceptions may change the conclusion. If the system affects employment, education, access to essential services, credit, health, biometrics, administration of justice, or public services, make legal and sector-specific review an exit condition.

Step 4: build a timetable for each obligation and condition

Planning should link each obligation to an activation condition, rather than relying on one global date. The Commission’s framework indicates that prohibited practices and AI literacy obligations apply from 2 February 2025. Obligations relating to general-purpose AI models and certain governance provisions began before the general regime, on 2 August 2025. The general regime uses 2 August 2026 as its reference date, subject to the stated exceptions.

For high-risk systems, do not automatically reuse earlier dates. The legislative amendment published in 2026 postpones application linked to Annex III systems and systems related to Annex I on a differentiated timetable: 2 December 2027 for one group and 2 August 2028 for the other. The precise mapping must be validated against the consolidated text and the system’s circumstances.

The Commission’s transparency guidelines published in 2026 are presented as guidance on the practical scope of obligations applicable from 2 August 2026. Use them to design controls and evidence, not to replace analysis of the legal text or later acts.

Step 5: translate requirements into operational evidence

An obligation is manageable only when it is linked to an owner, a source, a date, a version, and evidence of execution. The file must not consist of a generic commercial statement. It should allow someone to reconstruct which system was assessed, for what purpose, with which configuration, which controls were applied, and which decision was made.

For a case that may be high-risk, commonly relevant areas include risk management, data governance and quality where relevant, technical documentation, logging, information for deployers, human oversight, accuracy, robustness, and cybersecurity. Specific applicability depends on classification and role. Do not state that a control meets a requirement unless its scope, testing, and evidence have been checked.

Human oversight is not demonstrated by saying that “a person is in the loop”. Describe what the person can see, when they intervene, what authority they have to disregard or stop an output, what training they receive, how alerts are handled, and what happens in cases of excessive automation. If they cannot materially intervene before a relevant consequence, document that limitation.

Step 6: apply the analysis to third-party procurement and integration

Buying a system or API does not eliminate the responsibilities of the party configuring and using it. The buying organisation should distinguish documentation received from the provider from evidence generated about its own implementation. For example, the provider may supply instructions, declared characteristics, and conformity documentation where applicable; the deployer should be able to explain the local purpose, authorised users, connected data, permissions, and decisions made after an output.

Include compliance questions in selection, contracting, technical acceptance, and periodic review. Request information at a level of detail proportionate to the intended use. If the provider refuses to identify the version, material changes, known limits, conditions of use, or incident mechanism, treat missing information as an acquisition risk rather than a minor administrative issue.

The general-purpose AI Code of Practice, published in 2025 and regarded by the Commission as a suitable voluntary tool, can be a useful documentary signal in some cases. It does not by itself demonstrate legal compliance and does not replace evidence specific to the integrated system.

Three scenarios: which facts change the analysis

Scenario one: an internal assistant drafts content from documents manually uploaded by the team. If it does not make decisions about people, does not execute external actions, and is used with substantive human review, the initial file may focus on purpose, data, user information, permissions, providers, and training. The classification changes, however, if drafts are used for employment, credit, health, or access-to-service decisions without effective review.

Scenario two: a system prioritises customer requests. The term “prioritisation” resolves nothing. What matters is whether it merely orders an operational queue or effectively determines who receives a service, within what timeframe, under what conditions, and with what opportunity for correction. Variables, rules, metrics, known biases, override owners, and the effects of false positives and negatives should be documented.

Scenario three: an agent can send emails, change records, or trigger actions in external tools. The decisive fact is not that it uses natural language, but the scope of its permissions, reversibility of actions, authorisation thresholds, the identity executing the action, and pre- and post-action controls. Broad execution capability may require a more intensive security assessment even where regulatory classification remains uncertain.

Text template for an applicability record

Maintain one record for each use case and update it when purpose, model, integration, provider, data, or affected population changes. Product, security, procurement, and compliance should be able to read the record without having to reconstruct decisions from isolated messages or meetings.

It is better to record uncertainty explicitly than to close a classification without a sufficient basis. Mark which conclusion is a documented fact, which item is internal analysis, and which matter awaits legal, technical, or contractual confirmation.

Common errors and when to stop and escalate

A common mistake is assuming that the provider absorbs all responsibility. Another is accepting a commercial conformity statement without checking which product, version, purpose, and actor it covers. It is also common to use one date for the entire Regulation, or to turn risk assessment into a checkbox that is not revisited after a technical or contextual change.

Stop deployment or expansion and escalate for legal advice where there may be a prohibited practice; reasonable uncertainty about high risk; sensitive processing or decisions with significant effects on people; biometrics; employment; credit; health; education; public services; policing or judicial activity; complex cross-border marketing; substantial modification; or a conflict between declared purpose and actual use.

Escalation does not mean permanently blocking the product. It means framing a specific question, attaching facts and evidence, identifying the pending decision, and preserving the version of the system that was assessed. This discipline enables legal, privacy, security, or fundamental-rights review to be faster and verifiable.

Keep exploring

Corrections and transparency

If you spot incorrect or outdated information, send us a correction with the page and source we should review.