GPAI Enforcement Has Begun: What Belongs in the AI Governance File Now
EU AI Act · GPAI · General-Purpose AI · AI Office · Model Governance · AI Risk Management · AI Compliance · GRC
The EU AI Act has entered a more serious phase. From 2 August 2026, the European Commission's AI Office can begin enforcing obligations related to general-purpose AI models. For model providers, this is a direct regulatory milestone. For enterprises that build, fine-tune, integrate, or deploy GPAI-powered systems, it is also a governance signal: AI risk evidence needs to become structured, repeatable, and board-legible.
The useful way to think about this is the AI governance file. Not one document, and not a static binder, but a living evidence set that shows how the organisation understands, controls, and monitors its AI dependencies.
The first section should be the model inventory. It should identify which GPAI models are used, who provides them, where they are deployed, whether they are accessed through APIs or embedded products, whether they are fine-tuned, and which business processes depend on them. Shadow AI makes this difficult, but not optional. You cannot govern models you cannot name.
The second section should cover role analysis. The AI Act distinguishes between providers, deployers, importers, distributors, product manufacturers, and downstream providers. An enterprise that simply uses a model may have different obligations from one that substantially modifies it or places an AI system on the market. The governance file should record the role assessment for each material AI use case and the reasoning behind it.
The third section should cover provider due diligence. Organisations should collect model cards, technical documentation, safety summaries, terms of use, data-processing terms, copyright commitments, security information, incident notification commitments, and any statements about compliance with the GPAI Code of Practice. The question is not "is this vendor famous?" The question is whether the organisation can show why the model is appropriate for the intended use.
The fourth section should cover risk assessment. For high-impact use cases, the file should document intended purpose, foreseeable misuse, data sensitivity, human oversight, output reliance, monitoring, and fallback procedures. If the AI system supports customer decisions, security operations, hiring, financial services, healthcare, or legal processes, the risk assessment should be more than a generic questionnaire.
The fifth section should cover transparency and copyright. GPAI obligations include transparency and copyright-related requirements for providers, but deployers also need to understand what evidence flows downstream. Can the organisation explain when users interact with AI? Can it label generated content where required? Can it show that vendor commitments around training data summaries, copyright policy, and content marking were reviewed?
The sixth section should cover AI incidents. Organisations should define what counts as an AI incident or serious AI-related event, who investigates it, when legal is involved, and whether external notification may be required. Incident records should include prompts, outputs, logs, model version, user context, downstream impact, and remediation.
The AI governance file should not be built only for regulators. It helps procurement make better decisions, security teams understand exposure, legal teams assess obligations, and executives see AI risk as part of enterprise risk. As GPAI enforcement begins, mature organisations will not rely on scattered vendor PDFs and meeting notes. They will govern AI with the same discipline they expect from security, privacy, and operational resilience.
Suggested sources:
https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers