AIGO — EU AI Act GPAI Mapping

1. Document Purpose

This document provides the AIGO mapping for the European Union Artificial Intelligence Act requirements concerning general-purpose AI (GPAI) models, including models presenting systemic risk. The mapping translates the applicable legal and implementation requirements into the AIGO governance framework covering:

GPAI applicability;
provider identification;
model classification;
systemic-risk determination;
technical documentation;
information for downstream providers;
copyright-policy governance;
training-content summaries;
open-source considerations;
safety and security;
systemic-risk assessment;
evaluation and testing;
serious incidents;
corrective action;
regulatory interaction;
evidence;
monitoring;
assurance;
change management;
management review; and
continual improvement.

This document is an operational governance mapping. It is not legal advice, a legal opinion, a conformity assessment, or a declaration of compliance. The European Commission states that GPAI obligations entered into application on 2 August 2025; Commission enforcement powers apply from 2 August 2026; and providers of GPAI models placed on the market before 2 August 2025 must comply by 2 August 2027.

2. Mapping Information

Field	Value
Mapping	AIGO EU AI Act GPAI Mapping
Version	0.1
Status	Draft
Document Identifier	`AIGO-MAP-EUAI-005`
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 GPAI Provisions	Articles 51–56 and related provisions
Mapping Architecture	`AIGO-MAP-EUAI-ARCH-001`
Registry	`00-AIGO-EU-AI-Act-Mapping-Registry-v0.1.json`

Regulation (EU) 2026/1744, published on 24 July 2026, amended the AI Act as part of the Digital Omnibus on AI and must therefore be treated as part of the current legal baseline.

3. Source Hierarchy

3.1 Binding Legal Source

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

3.2 Official Implementation Material

Supporting material includes:

European Commission GPAI guidelines;
European AI Office guidance;
General-Purpose AI Code of Practice;
official FAQs;
EU SEND submission guidance;
implementing and delegated acts where applicable.

The Commission states that its GPAI guidelines are non-binding but reflect the Commission’s interpretation and are intended to guide implementation and enforcement.

3.3 AIGO Mapping

AIGO translates legal requirements into operational governance mechanisms. AIGO implementation mechanisms must not be represented as automatically equivalent to statutory compliance.

4. GPAI Governance Principle

GPAI governance should be treated as a distinct regulatory profile. The recommended AIGO process is:

AI Model / AI System
        ↓
GPAI Applicability Screening
        ↓
Provider / Role Determination
        ↓
GPAI Classification
        ↓
Systemic-Risk Determination
        ↓
Applicable Obligations
        ↓
Control Mapping
        ↓
Assessment
        ↓
Evidence
        ↓
Regulatory Submission / Interaction
        ↓
Monitoring
        ↓
Assurance
        ↓
Change / Improvement

AIGO should distinguish the governance of:

providers of GPAI models;
deployers of systems based on GPAI models;
downstream providers;
organizations making significant modifications;
organizations integrating GPAI models into AI systems.

5. GPAI Applicability

AIGO should determine:

whether the artifact is an AI model;
whether it is general-purpose;
whether the organization is a provider;
whether the organization makes significant modifications;
whether the model has systemic risk;
whether an open-source exemption is relevant;
whether transitional rules apply;
whether the organization’s activity falls under another actor category.

The Commission’s current guidelines provide technical criteria for determining when a model is general-purpose and clarify that providers making significant modifications may become subject to provider obligations, while minor modifications do not necessarily create the same status.

6. AIGO GPAI Applicability Assessment

The organization should maintain a structured assessment containing:

Field	Purpose
Model ID	Identifies the model
Provider	Identifies responsible organization
Role	Provider / downstream actor / other
Model Purpose	Establishes context
General-Purpose Determination	Determines GPAI status
Significant Modification	Determines provider status where applicable
Systemic Risk	Determines enhanced obligations
Open-Source Status	Determines possible exemption
Market Status	Determines transition
Effective Date	Establishes timing
Rationale	Documents determination
Evidence	Supports determination
Reviewer	Accountability
Review Date	Currency

7. AIGO GPAI Classification

AIGO should use separate regulatory attributes for:

GPAI = YES / NO / UNCERTAIN
SYSTEMIC_RISK = YES / NO / UNCERTAIN
OPEN_SOURCE = YES / NO / UNCERTAIN
SIGNIFICANT_MODIFICATION = YES / NO / UNCERTAIN

These should not replace the general AIGO AI classification or risk rating.

8. Provider Role Determination

The organization should identify whether it is:

provider of a GPAI model;
provider of a downstream AI system using GPAI;
deployer;
importer;
distributor;
other actor.

Provider obligations should not be assigned merely because an organization uses a third-party GPAI model.

9. Significant Modification

Where an organization materially modifies an existing model, AIGO should assess whether the modification creates obligations applicable to providers of GPAI models. The assessment should consider:

technical modifications;
retraining;
substantial fine-tuning;
changes to capabilities;
architecture changes;
changes to intended purpose;
changes affecting systemic-risk characteristics.

The Commission’s guidelines explicitly distinguish significant modifications from minor modifications.

10. Open-Source Considerations

The current Commission guidelines explain the conditions under which providers of open-source GPAI models may benefit from exemptions from certain obligations. AIGO should therefore record:

open-source status;
applicable licence;
openness characteristics;
documentation availability;
applicable exemption;
obligations that remain applicable;
evidence supporting the determination.

Open-source status should never be represented as a blanket exemption from all GPAI obligations.

11. Systemic-Risk Determination

AIGO should perform a separate systemic-risk assessment. The assessment should consider the applicable legal criteria and evidence, including where relevant:

model capability;
computational characteristics;
scale;
systemic impact;
evaluation results;
model use across downstream systems;
potential severity of incidents;
concentration of use;
technical capacity.

The exact legal threshold and criteria must be taken from the current AI Act and applicable official guidance.

12. Systemic-Risk Governance Profile

Where a GPAI model presents systemic risk, AIGO should activate an enhanced governance profile:

SYSTEMIC_RISK
      ↓
Enhanced Risk Assessment
      ↓
Safety / Security Framework
      ↓
Enhanced Evaluation
      ↓
Adversarial Testing
      ↓
Incident Reporting
      ↓
AI Office Interaction
      ↓
Enhanced Monitoring
      ↓
Independent Assurance

13. GPAI Provider Obligations

The AIGO mapping should organize GPAI provider requirements into operational categories:

technical documentation;
information for downstream providers;
copyright compliance;
training-content summary;
open-source requirements/exemptions;
systemic-risk requirements;
safety and security;
serious incidents;
corrective actions;
regulatory cooperation.

The exact statutory obligations must be traced to the current legal text.

14. Technical Documentation

14.1 Legal Theme

Providers of GPAI models must maintain the documentation required by the AI Act for the purposes defined by the Regulation.

14.2 AIGO Mapping

Relationship: DIRECT AIGO Components:

AI System / Model Profile;
Evidence;
Change;
Assurance;
Governance.

14.3 AIGO Control

GPAI Technical Documentation Control Documentation should address, where applicable:

model architecture;
capabilities;
limitations;
training;
testing;
evaluation;
performance;
intended and foreseeable uses;
risk management;
energy/resources where applicable;
security;
post-release changes.

14.4 Evidence

controlled technical documentation;
version history;
review records;
change records;
assessment results.

15. Information for Downstream Providers

15.1 Legal Theme

GPAI providers must make specified information available to downstream providers to enable their compliance obligations.

15.2 AIGO Mapping

Relationship: DIRECT

15.3 AIGO Control

Downstream Provider Information Control The control should require:

information package;
controlled release;
versioning;
accessibility;
update process;
recipient tracking;
material-change notification.

15.4 Evidence

provider information package;
version record;
delivery record;
update notice;
contractual evidence.

16. Downstream Traceability

AIGO should support:

GPAI Model
    ↓
GPAI Provider
    ↓
Downstream Provider
    ↓
AI System
    ↓
Use Case
    ↓
Risk
    ↓
Controls

The provider should be able to maintain traceability to downstream entities where the legal or contractual framework requires it.

17. Copyright Policy

17.1 Legal Theme

GPAI providers are subject to obligations concerning a policy for compliance with Union copyright law.

17.2 AIGO Mapping

Relationship: DIRECT AIGO Components:

Governance;
Control;
Evidence;
Assurance;
Risk.

17.3 AIGO Control

GPAI Copyright Governance Control The control should require:

policy;
owner;
applicable legal basis;
implementation;
review;
monitoring;
evidence.

17.4 Evidence

copyright policy;
implementation records;
rights-management process;
review;
compliance assessment.

18. Training-Content Summary

GPAI providers are subject to requirements concerning publication of a sufficiently detailed summary of training content. AIGO should maintain:

training-content summary;
source documentation;
review;
version;
publication record;
change history.

The Commission provides a template and Q&A material for the public summary of training content.

19. Training Data Governance

The AIGO Data Governance framework should support:

Training Data
     ↓
Source
     ↓
Collection
     ↓
Processing
     ↓
Rights / Copyright Review
     ↓
Quality
     ↓
Bias / Risk
     ↓
Documentation
     ↓
Summary

This is an operational governance chain and does not replace legal analysis of copyright or other rights.

20. Model Evaluation

AIGO should establish a controlled model-evaluation process. Potential areas include:

capabilities;
limitations;
performance;
misuse;
robustness;
safety;
security;
harmful outputs;
systemic risk;
downstream impacts.

For systemic-risk models, the evaluation profile should be enhanced.

21. Safety and Security

Systemic-risk GPAI providers require enhanced safety and security governance. AIGO should establish:

safety framework;
security framework;
threat assessment;
red-team testing;
adversarial evaluation;
incident handling;
monitoring;
corrective action.

The Commission’s current implementation material directs providers toward the GPAI Code of Practice and related safety-and-security documentation, including Safety and Security Framework and Model Report submissions through EU SEND.

22. GPAI Code of Practice

The General-Purpose AI Code of Practice is a voluntary implementation tool intended to help providers meet GPAI obligations. AIGO should support three states:

CODE_ADOPTED
ALTERNATIVE_COMPLIANCE_APPROACH
UNDER_REVIEW

Where the Code is used, AIGO should record:

signatory status;
applicable chapters;
implementation;
evidence;
monitoring;
review.

Where another approach is used, the organization should document how it intends to meet the applicable legal obligations. The Commission states that providers not signing the Code should report how they intend to comply, and the EU SEND process supports submission of such reports.

23. AI Office Interaction

The EU AI Office has a central role in GPAI supervision and support. AIGO should maintain a regulatory-interaction record containing:

communication;
request;
response;
submission;
acknowledgment;
deadline;
responsible owner;
evidence;
follow-up.

AIGO internal governance must remain distinct from the statutory authority of the AI Office.

24. EU SEND

The Commission states that GPAI providers must use the EU SEND platform to submit relevant documents to the AI Office, including certain systemic-risk notifications, reassessment requests, serious-incident reports, and other specified materials. AIGO should therefore establish: Regulatory Submission Control The control should manage:

submission applicability;
responsible person;
document preparation;
review;
authorization;
submission;
acknowledgment;
evidence;
follow-up.

25. Systemic-Risk Notification

Where legally required, a provider should maintain evidence of notification to the AI Office. The AIGO record should include:

model ID;
systemic-risk determination;
notification requirement;
notification date;
submission reference;
response;
follow-up.

The Commission states that providers of the most advanced models presenting systemic risk are legally required to notify the AI Office.

26. Reassessment Requests

The Commission’s EU SEND guidance lists requests for reassessment under the relevant AI Act provisions as a category of submission. AIGO should treat a reassessment request as a controlled regulatory interaction linked to:

model;
classification;
evidence;
legal basis;
decision;
outcome.

27. Serious Incidents

27.1 Legal Theme

GPAI providers with applicable obligations must manage and report serious incidents under the relevant provisions.

27.2 AIGO Mapping

Relationship: DIRECT / CRITICAL AIGO Components:

Incident;
Risk;
Evidence;
Change;
Assurance;
Governance.

The Commission’s EU SEND process includes serious-incident reports among the GPAI documents submitted to the AI Office.

28. GPAI Incident Management

The recommended chain is:

Detection
   ↓
Incident
   ↓
Severity
   ↓
Containment
   ↓
Investigation
   ↓
Regulatory Assessment
   ↓
EU AI Office / Authority Reporting
   ↓
Corrective Action
   ↓
Change
   ↓
Verification
   ↓
Evidence

Internal incident closure should not automatically imply regulatory reporting completion.

29. Serious Incident Evidence

Evidence may include:

technical logs;
model outputs;
affected systems;
impact information;
root cause;
safety/security evaluation;
containment;
corrective action;
regulatory submission;
correspondence;
verification.

30. Corrective Action

GPAI incidents, evaluation findings, or regulatory findings should generate corrective actions where required. Recommended chain:

Finding
   ↓
Corrective Action
   ↓
Change
   ↓
Testing
   ↓
Monitoring
   ↓
Evidence
   ↓
Assurance

The AIGO Improvement and Change schemas should support the lifecycle.

31. Systemic-Risk Evaluation

AIGO should establish enhanced evaluation for systemic-risk models. Potential evaluation domains include:

dangerous capability;
misuse;
autonomy;
cyber capability;
harmful content;
manipulation;
biological or chemical assistance;
critical infrastructure risk;
large-scale societal impact.

The exact scope should be derived from applicable legal obligations and current official guidance.

32. Red-Teaming

Red-team testing may be used as evidence for safety and security governance. The record should capture:

objective;
scope;
methodology;
scenarios;
findings;
residual risk;
remediation;
retesting.

Red-team results should not be treated as the sole evidence of model safety.

33. Model Release Governance

A GPAI provider should maintain a controlled release process. Recommended sequence:

Model Development
      ↓
Evaluation
      ↓
Risk Assessment
      ↓
Safety / Security Review
      ↓
Documentation
      ↓
GPAI Regulatory Assessment
      ↓
Approval
      ↓
Release
      ↓
Monitoring

For systemic-risk models, enhanced gates should apply.

34. Model Change Governance

Material changes should trigger review of:

GPAI classification;
systemic-risk determination;
technical documentation;
training-content summary;
copyright policy;
downstream information;
safety/security framework;
incident risk;
regulatory submission;
monitoring.

35. Significant Modification

AIGO should treat significant model modification as a regulatory-impact trigger. The assessment should document:

original provider;
modification owner;
modification scope;
capability change;
training change;
system impact;
legal analysis;
provider-status outcome.

Minor changes should be distinguished from significant modifications in accordance with the current Commission interpretation.

36. Open-Source GPAI Governance

Where an open-source exemption is potentially applicable, AIGO should document:

licence;
source availability;
model parameters;
technical documentation;
training-content information;
exemption conditions;
obligations that remain applicable.

Open-source status should be a controlled legal applicability determination.

37. Downstream Integration Governance

Organizations using GPAI models in their own AI systems should maintain:

GPAI provider identity;
model version;
terms;
documentation;
known limitations;
risk;
security;
privacy;
transparency;
changes;
incidents;
evidence.

The downstream organization should not assume that the GPAI provider’s compliance eliminates its own obligations.

38. Third-Party GPAI Due Diligence

Recommended controls include:

provider assessment;
model documentation review;
regulatory status;
systemic-risk status;
safety/security documentation;
incident history;
transparency;
change notification;
contractual commitments.

39. GPAI Procurement Gate

The AIGO procurement workflow should include:

GPAI Candidate
     ↓
Provider Identification
     ↓
GPAI Status
     ↓
Systemic Risk Status
     ↓
Documentation Review
     ↓
Safety / Security Review
     ↓
Contract Review
     ↓
Approval
     ↓
Integration

40. GPAI Monitoring

Monitoring should include:

model changes;
capability drift;
incidents;
safety events;
security events;
downstream use;
provider notifications;
regulatory developments;
classification changes.

Systemic-risk models should receive enhanced monitoring.

41. GPAI Evidence

Potential evidence includes:

GPAI Applicability Assessment
Provider Information
Technical Documentation
Training-Content Summary
Copyright Policy
Model Evaluation
Safety Framework
Security Framework
Systemic-Risk Assessment
Notification
EU SEND Submission
Incident Reports
Corrective Actions
Monitoring
Assurance

42. Evidence Coverage

The Evidence Coverage Validator should eventually assess whether GPAI governance activities have sufficient evidence. Critical evidence may include:

systemic-risk notification;
serious-incident submission;
model documentation;
training-content summary;
safety/security documentation;
regulatory correspondence.

43. GPAI Control Coverage

The Control Coverage Validator should evaluate:

applicability control;
provider-role control;
systemic-risk control;
documentation control;
downstream-information control;
copyright control;
training-summary control;
safety/security control;
incident control;
regulatory-submission control;
change control.

44. GPAI Assurance

Assurance may cover:

GPAI classification;
systemic-risk determination;
documentation;
safety/security framework;
incident management;
regulatory submissions;
evidence;
control implementation;
Code of Practice implementation.

Independent assurance may be appropriate for systemic-risk models.

45. GPAI Management Review

Management review should consider:

number of GPAI models;
provider concentration;
systemic-risk models;
regulatory submissions;
incidents;
safety/security findings;
evidence gaps;
contractual issues;
upcoming regulatory deadlines;
changes in Commission guidance.

46. GPAI Improvement

Improvement opportunities may arise from:

provider findings;
incidents;
red-team results;
assurance;
regulatory feedback;
model changes;
downstream-use issues.

The Improvement record should identify:

source;
action;
owner;
target;
evidence;
effectiveness.

47. GPAI Retirement

Retirement or replacement of a GPAI model should address:

historical evidence;
provider records;
model version;
incident history;
downstream systems;
regulatory submissions;
contractual obligations;
retained documentation.

Retirement should preserve sufficient history to support future regulatory review.

48. GPAI Regulatory Change

Changes to the EU AI Act, AI Office guidance, GPAI Code of Practice, standards, or Commission implementation material should trigger:

Regulatory Change
      ↓
GPAI Mapping Review
      ↓
Affected Models
      ↓
Classification Review
      ↓
Control Impact
      ↓
Evidence Impact
      ↓
Management Review
      ↓
Implementation

49. Current GPAI Timeline

The current official Commission position is:

Event	Date
GPAI obligations apply	2 August 2025
Commission enforcement powers	2 August 2026
Pre-existing GPAI models placed on market before 2 August 2025 must comply	2 August 2027

The Commission’s current GPAI guidance confirms these dates.

50. Current GPAI Enforcement Baseline

From 2 August 2026, the European Commission’s enforcement powers for GPAI obligations apply, including the ability to enforce compliance and impose fines. AIGO should therefore treat GPAI compliance monitoring as a current governance requirement rather than a future readiness exercise.

51. Digital Omnibus Integration

The current mapping baseline must incorporate Regulation (EU) 2026/1744. The Digital Omnibus amended the AI Act’s implementation structure and supervision arrangements, including provisions concerning AI Office supervision of certain GPAI-based AI systems. AIGO should therefore review GPAI governance whenever supervisory allocations or statutory provisions are amended.

52. Regulatory Supervision

The current amended AI Act includes provisions allocating exclusive AI Office supervision and enforcement for certain GPAI-based AI systems, subject to specified exceptions. AIGO should record the applicable supervisory authority based on:

model;
system;
actor;
sector;
Annex I status;
Annex III status;
law-enforcement/border/financial-sector context;
other statutory conditions.

Internal governance should not assume that all GPAI matters are supervised identically.

53. GPAI Regulatory Interaction Control

Control Name: GPAI Regulatory Interaction Objective: Ensure that applicable communications, notifications, submissions, responses, and regulatory requests are controlled, approved, submitted, and retained. Evidence:

submission;
acknowledgment;
correspondence;
response;
decision;
follow-up.

54. GPAI Safety and Security Framework

For systemic-risk models, AIGO should maintain a documented safety and security framework covering:

threat model;
risks;
evaluations;
safeguards;
residual risk;
monitoring;
incident handling;
change management;
governance accountability.

The Commission’s current EU SEND information specifically references Safety and Security Framework and Model Report submissions under the GPAI Code of Practice.

55. GPAI Model Report

Where applicable, AIGO should maintain a controlled model report containing:

model identity;
architecture;
capabilities;
limitations;
evaluations;
safety/security information;
known risks;
mitigation;
changes;
review.

The exact legal or Code-of-Practice submission requirements should be determined from the current applicable source.

56. GPAI Code-of-Practice Governance

Where the organization adopts the Code of Practice:

Code Chapter
    ↓
Implementation Measure
    ↓
AIGO Control
    ↓
Evidence
    ↓
Assurance

The implementation should identify the Code measure and corresponding AIGO control.

57. Alternative Compliance Governance

Where the organization does not rely on the Code, AIGO should record:

statutory requirement;
alternative measure;
implementation;
rationale;
evidence;
assurance.

The alternative should be reviewed by appropriate legal/compliance authority.

58. GPAI Incident Escalation

Potential systemic-risk incidents should be escalated based on:

severity;
harm;
scale;
safety;
security;
rights impact;
regulatory significance.

The escalation chain should identify:

Operational Team
   ↓
Incident Owner
   ↓
AI Governance Owner
   ↓
Legal / Compliance
   ↓
Executive Authority
   ↓
AI Office / Competent Authority

The actual regulatory notification pathway depends on the legal role and applicable requirement.

59. GPAI Risk Register

AIGO should maintain GPAI risks such as:

GPAI_REGULATORY_RISK
GPAI_SYSTEMIC_RISK
GPAI_SAFETY_RISK
GPAI_SECURITY_RISK
GPAI_COPYRIGHT_RISK
GPAI_DATA_GOVERNANCE_RISK
GPAI_DOWNSTREAM_RISK
GPAI_SUPPLIER_RISK
GPAI_INCIDENT_RISK
GPAI_REPUTATIONAL_RISK

These should remain within the controlled AIGO risk taxonomy.

60. GPAI Control Matrix

GPAI Requirement Area	AIGO Control	Primary Record
Applicability	GPAI Applicability Control	Assessment
Provider Status	Provider Role Control	Governance / Assessment
Significant Modification	Modification Assessment	Change / Assessment
Systemic Risk	Systemic-Risk Determination	Risk / Assessment
Technical Documentation	GPAI Documentation Control	Evidence
Downstream Information	Downstream Information Control	Evidence
Copyright	Copyright Governance Control	Control / Evidence
Training Summary	Training-Content Summary Control	Evidence
Open Source	Open-Source Applicability Control	Assessment
Safety	GPAI Safety Control	Control / Assurance
Security	GPAI Security Control	Control / Assurance
Incident	GPAI Incident Control	Incident
Regulatory Submission	GPAI Regulatory Interaction Control	Approval / Evidence
Monitoring	GPAI Monitoring Control	Monitoring
Change	GPAI Change Control	Change
Assurance	GPAI Assurance Control	Assurance

61. GPAI Lifecycle Mapping

AIGO Lifecycle Stage	GPAI Governance
Planning	GPAI applicability
Design	Architecture / risk
Development	Data / training
Data Preparation	Training-data governance
Testing and Validation	Model evaluation
Approval	Regulatory and safety readiness
Deployment	Downstream information
Operation	Monitoring
Monitoring	Incident / systemic-risk monitoring
Change	Significant-modification review
Assurance	Independent assessment
Retirement	Records / downstream impact

62. GPAI Traceability Chain

The minimum governance chain is:

GPAI Model
    ↓
Provider
    ↓
Applicability
    ↓
Systemic-Risk Assessment
    ↓
Requirements
    ↓
Controls
    ↓
Evidence
    ↓
Regulatory Interaction
    ↓
Monitoring
    ↓
Incident / Change
    ↓
Assurance

63. GPAI Findings

Potential mapping findings include:

GPAI_APPLICABILITY_UNRESOLVED
PROVIDER_ROLE_UNRESOLVED
SIGNIFICANT_MODIFICATION_UNRESOLVED
SYSTEMIC_RISK_ASSESSMENT_MISSING
TECHNICAL_DOCUMENTATION_MISSING
DOWNSTREAM_INFORMATION_MISSING
COPYRIGHT_POLICY_MISSING
TRAINING_CONTENT_SUMMARY_MISSING
OPEN_SOURCE_STATUS_UNRESOLVED
SAFETY_FRAMEWORK_MISSING
SECURITY_FRAMEWORK_MISSING
SERIOUS_INCIDENT_CONTROL_MISSING
REGULATORY_SUBMISSION_CONTROL_MISSING
AI_OFFICE_INTERACTION_MISSING
GPAI_MONITORING_MISSING
GPAI_ASSURANCE_MISSING
GPAI_EVIDENCE_GAP
GPAI_TIMELINE_GAP
GPAI_REGULATORY_CHANGE_PENDING

64. Critical GPAI Gaps

Potential critical gaps include:

systemic-risk determination missing where potentially applicable;
legally required notification absent;
serious-incident reporting process absent;
mandatory technical documentation missing;
required downstream information unavailable;
required copyright policy absent;
required training-content summary absent;
safety/security governance absent for systemic-risk models;
regulatory submissions not controlled.

65. Evidence Requirements

Minimum evidence for a governed GPAI provider may include:

applicability assessment;
provider-role determination;
model documentation;
training-content summary;
copyright policy;
systemic-risk determination;
safety/security assessment;
evaluations;
notifications;
EU SEND submissions;
incidents;
corrective actions;
monitoring;
assurance.

Evidence requirements should be proportional to the actual legal obligations and actor role.

66. Assurance Requirements

Assurance should consider:

GPAI classification;
systemic-risk classification;
technical documentation;
safety/security;
regulatory submissions;
incident management;
evidence;
downstream governance;
change management.

Systemic-risk models should normally receive enhanced assurance.

