EU AI Act Technical Documentation in Safeguard: Scans, AI-BOM, Controls

Safeguard helps with the software and component side of EU AI Act technical documentation. Its EU AI Act framework, part of the Compliance and GRC suite (GA), checks six requirements on every product scan against the product's software inventory: component documentation, version traceability, integrity, value chain suppliers, dated records and machine-readable composition data. Everything else the Act asks for, from your risk management system to human oversight, is a catalogue control that you evidence yourself, and the decision on whether your system is high-risk stays with you.

This post is product education, not legal advice. It explains what Regulation (EU) 2024/1689 asks for in Articles 11, 12, 13, 15 and 25 and Annex IV, what a Safeguard scan can and cannot decide about those provisions, where AI-BOM discovery (early access) fills gaps in the inventory, and the exact steps to switch the framework on, read the results and attach evidence. Where a question turns on how the Act applies to your system, ask your counsel or your notified body.

Key takeaways

• The Compliance and GRC suite (GA) includes an EU AI Act framework, on in your workspace unless someone switches it off in Compliance › Manage.
• Six requirements are decided by a scan (EU-AIA-11, 11V, 15, 25, 12 and 13). They read the product's software inventory, so SBOM generation and analysis (GA) is the foundation.
• Catalogue controls for Article 9 risk management, Article 10 data governance, Article 14 human oversight and the rest need evidence you supply. A compliance reviewer accepts it; Safeguard's assistant never does.
• AI-BOM discovery (early access) adds AI-specific assets a dependency scan does not describe well. AI-SPM model artifact scanning (early access) inspects model files. An administrator switches both on.
• Attestation and signing (GA), policies, gates and guardrails (GA) and Lino evidence mapping (GA) support integrity, release control and drafting.
• You can read results in Claude through Safeguard's community listing in the Claude connector directory; the MCP server (GA) tools used here are read only.
• Dates moved. Under the Digital Omnibus on AI, Annex III high-risk obligations apply from 2 December 2027 and Annex I obligations from 2 August 2028.
• A readiness score is not a conformity assessment. Safeguard does not classify your system, assess conformity or affix CE marking.

The problem: Annex IV asks for a software story most teams cannot tell

A high-risk AI system is not just a model. It is a model plus an inference server, a retrieval layer, an orchestration framework, a dozen SDKs and a container base image. When a team is asked to "write the technical documentation", the model card is usually ready. The rest of the stack is not.

Annex IV makes the rest of the stack part of the documentation: versions of relevant software, interaction with other software and AI systems, third-party pre-trained systems and tools, how components feed into each other, and cybersecurity measures. That is an inventory question before it is a writing question, and it gets harder for three reasons.

The inventory changes every release. Article 11(1) requires the documentation to exist before the system is placed on the market or put into service and to be "kept up-to date". A spreadsheet built for the first assessment is stale by the second sprint.

The inventory must be traceable for years. Article 18 requires providers to keep technical documentation available to national competent authorities for 10 years after the system is placed on the market or put into service.

The value chain is shared. Article 25(4) requires a written agreement between the provider and each third party that supplies AI systems, models, tools, services, components or processes integrated into the high-risk system. You cannot write those agreements without knowing who is in the stack.

Which obligations apply when?

The AI Act entered into force on 1 August 2024. The Commission's AI Act page says it became applicable on 2 August 2026 with exceptions, and that the Digital Omnibus on AI (proposed 19 November 2025, political agreement 7 May 2026, in force 27 July 2026) extended the high-risk transition periods. The AI Act Service Desk shows Article 113 as amended, based on the EUR-Lex consolidated text as at 27 July 2026.

Articles 9 to 15 sit in Chapter III Section 2 and Articles 16 to 27 in Section 3, so for most AI product teams the documentation clock runs to 2 December 2027. Dates have moved once; check the Service Desk timeline.

What Articles 11, 12, 13, 15 and 25 and Annex IV ask for, in plain terms

These summaries paraphrase the consolidated text on the AI Act Service Desk, which marks passages the Omnibus added or amended.

Article 11, technical documentation. Draw it up before placing the system on the market, keep it current, show compliance with Chapter III Section 2, and include at least the Annex IV elements. As amended, SMEs, start-ups and small mid-caps may use a simplified Commission form that notified bodies must accept.

Annex IV, the content. The points that touch software composition most directly are 1(a) the system version and its relation to previous versions, 1(b) interaction with hardware or software, including other AI systems, outside the system, 1(c) versions of relevant software or firmware and version update requirements, 1(d) the forms in which the system is placed on the market, 2(a) recourse to pre-trained systems or third-party tools and how they were integrated or modified, 2(c) the architecture and how software components build on each other, 2(d) training data provenance and characteristics, 2(h) cybersecurity measures, and 6 lifecycle changes. The rest (design rationale, human oversight assessment, validation and testing, performance metrics, the risk management system, standards applied, the declaration of conformity and the post-market monitoring plan) documents decisions and tests. No scanner produces it.

Article 12, record-keeping. The system must technically allow automatic recording of events over its lifetime, for identifying risks, post-market monitoring and operational monitoring. Article 19 requires providers to keep logs under their control for at least six months unless other law says otherwise. These are runtime logs produced by the AI system itself.

Article 13, transparency to deployers. The system must be transparent enough for deployers to interpret and use its output, and come with instructions for use whose minimum content Article 13(3) lists, from intended purpose and accuracy levels to oversight measures, maintenance and software updates, and log collection.

Article 15, accuracy, robustness and cybersecurity. The system must perform consistently on all three across its lifecycle. Article 15(5) requires resilience against unauthorised attempts to alter its use, outputs or performance by exploiting vulnerabilities, including data poisoning, model poisoning through pre-trained components, adversarial examples and confidentiality attacks.

Article 25, the value chain. A third party that rebrands, substantially modifies or repurposes a system into high-risk use becomes its provider, and the initial provider must cooperate. Article 25(4) requires the written supplier agreements described above, except for tools, services, processes or components other than general-purpose AI models made public under a free and open-source licence.

For a broader walk through the obligations, see EU AI Act high-risk system obligations, and for Article 15's attack categories, Article 15 cybersecurity and AI-specific attacks.

Which of these does a Safeguard scan check?

The EU AI Act page in Safeguard's framework library lists six requirements that each scan of a product checks against what the scan found, including the product's software inventory (SBOM). All six are marked "decided by a scan". Here they are, with what the docs say each one checks and what a pass does and does not tell you.

Read the right-hand column carefully. Each requirement checks a software composition precondition that the provision depends on. None of them checks the provision itself. EU-AIA-12 is the clearest example: the docs tie it to Articles 12 and 18, but what a scan can see is whether your composition documentation is identifiable and dated. Whether your AI system writes the event logs Article 12 asks for is a property of your application code and runtime, which you evidence separately.

What your SBOM needs to carry for each check

Safeguard's docs describe what each requirement checks, not the field-level logic. The table below is a practical guide to where that information lives in the two SBOM formats Safeguard generates and reads (SPDX and CycloneDX), so you can inspect your own inventory before a scan and understand a failure after one. It is a reading aid based on the formats, not a statement of Safeguard's internal rules.

The common reasons a requirement fails are the reasons an SBOM is thin: components resolved without versions because a lockfile was missing, no hashes because the generator ran against a manifest rather than installed artifacts, and no supplier data for packages pulled from a private mirror. Fixing the build that produces the inventory fixes the requirement.

Which catalogue controls need your evidence?

The framework's Controls tab lists the six scan requirements as controls, plus controls from Safeguard's control catalogue. The docs say you evidence these with automated tests, uploaded evidence, policies or an attestation. No automated test from connected systems maps to the EU AI Act directly, so you link tests yourself or rely on uploads, policies and attestations.

The evidence column is not a Safeguard checklist, and not a statement of what a notified body will accept. Three controls carry most of the work.

Article 9, risk management. A continuous process across the lifecycle: identify and estimate risks to health, safety and fundamental rights under intended use and foreseeable misuse, evaluate post-market data, and adopt measures until residual risk is acceptable. The suite's Risks area (GA) records and scores risks, with acceptance rules that depend on the residual level. It is a register, not the analysis.

