AI Act,
from inventory to proof.

Turn AI Act obligations into decisions for each use case

A procurement assistant and a recruitment-ranking system may use similar underlying technology but create different legal obligations. Start with what the system does, who uses its output and whose interests it affects. Then identify your organisation’s role. Buying a model, integrating it into a product and deploying a finished application are not interchangeable activities under the AI Act.

This guide reflects official information available in November 2026, including the AI Omnibus that entered into force on 27 July 2026. Earlier implementation charts can now lead teams to the wrong deadline.

Who falls within scope?

Regulation (EU) 2024/1689 covers providers placing AI systems or general-purpose AI models on the EU market, deployers established or located in the EU, and other specified supply-chain actors. Certain providers and deployers outside the EU are also covered when system output is used in the Union. There is no blanket exemption simply because the business is small or its supplier is overseas.

Assess the actual role for each activity. A deployer uses a system under its authority; a provider develops, or has a system developed, and places it on the market or puts it into service under its name. Rebranding or substantial modification can change responsibilities. Buying a tool does not automatically transfer all compliance duties to the vendor.

An internal register is a practical governance measure, not a claim that every AI use must be registered in an EU database. Record purpose, owner, supplier, affected people, input data and decisions supported. Check statutory exclusions separately rather than assuming every algorithm is covered.

What changed in the application timetable?

The Commission’s AI Act overview and AI Omnibus announcement are essential references for current planning:

• 1 August 2024: the AI Act entered into force; this was not universal application of every obligation.
• 2 February 2025: the original prohibited-practice rules and AI literacy provisions began applying.
• 2 August 2025: rules for general-purpose AI models began applying, subject to relevant transitional provisions.
• 19 November 2025: the Commission proposed the AI Omnibus; a proposal alone did not change the law.
• 27 July 2026: the AI Omnibus entered into force, amending the framework and extending high-risk deadlines.
• 2 August 2026: the general application milestone includes transparency rules; it no longer means all high-risk requirements apply.
• 2 December 2027: requirements apply for high-risk systems covered by Annex III.
• 2 August 2028: requirements apply for high-risk AI embedded in products covered by Annex I.

The Commission also identifies a new prohibition concerning AI generating non-consensual sexually explicit or intimate content, or child sexual abuse material, taking effect in December 2026. In November, distinguish that forthcoming rule from prohibitions already applicable since 2025.

The Omnibus amended Article 4 on AI literacy. Use the current provision rather than repeating the original wording as unchanged. Providers and deployers should organise appropriate literacy support, while the Commission and Member States have a strengthened supporting role. Role-based preparation remains important, particularly for people supervising consequential decisions.

Translate risk classification into requirements

First check prohibited practices. Workplace emotion recognition, for example, requires careful review of the prohibition and its exceptions; do not assume a managerial efficiency argument makes a use lawful.

Next assess high-risk classification against Article 6 and the relevant annex. Recruitment screening and certain creditworthiness decisions are examples requiring close analysis. Not every enterprise chatbot is high-risk, and the underlying model alone does not determine classification.

For high-risk providers, the core requirements include:

• risk management and appropriate data governance;
• technical documentation and logging capabilities;
• information enabling deployers to understand use and limitations;
• human oversight, accuracy, robustness and cybersecurity;
• quality management, applicable conformity procedures and post-market monitoring.

Deployers have their own responsibilities, including following instructions, assigning competent oversight and monitoring operation. A fundamental-rights impact assessment is required for specified deployers and uses, not automatically for every organisation using AI.

Article 50 transparency duties are a separate workstream. Depending on the actor and use, they concern disclosure of AI interaction, identifiability of generated content and labelling of specified synthetic content. Review the conditions and exceptions rather than adding the same notice everywhere. GDPR obligations remain relevant where personal data are processed.

Sanctions and operational exposure

Under Article 99, prohibited-practice infringements can attract fines up to €35 million or, for undertakings, 7% of worldwide annual turnover for the preceding financial year, whichever is higher. Other specified infringements can reach €15 million or 3%. SME ceilings use the lower applicable amount. These are ceilings, not automatic penalties for every documentation gap.

Authorities can also require corrective measures or restrict systems. Operational exposure includes withdrawing a feature, interrupting a workflow and explaining an unsupported decision to affected people. Model-provider enforcement has separate provisions; do not apply the headline prohibited-practice ceiling indiscriminately.

The official Article 99 text provides the detailed categories and penalty rules.

A step-by-step implementation path

1. Discover actual uses. Interview business owners and review procurement. Include embedded AI functions, not just projects explicitly labelled as AI.
2. Assign roles and owners. Document whether you provide, deploy, import or distribute each system. Escalate customisation and rebranding questions before signing commitments.
3. Record classification reasoning. Review prohibited practices, high-risk criteria and transparency duties. Preserve the purpose, evidence and approver behind each decision.
4. Map applicable dates. Distinguish requirements already in force from deferred high-risk duties. Check transitional treatment for existing systems and models individually.
5. Close evidence gaps. Request supplier instructions, limitations and relevant documentation. Define oversight, escalation and testing; verify that reviewers can actually challenge outputs.
6. Approve and monitor. Set conditions for release and reclassification triggers. Revisit changes in model, purpose, data and affected populations, and retain incident records.

How Domyno helps organise the programme

Domyno combines SaaS with a dedicated human expert: agents prepare work and a human validates it. Use asset management to structure the systems and dependencies behind the register, and Controls & compliance for controls, evidence and action plans across 28+ frameworks.

Risk analysis, supplier management and versioned documentation support the surrounding governance work. This does not make the platform a notified body or replace legal classification and any required conformity assessment. Owners remain accountable for deployment decisions and operational controls.

Bring a live use case and its supplier documentation to a Domyno demo to discuss a workable governance plan.