67. Management Review

Management should periodically review:

GPAI portfolio;
systemic-risk models;
regulatory status;
incidents;
safety findings;
evidence gaps;
provider changes;
contractual issues;
upcoming deadlines;
official guidance changes.

68. Continuous Improvement

GPAI improvement should be driven by:

incidents;
assurance;
red-team findings;
regulatory feedback;
AI Office communication;
model changes;
downstream findings;
evidence gaps.

Improvements should be managed through the AIGO Improvement Schema.

69. Regulatory Source Currency

The GPAI mapping should be reviewed when:

the AI Act is amended;
the Digital Omnibus is amended;
Commission GPAI guidelines change;
the GPAI Code of Practice changes;
implementing or delegated acts are adopted;
AI Office processes change;
new official templates or submission mechanisms are introduced.

The current Commission GPAI page was updated in April 2026 and remains the principal official implementation reference used by this mapping version.

70. Review Frequency

Minimum review frequency:

annual;
event-driven after regulatory change;
after material AI Office guidance;
after material enforcement developments;
before major AIGO releases.

Event-driven review takes precedence.

71. 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 systems
`04-AIGO-EU-AI-Act-Transparency-Mapping-v0.1.md`	Article 50
`06-AIGO-EU-AI-Act-AI-Literacy-Mapping-v0.1.md`	AI literacy
`07-AIGO-EU-AI-Act-Governance-and-Enforcement-Mapping-v0.1.md`	Governance
`08-AIGO-EU-AI-Act-Conformity-and-Documentation-Mapping-v0.1.md`	Conformity
`09-AIGO-EU-AI-Act-Rights-and-Remedies-Mapping-v0.1.md`	Rights
`10-AIGO-EU-AI-Act-Annexes-Mapping-v0.1.md`	Annexes
`11-AIGO-EU-AI-Act-Applicability-and-Timeline-v0.1.md`	Dates and applicability
`12-AIGO-EU-AI-Act-AIGO-Control-Mapping-v0.1.md`	Control mapping
`13-AIGO-EU-AI-Act-Evidence-and-Assurance-Mapping-v0.1.md`	Evidence and assurance

72. Relationship to AIGO Schemas

GPAI Activity	AIGO Schema
Model identification	AI System
Applicability	Assessment
Provider role	Governance / Assessment
Systemic risk	Risk
Controls	Control
Testing	Assessment
Regulatory decision	Approval
Monitoring	Monitoring
Incident	Incident
Change	Change
Regulatory assurance	Assurance
Evidence	Evidence
Management review	Management Review
Improvement	Improvement
Retirement	Retirement

73. Relationship to AIGO Tools

GPAI mappings should be usable by:

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

74. EU AI Act GPAI Timeline Baseline

The current official baseline is:

2 August 2025
→ GPAI obligations apply

2 August 2026
→ Commission enforcement powers apply

2 August 2027
→ Providers of GPAI models placed on the market before
   2 August 2025 must comply

This timing is confirmed by the Commission’s current GPAI guidance. AIGO should preserve the distinction between:

obligation application;
enforcement authority;
transition for pre-existing models.

75. Current Legal Change Baseline

Regulation (EU) 2026/1744 entered into force on 27 July 2026 and amended the AI Act’s implementation and governance architecture. The GPAI mapping should therefore be reviewed against the amended legal text before approval and at each future regulatory-change event.

76. Compliance Status Model

AIGO should distinguish:

NOT_ASSESSED
APPLICABILITY_UNRESOLVED
APPLICABLE
NOT_APPLICABLE
IMPLEMENTATION_DEFINED
IMPLEMENTED
EVIDENCED
ASSESSED
ASSURED
EXCEPTION
SUPERSEDED

These states represent governance progress and should not be presented as formal legal certification.

77. Mapping Confidence

Potential values:

HIGH
MEDIUM
LOW
PENDING_INTERPRETATION

Confidence concerns the mapping quality and interpretation stability. It is not a legal certainty rating.

78. Validation Requirements

The GPAI mapping should satisfy:

Source Validation

Legal provisions and amendments are identified.

Applicability Validation

Provider and model status are defined.

Systemic-Risk Validation

Systemic-risk assessment is represented where relevant.

Control Validation

Applicable AIGO controls exist.

Evidence Validation

Required evidence is defined.

Regulatory Interaction Validation

Required submissions and communications are controlled.

Timeline Validation

Application and transition dates are current.

