AIGO — EU AI Act Evidence and Assurance Mapping

1. Document Purpose

This document establishes the AIGO evidence and assurance mapping for Regulation (EU) 2024/1689, the European Union Artificial Intelligence Act, as amended by Regulation (EU) 2026/1744. It provides the evidence and assurance layer connecting:

EU AI Act Requirement
        ↓
Applicability
        ↓
AIGO Control
        ↓
Implementation
        ↓
Evidence
        ↓
Assessment
        ↓
Monitoring
        ↓
Assurance
        ↓
Finding
        ↓
Corrective Action
        ↓
Improvement

The purpose is to establish a controlled approach for identifying what evidence should exist, how evidence should be linked to AI governance activities, and how assurance should evaluate the reliability of the resulting governance record. This document is an operational governance mapping. It is not a legal opinion, conformity assessment, certification, audit opinion, or declaration of compliance. The current legal baseline is Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744. The European Commission’s current AI Act material confirms that high-risk obligations include risk management, data governance, logging, technical documentation, human oversight, robustness, cybersecurity and accuracy, while GPAI providers have separate documentation and other evidence obligations.

2. Mapping Information

Field	Value
Mapping	AIGO EU AI Act Evidence and Assurance Mapping
Version	0.1
Status	Draft
Document Identifier	`AIGO-MAP-EUAI-013`
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 Purpose	Evidence and assurance crosswalk
Mapping Architecture	`AIGO-MAP-EUAI-ARCH-001`
Timeline Source	`11-AIGO-EU-AI-Act-Applicability-and-Timeline-v0.1.md`
Control Mapping Source	`12-AIGO-EU-AI-Act-AIGO-Control-Mapping-v0.1.md`
Registry	`00-AIGO-EU-AI-Act-Mapping-Registry-v0.1.json`

Regulation (EU) 2026/1744 is the current amendment baseline for this mapping. It was published on 24 July 2026 and entered into force on 27 July 2026.

3. Evidence Governance Principle

Evidence should demonstrate the operation and outcome of governance activities. AIGO should distinguish:

Requirement

from:

Control

from:

Evidence

from:

Assurance

For example:

Article 9 Risk Management
        ↓
AIGO Risk Management Control
        ↓
Risk Assessment Record
        ↓
Risk-Treatment Evidence
        ↓
Monitoring Evidence
        ↓
Assurance Test
        ↓
Assurance Finding

The existence of a policy or control description alone does not demonstrate that the control operated effectively.

4. Evidence Relationship Types

AIGO should classify evidence relationships using:

PRIMARY
SUPPORTING
DERIVED
CROSS_REFERENCE
REGULATORY
TECHNICAL
OPERATIONAL
ASSURANCE
HISTORICAL

PRIMARY

Evidence directly demonstrating satisfaction or implementation of the mapped control.

SUPPORTING

Evidence supporting a decision or conclusion.

DERIVED

Evidence generated from another authoritative record.

CROSS_REFERENCE

Evidence held elsewhere and referenced rather than duplicated.

REGULATORY

Evidence supplied to or received from a competent authority.

TECHNICAL

Evidence concerning system, model, data, testing, or infrastructure.

OPERATIONAL

Evidence generated during normal system operation.

ASSURANCE

Evidence generated by independent or objective assessment.

HISTORICAL

Evidence retained for previous versions, decisions, or regulatory states.

5. Evidence Status

Evidence records should support:

REQUIRED
PLANNED
REQUESTED
RECEIVED
VALIDATED
CURRENT
STALE
SUPERSEDED
REJECTED
WITHDRAWN
RETAINED
DISPOSED

“Received” should not automatically mean “validated.”

6. Evidence Quality Model

AIGO evidence should be evaluated against:

Authenticity
Integrity
Attribution
Completeness
Accuracy
Currency
Relevance
Traceability
Availability
Retention

The appropriate evidence-quality threshold depends on risk and the legal requirement.

7. Evidence Integrity

Evidence supporting material EU AI Act governance decisions should be protected against unauthorized alteration. Potential controls include:

version control;
timestamps;
access control;
immutable or controlled repositories;
checksums where appropriate;
audit logs;
controlled deletion;
chain of custody.

The Document Integrity Checker can support structural integrity checks, but technical evidence integrity may require additional controls.

8. Evidence Attribution

Every material evidence record should identify:

evidence ID;
source;
owner;
creation date;
relevant system;
version;
related control;
related requirement;
review status.

Where evidence originates externally, the external source should be identified.

9. Evidence Currency

Evidence should be considered current only when its validity period or review state supports the applicable decision. Examples:

Current System Version
        ↓
Current Risk Assessment
        ↓
Current Control Evidence

Historical evidence should not be silently reused as current evidence.

10. Evidence and Versioning

AIGO should preserve version relationships:

AI System Version
        ↓
Model Version
        ↓
Configuration Version
        ↓
Risk Version
        ↓
Control Version
        ↓
Evidence Version
        ↓
Assurance Version

Material evidence should identify the system state to which it relates.

11. Evidence Traceability Principle

Every material EU AI Act requirement should be traceable through:

Legal Requirement
      ↓
Applicability Decision
      ↓
AIGO Control
      ↓
Assessment
      ↓
Evidence
      ↓
Monitoring
      ↓
Assurance

Where a requirement is not directly represented by an AIGO control, the mapping should explicitly state: NO_DIRECT_AIGO_EQUIVALENT rather than creating a false control relationship.

12. Master Evidence Chain

The AIGO evidence architecture is:

Source
  ↓
Requirement
  ↓
Applicability
  ↓
System
  ↓
Control
  ↓
Activity
  ↓
Evidence
  ↓
Validation
  ↓
Assessment
  ↓
Monitoring
  ↓
Assurance
  ↓
Finding
  ↓
Corrective Action

This is the primary traceability model for the EU AI Act mapping package.

13. Evidence Categories

Evidence should be organized into controlled categories:

LEGAL
GOVERNANCE
CLASSIFICATION
RISK
DATA
TECHNICAL
CONTROL
ASSESSMENT
APPROVAL
OPERATIONAL
MONITORING
INCIDENT
CHANGE
CONFORMITY
REGISTRATION
REGULATORY
RIGHTS
TRANSPARENCY
GPAI
AI_LITERACY
ASSURANCE
IMPROVEMENT
RETIREMENT

14. Applicability Evidence

Control Relationship

EUAI-CTRL-APP-001

Purpose

Demonstrate how the organization determined whether the AI Act applies.

Evidence

Potential evidence:

AI System Profile;
actor determination;
intended-purpose record;
territorial analysis;
AI-system definition analysis;
regulatory classification;
exception analysis;
transition analysis;
legal review.

Assurance

Assurance should verify:

source currency;
factual basis;
logical reasoning;
reviewer;
date;
change triggers.

15. Classification Evidence

Control Relationship

EUAI-CTRL-CLS-001

Evidence

Potential evidence:

Article 5 screening;
Article 6 assessment;
Annex I analysis;
Annex III analysis;
GPAI classification;
systemic-risk assessment;
technology classification;
intended purpose;
technical capabilities.

Assurance

The reviewer should verify that classification is supported by the current legal baseline and actual system characteristics.

16. Prohibited-Practice Evidence

Control Relationship

EUAI-CTRL-PROH-001 Evidence should demonstrate:

use-case description;
intended purpose;
system capabilities;
relevant Article 5 categories screened;
conditions considered;
exceptions considered;
decision;
reviewer;
date.

Potential additional evidence:

technical testing;
UX design;
model evaluation;
safety testing;
legal assessment.

17. Article 5 Evidence Standard

A prohibited-practice screening should not be treated as complete merely because a questionnaire was completed. For material use cases, evidence should allow an independent reviewer to understand:

What the system does
        ↓
What it is intended to do
        ↓
What it can reasonably do
        ↓
Which Article 5 category was considered
        ↓
Why the result was reached

18. Risk Evidence

Control Relationship

EUAI-CTRL-RISK-001 Evidence may include:

risk assessment;
risk register;
risk analysis;
risk evaluation;
treatment;
residual risk;
acceptance;
monitoring;
reassessment.

For high-risk AI systems, risk evidence should be maintained throughout the lifecycle. The Commission identifies risk assessment and mitigation systems as a core high-risk obligation.

19. Risk Evidence Quality

Risk evidence should identify:

risk owner;
assessment method;
assumptions;
evidence used;
probability;
impact;
treatment;
residual risk;
approval where applicable.

Risk conclusions without supporting analysis should be treated as weak evidence.

20. Data Governance Evidence

Control Relationship

EUAI-CTRL-DATA-001 Potential evidence:

data inventory;
provenance;
lineage;
quality assessment;
representativeness analysis;
bias assessment;
data-preparation records;
validation/testing datasets;
approvals;
data-change records.

The Commission identifies data quality and governance as part of the high-risk framework.

21. Technical Documentation Evidence

Control Relationship

EUAI-CTRL-DOC-001 Potential evidence:

technical documentation;
architecture;
model description;
system description;
development information;
data documentation;
testing;
validation;
cybersecurity;
human oversight;
limitations;
change history.

The Commission’s GPAI guidance likewise identifies technical documentation as a core GPAI obligation and describes documentation concerning architecture, training, data, testing, validation, computation, and energy consumption.

22. Technical Documentation Completeness

AIGO should assess:

Required Component
        ↓
Applicable?
        ↓
Documented?
        ↓
Current?
        ↓
Evidence Linked?
        ↓
Reviewed?

This permits partial documentation gaps to be identified without treating the entire documentation package as simply “complete” or “incomplete.”

23. Record-Keeping Evidence

Control Relationship

EUAI-CTRL-REC-001 Evidence may include:

logs;
retention records;
record inventories;
access logs;
log configurations;
integrity information;
retention actions;
audit trails.

High-risk systems are subject to logging requirements, and the Commission identifies logging as a core traceability requirement.

24. Logging Evidence

AIGO should distinguish:

Logging Configured

from:

Logging Operating

from:

Logs Retained

from:

Logs Reviewed

These are separate evidence claims.

25. Transparency Evidence

Control Relationships

EUAI-CTRL-TRANS-001
EUAI-CTRL-TRANS-002
EUAI-CTRL-TRANS-003
EUAI-CTRL-TRANS-004
EUAI-CTRL-TRANS-005
EUAI-CTRL-TRANS-006

Evidence may include:

user notices;
interface evidence;
machine-readable markings;
content samples;
label tests;
disclosure configuration;
editorial-review records;
publication records;
biometric/emotion-recognition notices.

The Commission’s final Article 50 guidelines apply from 2 August 2026 and address these transparency obligations.

26. Transparency Technical Evidence

For machine-readable AI-content marking, evidence should include:

marking method;
implementation;
detection test;
interoperability;
persistence test;
failure analysis;
configuration;
version.

The Commission and AI Board have recognized the transparency Code of Practice as an adequate voluntary implementation instrument for Articles 50(2), 50(4), and 50(5), while expressly noting that adherence is not conclusive evidence of compliance.

27. Human-Oversight Evidence

Control Relationship

EUAI-CTRL-HUM-001 Evidence may include:

assigned oversight role;
competence evidence;
instructions;
intervention procedures;
override tests;
intervention logs;
escalation records;
training.

The key question is not simply whether a human was “in the loop,” but whether the required oversight capability was actually available and operational.

28. Accuracy Evidence

Control Relationship

EUAI-CTRL-PERF-001 Evidence may include:

test methodology;
datasets;
validation results;
performance metrics;
acceptance criteria;
limitations;
monitoring results;
version-specific results.

Evidence should identify the tested system version.

29. Robustness Evidence

Control Relationship

EUAI-CTRL-ROB-001 Evidence may include:

stress tests;
failure-mode analysis;
robustness evaluation;
adversarial testing;
resilience tests;
degradation behavior;
remediation.

30. Cybersecurity Evidence

Control Relationship

EUAI-CTRL-SEC-001 Potential evidence:

threat model;
secure-design evidence;
vulnerability assessments;
penetration tests;
adversarial testing;
security controls;
incident results;
remediation;
update records.

31. Quality-Management Evidence

Control Relationship

EUAI-CTRL-QMS-001 Evidence may include:

policies;
procedures;
organizational roles;
design controls;
testing procedures;
data governance;
risk management;
corrective action;
management review.

AIGO evidence can support a statutory QMS but should not be represented as automatically satisfying every QMS requirement.

32. Conformity Evidence

Control Relationships

EUAI-CTRL-CONF-001
EUAI-CTRL-CONF-002
EUAI-CTRL-CONF-003
EUAI-CTRL-CONF-004
EUAI-CTRL-CONF-005
EUAI-CTRL-CONF-006

Potential evidence:

conformity applicability decision;
assessment plan;
conformity assessment;
notified-body information;
assessment reports;
findings;
corrective actions;
certificate;
declaration;
CE marking evidence;
registration.

33. Conformity Evidence Boundary

AIGO assurance evidence must distinguish:

AIGO Internal Assurance

from:

Statutory Conformity Assessment

AIGO should never convert an internal assurance report into a statutory conformity certificate.

34. Notified-Body Evidence

Where required, evidence should establish:

identity;
notification;
current scope;
relevant AI-system category;
applicable Annex XIV code where relevant;
assessment engagement;
assessment output;
certificate.

The 2026 amendment introduced Annex XIV designation codes and changed certain notified-body arrangements.

35. Declaration of Conformity Evidence

Evidence should include:

declaration;
AI-system identifier;
provider;
applicable legislation;
authorized signatory;
date;
version;
relationship to conformity assessment.

36. Registration Evidence

Potential evidence:

registration assessment;
submitted dataset;
submission;
registration identifier;
acknowledgment;
updates;
change history.

The internal AI inventory should not be used as a substitute for a statutory EU registration where registration is required.

37. GPAI Evidence Architecture

GPAI evidence should support distinct obligations:

GPAI Applicability
      ↓
Provider Status
      ↓
Technical Documentation
      ↓
Downstream Information
      ↓
Copyright Policy
      ↓
Training-Content Summary
      ↓
Systemic-Risk Assessment
      ↓
Safety / Security
      ↓
Incident
      ↓
AI Office Submission

The Commission states that GPAI providers must maintain technical documentation, provide downstream information, implement copyright policies, and publish training-content summaries. Providers subject to the systemic-risk requirements have additional duties.

38. GPAI Regulatory Submission Evidence

The Commission currently requires applicable GPAI providers to use the EU SEND platform for specified submissions, including systemic-risk notifications, reassessment requests, serious-incident reports, and certain safety/security or Code-of-Practice-related documents. AIGO should retain:

submission;
submission type;
model;
submitter;
date;
receipt/acknowledgment;
response;
follow-up.

39. GPAI Safety and Security Evidence

For systemic-risk GPAI models, evidence may include:

safety and security framework;
model report;
systemic-risk assessment;
evaluation;
red-team testing;
mitigation;
security testing;
incident records;
monitoring.

The Commission explicitly references Safety and Security Framework and Model Report submissions in its current EU SEND guidance.

40. AI Literacy Evidence

Control Relationship

EUAI-CTRL-LIT-001 Evidence may include:

literacy-needs assessment;
learning plan;
training records;
practical exercises;
role-specific guidance;
awareness activities;
competence evidence where used.

The amended Article 4 focuses on measures supporting AI literacy and does not impose a universal individual competency threshold.

41. Fundamental-Rights Evidence

Control Relationship

EUAI-CTRL-FR-001 Evidence may include:

Fundamental-Rights Impact Assessment;
affected-person analysis;
rights mapping;
bias assessment;
mitigation;
residual-risk assessment;
monitoring;
complaints;
remediation.

42. Rights and DPIA Evidence

Where Article 27 overlaps with a GDPR or law-enforcement data-protection impact assessment, AIGO should cross-reference, rather than duplicate unnecessarily, overlapping evidence. The amended Article 27 expressly supports cross-referencing the relevant sections of applicable data-protection impact assessments. AIGO should identify:

source DPIA;
relevant sections;
Article 27 requirement;
additional rights analysis;
remaining evidence gaps.

43. Complaint Evidence

Control Relationship

EUAI-CTRL-FR-003 Evidence should establish:

complaint received;
affected system;
issue;
rights claimed;
triage;
investigation;
decision;
communication;
remedy;
escalation.

44. Regulatory Complaint Evidence

Where a complaint reaches an external authority, evidence should additionally include:

authority;
complaint reference;
correspondence;
submissions;
findings;
corrective action;
closure.

Internal complaint closure should not be represented as regulatory closure.

45. Monitoring Evidence

Control Relationships

EUAI-CTRL-MON-001
EUAI-CTRL-MON-002

Monitoring evidence may include:

performance reports;
risk indicators;
control metrics;
incident trends;
transparency monitoring;
post-market information;
system changes;
user complaints.

46. Incident Evidence

Control Relationships

EUAI-CTRL-INC-001
EUAI-CTRL-INC-002
EUAI-CTRL-INC-003
EUAI-CTRL-INC-004
EUAI-CTRL-INC-005

Evidence may include:

detection;
event record;
severity;
affected system;
impact;
investigation;
containment;
notification analysis;
regulatory report;
corrective action;
verification.

47. Change Evidence

Control Relationships

EUAI-CTRL-CHG-001
EUAI-CTRL-CHG-002
EUAI-CTRL-CHG-003
EUAI-CTRL-CHG-004
EUAI-CTRL-CHG-005

Evidence should demonstrate:

change request;
reason;
impact assessment;
classification impact;
risk impact;
conformity impact;
evidence impact;
approval;
testing;
implementation;
verification.

48. Significant-Change Evidence

For transitional high-risk systems, evidence should demonstrate:

Original System
        ↓
Original Market Date
        ↓
Change
        ↓
Design Impact
        ↓
Significant-Change Analysis
        ↓
Legal Consequence
        ↓
Decision

The current Article 111 transition framework makes this particularly important for high-risk systems placed on the market or put into service before the applicable Chapter III date.

49. Regulatory-Authority Evidence

Control Relationships

EUAI-CTRL-AUTH-001
EUAI-CTRL-AUTH-002
EUAI-CTRL-AUTH-003
EUAI-CTRL-AUTH-004
EUAI-CTRL-AUTH-005

Evidence may include:

authority identification;
request;
response;
submission;
inspection;
investigation;
commitment;
finding;
corrective action;
fine;
closure.

50. Evidence Preservation During Investigations

When an investigation occurs, AIGO should activate a preservation process. Potential evidence controls:

Regulatory Request
      ↓
Preservation Hold
      ↓
Evidence Identification
      ↓
Integrity Protection
      ↓
Access Control
      ↓
Chain of Custody
      ↓
Submission

51. Evidence Chain of Custody

Where evidence may be used in a regulatory investigation, the record should capture:

evidence ID;
source;
collector;
collection date;
method;
original location;
hash or integrity control where appropriate;
transformations;
transfers;
recipient;
submission.

The required depth depends on the legal and technical context.

52. Regulatory Commitment Evidence

Where an AI Office or other competent authority establishes a regulatory commitment, evidence should include:

commitment;
authority;
legal basis;
owner;
milestone;
completion;
verification;
correspondence.

The amended framework provides for binding commitments in specified AI Office proceedings.

53. Enforcement Evidence

Evidence supporting an enforcement event may include:

authority decision;
finding;
legal provision;
penalty;
corrective measures;
response;
remediation;
assurance.

A penalty-payment record should not be treated as evidence that the underlying compliance issue was resolved.

54. Assurance Governance Principle

Assurance should answer:

Can the organization reasonably demonstrate that its AIGO control framework is designed, implemented, evidenced, monitored, and functioning as intended for the mapped requirement?

It should not answer:

Is the organization legally compliant in all respects?

The latter may require legal, regulatory, conformity, and factual determinations beyond AIGO assurance.

55. Assurance Types

AIGO should recognize:

DESIGN_ASSURANCE
IMPLEMENTATION_ASSURANCE
OPERATING_EFFECTIVENESS
TECHNICAL_ASSURANCE
LEGAL_COMPLIANCE_REVIEW
EVIDENCE_ASSURANCE
CONFORMITY_READINESS_ASSURANCE
REGULATORY_READINESS_ASSURANCE
INDEPENDENT_ASSURANCE

Different assurance types answer different questions.

56. Design Assurance

Design assurance evaluates:

control objective;
applicability;
control design;
ownership;
evidence requirements;
monitoring;
dependencies.

It does not demonstrate that the control operated.

57. Implementation Assurance

Implementation assurance evaluates whether the designed control has actually been deployed. Examples:

configuration;
workflow;
documentation;
system settings;
assigned roles;
evidence repository.

58. Operating-Effectiveness Assurance

Operating-effectiveness assurance evaluates whether a control:

operated;
operated consistently;
produced expected outputs;
was performed by the correct owner;
generated evidence;
handled exceptions.

Sampling may be used where appropriate.

59. Technical Assurance

Technical assurance may examine:

model performance;
testing;
robustness;
cybersecurity;
content marking;
logs;
model documentation;
data.

Technical assurance should use qualified personnel.

60. Legal / Compliance Review

Legal/compliance review may evaluate:

legal interpretation;
applicability;
exception;
regulatory scope;
amendment impact.

It should be distinguished from operational control assurance.

61. Evidence Assurance

Evidence assurance should evaluate:

authenticity;
completeness;
integrity;
currency;
traceability;
consistency.

62. Conformity Readiness Assurance

AIGO may provide a readiness review covering:

documentation;
controls;
risk management;
evidence;
QMS;
conformity pathway.

It should be explicitly labelled: CONFORMITY_READINESS_ASSURANCE unless it is a statutory conformity assessment.

63. Regulatory-Readiness Assurance

Regulatory-readiness assurance evaluates whether the organization can respond effectively to:

information requests;
investigations;
inspections;
complaints;
submissions;
enforcement findings.

64. Independent Assurance

Independent assurance should be used where:

risk is high;
rights impact is material;
regulatory significance is high;
systemic risk exists;
control independence is required.

Independence criteria should be defined by the organization’s assurance framework.

65. Assurance Planning

Each assurance activity should have:

Field	Purpose
Assurance ID	Unique identifier
Scope	What is reviewed
Requirement	Why review is performed
Control	Control being evaluated
System	Affected AI system
Criteria	Assessment criteria
Reviewer	Responsible reviewer
Independence	Level of independence
Method	Review / test / interview / sample
Period	Evidence period
Outcome	Result
Findings	Exceptions
Actions	Remediation

66. Assurance Criteria

Criteria should come from:

binding legal text;
applicable official implementation material;
approved AIGO controls;
organizational policies;
technical requirements;
conformity requirements where relevant.

The source for each criterion should be explicit.

67. Assurance Testing

Potential methods:

DOCUMENT_REVIEW
INTERVIEW
OBSERVATION
CONFIGURATION_REVIEW
TECHNICAL_TEST
DATA_TEST
SAMPLING
REPERFORMANCE
TRACEABILITY_TEST
RECORD_INSPECTION
REGULATORY_SUBMISSION_REVIEW

The method should match the assertion being tested.

68. Sampling

Sampling may be used for recurring evidence or control operations. The assurance record should state:

population;
sampling approach;
sample size;
sample selection;
exceptions;
conclusion.

Sampling should not be used where complete evidence review is necessary.

69. Assurance Findings

Findings should distinguish:

OBSERVATION
MINOR_GAP
MAJOR_GAP
CRITICAL_GAP
NONCONFORMITY
REGULATORY_FINDING

“Nonconformity” should be used carefully and should not imply a formal statutory finding unless one exists.

70. Assurance Finding Lifecycle

Finding
  ↓
Validation
  ↓
Owner
  ↓
Root Cause
  ↓
Corrective Action
  ↓
Due Date
  ↓
Evidence
  ↓
Verification
  ↓
Closure

71. Corrective-Action Evidence

Evidence should demonstrate:

action completed;
responsible owner;
implementation;
testing;
validation;
effectiveness;
closure approval.

A status change to “complete” is not itself sufficient evidence.

72. Assurance and Continuous Improvement

The assurance loop is:

Assurance
   ↓
Finding
   ↓
Root Cause
   ↓
Improvement
   ↓
Control Change
   ↓
Reassessment
   ↓
Assurance

This makes assurance an improvement mechanism rather than a one-time audit exercise.

73. Assurance and Management Review

Management review should receive:

critical findings;
overdue actions;
evidence gaps;
recurring findings;
regulatory issues;
systemic-risk findings;
material rights findings;
conformity-readiness issues.

74. Evidence and Management Review

Management review should have evidence that supports:

current control coverage;
evidence coverage;
assurance status;
regulatory status;
incidents;
changes;
upcoming deadlines.

75. Evidence and AI Act Timeline

Evidence should carry applicability context. For example:

Legal Application Date:
2 December 2027

Evidence Date:
14 August 2026

Legal Status:
FUTURE_APPLICABLE

AIGO Status:
IMPLEMENTED_EARLY

This prevents future-readiness evidence from being mistaken for evidence of a currently applicable legal obligation. The Commission currently confirms the revised 2 December 2027 and 2 August 2028 high-risk application dates.

76. Evidence and Transitional Rules

Evidence for a transitional system should contain:

original market date;
transitional legal basis;
system version;
current state;
significant-change analysis;
deadline;
implementation progress.

This is especially important where the legal outcome depends on whether the system has undergone a significant design change.

77. Evidence and Article 50 Transition

For certain pre-existing synthetic-content systems, AIGO should retain:

market-placement date;
transition eligibility;
content capability;
Article 50(2) implementation;
deadline;
technical marking evidence.

The current legal and Commission framework identifies 2 December 2026 as the relevant transition endpoint for certain systems placed on the market before 2 August 2026.

78. Evidence and GPAI Enforcement

As of 2 August 2026, the Commission’s enforcement powers concerning GPAI provider obligations apply. GPAI evidence should therefore be treated as a current enforcement-readiness matter.

79. Evidence and EU SEND

Where EU SEND submission is required, the submission record should be treated as authoritative regulatory evidence. AIGO should retain:

Document
Submission
Receipt
Correspondence
Revision
Response

The Commission states that EU SEND is designed to provide confidentiality, integrity, and authenticity for GPAI submissions.

80. Regulatory Evidence and Confidentiality

Evidence may contain:

trade secrets;
model architecture;
security information;
personal data;
legal advice;
business-sensitive information.

AIGO should use:

role-based access;
classification;
encryption;
restricted repositories;
legal holds;
controlled disclosure.

81. Evidence Minimization

Evidence retention does not mean retaining unlimited information. The organization should retain what is:

legally required;
necessary to demonstrate governance;
necessary for assurance;
necessary for investigation;
proportionate.

Data-protection requirements remain applicable.

82. Evidence Retention

Retention should consider:

AI Act requirements;
applicable sectoral requirements;
data-protection law;
litigation holds;
regulatory investigations;
contractual obligations;
organizational retention policy.

AIGO should not define a universal retention period for every evidence category.

83. Evidence Disposal

Disposal should be controlled. Potential evidence:

disposal authorization;
retention expiry;
destruction method;
repository;
date;
responsible person.

A regulatory or legal hold should prevent ordinary disposal.

84. Evidence and Historical State

Historical evidence should remain associated with:

historical system version;
historical legal baseline;
historical control;
historical decision.

A later legal amendment should not retroactively rewrite historical evidence.

85. Evidence and Regulatory Amendments

When law changes:

Amendment
  ↓
Applicability Review
  ↓
Evidence Requirement Change
  ↓
New Evidence
  ↓
Historical Evidence Preserved

The organization should preserve the distinction between past and current requirements.

86. Evidence and Source Currency

Every legal-source evidence record should identify:

source;
version;
date accessed;
amendment;
applicability;
reviewer.

This is especially important for evolving AI regulation.

87. Assurance Source Currency

Assurance criteria should be verified against current legal and official sources before each assurance cycle. The Commission’s high-risk classification guidance remains subject to regulatory development, while the final transparency guidelines were adopted in July 2026. This difference in source maturity should be reflected in assurance criteria.

88. Evidence and Official Guidance

Official guidance can support evidence and interpretation, but AIGO must distinguish:

Binding Legal Requirement

from:

Official Guidance

from:

Voluntary Code of Practice

The distinction should be preserved in evidence metadata.

89. Code-of-Practice Evidence

Where an organization relies on an EU AI Act Code of Practice, evidence should include:

code version;
signatory status where relevant;
applicable measures;
implementation;
mapping;
deviations;
alternative measures;
assurance.

The Commission states that the transparency Code of Practice is voluntary and adequate for the identified Article 50 obligations, but adherence is not conclusive evidence of compliance.

90. Assurance of Code Implementation

Assurance may test:

whether the organization actually implemented the Code measures it claims;
whether the relevant scope is correct;
whether deviations are controlled;
whether evidence exists;
whether alternative measures are documented.

91. Evidence of Regulatory Monitoring

The regulatory-change control should retain:

monitored source;
date;
change identified;
legal impact;
affected mappings;
affected controls;
decisions;
implementation evidence.

92. Regulatory-Change Assurance

Assurance should test whether:

regulatory changes are identified;
relevant changes reach owners;
affected controls are updated;
timeline changes propagate;
evidence is updated;
obsolete documents are controlled.

93. AI Act Evidence Coverage

A future coverage model may calculate:

Applicable Requirements
        ↓
Mapped Requirements
        ↓
Controlled Requirements
        ↓
Evidence-Required Requirements
        ↓
Evidence Available
        ↓
Evidence Validated
        ↓
Evidence Assured

The output should distinguish coverage from legal compliance.

94. Evidence Coverage Categories

AIGO may report:

NO_EVIDENCE
PARTIAL_EVIDENCE
EVIDENCE_AVAILABLE
EVIDENCE_VALIDATED
EVIDENCE_CURRENT
EVIDENCE_ASSURED

95. Evidence Gaps

Potential findings include:

EVIDENCE_REQUIRED
EVIDENCE_MISSING
EVIDENCE_INCOMPLETE
EVIDENCE_STALE
EVIDENCE_UNATTRIBUTED
EVIDENCE_INCONSISTENT
EVIDENCE_INTEGRITY_UNVERIFIED
EVIDENCE_NOT_TRACEABLE
EVIDENCE_NOT_REVIEWED

96. Critical Evidence Gaps

Potential critical evidence gaps include:

no evidence for prohibited-practice screening;
no evidence for required high-risk risk management;
no technical documentation for an applicable high-risk system;
no required conformity evidence;
no GPAI systemic-risk documentation;
no required regulatory submission evidence;
no evidence of mandatory rights assessment;
material evidence destroyed during regulatory proceedings.

97. Assurance Coverage

AIGO should report:

Requirements
   ↓
Controls
   ↓
Evidence
   ↓
Assurance

Possible assurance coverage statuses:

NOT_ASSURED
PLANNED
ASSURED
PARTIALLY_ASSURED
EXCEPTION
REQUIRES_REVIEW

98. Assurance Prioritization

Assurance priority should consider:

legal criticality;
safety;
fundamental-rights impact;
system scale;
systemic risk;
control criticality;
incident history;
regulatory attention;
evidence weaknesses.

99. High-Risk Assurance

For high-risk AI, assurance may prioritize:

classification;
risk management;
data governance;
technical documentation;
human oversight;
accuracy;
robustness;
cybersecurity;
conformity;
monitoring.

The Commission identifies these as core high-risk obligations.

100. GPAI Assurance

For GPAI providers, assurance may prioritize:

model classification;
technical documentation;
downstream information;
copyright policy;
training summary;
systemic-risk determination;
safety/security;
incident management;
regulatory submissions.

The Commission’s current guidance identifies these as key GPAI provider obligations and submission areas.

101. Transparency Assurance

For Article 50, assurance may prioritize:

applicability;
direct interaction disclosure;
machine-readable marking;
deepfake disclosure;
public-interest text disclosure;
biometric/emotion notification;
testing;
evidence.

The Commission’s final transparency guidance was adopted in July 2026 and applies from 2 August 2026.

102. Rights Assurance

Rights assurance may prioritize:

affected-person identification;
Article 27 applicability;
fundamental-rights impact;
bias;
human oversight;
complaints;
remediation;
evidence.

103. Regulatory-Readiness Assurance

Regulatory-readiness assurance should evaluate:

authority register;
regulatory monitoring;
submission controls;
deadlines;
evidence retrieval;
incident escalation;
investigation readiness.

104. Assurance Independence

The organization should define independence requirements. Potential levels:

SELF_ASSESSMENT
PEER_REVIEW
SECOND_LINE_REVIEW
INDEPENDENT_INTERNAL_ASSURANCE
EXTERNAL_ASSURANCE
STATUTORY_ASSESSMENT

The last category must only be used when the activity actually has statutory status.

105. Assurance Conflicts of Interest

Where possible, the assurance reviewer should not be the person solely responsible for operating the control being assessed. Material assurance activities should document independence considerations.

106. Assurance Evidence

The assurance file should contain:

scope;
criteria;
source;
evidence reviewed;
methodology;
tests;
findings;
conclusion;
reviewer;
date;
approval.

107. Assurance Conclusion Types

AIGO may use:

EFFECTIVE
EFFECTIVE_WITH_OBSERVATIONS
PARTIALLY_EFFECTIVE
INEFFECTIVE
INSUFFICIENT_EVIDENCE
NOT_ASSESSED

These are AIGO assurance conclusions. They are not legal compliance declarations.

108. Assurance Findings and Corrective Action

Every major or critical assurance finding should have:

owner;
action;
deadline;
evidence requirement;
verification;
closure.

109. Assurance Follow-Up

Follow-up should verify:

Finding
 ↓
Action
 ↓
Evidence
 ↓
Retest
 ↓
Effectiveness
 ↓
Closure

Closure should not occur solely because an action was marked completed.

110. Management Assurance Dashboard

Management may receive:

Metric	Meaning
Applicable Requirements	Scope
Control Coverage	Design coverage
Evidence Coverage	Demonstrability
Assurance Coverage	Validation
Critical Findings	Risk
Overdue Actions	Remediation
Regulatory Events	External exposure
Upcoming Deadlines	Timing
Systemic-Risk Models	Elevated exposure
Rights Findings	Rights exposure

These are governance metrics rather than statutory compliance percentages.

111. Evidence and Repository Health

The Repository Health Checker should inspect:

missing evidence;
broken references;
stale evidence;
duplicate records;
missing owners;
inconsistent system versions;
orphaned assessments;
orphaned assurance records.

112. Evidence and Framework Consistency

The Framework Consistency Checker should identify contradictions among:

AI System Profile;
classification;
risk;
controls;
assessments;
technical documentation;
approvals;
monitoring;
incidents;
changes;
assurance.

113. Evidence and Reference Validation

The Reference Validator should verify that:

legal sources resolve;
AIGO control IDs resolve;
system IDs resolve;
evidence IDs resolve;
assessment IDs resolve;
assurance IDs resolve.

114. Evidence and Traceability Validation

The Traceability Validator should detect broken chains such as:

Requirement
   ↓
Control
   X
Evidence

or:

Incident
   ↓
Corrective Action
   X
Verification

115. Evidence and Schema Validation

The Schema Validator should verify that evidence records conform to:

Evidence Schema;
related AI System Schema;
Risk Schema;
Control Schema;
Assessment Schema;
Assurance Schema;
Incident Schema;
Change Schema.

116. Regulatory Evidence Pack

For a material AI system, AIGO should be capable of producing a controlled evidence pack containing:

AI System
Classification
Applicability
Risk
Controls
Assessments
Approvals
Technical Documentation
Logs
Monitoring
Incidents
Changes
Conformity
Registration
Rights
Transparency
GPAI
AI Literacy
Assurance
Improvement

The pack should reference authoritative records rather than creating uncontrolled duplicates.

117. Evidence-Pack Version

Every evidence pack should identify:

pack ID;
generated date;
legal baseline;
AIGO version;
system version;
included evidence versions;
exclusions;
reviewer.

118. Evidence-Pack Integrity

Where a pack may be submitted externally, the organization should preserve:

generation event;
content manifest;
evidence IDs;
file integrity;
access history;
submission record.

119. Regulatory Submission Evidence Pack

For regulatory submissions, AIGO should maintain:

Submission Requirement
      ↓
Required Documents
      ↓
Evidence Selection
      ↓
Legal Review
      ↓
Approval
      ↓
Submission
      ↓
Receipt
      ↓
Correspondence

This applies particularly to GPAI EU SEND submissions where relevant.

120. Evidence and Corrective Action

When evidence reveals a gap:

Evidence Gap
    ↓
Finding
    ↓
Risk
    ↓
Corrective Action
    ↓
Change
    ↓
New Evidence
    ↓
Assurance

121. Evidence and Continual Improvement

The evidence model should support organizational learning:

recurring failures;
evidence-quality trends;
control gaps;
assurance findings;
regulatory developments;
incident patterns.

122. Evidence Retention and Retirement

When an AI system is retired, evidence should not automatically be deleted. AIGO should determine:

legal retention;
regulatory retention;
assurance retention;
incident retention;
contractual retention.

Historical evidence should remain linked to the retired system.

123. Retirement Evidence

Potential records:

retirement decision;
final system version;
final risk state;
final monitoring;
incidents;
conformity;
registration;
authority communication;
evidence-retention decision.

124. Historical Assurance

Historical assurance should remain associated with:

historical system;
historical control;
historical legal baseline;
historical evidence.

Later assurance should not overwrite historical conclusions.

125. Evidence and Legal Amendments

When the legal framework changes:

New Law
  ↓
New Requirement
  ↓
New Evidence Requirement
  ↓
New Control
  ↓
New Evidence
  ↓
Assurance

Historical evidence remains valid for the period to which it originally related, subject to the applicable legal context.

126. Evidence and Current Legal Baseline

This mapping uses:

Regulation (EU) 2024/1689
+
Regulation (EU) 2026/1744

as its current legal baseline. The 2026 amendment is therefore part of the evidence-assurance assessment criteria.

127. Current Timeline Evidence

The central timeline source is: 11-AIGO-EU-AI-Act-Applicability-and-Timeline-v0.1.md Evidence records should identify whether the applicable requirement was:

CURRENTLY_APPLICABLE
FUTURE_APPLICABLE
TRANSITIONAL
IMPLEMENTED_EARLY
HISTORICAL

128. Future Requirement Evidence

Evidence collected before legal application should be labelled clearly. Example:

Requirement:
Annex III high-risk obligations

Legal Application:
2 December 2027

AIGO Implementation:
14 August 2026

Status:
IMPLEMENTED_EARLY

This avoids misleading compliance claims.

129. Evidence and Annual Regulatory Review

The Commission’s 2026 report on Article 5 and Annex III demonstrates ongoing annual review of prohibited practices and high-risk use cases. AIGO should retain evidence of:

annual regulatory review;
affected system analysis;
mapping update;
control impact;
management review.

130. Assurance and Regulatory Change

Assurance should test whether regulatory reviews actually produce changes where required. Recommended test:

Regulatory Change
   ↓
Impact Assessment
   ↓
Control Update
   ↓
Evidence Update

A missing downstream update is a governance finding.

131. Assurance and Official Guidance

Where official guidance is not legally binding, assurance criteria should identify it as implementation guidance rather than legal text. For high-risk classification, current Commission guidance remains identified as draft/non-binding in the current Commission materials. For transparency, final Commission guidelines were adopted in July 2026. This difference should be reflected in the source metadata.

132. Assurance and Code of Practice

A Code of Practice may support implementation but should not be treated as identical to binding law. Assurance should evaluate:

which Code measures were adopted;
whether they are implemented;
whether alternative measures are used;
whether evidence supports the claim.

The Commission expressly states that adherence to the transparency Code is not conclusive evidence of compliance.

133. Evidence and External Assessment

When an external auditor, notified body, assessor, or authority requests evidence: AIGO should provide the evidence through controlled access and preserve the interaction record.

134. Evidence Disclosure Control

Control Name: EU AI Act Evidence Disclosure Governance The control should determine:

requested evidence;
authority;
legal basis;
confidentiality;
personal-data implications;
trade secrets;
approved disclosure;
submission channel;
evidence of disclosure.

135. Evidence Redaction

Where lawful and necessary, evidence may require controlled redaction. The record should preserve:

original evidence;
redacted version;
reason;
authority request;
reviewer;
approval.

Redaction should not destroy the organization’s ability to reconstruct what was originally disclosed.

136. Assurance Report Integrity

Assurance reports should be controlled evidence. Each should have:

report ID;
scope;
date;
reviewer;
version;
conclusion;
findings;
approval.

137. Evidence Control Matrix

Evidence Domain	Primary Controls	Assurance
Applicability	APP controls	Legal / governance review
Classification	CLS	Classification assurance
Prohibited AI	PROH	Legal / technical assurance
Risk	RISK	Risk assurance
Data	DATA	Data assurance
Documentation	DOC	Documentation assurance
Records / Logs	REC	Technical / operational assurance
Transparency	TRANS	Technical / compliance assurance
Human Oversight	HUM	Operational / competence assurance
Accuracy	PERF	Technical assurance
Robustness	ROB	Technical assurance
Security	SEC	Security assurance
Quality	QMS	QMS assurance
Conformity	CONF	Conformity readiness / statutory assessment
Registration	REG	Registration assurance
GPAI	GPAI	GPAI assurance
Literacy	LIT	Competence / governance assurance
Rights	FR	Rights assurance
Monitoring	MON	Operational assurance
Incident	INC	Incident assurance
Change	CHG	Change assurance
Authority	AUTH	Regulatory readiness assurance
Improvement	IMP	Effectiveness assurance
Retirement	RET	Lifecycle assurance

138. Evidence Coverage Model

AIGO should ultimately support:

Requirement
   ↓
Applicable?
   ↓
Control
   ↓
Evidence Required
   ↓
Evidence Available
   ↓
Evidence Validated
   ↓
Evidence Current
   ↓
Assured

Potential final states:

FULL
PARTIAL
GAP
NOT_APPLICABLE
PENDING

139. Assurance Coverage Model

Applicable Requirement
        ↓
Control
        ↓
Evidence
        ↓
Assurance Plan
        ↓
Assurance Performed
        ↓
Finding
        ↓
Verification

140. Evidence and Assurance Metrics

Potential management metrics:

Metric	Purpose
Requirements With Evidence	Evidence coverage
Evidence Validated	Quality
Evidence Stale	Currency risk
Controls With Assurance	Assurance coverage
Critical Findings	Risk
Overdue Assurance Actions	Remediation
Regulatory Evidence Requests	External activity
Regulatory Evidence Response Time	Responsiveness
Repeated Findings	Control maturity
Evidence Integrity Issues	Repository risk

141. Critical Evidence and Assurance Threshold

AIGO should define a rule that certain critical governance controls cannot be treated as assured where material evidence is absent. Potential critical areas include:

prohibited practices;
high-risk risk management;
human oversight;
cybersecurity;
systemic-risk GPAI;
fundamental rights;
regulatory submissions;
conformity.

142. Evidence and Control Coverage Validator

The Control Coverage Validator should consume this mapping to determine:

which controls are applicable;
which are critical;
which are implemented;
which have evidence;
which have assurance.

143. Evidence Coverage Validator

The Evidence Coverage Validator should consume this mapping to determine:

evidence requirement;
evidence ID;
current status;
system version;
completeness;
validation;
review.

144. Traceability Validator

The Traceability Validator should verify:

Legal Requirement
       ↓
Control
       ↓
Assessment
       ↓
Evidence
       ↓
Monitoring
       ↓
Assurance
       ↓
Improvement

Broken chains should produce findings.

145. Framework Consistency Checker

The checker should detect:

inconsistent legal references;
mismatched system IDs;
conflicting versions;
contradictory classification;
conflicting evidence status;
stale control relationships;
inconsistent assurance conclusions.

146. Document Integrity Checker

The checker should verify:

file existence;
file readability;
required sections;
metadata;
version;
references;
links;
document status.

147. Repository Health Checker

The repository health layer should aggregate:

Evidence Coverage
+
Control Coverage
+
Traceability
+
Assurance
+
Regulatory Currency

Potential status:

HEALTHY
HEALTHY_WITH_WARNINGS
DEGRADED
UNHEALTHY
NOT_READY

148. Evidence Findings

Potential findings:

EVIDENCE_REQUIRED
EVIDENCE_MISSING
EVIDENCE_INCOMPLETE
EVIDENCE_STALE
EVIDENCE_INVALID
EVIDENCE_UNATTRIBUTED
EVIDENCE_NOT_TRACEABLE
EVIDENCE_INCONSISTENT
EVIDENCE_INTEGRITY_GAP
EVIDENCE_RETENTION_GAP
EVIDENCE_DISCLOSURE_GAP

149. Assurance Findings

Potential findings:

ASSURANCE_NOT_PLANNED
ASSURANCE_OVERDUE
ASSURANCE_SCOPE_GAP
ASSURANCE_EVIDENCE_GAP
ASSURANCE_CONTROL_GAP
ASSURANCE_DESIGN_GAP
ASSURANCE_EFFECTIVENESS_GAP
ASSURANCE_INDEPENDENCE_GAP
ASSURANCE_FOLLOWUP_OVERDUE

150. Critical Findings

Potential critical evidence/assurance findings:

statutory requirement has no identifiable evidence;
critical control has no operating evidence;
evidence required by a regulator cannot be produced;
evidence integrity is compromised;
material regulatory submission cannot be verified;
critical assurance finding remains unresolved;
conformity evidence cannot be linked to the correct system version;
systemic-risk GPAI safety/security evidence is materially incomplete.

151. Evidence and Risk Acceptance

Evidence gaps should not automatically be accepted as ordinary residual risk when the evidence is required by law or needed to demonstrate a mandatory control. The organization should distinguish:

Residual Operational Risk

from:

Missing Required Evidence

The second can create an independent governance problem.

152. Assurance and Risk Acceptance

An assurance reviewer may identify that risk acceptance was used incorrectly. For example:

Legal Prohibition
+
Risk Acceptance
=
INVALID

Risk acceptance cannot override an applicable prohibition.

153. Evidence and Exceptions

Evidence for an exception should include:

legal basis;
applicability;
approving authority;
conditions;
expiry;
compensating controls;
evidence;
review.

Legal exceptions should be distinguished from AIGO policy exceptions.

154. Assurance of Exceptions

Assurance should test:

whether the exception actually applies;
whether conditions are satisfied;
whether expiry is controlled;
whether compensating controls exist.

155. Evidence and Third Parties

Third-party evidence should identify:

provider;
source;
contract;
system;
date;
version;
validation;
responsibility.

Supplier documentation should not automatically be accepted without appropriate review.

156. Assurance of Third-Party Evidence

Assurance may sample:

supplier documentation;
certificates;
provider claims;
security reports;
testing;
change notices.

157. Evidence and GPAI Downstream Providers

Where a GPAI provider supplies downstream documentation, the downstream organization should preserve:

received package;
model version;
date received;
provider;
changes;
review;
integration impact.

The Commission identifies downstream-provider documentation as a distinct GPAI obligation.

158. Assurance of GPAI Downstream Information

The downstream organization may assess:

completeness;
usability;
currency;
consistency;
known limitations;
change notifications.

159. Evidence and Transparency Code

Where the transparency Code of Practice is adopted, evidence should identify:

adopted measures;
implementation;
version;
exclusions;
alternative measures.

This supports traceability without treating the Code itself as binding law.

160. Evidence and High-Risk Guidelines

Where the organization’s classification decision relies on Commission guidance, evidence should label it as: OFFICIAL_NON_BINDING_GUIDANCE until a legally binding source establishes otherwise. Current Commission high-risk classification guidance was still described as draft in the latest available Commission publication during this mapping cycle.

161. Assurance Source Hierarchy

Assurance criteria should follow:

Binding Law
    ↓
Applicable Delegated / Implementing Acts
    ↓
Applicable Conformity / Regulatory Instruments
    ↓
Official Guidance
    ↓
Approved AIGO Controls
    ↓
Organizational Procedures

The lower layer cannot override the higher layer.

162. Assurance Planning by Risk

The assurance programme should allocate more resources to:

prohibited practices;
high-risk AI;
systemic-risk GPAI;
fundamental-rights impacts;
safety;
cybersecurity;
material conformity;
regulatory submissions.

163. Assurance and Materiality

Materiality factors may include:

potential harm;
number of affected persons;
legal significance;
regulatory significance;
financial significance;
safety significance;
rights significance;
likelihood.

164. Assurance and Lifecycle

Assurance should occur at multiple stages:

Lifecycle	Assurance
Planning	Applicability
Design	Controls / risk
Development	Technical
Testing	Validation
Approval	Readiness
Deployment	Pre-production
Operation	Operating effectiveness
Monitoring	Performance
Change	Impact
Incident	Corrective action
Retirement	Evidence / retention

165. Assurance Release Gate

Before an AI system is released into an assurance-relevant operational state, the organization should verify:

required evidence exists;
critical gaps are addressed;
required assurance is complete;
unresolved issues are formally governed;
applicable legal status is clear.

166. Evidence and Deployment Approval

The approval process may require:

Applicable Requirement
      ↓
Control Coverage
      ↓
Evidence Coverage
      ↓
Assurance
      ↓
Residual Gaps
      ↓
Approval Decision

Approval authorities should not ignore mandatory legal requirements merely because overall risk is considered acceptable.

167. Evidence and Post-Market Monitoring

Evidence should be continuously generated during operation. Potential sources:

model performance;
user feedback;
incidents;
complaints;
security events;
rights impacts;
provider notifications.

This is particularly important for systems subject to post-market monitoring.

168. Assurance and Post-Market Monitoring

Assurance may test:

monitoring design;
monitoring execution;
threshold accuracy;
escalation;
corrective action.

169. Regulatory Evidence Pack Readiness

An organization should periodically test whether it can retrieve the evidence needed for a material regulatory inquiry. A readiness test may ask:

Can the organization identify:
- the current AI system version?
- the applicable legal classification?
- the risk assessment?
- the controls?
- the evidence?
- the approvals?
- the incidents?
- the changes?
- the assurance?

170. Regulatory Evidence Retrieval Test

A future AIGO assurance procedure may use:

Request
  ↓
Retrieve
  ↓
Validate
  ↓
Assemble
  ↓
Review
  ↓
Submit / Demonstrate

The retrieval exercise itself may generate assurance evidence.

171. Evidence Response Time

Organizations may monitor:

evidence retrieval time;
regulatory response time;
evidence validation time;
approval time.

These are management indicators. They are not statutory deadlines unless specifically linked to a legal requirement.

172. Evidence and Management Review

Management should review:

evidence gaps;
assurance gaps;
regulatory requests;
recurring evidence failures;
system-version inconsistencies;
retention issues.

173. Evidence and Continuous Improvement

Evidence quality should improve through:

metadata standards;
central identifiers;
controlled repositories;
automated validation;
evidence templates;
clear ownership;
periodic assurance.

174. Machine-Readable Evidence Relationship

A future machine-readable mapping may represent:

{
  "mappingId": "EUAI-EVD-RISK-001",
  "legalSource": {
    "instrument": "Regulation (EU) 2024/1689",
    "article": "9"
  },
  "controlId": "EUAI-CTRL-RISK-001",
  "evidenceTypes": [
    "RISK_ASSESSMENT",
    "RISK_REGISTER",
    "RISK_TREATMENT",
    "RESIDUAL_RISK_REVIEW"
  ],
  "assuranceTypes": [
    "DESIGN_ASSURANCE",
    "OPERATING_EFFECTIVENESS"
  ]
}

The future schema should remain aligned with the existing AIGO Evidence and Assurance Schemas.

175. Evidence Registry Integration

The evidence registry should support relationships:

Evidence ID
  ↓
AI System ID
  ↓
Requirement ID
  ↓
Control ID
  ↓
Assessment ID
  ↓
Assurance ID

This provides machine-checkable traceability.

176. Assurance Registry Integration

The assurance registry should support:

Assurance ID
  ↓
Requirement ID
  ↓
Control ID
  ↓
Evidence Set
  ↓
Assurance Criteria
  ↓
Finding
  ↓
Corrective Action

177. Evidence and Assurance Versioning

When a control changes:

Control v1
 ↓
Evidence v1
 ↓
Assurance v1

Control v2
 ↓
New Evidence Requirement
 ↓
Assurance v2

Historical evidence should remain linked to the earlier control version.

178. Evidence and Regulatory Baseline Versioning

An evidence record should optionally identify:

legalBaselineVersion
aigoFrameworkVersion
systemVersion
controlVersion

This is especially important for historical audits and regulatory investigations.

179. Evidence and Current Date

Because AI regulation changes over time, evidence should preserve the date on which the legal applicability determination was made. This prevents an organization from applying today’s legal interpretation retrospectively without a documented basis.

180. Evidence Review Frequency

Evidence should be reviewed:

according to control frequency;
after material change;
after regulatory amendment;
before assurance;
before regulatory submission;
when evidence becomes stale.

181. Evidence Revalidation

Revalidation should determine:

still applicable?
still current?
still attributable?
still complete?
still aligned to the system version?
still aligned to the legal baseline?

182. Evidence Supersession

When new evidence replaces older evidence:

Evidence v1
    ↓
Superseded
    ↓
Evidence v2

The historical evidence should normally remain retained if required.

183. Evidence Correction

If an evidence record contains an error:

do not silently overwrite where historical integrity matters;
create corrected version;
record correction reason;
preserve previous version where appropriate;
reassess linked assurance.

184. Assurance Reperformance

Assurance should be repeated where:

material evidence changes;
control changes;
legal requirement changes;
material incident occurs;
assurance finding remains unresolved.

185. Assurance and Regulatory Amendments

A legal amendment should trigger assessment of:

Criteria
  ↓
Controls
  ↓
Evidence
  ↓
Assurance Programme

The assurance plan itself may require amendment.

186. Evidence and Annual Regulatory Review

The organization should preserve evidence of the annual regulatory review process. The Commission’s 2026 review of prohibited practices and Annex III demonstrates that the regulatory environment is subject to periodic review and future modification.

187. Evidence and Official Consultation

Where an organization contributes to:

public consultation;
regulatory sandbox;
standards development;
AI Office consultation;

the contribution may be retained as regulatory context but should not be treated as legal evidence of compliance.

188. Assurance and Regulatory Learning

Regulatory sandboxes and implementation experience may generate evidence useful for future assurance and improvement. The evidence should identify:

experiment;
scope;
result;
limitations;
regulatory interpretation;
lessons learned.

189. Assurance and Emerging Technology

For emerging technologies such as agentic AI, assurance should focus on:

autonomy;
control boundaries;
human intervention;
logging;
security;
model/system interactions;
unintended actions.

Annex XIV introduced an emerging-technology designation category including agentic AI for conformity-assessment-body scope. This is not itself a universal high-risk classification.

190. Evidence and Agentic Systems

Where relevant, evidence should include:

agent architecture;
tool access;
authorization boundaries;
intervention;
action logs;
safety tests;
failure modes;
shutdown;
monitoring.

191. Assurance and Agentic Systems

Assurance may test:

authorization controls;
action boundaries;
human intervention;
logging;
tool use;
failure handling.

192. Evidence and Systemic Risk

Systemic-risk GPAI evidence should receive enhanced protection and review because it may contain highly sensitive technical, safety, or security information. The Commission’s current GPAI framework identifies systemic-risk obligations including risk assessment, incident reporting, and cybersecurity.

193. Systemic-Risk Evidence Pack

Potential content:

Systemic-Risk Determination
Risk Assessment
Evaluation
Safety Framework
Security Framework
Red-Team Results
Mitigations
Monitoring
Serious Incidents
AI Office Notifications
Submissions
Corrective Actions
Assurance

194. Systemic-Risk Assurance

Assurance should consider:

systemic-risk classification;
safety;
security;
evaluation;
incident handling;
regulatory reporting;
evidence completeness.

195. Evidence and Transparency Risk

Transparency evidence should be tested for actual user exposure. A hidden configuration value may not demonstrate that users were informed. The evidence model should therefore distinguish:

Technical Configuration

from:

User-Visible Effect

196. Evidence and Human Oversight

Similarly:

Human Assigned

does not automatically mean:

Human Oversight Effective

Evidence should demonstrate the actual operating capability where appropriate.

197. Evidence and Control Effectiveness

For every critical control, the preferred evidence sequence is:

Design
  ↓
Implementation
  ↓
Operation
  ↓
Monitoring
  ↓
Testing
  ↓
Assurance

198. Evidence and Risk Treatment

A risk treatment should identify:

treatment action;
control;
evidence;
expected effect;
residual risk;
verification.

199. Assurance and Residual Risk

Assurance may evaluate whether:

residual risk is supported by evidence;
treatment was implemented;
monitoring is active;
acceptance authority was appropriate.

200. Assurance Conclusion

AIGΟ assurance should conclude on the defined criteria, not on a broader undefined claim of “AI Act compliance.” Example:

Conclusion:
Control EUAI-CTRL-RISK-001 was designed and implemented,
and sampled operating evidence supports effective operation
for the period reviewed, subject to the findings identified.

This is materially more defensible than:

The organization is EU AI Act compliant.

201. Evidence and Legal Compliance Claims

The repository should avoid unsupported claims such as:

“fully AI Act compliant”;
“certified by AIGO”;
“approved under the AI Act”;
“conformity achieved” without the applicable statutory process.

Evidence should support precise, bounded statements.

202. Evidence and Audit Trail

The AIGO audit trail should allow reconstruction of:

requirement;
decision;
control;
evidence;
reviewer;
assurance;
finding;
action;
closure.

203. Evidence and Auditability

The audit trail should be:

chronological;
attributable;
versioned;
tamper-resistant;
searchable;
retrievable.

204. Evidence Accessibility

Evidence should be accessible to authorized:

governance;
legal/compliance;
assurance;
technical;
regulatory-response personnel.

Access should follow least privilege.

205. Evidence and Security

Evidence repositories should be protected against:

unauthorized access;
unauthorized modification;
deletion;
leakage;
ransomware;
accidental loss.

206. Evidence and Privacy

Evidence may contain personal data. The organization should apply:

data minimization;
purpose limitation;
access restriction;
retention;
secure deletion;
applicable data-protection law.

207. Assurance Data Protection

Assurance teams should only obtain the evidence needed for the review and should control copies of sensitive evidence.

208. Evidence and Third-Party Confidentiality

Supplier evidence may contain trade secrets or confidential information. The repository should maintain:

classification;
access restrictions;
contractual rights;
disclosure rules.

209. Evidence and Regulatory Disclosure

Before regulatory disclosure, the organization should assess:

requested scope;
confidentiality;
personal data;
trade secrets;
legal basis;
applicable disclosure obligation.

The organization should not use confidentiality as a reason to ignore a lawful disclosure obligation.

210. Evidence and Notified Bodies

Where a notified body requests evidence, the organization should maintain:

request;
scope;
evidence package;
response;
findings;
corrective action;
closure.

211. Assurance and Notified Bodies

AIGO assurance can assess readiness for notified-body engagement but must not represent itself as a notified body.

212. Evidence and Market Surveillance

Where market-surveillance authorities request information, AIGO should support:

rapid evidence retrieval;
legal review;
integrity;
submission;
tracking.

213. Assurance and Market Surveillance

Regulatory-readiness assurance can test whether the evidence package can be retrieved and produced within required timelines.

214. Regulatory Evidence Response

The recommended workflow is:

Authority Request
      ↓
Register Request
      ↓
Determine Scope
      ↓
Identify Evidence
      ↓
Preserve Evidence
      ↓
Validate Evidence
      ↓
Legal Review
      ↓
Management Approval Where Required
      ↓
Submit
      ↓
Retain Receipt

215. Evidence and Enforcement

If an enforcement decision is received:

Decision
   ↓
Evidence Preservation
   ↓
Legal Review
   ↓
Risk
   ↓
Corrective Action
   ↓
Assurance
   ↓
Management Review

216. Evidence and Commitments

Regulatory commitments should generate a dedicated evidence trail.

Commitment
   ↓
Milestone
   ↓
Implementation
   ↓
Evidence
   ↓
Verification
   ↓
Authority Response

217. Evidence and Fines

A fine should generate evidence of:

decision;
amount;
legal basis;
payment;
corrective action;
governance response.

Payment alone does not demonstrate resolution of the underlying cause.

218. Evidence and Periodic Penalty Payments

Where periodic penalty payments are imposed, AIGO should track:

authority decision;
daily amount;
compliance condition;
start date;
end date;
evidence of compliance;
cessation decision.

219. Assurance of Enforcement Response

An assurance review should determine whether:

the enforcement issue was understood;
corrective actions were implemented;
evidence exists;
recurring risk remains;
management addressed root causes.

220. Evidence and Continuous Improvement

Regulatory and assurance findings should feed the AIGO Improvement process. The loop is:

Evidence
  ↓
Finding
  ↓
Learning
  ↓
Improvement
  ↓
New Control
  ↓
New Evidence

221. Master Evidence Matrix

EU AI Act Area	Minimum Evidence Family	Typical Assurance
Applicability	Applicability assessment	Legal / governance
Classification	Classification record	Classification review
Article 5	Prohibited-practice screening	Legal / technical
Risk	Risk assessment / register	Risk assurance
Data	Data governance records	Data assurance
Documentation	Technical documentation	Documentation review
Logging	Logs / configurations	Technical assurance
Transparency	Notices / marks / tests	Technical / compliance
Human oversight	Role / intervention evidence	Operational assurance
Accuracy	Validation results	Technical assurance
Robustness	Robustness tests	Technical assurance
Cybersecurity	Security evidence	Security assurance
QMS	QMS records	QMS assurance
Conformity	Assessment / certificate	Conformity readiness / statutory assessment
Registration	Submission / identifier	Registration review
GPAI	Model documentation / submissions	GPAI assurance
AI literacy	Learning measures	Competence / governance review
Rights	FRIA / complaints / remediation	Rights assurance
Monitoring	Monitoring reports	Operational assurance
Incident	Incident records	Incident assurance
Change	Change / impact assessment	Change assurance
Regulatory	Authority interaction evidence	Regulatory readiness
Improvement	Corrective-action evidence	Effectiveness review
Retirement	Retirement / retention records	Lifecycle review

222. Evidence Prioritization

Evidence should be prioritized based on:

legal criticality;
safety;
fundamental rights;
regulatory exposure;
system impact;
control criticality;
incident history.

Critical evidence should receive stronger integrity and assurance controls.

223. Evidence Review Frequency

Evidence review should follow the corresponding control. Possible frequencies:

CONTINUOUS
PER_TRANSACTION
PER_SYSTEM
PER_CHANGE
MONTHLY
QUARTERLY
SEMI_ANNUAL
ANNUAL
EVENT_DRIVEN

224. Evidence Owner

Every material evidence category should have an accountable owner. Potential owners:

AI System Owner;
Control Owner;
Risk Owner;
Evidence Owner;
Technical Owner;
Compliance Owner;
Assurance Owner.

225. Evidence Escalation

Evidence gaps should escalate when:

evidence is legally required;
evidence supports a critical control;
regulator request exists;
assurance cannot conclude;
evidence integrity is compromised;
deadline is approaching.

226. Evidence Review Board

The organization may establish a cross-functional evidence review mechanism involving:

AI Governance;
Legal/Compliance;
Risk;
Technical;
Assurance;
Records Management.

227. Evidence and AIGO Schemas

Evidence Activity	AIGO Schema
AI system evidence	AI System
Risk evidence	Risk
Control evidence	Control
Assessment evidence	Assessment
Decision evidence	Approval
Monitoring evidence	Monitoring
Incident evidence	Incident
Change evidence	Change
Assurance evidence	Assurance
Primary evidence record	Evidence
Management evidence	Management Review
Improvement evidence	Improvement
Retirement evidence	Retirement
Organizational responsibility	Governance

228. Evidence and Existing Templates

The following existing templates should support evidence production:

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

No additional generic evidence template is required beyond the existing Evidence Record Template at this stage.

229. Evidence and AIGO Tools

This mapping should be consumed by:

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

230. Evidence Registry Requirements

The machine-readable evidence registry should eventually support:

evidenceId
systemId
requirementId
controlId
assessmentId
assuranceId
source
type
status
version
createdDate
reviewDate
validUntil
owner
integrity
classification
retention

231. Assurance Registry Requirements

The machine-readable assurance registry should support:

assuranceId
requirementId
controlId
evidenceIds
scope
criteria
method
reviewer
independence
period
status
findings
conclusion
followUp

232. Evidence and Assurance Relationship

The primary relationship is:

One Requirement
        ↓
One or More Controls
        ↓
One or More Evidence Records
        ↓
One or More Assurance Activities

The reverse relationship should also be supported. A single evidence record may support several related controls, provided the relationship is explicit.

233. Evidence Reuse

Evidence may be reused when:

it remains current;
it applies to the same system/version;
the legal context is compatible;
the evidence scope is sufficient.

Evidence should not be reused merely because the document title is similar.

234. Evidence Duplication

AIGO should prefer controlled cross-reference over unnecessary duplication. Example:

Technical Documentation
      ↕
AI System Profile
      ↕
Evidence Record

The repository should avoid multiple conflicting copies.

235. Evidence Supersession

When evidence is replaced:

new evidence becomes current;
old evidence becomes superseded;
history remains traceable;
linked assurance should be reassessed where material.

236. Assurance Reuse

Prior assurance may be reused only when:

scope remains valid;
legal baseline remains valid;
system remains materially unchanged;
evidence remains current.

Material changes should trigger reassessment.

237. Evidence and Change Impact

Changes should automatically identify affected evidence. Potential impacts:

System Version
Risk
Classification
Technical Documentation
Conformity
Registration
Monitoring
Assurance

238. Assurance and Change Impact

Assurance should assess whether material changes have been correctly reflected in evidence and controls.

239. Evidence and Retirement

The retirement process should include:

Final Evidence Snapshot
        ↓
Final Monitoring
        ↓
Final Incident Status
        ↓
Conformity / Registration Status
        ↓
Retention Decision
        ↓
Repository Closure

240. Evidence and Lessons Learned

Retirement may generate evidence used for future improvement:

incidents;
performance;
assurance findings;
user feedback;
regulatory findings.

241. Evidence Quality Dashboard

AIGO may provide a dashboard showing:

Required Evidence
Available Evidence
Validated Evidence
Stale Evidence
Critical Gaps
Assurance Coverage

This should be based on actual repository records.

242. Evidence Health Categories

Potential health status:

HEALTHY
CURRENT_WITH_WARNINGS
STALE
INCOMPLETE
UNTRUSTED
UNAVAILABLE

243. Assurance Health Categories

Potential assurance status:

NOT_PLANNED
PLANNED
IN_PROGRESS
COMPLETE
FINDINGS_OPEN
OVERDUE
REQUIRES_REASSESSMENT

244. Evidence Governance Minimum Standard

For material AI systems, AIGO should be able to answer:

What system is this?
Which legal requirements apply?
Why do they apply?
Which controls address them?
What evidence demonstrates implementation?
Is the evidence current?
Has the evidence been assessed?
What findings exist?
What remediation is underway?
Who reviewed it?

245. Assurance Governance Minimum Standard

For material controls, AIGO should be able to answer:

What was reviewed?
Against what criteria?
What evidence was examined?
Who performed the assurance?
Was the reviewer independent?
What was concluded?
What findings were identified?
What remediation is required?
Was remediation verified?
When is reassessment required?

246. Critical Evidence Assurance Rule

Where evidence is unavailable for a critical control, the assurance conclusion should normally be: INSUFFICIENT_EVIDENCE unless sufficient alternative evidence exists and the alternative is documented.

247. Alternative Evidence

Alternative evidence may be accepted where:

the primary evidence type is unavailable;
the alternative is sufficiently reliable;
the legal requirement does not mandate the primary form;
the alternative is documented.

The alternative should identify why it is acceptable.

248. Legal Evidence Versus Governance Evidence

AIGO should distinguish:

LEGAL / REGULATORY EVIDENCE

from:

AIGO GOVERNANCE EVIDENCE

The second supports governance but does not automatically have the legal status of the first.

249. Statutory Evidence Boundary

Examples of statutory or externally issued evidence may include:

certificate;
declaration;
registration acknowledgment;
authority decision;
regulatory submission receipt.

Examples of organizational evidence include:

internal approval;
internal assessment;
control record;
internal assurance report.

The two categories should not be conflated.

250. Evidence and Legal Source

Every material evidence claim should identify its relationship to a legal or governance requirement. For example:

Evidence:
Risk Assessment RA-001

Supports:
EUAI-CTRL-RISK-001

Maps To:
Article 9

System:
AI-001

Version:
2.3

251. Evidence and Regulatory Source Currency

Evidence should identify the legal baseline under which the decision was made. This is particularly important after amendments such as Regulation (EU) 2026/1744.

252. Evidence Assurance Matrix

Evidence Claim	Required Validation
Classification	Legal + factual
Risk	Method + evidence
Control	Design + operation
Technical Documentation	Completeness + currency
Conformity	Statutory pathway + source
Registration	Submission + identifier
Transparency	Technical/user evidence
Human Oversight	Operational evidence
GPAI	Regulatory + technical
Rights	Legal/contextual
Incident	Event + impact
Change	Impact + implementation
Monitoring	Method + results
Assurance	Independence + methodology

253. Current Regulatory Source Baseline

This version should be reviewed against:

Regulation (EU) 2024/1689;
Regulation (EU) 2026/1744;
current Commission AI Act framework material;
current GPAI guidance;
current transparency guidance;
current official implementation material.

The Commission’s AI Act framework page identifies the current application schedule and distinguishes the different risk categories and obligations.

254. Current GPAI Baseline

GPAI obligations are currently applicable, and Commission enforcement powers entered into application on 2 August 2026. Providers of GPAI models placed on the market before 2 August 2025 have until 2 August 2027 to comply. AIGO should therefore treat GPAI evidence and assurance as current governance requirements.

255. Current Transparency Baseline

Article 50 transparency obligations apply from 2 August 2026 under the current Commission implementation framework. The transparency Code of Practice is a voluntary adequate implementation tool, but adherence does not constitute conclusive proof of compliance.

256. Current High-Risk Baseline

The current implementation schedule provides:

2 December 2027
→ Article 6(2) / Annex III high-risk systems

2 August 2028
→ Article 6(1) / Annex I high-risk systems

The Commission’s current high-risk guidance reflects these dates, while noting that its classification guidance is non-binding implementation guidance.

257. Regulatory Review Baseline

The Commission’s 2026 review of Article 5 and Annex III confirms that those lists remain subject to ongoing regulatory review. AIGO should therefore consider regulatory currency itself an assurance criterion.

258. Evidence and Regulatory Change Control

A material legal change should generate:

Change Record
        ↓
Updated Mapping
        ↓
Updated Control
        ↓
Updated Evidence Requirement
        ↓
Assurance Reassessment

259. Evidence and Mapping Version

Every assurance activity should identify the mapping version used. Example:

Mapping:
AIGO-MAP-EUAI-013 v0.1

Control:
EUAI-CTRL-RISK-001

Legal Baseline:
Regulation (EU) 2026/1744

Assurance Date:
2026-08-14

260. Evidence and Assurance Release Gate

The EU AI Act mapping package should not be marked ready for operational release unless:

critical evidence requirements are defined;
critical controls are mapped;
assurance expectations are defined;
timeline is current;
references resolve;
evidence identifiers are stable;
document integrity checks pass.