Article 10, data governance. Training, validation and testing data: design choices, origin, preparation, assumptions, suitability, bias examination and data gaps. The Omnibus deleted the old Article 10(5) and moved bias-related processing of special categories of personal data to a new Article 4a. A software scan sees none of this; see AI-BOM and EU AI Act Article 10.

Article 14, human oversight. People must be able to understand the system's limits, watch for automation bias, interpret outputs, override them and stop the system safely. That is interface and process design, evidenced by procedures, screenshots, training and test records.

Where does AI-BOM discovery (early access) help, and where does it stop?

A dependency scanner sees openai or transformers as one more library. It does not record that your code loads a model weight file, calls a cloud inference endpoint created in a console, or reads a vector store. Annex IV points 1(b), 2(a) and 2(c) need that AI layer.

AI-BOM discovery is early access. Per Safeguard's docs, it is part of the AI-SPM engine, an administrator switches it on through a server-enforced feature flag, and it then runs through the standard scan flow across connected repositories, cloud accounts and SaaS integrations. It inventories:

• Code: AI SDK imports such as openai, anthropic, langchain, transformers and llama_index; model weight files such as .pt, .safetensors and .gguf; prompt templates; notebooks; MCP server configuration.
• Cloud: managed inference endpoints in the cloud accounts you connect.
• SaaS: connected but unsanctioned AI tools, surfaced as shadow AI.
• Vector databases as vector stores, and agent definitions as agents.

Assets for a product are assembled into an AI-BOM, a point-in-time snapshot. The offering files say the output follows CycloneDX ML-BOM and the SPDX AI profile; CycloneDX describes models, datasets and their dependencies, and SPDX 3.0 defines an AIPackage for AI software.

Where it stops: it sees only what you connect; it records presence, not behaviour, so a model name chosen at runtime from configuration may not appear; it does not document training data provenance for point 2(d); and as early access, coverage and behaviour can change. Treat the AI-BOM as an input you verify. The full flow is in Find every AI model and SDK you ship with Safeguard AI-BOM discovery.

AI-SPM model artifact scanning (early access) inspects the model files discovery finds, in formats such as pickle, PyTorch, safetensors, GGUF and ONNX. It speaks to one narrow part of Article 15(5), whether a pre-trained component is safe to load, and does not measure accuracy, robustness or adversarial resistance.

Step by step: switch on the framework, scan, read the six requirements, evidence a control

The flow below uses screen names from Safeguard's docs and app. Where the docs do not show a command or screen, the step describes the outcome instead.

1. Write down your classification decision first. Decide whether the system is high-risk under Article 6 and Annex III or Annex I, and record why; Article 6(4) requires a documented assessment if you conclude an Annex III system is not high-risk. Safeguard does not make this call. The Commission's classification guidelines were published as a draft with a consultation that closed on 23 July 2026; check whether a final version is adopted.

2. Confirm the EU AI Act framework is on. Open Compliance › Manage, then the Frameworks tab. Find the EU AI Act by region, sector or search. If someone switched it off, switch it on and select Save; it then appears on Compliance › Frameworks, Controls and Overview. Your plan decides which frameworks are available, and your Safeguard administrator manages that list.

3. Group the AI system as one product. The six requirements are checked per product scan, so put the serving repository, application, retrieval service and container images of the system into one product.

4. Scan the product. For connected repositories, scans run from the web app. From a developer machine, the Safeguard CLI (GA) builds an SBOM for one target:

   safeguard scan --dir .
   

   A plain safeguard scan keeps results on the machine, as JSON under ./output. To see the project in the platform, the docs say to sign in from the interactive terminal and scan there:

   safeguard
   /login
   /scan .
   

   The runner then uploads the SBOM and findings, and the docs say it never uploads your source. If a supplier gave you an SBOM for a component of the system, safeguard scan --sbom sbom.json reads SPDX or CycloneDX and runs the same analysis. If AI-BOM discovery is enabled for your tenant, it runs through the same scan flow.

5. Read the six requirements. Open Compliance › Frameworks, select the EU AI Act, and open its Controls tab. Each scan requirement shows met or not met by the latest scan. The readiness score is the share of in-scope requirements that pass; one waiting for evidence counts as not passing, and one scoped out with a written justification leaves the score. The docs are plain that the score is Safeguard's assessment of what it can see, not an audit opinion or a certification.

