AI Model Attestation Planner
Describe your situation and get a plan: which attestations you need for an AI system, who can issue each one (you, your build platform, a signing service, a certification body or a notified body), the evidence each needs, and the order to do them in. It separates what the EU AI Act requires from what customers ask for and what is simply good practice.
Who this is for: GRC and compliance leads planning AI Act and customer assurance work, and CISOs who need to know which certificate is worth paying for. Not legal advice: confirm your classification with counsel.
What this tool is
- Tell it where you sell, whether you are provider or deployer, whether the system is high-risk under the EU AI Act, whether you provide a general-purpose AI model, and what customers ask for (ISO/IEC 42001, SOC 2, a signed AIBOM, signed models, SLSA provenance).
- It picks from 21 attestations and, for each, says who can issue it: you, your build platform, a signing service, an accredited certification body, a notified body, a CPA firm or a tester.
- Each attestation lists the evidence it needs, whether the law requires it or a customer asked, its current legal status, and where to link it from your AIBOM.
- The plan is ordered in five phases: classify, generate and sign at build, document, assess, then declare and maintain.
- Downloads: a PDF plan, a CSV and a JPG of the plan card.
- EU AI Act facts were checked on 29 October 2026, including the dates as amended by the Digital Omnibus on AI. Not legal advice.
EU AI Act: who assesses what
The route depends on the risk class, from Article 43. The provider is the one who assesses or arranges the assessment; a deployer collects the provider’s evidence and has its own duties under Article 26, and becomes the provider if Article 25 applies.
| System | Route | Who assesses | Where |
|---|---|---|---|
| Annex III point 1: biometrics | Internal control (Annex VI) or a notified body (Annex VII), if harmonised standards or common specifications were applied in full. Otherwise Annex VII. | You, or a notified body | Art. 43(1) |
| Annex III points 2 to 8 | Internal control (Annex VI). No notified body. | You | Art. 43(2) |
| Annex I products (e.g. medical devices, machinery) | The conformity assessment of the sector law, with the AI Act requirements added to it. | The sector’s notified body, where that law requires one | Art. 43(3) |
| Not high-risk | No AI Act conformity assessment. If an Annex III system is not high-risk under Art. 6(3), document why and register it. | You | Art. 6(4), 49(2) |
| General-purpose AI model | No conformity assessment. Documentation, copyright policy and training-content summary; more for systemic risk. The voluntary Code of Practice is one way to show compliance. | You; the AI Office supervises | Art. 53, 55 |
After the assessment, the provider of a high-risk system signs an EU declaration of conformity (Art. 47, kept for 10 years), affixes the CE marking (Art. 48) and, for Annex III systems, registers in the EU database (Art. 49; critical infrastructure registers nationally). Notified body certificates last at most four years for Annex III systems and five for Annex I (Art. 44).
The 21 attestations and who can issue each
Every attestation the planner can put in a plan. “Self” is not a weaker answer: most AI Act duties are the provider’s own, signed by an accountable person.
| Attestation | Issued by | What it attests | Status |
|---|---|---|---|
| AI Act role and risk classification | Self (you) | Whether you are provider or deployer, and whether the system is high-risk under Article 6 and Annexes I and III. | Article 6(4): a provider that considers an Annex III system not high-risk must document that assessment before placing it on the market, and Article 49(2) requires registering it. |
| AIBOM (self-declared) | Self (you) | What the AI system is made of: model, base model, datasets, libraries, services, with versions and digests. | No law requires an AIBOM by that name. It supplies much of the content of EU AI Act technical documentation. |
| Model signature | Signing service | These exact files were signed by this identity and have not changed since. | Proves integrity and who signed. Says nothing about how the model was trained or whether it is safe. |
| Build provenance (SLSA, in-toto) | Build platform | This artefact was produced by this build, from these inputs (base model revision, dataset digests, training config). | SLSA v1.2 is the current spec. Provenance covers only what ran in the attested build: if training ran on a separate GPU cluster and CI only packaged the weights, it attests the packaging. Record the training inputs in it anyway. It does not vouch for the data or the model’s behaviour. |
| Signed AIBOM | Signing service | This AIBOM was issued by you and has not been altered. | A signature proves who issued the BOM, not that its contents are true. Pair it with build provenance. |
| Technical documentation (Annex IV) and quality management system (Art. 17) | Self (you) | The system and how it was built, tested and is controlled, as Annex IV lists; and a documented QMS. | Applies with the high-risk rules: 2 December 2027 for Annex III systems, 2 August 2028 for Annex I products (AI Act Service Desk timeline, after the Digital Omnibus on AI). ISO/IEC 42001 can help build the QMS, but a 42001 certificate is not an AI Act conformity assessment. |
| Conformity assessment: internal control (Annex VI) | Self (you) | You checked that your QMS, technical documentation and post-market monitoring meet the AI Act requirements. | Article 43(2): the route for Annex III points 2 to 8. Also an option for Annex III point 1 when harmonised standards or common specifications were applied in full. |
| Conformity assessment with a notified body (Annex VII) | Notified body | A notified body assessed your quality management system and technical documentation, and issued an EU technical documentation assessment certificate. | Article 43(1): required for Annex III point 1 (biometrics) where harmonised standards or common specifications do not exist or were not applied in full. Certificates last at most four years for Annex III systems (Art. 44). Check the Commission’s NANDO database for bodies notified under Regulation (EU) 2024/1689: trackers reported none listed as of late October 2026, which we could not verify. |
| Sectoral conformity assessment covering the AI Act (Annex I) | Notified body | The product’s existing conformity assessment (e.g. under the medical devices or machinery rules) also covers the AI Act requirements. | Article 43(3). Annex I high-risk rules apply from 2 August 2028 (AI Act Service Desk timeline). Certificates last at most five years for Annex I systems (Art. 44). |
| EU declaration of conformity (Art. 47) and CE marking (Art. 48) | Self (you) | You declare that the high-risk system meets the AI Act requirements. | Applies with the high-risk rules (2 December 2027 for Annex III, 2 August 2028 for Annex I). |
| EU database registration (Art. 49) | Self (you) | The provider and the high-risk system are registered before it is placed on the market. | Applies to Annex III systems with the high-risk rules. Not required by Art. 49 for Annex I products. |
| Provider evidence for a high-risk system you deploy | Self (you) | The system you deploy has been assessed, declared and registered by its provider. | You become the provider yourself if you put your name on the system, substantially modify it, or change its intended purpose so it becomes high-risk (Art. 25). |
| Deployer records (Art. 26) | Self (you) | You use the system per its instructions, with assigned human oversight, monitoring and log retention. | Applies with the high-risk rules. Public-authority deployers also register their use (Art. 49(3)). |
| Fundamental rights impact assessment (Art. 27) | Self (you) | You assessed the impact on fundamental rights before first use, and notified the market surveillance authority. | Required for deployers that are bodies governed by public law or private entities providing public services, and for deployers of Annex III point 5(b) and (c) systems (creditworthiness, life and health insurance pricing). Not for Annex III point 2. |
| GPAI model documentation (Annex XI and XII) | Self (you) | Technical documentation for the AI Office and authorities, and information for providers who integrate your model. | Since 2 August 2025 (models placed on the market before then: by 2 August 2027). Commission enforcement powers from 2 August 2026. Open-source models (weights, architecture and usage information public, free and open-source licence) are exempt from this item unless they have systemic risk (Art. 53(2)). |
| Copyright policy and public training-content summary (Art. 53(1)(c), (d)) | Self (you) | You comply with EU copyright law, including text-and-data-mining opt-outs, and you publish a summary of the training content. | Applies to all GPAI providers, open-source included. The Code of Practice (published 10 July 2025, voluntary) is one way to demonstrate compliance with Article 53. |
| Systemic-risk obligations (Art. 55) | Self (you) | You evaluate the model (including adversarial testing), assess and mitigate systemic risks, report serious incidents and protect the model’s cybersecurity. | Applies to GPAI models with systemic risk since 2 August 2025. |
| ISO/IEC 42001 certificate | Accredited certification body | Your AI management system meets ISO/IEC 42001. | Voluntary. It certifies the management system, not a model. It is not an EU AI Act conformity assessment. A self-declared "42001-aligned" is not a certificate. |
| SOC 2 report covering the AI service | Independent CPA firm | A CPA firm’s opinion on your controls against the AICPA Trust Services Criteria. | An attestation report, not a certificate, and not AI-specific. Check the scope actually includes the model and training pipeline. |
| Red-team or penetration test report | Independent tester | The system was tested for prompt injection, jailbreaks, data leakage and tool misuse, with findings and fixes. | Not a certification. A report is dated and covers one version. |
| Model card | Self (you) | What the model is for, how it was trained and evaluated, and its limits. | Not a legal form. For GPAI providers, Annex XII information covers much of it. |
Worked example: Northwind’s plan
Northwind Health and its Triage Assistant are fictional, used across the AIBOM Library.
Northwind fine-tunes Mistral-7B-Instruct-v0.3 into a support assistant that drafts replies for human agents. It sells to enterprise customers in the EU and US. Drafting support replies is not an Annex III use, its legal team concluded that a small LoRA fine-tune does not make it the provider of a general-purpose AI model, and customers ask for a signed AIBOM and a SOC 2 report. The plan has 7 items and none is required by the AI Act:
- AI Act role and risk classification (recommended, phase 1: classify and scope). Self (you).
- AIBOM (self-declared) (customer asks, phase 2: generate and sign at build). Self (you).
- Signed AIBOM (customer asks, phase 2: generate and sign at build). Signing service.
- Model signature (recommended, phase 2: generate and sign at build). Signing service.
- Build provenance (SLSA, in-toto) (recommended, phase 2: generate and sign at build). Build platform.
- Model card (recommended, phase 3: document). Self (you).
- SOC 2 report covering the AI service (customer asks, phase 4: assess). Independent CPA firm.
The order matters. The signed AIBOM a customer asked for is only as good as what backs it, so the model signature and the build provenance are produced in the same pipeline run, then linked from the AIBOM, then the AIBOM is signed. The SOC 2 report is the slowest item, because a Type 2 report needs an observation period; start it first in calendar terms even though it sits in phase 4.
Read more
The reasoning behind this tool is in who can attest to an AI model, and to what. For a hands-on signing walk-through, see sign a model and attach provenance. For which AIBOM field proves which requirement, see the AIBOM as compliance evidence; for the documentation itself, Annex IV item by item and the GPAI Model Documentation Form. Before a model goes live, run it through the AI Model Intake and Approval Checklist. Everything else is on the AIBOM Library hub.
What it does not cover
Sector rules outside the AI Act (financial, medical, public procurement), national implementing laws, US state AI laws, and the content of harmonised standards. It does not tell you whether your system is high-risk; it asks you. It is not legal advice.
Sources
Checked on 29 October 2026. Article summaries are from the AI Act Service Desk; the legal text is on EUR-Lex.
- AI Act Service Desk: implementation timeline (reflects the Digital Omnibus on AI)
- AI Act Article 43: conformity assessment
- AI Act Article 44: certificates
- AI Act Article 47: EU declaration of conformity
- AI Act Article 49: registration
- AI Act Article 25: responsibilities along the AI value chain
- AI Act Article 26: obligations of deployers
- AI Act Article 27: fundamental rights impact assessment
- AI Act Article 53: obligations for providers of GPAI models
- European Commission: the General-Purpose AI Code of Practice
- Regulation (EU) 2024/1689 on EUR-Lex
- ISO/IEC 42006:2025, requirements for bodies certifying AI management systems
- SLSA v1.2 specification (Build levels)
- OpenSSF model signing (sigstore/model-transparency)
- Sigstore blog: model signing v1.0
- CycloneDX 1.7 JSON schema (externalReferences types, declarations, signature)
Frequently asked questions
Who can certify an AI model?
It depends what you want certified. Nobody issues a general "this model is safe" certificate. Under the EU AI Act, a notified body assesses some high-risk systems (Annex III biometrics without full harmonised standards, and Annex I products whose sector law needs one); most other high-risk systems are self-assessed by the provider. An accredited certification body certifies your AI management system to ISO/IEC 42001, not a model. A CPA firm issues SOC 2 reports. Signatures and build provenance are attestations from a signing service and a build platform, not certifications.
Does the EU AI Act require a notified body?
Only for some high-risk systems. Article 43 sends Annex III point 1 (biometrics) to a notified body under Annex VII when harmonised standards or common specifications were not applied in full. Annex III points 2 to 8 use internal control under Annex VI, with no notified body. AI in Annex I products follows the sector law, which may involve that sector’s notified body. General-purpose AI models have no conformity assessment.
Is ISO 42001 certification enough for the EU AI Act?
No. ISO/IEC 42001 certifies an AI management system. It can supply much of the quality management system the Act asks providers of high-risk systems to have, but the certificate is not a conformity assessment, it does not cover a specific system’s technical documentation, and it does not replace the declaration of conformity.
What is the difference between signing a model and SLSA provenance?
A signature says who signed these exact files and that they have not changed. Provenance says which build produced them and from which inputs. You sign the model with a signing service such as Sigstore. The build platform issues the provenance; at SLSA Build L2 a hosted platform signs it, and at L3 the platform is hardened so build steps cannot reach the signing key. You usually want both.
When do the EU AI Act high-risk rules apply?
The AI Act Service Desk timeline, which reflects the Digital Omnibus on AI, gives 2 December 2027 for high-risk systems in Annex III and 2 August 2028 for AI in Annex I products. GPAI rules have applied since 2 August 2025, and the Article 50 transparency rules from 2 August 2026. Check the timeline before you plan; these dates have moved before.
Can I self-attest an AIBOM?
Yes, and that is what an AIBOM is by default: your claim about your system. Signing it proves you issued it and it was not altered. Linking a model signature and build provenance from it makes the key claims checkable. CycloneDX can carry formal claims and evidence in its declarations section and an enveloped signature.
More free security tools
The tools people use most on PlayCISO.
Catch injected instructions hiding in content your AI agent should only read.
Score your readiness against the first international standard for AI security threats.
Critical CVEs across 21 major vendors, month by month — and what the 2026 surge means.
Build an ordered ruleset, replay labelled packets and catch shadowed and any-to-any rules.
Self-assess all six Functions, from Govern to Recover, and see your weakest one.
Search 172 threat actors across Microsoft, CrowdStrike, Mandiant and community names.