DEV Community: Gregorio von Hildebrand

NIST AI RMF Govern Function: Practical Implementation Guide

Gregorio von Hildebrand — Wed, 13 May 2026 10:43:05 +0000

The NIST AI RMF Govern function establishes accountability and oversight for AI systems. Learn how to implement Govern 1.1–1.6 with practical examples and templates.

The NIST AI Risk Management Framework (AI RMF) organizes AI risk management into four functions: Govern, Map, Measure, and Manage. Of these, Govern is the foundation. It establishes the organizational structures, policies, and accountability mechanisms that enable all other risk management activities.

If you're implementing the NIST AI RMF — whether to satisfy customer requirements, prepare for regulatory compliance, or establish defensible AI governance — you must start with Govern. This guide explains what the Govern function actually requires, provides practical implementation steps, and includes templates you can use immediately.

What the NIST AI RMF Govern Function Actually Says

The Govern function is organized into six categories, each with specific subcategories. Here's the high-level structure:

GOVERN 1.1: Legal and regulatory requirements are understood and managed
GOVERN 1.2: The characteristics of trustworthy AI are integrated into organizational policies
GOVERN 1.3: Processes and procedures are in place to determine AI system impacts on individuals, groups, communities, organizations, and society
GOVERN 1.4: Organizational teams are in place to regularly carry out AI risk management activities
GOVERN 1.5: Organizational policies and practices are in place to collect, consider, prioritize, and integrate feedback from those external to the team
GOVERN 1.6: Mechanisms are in place to inventory AI systems and track their risks

These are not aspirational goals. They are concrete organizational capabilities that you must build and document.

Why Govern Is Harder Than It Looks

Most organizations assume they already have "governance" because they have an AI ethics policy or a responsible AI committee. But the NIST AI RMF demands something more rigorous: documented processes, assigned accountability, and continuous risk tracking.

Here's what breaks down in practice:

No legal/regulatory tracking: You know the EU AI Act exists, but you haven't assigned anyone to track new AI regulations or assess their impact on your systems.
No trustworthy AI definition: You talk about "responsible AI," but you haven't defined what that means for your organization or integrated it into product development processes.
No impact assessment process: You deploy AI systems, but you've never documented their impact on users, communities, or society.
No dedicated AI risk team: AI risk management is "everyone's responsibility," which means no one is actually accountable.
No external feedback mechanism: You don't have a process to collect feedback from affected communities, civil society, or domain experts.
No AI system inventory: You don't have a centralized list of all AI systems in production, their risk levels, or their compliance status.

The NIST AI RMF Govern function requires you to close all of these gaps — and to demonstrate that you've closed them.

GOVERN 1.1: Legal and Regulatory Requirements

What it requires:

Your organization must identify, understand, and track legal and regulatory requirements that apply to your AI systems. This includes sector-specific regulations (e.g., healthcare, finance) and horizontal AI regulations (e.g., EU AI Act, state-level AI laws).

Practical implementation:

Assign ownership: Designate a Legal/Compliance lead responsible for tracking AI regulations.
Create a regulatory tracker: Maintain a living document that lists applicable regulations, their enforcement dates, and their impact on your AI systems.
Conduct quarterly reviews: Review the tracker quarterly and update it with new regulations or guidance.
Integrate into product development: Require that every new AI system undergo a regulatory compliance check before deployment.

Example regulatory tracker:

| Regulation | Jurisdiction | Enforcement Date | Applicable Systems | Compliance Status |
|---|---|---|---|
| EU AI Act | EU | Aug 2, 2026 | CV screening AI (high-risk) | In progress |
| Colorado AI Act | Colorado, USA | Feb 1, 2026 | All high-risk systems | Not started |
| NYC Local Law 144 | New York City | Jul 5, 2023 | HR AI tools | Compliant |
| GDPR Article 22 | EU | May 25, 2018 | All automated decision-making | Compliant |

Deliverable: A regulatory compliance tracker, updated quarterly, with assigned ownership.

GOVERN 1.2: Trustworthy AI Characteristics

What it requires:

Your organization must define what "trustworthy AI" means and integrate those characteristics into organizational policies, procedures, and practices.

The NIST AI RMF identifies seven characteristics of trustworthy AI:

Valid and reliable: The system performs as intended.
Safe: The system does not cause unacceptable harm.
Secure and resilient: The system is protected against adversarial attacks.
Accountable and transparent: Decisions are explainable and traceable.
Explainable and interpretable: Stakeholders can understand how the system works.
Privacy-enhanced: The system protects personal data.
Fair: The system does not produce discriminatory outcomes.

Practical implementation:

Adopt or adapt the NIST characteristics: Use the seven NIST characteristics as a starting point, or customize them for your organization.
Document in an AI policy: Create or update your AI governance policy to explicitly reference these characteristics.
Integrate into product development: Require that every AI system design document address how it satisfies each characteristic.
Create acceptance criteria: Define measurable acceptance criteria for each characteristic (e.g., "Fair" means demographic parity within 5%).

Example policy language:

All AI systems developed or deployed by [Company Name] must satisfy the following trustworthy AI characteristics: validity, safety, security, accountability, explainability, privacy, and fairness. Each AI system design document must include a section titled "Trustworthy AI Assessment" that addresses how the system satisfies each characteristic.

Deliverable: An AI governance policy that defines trustworthy AI characteristics and integrates them into product development.

GOVERN 1.3: Impact Assessment Process

What it requires:

Your organization must have a documented process to assess the impact of AI systems on individuals, groups, communities, organizations, and society.

Practical implementation:

Create an impact assessment template: Develop a structured template that prompts teams to consider impacts across multiple dimensions (individual, group, societal).
Require impact assessments for high-risk systems: Mandate that all high-risk AI systems (e.g., those affecting employment, credit, or essential services) undergo an impact assessment before deployment.
Involve diverse stakeholders: Include legal, ethics, product, and domain experts in the assessment process.
Document and review: Store completed impact assessments in a centralized repository and review them annually.

Example impact assessment template:

Impact Dimension	Questions to Consider	Assessment	Mitigation
Individual	Could this system harm individual users? Could it affect their rights or opportunities?	Medium risk: System may deny loan applications	Human review for all denials
Group	Could this system disproportionately affect a protected group (race, gender, age, disability)?	Low risk: Bias testing shows no disparate impact	Ongoing bias monitoring
Community	Could this system affect community cohesion, trust, or access to resources?	Low risk: System used only for internal credit scoring	N/A
Organizational	Could this system create reputational, legal, or operational risk for the organization?	Medium risk: Regulatory scrutiny likely	Compliance audit before deployment
Societal	Could this system contribute to broader societal harms (e.g., surveillance, inequality)?	Low risk: System not used for surveillance	N/A

Deliverable: An impact assessment template and a repository of completed assessments.

GOVERN 1.4: AI Risk Management Teams

What it requires:

Your organization must establish teams with clear roles and responsibilities for AI risk management.

Practical implementation:

Define roles: Identify who is responsible for AI risk management activities (e.g., AI Risk Lead, Legal/Compliance Lead, Product Owners, Data Scientists).
Create a RACI matrix: Document who is Responsible, Accountable, Consulted, and Informed for each AI risk management activity.
Establish a cross-functional AI governance committee: Convene a committee that meets quarterly to review AI risks, compliance status, and policy updates.
Assign accountability: Ensure that every AI system has a named owner who is accountable for its risk management.

Example RACI matrix:

| Activity | AI Risk Lead | Legal/Compliance | Product Owner | Data Scientist |
|---|---|---|---|
| Regulatory tracking | I | A/R | I | I |
| Impact assessment | C | C | A/R | C |
| Bias testing | C | I | C | A/R |
| Incident response | A/R | C | C | C |
| Policy updates | A/R | C | I | I |

Key: A = Accountable, R = Responsible, C = Consulted, I = Informed

Deliverable: A RACI matrix and a charter for the AI governance committee.

GOVERN 1.5: External Feedback Mechanisms

What it requires:

Your organization must have processes to collect, consider, prioritize, and integrate feedback from external stakeholders (users, affected communities, civil society, domain experts).

Practical implementation:

Establish feedback channels: Create mechanisms for external stakeholders to provide feedback (e.g., a dedicated email address, a feedback form, public consultations).
Document feedback: Log all external feedback in a centralized tracker.
Review and prioritize: Review feedback quarterly and prioritize items for action.
Close the loop: Communicate back to stakeholders how their feedback was considered and what actions were taken.

Example feedback tracker:

| Date | Source | Feedback Summary | Priority | Action Taken | Status |
|---|---|---|---|---|
| Jan 15, 2026 | User email | CV screening AI rejected qualified candidate | High | Reviewed case; updated training data | Closed |
| Feb 3, 2026 | Civil society org | Request for bias testing results | Medium | Published summary of bias testing methodology | Closed |
| Mar 10, 2026 | Domain expert | Suggested improvement to explainability | Low | Added to product roadmap for Q3 | Open |

Deliverable: A feedback tracker and a documented process for external feedback collection and review.

GOVERN 1.6: AI System Inventory

What it requires:

Your organization must maintain an inventory of AI systems and track their associated risks.

Practical implementation:

Create an AI system registry: Develop a centralized database or spreadsheet that lists all AI systems in development or production.
Capture key metadata: For each system, document: name, owner, intended purpose, risk level, compliance status, deployment date.
Update regularly: Require that the registry is updated whenever a new AI system is deployed or an existing system is modified.
Link to risk assessments: Ensure that each system in the registry links to its impact assessment, bias testing results, and compliance documentation.

Example AI system inventory:

| System Name | Owner | Intended Purpose | Risk Level | Compliance Status | Deployment Date |
|---|---|---|---|---|
| CV Screening AI | HR Tech Lead | Automate candidate screening | High-risk (EU AI Act Annex III) | In progress | Q3 2026 |
| Fraud Detection AI | Payments Lead | Detect fraudulent transactions | Not high-risk | Compliant (Article 52) | Jan 2024 |
| Chatbot | Customer Support Lead | Answer customer questions | Not high-risk | Compliant (Article 52) | Mar 2025 |

Deliverable: An AI system inventory with links to risk assessments and compliance documentation.

How the Govern Function Connects to EU AI Act Compliance

If you're preparing for EU AI Act compliance, the NIST AI RMF Govern function provides a structured approach to satisfying many of the regulation's requirements:

GOVERN 1.1 → Tracks EU AI Act and other regulations
GOVERN 1.2 → Integrates EU AI Act trustworthy AI principles (Articles 9, 10, 13, 14, 15)
GOVERN 1.3 → Satisfies impact assessment requirements (implicit in Articles 9, 27)
GOVERN 1.4 → Establishes accountability (required under Article 16, 26)
GOVERN 1.5 → Collects feedback from affected communities (implicit in Article 29)
GOVERN 1.6 → Maintains AI system inventory (required for demonstrating compliance)

Implementing the NIST AI RMF Govern function is not a substitute for EU AI Act compliance, but it provides the organizational foundation you need.

How to Get Govern-Compliant in 20 Minutes

Most organizations spend 1–3 months (and €5,000–€40,000) building a governance framework from scratch. Vigilia delivers a compliance-ready assessment in 20 minutes for €499.

Vigilia's NIST AI RMF analysis includes:

Gap detection: Identifies which Govern subcategories you're missing
Template generation: Provides templates for impact assessments, RACI matrices, and AI system inventories
Remediation roadmap: Step-by-step guidance to implement Govern 1.1–1.6

You answer a structured questionnaire about your AI governance practices. Vigilia generates an audit-ready PDF with gap analysis and remediation steps.

Generate your NIST AI RMF Govern compliance report in 20 minutes: www.aivigilia.com

This article is for informational purposes only and does not constitute legal advice. Consult a qualified AI governance expert or attorney for guidance specific to your organization.

Originally published at Vigilia.

EU AI Act Annex III: Complete High-Risk AI Systems List

Gregorio von Hildebrand — Mon, 11 May 2026 11:37:17 +0000

Annex III lists all AI systems classified as high-risk under the EU AI Act. Learn which use cases trigger compliance obligations before August 2, 2026 enforcement.

The EU AI Act divides AI systems into four risk categories: unacceptable, high, limited, and minimal. Only high-risk AI systems face the full weight of compliance obligations — Articles 9 through 15, technical documentation, conformity assessment, CE marking, and post-market monitoring.

Whether your AI system is high-risk is determined by Annex III, a legally binding list of use cases. If your system falls into any Annex III category, you must comply with all high-risk obligations. If it does not, you may only face limited transparency requirements (Article 52) or no obligations at all.

Enforcement begins August 2, 2026. Fines for deploying a non-compliant high-risk system reach €35 million or 6% of global annual turnover, whichever is higher. This article provides the complete Annex III list, explains what each category covers, and shows how to determine whether your system is high-risk.

How Annex III Works

Annex III is not a static list. The European Commission can update it via delegated acts to add new high-risk categories as AI technology evolves. However, the current list (as of May 2026) covers eight major domains.

A system is high-risk if it meets both of these conditions:

It falls into an Annex III category (biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, or justice), AND
It is used as a safety component of a product covered by EU harmonized legislation (e.g., medical devices, machinery, toys) OR it is itself a product covered by that legislation.

If your system does not fall into any Annex III category, it is not high-risk under the EU AI Act, even if it poses significant ethical or social risks. The Act is use-case-specific, not capability-specific.

The Complete Annex III List

Here are all eight high-risk categories, with explanations and examples.

1. Biometric Identification and Categorization (Annex III.1)

AI systems used for biometric identification or biometric categorization of natural persons.

Subcategory	Description	Examples
Remote biometric identification	Real-time or post-use identification of individuals in public spaces using biometric data (face, gait, voice)	Facial recognition at airports, police surveillance cameras, stadium entry systems
Biometric categorization	Classifying individuals based on biometric data to infer sensitive attributes (race, political opinions, sexual orientation, religious beliefs)	Emotion detection in hiring, ethnicity classification, sexual orientation inference

Key point: Not all biometric systems are high-risk. Biometric authentication (unlocking your phone with Face ID) is not covered by Annex III.1 because it verifies identity, not identifies or categorizes individuals in a broader population.

2. Critical Infrastructure (Annex III.2)

AI systems used as safety components in the management and operation of critical infrastructure.

Subcategory	Description	Examples
Road traffic	AI controlling traffic signals, autonomous vehicle routing, collision avoidance	Traffic management systems, autonomous vehicle control software
Water, gas, heating, electricity supply	AI managing supply, demand, or safety in utility networks	Smart grid optimization, predictive maintenance for power plants, water treatment control systems

Key point: The system must be a safety component. An AI that optimizes energy costs is not high-risk; an AI that prevents blackouts or pipeline failures is.

3. Education and Vocational Training (Annex III.3)

AI systems used to determine access to educational institutions or assess students.

Subcategory	Description	Examples
Admission and enrollment	AI that decides who gets accepted to schools, universities, or training programs	University admissions algorithms, scholarship award systems
Assessment and evaluation	AI that grades exams, evaluates student performance, or influences academic outcomes	Automated essay grading, plagiarism detection that affects grades, AI proctoring systems that flag students for cheating

Key point: AI tutoring tools that provide feedback but do not affect grades or admissions are not high-risk. The trigger is access or evaluation, not assistance.

4. Employment, Worker Management, and Self-Employment (Annex III.4)

AI systems used in recruitment, hiring, promotion, termination, task allocation, or monitoring of workers.

Subcategory	Description	Examples
Recruitment and hiring	AI that screens résumés, ranks candidates, or recommends who to interview or hire	LinkedIn Recruiter AI, HireVue video interview analysis, résumé parsing and ranking tools
Promotion and termination	AI that decides or influences who gets promoted, demoted, or fired	Performance review algorithms, layoff selection models
Task allocation and monitoring	AI that assigns work, monitors productivity, or evaluates worker performance	Warehouse task assignment (Amazon-style), driver monitoring (Uber/Lyft ratings), call center performance scoring

Key point: This is the broadest high-risk category. If your AI touches hiring, firing, or worker evaluation in any way, it is almost certainly high-risk.

5. Essential Private and Public Services (Annex III.5)

AI systems used to evaluate eligibility for or grant access to essential services and benefits.

Subcategory	Description	Examples
Creditworthiness and credit scoring	AI that assesses whether someone qualifies for a loan, credit card, or mortgage	Credit scoring models (FICO-style), loan approval algorithms, buy-now-pay-later eligibility checks
Emergency services dispatch	AI that prioritizes or routes emergency calls (police, fire, ambulance)	911 call triage systems, ambulance dispatch optimization
Public benefits eligibility	AI that determines who qualifies for welfare, unemployment, housing assistance, or healthcare	Fraud detection in welfare systems, eligibility screening for public housing

Key point: The system must affect access. An AI that helps you compare loan offers is not high-risk; an AI that decides whether you get approved is.

6. Law Enforcement (Annex III.6)

AI systems used by or on behalf of law enforcement authorities.

Subcategory	Description	Examples
Risk assessment for offending	AI that predicts the likelihood someone will commit a crime	Recidivism prediction (COMPAS-style), predictive policing heat maps
Polygraph and lie detection	AI that assesses the veracity of statements during investigations	AI-powered lie detectors, voice stress analysis
Evidence evaluation	AI that analyzes evidence to support criminal investigations	DNA match probability, forensic image analysis, gunshot detection (ShotSpotter)
Crime analytics	AI that identifies patterns or predicts where crimes will occur	Predictive policing software, gang affiliation detection, criminal network analysis

Key point: This category applies only to law enforcement use. The same AI used by a private company for fraud detection is not high-risk under Annex III.6 (it may be high-risk under Annex III.5 instead).

7. Migration, Asylum, and Border Control (Annex III.7)

AI systems used to manage migration, asylum applications, or border security.

Subcategory	Description	Examples
Visa and asylum applications	AI that assesses eligibility for visas, asylum, or residence permits	Visa risk assessment tools, asylum claim credibility scoring
Border control	AI that detects illegal border crossings or verifies traveler identity	Automated passport control (e-gates), lie detection at borders, risk profiling for customs
Complaint examination	AI that evaluates complaints related to migration or asylum decisions	Automated review of asylum appeal documents

Key point: This category is narrow and applies primarily to government agencies managing immigration.

8. Administration of Justice and Democratic Processes (Annex III.8)

AI systems used to assist judicial authorities or influence democratic processes.

Subcategory	Description	Examples
Legal research and case law	AI that assists judges or lawyers in researching legal precedents or drafting decisions	Legal research tools (Westlaw AI, ROSS Intelligence), AI-assisted sentencing recommendations
Democratic processes	AI that influences election outcomes, voter behavior, or political campaigns	Voter targeting algorithms, deepfake detection in election content, AI-generated political ads

Key point: AI used by judges to assist in sentencing or case research is high-risk. AI used by lawyers for the same purpose is generally not high-risk (unless it directly influences judicial decisions).

What If Your System Spans Multiple Categories?

If your AI system falls into more than one Annex III category, you must comply with all applicable obligations. For example:

An AI system that screens job applicants (Annex III.4) and uses facial recognition to verify identity (Annex III.1) is high-risk under both categories.
An AI system that assesses creditworthiness (Annex III.5) and predicts fraud risk for law enforcement (Annex III.6) is high-risk under both categories.

You cannot "choose" the easier category. Compliance obligations stack.

What If Your System Is Not on the List?

If your AI system does not fall into any Annex III category, it is not high-risk under the EU AI Act. You may still face limited obligations:

Article 52 (Transparency): If your system interacts with humans (chatbots, deepfakes, emotion recognition), you must disclose that users are interacting with AI.
Article 50 (General-Purpose AI): If you provide a foundation model (GPT, Claude, Mistral), you face separate obligations under Articles 53 and 54.

Most AI systems — recommendation engines, content moderation, marketing optimization, internal analytics — are not high-risk and face minimal or no EU AI Act obligations.

Common Misclassifications

Vigilia's audit engine detects several recurring classification errors:

Overclaiming high-risk status: Providers assume their system is high-risk because it uses sensitive data or makes important decisions. The EU AI Act is use-case-specific, not risk-based in the general sense. If your system is not in Annex III, it is not high-risk.
Underclaiming high-risk status: Providers assume their system is not high-risk because it "only assists" humans. If the system influences hiring, credit access, or law enforcement decisions, it is high-risk even if a human makes the final call.
Ignoring edge cases: A system used for internal HR analytics is not high-risk. The same system used to rank candidates for promotion is high-risk (Annex III.4).

Vigilia's risk classification engine checks your system's intended purpose, use case, and deployment context to determine whether Annex III applies.

How to Determine If Your System Is High-Risk

Follow this decision tree:

Does your system fall into any Annex III category?
- No → Your system is not high-risk. Check Article 52 for transparency obligations.
- Yes → Continue to step 2.
Is your system used for the specific purpose listed in Annex III?
- Example: Your system uses facial recognition, but only to unlock a phone (authentication, not identification). → Not high-risk.
- Example: Your system uses facial recognition to identify individuals in a crowd. → High-risk (Annex III.1).
Is your system a safety component of a regulated product, or is it itself a regulated product?
- Example: Your AI controls a medical device. → High-risk (EU Medical Device Regulation + Annex III).
- Example: Your AI optimizes ad targeting. → Not high-risk (not a safety component, not in Annex III).

If you answered "yes" to all three questions, your system is high-risk and must comply with Articles 9–15, technical documentation, conformity assessment, and post-market monitoring.

Vigilia's Risk Classification Engine

Vigilia's €499 compliance audit includes a risk classification analysis. It checks:

Whether your system falls into any Annex III category
Whether your intended purpose triggers high-risk obligations
Whether you are overclaiming or underclaiming high-risk status
What compliance obligations apply (Articles 9–15, Article 52, Articles 53–54)

The report provides a clear high-risk / not high-risk determination with legal justification, so you know exactly what obligations apply.

Generate your risk classification report now: www.aivigilia.com

Timeline: When Annex III Becomes Enforceable

Date	Milestone
August 2, 2026	Annex III high-risk obligations enforceable
February 2, 2027	Full EU AI Act enforcement (all provisions)

You have 83 days until high-risk obligations become legally binding. Penalties apply immediately after that date.

Final Checklist: Is Your System High-Risk?

Use this checklist to assess your system:

[ ] My system falls into at least one Annex III category (biometrics, infrastructure, education, employment, essential services, law enforcement, migration, justice)
[ ] My system is used for the specific purpose listed in that category (not a tangential use case)
[ ] My system influences access, evaluation, or safety in that domain (not just assistance or analytics)
[ ] I have documented the risk classification with legal justification
[ ] If high-risk, I have begun implementing Articles 9–15 obligations (risk management, data governance, transparency, human oversight, accuracy, cybersecurity)

If you checked the first three boxes, your system is high-risk and you must comply with all obligations. If you checked fewer than three, your system is likely not high-risk, but you should verify with a compliance audit.

Vigilia can generate a full risk classification and gap analysis in 20 minutes.

Try the free EU AI Act checker or generate your full compliance report: www.aivigilia.com

This article is for informational purposes only and does not constitute legal advice. Consult a qualified EU AI Act attorney for guidance specific to your situation.

Originally published at Vigilia.

EU AI Act Article 14: Human Oversight Requirements Explained

Gregorio von Hildebrand — Sun, 10 May 2026 09:47:55 +0000

Article 14 mandates human oversight for high-risk AI systems. Learn what oversight measures you must implement and how to document them before August 2026.

If your AI system is classified as high-risk under the EU AI Act, Article 14 requires you to design it so that humans can effectively oversee its operation. This isn't a checkbox exercise — it's a fundamental architectural requirement that affects how you build, deploy, and monitor your system.

Article 14 mandates that high-risk AI systems must be designed to enable human oversight through appropriate measures. These measures must allow humans to understand system outputs, interpret results, and intervene when necessary. And enforcement begins August 2, 2026 — with fines up to €35 million or 6% of global turnover for non-compliance.

This guide explains what Article 14 requires, what oversight measures satisfy the regulation, and how to implement human oversight that works in practice.

What Article 14 Requires

Article 14 applies to providers of high-risk AI systems (those listed in Annex III or classified under Article 6). It requires that systems be designed and developed in such a way that they can be effectively overseen by natural persons during their use.

Core Human Oversight Obligations

Human oversight must aim to prevent or minimize risks to health, safety, or fundamental rights that may emerge when a high-risk AI system is used in accordance with its intended purpose, or under conditions of reasonably foreseeable misuse.

Oversight measures must enable individuals to:

Fully understand the capacities and limitations of the high-risk AI system
Remain aware of the possible tendency of automatically relying or over-relying on the output produced by a high-risk AI system (automation bias)
Correctly interpret the system's output, taking into account the system's characteristics and available interpretation tools and methods
Decide not to use the system or otherwise disregard, override, or reverse the output in any particular situation
Intervene in the operation of the system or interrupt it through a "stop" button or similar procedure

Additionally, oversight measures must be identified and built into the system by the provider before it's placed on the market, or they must be identified as appropriate for implementation by the deployer.

The Three Types of Human Oversight

Article 14 recognizes three oversight patterns, depending on the risk level and deployment context:

1. Human-in-the-Loop (HITL)

The AI system provides a recommendation, but a human makes the final decision before any action is taken.

Example: An AI system recommends rejecting a loan application, but a human loan officer must review the recommendation and approve the rejection before the applicant is notified.

When required: High-stakes decisions affecting individuals (hiring, credit, benefits eligibility).

2. Human-on-the-Loop (HOTL)

The AI system operates autonomously, but a human monitors its operation in real-time and can intervene if necessary.

Example: An autonomous vehicle drives itself, but a safety operator monitors the system and can take control at any time.

When required: Real-time systems where human-in-the-loop would introduce unacceptable latency, but human intervention must remain possible.

3. Human-in-Command (HIC)

A human oversees the overall operation of the AI system, including the ability to deactivate or shut it down.

Example: A hospital administrator can disable an AI-powered diagnostic tool if it begins producing unreliable results.

When required: All high-risk systems (minimum baseline). Humans must always retain the ability to stop the system.

Most high-risk AI systems require multiple oversight layers — for example, human-in-the-loop for individual decisions plus human-in-command for system-level control.

Article 14 Compliance Checklist

Here's what you must implement and document:

Requirement	What You Must Implement	Evidence Needed
Understanding capacities and limitations	Training materials, system documentation, performance disclosures	User manual, training completion records, instructions for use (Article 13)
Awareness of automation bias	Warnings, training on over-reliance risks, decision-forcing functions	UI warnings, training materials, decision audit logs
Interpretation tools	Explainability features, confidence scores, feature importance	Explainability reports, UI screenshots, interpretation guide
Ability to override or disregard	Override button, manual review workflow, rejection mechanism	UI design docs, override logs, workflow diagrams
Ability to intervene or stop	Emergency stop button, system shutdown procedure, escalation path	Technical architecture, stop button design, incident response plan
Oversight role assignment	Who oversees the system, qualifications required, escalation hierarchy	Role definitions, RACI matrix, training requirements

Practical Example: AI-Powered Hiring Tool

Suppose you provide an AI system that screens CVs and recommends candidates for interviews — a high-risk system under Annex III, point 4(a).

Step 1: Identify Required Oversight Type

Your system makes decisions that significantly affect individuals' access to employment. You need human-in-the-loop oversight: a human must review and approve every hiring decision before candidates are notified.

Step 2: Design Interpretation Tools

You implement explainability features so hiring managers can understand why the system recommended or rejected a candidate:

Feature importance scores: "This candidate was ranked highly due to: relevant experience (35%), education match (28%), skills alignment (22%), other factors (15%)"
Confidence score: "Confidence: 78% (medium confidence — manual review recommended)"
Comparison view: Side-by-side comparison of top candidates with key differentiators highlighted

Step 3: Implement Override Mechanism

You build a workflow where hiring managers can:

Accept the AI recommendation (candidate moves to interview stage)
Reject the AI recommendation (candidate is manually reviewed by senior recruiter)
Flag for review (case escalated to hiring committee)

Every override is logged with a reason code (e.g., "AI missed relevant experience," "candidate has unique background," "bias concern").

Step 4: Mitigate Automation Bias

You add UI warnings to prevent over-reliance:

Decision-forcing prompt: "Before accepting this recommendation, have you reviewed the candidate's full CV?"
Randomized manual review: 10% of AI recommendations are flagged for mandatory manual review, even if the hiring manager agrees with the AI
Training requirement: All hiring managers must complete a 30-minute training on automation bias before using the system

Step 5: Provide System-Level Control

You implement human-in-command oversight:

System administrator (Head of HR) can disable the AI system at any time
Performance dashboard shows accuracy, bias metrics, and override rates in real-time
Automatic shutdown triggers: System disables itself if accuracy drops below 80% or if bias metrics exceed predefined thresholds

Step 6: Document Everything

You create an Oversight Design Document that includes:

Role definitions (who oversees what)
Oversight workflows (diagrams showing decision paths)
Interpretation tools (screenshots, user guide)
Override mechanisms (technical design, logs)
Training requirements (curriculum, completion tracking)
System-level controls (shutdown procedures, escalation paths)

This document becomes part of your Article 11 technical documentation and informs your Article 13 instructions for use.

Common Gaps and How to Fix Them

Gap 1: No Explainability Features

Problem: Your system produces recommendations, but users can't understand why.

Fix: Implement interpretation tools:

Confidence scores (how certain is the system?)
Feature importance (what factors drove this decision?)
Counterfactual explanations (what would need to change for a different outcome?)
Comparison views (how does this case compare to similar cases?)

Gap 2: Override Mechanism Exists But Isn't Used

Problem: Users can override the system, but in practice they almost never do (automation bias).

Fix: Implement decision-forcing functions:

Require users to actively confirm decisions (not just click "accept all")
Randomize mandatory manual reviews
Track override rates and investigate if they're too low
Train users on when and how to override

Gap 3: No System-Level Shutdown Capability

Problem: Individual users can reject recommendations, but no one can stop the entire system if it starts malfunctioning.

Fix: Implement human-in-command controls:

Designate a system owner with shutdown authority
Build an emergency stop mechanism (e.g., admin dashboard with "disable system" button)
Define automatic shutdown triggers (accuracy thresholds, bias thresholds, incident reports)
Document escalation procedures (who gets notified, how quickly, what happens next)

Gap 4: Oversight Roles Are Undefined

Problem: It's unclear who is responsible for overseeing the system, what qualifications they need, or what they're supposed to do.

Fix: Define oversight roles and responsibilities:

Who reviews individual decisions? (e.g., hiring manager, loan officer)
Who monitors system-level performance? (e.g., compliance lead, ML engineer)
Who has authority to shut down the system? (e.g., CTO, Head of Compliance)
What qualifications are required? (e.g., training completion, domain expertise)
How are oversight activities logged and audited?

