AIGO — EU AI Act Conformity and Documentation Mapping

1. Document Purpose

This document provides the AIGO mapping for the conformity-assessment, technical-documentation, quality-management, declaration, registration, notified-body, and related documentation requirements of Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744. The mapping translates these requirements into AIGO governance mechanisms covering:

conformity applicability;
conformity-assessment pathway selection;
technical documentation;
quality-management systems;
record keeping;
logs;
declaration of conformity;
CE marking;
notified bodies;
notifying authorities;
EU registration;
post-market documentation;
corrective action;
regulatory evidence;
assurance;
change management;
document integrity;
management review; and
retirement.

The document is an operational governance mapping. It does not constitute a conformity assessment, legal opinion, EU declaration of conformity, notified-body certification, or statement of legal compliance. The AI Act requires technical documentation for applicable high-risk AI systems and provides defined conformity-assessment routes, including internal control and third-party assessment depending on the applicable pathway. Annex IV establishes the minimum technical-documentation information for high-risk AI systems.

2. Mapping Information

Field	Value
Mapping	AIGO EU AI Act Conformity and Documentation Mapping
Version	0.1
Status	Draft
Document Identifier	`AIGO-MAP-EUAI-008`
Document Type	EU AI Act Mapping
Mapping Package	`AIGO-MAP-EUAI`
Primary Legal Instrument	Regulation (EU) 2024/1689
Current Amendment Baseline	Regulation (EU) 2026/1744
Primary Provisions	Articles 11, 16–19, 43–49 and related provisions
Relevant Annexes	Annexes IV, V, VI, VII, VIII, IX
Mapping Architecture	`AIGO-MAP-EUAI-ARCH-001`
Registry	`00-AIGO-EU-AI-Act-Mapping-Registry-v0.1.json`

Regulation (EU) 2026/1744 made targeted changes to Article 43 concerning conformity assessment and notified-body arrangements, including transitional provisions for certain notified bodies already designated under the Union harmonisation legislation listed in Annex I.

3. Source Hierarchy

3.1 Binding Legal Source

The primary source is: Regulation (EU) 2024/1689 as amended by applicable subsequent Union legislation, including: Regulation (EU) 2026/1744. The current EUR-Lex legal text is authoritative.

3.2 Official Implementation Material

Supporting sources include:

European Commission guidance;
European AI Office guidance;
official FAQs;
implementing acts;
delegated acts;
harmonised standards;
common specifications;
notified-body information;
Commission implementation material.

Official guidance is supporting material and does not have the same legal status as the Regulation.

3.3 AIGO Mapping

AIGO translates the legal requirements into organizational governance mechanisms. AIGO controls, assessments, approvals, and assurance activities are not automatically statutory conformity procedures.

4. Conformity Governance Principle

Conformity governance should follow:

AI System
    ↓
Regulatory Applicability
    ↓
High-Risk Classification
    ↓
Applicable Legal Requirements
    ↓
Conformity Pathway
    ↓
Quality Management
    ↓
Technical Documentation
    ↓
Risk / Control Assessment
    ↓
Conformity Assessment
    ↓
Declaration / Registration where applicable
    ↓
Market Placement / Putting into Service
    ↓
Post-Market Monitoring
    ↓
Corrective Action
    ↓
Evidence / Assurance

AIGO should make the boundary between internal governance and statutory conformity explicit.

5. Conformity Applicability

Before establishing a conformity workflow, AIGO should determine:

whether the AI system is high-risk;
whether Article 6(1) or Article 6(2) applies;
whether an applicable product-law pathway exists;
whether a third-party conformity assessment is required;
whether internal control is permitted;
whether notified-body involvement is required;
whether an exemption or special pathway applies;
whether transition provisions apply.

The conformity pathway must be derived from the current legal requirements.

6. Conformity Decision Record

AIGO should maintain a controlled conformity applicability assessment containing:

Field	Purpose
AI System ID	Identifies system
Provider	Identifies provider
Legal Role	Establishes responsibility
High-Risk Pathway	Annex I / Annex III
Applicable Requirements	Identifies obligations
Conformity Procedure	Identifies applicable route
Third-Party Required	Yes / No / Conditional
Notified Body	Where applicable
Applicable Product Law	Where relevant
Exemption	Where applicable
Evidence	Supporting material
Decision	Outcome
Reviewer	Accountability
Review Date	Currency

7. AIGO Conformity Control

Control Name: AI Act Conformity Assessment Governance Objective: Ensure that applicable conformity-assessment requirements are identified, assigned, documented, completed, evidenced, and maintained through the AI system lifecycle. Control Owner: AI Governance Owner / Compliance Owner / AI System Owner. Frequency:

before applicable market placement or putting into service;
after material change;
when legal requirements change;
when conformity-assessment conditions change;
during post-market obligations.

8. Relationship Between AIGO Assurance and Conformity Assessment

AIGO shall maintain a strict distinction:

AIGO Assurance
        ≠
Statutory Conformity Assessment

AIGO assurance may evaluate:

readiness;
control design;
control implementation;
evidence;
documentation;
risk management;
monitoring.

