EU AI Act Compliance Guide: From Legal Duty to Evidence
Margareta Petrovic, Chief AI Officer, DigitalXForce. Last checked 5 November 2026.
EU AI Act compliance means knowing which AI systems your organization runs, which duties Regulation (EU) 2024/1689 places on you for each system, and being able to show evidence that those duties are met. Some duties already apply, and the high-risk rules follow on 2 December 2027 and 2 August 2028.
The Act sets out the duties. This guide covers the part a legal summary leaves open, which is how an enterprise turns each duty into a control with an owner, a test, a record and a trigger for looking again. For the requirements and dates alone, the EU AI Act requirements and timeline page is the shorter read.
This guide reads the consolidated text of the Act as at 27 July 2026, which includes Regulation (EU) 2026/1744, the Digital Omnibus on AI. AI governance is the set of policies, roles, controls and evidence an organization uses to decide which AI systems it runs, how they may be used and whether their controls keep working. What is AI governance explains how to run it continuously.
What applies now, and what comes next?
As of 5 November 2026, the original bans, the AI literacy duty, the rules for general-purpose AI model providers and the Article 50 transparency rules all apply, and enforcement has begun. The Digital Omnibus entered into force on 27 July 2026 and moved the high-risk rules to 2 December 2027 for Annex III and 2 August 2028 for Annex I.
EU AI Act dates, as of 5 November 2026
- In force1 Aug 2024The AI Act enters into force.
- Applies now2 Feb 2025Definitions, AI literacy and the original bans apply.
- Applies now2 Aug 2025Duties for general-purpose AI model providers and the governance rules apply.
- Applies now2 Aug 2026Most rules apply, including Article 50 transparency, and enforcement begins.
- Next2 Dec 2026Bans on non-consensual sexual deep fakes and child sexual abuse material apply, and older content generators reach their Article 50(2) deadline.
- Coming2 Aug 2027Each Member State should have an AI regulatory sandbox, and older general-purpose AI models must comply.
- Coming2 Dec 2027The rules for high-risk systems in Annex III apply.
- Coming2 Aug 2028The rules for high-risk AI in products under Annex I apply.
The later dates give an enterprise more time to build. They do not lift the duties that already bind it, and a team that waits for 2027 to find its AI will start with the step that takes longest.
What should a company do first?
A company should start with an inventory of every AI system in use, including AI embedded in software it already buys. Every later decision depends on that list, since a system nobody has recorded cannot be classified, assigned or tested. The order below runs from that first step to a working program.
- Build the inventory, with an owner for each system and the supplier behind it.
- Screen each use against the bans in Article 5, which already apply, and stop any use that falls inside them.
- Record each system’s risk category and your organization’s role, with the reason and the date.
- Write each duty that applies as a control with an owner and a test.
- Keep the evidence from each test, and set the events that send a system back to step 3.
Does the EU AI Act apply to a US company?
Yes, the EU AI Act can apply to a US company, even one with no office in the EU. Article 2 covers providers that place AI systems or general-purpose AI models on the EU market, wherever they are based, deployers established or located in the EU, and providers and deployers in a third country where the system’s output is used in the EU.
The practical test is therefore where each system’s output goes. A US employer that uses an AI tool to assess candidates for a role in Germany should treat that system as in scope until a documented review says otherwise.
Are we a provider or a deployer?
Your organization holds a role for each AI system, and one organization can be a provider for one system and a deployer for another. A provider develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. A deployer uses an AI system under its authority, outside personal, non-professional use.
The role can change after purchase. Article 25 makes a deployer the provider of a high-risk system in three cases: it puts its own name or trademark on the system, it substantially modifies the system, or it changes the intended purpose of a system so that the system becomes high risk.
The third case is the easiest to trigger by accident. A team that starts using a general-purpose assistant to rank job applicants has changed that assistant’s purpose, and recruitment is listed in Annex III, so the organization can take on provider duties without having bought or built anything new.
Who owes what: provider and deployer
| Duty | Provider | Deployer |
|---|---|---|
| AI literacy, Article 4 | Takes measures to support staff literacy | Takes measures to support staff literacy |
| Prohibited practices, Article 5 | Must not place or supply a banned system | Must not use a banned system |
| Risk management, Article 9 | Runs it across the lifecycle | No direct duty |
| Data, Article 10 and Article 26(4) | Governs training, validation and test data | Checks input data it controls |
| Technical documentation, Article 11 | Writes and keeps it | No direct duty |
| Logs, Articles 12, 19 and 26(6) | Builds logging in and keeps logs it controls | Keeps logs it controls for at least 6 months |
| Instructions, Articles 13 and 26(1) | Supplies them | Follows them |
| Human oversight, Articles 14 and 26(2) | Designs the system so people can oversee it | Assigns competent people |
| Accuracy and cybersecurity, Article 15 | Builds and tests for them | No direct duty |
| Conformity, Articles 43, 47 and 48 | Completes the assessment, declaration and CE marking | No direct duty |
| Monitoring, Articles 72 and 26(5) | Runs post-market monitoring | Monitors operation and informs the provider |
| Serious incidents, Articles 73 and 26(5) | Reports to the authority | Informs the provider immediately |
| Impact assessment, Article 27 | No direct duty | Carries it out where Article 27 applies |
| Notices, Article 26(7) and 26(11) | No direct duty | Informs workers and affected people |
| Transparency, Article 50 | Discloses AI interaction and marks synthetic content | Discloses deep fakes and certain public-interest text |
Which AI systems are high risk?
An AI system is high risk by one of two routes in Article 6. It is a safety component of a product, or is itself a product, that needs third-party conformity assessment under the laws in Annex I, or its use falls within one of the areas in Annex III.
Annex III lists biometrics, safety components of critical infrastructure, education, employment, essential services such as credit scoring and life and health insurance pricing, law enforcement, migration and border control, and the administration of justice and democratic processes. Each area has its own precise wording and exclusions. Credit scoring, for example, excludes AI used to detect financial fraud.
Using AI in one of those sectors does not settle the answer. Article 6(3) takes an Annex III system out of the high-risk category when it poses no significant risk and performs a narrow procedural task, improves a completed human activity, detects patterns without replacing human assessment, or does a preparatory task. A system that profiles people stays high risk regardless. The Commission published draft classification guidelines on 19 May 2026, and its page still shows them as a draft on 5 November 2026.
How to classify one AI system
- 1. Is it an AI system under Article 3(1)?No: record why and stop.Yes: go to question 2.
- 2. Does Article 2 reach it?No: record why and recheck when its use or market changes.Yes: go to question 3.
- 3. Is the use banned by Article 5?Yes: stop the use and escalate it.No: go to question 4.
- 4. Is it a safety component or product under Annex I that needs third-party assessment?Yes: high risk, with rules from 2 August 2028.No: go to question 5.
- 5. Does its use fall within Annex III?Yes: high risk from 2 December 2027, unless Article 6(3) applies. A system that profiles people stays high risk.No: go to question 6.
- 6. Does Article 50 apply?Yes: add the transparency duties.No: the Act adds few duties beyond Article 4 and the ban check.
- 7. What is your role for this system?Provider or deployer: check Article 3.Changed since purchase? Check Article 25.
Every path through that flow ends in a record. A record that holds up names the system, its intended purpose, the provisions considered, the organization’s role, the reason, the owner and the date.
What must a deployer do, and how do you prove it?
A deployer of a high-risk system must follow the provider’s instructions, assign competent human oversight, check its input data where it controls that data, monitor the system, keep its logs for at least 6 months and inform workers and affected people, under Article 26. Those duties apply with the high-risk rules. Certain deployers also carry out a fundamental rights impact assessment under Article 27.
Each duty becomes easier to run once it is written as something that can be checked. The chain below is the method DigitalXForce recommends. It is an operating method and not a legal requirement, and the Act does not prescribe it.
From legal duty to evidence
- DutyThe article that applies
- AI systemThe system it applies to
- OwnerThe person accountable
- ControlWhat must stay true
- TestHow it is checked, and how often
- EvidenceThe result, its source and date
- TriggerWhat forces a fresh review
The table applies that chain. The first column is the law, and the other three are recommended practice.
| Duty in the Act | Control to run | Evidence to keep | What sends it back for review |
|---|---|---|---|
| AI literacy, Article 4 | Staff who operate or use AI receive training suited to their role | Training records by role | A new tool or a new role |
| Prohibited practices, Article 5 | Each new AI use is screened before approval | The screening decision and its reason | A new use of an existing tool |
| Instructions for use, Article 26(1) | Use of the system is checked against the provider’s current instructions | The instructions, their version and the review record | New instructions from the provider |
| Human oversight, Article 26(2) | Named people with the competence, training and authority oversee the system | The assignment and each intervention | A change of role or team |
| Input data, Article 26(4) | Data the deployer controls is checked for relevance and representativeness | The check results | A new data source |
| Monitoring, Article 26(5) | Operation is monitored against the instructions, with a path to suspend use | Monitoring records, notices to the provider and suspension decisions | An incident or a change in behavior |
| Logs, Article 26(6) | Logs under the deployer’s control are kept for at least 6 months | The retention setting and a retrieved log from 6 months ago | A change of system or storage |
| Notices, Article 26(7) and 26(11) | Workers and affected people are told before use | The notice text and the date it went out | A new use or a new group of people |
| Impact assessment, Article 27 | The assessment is done before first use where Article 27 requires one | The assessment and the notice to the authority | A change to any element it describes |
| Disclosure, Article 50(3) and 50(4) | Required disclosures are built into the process | The disclosure text and where it appears | New content types or channels |
The logs row shows the difference an auditor cares about. A retention setting is a claim about what should happen, and a retrieved log from 6 months ago shows that it did.
Who is responsible when we buy AI from a vendor?
The vendor and your organization are each responsible for different duties, and buying an AI system does not move the deployer’s duties to the vendor. A vendor that is the provider carries duties such as the risk management system, technical documentation and conformity assessment, and your organization carries Article 26.
Third-party risk management (TPRM) is the discipline of identifying, assessing, monitoring and controlling the risks an organization takes on through its suppliers, vendors and other outside parties. AI suppliers belong in that program, so third-party risk management and AI governance should work from one record of which supplier sits behind which system.
These questions are good practice for an AI supplier assessment, and the Act does not require all of them from every organization.
- Who is the provider, and what role does that leave your organization?
- What is the intended purpose, and which uses do the instructions rule out?
- What information will the supplier give you under Article 13 for a high-risk system?
- Which general-purpose model sits underneath, and who supplies it?
- Will the supplier tell you before a model, a data source or a capability changes?
- How does the supplier report serious incidents, and how fast will it tell you?
- Can you get the logs, and for how long?
- What evidence can you see, and what happens to your data when the contract ends?
What happens when a vendor changes the model?
A vendor’s model change should send the affected system back for review, since the classification, the instructions and the monitoring thresholds were all set against the earlier version. A provider may treat the change as routine, and your record of the system may no longer be true.
Changes also decide when older systems come into scope. Under Article 111, a high-risk system placed on the market before the high-risk rules apply is caught only if it undergoes a significant change in its design from that date, while systems used by public authorities must comply by 2 August 2030 regardless. An enterprise without a change record cannot say which side of that line a system sits on.
Where a supplier's change reaches your obligations
- A new base model
- A new data source
- A new capability or tool access
- New instructions for use
- A serious incident
- The system's intended purpose and category
- Your role under Article 25
- Monitoring thresholds and oversight
- Any impact assessment under Article 27
- Whether an older system now counts under Article 111
- Reassesses the supplier in third-party risk management
- Updates the control and its owner
- Tests again and keeps the evidence
- Informs the provider or suspends use where Article 26(5) requires it
Does the EU AI Act require continuous monitoring?
The EU AI Act does not impose one continuous monitoring architecture on every organization, and several of its duties do recur for as long as a system runs. Article 9 asks providers of high-risk systems to run risk management across the lifecycle, Article 72 asks them to collect and analyze performance data throughout the system’s lifetime, and Article 26(5) asks deployers to monitor operation.
A point-in-time assessment can therefore be accurate on the day it is signed and wrong by the next model update. Continuous Control Monitoring (CCM) monitors conditions, evidence and signals associated with controls. Continuous Control Assurance (CCA) uses evidence, monitoring and validation to determine whether controls continue to operate as expected, and CCM is a capability within it. Why continuous AI governance requires technical controls covers the technical side, and continuous AI risk monitoring shows the signals involved.
The loop below is a recommended method, and the Act does not require these seven stages.
The seven-stage assurance loop
- DiscoverFind AI systems, embedded AI and suppliers
- ClassifyRecord the role and category
- AssessReview legal, security and supplier risk
- ControlAssign owners and safeguards
- MonitorWatch changes, signals and incidents
- EvidenceKeep each decision and result
- ImproveFix findings and update the program
What evidence should we keep?
The evidence depends on your role. A provider of a high-risk system keeps technical documentation, quality management records, logs under its control and conformity assessment records. A deployer keeps logs under its control for at least 6 months and any fundamental rights impact assessment it must carry out.
Beyond those legal records, the third column of the table above is a sensible register to run. Each record should show what was checked, when, by whom or by which system, and what the result was. Those four facts are what let automated evidence stand up to questions later.
Is ISO/IEC 42001 certification the same as EU AI Act compliance?
No, ISO/IEC 42001 certification is not the same as EU AI Act compliance. ISO/IEC 42001 is a management system standard that can support the work, and adhering to it alone gives no presumption of conformity with the Act.
The first harmonized standard under the Act, EN 18286, was cited by Commission Implementing Decision (EU) 2026/2274, published on 14 October 2026. It covers the quality management system and technical documentation duties of providers, and it is built to sit alongside a management system such as ISO/IEC 42001. An organization that already runs ISO/IEC 42001 can reuse much of its work, as long as it checks each duty against the Act directly.
What are the fines?
The highest fine is €35 million or 7% of worldwide annual turnover, whichever is higher, and it applies to prohibited practices. These are ceilings, and a fine depends on the infringement, the operator and the circumstances.
Fine ceilings under Article 99
For small and medium-sized enterprises, including start-ups, the lower of the two figures applies in each tier. For small mid-cap companies, the lower figure applies in the 2 lower tiers. Under Article 101, the Commission can fine providers of general-purpose AI models up to €15 million or 3%, whichever is higher.
What software helps prove EU AI Act compliance?
Software can hold the inventory, test controls, keep the evidence and show what changed, and no software can make an organization compliant on its own. Compliance rests on the organization’s legal decisions and on whether its controls actually work. A buyer comparing platforms can ask each one to show five things on a real system: how it finds AI nobody declared, how it maps one control to several frameworks, how it tests that control, what record a test leaves, and what happens when a supplier changes a model.
How DigitalXForce connects to this work
DigitalXForce governs AI through AI TRiSCM and AI Risk Governance, the module of its Trust, Risk, Security and Compliance Management platform for AI asset discovery, assessment and mapping to the EU AI Act, ISO/IEC 42001 and the NIST AI Risk Management Framework. It follows the chain in this guide from duty to evidence.
- Inventory: the module discovers AI assets across cloud, code repositories, CI/CD pipelines, containers, model endpoints, RAG and vector databases and business applications.
- Assessment: it assesses LLMs, chatbots, copilots, RAG systems, AI agents and model files against security, safety, privacy, robustness and operational risk.
- Controls: an AI system is approved before it goes into production, and approved and prohibited use are enforced as policy gates.
- Monitoring: bias monitoring, drift detection and performance and safety telemetry run after deployment.
- Evidence: every test result is kept with the evidence it read and a timestamp, and each AI control is mapped once to the Act, ISO/IEC 42001 and the NIST AI RMF.
- Vendors: the vendors behind an organization’s AI are assessed in the third-party risk management module, and a material change in a vendor’s posture, such as a new base model, triggers a reassessment.
- Response: a failed guardrail raises a risk in the enterprise risk register, AI JedAI scores it, and X-ROC, the XForce Risk Operations Center, alerts, triages, escalates and reports it.
- Reporting: XForce GPT writes the narrative on what AI is in use, what its risk is and what changed, and an analyst reviews AI output before anyone relies on it.
Some decisions stay with your organization whatever tool it uses. Your organization decides each system’s category and its own role, names the people who oversee each system, writes any fundamental rights impact assessment and makes the disclosures. DigitalXForce is not a certification, assessment or authorization body for the EU AI Act. AI governance and compliance and enterprise AI governance and AI risk management cover the capability in more detail.
Three worked examples
These examples are hypothetical, and each real system needs its own review.
An employer buys an AI screening tool for recruitment. Annex III point 4(a) lists recruitment and candidate evaluation, so the tool is likely high risk unless Article 6(3) applies, and the vendor is the provider while the employer is the deployer. The employer names the people who review results, informs workers’ representatives and affected workers, tells candidates that the system is in use, and keeps the logs. A new model from the vendor sends the system back for review.
A lender buys a credit scoring model. Annex III point 5(b) lists creditworthiness assessment and credit scoring, and Article 27 requires this deployer to carry out a fundamental rights impact assessment before first use. A financial institution meets the Article 26(5) monitoring duty by complying with the internal governance rules of EU financial services law, and it keeps the logs in the documentation that law requires. A separate model used only to detect fraud falls outside that point.
A company rolls out a generative AI assistant for drafting. Internal drafting is not an Annex III use by itself, so the first duties are AI literacy under Article 4 and any disclosure Article 50(4) requires, such as for deep fakes. The company writes approved and prohibited uses as controls with tests, and the workplace policy for public AI tools is a starting point. If a team later uses the assistant to rank applicants, the system goes back to classification and the Article 25 question from earlier in this guide.
What should a board ask?
A board does not need every article of the Act, and it does need answers it can test. These 7 questions sit well beside the cybersecurity metrics a board already sees.
- Which AI systems do we use, including those inside software we buy?
- Where does the EU AI Act reach our activities, and who decided that?
- Which systems are high risk, and can someone show the reason for each decision?
- Where are we a provider, where are we a deployer, and could a team change that by accident?
- Have we met the duties that already apply, including the bans and AI literacy?
- What evidence shows that our controls work today?
- What happens here when a supplier changes a model?
Quick answers
Is the EU AI Act in force?
Yes. The EU AI Act entered into force on 1 August 2024 and has applied generally since 2 August 2026, with later dates for the high-risk rules.
When do the high-risk rules apply?
The rules for high-risk systems in Annex III apply from 2 December 2027, and the rules for high-risk AI in products under Annex I apply from 2 August 2028.
Does every AI system need a conformity assessment?
No. Conformity assessment is a duty of providers of high-risk AI systems, and a deployer takes it on only if Article 25 makes it the provider.
Is using ChatGPT at work high risk under the EU AI Act?
The answer depends on the use, because the Act classifies by purpose. Drafting an email is not an Annex III use, and ranking job applicants is.
Do small companies have to comply?
Yes, the EU AI Act has no general exemption by size. Small and medium-sized enterprises do get lower fine ceilings and some simplifications.
What happens to AI systems already in use?
A high-risk system already on the market before the high-risk rules apply is caught only if its design changes significantly from that date, and systems used by public authorities must comply by 2 August 2030.
Does DigitalXForce classify our AI systems under the EU AI Act?
DigitalXForce does not make the legal classification. The AI TRiSCM module inventories and assesses each system, its mapping covers risk classification, and your organization decides the category and its own role.
Is this guide legal advice?
No. This guide is general information on the Act’s text as at 27 July 2026, and how the Act applies to a specific system depends on the facts of that system.
Sources
- Regulation (EU) 2024/1689, the AI Act, EUR-Lex.
- Regulation (EU) 2026/1744, the Digital Omnibus on AI, Official Journal, 24 July 2026.
- AI Act implementation timeline, European Commission AI Act Service Desk.
- AI Act Explorer, the consolidated articles as at 27 July 2026, European Commission.
- Draft guidelines on the classification of high-risk AI systems, European Commission.
- Commission Implementing Decision (EU) 2026/2274, Official Journal, 14 October 2026.
- First harmonised technical standard published under the EU AI Act, Orrick, October 2026.
Change log
5 November 2026: DigitalXForce published this guide, reading the Act as at 27 July 2026.
If your AI program looks like the one this guide describes, a 30 minute walkthrough on your own AI systems is the fastest way to check what the chain would look like for you. Request a demo.
