> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aigoframework.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 03 AIGO EU AI Act High Risk AI Mapping v0.1

# AIGO — EU AI Act High-Risk AI Mapping

## 1. Document Purpose

This document provides the AIGO mapping for high-risk artificial intelligence systems under Regulation (EU) 2024/1689, as amended by subsequent Union legislation including Regulation (EU) 2026/1744.

The mapping translates the EU AI Act high-risk framework into AIGO governance mechanisms covering:

* high-risk classification;
* applicability;
* risk management;
* data governance;
* technical documentation;
* record keeping;
* transparency;
* human oversight;
* accuracy;
* robustness;
* cybersecurity;
* quality management;
* provider obligations;
* deployer obligations;
* fundamental-rights impact assessment;
* conformity-related governance;
* registration;
* monitoring;
* incident management;
* change management;
* assurance;
* evidence;
* management review;
* continual improvement; and
* retirement.

This document is an operational governance mapping. It is not a legal opinion, conformity assessment, or declaration of compliance.

The European Commission's current draft high-risk guidance identifies the relevant classification approach and practical examples, while noting that the guidance is non-binding and is being finalized following consultation.

***

## 2. Mapping Information

| Field                    | Value                                          |
| ------------------------ | ---------------------------------------------- |
| Mapping                  | AIGO EU AI Act High-Risk AI Mapping            |
| Version                  | 0.1                                            |
| Status                   | Draft                                          |
| Document Identifier      | `AIGO-MAP-EUAI-003`                            |
| Document Type            | EU AI Act Mapping                              |
| Mapping Package          | `AIGO-MAP-EUAI`                                |
| Primary Legal Instrument | Regulation (EU) 2024/1689                      |
| Amendment Baseline       | Regulation (EU) 2026/1744                      |
| Primary Provisions       | Article 6 and Chapter III, Sections 1–3        |
| Relevant Annexes         | Annex I and Annex III                          |
| Mapping Architecture     | `AIGO-MAP-EUAI-ARCH-001`                       |
| Registry                 | `00-AIGO-EU-AI-Act-Mapping-Registry-v0.1.json` |

The current legal framework distinguishes high-risk AI systems classified under Article 6(1) and Annex I from those classified under Article 6(2) and Annex III. Regulation (EU) 2026/1744 amended Article 113 so that the relevant Chapter III, Sections 1–3 rules apply from 2 December 2027 for Article 6(2)/Annex III systems and from 2 August 2028 for Article 6(1)/Annex I systems.

***

## 3. Legal Source Hierarchy

### 3.1 Binding Source

The authoritative legal source is:

**Regulation (EU) 2024/1689**

as amended, including:

**Regulation (EU) 2026/1744**

The EUR-Lex legal text is controlling.

### 3.2 Official Implementation Material

Supporting material includes:

* European Commission guidance;
* European AI Office guidance;
* official FAQs;
* implementing acts;
* delegated acts;
* harmonised standards;
* common specifications;
* codes of practice.

Official guidelines are implementation support and do not have the same legal status as the Regulation. The Commission's current high-risk guidance is expressly identified as non-binding.

### 3.3 AIGO Mapping

AIGO translates requirements into operational governance structures.

An AIGO control, assessment, or approval does not automatically constitute statutory conformity.

***

## 4. High-Risk Classification Principle

AIGO should determine high-risk status before applying the detailed high-risk control set.

The principal sequence is:

```text theme={null}
AI System
    ↓
Actor
    ↓
Intended Purpose
    ↓
Product / Use-Case Context
    ↓
Article 6(1) Test
    ↓
Article 6(2) / Annex III Test
    ↓
Applicable Exceptions
    ↓
High-Risk Determination
    ↓
Applicable Obligations
```

The classification decision should be documented and evidence-supported.

***

## 5. Two Primary High-Risk Pathways

AIGO should distinguish:

### Path A — Article 6(1) / Annex I

AI systems that are safety components of, or are themselves products, covered by specified Union harmonisation legislation and subject to the relevant conditions.

### Path B — Article 6(2) / Annex III

AI systems used for specified high-risk purposes and falling within the conditions defined in Annex III and the associated provisions.

These are legally distinct classification pathways and must not be merged into a single generic "high-risk" test.

***

## 6. Article 6(1) / Annex I Pathway

The original Article 6(1) provides that an AI system is high-risk where the relevant conditions concerning a product or safety component covered by Annex I are satisfied, including the relevant conformity-assessment relationship.

The current amendment baseline also modified Annex I, including changes to the Union harmonisation legislation listed there.

### AIGO Requirements

The organization should capture:

* product category;
* applicable Union harmonisation legislation;
* product manufacturer relationship;
* AI-system role;
* safety-component relationship;
* conformity pathway;
* relevant notified-body or other assessment considerations;
* deployment context;
* applicable transition date.

***

## 7. Article 6(2) / Annex III Pathway