A statutory conformity assessment establishes conformity according to the applicable legal procedure. AIGO may support the statutory process without substituting for it.

9. Article 11 — Technical Documentation

9.1 Legal Theme

Providers of high-risk AI systems must draw up and maintain the technical documentation required by Article 11 and Annex IV. The documentation must allow authorities and, where relevant, notified bodies to assess compliance with the applicable requirements. The Regulation requires at least the information specified in Annex IV.

9.2 AIGO Mapping

Relationship: DIRECT / CRITICAL AIGO Components:

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

10. Technical Documentation Control

Control Name: High-Risk AI Technical Documentation The control should ensure that applicable technical documentation:

exists;
is complete;
is current;
is version-controlled;
is internally consistent;
is traceable;
is retained;
can be provided to authorized authorities or notified bodies where required.

11. Technical Documentation — General System Description

Annex IV requires a general description including, as applicable:

intended purpose;
provider name;
system version;
relationship to previous versions;
interaction with hardware and software;
relevant software or firmware versions;
update requirements;
forms of market placement or putting into service;
intended hardware environment;
product-component information.

AIGO Mapping

These elements should map to:

AI System Profile;
Change Management;
Evidence;
Configuration Management.

12. Technical Documentation — Intended Purpose

The intended purpose should be:

explicitly defined;
approved;
version-controlled;
linked to classification;
linked to risk;
linked to controls;
reassessed after material change.

A change in intended purpose should trigger conformity-impact assessment.

13. Technical Documentation — System Version

AIGO should preserve:

Model Version
System Version
Software Version
Firmware Version
Configuration Version
Documentation Version

These version concepts should remain distinguishable. The Document Integrity Checker and Framework Consistency Checker should identify conflicting versions.

14. Technical Documentation — System Interfaces

Documentation should describe relevant interactions with:

software;
hardware;
APIs;
external systems;
other AI systems;
data services;
identity systems;
monitoring platforms.

The purpose is to make the operational architecture sufficiently traceable for the applicable assessment.

15. Technical Documentation — Lifecycle Versions

The documentation should preserve relationships among:

Original Version
        ↓
Modified Version
        ↓
Material Change
        ↓
Reassessment
        ↓
Updated Documentation

A system should not undergo material modification while retaining obsolete conformity documentation without appropriate reassessment.

16. Technical Documentation — Design and Development

Where applicable, the technical documentation should capture:

design specifications;
architecture;
computational methods;
model structure;
development process;
data requirements;
testing;
validation;
verification;
performance;
limitations.

AIGO should link these materials to the AI System, Assessment, Evidence, and Change records.

17. Technical Documentation — Data

Documentation should include relevant information about:

training data;
validation data;
testing data;
data governance;
data provenance;
data preparation;
quality;
bias;
representativeness;
data-processing choices.

The High-Risk mapping and AIGO Data Governance controls remain authoritative for detailed data requirements.

18. Technical Documentation — Risk Management

Technical documentation should remain traceable to the applicable risk-management process. Recommended chain:

Technical Documentation
        ↓
Risk Identification
        ↓
Risk Analysis
        ↓
Risk Treatment
        ↓
Control
        ↓
Evidence

This prevents technical documentation from becoming disconnected from the risk-management system.

19. Technical Documentation — Testing and Validation

The documentation should preserve applicable:

test plans;
test datasets;
validation methods;
acceptance criteria;
test results;
known failures;
remediation;
retesting.

The evidence should remain linked to the relevant system version.

20. Technical Documentation — Accuracy

Where accuracy requirements apply, documentation should identify:

accuracy objectives;
performance measures;
measurement methods;
validation results;
limitations;
monitoring;
changes.

21. Technical Documentation — Robustness

Documentation should address applicable:

robustness requirements;
expected failure modes;
stress tests;
resilience;
failure handling;
degradation behavior.

22. Technical Documentation — Cybersecurity

Documentation should address relevant cybersecurity measures, including:

threat model;
security architecture;
vulnerabilities;
protective controls;
testing;
incident response;
updates.

This should align with the organization’s cybersecurity framework.

23. Technical Documentation — Human Oversight

Where applicable, documentation should describe:

human oversight arrangements;
roles;
intervention;
override;
limitations;
escalation;
competence requirements.

This should link to the AIGO Human Oversight control.

24. Technical Documentation — Logging

Documentation should identify:

what is logged;
how logging operates;
applicable retention;
integrity measures;
access controls;
review mechanisms.

Logs should connect to evidence and monitoring.

25. Article 12 — Record-Keeping

25.1 AIGO Mapping

Relationship: DIRECT AIGO should provide: High-Risk Record-Keeping Control The control should manage:

automatic logs where required;
records;
access;
retention;
integrity;
traceability;
incident linkage.

26. Record-Keeping Evidence

AIGO should retain evidence showing:

logging was enabled;
logs were produced;
log configuration;
changes;
access;
retention;
relevant incidents.

The existence of a logging configuration alone is not the same as evidence that logging actually operated.

27. Article 16 — Provider Documentation and Compliance Responsibilities

Provider obligations should be distributed across the AIGO lifecycle. Recommended chain:

Provider Governance
      ↓
