AIGO — EU AI Act Mapping Architecture

1. Document Purpose

This document defines the architecture, methodology, scope, governance, versioning, traceability model, and maintenance requirements for the AIGO mapping package for the European Union Artificial Intelligence Act. The mapping package translates applicable EU AI Act requirements into the AIGO AI Governance Operating Framework while preserving a clear distinction between:

the authoritative legal requirements of the EU AI Act;
European Commission and EU AI Office implementation material;
AIGO governance interpretations;
AIGO controls and procedures;
evidence and assurance expectations; and
organization-specific legal or compliance determinations.

The mapping package is intended to provide a structured bridge from European Union AI regulation to an operational AI governance system. It is not itself a legal interpretation, legal opinion, or substitute for professional legal advice.

2. Mapping Package Information

Field	Value
Mapping Package	AIGO EU AI Act Mapping
Version	0.1
Status	Draft
Document Identifier	`AIGO-MAP-EUAI-ARCH-001`
Document Type	Mapping Architecture
Framework	AIGO — AI Governance Operating Framework
Primary Legal Instrument	Regulation (EU) 2024/1689
Current Legal Update Basis	Regulation (EU) 2026/1744
Primary Legal Source	EUR-Lex
Supporting Implementation Source	European Commission / European AI Office
Mapping Directory	`mappings/eu-ai-act/`

Regulation (EU) 2024/1689 is the foundational AI Act instrument. Its original Article 113 established staged application dates, and Regulation (EU) 2026/1744 subsequently amended the AI Act as part of the Digital Omnibus on AI.

3. Authoritative Source Hierarchy

The mapping package shall use an explicit source hierarchy.

Tier 1 — Binding EU Law

The primary source is the applicable text of: Regulation (EU) 2024/1689 as amended by applicable subsequent Union legislation, including: Regulation (EU) 2026/1744 The EUR-Lex consolidated/current legal text and Official Journal publications are authoritative for legal requirements.

Tier 2 — Official EU Implementation Material

Supporting sources include:

European Commission guidance;
European AI Office guidance;
Commission FAQs;
implementing acts;
delegated acts;
codes of practice;
harmonised standards where formally applicable;
common specifications;
other official implementation material.

These materials should never be presented as having the same legal status as the Regulation itself.

Tier 3 — AIGO Interpretation

AIGO mapping documents may interpret how an EU AI Act requirement can be operationalized through AIGO. AIGO interpretation must remain clearly labelled as an implementation mapping rather than a statement of law.

Tier 4 — Organizational Implementation

Organizations may define:

policies;
procedures;
roles;
controls;
evidence;
assessments;
approvals;
monitoring;
assurance.

These are implementation mechanisms and do not modify the legal requirement.

4. Core Mapping Principle

Every material mapping should preserve the following chain:

EU AI Act Requirement
        ↓
Applicable Article / Annex / Provision
        ↓
Applicability Condition
        ↓
AIGO Governance Requirement
        ↓
AIGO Risk / Governance Objective
        ↓
AIGO Control
        ↓
AIGO Procedure / Template
        ↓
AIGO Evidence
        ↓
AIGO Assessment / Assurance
        ↓
Management / Governance Decision

This chain allows an organization to move from legal requirement to operational governance without losing source traceability.

5. Mapping Objectives

The mapping package shall support the following objectives:

identify applicable EU AI Act requirements;
identify the actors affected by each requirement;
classify requirements by legal and governance significance;
map requirements to AIGO governance domains;
map requirements to AIGO controls;
map requirements to AIGO risks;
identify assessment requirements;
identify approval requirements;
identify monitoring requirements;
identify evidence requirements;
identify assurance opportunities;
identify implementation gaps;
support traceability;
support audit and assurance;
support management review; and
support continual improvement.

6. Mapping Scope

The mapping package should cover, as applicable:

definitions;
prohibited AI practices;
AI literacy;
high-risk AI systems;
obligations of providers;
obligations of deployers;
transparency;
general-purpose AI models;
systemic-risk GPAI;
governance;
market surveillance;
enforcement;
penalties;
conformity assessment;
registration;
documentation;
record keeping;
technical requirements;
fundamental-rights considerations;
post-market monitoring;
incident reporting;
rights and remedies;
annexes;
applicability;
transitional provisions; and
official implementation guidance.

The package should also identify provisions that do not directly map to an AIGO organizational control.

7. EU AI Act Structural Model

The mapping architecture should organize the Regulation into logical mapping domains. The initial package is:

Main Mapping
Prohibited AI Practices
High-Risk AI
Transparency
GPAI
AI Literacy
Governance and Enforcement
Conformity and Documentation
Rights and Remedies
Annexes
Applicability and Timeline
AIGO Control Mapping
Evidence and Assurance

Each document should avoid duplicating the entire Regulation. Instead, it should provide focused cross-references to authoritative provisions.

8. Mapping File Architecture

The complete package should be:

