EU AI Act Compliance Assessment for AI Deployments

Written by Jakub Rusinowski · Last updated 2026-09-13 · Assessment logic is deterministic and runs in your browser

This section is practitioner guidance on deployment and governance mechanics, not legal advice. Regulatory classification turns on facts about intended purpose and real-world use that a questionnaire cannot establish — involve your counsel or DPO for decisions about your specific obligations.

The EU AI Act — Regulation (EU) 2024/1689 — classifies AI systems by intended purpose, not by model, size or hosting location. There are four positions a deployment can be in: inside an Article 5 prohibition, high-risk through one of two independent pathways, subject to Article 50 transparency duties, or below all of these with the Article 4 AI-literacy duty still applying. Which one you are in depends on what the system does and to whom, and that is what an assessment has to establish.

EU AI Act Regulation — applies whether or not you adopt it

  • Version Regulation (EU) 2024/1689
  • Publisher European Parliament and Council of the European Union
  • In force 2024-08-01
  • Last verified 2026-09-13

The European Union's horizontal AI law. It regulates AI systems by their intended purpose and the risk that purpose creates — not by model size, architecture or where the model runs. It bans a short list of practices outright (Article 5), defines two routes into the high-risk tier (Article 6), attaches transparency duties to certain systems regardless of tier (Article 50), and splits obligations between providers, deployers, importers and distributors.

What this tool does not do

  • This tool performs a readiness assessment, not a conformity assessment. Conformity assessment under the Act is a formal procedure, and for some high-risk systems it involves a notified body.
  • Classification under Articles 5 and 6 turns on facts about intended purpose and real-world use that a questionnaire cannot establish. Where the answers are ambiguous the result is MANUAL REVIEW, not a verdict.
  • We do not assess the general-purpose AI model obligations that sit with model providers (Chapter V). Those rest with the organisation that trains and releases the weights.
  • Nothing here is legal advice, and no output of this tool has any standing before a market surveillance authority.

Official source ↗

The structure, in the order an assessment has to walk it

The Act is often summarised as a four-tier risk pyramid. That picture is useful for a slide and misleading for an assessment, because the tiers are not tested in parallel — they are a precedence ladder, and the order changes the answer.

1. Article 5 — prohibited practices. A short list of practices that may not be placed on the market or put into service at all: certain manipulative and exploitative techniques, social scoring leading to unjustified detrimental treatment, predicting criminal offending from profiling alone, untargeted scraping to build facial-recognition databases, emotion inference in workplaces and education, biometric categorisation by protected attributes, and real-time remote biometric identification in publicly accessible spaces for law enforcement, subject to narrow exceptions. There is no compliance route here. You do not document your way into an Article 5 practice being acceptable, which is why any signal at this stage takes precedence over every other finding.

2. Article 6(1) — the Annex I product pathway. An AI system is high-risk if it is intended to be used as a safety component of a product covered by the Union harmonisation legislation listed in Annex I (machinery, medical devices, lifts, toys, vehicles, radio equipment and more), or is itself such a product, and that product must undergo third-party conformity assessment. Both conditions. Being in a regulated sector is not the trigger.

3. Article 6(2) — the Annex III listed areas. Eight areas: biometrics; critical infrastructure; education and vocational training; employment and worker management; access to essential private and public services; law enforcement; migration, asylum and border control; and administration of justice and democratic processes. This is the route most business deployments would reach the high-risk tier by.

4. Article 6(3) — the derogation. An Annex III system is not high-risk where it does not pose a significant risk of harm, including by not materially influencing decision making — supported by any of four conditions: a narrow procedural task, improving a previously completed human activity, detecting decision patterns without replacing a human assessment, or performing a preparatory task. It is unavailable outright where the system profiles natural persons. A provider relying on it must document the assessment.

5. Article 50 — transparency. Independent of all of the above. People must be told when they are interacting with an AI system; generative output must be marked machine-readably by its provider; deep fakes and AI-generated public-interest text must be disclosed by deployers. This is the article that touches ordinary deployments, and it is the one most often missed by tools that stop once "not high-risk" is established.

Running these out of order produces wrong answers. Testing Annex III first and stopping when it misses skips both Article 6(1) and Article 50 — which is how a deployment ends up believing it has no obligations at all.

The two questions that actually move the answer

What is the intended purpose? Not the model, not the industry, not the data. The Act asks what the system is *for*. This is why "we are a hospital" tells you nothing: a meeting-notes summariser and a triage system are both healthcare AI and only one of them is anywhere near the high-risk tier. Write the intended purpose down as a sentence before you assess anything — everything downstream is anchored to it, and an assessment against a vague purpose is a vague assessment.

What is your role? The Act splits obligations between the provider (who develops the system or places it on the market under their own name), the deployer (who uses it under their own authority), the importer and the distributor. The provider duty set is far heavier: a risk management system, data governance, technical documentation, record-keeping, accuracy and robustness requirements, conformity assessment and CE marking. The deployer set centres on using the system per its instructions, assigning competent human oversight, monitoring, keeping logs, and informing affected people.