The Article 6(2) pathway covers specified AI use cases listed in Annex III where the legal classification conditions are satisfied.

AIGO should record:

* Annex III area;
* specific use case;
* intended purpose;
* actor;
* relevant exception;
* classification rationale;
* affected persons;
* risk;
* evidence.

***

## 8. Annex III Areas

The AIGO mapping should maintain the Annex III structure as a controlled taxonomy rather than inventing independent categories.

The major areas include:

1. biometrics;
2. critical infrastructure;
3. education and vocational training;
4. employment, workers management and access to self-employment;
5. access to and enjoyment of essential private services and essential public services and benefits;
6. law enforcement;
7. migration, asylum and border control management;
8. administration of justice and democratic processes.

The actual legal wording and subcategories must be taken from the current consolidated Regulation and maintained in the dedicated Annex mapping.

***

## 9. High-Risk Classification Record

AIGO should maintain a high-risk classification decision containing at minimum:

| Field             | Purpose                                 |
| ----------------- | --------------------------------------- |
| AI System ID      | Identifies the subject                  |
| Actor             | Identifies the legal role               |
| Intended Purpose  | Establishes context                     |
| Article 6 Pathway | Annex I or Annex III                    |
| Annex Reference   | Identifies applicable category          |
| Use Case          | Defines operational context             |
| Classification    | High-risk / Not high-risk / Conditional |
| Exception         | Documents applicable exception          |
| Rationale         | Explains decision                       |
| Evidence          | Supports decision                       |
| Reviewer          | Accountability                          |
| Decision Date     | Timing                                  |
| Review Trigger    | Future reassessment                     |

***

## 10. AIGO Control — High-Risk Classification

**Control Name:** EU AI Act High-Risk Classification

**Objective:**

Ensure that each potentially in-scope AI system is assessed against the current Article 6 and Annex I/III criteria before the organization relies on a non-high-risk classification.

**Owner:**

AI Governance Owner / Classification Owner.

**Frequency:**

* initial registration;
* before approval;
* after material change;
* after intended-purpose change;
* after regulatory change;
* after relevant official guidance.

***

## 11. Classification Evidence

Evidence may include:

* AI system profile;
* intended-purpose document;
* product information;
* technical architecture;
* use-case description;
* deployment context;
* Annex mapping;
* regulatory analysis;
* legal/compliance review;
* classification assessment.

***

## 12. Article 6(3) and Exception Handling

Where the Regulation provides conditions under which certain Annex III systems may not be classified as high-risk, AIGO should document the relevant determination explicitly.

The organization should not simply select "not high-risk" without recording:

* the applicable condition;
* supporting facts;
* evidence;
* reviewer;
* effective date.

The precise legal criteria must be evaluated from the current text.

***

## 13. Classification Uncertainty

Where the evidence is insufficient, AIGO should support:

```text theme={null}
CLASSIFICATION_PENDING
```

rather than forcing:

```text theme={null}
NOT_HIGH_RISK
```

An unresolved high-risk question should receive appropriate governance escalation.

***

## 14. High-Risk Governance Profile

Once an AI system is classified as high-risk, AIGO should automatically or procedurally activate an enhanced governance profile.

Recommended profile:

```text theme={null}
HIGH_RISK
    ↓
Enhanced Risk Management
Enhanced Data Governance
Enhanced Documentation
Enhanced Record Keeping
Enhanced Human Oversight
Enhanced Monitoring
Enhanced Assurance
Enhanced Evidence
Enhanced Change Control
Enhanced Incident Governance
```

***

# 15. Article 9 — Risk Management System

## 15.1 Legal Theme

High-risk AI systems are subject to a risk-management system throughout their lifecycle.

## 15.2 AIGO Mapping

**Relationship:** `DIRECT / CRITICAL`

**AIGO Components:**

* Risk;
* Control;
* Assessment;
* Monitoring;
* Evidence;
* Assurance;
* Improvement.

## 15.3 Operational Model

```text theme={null}
Risk Identification
      ↓
Risk Analysis
      ↓
Risk Estimation
      ↓
Risk Evaluation
      ↓
Risk Treatment
      ↓
Residual Risk
      ↓
Monitoring
      ↓
Reassessment
```

## 15.4 AIGO Control

**High-Risk AI Risk Management Control**

The control should require:

* documented risks;
* affected-person analysis;
* foreseeable misuse;
* reasonably foreseeable misuse;
* risks from intended use;
* mitigation;
* residual risk;
* lifecycle reassessment.

## 15.5 Evidence

* risk assessments;
* risk register;
* treatment records;
* control evidence;
* monitoring;
* reassessment.

***

# 16. Article 10 — Data and Data Governance

## 16.1 Legal Theme

High-risk AI systems are subject to requirements concerning data and data governance for training, validation and testing datasets.

## 16.2 AIGO Mapping

**Relationship:** `DIRECT / CRITICAL`

**AIGO Components:**

* Data Governance;
* Control;
* Assessment;
* Risk;
* Evidence;
* Assurance.

## 16.3 AIGO Controls

Controls should address:

* relevance;
* representativeness;
* quality;
* provenance;
* suitability;
* bias detection and mitigation;
* data governance;
* data preparation;
* testing;
* documentation.

## 16.4 Evidence

Potential evidence includes:

* dataset inventory;
* lineage;
* data-quality records;
* provenance;
* bias assessment;
* preprocessing records;
* validation results.

***

# 17. Article 11 — Technical Documentation

## 17.1 Legal Theme

Providers of high-risk AI systems must prepare technical documentation before placing the system on the market or putting it into service and keep it updated as required.

## 17.2 AIGO Mapping

**Relationship:** `DIRECT`

**AIGO Components:**

* AI System Profile;
* Evidence;
* Change;
* Assurance.

## 17.3 AIGO Control

**High-Risk Technical Documentation Control**

The control should require controlled documentation covering the applicable statutory requirements.

AIGO should support the documentation lifecycle:

```text theme={null}
Create
 ↓
Review
 ↓
Approve
 ↓
Version
 ↓
Update
 ↓
Retain
 ↓
Assure
```

***

# 18. Article 12 — Record-Keeping

## 18.1 Legal Theme

High-risk AI systems must support automatic logging and appropriate record keeping according to the applicable legal requirements.

## 18.2 AIGO Mapping

**Relationship:** `DIRECT`

**AIGO Components:**

* Monitoring;
* Evidence;
* Incident;
* Assurance.

## 18.3 AIGO Control

**High-Risk Logging and Record-Keeping Control**

The control should define:

* required events;
* timestamps;
* retention;
* access;
* integrity;
* traceability;
* review;
* incident linkage.

***

# 19. Article 13 — Transparency and Information for Deployers

## 19.1 Legal Theme

High-risk AI providers must ensure sufficient transparency and provide relevant information and instructions to deployers.

## 19.2 AIGO Mapping

**Relationship:** `DIRECT`

## 19.3 AIGO Controls

Controls should cover:

* intended purpose;
* limitations;
* performance characteristics;
* known risks;
* human oversight;
* operational conditions;
* information to deployers;
* documentation.

## 19.4 Evidence

* instructions;
* technical documentation;
* deployment guidance;
* acceptance records;
* review evidence.

***

# 20. Article 14 — Human Oversight

## 20.1 Legal Theme

High-risk AI systems must be designed and developed in a way that enables appropriate human oversight.

## 20.2 AIGO Mapping

**Relationship:** `DIRECT / CRITICAL`

## 20.3 AIGO Control

**High-Risk Human Oversight Control**

The control should establish:

* oversight role;
* authority;
* competence;
* ability to intervene;
* ability to interrupt or override where required;
* escalation;
* monitoring;
* documented procedures.

## 20.4 Evidence

* oversight assignment;
* competence record;
* intervention procedures;
* override tests;
* monitoring;
* training;
* oversight logs.

***

# 21. Article 15 — Accuracy, Robustness and Cybersecurity

## 21.1 Legal Theme

High-risk AI systems must meet relevant requirements for:

* appropriate levels of accuracy;
* robustness;
* cybersecurity.

## 21.2 AIGO Mapping

**Relationship:** `DIRECT / CRITICAL`

## 21.3 AIGO Control Domains

AIGO should map:

* accuracy controls;
* validation;
* performance monitoring;
* robustness testing;
* adversarial testing;
* cybersecurity;
* resilience;
* failure handling.

## 21.4 Evidence

* validation results;
* testing;
* vulnerability assessments;
* security testing;
* performance records;
* monitoring.

***

# 22. Article 16 — Obligations of Providers

## 22.1 Legal Theme

Providers of high-risk AI systems have a set of organizational and lifecycle obligations.

## 22.2 AIGO Mapping

**Relationship:** `DIRECT`

The obligations should be distributed across:

* Governance;
* AI System;
* Risk;
* Control;
* Assessment;
* Evidence;
* Monitoring;
* Change;
* Assurance.

## 22.3 AIGO Operating Model

```text theme={null}
Provider Governance
      ↓
Quality Management
      ↓
Risk Management
      ↓
Technical Documentation
      ↓
Conformity / Assessment
      ↓
Registration
      ↓
Monitoring
      ↓
Incident / Corrective Action
```

***

# 23. Article 17 — Quality Management System

## 23.1 Legal Theme

Providers of high-risk AI systems must establish a quality-management system meeting the applicable legal requirements.

## 23.2 AIGO Mapping

**Relationship:** `DIRECT / SUPPORTING`

## 23.3 AIGO Implementation

AIGO governance should support a controlled QMS-related structure covering, where applicable:

* strategy;
* procedures;
* design and development;
* testing;
* validation;
* data governance;
* risk;
* technical documentation;
* record keeping;
* incident handling;
* corrective action;
* regulatory communication.

AIGO should not claim to be identical to every statutory QMS requirement.

***

# 24. Article 18 — Documentation Retention

## AIGO Mapping

**Relationship:** `DIRECT`

AIGO Evidence and Document Integrity controls should support retention of relevant documentation for the statutory period where applicable.

Retention rules should distinguish:

* legal retention;
* organizational retention;
* evidence retention;
* technical record retention.

***

# 25. Article 19 — Automatically Generated Logs

## AIGO Mapping

**Relationship:** `DIRECT`

AIGO should establish:

* log requirements;
* retention;
* access;
* integrity;
* event definitions;
* incident linkage;
* monitoring;
* review.

***

# 26. Article 20 — Corrective Action

## AIGO Mapping

**Relationship:** `DIRECT`

Recommended chain:

```text theme={null}
Nonconformity
    ↓
Corrective Action
    ↓
Change
    ↓
Verification
    ↓
Evidence
    ↓
Closure
```

The AIGO Improvement and Change schemas should support this lifecycle.

***

# 27. Article 21 — Cooperation with Authorities

## AIGO Mapping

**Relationship:** `SUPPORTING`

AIGO should support:

* regulatory correspondence;
* evidence preservation;
* authority requests;
* response coordination;
* management escalation.

***

# 28. Article 22 — Representatives of Providers

## AIGO Mapping

Where an authorized representative relationship exists, AIGO should record:

* provider;
* representative;
* authority;
* contractual basis;
* scope;
* communications;
* evidence.

This should be integrated with Third-Party Governance.

***

# 29. Articles 23–25 — Importers and Distributors

## AIGO Mapping

Importers and distributors may have specific responsibilities.

AIGO should support:

* role identification;
* supplier due diligence;
* documentation verification;
* conformity-related records;
* corrective action;
* communication;
* incident escalation.

***

# 30. Article 26 — Deployers

## 30.1 Legal Theme

Deployers have defined obligations for use of high-risk AI.

## 30.2 AIGO Mapping

**Relationship:** `DIRECT`

## 30.3 AIGO Controls

Deployers should have controls for:

* use according to instructions;
* human oversight;
* monitoring;
* record keeping;
* data governance where applicable;
* incident reporting;
* workplace obligations where applicable;
* regulatory communication.

***

# 31. Article 27 — Fundamental Rights Impact Assessment

## 31.1 Legal Theme

Certain deployers must perform a fundamental-rights impact assessment.

## 31.2 AIGO Mapping

**Relationship:** `DIRECT / CONDITIONAL / CRITICAL`

## 31.3 AIGO Assessment

AIGO should support:

```text theme={null}
Identify Affected Persons
       ↓
Identify Rights
       ↓
Assess Impacts
       ↓
Identify Risks
       ↓
Mitigate
       ↓
Residual Impact / Risk
       ↓
Approval
       ↓
Monitoring
       ↓
Evidence
```

## 31.4 Important Distinction

An AIGO general risk assessment does not automatically equal the legally required fundamental-rights impact assessment.

Where Article 27 applies, the mapping should identify the statutory assessment explicitly.

***

# 32. Article 29 — Monitoring by Deployers

## AIGO Mapping

**Relationship:** `DIRECT`

Monitoring should cover:

* system performance;
* use according to instructions;
* risks;
* incidents;
* changes;
* human oversight;
* relevant data quality;
* complaints or affected-person issues.

***

# 33. High-Risk Conformity Architecture

The AIGO framework should support, but not replace:

* conformity assessment;
* declarations;
* quality-management requirements;
* technical documentation;
* registration;
* post-market monitoring.

AIGO artifacts may provide governance evidence supporting those activities.

The statutory conformity process remains distinct.

***

# 34. Annex I — Product-Related High-Risk Systems

## 34.1 AIGO Classification

The Article 6(1)/Annex I determination should evaluate:

1. Is the AI system itself a product or safety component?
2. Is the product within current Annex I legislation?
3. Are the applicable product-law conditions satisfied?
4. Is the system subject to the relevant conformity-assessment pathway?
5. Is the system excluded or otherwise outside the high-risk classification?

## 34.2 Current Legal Baseline

The 2026 amendment modified Annex I and added/changed references to relevant Union harmonisation legislation.

AIGO's Annex I mapping must therefore be maintained against the current legal text rather than relying on an older product list.

***

# 35. Annex III — Stand-Alone High-Risk Systems

AIGO should map each Annex III area to:

* category;
* use case;
* actor;
* intended purpose;
* exception;
* applicable controls;
* assessment;
* evidence;
* monitoring;
* assurance.

The current Commission guidance identifies the sensitive areas covered by Annex III and provides practical examples for classification.

***

# 36. High-Risk Category — Biometrics

Potential Annex III contexts include specified biometric uses.

