Find out what the EU AI Act asks of your AI system. Plain English, about two minutes, and nothing leaves your browser.
You worked on an unnamed system here before — , last edited .
Some AI systems carry eighteen obligations. Some carry three. Most carry none at all. It all comes down to one thing: which category your system is in.
A few uses are banned outright, whatever the category. The check screens for those first.
Seven questions. No account, no email, no data sent anywhere.
A checklist, not legal advice. What you owe depends on your system, your role and how it is used. Check the official text, and take a legal opinion on close calls.
The Act splits duties by role, and the two that carry most of them are provider and deployer. This check covers those two.
Article 5 bans these outright — they are not a risk tier, they are a prohibition. Tick everything that applies, or leave all unticked. Eight have applied since 2 February 2025; the Digital Omnibus added two more that apply from 2 December 2026.
This is the Article 6(1) route: the AI is a safety component of — or is itself — a product covered by the EU product-safety legislation in Annex I (medical devices, machinery, lifts, toys, vehicles and the rest), and that product needs a third-party conformity assessment. The Digital Omnibus narrowed this: AI used solely for user assistance, performance optimisation, service efficiency, automation, convenience or quality control is not a safety component — unless its failure would endanger health and safety. A third-party assessment required only for non-safety reasons, such as radio spectrum, does not count either.
These are the eight Annex III areas, at the level of the actual use case — not your industry. A bank running a chatbot is not high-risk because it is a bank; it would be high-risk because it scores creditworthiness. Tick everything that applies.
Profiling means automated processing of personal data to evaluate personal aspects of a person — performance at work, economic situation, health, preferences, reliability, behaviour, location or movements. This question decides whether the Article 6(3) exception is available to you at all.
An Annex III system is not high-risk if it poses no significant risk of harm to health, safety or fundamental rights and it fits one of the four conditions below. Tick a condition only if the “no significant risk” part is also true for your system.
Article 50 transparency duties attach to how a system interacts with people or what it generates — independently of the risk tier. A minimal-risk chatbot still owes disclosure. In force from 2 August 2026.
All three lists are here. The check above just picks the right one for you and lets you tick it off.
Dates. The bans and the AI literacy duty already apply. The three limited-risk duties start 2 August 2026. High-risk starts 2 December 2027 — or 2 August 2028 for AI built into a regulated product.
These attach to high-risk AI systems under Chapter III of the Regulation. They are written from the provider’s side — the party that develops the system and puts it on the market under its own name. If you use a high-risk system somebody else built, your own duties sit in Article 26, and Article 25 can turn you into a provider if you substantially modify the system or put your name on it. Applicable from 2 December 2027 for the Annex III route.
Eighteen obligations is more than a page can carry for long — each one needs an owner, a document behind it and a record of when it changed. That is what Model Inventory for Jira does with this same list, for every system at once.
Run a continuous, documented risk process across the whole life of the system — not a one-off assessment before launch. You identify the reasonably foreseeable risks to health, safety and fundamental rights, decide what to do about each, test that the mitigation works, and revisit it whenever the system or its use changes.
Evidence typically requested: risk management plan, risk register, risk assessment reports.
Training, validation and test datasets need governance you can show: where the data came from, what it represents, how it was prepared, and what you did to find and handle bias and gaps. In practice this is the obligation that most often forces work upstream in the data pipeline, long before anyone looks at the model.
Evidence typically requested: data governance policy, dataset documentation, bias analysis.
Draw up the Annex IV technical file before the system goes on the market, and keep it current. It is the document an authority reads to decide whether everything else on this list actually happened — intended purpose, architecture, data, performance, the risk management outcomes.
Evidence typically requested: the technical documentation set required by Annex IV.
The system must record events automatically over its lifetime, at a level that lets someone reconstruct what happened and spot situations that create risk or amount to a substantial modification. This is a design requirement, not a policy: if the logging is not built in, it cannot be retro-fitted from a document.
Evidence typically requested: logging architecture, audit trail documentation, retention policy.
The system has to be transparent enough for the organisation deploying it to interpret its output and use it properly, and it ships with instructions for use covering capabilities, limitations, known risks, expected accuracy and the human oversight measures built in. Read the other way round, this is the procurement checklist you hand a vendor.
Evidence typically requested: instructions for use, model card, explainability documentation.
Design the system so a real person can effectively oversee it: understand what it is doing, notice when it is going wrong, decide not to use the output, and stop it. “A human approves the output” is not enough on its own — the person needs the means and the standing to override it.
Evidence typically requested: oversight procedures, override and stop mechanisms, operator training materials.
Reach a level of accuracy, robustness and security appropriate to the purpose, and declare the accuracy metrics in the instructions for use. Robustness covers errors and edge cases; the security half covers attacks specific to AI — data poisoning, model evasion, adversarial input.
Evidence typically requested: validation reports, accuracy metrics, robustness testing, security assessment.
A documented QMS covering the regulatory strategy, design and development procedures, testing, data management, post-market monitoring, incident reporting and accountability. If you already run ISO 9001 or ISO/IEC 42001, this is largely a mapping exercise rather than a new system — but the mapping itself has to exist on paper.
Evidence typically requested: quality management documentation, process descriptions, audit records.
A FRIA is a deployer duty, and it does not land on everyone: it applies to public bodies and to private deployers of the Annex III point 5(b) and 5(c) systems — creditworthiness assessment, and risk assessment and pricing in life and health insurance. It asks who is affected, how, and what you will do about it.
Evidence typically requested: FRIA report, records of stakeholder consultation.
Put the system through a conformity assessment before it goes on the market. For most Annex III systems this is an internal control procedure you run yourself against Annex VI; biometric systems and the Annex I product route can pull in a notified body. Substantial modifications restart it.
Evidence typically requested: conformity assessment report, notified body certificate where one applies.
A signed written declaration, per system, stating that it meets the high-risk requirements — kept for ten years after the system is placed on the market and handed to national authorities on request. It is short, and it is the document that makes the accountability personal.
Evidence typically requested: the signed declaration of conformity.
Affix the CE marking visibly, legibly and indelibly. For software supplied without a physical product it goes on the digital CE marking, the packaging or the accompanying documentation. It signals that the conformity assessment and the declaration behind it are done.
Evidence typically requested: evidence of CE marking placement, product or interface labelling.
Register the system in the EU database under Article 71 before it is placed on the market or put into service. Note the sting in the tail of the classification question: under Article 49(2) a provider that concluded its Annex III system is not high-risk still has to register that conclusion.
Evidence typically requested: EU database registration confirmation.
A documented plan for watching the system in real use, proportionate to its risks: collecting and analysing performance data over the system’s lifetime and feeding what you learn back into the Article 9 risk process. This is where drift, degradation and unexpected use get caught.
Evidence typically requested: post-market monitoring plan, incident logs, performance reports.
Report serious incidents to the market surveillance authority of the Member State where they happened, without undue delay. The practical requirement is upstream of the report: someone has to own this, and your monitoring has to surface incidents fast enough that the reporting window is reachable at all.
Evidence typically requested: incident reporting procedure, named owner, authority contact details.
People interacting with the system must be told they are dealing with an AI, unless it is obvious to a reasonably well-informed person. In practice: a visible statement at the start of a chat, not a line in the terms of service. Applies from 2 August 2026.
Evidence typically requested: the user-facing disclosure text and screenshots of where it appears.
Providers of generative systems must mark the output in a machine-readable format so it is detectable as artificially generated or manipulated — watermarking, metadata, provenance signals — and the solution has to be effective, interoperable, robust and reliable as far as is technically feasible. A visible “made with AI” badge does not satisfy this on its own. Systems already on the market before 2 August 2026 have until 2 December 2026 to comply.
Evidence typically requested: content marking implementation, metadata or watermarking specification.
Deployers publishing content that depicts people, objects, places or events in a way that could be mistaken for authentic must disclose that it is artificially generated or manipulated. Artistic, creative, satirical or fictional work gets a lighter version of the duty — disclosing that such content exists, without spoiling the work. A separate limb covers AI-generated text published to inform the public on matters of public interest, and that one falls away where the text went through human review and a person holds editorial responsibility for it.
Evidence typically requested: the disclosure mechanism and how users are notified.
Limited risk is not a lighter version of high-risk — it is a different regime. Article 50 attaches to how a system meets people and what it generates, so a system with no high-risk use case at all can still owe every duty below. These apply from 2 August 2026; the Digital Omnibus did not defer them.
People interacting with the system must be told they are dealing with an AI, unless it is obvious to a reasonably well-informed person. In practice: a visible statement at the start of a chat, not a line in the terms of service. Under Article 50(5) it has to be clear, distinguishable and given at the latest at the first interaction.
Evidence typically requested: the user-facing disclosure text and screenshots of where it appears.
Providers of generative systems must mark the output in a machine-readable format so it is detectable as artificially generated or manipulated — watermarking, metadata, provenance signals — effective, interoperable, robust and reliable as far as is technically feasible. Carved out where the system performs an assistive function for standard editing, or does not substantially alter the input data or its semantics. Systems already on the market before 2 August 2026 have until 2 December 2026 to comply.
Evidence typically requested: content marking implementation, metadata or watermarking specification.
Deployers publishing content that depicts people, objects, places or events in a way that could be mistaken for authentic must disclose that it is artificially generated or manipulated. Artistic, creative, satirical or fictional work gets a lighter version of the duty — disclosing that such content exists, without spoiling the work. A separate limb covers AI-generated text published to inform the public on matters of public interest, and that one falls away where the text went through human review and a person holds editorial responsibility for it.
Evidence typically requested: the disclosure mechanism and how users are notified.
One thing worth checking anyway. Article 50(3) puts a duty on deployers of emotion recognition and biometric categorisation systems to inform the people exposed to them. And before you get that far: inferring emotions of employees or students is prohibited outright under Article 5(1)(f), outside medical and safety purposes.
Most AI in most companies lands here: spam filters, recommendation engines, forecasting, code assistants, internal search. The Regulation imposes no specific obligations on these systems. Two duties still reach you regardless of tier, though — the Article 4 AI literacy duty, already in force, and the Article 5 prohibitions.
Article 95 invites providers of non-high-risk systems to apply some of the high-risk requirements voluntarily, and to sign up to codes covering environmental sustainability, accessibility, AI literacy and diverse participation in development. Nothing here is enforceable — but a system logged as minimal-risk with a recorded rationale is what turns “we decided it was fine” into something you can show.
Evidence typically requested: code of conduct document, adherence records.
Minimal risk is a conclusion, not an absence. The value in recording it is that the classification was made, by someone, on a date, for a stated use. When the use drifts — the customer-satisfaction sentiment tool quietly pointed at employees — the record is what makes the drift visible. Keeping that record for every system, not just this one, is what Model Inventory for Jira is for.
This is a practical checklist, not legal advice. Obligations depend on your specific system, your role (provider or deployer) and the context of use. Verify against the official text.
This check covers the provider and deployer roles, which carry most of the duties. Need the exhaustive version — importer, distributor and authorised-representative roles included? The EU AI Act Compliance Checker maintained by the Future of Life Institute is the reference implementation, and it will confirm what you see here.
Worked out with the free EU AI Act compliance checklist — www.closeit.co/eu-ai-act/compliance-checklist/
This sheet covers one system. Model Inventory for Jira holds the whole inventory in one place: every AI system, each with an owner, a status, its evidence attached and a full change history — inside the Jira your team already runs. www.closeit.co/mifj/
A practical checklist, not legal advice. Verify against Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744.
Worth knowing before you build anything on top of it:
None of that is a trick — it is what a page in a browser can do. The version that does the rest is a 30-second install in your Jira.
Send them this link — each of them can work through their own system the same way. But the answers will not come together anywhere: every result lives only in the browser that produced it, with no owner, no evidence and no history.
Model Inventory for Jira runs this same checklist — the same 18 / 3 / 1 obligations, the same item identifiers — inside the Jira your team already uses. Every answer lands in one inventory: a work item with an owner and a status, evidence linked from documents and governance items, and Jira’s own change history behind each edit.
Start building your company’s AI system inventory in a few clicks.
Start your inventory Free 30-day trial · your Jira admin installs it from the Atlassian Marketplace in about 30 seconds
It depends on the risk category. A high-risk system carries the eighteen obligations above — risk management, data governance, technical documentation, logging, transparency to deployers, human oversight, accuracy and security, a quality management system, the FRIA where it applies, conformity assessment, declaration of conformity, CE marking, EU database registration, post-market monitoring, incident reporting and the Article 50 duties. A limited-risk system carries the three Article 50 transparency duties. A minimal-risk system carries none, beyond the voluntary codes in Article 95.
The Article 5 prohibitions and the Article 4 AI literacy duty are already in force. Article 50 transparency applies from 2 August 2026 and was not deferred by the Digital Omnibus, Regulation (EU) 2026/1744. The Annex III high-risk obligations under Article 6(2) moved to 2 December 2027, and the Annex I product-safety route under Article 6(1) to 2 August 2028. The Digital Omnibus guide has every date before and after.
No — and this is where classifications most often go wrong in both directions. Article 6(3) lets an Annex III system out if it poses no significant risk of harm to health, safety or fundamental rights and fits one of four conditions: a narrow procedural task, improving the result of a previously completed human activity, detecting decision-making patterns without replacing human assessment, or a preparatory task. But the exception never applies to a system that profiles natural persons, and under Article 6(4) claiming it means documenting the assessment before the system goes to market. See the Article 6 decoder.
If you built the system, or put it on the market under your own name, you are a provider and the eighteen obligations are yours. If you use a system somebody else built, you are a deployer and your duties sit in Article 26 — with Article 25 turning you into a provider if you substantially modify the system or brand it as your own.
Not here. This page holds one system at a time, in one browser, with no owner and no history behind the answers. That is fine for working a single system out, and it is the honest limit of a page. Doing it across a portfolio means somewhere the answers come together: every AI system as a record with an owner, a status, the evidence attached and a change history an auditor can follow. That is what Model Inventory for Jira does with this same checklist, inside the Jira your team already uses.
No. Everything runs in your browser. Answers, statuses and notes are kept in that browser’s local storage so you can come back to them, and nothing is sent to CloseIT or anyone else — there is no account, no email step and no server holding your assessment. The flip side is in the list above: clearing the browser deletes it, and a colleague opening the link gets an empty form.