Quality Management
      ↓
Risk Management
      ↓
Technical Documentation
      ↓
Conformity Assessment
      ↓
Registration
      ↓
Market Placement
      ↓
Monitoring
      ↓
Corrective Action

28. Article 17 — Quality Management System

28.1 Legal Theme

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

28.2 AIGO Mapping

Relationship: DIRECT / SUPPORTING AIGO may provide governance structures supporting the QMS through:

policies;
procedures;
roles;
design controls;
testing;
risk management;
documentation;
records;
corrective action;
monitoring;
supplier management.

AIGO should not claim that its governance framework automatically constitutes a statutory QMS.

29. QMS Documentation

The QMS should be represented through controlled records where required. Potential evidence:

policy;
procedures;
responsibilities;
change management;
testing;
data governance;
risk management;
corrective action;
record keeping;
internal review.

30. QMS and Existing Management Systems

Where an organization already maintains:

quality management;
information security;
privacy management;
safety management;
product compliance;

AIGO should support integrated governance rather than unnecessary parallel processes. The organization should identify:

Existing Management System
        ↓
AI Act Requirement
        ↓
Existing Control
        ↓
AIGO Mapping

This can reduce duplicated controls and evidence.

31. Article 18 — Documentation Retention

AIGO should map retention obligations to the Evidence and Document Integrity frameworks. Retention controls should capture:

artifact;
legal basis;
retention period;
start event;
repository;
access;
disposition;
legal hold.

The organization should not assume that one generic retention period applies to all conformity artifacts.

32. Article 19 — Automatically Generated Logs

AIGO should integrate logs with:

Monitoring;
Evidence;
Incident;
Assurance.

The governance chain should be:

Required Log
    ↓
System Configuration
    ↓
Operational Log
    ↓
Retention
    ↓
Monitoring
    ↓
Evidence

33. Articles 20–22 — Corrective Action and Cooperation

Where conformity or market-surveillance findings identify non-compliance, AIGO should provide:

corrective action;
change;
verification;
evidence;
regulatory communication.

The AIGO Change and Improvement schemas should remain linked.

34. Article 43 — Conformity Assessment

34.1 Legal Theme

Article 43 establishes conformity-assessment procedures for high-risk AI systems. The applicable procedure depends on the relevant high-risk pathway and legal conditions. The AI Act includes internal-control and third-party-assessment routes through Annexes VI and VII, with specific rules depending on the system and applicable Union harmonisation legislation.

34.2 AIGO Mapping

Relationship: DIRECT / CRITICAL

35. Conformity Pathway Decision

AIGO should establish a formal determination of:

Applicable High-Risk Pathway
        ↓
Applicable Conformity Procedure
        ↓
Internal Control Permitted?
        ↓
Notified Body Required?
        ↓
Applicable Product Legislation
        ↓
Assessment Scope
        ↓
Required Evidence

This determination should be reviewed by qualified legal/compliance and conformity personnel.

36. Internal Control Route

Where the applicable legal pathway permits conformity assessment based on internal control, AIGO may support the organizational process through:

quality management;
risk management;
technical documentation;
control assessment;
evidence;
internal review;
corrective action.

The internal AIGO assessment should not be labelled a statutory conformity assessment unless it actually is one under the applicable legal procedure.

37. Third-Party Conformity Assessment

Where a notified body is required, the AIGO governance model should support:

notified-body selection;
scope verification;
contract;
assessment preparation;
evidence package;
correspondence;
findings;
corrective actions;
certificate;
surveillance;
re-assessment.

38. Notified Body Governance

AIGO should maintain a controlled notified-body record containing:

organization name;
notification status;
scope;
applicable product / AI system categories;
notification authority;
assessment scope;
certificate;
validity;
surveillance;
communications.

The organization should independently verify current notified-body status before relying on it.

39. Notifying Authority Relationship

The notifying authority supervises notified bodies. AIGO should distinguish:

Notifying Authority
        ↓
Notified Body
        ↓
Conformity Assessment

from:

AIGO Assurance

The two functions have different legal roles.

40. Article 43 Amendment Baseline

Regulation (EU) 2026/1744 made targeted changes to Article 43. The amendment:

corrects the relationship between conformity-assessment requirements and provider obligations;
clarifies interaction with Union harmonisation legislation;
permits specified notified bodies already notified under relevant product legislation to conduct certain AI conformity assessments during an 18-month transitional period beginning 27 July 2026, without prejudice to the general notification regime under Article 28.

AIGO must therefore treat notified-body eligibility as current, controlled regulatory data.

41. Notified-Body Transition Control

For Article 6(1)/Annex I systems, AIGO should capture:

notified-body legal basis;
existing product-law notification;
AI Act notification status;
transitional authority where applicable;
assessment scope;
transition expiry;
current verification source.

A notified body should not be treated as eligible merely because it was historically notified under another EU framework.

42. Article 44 — Certificates

Where a conformity certificate is issued under the applicable procedure, AIGO should record:

certificate identifier;
notified body;
system;
scope;
issue date;
expiry date where applicable;
version;
conditions;
surveillance;
related documentation.

