Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
Which AI governance artifacts should you keep?
Updated
Keep an AI system inventory with a risk classification per system, a risk assessment per system, model and dataset documentation, human-oversight records, records of AI-assisted changes to your own code, and post-deployment monitoring output.
AI-governance evidence map, last verified 10 September 2026 against Regulation (EU) 2024/1689 (the EU AI Act), ISO/IEC 42001:2023, ISO/IEC 23894:2023, and the NIST AI Risk Management Framework (AI 100-1). The AI Act applies in phases and its obligations differ sharply by risk tier and by whether you are a provider or a deployer, so re-verify the applicable dates. This page is not legal advice, does not determine YOUR obligations, does not classify your systems under any risk tier, does not start a clock, and does not file with the AI Office, a notified body, or an auditor.
What this page is, and what it is not
Audience: an engineering or product leader who ships software that uses machine-learning models, or whose team writes code with AI assistance, and who has been asked what any of that has to be able to prove.
This page is not legal advice. It does not determine YOUR obligations, does not classify any of your systems as prohibited, high-risk, limited-risk or minimal-risk under the EU AI Act, does not decide whether you are a provider or a deployer, does not start any clock, and does not file with the AI Office, a notified body, or an auditor. Classification is the decision that drives almost every obligation, and it is a legal one. Last verified 10 September 2026.
The single most useful thing to understand is that the AI Act's weight lands very unevenly. Most obligations attach to providers of high-risk systems and to general-purpose model providers. A company using a commercial assistant to help write code, or embedding a third-party model in a low-stakes product feature, is in a very different position from a company placing a high-risk system on the EU market — and the evidence set scales accordingly. Building high-risk documentation for a minimal-risk feature wastes money; assuming minimal risk without a recorded assessment is the failure mode in the other direction.
- The inventory is the foundational artifact. You cannot classify, assess, or monitor systems you have not enumerated — and shadow AI use is the norm, not the exception.
- Provider versus deployer changes everything. The same model can put you in either role depending on what you do with it, and fine-tuning or rebranding can move you.
- Third-party models do not remove your obligations, they distribute them. Keep the vendor's documentation as evidence, and keep your own record of how you evaluated and constrained the system.
- AI-assisted coding is a software-assurance question first. It touches your change-management and code-review evidence more than it touches AI Act obligations for most teams.
AI-governance-artifact-to-requirement map
First column is the artifact, second what it has to contain to be useful, third the requirement or criterion it maps to, fourth the common failure. Nothing here classifies your systems. Last verified 10 September 2026. Not legal advice.
| Artifact | What it must contain | Requirement or criterion it maps to | Common failure |
|---|---|---|---|
| AI system inventory | Every AI or machine-learning system in use or shipped: purpose, model and version, provider, whether you are provider or deployer, data it touches, decisions it influences, human-oversight arrangement, and owner | Prerequisite for every EU AI Act obligation; ISO/IEC 42001:2023 requires the organisation to determine the AI systems in scope of its management system; NIST AI RMF Map function as guidance. | Only the flagship model feature is listed, while a dozen assistants, embedded vendor features, and internal scripts calling a hosted model are not. |
| Risk classification record per system | The classification reached, the reasoning, the Annex or criteria consulted, the named decision-maker, the date, and any legal advice taken | The gateway to EU AI Act obligations, which differ by tier; ISO/IEC 42001 Clause 6 planning and risk assessment. | A classification asserted with no reasoning, so it cannot be defended or revisited when the system's use changes. |
| AI risk assessment per system | Identified risks including to health, safety and fundamental rights where relevant, likelihood and impact, treatment decisions, residual risk, and the review date | EU AI Act risk-management-system requirements for high-risk systems; ISO/IEC 42001 Clause 6 and ISO/IEC 23894:2023 as the AI risk-management guidance; NIST AI RMF Measure and Manage. | A generic security risk assessment reused, which misses AI-specific risks: bias, drift, hallucination, prompt injection, training-data provenance, and over-reliance. |
| Technical documentation for the system | Intended purpose, design, architecture, data requirements, capabilities and known limitations, performance metrics, and the human-oversight design | EU AI Act technical-documentation obligations for high-risk systems (Annex IV as written); ISO/IEC 42001 Clause 7.5 documented information. | Documentation written for the launch and never updated, so it describes a model version no longer in production. |
| Dataset and data-governance documentation | Training, validation and testing data: provenance, collection method, licensing basis, preparation steps, known gaps and bias examination, and personal-data lawful basis where applicable | EU AI Act data and data-governance requirements for high-risk systems; ISO/IEC 42001; GDPR where personal data is processed. | Provenance that cannot be reconstructed because the dataset was assembled ad hoc. This is not recoverable later, which is why it is worth recording at the time. |
| Model evaluation and testing records | What was tested, against which data, the metrics and thresholds, results per version, and the accept-or-reject decision with the named decision-maker | EU AI Act accuracy, robustness and cybersecurity expectations for high-risk systems; ISO/IEC 42001 Clause 9 performance evaluation; NIST AI RMF Measure. | Evaluation numbers in a notebook with no record of which model version produced them. |
| Human-oversight records | Who reviews what, the review capability and authority to override or halt, the training those reviewers received, and samples of oversight actually exercised | EU AI Act human-oversight requirements for high-risk systems and deployer duties; ISO/IEC 42001; NIST AI RMF Govern. | Oversight described in the design but never evidenced in operation. A human in the loop who has never overridden anything, with no review record, is a claim rather than a control. |
| Transparency and disclosure records | The user-facing disclosures made, where and when, including synthetic-content marking where applicable, and the version history of that copy | EU AI Act transparency obligations, which reach certain systems regardless of high-risk classification. | Disclosure shipped once and quietly removed in a redesign, with no record of the change. |
| Post-deployment monitoring output | Ongoing performance, drift, error and complaint monitoring; the thresholds; and the record of action taken when thresholds were crossed | EU AI Act post-market monitoring for high-risk systems; ISO/IEC 42001 Clause 9; NIST AI RMF Manage; NIST SP 800-137 as continuous-monitoring guidance. | Dashboards with no thresholds, so nothing ever triggers and there is no record of a decision. |
| Serious-incident and malfunction records | What happened, when awareness occurred, the assessment, the reporting decision with reasoning, and any submission with its receipt | EU AI Act serious-incident reporting for high-risk systems; ISO/IEC 42001 Clause 10; the incident-evidence expectations in the AICPA and ISO/IEC 27001 criteria. | AI failures triaged as ordinary bugs, so the record does not exist when a reporting question is raised. |
| Third-party model and vendor documentation | The provider's documentation, model or system cards, terms covering your permitted use, security review, and your own evaluation record | Deployer duties under the EU AI Act; ISO/IEC 42001 supplier requirements; ISO/IEC 27001:2022 Annex A 5.19 to 5.23 supplier relationships. | Relying on a vendor's compliance claims with no copy retained and no independent evaluation of fitness for your use. |
| AI literacy and training records | Who was trained, on what, when, and the material version — for the people who build, operate, and oversee AI systems | EU AI Act AI-literacy expectations for providers and deployers; ISO/IEC 42001 Clause 7.2 competence. | General security awareness training counted as AI literacy. They are different subjects. |
| AI-assisted code records | Which changes were AI-assisted, the review they received, and the assurance activity applied — usually via commit trailers or markers plus your normal review evidence | Not a named EU AI Act obligation for ordinary software teams. Maps to change-management and secure-development criteria: AICPA TSC CC8.1; ISO/IEC 27001:2022 Annex A 8.28; NIST SP 800-218. | Treating this as an AI Act matter and missing the real point, which is that AI-assisted changes need at least the review rigour of human-authored ones. |
| Governance and policy records | Your AI policy, acceptable-use rules, roles and responsibilities, the management review record, and internal audit output where you run a management system | ISO/IEC 42001 Clauses 5, 9.2 and 9.3; NIST AI RMF Govern; AICPA TSC CC1 series for the control environment. | A policy published and never reviewed, with no record of who owns AI decisions. |
Legal obligation, certification, and best practice — separated
AI governance attracts more conflation of these three than any other topic in this cluster. The AI Act is law with phased application and tier-dependent duties. ISO/IEC 42001 is a certification you choose to seek. The NIST AI RMF is voluntary guidance. Confusing them produces both over-building and under-building. The dates and tier descriptions below were verified on 10 September 2026 against the Regulation as published; the AI Act is being implemented through further acts and guidance, so re-verify. Not legal advice.
| Statement | Which kind of authority | What it does not mean |
|---|---|---|
| Regulation (EU) 2024/1689 (EU AI Act) entered into force in 2024 and applies in phases: prohibitions and AI-literacy provisions first, general-purpose AI model obligations next, and the bulk of high-risk obligations later, with some obligations for high-risk systems embedded in regulated products running to the longest date. | Legal requirement, by tier and by role, for systems and models placed on or used in the EU market. | Does not mean every obligation is live today, and does not mean any obligation reaches your systems. Phasing, tier, and provider-versus-deployer role all have to be determined — and the implementing acts and guidance continue to arrive. Verify current dates against the Regulation and the AI Office. |
| Prohibited practices under the AI Act, which apply irrespective of documentation quality. | Legal prohibition. | Not a documentation exercise. No evidence set makes a prohibited practice permissible. |
| High-risk system obligations: risk management, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy, robustness and cybersecurity, conformity assessment, and post-market monitoring. | Legal requirement for providers of high-risk systems in scope, with distinct and lighter duties for deployers. | Does not apply to systems that are not high-risk. Whether yours is high-risk depends on the Annexes and on use, and is a legal determination this page does not make. |
| Transparency obligations for certain systems — for example interaction disclosure and marking of synthetic content. | Legal requirement where the system falls within those provisions, independent of high-risk classification. | Does not mean every product using a model needs a banner. Read the provisions against your actual use. |
| General-purpose AI model provider obligations, including technical documentation and copyright-policy duties, with additional duties for models presenting systemic risk. | Legal requirement for providers of such models. | Does not apply because you call somebody else's model through an API. It can, however, apply if you fine-tune or place a model on the market such that you become a provider — a role question for counsel. |
| ISO/IEC 42001:2023 AI management system. | Certification requirement, and only where you choose to seek or hold certification. | Not a legal obligation, and not the AI Act. It is a credible way to organise the evidence, and it overlaps substantially with AI Act documentation, but certification is not conformity with the Regulation. |
| ISO/IEC 23894:2023 AI risk-management guidance and the NIST AI Risk Management Framework (AI 100-1). | Industry best practice and voluntary guidance. | Neither is binding. Both are reasonable bases for your method; cite them as such, not as requirements. |
| Maintain a single AI inventory with a recorded classification and owner per system, and revisit it when a system's purpose changes. | ShipReady Metrics recommendation, and common industry best practice. | Not a legal determination and not a substitute for advice on classification. It is the artifact everything else depends on. |
| Record which changes to your own codebase were AI-assisted, and apply at least your normal review rigour to them. | ShipReady Metrics recommendation, aligned with secure-development best practice. | Not required by the AI Act for ordinary software development. It is a software-assurance and change-management practice, and it is how you answer a customer questionnaire honestly. |
Checklist
A question list for the AI side of your evidence set. Not a classification of your systems and not a determination that the AI Act, ISO/IEC 42001, or anything else applies to you. Last verified 10 September 2026. Not legal advice.
- Do we have one inventory that lists every AI system we ship and every one we use internally, including vendor features and assistants?
- Does each entry record whether we are the provider or the deployer for that system?
- Is there a written risk classification per system with reasoning, a named decision-maker, and a date?
- Is there an AI-specific risk assessment per system, covering bias, drift, hallucination, prompt injection, data provenance, and over-reliance — not a recycled security assessment?
- Can we reconstruct the provenance and licensing basis of the data used to train or fine-tune anything we built?
- Are evaluation results tied to specific model versions, with thresholds and an accept-or-reject decision?
- Is human oversight evidenced in operation — reviews performed, overrides exercised, reviewers trained — and not only in the design document?
- Do we hold the version history of user-facing AI disclosures?
- Does post-deployment monitoring have thresholds, and is there a record of action when they were crossed?
- Are AI failures recorded as AI incidents rather than triaged silently as bugs?
- Do we retain vendor model documentation and terms, plus our own evaluation of fitness for our use?
- Is AI literacy training recorded separately from general security awareness?
- Can we identify which changes to our codebase were AI-assisted, and show the review they received?
- Does someone own AI governance by name, and is there a management-review record?
What to do now
Ordered so the artifact everything depends on comes first. None of these steps classifies a system, determines an obligation, starts a clock, or files with the AI Office.
- Build the inventory this week, and go wider than you expect: ask each team what models and assistants they call, including vendor features enabled by default.
- For each entry, record provider or deployer role and a preliminary classification with reasoning — then take advice on the ones that plausibly sit in a regulated tier.
- Add AI-specific risks to your risk register rather than folding them into generic security risk. Bias, drift and provenance have no home in a standard security assessment.
- Start recording dataset provenance now for anything you train or fine-tune. It is the one artifact that cannot be reconstructed afterwards.
- Tie every evaluation result to a model version, and store the accept-or-reject decision with it.
- Make human oversight produce a record: log reviews and overrides, so the control is evidenced rather than asserted.
- Set thresholds on the monitoring you already have, so crossing one produces a decision and a record.
- Mark AI-assisted changes in your version-control history and confirm they receive at least your normal review.
- Re-verify the AI Act phasing and tier descriptions above against the Regulation and the AI Office annually and record the date. Ours says 10 September 2026.
Where this shows up in ShipReady Metrics
Only shipped behaviour is described here. This product does not classify your AI systems under any risk tier, does not perform conformity assessment, does not evaluate your models, does not file with the AI Office or a notified body, and does not produce a certification.
There is an AI inventory and an AI risk register, mapped against ISO/IEC 42001 and EU AI Act structures, plus AI ROI scoring. The obligation map lists frameworks your organisation marked in-scope — including AI frameworks — and that mark is your organisation's statement, not a legal opinion that a framework applies.
There is an AI-authored-code floor derived from counting git markers in your history. It is a floor: it counts what was marked, so unmarked AI-assisted work is invisible to it, and the number is a lower bound rather than a measurement. Treat it as a signal for your own assurance conversation, not as a compliance figure.
If you already have a session: signed-in app → Compliance holds evidence collection for control-mapped artifacts across starter control subsets, and evidence review, where a named human accepting a manual row renders it met and rejecting it renders it a gap, with a timestamp. Most AI-governance artifacts arrive as manual rows. That produces a timestamped compliance artifact — not a downloadable evidence binder, not a regulator filing pack, and not an auditor's opinion. Readiness figures are internal indicators, not certification, CE marking, or a conformity declaration.
Primary sources (last verified 10 September 2026)
Each source is labelled by the kind of authority it carries.
Regulation (EU) 2024/1689 (the EU AI Act) is a legal instrument, applying in phases and by risk tier and role; its implementing and delegated acts and the AI Office's guidance continue to develop, so treat any date as needing re-verification. ISO/IEC 42001:2023 is a certification requirement where you seek certification. ISO/IEC 23894:2023 and the NIST AI Risk Management Framework (AI 100-1) are voluntary guidance and industry best practice. AICPA Trust Services Criteria CC1 and CC8.1, ISO/IEC 27001:2022 Annex A 8.28 and the supplier controls, and NIST SP 800-218 carry the software-assurance side. Not a complete list, and not legal advice.
The EU AI Act cluster covers the Regulation's structure and its incident-reporting path; the framework guides cover ISO/IEC 42001 and the AI Act at a level above the evidence set.
Frequently asked questions
Is this legal advice?
No. It is an operational mapping of AI governance activity to evidence, with each source labelled by the kind of authority it carries. Whether the EU AI Act reaches your systems, which risk tier they fall in, and whether you are a provider or a deployer are legal determinations for counsel. This page does not classify your systems, does not determine YOUR obligations, does not start a clock, and does not file with the AI Office.
We only use a commercial coding assistant. Do we need any of this?
Far less of it. For most teams AI-assisted coding is a software-assurance question, not an EU AI Act one: mark which changes were AI-assisted, apply at least your normal review rigour, and be able to answer a customer questionnaire honestly. Keeping an inventory entry and an acceptable-use rule is proportionate. Building high-risk technical documentation for that use is not.
Does ISO/IEC 42001 certification make us EU AI Act compliant?
No. ISO/IEC 42001 is a management-system certification you choose to seek; the AI Act is law with tier-dependent obligations and its own conformity route. The documentation overlaps substantially, and 42001 is a sensible way to organise the evidence, but certification is not conformity with the Regulation and no certificate substitutes for the Act's own requirements.
Which AI artifact is hardest to produce late?
Dataset provenance. Performance metrics can be re-measured, documentation can be written, and oversight can start producing records from today. How a training set was assembled, under what licence, and with what known gaps generally cannot be reconstructed once the people and the intermediate files are gone. Start recording it before you need it.
What does the AI-authored-code figure in ShipReady Metrics actually measure?
It counts AI-authorship markers present in your git history, which makes it a floor rather than a measurement — unmarked AI-assisted work does not appear in it. Use it as a signal for your own assurance conversation. It is not a compliance metric, and it is not evidence of conformity with anything.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.