mappings/
└── eu-ai-act/
    ├── README.md
    ├── 00-AIGO-EU-AI-Act-Mapping-Architecture-v0.1.md
    ├── 00-AIGO-EU-AI-Act-Mapping-Registry-v0.1.json
    ├── 01-AIGO-EU-AI-Act-Main-Mapping-v0.1.md
    ├── 02-AIGO-EU-AI-Act-Prohibited-AI-Practices-Mapping-v0.1.md
    ├── 03-AIGO-EU-AI-Act-High-Risk-AI-Mapping-v0.1.md
    ├── 04-AIGO-EU-AI-Act-Transparency-Mapping-v0.1.md
    ├── 05-AIGO-EU-AI-Act-GPAI-Mapping-v0.1.md
    ├── 06-AIGO-EU-AI-Act-AI-Literacy-Mapping-v0.1.md
    ├── 07-AIGO-EU-AI-Act-Governance-and-Enforcement-Mapping-v0.1.md
    ├── 08-AIGO-EU-AI-Act-Conformity-and-Documentation-Mapping-v0.1.md
    ├── 09-AIGO-EU-AI-Act-Rights-and-Remedies-Mapping-v0.1.md
    ├── 10-AIGO-EU-AI-Act-Annexes-Mapping-v0.1.md
    ├── 11-AIGO-EU-AI-Act-Applicability-and-Timeline-v0.1.md
    ├── 12-AIGO-EU-AI-Act-AIGO-Control-Mapping-v0.1.md
    └── 13-AIGO-EU-AI-Act-Evidence-and-Assurance-Mapping-v0.1.md

The architecture file defines the package. The registry provides machine-readable inventory metadata. The numbered mapping documents provide substantive mapping content.

9. Mapping Identifier Convention

Each mapping requirement should have a stable identifier. Recommended format:

EUAI-<AREA>-<ARTICLE/ANNEX>-<SEQUENCE>

Examples:

EUAI-GEN-ART4-001
EUAI-PROH-ART5-001
EUAI-HR-ART9-001
EUAI-HR-ART10-001
EUAI-TRAN-ART50-001
EUAI-GPAI-ART53-001
EUAI-GOV-ART64-001
EUAI-ANNEX-III-001

The exact identifier scheme may be refined before the mapping registry is finalized. Identifiers should remain stable across mapping revisions.

10. Source Citation Convention

Every material mapping should identify its legal source precisely. At minimum:

regulation;
article;
paragraph where applicable;
point or subparagraph where applicable;
annex where applicable;
official source location;
source version or amendment context.

Example:

Source:
Regulation (EU) 2024/1689, Article 50(1)

Where the provision has been amended, the mapping should identify the amending instrument. The mapping should not rely solely on a secondary web summary.

11. Legal Status Field

Each mapping entry should identify the nature of the source. Recommended values include:

BINDING_PROVISION
RECITAL
ANNEX
DELEGATED_ACT
IMPLEMENTING_ACT
OFFICIAL_GUIDELINE
OFFICIAL_FAQ
CODE_OF_PRACTICE
HARMONISED_STANDARD
COMMON_SPECIFICATION
AIGO_INTERPRETATION
ORGANIZATIONAL_IMPLEMENTATION

This prevents different authorities from being conflated.

12. Mapping Relationship Types

The package should distinguish mapping relationships. Recommended types include:

DIRECT
PARTIAL
SUPPORTING
INDIRECT
CONDITIONAL
INFORMATIVE
NOT_APPLICABLE
NO_DIRECT_AIGO_EQUIVALENT

DIRECT

AIGO contains a control or governance requirement that directly addresses the legal requirement.

PARTIAL

AIGO addresses part of the requirement.

SUPPORTING

AIGO provides an enabling governance mechanism but not the full legal requirement.

INDIRECT

The relationship is useful but not a direct implementation mapping.

CONDITIONAL

The mapping applies only when defined applicability conditions are met.

INFORMATIVE

The relationship provides context but not an implementation control.

NOT_APPLICABLE

The provision is outside the defined AIGO organizational scope.

NO_DIRECT_AIGO_EQUIVALENT

The legal requirement does not correspond to a single AIGO object and requires external or organizational implementation.

13. Applicability Model

EU AI Act applicability must be evaluated before control mapping. The mapping should consider:

actor role;
provider/deployer/importer/distributor status;
system type;
intended purpose;
location;
placing on the market;
putting into service;
deployment context;
affected persons;
high-risk status;
GPAI status;
systemic-risk status;
prohibited-practice conditions;
exceptions;
transitional provisions;
sectoral context.

AIGO should not map every EU AI Act requirement to every AI system.

14. Actor Model

The mapping package should distinguish actors including, as applicable:

PROVIDER
DEPLOYER
IMPORTER
DISTRIBUTOR
PRODUCT_MANUFACTURER
AUTHORISED_REPRESENTATIVE
OPERATOR
USER
AFFECTED_PERSON
PUBLIC_AUTHORITY
NATIONAL_COMPETENT_AUTHORITY
MARKET_SURVEILLANCE_AUTHORITY
EUROPEAN_AI_OFFICE
OTHER_RELEVANT_ACTOR

The applicability of a requirement should not be inferred solely from the existence of an AI system.

15. Geographic and Territorial Applicability

The mapping should consider the AI Act’s territorial scope. Applicability may depend on:

establishment;
provider location;
deployer location;
output use in the Union;
placing on the EU market;
activities involving Union users or affected persons;
other statutory conditions.

AIGO should provide an applicability field rather than assuming that all organizational AI activity is automatically within scope.

16. Risk-Based Mapping

The mapping should preserve the EU AI Act’s risk-oriented structure. A conceptual mapping is:

Prohibited Risk
      ↓
Prohibited Practice Controls

High Risk
      ↓
High-Risk Governance and Control Set

Transparency Risk
      ↓
Transparency Controls

GPAI
      ↓
GPAI Governance Set

Minimal / Limited Regulatory Burden
      ↓
Baseline AIGO Governance

The AIGO risk model may be more granular than the EU AI Act. The mapping should therefore not force the two classification systems into false equivalence.

17. AIGO Classification Versus EU AI Act Classification

The AIGO classification system and EU AI Act categories should remain distinct. A mapping should identify:

EU AI Act category;
AIGO classification;
basis for relationship;
applicability;
required additional controls.

A high AIGO risk classification does not automatically mean that a system is legally high-risk under the EU AI Act. Conversely, legal high-risk status should be represented explicitly within AIGO classification and applicability records.

18. Prohibited-Practice Architecture

The prohibited-practice mapping should identify:

Article 5 requirements;
applicable prohibited-practice categories;
system conditions;
organization role;
applicable exceptions;
AIGO decision gate;
control requirements;
assessment;
approval;
evidence;
escalation.

The mapping should support an explicit governance decision:

Potential Use
     ↓
Article 5 Screening
     ↓
Prohibited Practice?
     ↓
YES → Do Not Proceed / Escalate
NO  → Continue Classification

The Commission has published guidance on prohibited AI practices and definitions, and these should be treated as official interpretive support rather than as a replacement for the Regulation.

19. High-Risk Architecture

The high-risk mapping should separate at least:

Article 6 classification;
Annex I product-related systems;
Annex III use cases;
applicable provider/deployer obligations;
conformity assessment;
post-market obligations;
transition dates.

The European Commission currently indicates that, following the Digital Omnibus, high-risk rules for certain Annex III systems apply from 2 December 2027, while AI embedded in regulated products under the Annex I pathway has an extended date of 2 August 2028. These dates must be maintained in the dedicated applicability/timeline mapping rather than duplicated independently throughout every mapping document.

20. Transparency Architecture

Transparency mapping should include Article 50 and related requirements. As of the current AIGO mapping baseline, the European Commission states that Article 50 transparency obligations apply from 2 August 2026. It also identifies a limited transition for certain marking and detection obligations for AI systems placed on the market before that date, running to 2 December 2026. The mapping should distinguish:

interaction disclosure;
synthetic-content marking;
deepfake disclosure;
public-interest text disclosure;
emotion-recognition and biometric categorization information;
applicability conditions;
provider versus deployer responsibilities.

21. GPAI Architecture

The GPAI mapping should separately address:

providers;
GPAI models;
systemic-risk GPAI;
technical documentation;
information to downstream providers;
copyright policy;
training-content summaries;
systemic-risk assessment;
incident and risk-management expectations;
codes of practice;
AI Office interactions;
enforcement.

The Commission states that GPAI obligations entered into application on 2 August 2025, that Commission enforcement powers apply from 2 August 2026, and that providers of models placed on the market before 2 August 2025 have until 2 August 2027 for compliance.

22. AI Literacy Architecture

The architecture must reflect the current legal and implementation position rather than assuming the original 2024/2025 wording remains unchanged. The original AI Act imposed AI-literacy obligations from 2 February 2025. The 2026 Digital Omnibus changed aspects of the AI-literacy framework, including replacing a previous company-focused requirement with non-binding encouragement while strengthening the role of the Commission and Member States in promoting AI literacy. The mapping should therefore contain:

legal requirement;
current amendment status;
organizational relevance;
AIGO competence/training controls;
evidence;
current versus future implementation status.

23. Governance Architecture

Governance mapping should cover:

European AI governance;
AI Office;
national competent authorities;
market surveillance;
AI Board;
advisory bodies where relevant;
organizational accountability;
enforcement;
penalties;
cooperation.

AIGO should map organizational governance responsibilities without implying that an organization has regulatory powers belonging to EU or national authorities.

24. Conformity Architecture

Conformity-related mapping should distinguish:

conformity assessment;
technical documentation;
quality-management requirements;
registration;
declarations;
CE marking where applicable;
post-market monitoring;
logs;
corrective action;
incident reporting.

The AIGO Approval and Assurance structures should be mapped as organizational governance mechanisms supporting these obligations. They should not be represented as automatic substitutes for statutory conformity assessment procedures.

25. Fundamental-Rights Architecture

The mapping should identify relevant fundamental-rights considerations, including where applicable:

discrimination;
privacy;
data protection;
dignity;
human autonomy;
access to essential services;
employment;
education;
democratic processes;
effective remedy.

AIGO should connect these concerns to:

risk;
impact assessment;
classification;
controls;
human oversight;
monitoring;
incidents;
assurance.

26. Rights and Remedies Architecture