Article 25 is the one to watch, because it moves organisations between those sets through ordinary product decisions rather than a formal step. A deployer, distributor or importer is considered a provider of a high-risk system when it puts its own name or trademark on it, makes a substantial modification to it, or modifies its intended purpose so that it becomes high-risk. Fine-tuning an open-weight model and offering the result to your customers is exactly the shape of decision that can cross that line.

What self-hosting changes, and what it does not

This site exists because people run models on their own hardware, so this deserves a direct answer: self-hosting does not change your obligations. The Act regulates the workload, not the rack. An Annex III employment system carries the same deployer duties whether it answers from a workstation under a desk or a vendor API in another jurisdiction. Anyone selling "on-premise equals AI Act compliant" has made a category error.

What self-hosting genuinely changes is evidence and dependency:

The enterprise guide to the Act and self-hosted AI covers the timeline and the deployer-versus-provider logic at more length.

Controls this assessment derives from the Act

Each canonical control below maps into one or more Articles. The mapping type says how close the relationship is — a direct mapping means the Article requires substantially this activity; a strong or partial one means it is related but not coextensive.

AI risk management process CTL-RISK-001

A documented, iterative process that identifies the risks this AI system poses to health, safety and fundamental rights, estimates them against the intended purpose and reasonably foreseeable misuse, and records the mitigations adopted. Reviewed on a schedule and after material change, not written once.

Article 9 — Direct · high confidence

Risk management system for high-risk AI systems

Article 9 requires a risk management system established, implemented, documented and maintained across the lifecycle of a high-risk AI system. This control is that requirement expressed as a deployment activity. It is direct for high-risk systems and merely good practice below that tier.

Last verified 2026-09-13

Human oversight of AI output CTL-OVERSIGHT-001

A named human role that can understand the system's output and limitations, decide not to use it, and override or reverse it — with the authority and the time to actually do so. Oversight is a staffed procedure, not a checkbox in a UI.

Article 14 — Direct · high confidence

Human oversight requirements for high-risk AI systems

Article 14 requires high-risk systems to be designed so they can be effectively overseen by natural persons, including the ability to decide not to use the system and to intervene or interrupt it. Article 26 places the corresponding duty on deployers to assign oversight to people with the necessary competence, training and authority.

Last verified 2026-09-13

Input and reference data governance CTL-DATA-001

Know what data reaches the model and whether it is fit for the purpose: where it came from, whether it is relevant and sufficiently representative for the people the system is used on, what is excluded, and how errors and gaps are handled. For a retrieval system this covers the corpus, not just the prompt.

Article 10 — Direct · high confidence

Data and data governance for high-risk AI systems

Article 10 sets quality criteria for training, validation and testing data sets and requires data governance practices appropriate to the intended purpose. Article 26(4) places the parallel deployer duty for input data under the deployer's control.

Last verified 2026-09-13

Personal data handling in the inference path CTL-PRIVACY-001

Establish the lawful basis, the data minimisation position and the retention rule for personal data that enters prompts, retrieval context or logs. Inference logging is the common failure: a system designed not to store personal data often stores it anyway, in the log.

Article 26(9) / Recital interplay with the GDPR — Partial · medium confidence

Deployer duties alongside data-protection law

The AI Act does not replace the GDPR; it sits beside it and in places cross-refers, for example to data protection impact assessments. Partial because the substantive personal-data obligations are the GDPR's, not the AI Act's, and this tool does not assess the GDPR.

Last verified 2026-09-13

Inference and audit logging CTL-LOGGING-001

Record what the system was asked, what it answered, which model version answered, who was involved and when — to a retention period you chose deliberately. For high-risk systems the deployer must keep the automatically generated logs.

Article 12 / Article 26(6) — Direct · high confidence

Automatic recording of events, and the deployer duty to keep the logs

Article 12 requires high-risk systems to technically allow the automatic recording of events over their lifetime. Article 26(6) requires deployers to keep those logs for an appropriate period. Direct for high-risk systems.

Last verified 2026-09-13

Disclosure to the people who use or are affected by the system CTL-TRANSPARENCY-001

Tell people they are interacting with an AI system, at the point of interaction. Where the system is high-risk and makes or assists decisions about a person, inform that person as well.

Article 50 / Article 26(11) — Direct · high confidence

Transparency duties toward natural persons, and informing affected persons

Article 50 requires people to be informed they are interacting with an AI system and requires synthetic content to be marked. Article 26(11) requires deployers of certain high-risk systems to inform natural persons that they are subject to their use.

Last verified 2026-09-13

System and model documentation CTL-DOC-001

A record of what is deployed: the model and its exact version, the quantisation and serving stack, the hardware, the configuration, the known limitations, and the intended purpose. This is the document every other control cites.

Article 11 / Annex IV — Direct · high confidence

Technical documentation for high-risk AI systems

Article 11 and Annex IV specify the technical documentation a provider of a high-risk system must draw up before placing it on the market. For a deployer below that tier the same document is good practice rather than an obligation, which is why this control applies to every deployment but its mapping strength varies with the tier.

Last verified 2026-09-13

Access control and network isolation for the inference endpoint CTL-SEC-001