AIGO should consider:

* biometric modality;
* identification versus verification;
* categorization;
* purpose;
* access;
* affected persons;
* accuracy;
* privacy;
* security;
* human oversight.

The Article 5 prohibited-practice screening must also be completed because some biometric uses may be prohibited rather than merely high-risk.

***

# 37. High-Risk Category — Critical Infrastructure

For applicable critical-infrastructure AI systems, AIGO should consider:

* safety;
* resilience;
* cybersecurity;
* availability;
* continuity;
* incident response;
* monitoring;
* emergency intervention.

Critical infrastructure should normally receive enhanced governance and assurance.

***

# 38. High-Risk Category — Education and Vocational Training

For applicable systems, AIGO should assess:

* learner impact;
* access;
* grading;
* admissions;
* evaluation;
* fairness;
* human oversight;
* transparency;
* affected-person rights.

Article 5 emotion-recognition screening may also be relevant.

***

# 39. High-Risk Category — Employment and Worker Management

AIGO should assess:

* recruitment;
* selection;
* worker evaluation;
* promotion;
* termination;
* allocation of work;
* access to self-employment;
* bias;
* discrimination;
* transparency;
* human oversight.

Article 5 prohibited-practice screening should be completed separately.

***

# 40. High-Risk Category — Essential Services and Benefits

AIGO should evaluate systems affecting:

* access to essential public services;
* essential private services;
* eligibility;
* benefit allocation;
* credit-related or similarly consequential determinations where covered;
* vulnerable persons;
* explanations;
* human review.

Fundamental-rights considerations should be explicit.

***

# 41. High-Risk Category — Law Enforcement

AIGO should consider:

* law-enforcement purpose;
* person-level impact;
* profiling;
* biometric use;
* criminal-offence prediction;
* human oversight;
* evidence;
* authority;
* safeguards.

Article 5 prohibitions must be screened separately.

***

# 42. High-Risk Category — Migration, Asylum and Border Control

AIGO should assess:

* identity;
* eligibility;
* migration status;
* asylum;
* border control;
* vulnerability;
* fundamental rights;
* human oversight;
* transparency;
* data quality;
* record keeping.

***

# 43. High-Risk Category — Administration of Justice and Democratic Processes

AIGO should consider:

* judicial or quasi-judicial decision support;
* access to justice;
* procedural fairness;
* human review;
* explainability;
* independence;
* democratic-process risks;
* manipulation;
* public-interest impact.

High-consequence systems should receive enhanced assurance.

***

# 44. High-Risk Data Governance Control

All applicable high-risk AI systems should maintain a controlled data-governance process.

The control may include:

* data inventory;
* source;
* provenance;
* quality;
* bias;
* representativeness;
* processing;
* testing;
* access;
* retention;
* change management.

***

# 45. High-Risk Documentation Control

The control should ensure that required documentation remains:

* complete;
* current;
* version-controlled;
* approved;
* accessible to authorized parties;
* traceable;
* retained.

The Document Integrity Checker can support structural integrity, while substantive documentation adequacy requires assessment.

***

# 46. High-Risk Logging Control

Logs should support:

* traceability;
* incident investigation;
* monitoring;
* regulatory evidence;
* post-market activity;
* assurance.

Log requirements should be defined according to the applicable system and legal obligations.

***

# 47. High-Risk Human Oversight Control

The oversight control should be linked to:

* risk level;
* system capability;
* operating context;
* decision consequence;
* override;
* intervention;
* competence.

For high-consequence systems, human oversight should be subject to testing and assurance.

***

# 48. High-Risk Accuracy and Robustness Control

The control should define:

* accuracy objectives;
* validation;
* threshold;
* drift monitoring;
* robustness;
* stress testing;
* error handling;
* degradation behavior.

The AIGO Monitoring and Assessment schemas should preserve evidence of these activities.

***

# 49. High-Risk Cybersecurity Control

The cybersecurity control should address, where relevant:

* threat modeling;
* secure development;
* access control;
* authentication;
* integrity;
* resilience;
* adversarial attacks;
* data poisoning;
* model manipulation;
* vulnerability response.

The exact security control framework should remain consistent with the organization's approved security framework.

***

# 50. High-Risk Incident Governance

A high-risk incident should be connected to:

```text theme={null}
AI System
   ↓
Incident
   ↓
Risk
   ↓
Control Failure
   ↓
Corrective Action
   ↓
Change
   ↓
Verification
   ↓
Evidence
   ↓
Assurance
```

Where statutory reporting obligations apply, AIGO should support the reporting workflow without treating internal incident closure as equivalent to regulatory notification.

***

# 51. High-Risk Change Governance

Material changes should trigger review of:

* classification;
* intended purpose;
* data;
* risk;
* controls;
* documentation;
* conformity;
* registration;
* monitoring.

A material change may require re-assessment before deployment.

***

# 52. High-Risk Assurance