Where the EU AI Act provides rights, information, complaint, or challenge mechanisms, the mapping should identify:

entitled party;
duty bearer;
trigger;
information required;
complaint pathway;
authority;
record;
evidence;
remediation;
escalation.

AIGO should not claim to provide a statutory remedy merely because an internal complaint procedure exists.

27. Evidence Architecture

Every mapped requirement should identify evidence expectations where feasible. Recommended structure:

EU AI Act Requirement
        ↓
AIGO Requirement
        ↓
AIGO Control
        ↓
Evidence Requirement
        ↓
Evidence Record
        ↓
Assurance

The Evidence Coverage Validator can later evaluate whether the required evidence exists.

28. Assurance Architecture

Assurance mappings should identify where an EU AI Act requirement may warrant:

compliance assessment;
technical assessment;
independent assurance;
control assessment;
model validation;
documentation review;
monitoring review;
post-market review.

The mapping should distinguish:

Legal conformity assessment

from:

Organizational assurance

They are related but not interchangeable.

29. Control Mapping Architecture

The detailed control mapping file should connect:

EU AI Act Provision
       ↓
AIGO Governance Requirement
       ↓
AIGO Control ID
       ↓
Control Owner
       ↓
Assessment
       ↓
Evidence
       ↓
Monitoring
       ↓
Assurance

A legal provision may map to:

one AIGO control;
multiple controls;
a governance domain;
a procedure;
an assessment;
an approval condition.

Mapping should not force one-to-one relationships where they do not exist.

30. AIGO Control Mapping Rules

Control mappings should identify:

directness;
applicability;
control coverage;
implementation dependency;
evidence requirement;
assurance requirement;
status.

Example:

EUAI-HR-ART9-001
    ↓
AIGO Risk Management Control
    ↓
AIGO Risk Assessment Procedure
    ↓
AIGO Risk Assessment Template
    ↓
Risk Schema
    ↓
Evidence Schema

31. Requirement-to-Control Completeness

A mapped EU AI Act requirement should not be considered operationally covered solely because an AIGO control ID is listed. The mapping should distinguish:

Mapped

from:

Implemented

and:

Assured

Recommended status chain:

MAPPED
   ↓
IMPLEMENTATION_DEFINED
   ↓
IMPLEMENTED
   ↓
EVIDENCED
   ↓
ASSESSED
   ↓
ASSURED

32. Applicability Decision Model

For material requirements, AIGO should provide a structured applicability decision. Recommended model:

Requirement Identified
        ↓
Actor Check
        ↓
Territorial Scope
        ↓
AI-System Classification
        ↓
Use-Case / Purpose Check
        ↓
Exception Check
        ↓
Transition Check
        ↓
Applicable?
   ┌────┴────┐
  YES        NO
   ↓          ↓
Map Controls  Record Rationale

An NOT_APPLICABLE decision should have a documented basis where required.

33. Transitional and Timeline Architecture

The timeline mapping must be the single controlled source for application dates. The current regulatory architecture should distinguish at least:

2 February 2025
- Prohibitions, definitions, AI-literacy provisions began applying under the original AI Act structure.

2 August 2025
- Governance provisions and GPAI obligations entered application under the original staged framework.

2 August 2026
- General application date under the AI Act.
- Article 50 transparency obligations apply.
- Current EU implementation position must account for Digital Omnibus amendments.

2 December 2026
- Limited transition for certain Article 50 marking/detection obligations for certain pre-existing systems.

2 December 2027
- Current application date for specified Annex III high-risk systems following the Digital Omnibus.

2 August 2028
- Current application date for high-risk AI embedded in regulated products covered by the Annex I pathway.

These dates should be validated against current legal text and official Commission implementation materials before each AIGO release.

34. Timeline Governance Rule

Timeline information must never be copied independently into multiple mapping files without a controlled source. All mapping documents should reference: 11-AIGO-EU-AI-Act-Applicability-and-Timeline-v0.1.md for current application and transition information. This prevents inconsistent dates across the mapping package.

35. Legal Change Monitoring

The mapping package should be maintained as a living regulatory mapping. Change monitoring should cover:

amendments to the AI Act;
delegated acts;
implementing acts;
Commission guidance;
AI Office guidance;
codes of practice;
harmonised standards;
common specifications;
official FAQs;
enforcement developments;
relevant judgments or authoritative interpretations where applicable.

A mapping release should record the legal and implementation source baseline.

36. Mapping Status

Each mapping entry should support controlled status values:

DRAFT
UNDER_REVIEW
MAPPED
PARTIALLY_MAPPED
VALIDATED
APPROVED
SUPERSEDED
RETIRED

VALIDATED should mean the mapping has undergone the defined mapping review. It should not mean that legal compliance has been independently established.

37. Mapping Confidence

A mapping entry may include a confidence indicator. Possible values:

HIGH
MEDIUM
LOW
PENDING_INTERPRETATION

Confidence should reflect the stability and clarity of the mapping. It should not be used as a legal certainty score.

38. Mapping Ambiguity

Where a requirement is subject to interpretation or future guidance, the mapping should identify:

ambiguity;
source;
current interpretation;
alternative interpretation;
implementation consequence;
review trigger.

This is particularly important for concepts whose practical application depends on Commission guidance or evolving standards.

39. Mapping Exceptions

A mapping exception may be appropriate where:

no AIGO equivalent exists;
the provision is addressed outside AIGO;
the provision applies only to a specific actor;
the requirement is sector-specific;
implementation depends on another legal instrument.

Exceptions should be documented rather than silently omitted.

40. Mapping Traceability

Each mapping entry should be traceable to:

legal source;
applicability condition;
AIGO component;
control;
procedure;
template;
schema;
evidence requirement;
assurance requirement;
review status.

Recommended chain:

EU AI Act
    ↓
Mapping Entry
    ↓
AIGO Component
    ↓
Operational Artifact
    ↓
Evidence
    ↓
Assurance

41. Relationship to AIGO Schema Model

The mapping package should use the existing AIGO schemas. Examples:

EU AI Act Requirement
   ↓
Risk Schema
Control Schema
Assessment Schema
Approval Schema
Monitoring Schema
Incident Schema
Change Schema
Assurance Schema
Evidence Schema
Governance Schema

The mapping should not create parallel uncontrolled AIGO record structures.

42. Relationship to AIGO Governance

The Governance Schema provides the organizational framework for:

authority;
roles;
decision rights;
risk appetite;
controls;
lifecycle governance;
assurance;
management review;
improvement.

EU AI Act requirements should be mapped into this governance architecture where organizational action is required.

43. Relationship to AIGO Risk

A mapped legal requirement may create or modify an AI governance risk. For example:

EU AI Act Requirement
      ↓
Applicability
      ↓
Compliance / Governance Risk
      ↓
Risk Treatment
      ↓
Control

The mapping should distinguish regulatory compliance risk from technical AI risk where relevant.

44. Relationship to AIGO Controls

A control should state what it operationally accomplishes. The mapping should not merely copy legal text into the control catalog. The control should provide an operational mechanism for implementing the mapped requirement.

45. Relationship to AIGO Assessment

Assessments should determine matters such as:

applicability;
classification;
risk;
control implementation;
conformity-related readiness;
impact;
evidence sufficiency.

The mapping should identify which assessments support each mapped requirement.

46. Relationship to AIGO Approval

Some EU AI Act requirements may result in internal approval gates. Examples include:

deployment;
high-risk system release;
changes affecting compliance;
acceptance of residual compliance risk;
retirement.

An AIGO approval should not be represented as a replacement for any statutory approval or conformity procedure required by law.

47. Relationship to AIGO Monitoring

Monitoring should support continued compliance. Examples include:

system performance;
human oversight;
incidents;
logging;
transparency;
changes;
post-market obligations;
supplier changes.

Mapped monitoring requirements should be represented through the Monitoring Schema.

48. Relationship to AIGO Incidents

EU AI Act-related incidents or non-compliance conditions may feed:

Incident
   ↓
Risk
   ↓
Change
   ↓
Improvement
   ↓
Assurance

The mapping should identify where incident handling may support regulatory obligations.

49. Relationship to AIGO Change Management

Changes in:

model;
data;
intended purpose;
deployment;
provider;
high-risk classification;
transparency behavior;
GPAI dependency

may affect EU AI Act applicability. The mapping should require an applicability reassessment where defined triggers occur.

50. Relationship to AIGO Assurance

Assurance should evaluate whether:

mapped requirements are implemented;
controls operate;
evidence exists;
applicability decisions are documented;
material changes are reassessed;
exceptions remain authorized.

The mapping itself should not claim compliance merely because an assurance activity exists.

51. Relationship to AIGO Evidence

Evidence should support claims such as:

requirement applicability;
classification;
risk assessment;
control operation;
technical documentation;
monitoring;
incident management;
approval;
conformity-related activities;
rights handling.

The Evidence Coverage Validator should eventually be capable of checking mapped evidence coverage.

52. Relationship to Management Review

Material EU AI Act developments should be included in management review. Management should consider:

new requirements;
regulatory changes;
implementation status;
control gaps;
evidence gaps;
assurance findings;
timeline changes;
resource requirements.

This allows regulatory change to become part of the continual governance cycle.

53. Relationship to Improvement

Mapping gaps should create Improvement records when necessary. Example:

EU AI Act Mapping Gap
        ↓
AIGO Improvement
        ↓
Control / Procedure Change
        ↓
Evidence
        ↓
Verification
        ↓
Assurance

This connects regulatory monitoring to continual improvement.

54. Legal Disclaimer

The AIGO EU AI Act Mapping package is an operational governance mapping. It should not be represented as:

legal advice;
legal opinion;
official European Commission guidance;
official AI Office guidance;
an EU conformity assessment;
a declaration of compliance;
a regulatory approval.

The authoritative legal source remains applicable EU law.

55. Source Currency

Because the EU AI Act is an evolving implementation environment, the mapping package should record:

source publication date;
source access date;
legal instrument version;
amendment status;
implementation guidance version;
mapping review date.

The European Commission’s current material reflects significant 2026 developments, including the Digital Omnibus and updated transparency/GPAI implementation guidance.