How Article 14 Connects to Other Articles

Article 14 oversight requirements intersect with several other obligations:

Article 9 (Risk Management): Risks identified in your Article 9 risk assessment inform what oversight measures are needed under Article 14.
Article 13 (Transparency): The oversight measures you implement under Article 14 must be described in your Article 13 instructions for use.
Article 29 (Obligations of Deployers): Deployers must assign oversight to individuals with the necessary competence, training, and authority — which requires that you (the provider) have designed the system to support effective oversight.
Article 72 (Right to Explanation): Individuals affected by high-risk AI decisions have a right to obtain an explanation — which requires that your oversight tools include explainability features.

What Regulators Will Look For

When a market surveillance authority audits your high-risk AI system, they will ask:

Show me how humans oversee this system. (What workflows, tools, and controls exist?)
How do users understand what the system is doing? (Are explainability features built in?)
Can users override or reject system outputs? (Is there a documented override mechanism?)
How do you prevent automation bias? (What training, warnings, or decision-forcing functions exist?)
Who can shut down the system if it malfunctions? (Is there a designated owner with shutdown authority?)
How do you know oversight is working? (Are override rates, review times, and incident reports tracked?)

If you can't demonstrate effective oversight with documentation and logs, you're non-compliant.

Timeline and Enforcement

Date	Milestone
August 2, 2026	Article 14 obligations become enforceable for high-risk AI systems
February 2, 2027	Full EU AI Act enforcement (all provisions)

If your high-risk AI system is already deployed, you must implement compliant oversight measures by August 2, 2026. If you're building a new system, Article 14 applies from the design phase.

How Vigilia Helps

Vigilia's EU AI Act audit includes an Article 14 gap analysis:

We assess whether your system includes the oversight measures required by Article 14
We identify missing capabilities (explainability tools, override mechanisms, shutdown controls)
We provide a remediation roadmap with specific design changes and documentation requirements

The audit takes 20 minutes and costs €499 — compared to €5,000–€40,000 for a traditional compliance audit.

Ready to check your Article 14 compliance? Generate your audit-ready report at www.aivigilia.com. You'll get a detailed gap analysis covering Articles 9, 10, 12, 13, 14, and 52, plus a remediation roadmap you can hand to your engineering and compliance teams.

This article is for informational purposes only and does not constitute legal advice. Consult a qualified legal professional for guidance on your specific situation.

Originally published at Vigilia.

EU AI Act Article 13: Transparency Obligations for High-Risk AI

Gregorio von Hildebrand — Sat, 09 May 2026 09:28:37 +0000

Article 13 requires high-risk AI systems to be transparent and provide information to users. Learn the six transparency obligations and how to document compliance.

If your AI system is classified as high-risk under the EU AI Act, Article 13 mandates that it must be "sufficiently transparent to enable users to interpret the system's output and use it appropriately." This is not a soft recommendation — it's an enforceable obligation with fines up to €35 million or 6% of global turnover for non-compliance.

Most companies underestimate Article 13. They assume transparency means "add a disclaimer" or "show confidence scores." In reality, Article 13 requires six distinct categories of information, each with specific documentation requirements.

This guide breaks down what Article 13 actually requires, common compliance gaps, and how to build transparency into your high-risk AI system before the August 2, 2026 enforcement deadline.

What Article 13 Actually Requires

Article 13 mandates that high-risk AI systems must provide users with information that is:

Concise, complete, correct, and clear — no jargon, no ambiguity
Relevant and accessible — tailored to the user's role and technical literacy
Sufficient to enable users to interpret the output — users must understand what the system is telling them and why
Sufficient to enable users to use the system appropriately — users must understand when to trust the output and when to override it

The regulation specifies six categories of information that must be provided:

Identity and contact details of the provider
Characteristics, capabilities, and limitations of performance — including accuracy, robustness, and known failure modes
Changes to the system and its performance — version history and updates
Level of accuracy, robustness, and cybersecurity — quantitative metrics
Known or foreseeable circumstances that may lead to risks — edge cases and failure modes
Human oversight measures — what the human operator is expected to do

Each of these must be documented and made available to users. If you deploy a high-risk AI system without this information, you're non-compliant.

The Six Information Categories in Detail

1. Identity and Contact Details of the Provider

This is the simplest requirement: users must know who built the system and how to contact them.

What auditors look for:

Provider name, address, and contact email displayed in the system UI or documentation
Clear identification of the legal entity responsible for compliance

Common failure mode: Deploying a system with no provider identification or burying contact details in a 50-page terms-of-service document.

2. Characteristics, Capabilities, and Limitations of Performance

Users must understand what the system can and cannot do. This includes:

Intended purpose — what the system is designed for
Performance characteristics — accuracy, latency, throughput
Known limitations — tasks the system cannot perform reliably

What auditors look for:

A written specification of intended purpose and out-of-scope use cases
Performance benchmarks (e.g., "92% accuracy on validation set")
Documentation of known failure modes (e.g., "performs poorly on handwritten text")

Common failure mode: Providing only marketing claims ("state-of-the-art accuracy") without quantitative performance data or documented limitations.

3. Changes to the System and Its Performance

Users must be notified when the system is updated and how its performance has changed.

What auditors look for:

Version history with release notes
Performance comparison before and after updates
Notification mechanism for users (e.g., email, in-app alert)

Common failure mode: Silently updating models without notifying users or documenting performance changes.

4. Level of Accuracy, Robustness, and Cybersecurity

Article 13 explicitly requires quantitative metrics for:

Accuracy — precision, recall, F1, or domain-specific measures
Robustness — performance under adversarial inputs or distribution shift
Cybersecurity — resistance to data poisoning, model extraction, or adversarial attacks

What auditors look for:

Test set performance reports with confidence intervals
Robustness benchmarks (e.g., performance on out-of-distribution data)
Cybersecurity audit reports or penetration test results

Common failure mode: Reporting only aggregate accuracy without breaking down performance by demographic group, edge case, or adversarial scenario.

5. Known or Foreseeable Circumstances That May Lead to Risks

Users must be warned about situations where the system is likely to fail or produce unsafe outputs.

What auditors look for:

A documented list of edge cases and failure modes
Risk mitigation guidance (e.g., "Do not use this system for medical diagnosis")
Evidence that users are trained on these limitations

Common failure mode: Providing no failure mode documentation or assuming users will "figure it out."

6. Human Oversight Measures

Article 14 mandates human oversight for high-risk AI systems. Article 13 requires that users be informed about what oversight actions they are expected to take.

What auditors look for:

Documentation of the human operator's role (e.g., "Review all flagged cases before final decision")
Training materials for human operators
Evidence that the system supports oversight (e.g., explainability features, override mechanisms)

Common failure mode: Deploying a fully automated system with no documented human oversight role.

Article 13 Compliance Checklist

| Information Category | Documentation Needed | Common Gap |\n|---|---|---|\n| Provider identity | Name, address, contact email in UI/docs | No provider identification |\n| Characteristics, capabilities, limitations | Intended purpose, performance benchmarks, failure modes | Marketing claims without quantitative data |\n| Changes and updates | Version history, release notes, user notifications | Silent updates with no notification |\n| Accuracy, robustness, cybersecurity | Test set reports, robustness benchmarks, security audits | Aggregate accuracy only, no edge case breakdown |\n| Known risks and failure modes | Edge case list, risk mitigation guidance | No failure mode documentation |\n| Human oversight measures | Operator role, training materials, override mechanisms | No documented oversight role |\n

How Article 13 Interacts with Other Requirements

Article 13 does not exist in isolation. It intersects with:

Article 9 (Risk Management) — the risks you identify in Article 9 must be disclosed to users under Article 13
Article 10 (Data Governance) — the data quality metrics you document under Article 10 inform the accuracy disclosures required by Article 13
Article 14 (Human Oversight) — the oversight measures you design under Article 14 must be explained to users under Article 13
Article 52 (Transparency for Certain AI Systems) — if your system is also subject to Article 52 (e.g., chatbots, emotion recognition), you have additional transparency obligations

A complete compliance strategy addresses all of these together, not as isolated checklists.

Concrete Example: Credit Scoring System

Suppose you've built an AI-powered credit scoring system. Under Annex III.5(b), this is a high-risk system. Here's what Article 13 compliance looks like:

Provider identity: The system UI displays "Provided by FinTech Corp, 123 Main St, Dublin, Ireland. Contact: compliance@fintechcorp.eu"
Characteristics, capabilities, limitations: You document that the system is designed for consumer credit decisions up to €50,000, achieves 89% accuracy on validation data, and performs poorly for applicants with thin credit files (fewer than 3 tradelines).
Changes and updates: When you update the model, you send an email to all users with a link to release notes showing the new accuracy (91%) and changes in false positive/false negative rates.
Accuracy, robustness, cybersecurity: You provide a performance report showing precision, recall, and F1 by demographic group, plus robustness testing results showing performance under adversarial inputs (e.g., applicants who deliberately misreport income).
Known risks: You document that the system may underestimate risk for self-employed applicants and overestimate risk for recent immigrants. You provide guidance: "Manually review all self-employed and recent immigrant applications."
Human oversight: You document that loan officers must review all applications flagged as "borderline" (score 600–650) and have the authority to override the system's recommendation.

All of this is packaged into a User Information Document that is provided to every loan officer who uses the system. When an auditor asks for Article 13 evidence, you hand them this document plus training records showing that loan officers have been trained on it.

What Happens If You Don't Comply

Non-compliance with Article 13 can trigger:

Administrative fines up to €35 million or 6% of global turnover (whichever is higher)
Market surveillance actions — national authorities can order you to withdraw your system from the market or suspend its use
Liability exposure — if a user misuses your system because you failed to provide adequate information, you may be liable for resulting harms

The enforcement timeline is fixed: August 2, 2026. That's 85 days from today. If you're deploying a high-risk AI system in the EU, you need Article 13 compliance documentation now.

Common Anti-Patterns Vigilia Detects

Vigilia's EU AI Act audit flags these Article 13 anti-patterns:

No user-facing documentation — the system has no UI or documentation explaining its purpose, limitations, or performance
Marketing claims without quantitative data — the system claims "high accuracy" but provides no test set metrics
No failure mode documentation — users are not warned about edge cases or situations where the system is likely to fail
No human oversight guidance — users are not told what oversight actions they are expected to take
Silent updates — the system is updated without notifying users or documenting performance changes
No provider identification — users do not know who built the system or how to contact them

Each anti-pattern is mapped to a fine exposure estimate and a remediation roadmap.

How to Get Compliant in 20 Minutes

Vigilia's EU AI Act audit generates an Article 13 gap analysis in 20 minutes. You answer questions about your transparency documentation, user information, and oversight measures. Vigilia maps your answers to Article 13 requirements and flags gaps.

The output is an audit-ready PDF covering:

Article 13 compliance score (0–100)
Specific gaps (e.g., "No documented failure modes")
Remediation roadmap with estimated effort
Fine exposure estimates for each gap

Traditional compliance audits cost €5,000–€40,000 and take 1–3 months. Vigilia costs €499 and takes 20 minutes.

Generate your Article 13 compliance report now: www.aivigilia.com

This article is for informational purposes only and does not constitute legal advice. Consult a qualified EU AI Act attorney for guidance on your specific situation.

Originally published at Vigilia.

EU AI Act Article 10: Data Governance Requirements Explained

Gregorio von Hildebrand — Sat, 09 May 2026 05:40:09 +0000

Article 10 mandates training, validation, and testing data governance for high-risk AI. Learn what documentation you need and how to prove compliance before August 2026.

If your AI system is classified as high-risk under the EU AI Act, Article 10 is non-negotiable. It mandates specific data governance practices for training, validation, and testing datasets — and enforcement begins August 2, 2026. Fines for non-compliance can reach €35 million or 6% of global turnover.

Most teams assume "we have data lineage" equals compliance. It doesn't. Article 10 requires documented design choices, bias mitigation steps, and statistical properties of every dataset used to train or validate a high-risk system.

This guide walks through what Article 10 actually requires, which systems it applies to, and how to document compliance before the deadline.

What Article 10 Requires

Article 10 applies to high-risk AI systems listed in Annex III (e.g., HR screening tools, credit scoring, biometric identification, critical infrastructure management). It mandates that training, validation, and testing data meet specific quality criteria:

Requirement	What It Means	Documentation You Need
Relevant, representative, free of errors	Data must reflect the real-world use case without systematic gaps	Dataset composition report showing demographic/geographic coverage
Appropriate statistical properties	Data must have sufficient volume, variance, and balance for the task	Statistical summary: sample size, class distribution, variance metrics
Examination for biases	You must actively search for and document biases that could lead to discriminatory outcomes	Bias audit report with mitigation steps (e.g., resampling, fairness constraints)
Data governance and management	Formal processes for data collection, labeling, storage, and versioning	Data governance policy document + audit trail of dataset versions

Article 10 does not prescribe specific statistical tests or bias metrics. That's intentional — the regulation is technology-neutral. But it does require you to document your choices and explain why they're appropriate for your system's risk profile.

Who Article 10 Applies To

Article 10 obligations fall on providers of high-risk AI systems — the entity that develops the system or has it developed and places it on the EU market under their name or trademark.

If you're a deployer (an organization using a high-risk system developed by someone else), Article 10 compliance is the provider's responsibility. But you still need to verify that the provider has fulfilled it, especially if you're in a regulated sector (finance, healthcare, public services).

If you're a startup or scale-up building your own AI, you are the provider. Article 10 applies in full.

The Five Data Governance Practices Article 10 Demands

1. Dataset Design Choices Must Be Documented

Why did you choose this dataset? What real-world population or scenario does it represent? What are its known limitations?

Example: If you're building an AI-powered resume screener (Annex III, category 4), your training data must represent the actual applicant population you'll encounter. If your dataset is 80% male CVs from tech roles, and you deploy the system to screen healthcare applicants, Article 10 is violated.

What to document:

Dataset source and collection methodology
Geographic, demographic, and domain coverage
Known gaps or underrepresented groups
Rationale for dataset selection

2. Statistical Properties Must Be Appropriate

"Appropriate" means sufficient for the task's risk level and complexity. A high-risk credit scoring model needs more rigorous statistical validation than a low-risk content recommendation engine.

What to document:

Sample size and how it was determined
Class distribution (e.g., 60% approved loans, 40% rejected)
Feature variance and correlation analysis
Train/validation/test split ratios and methodology

If your dataset is imbalanced (e.g., 95% negative class), document why that reflects reality and what steps you took to prevent the model from ignoring the minority class (e.g., stratified sampling, class weighting, SMOTE).

3. Bias Examination Is Mandatory

Article 10(3) explicitly requires examining datasets for "possible biases" that could lead to discrimination based on protected characteristics (race, gender, age, disability, etc.).

This is not optional. You must actively search for bias, document what you found, and explain your mitigation strategy.

Practical steps:

Slice your dataset by protected attributes (if available) and measure performance disparities
Use fairness metrics (e.g., demographic parity, equalized odds, calibration) appropriate to your use case
Document any disparities found and the remediation steps taken (e.g., rebalancing, fairness constraints, post-processing)
If protected attributes are not in your dataset, document proxy analysis (e.g., ZIP code as a proxy for race in US credit data)

Example: A hiring AI trained on historical data may learn that "gaps in employment" correlate with rejection — but if women are more likely to have employment gaps due to parental leave, the model encodes gender bias. Article 10 requires you to detect and mitigate this.

4. Data Governance Processes Must Be Formalized

Article 10(4) requires "data governance and management practices" — not just good intentions, but documented processes.

Minimum documentation:

Data collection policy (who can add data, under what conditions)
Labeling guidelines and quality control (inter-annotator agreement scores, label audits)
Data versioning and lineage (which model version was trained on which dataset version)
Access controls and audit logs (who accessed training data, when, and why)

If you retrain your model on new data, you must repeat the Article 10 analysis for the updated dataset. One-time compliance is not sufficient.

5. Testing Data Must Be Separate and Representative

Article 10(5) requires that testing datasets be "appropriate, representative, free of errors and complete" — and separate from training data.

This is basic ML hygiene, but the EU AI Act makes it a legal requirement. If you evaluate your model on the same data you trained it on, you violate Article 10.

What to document:

How you ensured test data independence (e.g., temporal split, stratified holdout)
Why your test set represents real-world deployment conditions
Test set performance broken down by subgroups (to detect disparate impact)

Common Article 10 Compliance Gaps

Most teams building high-risk AI have some data governance practices. But few have the documentation Article 10 demands. Here are the most common gaps:

No bias examination documentation — teams run fairness metrics but don't document findings or mitigation steps
No dataset design rationale — teams use "whatever data we had" without documenting why it's appropriate
No versioning or lineage — teams retrain models but can't trace which dataset version produced which model version
No statistical justification — teams don't document why their sample size, class balance, or feature set is sufficient for the risk level
No formal governance policy — data practices exist informally but aren't written down or auditable

How to Document Article 10 Compliance

Article 10 compliance is proven through technical documentation (required under Article 11). At minimum, you need:

Dataset Specification Document — for each dataset (training, validation, test):
- Source, collection date, and methodology
- Size, structure, and statistical properties
- Known limitations and gaps
- Bias examination results and mitigation steps
Data Governance Policy — organization-wide:
- Data collection and labeling standards
- Versioning and lineage tracking
- Access controls and audit procedures
- Retraining and re-evaluation triggers
Model Card or Technical Documentation — per model:
- Which datasets were used (with version hashes)
- Why those datasets are appropriate for the use case
- Test set performance overall and by subgroup
- Residual risks and monitoring plan

These documents must be maintained and updated throughout the system's lifecycle. If you retrain, you update the documentation. If you discover a new bias, you document it and your response.

Article 10 and the August 2026 Deadline

Article 10 obligations become enforceable on August 2, 2026 for high-risk AI systems. If your system is already in production, you have until that date to bring your data governance into compliance.

If you're launching a new high-risk system after August 2, 2026, Article 10 compliance is required before you place it on the market.

The enforcement timeline is fixed. August 2, 2026 doesn't move. Fines for non-compliance start at €15 million or 3% of global turnover (for data governance violations specifically) and can escalate to €35 million or 6% for systemic non-compliance.

How Vigilia Helps with Article 10 Compliance

Vigilia's EU AI Act audit includes an Article 10 gap analysis as part of the high-risk system assessment. The report identifies:

Whether your system is high-risk (and therefore subject to Article 10)
Which data governance documentation is missing
Specific remediation steps to close Article 10 gaps
Estimated compliance effort and timeline

The audit takes 20 minutes and costs €499 — versus €5,000–€40,000 and 1–3 months for a traditional compliance audit.

Generate your Article 10 compliance report now: https://www.aivigilia.com

If you're not ready to purchase, try the free EU AI Act checker to see if your system is classified as high-risk: https://www.aivigilia.com

This article is for informational purposes only and does not constitute legal advice. Consult a qualified EU AI Act attorney for compliance guidance specific to your system.

Originally published at Vigilia.

EU AI Act Article 53: GPAI Provider Obligations Explained

Gregorio von Hildebrand — Tue, 28 Apr 2026 10:24:29 +0000

Article 53 requires GPAI providers to submit technical docs, risk assessments, and adversarial testing. Here's what you actually need to prepare before August 2026.

If you're building or deploying a general-purpose AI model (GPAI) — think foundation models, large language models, or multi-modal systems — Article 53 of the EU AI Act is your compliance checklist. It's the article that tells GPAI providers exactly what they must submit to regulators, and it's enforceable from August 2, 2026.

Unlike the high-risk system obligations in Articles 9–15, Article 53 is tailored specifically for foundation model providers. The requirements are lighter than full high-risk compliance, but they're not optional — and the penalties for non-compliance are the same: up to €15 million or 3% of global annual turnover, whichever is higher.

This guide walks through what Article 53 actually requires, what documentation you need to prepare, and how to structure your compliance workflow before the enforcement deadline.

What Is a GPAI System Under the EU AI Act?

Article 3(44) defines a general-purpose AI system as an AI model trained on broad data that can perform a wide range of tasks. Examples include:

Large language models (GPT-4, Claude, Llama, Mistral)
Multi-modal models (DALL·E, Stable Diffusion, Gemini)
Code generation models (Copilot, CodeLlama)
Embedding models used across multiple downstream applications