6. Fix failing scan requirements at the source. If EU-AIA-11V fails, fix the build that generates the inventory, usually by committing a lockfile or scanning built artifacts. If EU-AIA-25 fails, fill in missing suppliers where components are defined. If EU-AIA-15 fails, check how integrity is recorded; attestation and signing (GA) adds SLSA provenance and Sigstore signatures, covered in attestation and provenance in Safeguard. Then scan again.

7. Start the documentation policy from a template. Open the framework on Compliance › Frameworks, then its Policies tab, select New policy and choose Start from template. The docs list three templates written for the EU AI Act: a High-Risk AI System Risk Management Policy, a Technical Documentation Policy, and a GPAI Model Transparency and Obligations Policy, plus the standard set adapted to the framework. Edit it to describe how your team actually produces Annex IV documentation, then Submit for review. An approval covers one version, and the next review defaults to a year later.

8. Attach evidence for an evidence-only control. Take EUAI-ART14 (human oversight). Open Compliance › Evidence, choose Attach evidence and pick the control (or attach from the control itself). Choose the evidence type, add a title, the file or link and a note saying what it shows, and set a refresh cadence. Good evidence here is the operator procedure, a screenshot of the override control and a dated test record showing the stop function reaches a safe state.

9. Get the evidence accepted. Evidence starts as submitted. A compliance reviewer chooses Accept or Reject, and the decision is stamped with who made it, when and why. Changing accepted evidence creates a new version that goes back to submitted, and evidence with an end date moves to expiring, then expired. The Auditor role alone is not a reviewer, and Safeguard's assistant and MCP clients can draft and submit but never accept or approve.

10. Scope out what does not apply, in writing. If you do not provide a general-purpose AI model, EUAI-ART53 and EUAI-ART55 may not apply to you as a provider. Scope them out with a written justification rather than leaving them failing.

11. Export dated inventories into your documentation file. SBOM generation and analysis (GA) exports SPDX and CycloneDX. Export the SBOM (and AI-BOM, where enabled) for each release and store it with that release's Annex IV documentation in your own archive, planned for Article 18's ten years.

12. Ask questions in Claude, read only. Safeguard is listed in the Claude connector directory as a community connector. Open the Safeguard entry in the directory, connect, sign in to Safeguard, check the app name and host, and authorise access. On a Team or Enterprise plan, an Owner adds the connector first. The tools used here (listing products, projects and vulnerabilities, getting a project or vulnerability, and listing findings where findings are returned) read what is already in your tenant; which tools appear depends on your plan and administrator settings. Ask which projects have critical vulnerabilities with a fix available while you write the Annex IV point 2(h) section; the assistant does not change findings or approve evidence. More on the route in Safeguard in your IDE and in the Claude and ChatGPT connector directories.

Requirement versus what Safeguard does versus what you still own

How does this relate to the ISO/IEC 42001 and NIST AI RMF pages in the library?

Safeguard's library has separate ISO/IEC 42001 and NIST AI RMF pages, both on by default. All three ask for an inventory of AI system components, but they are different instruments.

ISO/IEC 42001:2023 is a voluntary AI management system standard; certification comes from an accredited certification body. Safeguard's page lists six scan requirements on the software inventory: resource documentation, supplier management, lifecycle documentation (an SBOM with document identity and timestamp), version records, component provenance and supply chain integrity (supported by integrity hashes). They line up closely with the EU AI Act six, so one good inventory serves both. We could not retrieve ISO's page while writing, so we do not quote its clauses; check each catalogue control against the standard before relying on it.

NIST AI RMF 1.0, released on 26 January 2023, is voluntary guidance organised into Govern, Map, Measure and Manage; NIST AI 600-1, the Generative AI Profile, followed on 26 July 2024. Safeguard's page lists four scan requirements (component identification, model documentation, transparency, version tracking) and catalogue controls named after AI RMF subcategories. Check the wording against NIST's text.

Evidence attached to one framework does not count toward another automatically. On Compliance › Crosswalk, a reviewer approves or rejects mappings; an approved equivalent mapping lets accepted evidence count toward the target control, a partial one does not, and decisions are append-only. Decide each mapping deliberately rather than in bulk.

What the platform cannot decide: classification, conformity assessment and CE marking

Classification. Article 6(1) covers safety components of, or products under, the Annex I legislation that need third-party conformity assessment; the Omnibus added Articles 6(1a) to 6(1c) narrowing what counts as a safety component. Article 6(2) adds Annex III use cases, and Article 6(3) carves out those without significant risk of harm. Applying this to your intended purpose is a legal judgement.

Conformity assessment. Under Article 43, Annex III point 1 (biometrics) systems use internal control (Annex VI) or a notified body procedure (Annex VII), and must use Annex VII in some cases; Annex III points 2 to 8 use internal control; Annex I systems follow their sector legislation. Safeguard is not a notified body.

Declaration and marking. The declaration of conformity (Article 47) and CE marking (Article 48) are the provider's acts. A readiness score or an exported SBOM is an input, not a substitute.

What Safeguard does not do

1. It does not classify your AI system. Whether a system is high-risk under Article 6 and Annex III or Annex I is a legal decision you make with counsel. The framework is on by default in every workspace, whether or not the Act applies to you.
2. It does not perform conformity assessment, issue a declaration of conformity or authorise CE marking. It is not a notified body, and a readiness score is Safeguard's assessment of what it can see, not an audit opinion or a certification.
3. It does not write your Annex IV documentation. The scan requirements check that the composition data behind points 1(c), 2(a) and 2(c) exists. Design rationale, test reports, performance metrics, the risk management description and the post-market monitoring plan are yours. Lino (GA) can help draft narrative and map evidence, but a person writes, reviews and approves.
4. It does not see training data quality or model behaviour. Scans see software composition. They do not evaluate accuracy, bias, robustness or resistance to adversarial inputs, which Articles 10 and 15 and Annex IV point 2(g) expect you to test and document.
5. It does not build or retain your Article 12 event logs. EU-AIA-12 checks that documentation is identifiable and dated. Runtime logging is a feature of your system, and keeping logs for at least six months under Article 19 is your operational job.
6. AI-BOM discovery and AI-SPM are early access. An administrator switches them on, coverage depends on what you connect, and behaviour can change. Plan around the GA SBOM path and treat the AI-BOM as an additional input.
7. It does not negotiate or check your Article 25(4) agreements. EU-AIA-25 tells you which third parties supply components. Whether you have a written agreement with each of them, and what it says, is contract work.
8. It does not give legal advice. Nothing in the platform or in this post tells you how a regulator will read your documentation.

Common mistakes

Reading a passing requirement as compliance with the article. EU-AIA-15 passing means integrity data is present, not that the system meets Article 15.

Scanning one repository and calling it the system. If the product holds only the serving repository, every Annex IV statement built on its inventory is partial.

Treating the framework as proof the Act applies. It is on by default. Record your Article 6 decision separately and scope controls to match.

Attesting over a broken inventory. When EU-AIA-11V fails for missing versions, fix the build. Authorities read the SBOM, not the attestation note.

Using the AI-BOM as if it were GA. Cross-check it against what the team knows is in the system, especially runtime-selected models and unconnected accounts.

Letting evidence expire quietly. Set refresh cadences for oversight and logging evidence that match your release cycle.

Bulk approving crosswalk mappings. A wrong equivalent mapping overstates your position in two frameworks at once.

Planning to the old dates. Annex III high-risk obligations now apply from 2 December 2027.

FAQ

Does Safeguard make us compliant with the EU AI Act?

No. The EU AI Act framework in the Compliance and GRC suite (GA) checks six software composition requirements on every product scan and gives you a workflow for the other controls. Compliance depends on your classification, documentation, conformity assessment and operations. A readiness score is not an audit opinion or a certification.

What does Annex IV require for software components?

Among other things, versions of relevant software (point 1(c)), interaction with other software and AI systems (1(b)), third-party pre-trained systems and tools (2(a)), the architecture of software components (2(c)) and cybersecurity measures (2(h)). An SBOM plus an AI-BOM keeps that current.

When do the EU AI Act high-risk obligations apply?

Per Article 113 as amended by the Digital Omnibus on AI: from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. General-purpose model obligations have applied since 2 August 2025.

Is an SBOM enough for EU AI Act technical documentation?

No. It covers the composition parts of Annex IV and supports Articles 15 and 25. Design rationale, training data, testing, metrics, risk management and post-market monitoring still need to be written.

Is Safeguard AI-BOM discovery generally available?

No, it is early access and an administrator switches it on. SBOM generation and analysis, which the six requirements read, is GA.

Does Safeguard check Article 12 logging?

Not as Article 12 means it. EU-AIA-12 checks that composition documentation is identifiable and dated. Runtime event logging is a property of your system, evidenced under EUAI-ART12.

Can Claude approve our EU AI Act evidence through the Safeguard connector?

No. Safeguard's assistant and MCP clients such as Claude or ChatGPT can draft and submit but never accept, approve, launch or acknowledge. A compliance reviewer decides in the app.

Who decides whether our AI system is high-risk?

You do, as provider, applying Article 6 and Annexes I and III with counsel. If you conclude an Annex III system is not high-risk, Article 6(4) requires you to document that before placing it on the market. Safeguard does not make or record this decision.

Fix it without waiting for upstream

Article 15(5) asks for resilience against attempts to exploit system vulnerabilities, and EU-AIA-15 and your Annex IV point 2(h) section both depend on what is actually in the stack. When a scan of your AI system turns up a vulnerable dependency, the documentation is only as good as how quickly the fix ships, which is where the following applies.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. It does not show the EU AI Act framework; it is the connection behind step 12's read-only questions.

Click through it at your own pace, or open it full screen.

The second is a real CLI session: install, open the interactive terminal, ask it to fix the lodash CVE in a repository, and approve each command as it edits package.json to lodash 4.17.21, runs npm install and npm test, and prints a summary without pushing anything. It then shows /permissions, /model and /scan, the same interactive scan that uploads an SBOM to the platform in step 4.

Click through it at your own pace, or open it full screen.

The third sets up the local runner on your own machine, approves it with its device code, and scans from the terminal: a way to produce the inventory the six requirements read without moving model serving code.

Click through it at your own pace, or open it full screen.

To try the CLI or the apps, start at safeguard.sh/download, and read the docs at docs.safeguard.sh/docs. Related reading: what Safeguard does today, every capability labelled, continuous compliance in Safeguard, SBOM generation and analysis in Safeguard, and in this series, how to structure Safeguard data and count vulnerabilities correctly.

Quick check

Sources

• Regulation (EU) 2024/1689, the AI Act, on EUR-Lex
• AI Act Service Desk: Article 6, classification rules for high-risk AI systems
• AI Act Service Desk: Article 9, risk management system
• AI Act Service Desk: Article 10, data and data governance
• AI Act Service Desk: Article 11, technical documentation
• AI Act Service Desk: Article 12, record-keeping
• AI Act Service Desk: Article 13, transparency and provision of information to deployers
• AI Act Service Desk: Article 14, human oversight
• AI Act Service Desk: Article 15, accuracy, robustness and cybersecurity
• AI Act Service Desk: Article 18, documentation keeping
• AI Act Service Desk: Article 19, automatically generated logs
• AI Act Service Desk: Article 25, responsibilities along the AI value chain
• AI Act Service Desk: Article 43, conformity assessment
• AI Act Service Desk: Article 113, entry into force and application
• AI Act Service Desk: Annex III
• AI Act Service Desk: Annex IV, technical documentation
• AI Act Service Desk: timeline for the implementation of the AI Act
• AI Act Service Desk: FAQ
• AI Act Service Desk: guidelines on the classification of high-risk AI systems
• European Commission: AI Act regulatory framework
• European Commission: guidelines for providers of general-purpose AI models
• NIST: AI Risk Management Framework
• NIST AI 600-1, Generative AI Profile
• CycloneDX: Machine Learning Bill of Materials
• SPDX 3.0.1 specification: AI profile
• Safeguard docs: EU AI Act framework
• Safeguard docs: compliance frameworks
• Safeguard docs: ISO/IEC 42001 framework
• Safeguard docs: NIST AI RMF framework
• Safeguard docs: approvals
• Safeguard docs: AI-BOM discovery
• Safeguard docs: AI-BOM and model security

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.