Traceability Validation

GPAI requirement → AIGO control → evidence chain is complete.

Consistency Validation

Terminology remains aligned with the master mapping and GPAI source material.

79. Limitations

This mapping cannot independently determine:

whether a specific model qualifies as GPAI;
whether a modification is legally significant;
whether a model presents systemic risk;
whether an open-source exemption applies;
whether a copyright policy satisfies applicable law;
whether training-content information is sufficient;
whether a safety or security framework is legally adequate;
whether an incident is legally “serious”;
whether an organization is compliant.

These questions require current law, factual analysis, technical evidence, and appropriate legal or regulatory review.

80. Document Control

Field	Value
Document	AIGO EU AI Act GPAI Mapping
Version	0.1
Status	Draft
Document Identifier	`AIGO-MAP-EUAI-005`
Document Type	EU AI Act Mapping
Primary Legal Source	GPAI provisions of Regulation (EU) 2024/1689
Amendment Baseline	Regulation (EU) 2026/1744
Owner
Legal/Compliance Reviewer
Governance Reviewer
Framework Architect
Approved By
Effective Date
Next Review Date

81. Document Status

Document: AIGO — EU AI Act GPAI Mapping Version: 0.1 Status: Draft Working Name: AIGO Full Name: AI Governance Operating Framework Document Identifier: AIGO-MAP-EUAI-005 Document Type: EU AI Act Mapping This document maps the EU AI Act’s general-purpose AI requirements to the AIGO AI Governance Operating Framework, including GPAI applicability, provider status, systemic risk, technical documentation, downstream information, copyright, training-content summaries, safety and security, incidents, AI Office interactions, regulatory submissions, monitoring, assurance, evidence, change management, and continual improvement. End of Document

​AIGO — EU AI Act GPAI Mapping

​1. Document Purpose

​2. Mapping Information

​3. Source Hierarchy

​3.1 Binding Legal Source

​3.2 Official Implementation Material

​3.3 AIGO Mapping

​4. GPAI Governance Principle

​5. GPAI Applicability

​6. AIGO GPAI Applicability Assessment

​7. AIGO GPAI Classification

​8. Provider Role Determination

​9. Significant Modification

​10. Open-Source Considerations

​11. Systemic-Risk Determination

​12. Systemic-Risk Governance Profile

​13. GPAI Provider Obligations

​14. Technical Documentation

​14.1 Legal Theme

​14.2 AIGO Mapping

​14.3 AIGO Control

​14.4 Evidence

​15. Information for Downstream Providers

​15.1 Legal Theme

​15.2 AIGO Mapping

​15.3 AIGO Control

​15.4 Evidence

​16. Downstream Traceability

​17. Copyright Policy

​17.1 Legal Theme

​17.2 AIGO Mapping

​17.3 AIGO Control

​17.4 Evidence

​18. Training-Content Summary

​19. Training Data Governance

​20. Model Evaluation

​21. Safety and Security

​22. GPAI Code of Practice

​23. AI Office Interaction

​24. EU SEND

​25. Systemic-Risk Notification

​26. Reassessment Requests

​27. Serious Incidents

​27.1 Legal Theme

​27.2 AIGO Mapping

​28. GPAI Incident Management

​29. Serious Incident Evidence

​30. Corrective Action

​31. Systemic-Risk Evaluation

​32. Red-Teaming

​33. Model Release Governance

​34. Model Change Governance

​35. Significant Modification

​36. Open-Source GPAI Governance

​37. Downstream Integration Governance

​38. Third-Party GPAI Due Diligence

​39. GPAI Procurement Gate

​40. GPAI Monitoring

​41. GPAI Evidence

​42. Evidence Coverage

​43. GPAI Control Coverage

​44. GPAI Assurance

​45. GPAI Management Review

​46. GPAI Improvement

​47. GPAI Retirement

​48. GPAI Regulatory Change

​49. Current GPAI Timeline

​50. Current GPAI Enforcement Baseline

​51. Digital Omnibus Integration

​52. Regulatory Supervision

​53. GPAI Regulatory Interaction Control

​54. GPAI Safety and Security Framework

​55. GPAI Model Report

​56. GPAI Code-of-Practice Governance

​57. Alternative Compliance Governance

​58. GPAI Incident Escalation

​59. GPAI Risk Register

​60. GPAI Control Matrix

​61. GPAI Lifecycle Mapping

​62. GPAI Traceability Chain