Assurance should be proportionate to:

* risk;
* classification;
* impact;
* regulatory significance;
* control criticality;
* incident history;
* change significance.

Possible activities include:

* control assessment;
* technical assessment;
* independent review;
* audit;
* model validation;
* data assessment;
* human-oversight assessment.

***

# 53. High-Risk Evidence Model

Evidence should be organized around the high-risk governance lifecycle.

| Area            | Potential Evidence            |
| --------------- | ----------------------------- |
| Classification  | Classification decision       |
| Risk            | Risk assessment               |
| Data            | Data governance records       |
| Documentation   | Technical documentation       |
| Logging         | Log records                   |
| Transparency    | Information / instructions    |
| Human Oversight | Oversight records             |
| Accuracy        | Test results                  |
| Robustness      | Robustness testing            |
| Cybersecurity   | Security assessment           |
| Approval        | Approval record               |
| Monitoring      | Monitoring results            |
| Incident        | Incident records              |
| Change          | Change records                |
| Assurance       | Assurance report              |
| Conformity      | Applicable conformity records |
| Registration    | Registration evidence         |

***

# 54. High-Risk Evidence Coverage

A high-risk AI system should not be considered fully governance-ready when material evidence gaps remain.

The Evidence Coverage Validator should eventually evaluate:

* required evidence;
* current evidence;
* quality;
* validity;
* integrity;
* review;
* retention.

***

# 55. High-Risk Control Coverage

The Control Coverage Validator should evaluate:

* all applicable mandatory controls;
* critical controls;
* assessments;
* evidence;
* monitoring;
* assurance;
* exceptions;
* compensating controls.

Critical control gaps should normally block high-risk operational approval.

***

# 56. High-Risk Traceability

The minimum chain should be:

```text theme={null}
EU AI Act
   ↓
Article 6 / Annex I / Annex III
   ↓
Applicability
   ↓
AI System
   ↓
Risk
   ↓
Control
   ↓
Assessment
   ↓
Evidence
   ↓
Approval
   ↓
Monitoring
   ↓
Assurance
```

Material changes, incidents, and improvements should branch from this chain.

***

# 57. High-Risk Management Review

Management review should periodically evaluate:

* number of high-risk systems;
* classification decisions;
* control coverage;
* evidence coverage;
* assurance findings;
* incidents;
* regulatory changes;
* upcoming deadlines;
* resource requirements;
* supplier dependencies.

***

# 58. Current Application Timeline

The current legal baseline is:

| High-Risk Pathway        | Current Application Date |
| ------------------------ | ------------------------ |
| Article 6(2) / Annex III | 2 December 2027          |
| Article 6(1) / Annex I   | 2 August 2028            |

This is the current amended position under Regulation (EU) 2026/1744.

The Commission's current high-risk guidance reports the same practical timeline: December 2027 for specified stand-alone high-risk systems and August 2028 for AI embedded in regulated products.

***

# 59. Important Timeline Qualification

Regulation (EU) 2026/1744 includes an implementation mechanism linked to the availability of support measures such as harmonised standards, common specifications, and guidance.

The legal text establishes the revised baseline dates while providing for the application mechanism described in the amended Article 113. AIGO must therefore treat the dates as controlled regulatory data and verify the current legal state before each release.

***

# 60. Transitional Governance

AIGO should maintain separate status for:

```text theme={null}
CURRENTLY_APPLICABLE
FUTURE_APPLICABLE
TRANSITIONAL
HISTORICAL
PENDING_EFFECTIVE_DATE
```

A system can be legally classified as high-risk before the relevant obligations become applicable.

Therefore:

```text theme={null}
Classification Date
```

and:

```text theme={null}
Obligation Application Date
```

must remain separate fields.

***

# 61. Early-Readiness Principle

Even where high-risk obligations are not yet legally applicable to a particular system, AIGO may require early implementation of high-risk governance controls.

For example:

```text theme={null}
Legal obligation:
Future

AIGO governance:
Implement early
```

Such early governance should be labelled as:

```text theme={null}
AIGO_EARLY_READINESS
```

rather than presented as a current statutory deadline.

***

# 62. High-Risk Procurement Gate

Organizations acquiring a potential high-risk AI system should assess:

* classification;
* provider status;
* documentation;
* control evidence;
* cybersecurity;
* human oversight;
* monitoring;
* incident arrangements;
* regulatory applicability.

Procurement should not proceed blindly based on supplier claims alone.

***

# 63. High-Risk Deployment Gate

The deployment gate should require:

1. classification;
2. required assessments;
3. risk treatment;
4. control assessment;
5. evidence;
6. approval;
7. applicable conformity-related readiness;
8. monitoring readiness;
9. human oversight readiness.

***

# 64. High-Risk Continued-Operation Gate

Periodic continued-operation review should consider:

* new risks;
* performance;
* incidents;
* control effectiveness;
* evidence;
* regulatory changes;
* system changes;
* provider changes;
* user/affected-person impacts.

***

# 65. High-Risk Retirement

Retirement should assess:

* regulatory record retention;
* technical documentation;
* historical logs;
* incidents;
* evidence;
* authority obligations;
* supplier obligations;
* post-market obligations;
* residual risks.

Retirement does not automatically eliminate historical compliance obligations.

***

# 66. High-Risk Regulatory Change

A change in EU law or official guidance should trigger:

```text theme={null}
Regulatory Change
      ↓
High-Risk Mapping Review
      ↓
Affected Systems Identification
      ↓
Classification Review
      ↓
Control Impact
      ↓
Evidence Impact
      ↓
Management Review
      ↓
Implementation
```

***

# 67. High-Risk Supplier Governance

Contracts with providers should address, where relevant:

* high-risk classification information;
* technical documentation;
* changes;
* incidents;
* evidence;
* security;
* privacy;
* conformity-related records;
* cooperation;
* termination;
* regulatory communication.

Contract allocation does not necessarily remove statutory obligations from the organization's role.

***

# 68. High-Risk Assurance Triggers

Enhanced assurance should be considered when:

* classification is disputed;
* system is critical;
* fundamental rights impact is material;
* control coverage is incomplete;
* material incident occurred;
* major change occurred;
* evidence is weak;
* regulatory review is expected.

***

# 69. High-Risk Improvement

Improvement activities may address:

* control gaps;
* documentation gaps;
* evidence gaps;
* monitoring weaknesses;
* incident recurrence;
* high-risk classification uncertainty;
* supplier weaknesses;
* assurance findings.

The Improvement Schema should retain the source and effectiveness evidence.

***

# 70. High-Risk Control Matrix

| EU AI Act Area         | AIGO Control Domain      | Primary AIGO Record     |
| ---------------------- | ------------------------ | ----------------------- |
| Classification         | AI Classification        | Assessment              |
| Risk Management        | AI Risk Management       | Risk                    |
| Data Governance        | Data Governance          | Control / Assessment    |
| Documentation          | Technical Documentation  | Evidence                |
| Logging                | Record Keeping           | Monitoring / Evidence   |
| Transparency           | Transparency             | Control / Evidence      |
| Human Oversight        | Human Oversight          | Control / Monitoring    |
| Accuracy               | Performance / Validation | Assessment              |
| Robustness             | Robustness / Resilience  | Assessment              |
| Cybersecurity          | Security                 | Control / Assurance     |
| QMS                    | Governance / Quality     | Governance / Evidence   |
| Provider obligations   | Governance               | Governance              |
| Deployer obligations   | Operations / Governance  | Governance / Monitoring |
| Fundamental Rights     | Impact / Risk            | Assessment              |
| Conformity             | Assessment / Assurance   | Assessment / Assurance  |
| Registration           | Regulatory Registration  | Evidence                |
| Post-Market Monitoring | Monitoring               | Monitoring              |
| Incident Response      | Incident                 | Incident                |
| Corrective Action      | Change / Improvement     | Change / Improvement    |

***

# 71. High-Risk Decision Matrix

| Decision                 | Required Basis                    | Typical Authority             |
| ------------------------ | --------------------------------- | ----------------------------- |
| High-risk classification | Article 6 / Annex analysis        | Classification Owner          |
| High-risk deployment     | Assessments / Controls / Evidence | Approval Authority            |
| Exception                | Legal / Governance basis          | Authorized Authority          |
| Continued operation      | Monitoring / Risk / Assurance     | System / Governance Authority |
| Material change          | Impact / Risk / Classification    | Change Authority              |
| Regulatory response      | Legal / Incident / Evidence       | Authorized Governance Body    |
| Retirement               | Risk / Continuity / Evidence      | Retirement Authority          |

Actual authority should follow the organization's approved AIGO Governance record.

***

# 72. Mapping Status

Potential mapping statuses are:

```text theme={null}
DRAFT
UNDER_REVIEW
MAPPED
PARTIALLY_MAPPED
VALIDATED
APPROVED
SUPERSEDED
RETIRED
```

The current document is:

`DRAFT`

***

# 73. Mapping Confidence

Each substantive high-risk mapping should eventually carry:

```text theme={null}
HIGH
MEDIUM
LOW
PENDING_INTERPRETATION
```

Confidence reflects mapping certainty, not legal certainty.

***

# 74. High-Risk Mapping Findings

Potential findings include:

```text theme={null}
HIGH_RISK_CLASSIFICATION_MISSING
HIGH_RISK_PATHWAY_UNRESOLVED
ANNEX_I_REFERENCE_MISSING
ANNEX_III_REFERENCE_MISSING
RISK_MANAGEMENT_MAPPING_MISSING
DATA_GOVERNANCE_MAPPING_MISSING
DOCUMENTATION_MAPPING_MISSING
RECORD_KEEPING_MAPPING_MISSING
HUMAN_OVERSIGHT_MAPPING_MISSING
ACCURACY_MAPPING_MISSING
ROBUSTNESS_MAPPING_MISSING
CYBERSECURITY_MAPPING_MISSING
PROVIDER_OBLIGATION_GAP
DEPLOYER_OBLIGATION_GAP
FUNDAMENTAL_RIGHTS_ASSESSMENT_GAP
CONFORMITY_MAPPING_GAP
REGISTRATION_MAPPING_GAP
MONITORING_MAPPING_GAP
INCIDENT_MAPPING_GAP
EVIDENCE_MAPPING_GAP
ASSURANCE_MAPPING_GAP
TIMELINE_MAPPING_GAP
```

***

# 75. Validation Requirements

The document should satisfy:

### Legal Source Validation

Article and Annex references resolve to the applicable legal text.

### Classification Validation

Article 6 pathways are distinguishable.

### Annex Validation

Annex I and Annex III mappings are traceable.

### Control Validation

Referenced AIGO controls exist.

### Evidence Validation

Required evidence relationships are represented.

### Traceability Validation

Legal requirement → AIGO governance chain is intact.

### Timeline Validation

Current application dates are used.

### Consistency Validation

High-risk terminology matches the master mapping and architecture.

### Version Validation

Amendment baseline is identified.

***

# 76. Limitations

This mapping cannot independently determine:

* whether a particular AI system legally qualifies as high-risk;
* whether an Annex I product-law pathway applies;
* whether an Annex III exception applies;
* whether a fundamental-rights assessment is legally required in a specific case;
* whether technical documentation satisfies every legal element;
* whether a control is effective;
* whether an organization is legally compliant.

Those determinations require factual analysis, current legal text, technical evidence, and appropriate professional review.

***

# 77. Relationship to Other EU AI Act Mappings

| File                                                             | Relationship                    |
| ---------------------------------------------------------------- | ------------------------------- |
| `01-AIGO-EU-AI-Act-Mapping-v0.1.md`                              | Master mapping                  |
| `02-AIGO-EU-AI-Act-Prohibited-AI-Practices-Mapping-v0.1.md`      | Article 5 screening             |
| `04-AIGO-EU-AI-Act-Transparency-Mapping-v0.1.md`                 | Article 50                      |
| `05-AIGO-EU-AI-Act-GPAI-Mapping-v0.1.md`                         | GPAI                            |
| `07-AIGO-EU-AI-Act-Governance-and-Enforcement-Mapping-v0.1.md`   | Governance                      |
| `08-AIGO-EU-AI-Act-Conformity-and-Documentation-Mapping-v0.1.md` | Conformity                      |
| `09-AIGO-EU-AI-Act-Rights-and-Remedies-Mapping-v0.1.md`          | Fundamental rights and remedies |
| `10-AIGO-EU-AI-Act-Annexes-Mapping-v0.1.md`                      | Detailed Annex mapping          |
| `11-AIGO-EU-AI-Act-Applicability-and-Timeline-v0.1.md`           | Dates and applicability         |
| `12-AIGO-EU-AI-Act-AIGO-Control-Mapping-v0.1.md`                 | Detailed controls               |
| `13-AIGO-EU-AI-Act-Evidence-and-Assurance-Mapping-v0.1.md`       | Evidence and assurance          |

***

# 78. Document Control

| Field                     | Value                                         |
| ------------------------- | --------------------------------------------- |
| Document                  | AIGO EU AI Act High-Risk AI Mapping           |
| Version                   | 0.1                                           |
| Status                    | Draft                                         |
| Document Identifier       | `AIGO-MAP-EUAI-003`                           |
| Document Type             | EU AI Act Mapping                             |
| Primary Legal Source      | Article 6 / Chapter III / Annex I / Annex III |
| Amendment Baseline        | Regulation (EU) 2026/1744                     |
| Owner                     |                                               |
| Legal/Compliance Reviewer |                                               |
| Governance Reviewer       |                                               |
| Framework Architect       |                                               |
| Approved By               |                                               |
| Effective Date            |                                               |
| Next Review Date          |                                               |

***

# 79. Document Status

**Document:** AIGO — EU AI Act High-Risk AI Mapping

**Version:** 0.1

**Status:** Draft

**Working Name:** AIGO

**Full Name:** AI Governance Operating Framework

**Document Identifier:** `AIGO-MAP-EUAI-003`

**Document Type:** EU AI Act Mapping

This document maps the EU AI Act high-risk AI framework to the AIGO AI Governance Operating Framework, including Article 6 classification, Annex I and Annex III pathways, Chapter III requirements, risk management, data governance, documentation, human oversight, accuracy, robustness, cybersecurity, provider and deployer obligations, fundamental-rights assessment, monitoring, evidence, assurance, and lifecycle governance.

End of Document