56. Mapping Review Frequency

At minimum, the EU AI Act mapping should be reviewed:

whenever an amending legal act enters into force;
whenever the Commission publishes material implementation guidance;
whenever relevant delegated or implementing acts are adopted;
whenever harmonised standards materially change the implementation environment;
before each AIGO major release;
after a material regulatory incident;
after a material assurance finding concerning EU AI Act mapping.

57. Mapping Review Triggers

Review should be triggered by:

amendment to Regulation (EU) 2024/1689;
new regulation affecting applicability;
Digital Omnibus changes;
new official Commission guidance;
AI Office guidance;
new GPAI Code of Practice;
new transparency guidance;
new high-risk classification guidance;
significant case law or authoritative interpretation;
new standards or common specifications;
significant organization/business changes.

58. Mapping Versioning

The mapping package version is separate from:

the EU AI Act legal version;
AIGO framework version;
tool version;
schema version.

Example:

AIGO Mapping Package: 0.1
AIGO Framework: 0.1
EU AI Act: 2024/1689 as amended by applicable law
Mapping Review Date: 2026-08-14

59. Release and Approval

A mapping release should pass:

Source Verification
        ↓
Mapping Completeness
        ↓
AIGO Reference Validation
        ↓
Traceability Validation
        ↓
Framework Consistency Check
        ↓
Legal / Compliance Review
        ↓
Governance Approval
        ↓
Release

Legal/compliance review is recommended for material mappings because automated validation cannot determine whether the legal interpretation is correct.

60. Mapping Quality Criteria

A high-quality mapping should be:

source-traceable;
current;
explicit;
actor-aware;
applicability-aware;
risk-aware;
control-linked;
evidence-linked;
versioned;
reviewable;
reproducible;
clear about uncertainty.

61. Mapping Completeness

Mapping completeness should be measured separately from legal compliance. Possible metrics include:

Provision Coverage
Actor Coverage
Applicability Coverage
AIGO Control Coverage
Evidence Coverage
Assurance Coverage
Timeline Coverage
Annex Coverage

A complete mapping does not automatically establish compliance.

62. Mapping Coverage Score

A future mapping validator may calculate:

Mapping Coverage % =
Mapped Applicable Provisions
----------------------------
Applicable Provisions
× 100

The calculation should exclude provisions outside the defined mapping scope and should identify exclusions explicitly.

63. Critical Mapping Gaps

Critical mapping gaps may include:

prohibited practice provision not mapped;
high-risk obligation missing;
GPAI obligation missing;
Article 50 requirement missing;
applicable governance obligation missing;
mandatory evidence requirement absent;
timeline change not reflected;
amendment not incorporated.

Critical mapping gaps should normally block an AIGO mapping release until addressed or formally accepted.

64. Current Timeline Baseline

The mapping architecture shall treat the following as the current baseline to be verified against the legal source at every release:

Requirement Area	Current Baseline
AI Act entry into force	1 August 2024
Prohibitions / definitions / AI literacy	2 February 2025 under the original staged framework
Governance / GPAI	2 August 2025
General application	2 August 2026
Article 50 transparency	2 August 2026
Certain pre-existing Article 50 content-marking transition	2 December 2026
Specified Annex III high-risk systems	2 December 2027
Annex I regulated-product high-risk systems	2 August 2028

The 2027/2028 high-risk dates reflect the current Digital Omnibus implementation position. The original Regulation contains different staged dates in Article 113, so the mapping package must always account for subsequent amendments rather than reproducing the unamended 2024 timeline.

65. Official Implementation Material

The mapping package should maintain source references to relevant official material, including:

European Commission AI Act implementation page;
European AI Office guidance;
Article 50 transparency guidelines;
GPAI provider guidelines;
GPAI Code of Practice;
prohibited-practice guidance;
high-risk classification guidance when finalized;
official FAQs;
implementing acts;
delegated acts.

For example, the Commission published Article 50 transparency guidelines in July 2026, confirming application from 2 August 2026.

66. Mapping Registry Requirements

The machine-readable registry should maintain at least:

mappingId
mappingFile
mappingArea
version
status
legalSource
sourceVersion
lastReviewed
reviewOwner
aigoComponents
coverage
dependencies

Additional fields may include:

sourceArticleCount
mappedProvisionCount
unmappedProvisionCount
criticalGapCount
confidence

67. Mapping Registry Integrity

The registry must remain consistent with:

actual mapping files;
mapping identifiers;
package version;
source version;
document paths;
review status.

The Framework Consistency Checker should be capable of validating registry consistency.

68. Mapping Documentation

Each mapping file should include:

purpose;
source basis;
scope;
applicability;
mapping methodology;
mapping table;
AIGO relationships;
evidence;
assurance;
limitations;
version;
source date;
review;
document control.

69. Mapping Table Standard

The preferred table structure is:

Mapping ID	EU AI Act Source	Applicability	Requirement	AIGO Component	AIGO Control	Evidence	Assurance	Status

This should be used consistently across the mapping package where practical.

70. Additional Mapping Fields

Detailed mappings may include:

Field	Purpose
Actor	Identifies duty bearer
Legal Status	Distinguishes binding and supporting material
Effective Date	Determines timing
Transition	Identifies transitional rule
Relationship	Defines direct/partial/supporting mapping
AIGO Procedure	Identifies operating mechanism
AIGO Template	Identifies operational record
AIGO Schema	Identifies machine-readable representation
Risk	Identifies governance risk
Control	Identifies implementation mechanism
Evidence	Identifies proof
Assurance	Identifies verification
Owner	Identifies accountability
Confidence	Identifies mapping certainty
Review Date	Controls currency

71. Mapping and AIGO Control Coverage

After the EU AI Act control-mapping file is established, the AIGO Control Coverage Validator should eventually be extended to calculate:

EU AI Act mapped control coverage;
high-risk control coverage;
transparency control coverage;
GPAI control coverage;
evidence coverage;
assurance coverage.

This creates a machine-verifiable connection between legal mapping and operational governance.

72. Mapping and Evidence Coverage

The Evidence Coverage Validator should eventually support evidence requirements derived from EU AI Act mappings. Example:

EU AI Act Requirement
      ↓
AIGO Control
      ↓
Required Evidence
      ↓
Evidence Coverage

This will allow AIGO to identify documentation and evidence gaps systematically.

73. Mapping and Repository Health

The Repository Health Checker should eventually include:

EU AI Act Mapping Health

with checks for:

mapping registry;
legal-source currency;
broken AIGO references;
missing mapping files;
inconsistent timeline dates;
unmapped critical provisions;
stale references.

74. Future Machine-Readable Mapping Schema

A future AIGO release may introduce a dedicated EU AI Act mapping schema. Potential object:

EU_AI_ACT_MAPPING

Potential structure:

mappingId
legalInstrument
sourceProvision
sourceType
actor
applicability
effectiveDate
transition
relationship
aigoRequirement
aigoRisk
aigoControl
aigoAssessment
aigoApproval
aigoMonitoring
aigoEvidence
aigoAssurance
status
confidence
review

Until such a schema exists, the Markdown mapping documents and mapping registry should remain the controlled source.

75. Mapping Tooling Roadmap

The mapping package should eventually support:

EU AI Act Mapping
       ↓
Mapping Registry
       ↓
Reference Validation
       ↓
Traceability Validation
       ↓
Control Coverage
       ↓
Evidence Coverage
       ↓
Repository Health

A later specialized Mapping Validator may verify legal-source references and mapping completeness.

76. Separation from Legal Compliance Assessment

The architecture must maintain the following distinction:

EU AI Act Mapping
        ≠
Legal Compliance Assessment

The mapping tells an organization:

Where and how AIGO addresses the identified requirement.

A compliance assessment determines:

Whether the organization actually satisfies the legal requirement in its specific factual and legal context.

These are different activities.

77. Regulatory Change Management

Changes to the legal source should trigger:

source identification;
applicability analysis;
impact analysis;
mapping update;
control impact analysis;
evidence impact analysis;
assurance impact analysis;
documentation update;
governance review;
approval;
release.

This creates a controlled regulatory-change loop.

78. Regulatory Change Traceability

The recommended chain is:

EU Legal Change
       ↓
Mapping Change
       ↓
AIGO Requirement Change
       ↓
Control Change
       ↓
Procedure / Template Change
       ↓
Evidence Change
       ↓
Monitoring / Assurance Change
       ↓
Management Review

Material changes should be managed through AIGO Change Management.

79. Regulatory Watchlist

The mapping package should maintain a future watchlist for:

amendments;
delegated acts;
implementing acts;
AI Office publications;
Commission guidelines;
codes of practice;
standards;
common specifications;
enforcement developments;
relevant legal decisions.

The watchlist should not itself be treated as legal authority.

80. Review and Maintenance Responsibility

The mapping package should have:

Mapping Owner;
Legal/Compliance Reviewer;
AI Governance Owner;
Framework Architect;
Control Owner;
Evidence Owner;
Assurance Reviewer.

Responsibilities should be documented in the mapping registry or governance record.

81. Document Control

Field	Value
Document	AIGO EU AI Act Mapping Architecture
Version	0.1
Status	Draft
Document Identifier	`AIGO-MAP-EUAI-ARCH-001`
Document Type	Mapping Architecture
Owner
Legal/Compliance Reviewer
Governance Reviewer
Framework Architect
Approved By
Effective Date
Next Review Date

82. Document Status

Document: AIGO — EU AI Act Mapping Architecture Version: 0.1 Status: Draft Working Name: AIGO Full Name: AI Governance Operating Framework Document Identifier: AIGO-MAP-EUAI-ARCH-001 Document Type: Mapping Architecture This document defines the architecture, methodology, source hierarchy, applicability model, traceability model, maintenance requirements, and validation approach for the AIGO EU AI Act Mapping package. End of Document

​AIGO — EU AI Act Mapping Architecture

​1. Document Purpose

​2. Mapping Package Information

​3. Authoritative Source Hierarchy

​Tier 1 — Binding EU Law

​Tier 2 — Official EU Implementation Material

​Tier 3 — AIGO Interpretation

​Tier 4 — Organizational Implementation

​4. Core Mapping Principle

​5. Mapping Objectives

​6. Mapping Scope

​7. EU AI Act Structural Model

​8. Mapping File Architecture

​9. Mapping Identifier Convention

​10. Source Citation Convention

​11. Legal Status Field

​12. Mapping Relationship Types

​DIRECT

​PARTIAL

​SUPPORTING

​INDIRECT

​CONDITIONAL

​INFORMATIVE

​NOT_APPLICABLE

​NO_DIRECT_AIGO_EQUIVALENT

​13. Applicability Model

​14. Actor Model

​15. Geographic and Territorial Applicability

​16. Risk-Based Mapping

​17. AIGO Classification Versus EU AI Act Classification

​18. Prohibited-Practice Architecture

​19. High-Risk Architecture

​20. Transparency Architecture

​21. GPAI Architecture

​22. AI Literacy Architecture

​23. Governance Architecture

​24. Conformity Architecture

​25. Fundamental-Rights Architecture

​26. Rights and Remedies Architecture

​27. Evidence Architecture

​28. Assurance Architecture

​29. Control Mapping Architecture

​30. AIGO Control Mapping Rules

​31. Requirement-to-Control Completeness

​32. Applicability Decision Model

​33. Transitional and Timeline Architecture

​34. Timeline Governance Rule

​35. Legal Change Monitoring

​36. Mapping Status

​37. Mapping Confidence

​38. Mapping Ambiguity

​39. Mapping Exceptions

​40. Mapping Traceability

​41. Relationship to AIGO Schema Model

​42. Relationship to AIGO Governance

​43. Relationship to AIGO Risk

​44. Relationship to AIGO Controls

​45. Relationship to AIGO Assessment

​46. Relationship to AIGO Approval

​47. Relationship to AIGO Monitoring

​48. Relationship to AIGO Incidents

​49. Relationship to AIGO Change Management

​50. Relationship to AIGO Assurance

​51. Relationship to AIGO Evidence

​52. Relationship to Management Review

​53. Relationship to Improvement

​54. Legal Disclaimer

​55. Source Currency

​56. Mapping Review Frequency

​57. Mapping Review Triggers

​58. Mapping Versioning

​59. Release and Approval

​60. Mapping Quality Criteria

​61. Mapping Completeness

​62. Mapping Coverage Score

​63. Critical Mapping Gaps

​64. Current Timeline Baseline

​65. Official Implementation Material

​66. Mapping Registry Requirements

​67. Mapping Registry Integrity

AIGO — EU AI Act Mapping Architecture

1. Document Purpose

2. Mapping Package Information

3. Authoritative Source Hierarchy

Tier 1 — Binding EU Law

Tier 2 — Official EU Implementation Material

Tier 3 — AIGO Interpretation

Tier 4 — Organizational Implementation

4. Core Mapping Principle

5. Mapping Objectives

6. Mapping Scope

7. EU AI Act Structural Model

8. Mapping File Architecture

9. Mapping Identifier Convention

10. Source Citation Convention

11. Legal Status Field

12. Mapping Relationship Types

DIRECT

PARTIAL

SUPPORTING

INDIRECT

CONDITIONAL

INFORMATIVE

NOT_APPLICABLE

NO_DIRECT_AIGO_EQUIVALENT

13. Applicability Model

14. Actor Model

15. Geographic and Territorial Applicability

16. Risk-Based Mapping

17. AIGO Classification Versus EU AI Act Classification

18. Prohibited-Practice Architecture

19. High-Risk Architecture

20. Transparency Architecture

21. GPAI Architecture

22. AI Literacy Architecture

23. Governance Architecture

24. Conformity Architecture

25. Fundamental-Rights Architecture

26. Rights and Remedies Architecture

27. Evidence Architecture

28. Assurance Architecture

29. Control Mapping Architecture

30. AIGO Control Mapping Rules

31. Requirement-to-Control Completeness

32. Applicability Decision Model

33. Transitional and Timeline Architecture

34. Timeline Governance Rule

35. Legal Change Monitoring

36. Mapping Status

37. Mapping Confidence

38. Mapping Ambiguity

39. Mapping Exceptions

40. Mapping Traceability

41. Relationship to AIGO Schema Model

42. Relationship to AIGO Governance

43. Relationship to AIGO Risk

44. Relationship to AIGO Controls

45. Relationship to AIGO Assessment

46. Relationship to AIGO Approval

47. Relationship to AIGO Monitoring

48. Relationship to AIGO Incidents

49. Relationship to AIGO Change Management

50. Relationship to AIGO Assurance

51. Relationship to AIGO Evidence

52. Relationship to Management Review

53. Relationship to Improvement

54. Legal Disclaimer

55. Source Currency

56. Mapping Review Frequency

57. Mapping Review Triggers

58. Mapping Versioning

59. Release and Approval

60. Mapping Quality Criteria

61. Mapping Completeness

62. Mapping Coverage Score

63. Critical Mapping Gaps

64. Current Timeline Baseline

65. Official Implementation Material

66. Mapping Registry Requirements

67. Mapping Registry Integrity