If your model is only trained for a single, narrow use case (e.g., fraud detection in banking), it's not a GPAI — it's a specific-purpose AI system and falls under different articles.

Article 53 Core Obligations

Article 53 imposes four main requirements on GPAI providers:

Technical documentation describing the model, training data, compute resources, and capabilities
Instructions for use for downstream deployers (your customers or internal teams)
Cooperation with the AI Office if your model is flagged for systemic risk assessment
Transparency obligations if your model is classified as high-risk GPAI (Article 53(1)(b))

Let's break down each one.

1. Technical Documentation (Article 53(1)(a))

You must prepare and maintain documentation covering:

Model architecture: Transformer type, parameter count, training objective
Training data: Data sources, curation process, known biases or gaps
Compute resources: Total FLOPs, training duration, hardware used
Capabilities and limitations: What the model can and cannot do reliably
Risk mitigation measures: Steps taken to reduce harmful outputs (e.g., RLHF, red-teaming)

This documentation must be updated whenever you release a new model version or make material changes to training data or fine-tuning.

Example: Technical Documentation Checklist

Section	Required Content	Format
Model Overview	Architecture, parameter count, release date	Markdown or PDF
Training Data	Dataset names, size, curation methodology	Structured table
Compute	Total FLOPs, GPU hours, training cost estimate	Numeric summary
Capabilities	Benchmarks, task performance, known failure modes	Test results + narrative
Risk Mitigation	Adversarial testing, alignment techniques, content filters	Process documentation

2. Instructions for Use (Article 53(1)(a))

If you're providing a GPAI model to downstream deployers (via API, download, or SaaS), you must give them clear instructions on:

Intended use cases (and explicitly flagged prohibited uses)
Known limitations (e.g., "not suitable for medical diagnosis")
Integration requirements (e.g., "requires human review for high-stakes decisions")
Monitoring recommendations (e.g., "log all outputs for audit")

This is the equivalent of a "compliance datasheet" — your customers need it to assess whether their use of your model triggers high-risk obligations under Articles 6 and 9.

Practical Example: Instructions for a Code Generation Model

If you're offering a Copilot-style code assistant, your instructions might include:

Intended use: "Autocomplete and refactoring suggestions for software developers"
Not intended for: "Generating production code without human review; security-critical systems without additional validation"
Limitations: "May suggest insecure patterns; does not guarantee correctness"
Deployer obligations: "If used in safety-critical software development (Annex III), deployer must implement human oversight per Article 14"

3. Cooperation with the AI Office (Article 53(2))

If the European AI Office designates your model as systemic risk GPAI (Article 51), you must:

Respond to information requests within specified timelines
Provide access to model weights, training data, or evaluation results if requested
Participate in adversarial testing or third-party audits

Systemic risk classification applies if your model meets thresholds for compute (≥10²⁵ FLOPs) or demonstrates capabilities that could cause serious harm at scale (e.g., generating bioweapon instructions, large-scale disinformation).

Most startups and mid-sized AI companies will not hit the systemic risk threshold — this is aimed at OpenAI, Anthropic, Google, Meta, and similar frontier labs.

4. Transparency for High-Risk GPAI (Article 53(1)(b))

If your GPAI is used in a high-risk application listed in Annex III (e.g., hiring, credit scoring, law enforcement), you must also:

Publish a public summary of the model's capabilities and limitations
Disclose training data sources (at a high level — not raw datasets)
Maintain an EU representative if you're based outside the EU

This overlaps with Article 13 (transparency for high-risk systems), but Article 53 makes it explicit for GPAI providers.

Timeline and Enforcement

Date	Milestone
August 2, 2026	Article 53 obligations enforceable
February 2, 2027	Full EU AI Act enforcement (all articles)

You have until August 2, 2026 to prepare and publish your Article 53 documentation. After that date, regulators can request it at any time, and failure to produce it is a violation.

How to Prepare: 5-Step Compliance Workflow

Step 1: Classify Your Model

Is it a GPAI (general-purpose) or specific-purpose AI? If you're unsure, ask:

Can the model perform multiple unrelated tasks?
Is it trained on broad, general data (not domain-specific)?
Do you offer it as a platform or API for others to build on?

If yes to all three, it's a GPAI.

Step 2: Draft Technical Documentation

Use the checklist above. Store it in version-controlled markdown or a structured PDF. Update it with every model release.

Step 3: Write Instructions for Use

Create a one-page "compliance datasheet" for downstream deployers. Include:

Intended use cases
Prohibited uses
Known limitations
Deployer obligations (if any)

Step 4: Assess Systemic Risk

Calculate total training FLOPs. If you're below 10²⁵, you're not systemic risk. If you're above, prepare for additional scrutiny (and budget for third-party audits).

Step 5: Publish Transparency Summary (If High-Risk)

If your model is used in Annex III applications, publish a public summary on your website. Keep it non-technical but specific enough to be useful.

Common Objections and Answers

"We're a startup — do we really need this?"

If you're offering a GPAI model to EU customers or deploying it in the EU, yes. Article 53 applies regardless of company size.

"Our model is open-source — does that exempt us?"

No. Open-source GPAI providers have the same obligations. You still need technical documentation and instructions for use.

"Can we just copy OpenAI's model card?"

Model cards are a good starting point, but Article 53 requires more detail — especially on risk mitigation, compute resources, and deployer obligations.

"What if we only fine-tune someone else's model?"

If you're fine-tuning a third-party GPAI and offering it as a service, you're a deployer, not a provider. Your obligations are under Articles 9–15 (if high-risk) or Article 52 (if transparency-only). Article 53 applies to the original foundation model provider.

How Vigilia Helps

Vigilia's EU AI Act audit covers Article 53 obligations for GPAI providers. The report includes:

Gap analysis: which documentation you're missing
Template checklists for technical docs and instructions for use
Systemic risk assessment (compute threshold check)
Remediation roadmap with timeline to August 2, 2026

Traditional compliance consultants charge €5,000–€40,000 and take 1–3 months. Vigilia delivers the same output in 20 minutes for €499.

Ready to check your Article 53 compliance?

Generate your audit report at https://www.aivigilia.com — article-by-article gap analysis, remediation roadmap, and audit-ready PDF in 20 minutes.

This article is for informational purposes only and does not constitute legal advice. Consult a qualified EU AI Act attorney for binding guidance on your specific situation.

Originally published at Vigilia.

EU AI Act Article 53: GPAI Provider Obligations Explained

Gregorio von Hildebrand — Sat, 25 Apr 2026 09:04:10 +0000

Article 53 requires GPAI providers to submit technical documentation, transparency info, and systemic risk evaluations. Here's what you actually need to prepare.

If you're building or deploying a general-purpose AI model (GPAI) in the EU, Article 53 of the EU AI Act defines what you must submit to regulators—and the deadline is closer than most teams think.

Article 53 sits alongside Article 52 (transparency obligations for AI systems that interact with humans) but targets a different audience: providers of foundation models and large language models that can be adapted to a wide range of downstream tasks. If your model is used by third parties, embedded in products, or fine-tuned for multiple use cases, Article 53 likely applies to you.

This guide walks through the three core obligations, what documentation you need, and how to prepare before enforcement begins on August 2, 2026.

What Is a General-Purpose AI Model Under Article 53?

The EU AI Act defines a general-purpose AI model (GPAI) as an AI model—including foundation models and large language models—that:

Displays significant generality
Is capable of performing a wide range of tasks
Can be integrated into a variety of downstream systems or applications

Examples include:

OpenAI GPT-4, Anthropic Claude, Google Gemini
Open-weight models like Llama 3, Mistral, Falcon
Embedding models (e.g., text-embedding-ada-002, Cohere Embed)
Multimodal models (CLIP, Flamingo, GPT-4 Vision)

If your model is task-specific (e.g., trained only for sentiment analysis or named entity recognition), Article 53 does not apply. But if it can be fine-tuned, prompted, or adapted for multiple use cases, it likely qualifies as GPAI.

The Three Core Obligations of Article 53

Article 53 imposes three categories of requirements on GPAI providers:

Obligation	What You Must Submit	Deadline
Technical Documentation	Architecture, training data, compute resources, evaluation results	Before market placement
Transparency Information	Publicly accessible summary of training data sources, copyright compliance statement	Before market placement
Systemic Risk Evaluation	Risk assessment for models with systemic risk (>10²⁵ FLOPs training threshold)	Ongoing, updated annually

Let's break down each one.

1. Technical Documentation (Article 53.1.a)

You must prepare and maintain up-to-date technical documentation that includes:

Model architecture: Number of parameters, layer structure, attention mechanisms, tokenization strategy
Training data: Description of data sources, curation methods, filtering rules, and known limitations or biases
Training process: Compute resources (FLOPs), training duration, optimization algorithms, hyperparameters
Evaluation results: Benchmarks, accuracy metrics, safety evaluations, red-teaming findings

This documentation must be available to the AI Office and national authorities upon request. It does not need to be public, but it must exist and be current.

Practical example: What a compliant technical doc looks like

A GPAI provider releasing a 7B-parameter language model would include:

Architecture: "Transformer decoder, 32 layers, 4096 hidden dimensions, 32 attention heads, SentencePiece tokenizer with 32k vocab"
Training data: "1.2 trillion tokens from Common Crawl (filtered for toxicity and PII), GitHub (permissive licenses only), Wikipedia, books corpus (Project Gutenberg)"
Training: "Pre-trained on 512 A100 GPUs for 21 days (~2.1e23 FLOPs), AdamW optimizer, cosine learning rate schedule"
Evaluation: "MMLU: 62.3%, HumanEval: 28.7%, TruthfulQA: 41.2%. Red-team findings: jailbreak resistance moderate, no critical safety failures"

2. Transparency Information (Article 53.1.b)

You must publish a publicly accessible summary that includes:

A general description of the training data sources
Information on how rights holders can request exclusion of their content from training data (opt-out mechanism)

This is the only part of Article 53 that must be public. It's typically published as a model card, data sheet, or transparency report on your website or model hub page (Hugging Face, GitHub, etc.).

What copyright compliance means in practice

Under Article 4 of the Copyright Directive, you can use copyrighted material for text and data mining unless the rights holder has expressly reserved their rights. Your transparency statement must:

Confirm that you respect robots.txt, TDM reservation tags, and opt-out requests
Provide a contact mechanism for rights holders to request exclusion
Document any licenses or permissions obtained for training data

