Important duties already apply. Original prohibitions and literacy began applying on 2 February 2025; GPAI Chapter V on 2 August 2025, with an older model transition; Article 50 generally on 2 August 2026. Principal Chapter III Sections 1 through 3 high-risk dates are 2 December 2027 for Annex III and 2 August 2028 for Annex I, with Article 6(5), scope and transitions treated separately.
Non-EU organizations can fall within scope. Start with the system, intended use, legal entity, role and territorial connection. Then identify who can implement each applicable obligation and what evidence would help examine the result.
What the EU AI Act is
The EU AI Act is Regulation (EU) 2024/1689, amended in this research baseline by Regulation (EU) 2026/1744. Each obligation family has its own conditions and application dates. The July 2026 amendment is adopted law in the baseline, rather than an assumed future proposal.
The Act is intended to reduce specific harms from AI. It prohibits certain practices, requires disclosure in some AI interactions and content, and imposes stricter rules on systems classified as high-risk.
For companies, this means AI governance cannot stop with a list of approved tools. It must also cover how those tools are used, what data they rely on, who oversees them, and how their performance is tested, especially when they can affect people.
An AI system has a functional legal definition. Article 3 describes a machine-based system that operates with varying autonomy, may adapt after deployment, and infers from input how to generate outputs for explicit or implicit objectives that can influence physical or virtual environments. A vendor's AI branding does not settle that test. A GPAI model is a separate object with its own definition and provider obligations.
What matters now
The amended high-risk timetable gives organizations more time to prepare for major structural requirements. It does not suspend duties that already apply. A customer interface, a publication process and an internal AI training program can raise immediate questions even when the system is outside the high-risk routes.
| Area | Position at the source cutoff | Key qualification |
|---|---|---|
| Original Article 5 prohibitions | Applicable since 2 February 2025 | Each prohibition has its own conditions and exceptions. |
| Article 4 AI literacy | Already applicable; amended wording entered into force on 27 July 2026 | Measures remain mandatory, but no specific individual attainment level is guaranteed by law. |
| GPAI Chapter V | Applicable since 2 August 2025 | Models placed before that date have a 2 August 2027 transition. |
| Article 50 transparency | Generally applicable since 2 August 2026 | The December 2026 old-system transition concerns paragraph 2 only. |
| Chapter III Sections 1 through 3 | Principal Annex III/Annex I dates are 2 December 2027 and 2 August 2028 | Article 6(5), sector scope and existing-system transitions need separate treatment. |
Enforcement is also differentiated. Member State authorities supervise systems under the relevant competence rules. The Commission has exclusive Chapter V GPAI supervision, entrusted to the AI Office. The amendments add specific Office competence for certain systems. There is no single regulator or enforcement-start statement that correctly describes every branch.
Read the implementation timeline for dates and transition boundaries.
Who can be affected
Article 2 covers providers placing AI systems on the EU market or putting them into service, and providers placing GPAI models on that market, irrespective of where they are established. It also covers deployers established or located in the EU, and third-country providers and deployers where AI system output is used in the EU. Other specified supply-chain actors are included. Headquarters location alone does not resolve scope.
For a multinational group, the operational question is which legal entity performs which activity. An overseas parent, an EU operating subsidiary and a supplier can occupy different roles around the same deployment. A globally accessible website presents a scope question; the baseline does not establish that accessibility alone automatically satisfies the statutory output-use test.
Exclusions are conditional. Sole-purpose scientific research and certain pre-market development activities have exclusions, but real-world testing is not excluded by Article 2(8). Purely personal, non-professional use concerns natural persons rather than ordinary corporate activity. Free/open-source systems do not receive that exclusion where they are high-risk or covered by Articles 5 or 50.
The U.S. companies page explains the connecting factors and evidence needed to examine them.
Why provider and deployer are different
A provider develops or has developed an AI system or GPAI model and places it on the market, or puts an AI system into service, under its own name or trademark, whether paid or free. System putting into service can include first own use; model placement is a separate branch. A deployer uses an AI system under its authority, apart from purely personal non-professional use. The terms describe activities around an asset, rather than permanent corporate identities.
One organization can therefore need separate role analyses for a purchased application, an internally developed system and a customer-facing product. Using a third-party model does not itself answer whether the organization is the provider of the resulting system. It also does not automatically make the organization a GPAI model provider.
Article 25 can make another actor the provider of a high-risk system in specified circumstances. These include supplying a high-risk system under its own name, substantially modifying a system that remains high-risk, or changing the intended purpose so a system that was not high-risk becomes high-risk. Model modification requires a different analysis under Article 3 and GPAI guidance. A contract can allocate work, but the legal role still depends on the actual facts.
See provider vs deployer before assigning an obligation to an internal owner or supplier.
The principal obligation families
Prohibited practices
Article 5 prohibits specified practices within defined conditions. Examples include materially harmful manipulation, exploitation of vulnerabilities, social scoring, untargeted facial-image scraping and emotion inference in workplaces or education, with the qualifications of the relevant point. Avoid turning the list into broad labels that prohibit every persuasive interface, personalized service or workplace analytics tool.
The amendment adds two separate sexual-content prohibitions applicable from 2 December 2026. The baseline records intended-purpose, foreseeability, reproducibility and safeguard conditions. The 2025 prohibited-practices guidelines predate these additions. Their interpretation remains an area for further review.
Operationally, screening should examine the proposed function, affected population and actual workflow before approval. A policy naming Article 5 categories cannot show that a particular use has passed the relevant conditions.
Transparency
Article 50 separates human-AI interaction disclosure, provider marking/detectability of synthetic output, notices for emotion recognition and biometric categorisation, and deployer disclosures for deepfakes and qualifying public-interest text. These duties are not interchangeable. A visible notice does not demonstrate technical marking, and human editorial review does not remove a provider's separate paragraph 2 obligation.
Disclosure information must be clear and distinguishable, provided by first interaction or exposure, and accessible as required by paragraph 5. That makes interface delivery and publication behavior important, rather than the existence of a notice somewhere in a policy library.
The Article 50 page distinguishes each branch, its exceptions and suitable implementation evidence.
AI literacy
Amended Article 4 requires providers and deployers to take measures supporting development of AI literacy for staff and other people operating or using AI on their behalf. Measures account for knowledge, experience, education and training, use context and affected people. The law expressly excludes guaranteeing a specific individual literacy level.
The Commission Q&A says a certificate is not needed, Article 4 does not mandate an AI officer or particular governance structure, and measures can vary with context. Those are official nonbinding interpretations. They do not erase separate high-risk human-oversight duties.
The AI literacy page explains how to organize proportionate measures without inventing a universal course or pass mark.
GPAI models
GPAI provider duties include technical documentation, information for downstream system providers, a copyright-compliance policy and a sufficiently detailed public training-content summary using the AI Office template. Qualifying open-source models receive limited documentation exceptions; copyright and summary duties remain. Systemic-risk model providers have additional evaluation, risk, incident and security duties.
An enterprise integrating a model should separate upstream model documentation from its own system design and operating records. A model report can inform system evaluation. It cannot, by itself, establish that a customer interface gives a required notice or that a deployer can intervene in a particular workflow. This is an operational implication, not an extra model-provider duty.
High-risk systems
High-risk classification has two principal routes. Annex I requires both the specified product or safety-component connection and the required third-party conformity-assessment condition. Annex III identifies particular uses. Industry membership alone does not establish either route.
The Annex III derogation under Article 6(3) needs the overarching no-significant-risk condition and at least one of four task conditions. An Annex III system performing profiling of natural persons is always high-risk. A provider relying on the derogation needs documentation and the retained registration required by the law.
The core requirements include risk management, data governance, documentation, automatic logging, information for deployers, human oversight, accuracy, robustness and cybersecurity. Their principal amended route dates are future dates at this cutoff. Deployer operating duties differ from provider design duties.
Read high-risk AI for routes, requirements and the limits of blanket date statements.
What organizations need to organize
The operational task is to connect applicability decisions to implementation. Begin with a system inventory that distinguishes models, uses, intended purposes, legal entities, roles, jurisdictions, versions and relevant history. This record design is our recommendation. The Act does not prescribe this complete inventory format or a particular governance platform.
For each applicable obligation, identify the control objective, implementation owner, procedure or configuration, and evidence that would help examine whether it works. A disclosure screenshot can demonstrate presentation in one version. It cannot prove that all users saw it at their first interaction. Training attendance records show participation; they do not prove that every operator exercises effective oversight. Testing must match the conclusion being drawn.
Readiness work should also identify supplier dependencies early. A downstream team may need model capabilities and limitations, technical instructions, access to logs or the ability to change a UI. If those dependencies remain unresolved, writing an internal policy will not produce the missing technical capability. This is practical implementation analysis derived from the separation of provider information and deployer operations.
The operational readiness page provides a sequence without a compliance score or certification claim.
An illustrative governance decision
Suppose an enterprise introduces a model-powered application for service agents, then adds a customer chat interface and later uses generated text in public communications. This is a fictional planning example. It does not establish the legal status of a real deployment.
The governance record should show what changed. The underlying model might be unchanged, while the system interface, audience and publication purpose differ. Provider/deployer analysis, Article 50 paragraph 1 interaction, paragraph 2 marking and paragraph 4 public-interest-text disclosure then require separate examination. The facts and statutory conditions determine the answer.
Operationally, the team needs more than a new policy version. It needs to identify who can alter the customer interface, which output paths need examination, who controls publication and which records describe the released behavior. Existing model evidence may remain relevant to capabilities. New system and workflow evidence may be needed for the changed interaction and publication. These are implementation recommendations, not an invented requirement to collect every possible record.
The example also explains why executive ownership matters. A legal conclusion may depend on a purpose or operating fact that only the business team can confirm. A technical control may depend on a supplier feature that only procurement can negotiate. An evidence question may depend on logging or release practices controlled by engineering. The responsible executive's job is to connect those decisions and expose unresolved dependencies, while legal reviewers retain responsibility for consequential legal determinations.
How linked records could help
Large organizations need to reason across AI system, use case, model, data, legal role, jurisdiction, obligation, control, owner and evidence. One model may support several systems; a shared control may support multiple requirements; an evidence artifact has a particular version and time scope. Regulatory changes can require review of downstream interpretations and implementations.
Our proposal is to record those relationships explicitly instead of leaving them across disconnected documents or spreadsheet rows. A well-managed spreadsheet can work at an early stage. It becomes harder to maintain when references, exceptions and ownership decisions diverge across teams. The Act does not mandate this approach or require ontology technology.
What remains unsettled
The source review establishes statutory Article 50 duties but leaves the formal adoption status of the inspected guidance unresolved. High-risk classification guidance remained draft in the inspected materials, with final adoption officially expected by the end of 2026. An expectation is not adopted guidance.
Standards publication is also distinct from legal effect. EN 18286:2026 publication is supported by the archive. The review did not locate an AI Act harmonised-standard OJ reference in the sources searched, but that is a bounded finding. Article 40 presumption depends on an actual OJ reference and extends only to covered requirements.
The research separately flags Article 72/73 temporal coverage, internally developed older generative-system transitions, product/dual-route integration and GPAI modification edge cases. These need targeted review. They do not justify treating all current obligations as optional or all future high-risk systems as subject to identical duties today.
Common questions
Does the AI Act apply only to high-risk AI?
No. Article 4 literacy, Article 5 prohibitions, Article 50 transparency and GPAI duties have their own scope. A finding that a system is outside the high-risk routes does not resolve those other branches.
Are all high-risk requirements delayed until 2028?
No. The principal Annex III date is 2 December 2027. The Annex I date is 2 August 2028. The express postponement covers Chapter III Sections 1 through 3, except Article 6(5); Chapter IX timing and coverage need separate analysis.
Does an ISO certificate establish AI Act compliance?
A certificate alone does not establish the Article 40 presumption. That requires an OJ-cited harmonised standard and applies only to covered requirements. Commission Q&A also distinguishes ISO 42001 from the AI Act quality-management-system requirements.
What is the practical first step?
Use the readiness sequence to identify systems, roles and territorial facts, screen active obligation families, and assemble implementation evidence. This is our recommended planning approach, not an individual legal determination.
Next step
Review the 2026 to 2028 timeline, then use the operational readiness sequence with the relevant system owners.
Primary sources
Use the consolidated text to navigate provisions and the authentic original and amending Official Journal acts for the legislation. Guidance and Q&A retain their separate legal status.
- Consolidated text: Regulation (EU) 2024/1689, 27 July 2026 · legislation.
- Regulation (EU) 2024/1689 of 13 June 2024 · legislation.
- Regulation (EU) 2026/1744 of 8 July 2026 · legislation.
- Guidelines on transparency obligations for providers and deployers of AI systems · official information, nonbinding.
- Approval of the content of the draft Communication : Guidelines under Article 50 · draft guidance.
- Guidelines on transparency obligations for providers and deployers of certain AI systems · official information, nonbinding.
- AI literacy: Questions & Answers · official information, nonbinding.
- Targeted consultation on draft high-risk classification guidelines · official information, nonbinding.
- Commission Guidelines on the scope of obligations for providers of general-purpose AI models · final Commission guidance.
- Understanding standardisation in the AI Act · official information, nonbinding.
- CEN/CLC JTC 21 AI Standards Catalogue : public data · standards body information.
- Publication de la EN 18286:2026 : une première norme européenne pour soutenir la mise en œuvre de l’AI Act · official information, nonbinding.
- Harmonised Standards : references published in the OJEU · official information, nonbinding.
- Commission Guidelines on prohibited artificial intelligence practices · final Commission guidance.