AI Governance Documentation Checklist: What to Have on File Before the 2027 Obligations Land

The EU AI Act calendar is now settled law rather than a forecast. The Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force on 27 July 2026 (European Commission). Stand-alone high-risk systems listed in Annex III now face their obligations from 2 December 2027; high-risk AI embedded in products covered by Annex I sectoral law follows on 2 August 2028. Separately, providers of general-purpose AI (GPAI) models placed on the market before 2 August 2025 must be compliant by 2 August 2027 (Commission GPAI guidelines). Two of those three dates fall in 2027, and the year-end planning cycle is the last full budget round before the first of them.

The deferral bought time for documentation, not an exemption from it. Most of what the Act requires is evidence: records that a process existed, ran, and was kept current. This checklist sets out what should be on file, who owns it, and where the same artefacts serve the NIST AI Risk Management Framework and ISO/IEC 42001.

Step zero: the inventory and classification record

Every other obligation depends on knowing which systems are in scope and in what role. Before any document below is drafted, the organisation needs:

• An AI system inventory covering systems built, bought, fine-tuned, or embedded in products, with owner, purpose, deployment geography, and model dependencies.
• A role determination per system. The Act assigns different duties to providers and deployers, and a deployer that substantially modifies a system or puts its own name on it can become a provider.
• A risk classification record stating whether each system is prohibited, high-risk under Annex I or Annex III, subject to Article 50 transparency duties, or minimal risk, with the reasoning written down. Where an Annex III system is judged not high-risk under the Article 6(3) exceptions, that assessment itself must be documented.
• A GPAI model register identifying any general-purpose models the organisation provides, their market-placement dates, and whether any are pre-August-2025 models inside the 2027 transition window. Our analysis of the GPAI enforcement window covers why that date applies per model, not per organisation.

Provider checklist for high-risk systems

For each system classified as high-risk, a provider should be able to produce the following before the applicable date.

Design and development evidence

• Risk management file (Article 9): identified risks to health, safety, and fundamental rights, mitigation measures, residual-risk acceptance, and evidence the process runs across the lifecycle rather than once.
• Data governance records (Article 10): training, validation, and test data provenance, collection and labelling processes, representativeness and bias examination, and identified data gaps. The Omnibus explicitly permits processing special categories of personal data to detect and correct bias, under safeguards.
• Technical documentation (Article 11 and Annex IV): system description and intended purpose, architecture, development methods, performance metrics, testing and validation results, and versioning. SMEs and, after the Omnibus, small mid-cap companies may use a simplified form.
• Accuracy, robustness, and cybersecurity evidence (Article 15): declared accuracy metrics and the test results supporting them. Our overview of AI model evaluation standards covers what credible evaluation evidence looks like.

Operational evidence

• Automatic logging design (Article 12): proof that the system records events over its lifetime sufficient for traceability. This is an engineering artefact, not a policy, and it is where most stacks fall short, as discussed in our piece on the high-risk evidence gap.
• Instructions for use (Article 13) written for deployers, including capabilities, limitations, and required oversight measures.
• Human oversight design (Article 14): what a human can see, override, or halt, and how that was tested.

Organisational evidence

• Quality management system (Article 17): documented policies and procedures covering compliance strategy, design control, data management, risk management, post-market monitoring, incident reporting, and record-keeping, proportionate to organisation size.
• Conformity assessment record and EU declaration of conformity (Articles 43 and 47), plus CE marking where applicable.
• EU database registration (Article 49) for Annex III systems.
• Post-market monitoring plan (Article 72) and a serious-incident reporting procedure (Article 73) with named owners and timelines.
• A retention plan. Article 18 requires providers to keep technical documentation, QMS documentation, and the declaration of conformity available to authorities for ten years after the system is placed on the market.

Deployer checklist

Organisations using high-risk systems built by others carry their own record-keeping:

• Use in line with instructions (Article 26): evidence that the system is operated within the provider’s stated intended purpose.
• Named human overseers with documented competence, training, and authority.
• Log retention: automatically generated logs under the deployer’s control kept for a period appropriate to the purpose, and at least six months.
• Worker notification where high-risk AI is used in the workplace.
• Fundamental rights impact assessment (Article 27) before first use, required for public bodies, private entities providing public services, and deployers of certain Annex III systems such as creditworthiness assessment and life or health insurance risk assessment and pricing. Where a GDPR data protection impact assessment already exists, the FRIA complements it rather than replacing it.

GPAI provider checklist

For models placed on the market before 2 August 2025, the 2027 deadline covers the Article 53 documentation set:

• Technical documentation for the AI Office and national authorities (Annex XI).
• Information and documentation for downstream providers integrating the model (Annex XII).
• A copyright policy, including how text-and-data-mining opt-outs are respected.
• A public summary of training content using the Commission’s template.
• For models with systemic risk, evaluation and adversarial testing records, incident tracking, and cybersecurity measures under Article 55.

Building one evidence base, not three

Most organisations operating internationally will be asked about NIST and ISO alignment as well as the EU Act. The frameworks overlap enough that a single evidence base can serve all three if it is structured deliberately.

The NIST AI Risk Management Framework (AI 100-1, 2023) and its Generative AI Profile (NIST AI 600-1, 2024) are voluntary, but their Govern, Map, Measure, and Manage functions map cleanly onto the Act’s process requirements. ISO/IEC 42001:2023 is a certifiable management-system standard; certification does not by itself demonstrate AI Act conformity, which will rest on harmonised European standards still being finalised, but the documented system it requires is most of what Article 17 asks for.

What to do before year-end

Fund the inventory and classification work in the coming budget cycle; nothing else can be scoped without it. Assign a named owner to each document type above. Treat logging and data provenance as engineering backlog items with delivery dates, because they cannot be written retroactively. Schedule a dry-run conformity review well before December 2027, using the gaps it exposes as the 2027 work plan. And date every artefact: an undated document is weak evidence that a process ran when it was supposed to.

This article is editorial analysis, not legal advice. Confirm obligations against the consolidated text of Regulation (EU) 2024/1689 as amended and with qualified counsel.