The AI Act requires certificates issued under Annex VII to be drawn up in a language understandable to the relevant authorities in the Member State where the notified body is established.

43. Certificate Integrity

Certificates should be treated as controlled evidence. AIGO should verify:

source;
issuer;
validity;
scope;
system identity;
version;
relationship to technical documentation.

A certificate should not be assumed to cover a later system version unless the applicable conformity process establishes that coverage.

44. Certificate Change Management

Changes should trigger review of certificate status where they affect:

system version;
intended purpose;
architecture;
conformity scope;
product;
applicable legal requirements.

The organization should not continue relying on obsolete certificates without assessment.

45. Article 45 — Changes to High-Risk Systems

AIGO should link material changes to:

conformity reassessment;
documentation update;
risk reassessment;
control assessment;
certificate impact;
declaration impact;
registration impact.

Recommended chain:

Change
   ↓
Conformity Impact Assessment
   ↓
Documentation Update
   ↓
Reassessment
   ↓
Approval

For certain Article 6(1) systems, conformity assessment interacts with the relevant Union harmonisation legislation. AIGO should therefore retain:

product regulation;
applicable conformity module;
AI Act relationship;
notified body;
assessment record;
certificate;
declaration.

47. Article 47 — EU Declaration of Conformity

47.1 AIGO Mapping

Relationship: DIRECT / CRITICAL Where required, the organization should maintain the EU declaration of conformity as a distinct legal artifact. AIGO should provide:

document control;
version;
approval;
evidence;
applicable legal references;
change linkage;
retention.

AIGO Approval is not the EU declaration of conformity.

48. Declaration of Conformity Control

Control Name: EU Declaration of Conformity Governance The control should ensure:

correct declaration exists where required;
responsible signer is identified;
applicable system is identified;
applicable legislation is identified;
version is current;
declaration is retained;
changes trigger review.

49. Declaration Evidence

Potential evidence includes:

signed declaration;
version;
legal references;
product/system identifier;
authorized signatory;
date;
supporting conformity records.

50. Article 48 — CE Marking

Where applicable, CE marking should be managed as a distinct regulatory artifact and product-compliance activity. AIGO should maintain:

applicability;
marking design;
product/system version;
declaration relationship;
assessment basis;
evidence.

AIGO should not treat an internal governance approval as a CE-mark authorization.

51. Article 49 — Registration

Where registration requirements apply, AIGO should connect:

AI System
   ↓
Registration Applicability
   ↓
Registration
   ↓
Registration Identifier
   ↓
Evidence
   ↓
Change

The internal AIGO AI System Registry is not automatically equivalent to an EU database registration.

52. EU Database Registration Control

Control Name: AI Act Registration Governance The control should manage:

registration applicability;
responsible owner;
submission;
registration identifier;
update triggers;
evidence;
regulatory communication.

53. Registration Change Management

Changes may require registration updates. AIGO should identify:

system change;
legal change;
provider change;
intended-purpose change;
registration impact;
update requirement.

54. Annex IV — Technical Documentation Architecture

AIGO should use Annex IV as the primary technical-documentation baseline for applicable high-risk AI systems. The documentation architecture should cover, as applicable:

General System Description
        ↓
Detailed System Elements
        ↓
Development Process
        ↓
Data
        ↓
Algorithms / Models
        ↓
Computational Resources
        ↓
Testing
        ↓
Risk Management
        ↓
Human Oversight
        ↓
Performance
        ↓
Cybersecurity
        ↓
Post-Market Monitoring
        ↓
Change History

The exact legally required contents remain those established by Annex IV.

55. AIGO Technical Documentation Profile

The AI System Profile should provide the operational foundation for technical documentation, while preserving the distinction between:

AIGO AI System Profile

and:

Statutory Technical Documentation

The former may support the latter but should not automatically be treated as complete Annex IV documentation.

56. Technical Documentation and Evidence

Every material technical-documentation component should have:

owner;
version;
source;
review;
applicability;
evidence;
change history.

Where external documents are referenced, the reference should resolve and remain current.

57. Technical Documentation and Change

The Change Management process should automatically identify documentation impacts. Potential triggers:

new model;
model update;
architecture change;
training-data change;
hardware change;
API change;
intended-purpose change;
new deployment context;
security change;
human-oversight change.

58. Technical Documentation and Assurance

Assurance may assess:

completeness;
consistency;
version alignment;
evidence;
risk linkage;
change history.

Assurance should not issue a statutory certificate unless the organization is legally empowered and the activity is actually the applicable formal assessment.

59. Simplified Documentation for SMEs

The AI Act provides for simplified technical documentation for eligible SMEs, including start-ups, through a Commission-established form where the applicable requirements are met. AIGO should record:

SME status;
eligibility;
use of simplified documentation;
applicable form;
approval;
evidence.

The existence of a simplified form does not remove the underlying legal requirements.

60. Technical Documentation and Document Integrity

The AIGO Document Integrity Checker should verify:

file exists;
version;
integrity;
references;
completeness of required sections;
controlled status.

The substantive legal adequacy of technical documentation requires human review.

61. Technical Documentation and Framework Consistency

The Framework Consistency Checker should verify:

system identifier;
version;
intended purpose;
provider;
classification;
applicable controls;
related assessments;
registration;
declaration;
certificate.

Conflicting values across documents should be investigated.

62. Technical Documentation and Evidence Coverage

The Evidence Coverage Validator should identify required documentation components that are absent or stale. Examples:

Technical Documentation
      ↓
Required Evidence
      ↓
Evidence Record
      ↓
Current?
      ↓
Yes / No

63. Quality Management and Document Control

The QMS should ensure that documentation changes are:

authorized;
reviewed;
approved;
versioned;
distributed appropriately;
retained;
traceable.

The AIGO Change and Document Integrity frameworks should support these activities.

64. Regulatory Evidence Pack

For applicable high-risk systems, organizations should be able to assemble a controlled evidence package containing, as relevant:

Classification
Risk Assessment
Controls
Technical Documentation
Testing
Validation
Quality Management
Human Oversight
Logs
Monitoring
Certificates
Declaration
Registration
Incidents
Corrective Actions
Assurance

The package should be generated from authoritative records where possible.

65. Evidence-Pack Integrity

The evidence pack should include:

system version;
evidence date;
source identifiers;
checksums where required;
repository references;
review status.

This supports reproducibility.

66. Market-Placement Readiness

Before placing an applicable high-risk AI system on the market or putting it into service, AIGO should evaluate:

classification;
risk management;
documentation;
QMS;
conformity assessment;
declaration;
CE marking where applicable;
registration where applicable;
monitoring;
human oversight;
evidence.

67. Putting-Into-Service Gate

A controlled deployment gate may be:

High-Risk Classification
        ↓
Requirements Identified
        ↓
Controls Implemented
        ↓
Technical Documentation Complete
        ↓
Conformity Assessment Complete
        ↓
Declaration / Registration Complete
        ↓
Monitoring Ready
        ↓
Approval
        ↓
Putting Into Service

The exact legal sequence depends on the applicable conformity pathway.

68. Post-Market Documentation

AIGO should retain relevant:

monitoring records;
incidents;
corrective actions;
changes;
complaints;
authority interactions;
performance evidence;
surveillance findings.

These records should remain linked to the system and relevant versions.

69. Corrective Action Documentation

When a non-conformity is found:

Non-Conformity
   ↓
Correction
   ↓
Corrective Action
   ↓
Conformity Impact
   ↓
Testing
   ↓
Verification
   ↓
Documentation Update
   ↓
Evidence

70. Conformity and Incident Management

A serious incident may require:

regulatory reporting;
corrective action;
documentation update;
conformity reassessment;
monitoring changes;
risk reassessment.

The Incident Schema should link these records.

71. Conformity and Change Management

Material change should trigger:

legal applicability assessment;
risk assessment;
documentation update;
conformity-impact analysis;
certificate review;
declaration review;
registration review.

72. Conformity and Assurance

AIGO assurance should determine whether the organization is prepared to undergo the applicable conformity process. Possible assurance outputs:

readiness;
gap;
evidence sufficiency;
documentation consistency;
control coverage;
unresolved issue.

It should not be labelled a statutory conformity certificate.

73. Conformity and Management Review

Management review may consider:

conformity readiness;
open assessment findings;
certificate status;
notified-body relationship;
regulatory deadlines;
documentation gaps;
incidents;
post-market findings;
corrective actions.

74. Conformity and Retirement

Retirement should consider:

certificate history;
declarations;
registration;
technical documentation;
logs;
incidents;
authority communications;
retention requirements.

Retirement does not automatically justify destruction of conformity records.

75. Notified-Body Evidence

Where a notified body is involved, evidence should include:

body identity;
notification scope;
assessment agreement;
assessment reports;
findings;
responses;
certificate;
surveillance;
correspondence.

76. Notified-Body Change Management

The organization should reassess notified-body status when:

legal scope changes;
notification changes;
the body loses scope;
certificates change;
new AI-system categories become applicable;
transition provisions expire.

77. Conformity Timeline Governance

The current amendment baseline changed the implementation timetable for high-risk obligations. The Commission currently states that specified Annex III high-risk systems become subject to the strict high-risk obligations from 2 December 2027, while AI systems embedded in regulated products under the Annex I pathway are subject to those obligations from 2 August 2028. The dedicated timeline document is authoritative: 11-AIGO-EU-AI-Act-Applicability-and-Timeline-v0.1.md

78. Current Conformity Readiness Principle

AIGO should distinguish:

Legally Applicable

from:

AIGO Early Readiness

Organizations may implement conformity controls before their statutory application date. Early-readiness measures should not be represented as evidence that the legal obligations already applied.

79. Conformity and Digital Omnibus

Regulation (EU) 2026/1744 should be incorporated into the AIGO conformity baseline. It changed, among other matters:

Article 43 conformity-assessment provisions;
notified-body transition arrangements;
interaction with Union harmonisation legislation;
QMS relationship;
implementation timing.

80. Current Legal-Source Rule

Before approving a conformity mapping release, AIGO should verify:

current EUR-Lex consolidated text;
amendments;
applicable implementing acts;
delegated acts;
current Commission guidance;
current notified-body information;
relevant standards and common specifications.