261. Evidence Quality Standard

A high-quality evidence framework should be:

authoritative;
attributable;
versioned;
traceable;
current;
complete;
protected;
reviewable;
proportionate.

262. Assurance Quality Standard

A high-quality assurance framework should be:

criterion-based;
evidence-based;
appropriately independent;
repeatable;
documented;
proportionate;
transparent about limitations;
linked to remediation.

263. Evidence and Assurance Coverage

The complete governance chain is:

EU AI Act
      ↓
Applicability
      ↓
AIGO Requirement
      ↓
AIGO Control
      ↓
Implementation
      ↓
Evidence
      ↓
Assessment
      ↓
Monitoring
      ↓
Assurance
      ↓
Finding
      ↓
Corrective Action
      ↓
Improvement
      ↓
Reassessment

This chain is the core purpose of this mapping.

264. Evidence Findings

Potential findings include:

EVIDENCE_GAP
EVIDENCE_QUALITY_GAP
EVIDENCE_CURRENCY_GAP
EVIDENCE_INTEGRITY_GAP
EVIDENCE_TRACEABILITY_GAP
EVIDENCE_RETENTION_GAP
REGULATORY_EVIDENCE_GAP
TECHNICAL_EVIDENCE_GAP
ASSURANCE_EVIDENCE_GAP

265. Assurance Findings

Potential findings include:

ASSURANCE_GAP
ASSURANCE_OVERDUE
ASSURANCE_SCOPE_GAP
ASSURANCE_CRITERIA_GAP
ASSURANCE_INDEPENDENCE_GAP
CONTROL_EFFECTIVENESS_GAP
FOLLOWUP_GAP

266. Critical Findings

Potential critical findings include:

legally required evidence unavailable;
required conformity evidence unavailable;
critical system version cannot be established;
regulatory submission cannot be evidenced;
critical control cannot be assured;
evidence integrity compromised;
regulatory preservation obligation breached.

267. Validation Requirements

The evidence and assurance mapping should pass:

Legal Source Validation

Every material evidence requirement maps to an applicable source.

Control Validation

Every material evidence requirement maps to an AIGO control.

Evidence Validation

Evidence types are defined.

Traceability Validation

Requirement → control → evidence → assurance chain exists.

Version Validation

System, control, evidence, and legal versions are consistent.

Timeline Validation

Evidence status respects application dates and transitions.

Assurance Validation

Critical controls have defined assurance expectations.

Repository Validation

Identifiers resolve throughout the repository.

268. Limitations

This document cannot independently determine:

whether evidence is legally sufficient in a specific proceeding;
whether a regulator will accept an evidence package;
whether a notified body will accept an artifact;
whether a control is legally compliant;
whether a specific assurance conclusion establishes conformity;
whether evidence satisfies all requirements of another applicable legal regime.

Those determinations require appropriate legal, technical, regulatory, conformity, and assurance judgment.

269. 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
`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`	Governance / enforcement
`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`	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`	Controls

This document closes the evidence and assurance layer of the EU AI Act mapping package.

270. Relationship to AIGO Schemas

Evidence / Assurance Activity	AIGO Schema
AI system evidence	AI System
Risk evidence	Risk
Control evidence	Control
Assessment evidence	Assessment
Approval evidence	Approval
Monitoring evidence	Monitoring
Incident evidence	Incident
Change evidence	Change
Evidence record	Evidence
Assurance activity	Assurance
Management evidence	Management Review
Improvement evidence	Improvement
Retirement evidence	Retirement
Accountability	Governance

No additional generic evidence or assurance schema is required at this stage.

271. Relationship to AIGO Templates

Relevant templates include:

AI System Registration Template;
AI System Profile Template;
AI Classification Template;
AI Risk Assessment Template;
AI Approval Template;
AI Monitoring Template;
AI Incident Template;
AI Change Management Template;
AI Assurance Template;
AI Management Review Template;
AI Continuous Improvement Template;
AI Retirement Template;
AI Evidence Record Template.

The Evidence Record Template should remain the principal reusable evidence artifact.

272. Relationship to AIGO Tools

The evidence and assurance mapping should be consumed by:

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

273. Future Automation Model

A future automated validation flow may execute:

Legal Requirement
        ↓
Applicability Engine
        ↓
Applicable Control
        ↓
Required Evidence
        ↓
Evidence Registry
        ↓
Evidence Validation
        ↓
Assurance Registry
        ↓
Coverage Result
        ↓
Finding

This would allow the AIGO framework to move from a document-only crosswalk toward machine-checkable regulatory governance.

274. Final Governance Model

The intended AIGO evidence and assurance lifecycle is:

Requirement
    ↓
Applicability
    ↓
Control
    ↓
Implementation
    ↓
Evidence
    ↓
Validation
    ↓
Monitoring
    ↓
Assurance
    ↓
Finding
    ↓
Corrective Action
    ↓
Improvement
    ↓
Reassessment
    ↓
Evidence

This forms the closing control loop for the EU AI Act mapping package.

275. Document Control

Field	Value
Document	AIGO EU AI Act Evidence and Assurance Mapping
Version	0.1
Status	Draft
Document Identifier	`AIGO-MAP-EUAI-013`
Document Type	EU AI Act Mapping
Primary Purpose	Evidence and assurance crosswalk
Primary Legal Instrument	Regulation (EU) 2024/1689
Amendment Baseline	Regulation (EU) 2026/1744
Owner
Legal/Compliance Reviewer
Governance Reviewer
Evidence Reviewer
Assurance Reviewer
Framework Architect
Approved By
Effective Date
Next Review Date

276. Document Status

Document: AIGO — EU AI Act Evidence and Assurance Mapping Version: 0.1 Status: Draft Working Name: AIGO Full Name: AI Governance Operating Framework Document Identifier: AIGO-MAP-EUAI-013 Document Type: EU AI Act Mapping This document establishes the evidence and assurance layer for the AIGO EU AI Act mapping package, linking legal requirements to controls, evidence, assessments, monitoring, assurance, findings, corrective actions, improvement, and reassessment. End of Document

​AIGO — EU AI Act Evidence and Assurance Mapping

​1. Document Purpose

​2. Mapping Information

​3. Evidence Governance Principle

​4. Evidence Relationship Types

​PRIMARY

​SUPPORTING

​DERIVED

​CROSS_REFERENCE

​REGULATORY

​TECHNICAL

​OPERATIONAL

​ASSURANCE

​HISTORICAL

​5. Evidence Status

​6. Evidence Quality Model

​7. Evidence Integrity

​8. Evidence Attribution

​9. Evidence Currency

​10. Evidence and Versioning

​11. Evidence Traceability Principle

​12. Master Evidence Chain

​13. Evidence Categories

​14. Applicability Evidence

​Control Relationship

​Purpose

​Evidence

​Assurance

​15. Classification Evidence

​Control Relationship

​Evidence

​Assurance

​16. Prohibited-Practice Evidence

​Control Relationship

​17. Article 5 Evidence Standard

​18. Risk Evidence

​Control Relationship

​19. Risk Evidence Quality

​20. Data Governance Evidence

​Control Relationship

​21. Technical Documentation Evidence

​Control Relationship

​22. Technical Documentation Completeness

​23. Record-Keeping Evidence

​Control Relationship

​24. Logging Evidence

​25. Transparency Evidence

​Control Relationships

​26. Transparency Technical Evidence

​27. Human-Oversight Evidence

​Control Relationship

​28. Accuracy Evidence

​Control Relationship

​29. Robustness Evidence

​Control Relationship

​30. Cybersecurity Evidence

​Control Relationship

​31. Quality-Management Evidence

​Control Relationship

​32. Conformity Evidence

​Control Relationships

​33. Conformity Evidence Boundary

​34. Notified-Body Evidence

​35. Declaration of Conformity Evidence

​36. Registration Evidence

​37. GPAI Evidence Architecture

​38. GPAI Regulatory Submission Evidence

​39. GPAI Safety and Security Evidence

​40. AI Literacy Evidence

​Control Relationship

​41. Fundamental-Rights Evidence

​Control Relationship

​42. Rights and DPIA Evidence

​43. Complaint Evidence

​Control Relationship

​44. Regulatory Complaint Evidence

​45. Monitoring Evidence

​Control Relationships

​46. Incident Evidence

​Control Relationships

AIGO — EU AI Act Evidence and Assurance Mapping

1. Document Purpose

2. Mapping Information

3. Evidence Governance Principle

4. Evidence Relationship Types

PRIMARY

SUPPORTING

DERIVED

CROSS_REFERENCE

REGULATORY

TECHNICAL

OPERATIONAL

ASSURANCE

HISTORICAL

5. Evidence Status

6. Evidence Quality Model

7. Evidence Integrity

8. Evidence Attribution

9. Evidence Currency

10. Evidence and Versioning

11. Evidence Traceability Principle

12. Master Evidence Chain

13. Evidence Categories

14. Applicability Evidence

Control Relationship

Purpose

Evidence

Assurance

15. Classification Evidence

Control Relationship

Evidence

Assurance

16. Prohibited-Practice Evidence

Control Relationship

17. Article 5 Evidence Standard

18. Risk Evidence

Control Relationship

19. Risk Evidence Quality

20. Data Governance Evidence

Control Relationship

21. Technical Documentation Evidence

Control Relationship

22. Technical Documentation Completeness

23. Record-Keeping Evidence

Control Relationship

24. Logging Evidence

25. Transparency Evidence

Control Relationships

26. Transparency Technical Evidence

27. Human-Oversight Evidence

Control Relationship

28. Accuracy Evidence

Control Relationship

29. Robustness Evidence

Control Relationship

30. Cybersecurity Evidence

Control Relationship

31. Quality-Management Evidence

Control Relationship

32. Conformity Evidence

Control Relationships

33. Conformity Evidence Boundary

34. Notified-Body Evidence

35. Declaration of Conformity Evidence

36. Registration Evidence

37. GPAI Evidence Architecture

38. GPAI Regulatory Submission Evidence

39. GPAI Safety and Security Evidence

40. AI Literacy Evidence

Control Relationship

41. Fundamental-Rights Evidence

Control Relationship

42. Rights and DPIA Evidence

43. Complaint Evidence

Control Relationship

44. Regulatory Complaint Evidence

45. Monitoring Evidence

Control Relationships

46. Incident Evidence

Control Relationships