Example statement:

"Training data was sourced from publicly available web content, respecting robots.txt and TDM opt-out signals. Rights holders may request exclusion of their content by contacting legal@example.com. All code data is limited to permissive open-source licenses (MIT, Apache 2.0, BSD)."

3. Systemic Risk Evaluation (Article 53.1.c)

If your model meets the systemic risk threshold—defined as models trained with more than 10²⁵ FLOPs (floating-point operations)—you must conduct and document:

An assessment of systemic risks, including risks from misuse, cybersecurity vulnerabilities, and societal impact
Mitigation measures implemented
An annual update of this evaluation

As of April 2025, only a handful of models exceed this threshold:

GPT-4 (~10²⁵ FLOPs estimated)
PaLM 2, Gemini Ultra
Claude 3 Opus (estimated)

Most open-weight models (Llama 3 70B, Mistral Large, Falcon 180B) are below the threshold and do not require systemic risk evaluations under Article 53.

Who Enforces Article 53?

Article 53 obligations are enforced by:

The European AI Office (centralized oversight of GPAI models)
National competent authorities in each member state
Market surveillance authorities for downstream AI systems that integrate GPAI models

Penalties for non-compliance can reach €15 million or 3% of global annual turnover, whichever is higher (Article 99).

How to Prepare for Article 53 Compliance

Here's a checklist for GPAI providers:

Determine if Article 53 applies: Is your model general-purpose, or is it task-specific?
Draft technical documentation: Architecture, training data, compute, evaluation results
Publish transparency information: Data sources, copyright compliance, opt-out mechanism
Assess systemic risk threshold: Calculate training FLOPs; if >10²⁵, prepare risk evaluation
Establish update cadence: Technical docs and risk evaluations must be kept current
Designate a compliance owner: Assign responsibility for Article 53 submissions and updates

Article 53 vs. Article 52: What's the Difference?

Article	Applies To	Key Requirement
Article 52	AI systems that interact with humans (chatbots, deepfakes, emotion recognition)	Disclose to users that they are interacting with AI
Article 53	Providers of general-purpose AI models (foundation models, LLMs)	Submit technical documentation and transparency info to regulators

If you deploy a chatbot powered by a GPAI model, both articles apply: Article 52 requires you to disclose the chatbot is AI, and Article 53 requires the model provider to submit documentation to the AI Office.

What Happens If You Don't Comply?

Non-compliance with Article 53 can result in:

Administrative fines: Up to €15M or 3% of global turnover
Market access restrictions: Your model may be prohibited from EU deployment
Reputational damage: Public enforcement actions are published by the AI Office

Given the low cost of compliance (documentation you likely already maintain internally), the risk-reward calculus strongly favors proactive compliance.

Get Compliant in 20 Minutes

If you're deploying AI systems that integrate GPAI models—or building your own foundation model—you need to know your compliance posture before August 2, 2026.

Vigilia delivers an article-by-article EU AI Act gap analysis in 20 minutes, covering Articles 9, 10, 12, 13, 14, and 52, with a remediation roadmap and fine exposure estimates. Traditional audits cost €5,000–€40,000 and take months. Vigilia costs €499 and runs in 20 minutes.

Generate your compliance report now: www.aivigilia.com

This article is for informational purposes only and does not constitute legal advice. Consult qualified legal counsel for compliance guidance specific to your situation.

Originally published at Vigilia.

EU AI Act Article 53: GPAI Provider Obligations Explained

Gregorio von Hildebrand — Thu, 23 Apr 2026 09:53:10 +0000

Article 53 requires GPAI providers to submit technical docs and cooperate with authorities. Here's what foundation model builders must actually do before August 2026.

If you're building or deploying a general-purpose AI model (GPAI) — think GPT-4, Claude, Mistral, or Llama — Article 53 of the EU AI Act creates a new set of obligations that kick in on August 2, 2026.

Unlike Articles 9–15 (which apply to high-risk AI systems), Article 53 targets GPAI providers directly. It requires technical documentation, transparency about training data, cooperation with authorities, and adherence to the AI Office's codes of practice.

This guide walks through what Article 53 actually requires, who it applies to, and what you need to prepare before the enforcement deadline.

Who Article 53 Applies To

Article 53 applies to providers of general-purpose AI models placed on the EU market. A GPAI model is defined as:

An AI model trained on large amounts of data, capable of performing a wide range of tasks, and intended to be integrated into various downstream systems or applications.

In-Scope Examples

Foundation models (GPT-4, Claude, Gemini, Llama, Mistral)
Multimodal models (DALL·E, Stable Diffusion, Midjourney)
Embedding models distributed as APIs or libraries
Code generation models (Codex, GitHub Copilot backend)

Out-of-Scope Examples

A chatbot built on top of GPT-4 (you're a deployer, not a GPAI provider)
A narrow-domain model trained only for sentiment analysis
An internal model not placed on the EU market

If you're a downstream deployer (e.g., you use OpenAI's API to build a customer service bot), Article 53 does not apply to you directly — but Articles 9–15 might, depending on your use case.

Core Obligations Under Article 53

Article 53 establishes four primary requirements for GPAI providers:

1. Technical Documentation

You must prepare and maintain up-to-date technical documentation that includes:

Model architecture and training methodology
Data sources, including a description of training data and its provenance
Compute resources used (e.g., GPU-hours, training duration)
Testing and validation procedures
Known limitations and intended use cases
Measures taken to detect and mitigate bias

This documentation must be sufficient for the AI Office to assess compliance with the EU AI Act.

2. Transparency About Training Data

If your model was trained on copyrighted material, you must provide:

A sufficiently detailed summary of the content used for training

This is the "copyright transparency" clause — it's designed to address concerns about models trained on scraped web data, books, or code repositories without explicit licensing.

3. Cooperation with the AI Office

You must cooperate with the European AI Office and national competent authorities, including:

Responding to requests for information
Providing access to documentation
Participating in audits or assessments

Refusal to cooperate can trigger enforcement action.

4. Adherence to Codes of Practice

The AI Office will publish codes of practice for GPAI providers. These are voluntary frameworks, but:

If you adhere to an approved code of practice, you benefit from a presumption of compliance with Article 53.
If you don't adhere, you must demonstrate compliance through other means.

Codes of practice are expected to cover:

Model evaluation benchmarks
Red-teaming and adversarial testing
Incident reporting
Transparency about model capabilities and limitations

Article 53 vs. High-Risk AI System Requirements

Requirement	Article 53 (GPAI Providers)	Articles 9–15 (High-Risk AI Systems)
Who it applies to	Foundation model providers	Deployers of high-risk AI systems
Documentation scope	Model training, data, architecture	System-level risk management, data governance
Conformity assessment	Self-assessment + AI Office oversight	Third-party assessment (Annex VII systems)
Ongoing obligations	Cooperation with AI Office, code of practice adherence	Monitoring, logging, human oversight, incident reporting
Penalties for non-compliance	Up to €15M or 3% of global turnover	Up to €35M or 7% of global turnover

Key takeaway: If you're a GPAI provider and your model is integrated into a high-risk system, you face both Article 53 obligations (as the model provider) and Articles 9–15 obligations (as the system deployer or in cooperation with the deployer).

What "Systemic Risk" GPAI Models Must Do (Article 53 + Annex XIII)

If your GPAI model meets the systemic risk threshold — defined as models trained with compute exceeding 10²⁵ FLOPs — you face additional obligations under Annex XIII:

Model evaluation (including adversarial testing)
Assessment and mitigation of systemic risks (e.g., misuse for cyberattacks, CBRN threats)
Tracking and reporting of serious incidents
Cybersecurity protections for model weights and infrastructure
Energy efficiency reporting

As of April 2026, this threshold captures models like:

GPT-4
Claude 3 Opus
Gemini Ultra
Llama 3 405B

Smaller models (e.g., Mistral 7B, Llama 3 8B) are subject to Article 53 but not the systemic risk obligations.

Practical Compliance Checklist for Article 53

Here's what you should prepare before August 2, 2026:

Task	Owner	Deadline
Draft technical documentation (architecture, training data, compute)	ML Engineering	Q2 2026
Document copyright compliance for training data	Legal + Data	Q2 2026
Identify applicable code of practice and map adherence	Compliance Lead	Q3 2026
Establish AI Office liaison and incident reporting process	Compliance Lead	Q3 2026
(If systemic risk) Conduct adversarial testing and document results	ML Engineering + Security	Q2 2026
(If systemic risk) Implement model weight access controls	Security	Q2 2026

Example: A Startup Building a Code Generation Model

Scenario: You're building a code completion model (similar to GitHub Copilot) trained on 500B tokens of open-source code from GitHub, Stack Overflow, and public documentation.

Article 53 obligations:

Technical documentation: Document your model architecture (e.g., transformer-based, 7B parameters), training data sources (GitHub repos, Stack Overflow posts), and compute used (e.g., 10²³ FLOPs on 128 A100 GPUs over 14 days).
Copyright transparency: Provide a summary of the repositories used for training. If you scraped GPL-licensed code, document how you comply with the Copyright Directive (e.g., attribution, license compatibility).
Cooperation: Designate a compliance contact who can respond to AI Office requests within 30 days.
Code of practice: Monitor the AI Office's published codes of practice for GPAI models. If one covers code generation models, map your practices to it (e.g., "We red-team for code injection vulnerabilities and document results quarterly").

What you DON'T need to do under Article 53:

Conformity assessment (that's for high-risk systems, not GPAI models)
Logging of user queries (that's an Article 12 obligation for high-risk system deployers)
Human oversight (again, Article 14 for high-risk systems)

However, if a customer deploys your model in a high-risk context (e.g., an AI system that screens job candidates — Annex III.4), they become subject to Articles 9–15, and you may need to provide them with documentation to support their compliance.

Common Mistakes GPAI Providers Make

Mistake 1: Assuming Article 53 Only Applies to "Big Tech"

Reality: Article 53 applies to any GPAI provider placing a model on the EU market, regardless of company size. If you're a startup offering a fine-tuned Llama model via API, you're in scope.

Mistake 2: Confusing GPAI Obligations with High-Risk System Obligations

Reality: Article 53 is about the model. Articles 9–15 are about the system. If you provide a model API, you're subject to Article 53. If you deploy that model in a high-risk use case, you're also subject to Articles 9–15.

Mistake 3: Waiting for the AI Office to Publish Codes of Practice

Reality: Codes of practice may not be finalized until late 2026 or early 2027. You should prepare technical documentation and copyright summaries now, rather than waiting for official guidance.

Mistake 4: Treating Documentation as a One-Time Exercise

Reality: Article 53 requires up-to-date documentation. If you retrain your model, change your training data mix, or discover new limitations, you must update your documentation.

How Vigilia Helps GPAI Providers

If you're a GPAI provider, Vigilia's audit tool can help you:

Map your model to Article 53 requirements: Identify which obligations apply (standard GPAI vs. systemic risk).
Generate a compliance checklist: Article-by-article gap analysis covering Article 53, Annex XIII, and related transparency obligations.
Document your compliance posture: Audit-ready PDF you can share with the AI Office, investors, or enterprise customers.

The audit takes 20 minutes and costs €499 — versus €5,000–€40,000 for a traditional compliance audit.

Generate your Article 53 compliance report →

With 101 days until EU AI Act enforcement, now is the time to document your GPAI model's compliance posture. Article 53 doesn't require third-party certification, but it does require you to have your documentation ready when the AI Office comes knocking.

This article is for informational purposes only and does not constitute legal advice. Consult a qualified EU AI Act attorney for guidance on your specific situation.

Originally published at Vigilia.

EU AI Act Article 9: Risk Management for High-Risk AI Systems

Gregorio von Hildebrand — Wed, 22 Apr 2026 23:14:11 +0000

Article 9 mandates continuous risk management for high-risk AI. Learn what documentation, processes, and testing you need before August 2026 enforcement.

What Article 9 Actually Requires

Article 9 of the EU AI Act establishes the risk management framework that every provider of high-risk AI systems must implement. It's not a one-time checkbox—it's a continuous, documented process that must be in place before you place your system on the market and maintained throughout its lifecycle.

If your AI system falls under Annex III (HR tools, credit scoring, law enforcement, critical infrastructure, education, etc.), Article 9 applies to you. The fines for non-compliance reach €35 million or 6% of global annual turnover, whichever is higher. Enforcement begins August 2, 2026.

Here's what Article 9 demands in plain language:

Establish and document a risk management system that is continuous and iterative
Identify and analyze known and foreseeable risks associated with each high-risk AI system
Estimate and evaluate risks that may emerge when the system is used in accordance with its intended purpose and under conditions of reasonably foreseeable misuse
Adopt suitable risk management measures to address identified risks
Test the system to ensure risk management measures are effective
Update the risk management process throughout the entire lifecycle of the system

The key word is continuous. You can't run a risk assessment in January 2026, file it, and forget it. Article 9 requires ongoing monitoring, testing, and documentation updates as your system evolves.

The Five-Step Risk Management Process

Article 9 doesn't prescribe a specific methodology, but it does outline a clear sequence. Here's how to structure your compliance:

Step 1: Risk Identification

Document every reasonably foreseeable risk associated with your AI system. This includes:

Risks to health and safety
Risks to fundamental rights (privacy, non-discrimination, freedom of expression)
Risks arising from intended use
Risks arising from reasonably foreseeable misuse

Concrete example: If you're deploying an AI-powered recruitment tool, foreseeable risks include discriminatory outcomes based on protected characteristics (gender, age, ethnicity), privacy violations from excessive data collection, and misuse by hiring managers who over-rely on the system without human review.

Step 2: Risk Analysis and Estimation

For each identified risk, estimate:

Severity: What is the magnitude of harm if the risk materializes?
Probability: How likely is this risk to occur?
Affected populations: Who is exposed to this risk?

Document your methodology. If you use a risk matrix (e.g., 5×5 likelihood-impact grid), define your scoring criteria and thresholds.

Step 3: Risk Evaluation

Determine whether each risk is acceptable or requires mitigation. Article 9 requires you to evaluate risks in light of:

The intended purpose of the system
Reasonably foreseeable misuse
The state of the art in risk mitigation

If a risk exceeds your acceptable threshold, you must implement controls.

Step 4: Risk Mitigation

Adopt measures to eliminate or reduce risks to an acceptable level. Article 9 explicitly requires:

Design and development controls: Build safety and fairness into the system architecture
Testing and validation: Demonstrate that controls work as intended
Information to users: Provide clear instructions and warnings (see Article 13)
Human oversight mechanisms: Enable meaningful human intervention (see Article 14)

Document every mitigation measure and map it back to the specific risk(s) it addresses.

Step 5: Continuous Monitoring and Update

Risk management doesn't stop at deployment. Article 9 requires you to:

Monitor the system's performance in production
Update risk assessments when you modify the system or learn of new risks
Maintain records of all risk management activities

This means version-controlled documentation, change logs, and periodic reviews—not a static PDF.

Article 9 Documentation Requirements

The EU AI Act doesn't specify a document template, but Article 11 (technical documentation) and Article 9 together imply you must maintain:

Document	Purpose	Update Frequency
Risk Management Plan	Describes your overall process, methodology, roles, and review cadence	Annually or when process changes
Risk Register	Lists all identified risks with severity, probability, and status	Continuously (living document)
Risk Assessment Report	Detailed analysis of each risk, including evidence and evaluation	Per system version or major change
Mitigation Control Specification	Describes each control, its implementation, and effectiveness testing	Per control; updated when modified
Test and Validation Records	Evidence that mitigations work (test plans, results, pass/fail criteria)	Per test cycle
Monitoring and Incident Log	Production performance data, anomalies, user complaints, near-misses	Continuously (append-only log)

All documentation must be explainable and auditable. If a national authority requests your Article 9 records, you need to produce them within a reasonable timeframe (typically 30 days).

Common Gaps and Anti-Patterns

Most organizations fail Article 9 compliance in predictable ways. Here are the eight most common anti-patterns we detect in Vigilia audits:

One-time risk assessment: Treating risk management as a pre-launch checklist instead of a continuous process
No misuse analysis: Identifying intended-use risks but ignoring foreseeable misuse scenarios
Undocumented methodology: Using subjective risk judgments without defined scoring criteria
No traceability: Listing risks and controls in separate documents with no clear mapping
Missing test evidence: Claiming mitigations are effective without documented validation
No production monitoring: Deploying the system and never checking if risk assumptions hold in the real world
Stale documentation: Risk registers that haven't been updated in 12+ months
No version control: Overwriting old risk assessments instead of maintaining a change history

Each of these gaps can trigger enforcement action. Article 9 compliance is not about having some documentation—it's about having the right documentation, kept current, and demonstrably used to make decisions.

How Article 9 Connects to Other Requirements

Article 9 is the foundation, but it doesn't stand alone. Your risk management system must feed into:

Article 10 (Data Governance): Risk assessment informs what training data you need and how you validate it
Article 13 (Transparency): Identified risks determine what information you must provide to users
Article 14 (Human Oversight): Risk severity dictates the level of human control required
Article 15 (Accuracy, Robustness, Cybersecurity): Risk mitigation drives your technical performance requirements
Article 61 (Post-Market Monitoring): Continuous risk management requires ongoing performance tracking

If your Article 9 process is weak, every downstream obligation becomes harder to satisfy.

Practical Implementation Checklist

Here's a 30-day roadmap to establish Article 9 compliance:

Week 1: Scoping and Methodology

Confirm your system is high-risk (check Annex III)
Define your risk management process (who owns it, review cadence, escalation paths)
Choose a risk assessment methodology (ISO 31000, NIST AI RMF, or custom)
Document your risk scoring criteria (severity scale, probability scale, acceptability thresholds)

Week 2: Risk Identification and Analysis

Conduct a structured risk workshop with engineering, product, legal, and compliance
Identify risks to health, safety, and fundamental rights
Analyze reasonably foreseeable misuse scenarios
Populate your risk register with initial severity and probability estimates

Week 3: Risk Evaluation and Mitigation Planning

Evaluate each risk against your acceptability criteria
Design mitigation controls for unacceptable risks
Map each control to the specific risk(s) it addresses
Define test plans to validate control effectiveness

Week 4: Testing, Documentation, and Monitoring Setup

Execute validation tests for each mitigation control
Document test results and update risk register with residual risk levels
Set up production monitoring (performance metrics, anomaly detection, user feedback channels)
Schedule your first quarterly risk management review

This isn't a one-person job. Article 9 compliance requires cross-functional collaboration and executive sponsorship.

What Happens If You Don't Comply

Non-compliance with Article 9 is classified as a high-severity infringement under Article 71 of the EU AI Act. National market surveillance authorities can:

Require you to take corrective action within a specified timeframe
Restrict or prohibit the placing on the market of your AI system
Withdraw your system from the market
Impose administrative fines up to €35 million or 6% of total worldwide annual turnover

Beyond regulatory penalties, inadequate risk management exposes you to:

Civil liability: If your AI system causes harm and you can't demonstrate reasonable risk management, you may face lawsuits under national product liability laws
Reputational damage: Public disclosure of enforcement actions can destroy customer trust
Procurement exclusion: Many EU public sector buyers will require proof of Article 9 compliance in RFPs

The cost of non-compliance far exceeds the cost of getting it right.

How Vigilia Helps You Meet Article 9 Requirements

Vigilia automates the Article 9 gap analysis that traditionally takes consultants weeks to complete. In 20 minutes, you get:

Risk classification: Determines if your system is high-risk under Annex III
Article 9 compliance score: Evaluates your current risk management process against all Article 9 requirements
Gap analysis: Identifies missing documentation, process weaknesses, and anti-patterns
Remediation roadmap: Prioritized action items with effort estimates and fine exposure calculations
Audit-ready PDF: Exportable report you can share with legal, compliance, or external auditors

Traditional compliance audits cost €5,000–€40,000 and take 1–3 months. Vigilia costs €499 and delivers results in 20 minutes. You get the same article-by-article analysis, documented methodology, and remediation guidance—without the consultant overhead.

August 2, 2026 doesn't move. If you're deploying high-risk AI in the EU, you need Article 9 compliance in place before enforcement begins. The sooner you start, the more time you have to close gaps and validate your controls.

Ready to see where you stand? Generate your EU AI Act compliance report now — €499, 20 minutes, article-by-article gap analysis including Article 9 risk management requirements.

This article provides general information about the EU AI Act and does not constitute legal advice. For specific compliance questions, consult a qualified attorney with expertise in EU AI regulation.

Originally published at Vigilia.