The legal source should be recorded with a verification date.

81. Conformity Mapping Control Matrix

Requirement Area	AIGO Control	Primary Record
Applicability	Conformity Applicability Control	Assessment
High-Risk Classification	High-Risk Classification Control	Assessment
Technical Documentation	Technical Documentation Control	Evidence
Quality Management	QMS Governance Control	Governance / Evidence
Record Keeping	Record-Keeping Control	Evidence
Logging	High-Risk Logging Control	Monitoring / Evidence
Conformity Assessment	Conformity Assessment Governance	Assessment / Assurance
Notified Body	Notified-Body Governance	Evidence
Certificate	Certificate Control	Evidence
Declaration	Declaration of Conformity Governance	Evidence
CE Marking	CE Marking Governance	Evidence
Registration	Registration Control	Evidence
Corrective Action	Corrective Action Control	Change / Improvement
Post-Market	Post-Market Monitoring	Monitoring
Regulatory Interaction	Regulatory Submission Control	Evidence
Document Integrity	Controlled Documentation Integrity	Document Integrity

82. Technical Documentation Traceability

The minimum traceability chain is:

EU AI Act Requirement
        ↓
High-Risk AI System
        ↓
Technical Documentation Requirement
        ↓
Document Component
        ↓
Evidence
        ↓
Assessment
        ↓
Conformity
        ↓
Monitoring

83. Conformity Traceability

The preferred chain is:

Legal Requirement
        ↓
Applicability
        ↓
High-Risk Classification
        ↓
Conformity Pathway
        ↓
Assessment
        ↓
Evidence
        ↓
Certificate / Declaration where applicable
        ↓
Registration where applicable
        ↓
Market Placement / Putting Into Service
        ↓
Post-Market Monitoring

84. Conformity Findings

Potential AIGO findings include:

CONFORMITY_APPLICABILITY_UNRESOLVED
CONFORMITY_PATHWAY_UNRESOLVED
TECHNICAL_DOCUMENTATION_MISSING
TECHNICAL_DOCUMENTATION_OUTDATED
TECHNICAL_DOCUMENTATION_INCONSISTENT
QMS_DOCUMENTATION_GAP
RECORD_KEEPING_GAP
LOGGING_REQUIREMENT_UNRESOLVED
CONFORMITY_ASSESSMENT_MISSING
NOTIFIED_BODY_STATUS_UNVERIFIED
CERTIFICATE_MISSING
CERTIFICATE_SCOPE_MISMATCH
DECLARATION_MISSING
DECLARATION_OUTDATED
CE_MARKING_APPLICABILITY_UNRESOLVED
REGISTRATION_MISSING
CORRECTIVE_ACTION_GAP
CONFORMITY_EVIDENCE_GAP
CONFORMITY_ASSURANCE_GAP
CONFORMITY_TIMELINE_GAP

85. Critical Conformity Findings

Potential critical findings include:

applicable conformity procedure not determined;
required third-party assessment not performed;
technical documentation materially absent;
required declaration absent;
required certificate absent;
certificate does not cover the system;
notified-body eligibility not established;
required registration absent;
material system change without conformity-impact analysis.

86. Evidence Requirements

A conformity evidence set may contain:

Applicability Assessment
High-Risk Classification
Risk Management Records
Technical Documentation
QMS Records
Testing
Validation
Human Oversight
Cybersecurity
Logs
Control Assessments
Conformity Assessment
Certificate
Declaration
CE Marking Evidence
Registration
Post-Market Monitoring
Corrective Actions
Authority Communications
Assurance

The exact set depends on the legal pathway.

87. Evidence Quality

Conformity evidence should be:

attributable;
current;
version-specific;
traceable;
complete;
protected;
reviewable.

Evidence generated for a different system version should not be silently reused.

88. Document Integrity

The Document Integrity Checker should verify:

file existence;
readability;
version;
status;
integrity;
links;
document control;
metadata.

89. Framework Consistency

The Framework Consistency Checker should verify consistency among:

AI System Profile;
classification;
technical documentation;
risk;
QMS;
certificate;
declaration;
registration;
monitoring;
changes.

90. Control Coverage

The Control Coverage Validator should determine whether required conformity-supporting controls exist. A control being present does not prove statutory conformity.

91. Evidence Coverage

The Evidence Coverage Validator should identify missing or stale conformity evidence. A missing evidence record means the governance system cannot demonstrate the activity through the repository; it does not by itself prove that the activity never occurred.

92. Assurance Coverage

The Assurance framework should identify which conformity-supporting activities have been independently or objectively reviewed. Assurance should not be presented as a statutory notified-body assessment unless it legally is one.

93. Management Review

Management review should receive:

conformity status;
open gaps;
certificates;
declarations;
notified-body issues;
regulatory changes;
incidents;
corrective actions;
evidence gaps.

94. Regulatory Change Management

Conformity requirements should be reviewed after:

amendments;
implementing acts;
delegated acts;
changes in harmonised standards;
changes in common specifications;
new Commission guidance;
notified-body changes;
sectoral-law changes.

95. Continuous Improvement