Authenticate and authorise every caller of the model endpoint, and place the endpoint where only intended callers can reach it. An internal model server on an open port is a data-exfiltration path with a chat interface.

Article 15 — Strong · high confidence

Accuracy, robustness and cybersecurity for high-risk AI systems

Article 15 requires high-risk systems to achieve an appropriate level of cybersecurity and to be resilient against attempts to alter their use or performance. Access control is part of meeting that, not the whole of it.

Last verified 2026-09-13

Prompt injection and output handling CTL-MODELSEC-001

Treat model output as untrusted input to whatever consumes it. Where the model reads attacker-influenceable content — retrieved documents, user uploads, web pages — assume that content contains instructions aimed at the model, and constrain what the model is able to do about them.

Article 15 — Strong · medium confidence

Robustness and cybersecurity, including resilience to attempts to alter use or performance

Article 15 addresses resilience against attempts by third parties to alter a system's use or performance by exploiting vulnerabilities, which is a fair description of prompt injection — though the Act predates the term and does not name it.

Last verified 2026-09-13

AI incident detection and response CTL-INCIDENT-001

A route for someone to report that the system did something wrong, a person who owns the response, and a record of what happened. For high-risk systems, serious incidents carry a reporting duty with a deadline.

Article 73 / Article 26(5) — Direct · high confidence

Reporting of serious incidents, and the deployer duty to inform the provider and authorities

Article 73 sets the serious-incident reporting regime for providers of high-risk systems; Article 26(5) requires deployers who identify a serious incident to inform the provider and, where relevant, the authority without undue delay.

Last verified 2026-09-13

Post-deployment performance monitoring CTL-MONITOR-001

Measure whether the system still does what the documentation says it does. For a system affecting people, measure it across the groups it affects, not only in aggregate.

Article 72 / Article 26(5) — Direct · high confidence

Post-market monitoring by providers, and the deployer duty to monitor operation

Article 72 requires providers of high-risk systems to establish a post-market monitoring system; Article 26(5) requires deployers to monitor operation in accordance with the instructions for use.

Last verified 2026-09-13

Named accountability and AI literacy CTL-GOV-001

Someone owns this system by name. The people operating it understand what it can and cannot do. Article 4 of the AI Act makes AI literacy a duty for providers and deployers, and it applied from February 2025 — earlier than most of the rest.

Article 4 — Direct · high confidence

AI literacy duty for providers and deployers

Article 4 requires providers and deployers to take measures ensuring a sufficient level of AI literacy among their staff and others operating AI systems on their behalf, taking into account their knowledge, the context, and the persons the system is used on. It is one of the earliest-applying provisions.

Last verified 2026-09-13

Assess a specific deployment

The generic answer is on this page. The specific one depends on what your system is for, who it affects and what it decides — which is what the assessment asks about.

Create Compliance Profile →

Automated assessment based on the information you provide. Not legal advice, certification or an audit.

Frequently asked questions

When do the EU AI Act obligations start applying?
The Regulation entered into force on 1 August 2024 and applies in stages. The Article 5 prohibitions and the Article 4 AI-literacy duty applied from 2 February 2025. The general-purpose AI model provider obligations and the governance structures applied from 2 August 2025. The main body of obligations for Annex III high-risk systems, plus the Article 50 transparency duties, applies from 2 August 2026. High-risk rules for AI embedded in Annex I regulated products follow from 2 August 2027. Check the dates against the Regulation's own text rather than against a summary.
Is my internal chatbot high-risk?
Almost certainly not, and the reason matters. Annex III is a closed list keyed to what a system does — employment decisions, credit scoring, education assessment, biometrics and so on. An internal assistant that drafts and summarises is not in that list, however large the model. What does apply is Article 50: if staff interact with it directly they should be told it is an AI system. And Article 4 AI literacy applies to every provider and deployer regardless of tier.
What is the difference between a provider and a deployer?
A provider develops an AI system or has it 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 own authority in a professional capacity. Most organisations running an open-weight model internally are deployers. The distinction is worth getting right because the provider duty set includes conformity assessment and CE marking, which the deployer set does not — and because Article 25 can move you from one to the other if you rebrand the system, substantially modify it, or change its intended purpose so it becomes high-risk.
What happens if an Annex III area matches?
You are looking at a high-risk candidate, and the next question is Article 6(3): does a derogation apply? It requires that the system does not pose a significant risk of harm, supported by one of four conditions — and it is unavailable outright if the system profiles natural persons. If no derogation is available, the Chapter III obligations attach according to your role, and for deployers that means Article 26: use per the instructions, competent human oversight, relevant input data where you control it, monitoring, log retention, and informing affected people. Certain deployers also owe a fundamental rights impact assessment under Article 27.
Does the Act apply if we are not in the EU?
It can. The Regulation has extraterritorial reach: it applies to providers placing AI systems on the Union market or putting them into service in the Union regardless of where they are established, and to providers and deployers outside the Union where the output produced by the system is used in the Union. The assessment asks whether the system is placed on the market or put into service in the EU and applies the Act by default if you do not answer, rather than assuming it does not.

Keep going