An AI risk assessment should identify what an AI system does, who can be harmed, which EU AI Act role and risk class apply, and whether the remaining risk is acceptable after controls. It is not one universal form required from every AI user. Article 9 places the continuous risk-management-system duty on providers of high-risk AI systems, while deployers have a different set of duties and some must also complete a fundamental-rights impact assessment.
As of 8 August 2026, most AI Act provisions apply, including Article 50 transparency duties. Regulation (EU) 2026/1744 changed the high-risk timetable: the Chapter III rules for Annex III systems apply from 2 December 2027, while those for Article 6(1) systems linked to Annex I product legislation apply from 2 August 2028. An assessment should record these dates without treating the transition period as permission to ignore current GDPR, product-safety, employment, consumer-protection, or contractual duties.
Quick answer
| Question | Practical answer |
|---|---|
| Who owns the assessment? | The legal role determines ownership. A provider documents product-level risks; a deployer documents its use context and fulfils deployer duties. One company can hold both roles. |
| What should be assessed first? | Intended purpose, affected people, prohibited-practice screening, high-risk classification, data, performance, human oversight, security, and foreseeable misuse. |
| Is a score mandatory? | No. The AI Act requires a documented, iterative risk-management system for high-risk providers, but it does not prescribe a universal 5-by-5 matrix. |
| When is a FRIA required? | Article 27 covers specified deployers, including public-law bodies, private entities providing public services, and certain creditworthiness and life/health-insurance uses. |
| What is the commercial next step? | A scoped AI compliance assessment can establish the inventory, roles, classifications, gaps, and evidence plan. |
Start with the legal role, not the technology
The same model can create different duties in different supply chains. Record, for each system:
- the entity that develops the system, or has it developed, and places it on the market or puts it into service under its own name or trademark, including for its own first use in the EU;
- the entity that uses it under its authority;
- any importer, distributor, authorised representative, or product manufacturer;
- whether a deployer has changed the intended purpose or made a substantial modification; and
- where the system is placed on the market, put into service, or produces outputs used in the EU.
Under Article 3(11), “putting into service” includes supply for the deployer's first use or for the provider's own use in the EU for the intended purpose. An organisation that develops or commissions a system and first uses it internally under its own name or trademark can therefore be its provider, not merely its deployer. Do not accept a vendor's label as the final classification. Contracts should allocate information and cooperation duties, but they cannot rewrite statutory roles.
Apply the current AI Act timeline
| Date | Status at the review date | Main point |
|---|---|---|
| 2 February 2025 | In application | Chapters I and II, including most prohibited practices, began to apply. |
| 2 August 2025 | In application | Governance and general-purpose AI model rules began to apply, subject to transitional provisions. |
| 2 August 2026 | In application | The general application date and Article 50 transparency duties have passed. Commission enforcement powers for GPAI providers are also in application. |
| 2 December 2026 | Future | The new prohibitions added by Regulation (EU) 2026/1744 and the limited transition for Article 50(2) systems already on the market take effect. |
| 2 December 2027 | Future | Chapter III Sections 1–3 apply to Article 6(2)/Annex III high-risk systems. |
| 2 August 2028 | Future | The corresponding Chapter III rules apply to Article 6(1)/Annex I product-related high-risk systems. |
The date is only one field in the assessment. Also record the specific article, any transitional rule, the system version, and the evidence used for the conclusion.
A practical seven-step assessment
1. Define the system and intended purpose
Describe the inputs, model or rules, outputs, users, affected people, operating environment, decisions influenced, integrations, and geographic reach. Separate the vendor's intended purpose from the way your organisation actually uses the system.
2. Screen for prohibited practices
Test the actual use against Article 5. A prohibited-practice screen should be escalated to qualified counsel because the exceptions and conditions are fact-specific. A mitigation plan does not make a prohibited use lawful.
3. Classify high-risk and transparency exposure
Check both high-risk routes:
- Article 6(1) and Annex I: an AI safety component, or AI product, connected with listed Union product legislation and the relevant conformity-assessment conditions;
- Article 6(2) and Annex III: listed sensitive uses such as specified biometric, critical-infrastructure, education, employment, essential-service, law-enforcement, migration, or justice uses, subject to Article 6 qualifications. An Annex III system that performs profiling of natural persons is always considered high-risk under Article 6(3).
Then check Article 50 separately. A system can have a transparency obligation without being high-risk.
4. Identify harms and failure modes
Assess reasonably foreseeable effects on:
- health and safety;
- privacy and personal-data protection;
- equality and non-discrimination;
- access to employment, education, credit, insurance, or public services;
- accuracy, robustness, cybersecurity, and availability;
- human autonomy and effective challenge; and
- downstream users and people outside the immediate transaction.
Include normal use, reasonably foreseeable misuse, integration failures, model or data drift, and combined effects with other systems.
5. Evaluate controls and residual risk
Use a scale suited to the decision. Define each likelihood and severity level before scoring, explain uncertainty, and avoid averaging away a severe fundamental-rights impact. Useful controls include data-quality checks, representative testing, access restrictions, user instructions, human review, override and stop mechanisms, logging, security testing, monitoring thresholds, and incident escalation.
6. Assign treatment and approval
For every material risk, record the action, owner, due date, verification method, and residual-risk decision. The approver should have authority to delay, restrict, redesign, or stop deployment. Where a risk cannot be brought to an acceptable level, do not deploy merely because a weighted score looks moderate.
7. Monitor throughout the lifecycle
Set review triggers rather than relying only on an annual date. Triggers should include model or data changes, a new use case, a new affected population, material performance drift, a serious incident, a vendor change, a regulatory update, or evidence that assumptions were wrong.
Minimum risk-register fields
| Field | What to record |
|---|---|
| System and version | Stable identifier, release, owner, and status |
| Intended and actual use | Decision supported, operating context, users, and affected people |
| Legal role and class | Provider/deployer roles, Article 5 screen, Article 6 route, Article 50 exposure |
| Risk statement | Cause, event, affected person or interest, and consequence |
| Evidence | Test data, metrics, consultation, incidents, vendor documents, and limitations |
| Controls | Preventive, detective, corrective, and human-oversight measures |
| Residual risk | Rating, rationale, uncertainty, approver, and conditions of use |
| Monitoring | Indicator, threshold, owner, cadence, and escalation path |
FRIA, DPIA, and conformity assessment are different
A fundamental-rights impact assessment under Article 27 is a deployer assessment for specified high-risk uses and specified deployers. A data protection impact assessment under GDPR Article 35 addresses high-risk personal-data processing. The amended Article 27 permits relevant cross-references, but one assessment does not automatically replace the other.
A conformity assessment is the provider's broader pre-market compliance route for a high-risk system. It includes more than risk analysis: technical documentation, quality management, testing, conformity procedures, declaration and marking requirements can also apply. Keep these work products connected but do not collapse them into one generic checklist.
Questions to ask an AI vendor
- What is the exact intended purpose and prohibited-use policy?
- Which AI Act role and risk classification has the vendor documented, and why?
- What training, validation, and testing evidence is available?
- Which performance limits, failure modes, and affected groups were tested?
- What logs, instructions, human-oversight features, and incident channels are provided?
- How are model, data, and subcontractor changes communicated?
- Can the customer obtain the information needed for its own GDPR, FRIA, and deployer duties?
Record missing evidence as a risk. A contractual warranty is not a substitute for technical and operational verification.
Frequently asked questions
Must every company conduct an EU AI Act risk assessment?
Every organisation should inventory and classify its AI uses, but the formal Article 9 risk-management-system obligation attaches to providers of high-risk systems. Other duties depend on role, system type, use, and applicable sectoral law.
Can we wait until the high-risk dates?
The amended high-risk dates provide transition time, not a general legal safe harbour. Prohibitions, GPAI rules, Article 50 transparency duties, GDPR, and other applicable laws may already govern the system.
Is NIST AI RMF evidence of AI Act compliance?
NIST AI RMF is a voluntary risk-management resource. It can help structure governance, mapping, measurement, and management, but it does not determine EU legal scope or prove conformity with the AI Act.
When should legal counsel review the assessment?
Escalate uncertain role or classification decisions, possible prohibited practices, fundamental-rights impacts, employment or credit uses, special-category data, significant modifications, and any decision to accept a severe residual risk.
Sources and review
This guide was substantively reviewed on 8 August 2026 against primary and official sources. It is general information, not a substitute for advice on a specific system.
- Regulation (EU) 2024/1689 — Artificial Intelligence Act
- Regulation (EU) 2026/1744 — Digital Omnibus on AI
- European Commission — current AI Act application timeline
- NIST — AI Risk Management Framework
For help turning this framework into a role map, classification register, control plan, and reviewable evidence set, see Vision Compliance's AI compliance service.
Robert Lozo, mag. iur., is a Partner at Vision Compliance specializing in EU regulatory compliance. He advises organizations on GDPR, NIS2, AI Act, and financial regulation, delivering audit-ready documentation and compliance roadmaps across regulated industries.