Conformity governance improvements may include:

better documentation;
better version control;
improved evidence;
better assessment planning;
improved notified-body management;
improved QMS;
stronger change controls;
stronger post-market monitoring.

96. Relationship to High-Risk Mapping

This document depends on: 03-AIGO-EU-AI-Act-High-Risk-AI-Mapping-v0.1.md The high-risk mapping determines the relevant classification pathway. This document then determines the conformity and documentation implications of that pathway.

97. Relationship to Governance and Enforcement

This document depends on: 07-AIGO-EU-AI-Act-Governance-and-Enforcement-Mapping-v0.1.md Regulatory authorities and enforcement relationships should be managed through the governance and enforcement layer.

98. Relationship to Evidence and Assurance

This document feeds: 13-AIGO-EU-AI-Act-Evidence-and-Assurance-Mapping-v0.1.md The detailed evidence and assurance mapping should determine how conformity evidence is preserved and tested.

99. Relationship to Annex Mapping

Detailed Annex I and Annex IV–IX relationships should be maintained in: 10-AIGO-EU-AI-Act-Annexes-Mapping-v0.1.md This document provides the operational conformity architecture and should not duplicate the full annex text.

100. Relationship to AIGO Schemas

Conformity Activity	AIGO Schema
AI System	AI System
Classification	Assessment
Risk	Risk
Control	Control
Conformity assessment	Assessment / Assurance
Approval	Approval
Monitoring	Monitoring
Incident	Incident
Change	Change
Certificate / Declaration	Evidence
Regulatory interaction	Evidence / Governance
Assurance	Assurance
Management review	Management Review
Improvement	Improvement
Retirement	Retirement
Organizational authority	Governance

No dedicated Conformity Schema is required at this stage.

101. Relationship to AIGO Templates

Relevant existing templates include:

AI System Profile;
AI Classification;
AI Risk Assessment;
AI Control Assessment;
AI Approval;
AI Monitoring;
AI Incident;
AI Change Management;
AI Assurance;
AI Management Review;
AI Evidence Record;
AI Retirement.

A dedicated conformity-assessment template may be introduced later if operational use requires one.

102. Relationship to AIGO Tools

The mapping should be supported by:

Schema Validator;
Reference Validator;
Traceability Validator;
Control Coverage Validator;
Evidence Coverage Validator;
Framework Consistency Checker;
Document Integrity Checker;
Repository Health Checker.

103. Validation Requirements

The mapping should satisfy:

Legal Source Validation

Articles, Annexes, and amendment references resolve.

Classification Validation

The applicable high-risk pathway is identifiable.

Conformity Path Validation

The applicable procedure is documented.

Documentation Validation

Required documentation components are identified.

Evidence Validation

Supporting evidence is defined.

Notified-Body Validation

Where relevant, current eligibility and scope are verified.

Certificate Validation

Certificate scope and system version are aligned.

Declaration Validation

Declaration is present where required and current.

Registration Validation

Registration obligations are assessed.

Timeline Validation

Application dates and transitions are current.

Traceability Validation

Legal requirement → documentation → assessment → conformity → evidence chain is complete.

104. Limitations

This mapping cannot independently determine:

whether a particular conformity-assessment route legally applies;
whether a notified body is legally competent for a particular assessment;
whether technical documentation is substantively sufficient;
whether conformity has been demonstrated;
whether a declaration of conformity is legally valid;
whether CE marking is lawful;
whether a product-law conformity procedure is satisfied.

Those questions require current law, technical evidence, and the appropriate legal/conformity authorities.

105. Current Official Baseline

The current Commission implementation material states that high-risk AI systems are subject to strict obligations before they can be placed on the market or put into service, including risk management, data quality, logging, technical documentation, information to deployers, human oversight, robustness, cybersecurity, and accuracy. The current application schedule places the relevant Article 6(2)/Annex III obligations from 2 December 2027 and the Article 6(1)/Annex I product-related pathway from 2 August 2028. The Commission’s high-risk classification guidance remains an implementation aid rather than binding law.

106. Current Amendment Baseline

Regulation (EU) 2026/1744 is part of the current legal baseline. For conformity governance, particular attention should be paid to its amendments concerning:

Article 43;
notified-body arrangements;
interaction with Union harmonisation legislation;
quality-management systems;
transitional assessment arrangements.

107. Review Triggers

This mapping should be reviewed when:

the AI Act is amended;
Article 43 changes;
technical-documentation requirements change;
conformity procedures change;
Annexes change;
notified-body requirements change;
implementing acts are adopted;
delegated acts are adopted;
harmonised standards materially change;
common specifications are adopted;
official Commission guidance changes.

108. Review Frequency

Minimum:

annual;
event-driven after legal or regulatory change;
before major AIGO releases.

Event-driven review takes precedence.

109. 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
`03-AIGO-EU-AI-Act-High-Risk-AI-Mapping-v0.1.md`	High-risk classification and requirements
`04-AIGO-EU-AI-Act-Transparency-Mapping-v0.1.md`	Article 50
`05-AIGO-EU-AI-Act-GPAI-Mapping-v0.1.md`	GPAI
`06-AIGO-EU-AI-Act-AI-Literacy-Mapping-v0.1.md`	Article 4
`07-AIGO-EU-AI-Act-Governance-and-Enforcement-Mapping-v0.1.md`	Authorities and enforcement
`09-AIGO-EU-AI-Act-Rights-and-Remedies-Mapping-v0.1.md`	Rights
`10-AIGO-EU-AI-Act-Annexes-Mapping-v0.1.md`	Annexes
`11-AIGO-EU-AI-Act-Applicability-and-Timeline-v0.1.md`	Timeline
`12-AIGO-EU-AI-Act-AIGO-Control-Mapping-v0.1.md`	AIGO controls
`13-AIGO-EU-AI-Act-Evidence-and-Assurance-Mapping-v0.1.md`	Evidence / assurance

110. Document Control

Field	Value
Document	AIGO EU AI Act Conformity and Documentation Mapping
Version	0.1
Status	Draft
Document Identifier	`AIGO-MAP-EUAI-008`
Document Type	EU AI Act Mapping
Primary Provisions	Articles 11, 16–19, 43–49
Primary Annexes	IV, V, VI, VII, VIII, IX
Amendment Baseline	Regulation (EU) 2026/1744
Owner
Legal/Compliance Reviewer
Governance Reviewer
Conformity Reviewer
Framework Architect
Approved By
Effective Date
Next Review Date

111. Document Status

Document: AIGO — EU AI Act Conformity and Documentation Mapping Version: 0.1 Status: Draft Working Name: AIGO Full Name: AI Governance Operating Framework Document Identifier: AIGO-MAP-EUAI-008 Document Type: EU AI Act Mapping This document maps the EU AI Act conformity-assessment and documentation framework to the AIGO AI Governance Operating Framework, including technical documentation, quality management, record keeping, conformity procedures, notified bodies, certificates, declarations, CE marking, registration, corrective action, evidence, assurance, change management, and lifecycle governance. End of Document

​AIGO — EU AI Act Conformity and Documentation Mapping

​1. Document Purpose

​2. Mapping Information

​3. Source Hierarchy

​3.1 Binding Legal Source

​3.2 Official Implementation Material

​3.3 AIGO Mapping

​4. Conformity Governance Principle

​5. Conformity Applicability

​6. Conformity Decision Record

​7. AIGO Conformity Control

​8. Relationship Between AIGO Assurance and Conformity Assessment

​9. Article 11 — Technical Documentation

​9.1 Legal Theme

​9.2 AIGO Mapping

​10. Technical Documentation Control

​11. Technical Documentation — General System Description

​AIGO Mapping

​12. Technical Documentation — Intended Purpose

​13. Technical Documentation — System Version

​14. Technical Documentation — System Interfaces

​15. Technical Documentation — Lifecycle Versions

​16. Technical Documentation — Design and Development

​17. Technical Documentation — Data

​18. Technical Documentation — Risk Management

​19. Technical Documentation — Testing and Validation

​20. Technical Documentation — Accuracy

​21. Technical Documentation — Robustness

​22. Technical Documentation — Cybersecurity

​23. Technical Documentation — Human Oversight

​24. Technical Documentation — Logging

​25. Article 12 — Record-Keeping

​25.1 AIGO Mapping

​26. Record-Keeping Evidence

​27. Article 16 — Provider Documentation and Compliance Responsibilities

​28. Article 17 — Quality Management System

​28.1 Legal Theme

​28.2 AIGO Mapping

​29. QMS Documentation

​30. QMS and Existing Management Systems

​31. Article 18 — Documentation Retention

​32. Article 19 — Automatically Generated Logs

​33. Articles 20–22 — Corrective Action and Cooperation

​34. Article 43 — Conformity Assessment

​34.1 Legal Theme

​34.2 AIGO Mapping

​35. Conformity Pathway Decision

​36. Internal Control Route

​37. Third-Party Conformity Assessment

​38. Notified Body Governance

​39. Notifying Authority Relationship

​40. Article 43 Amendment Baseline

​41. Notified-Body Transition Control

​42. Article 44 — Certificates

​43. Certificate Integrity

​44. Certificate Change Management

​45. Article 45 — Changes to High-Risk Systems

​46. Article 46 — Certain Procedures for Product-Related Systems

​47. Article 47 — EU Declaration of Conformity

​47.1 AIGO Mapping

​48. Declaration of Conformity Control

​49. Declaration Evidence

​50. Article 48 — CE Marking

​51. Article 49 — Registration

​52. EU Database Registration Control

​53. Registration Change Management

​54. Annex IV — Technical Documentation Architecture

​55. AIGO Technical Documentation Profile

​56. Technical Documentation and Evidence

​57. Technical Documentation and Change

​58. Technical Documentation and Assurance

​59. Simplified Documentation for SMEs

​60. Technical Documentation and Document Integrity

​61. Technical Documentation and Framework Consistency

​62. Technical Documentation and Evidence Coverage

​63. Quality Management and Document Control

​64. Regulatory Evidence Pack

​65. Evidence-Pack Integrity

​66. Market-Placement Readiness

​67. Putting-Into-Service Gate