SBOM for AI in Public Administration: a Practical Inventory of Models and Data

Why a "SBOM" (Bill of Materials) matters for AI in government

An SBOM —software bill of materials— is a formal inventory of a system’s components. For AI projects in the public sector it makes sense to extend that concept to models, datasets and dependencies: a "Model & Data SBOM". This is more than a technical best practice: it supports legal compliance (ENS Royal Decree 311/2022, GDPR, and the documentation obligations of the EU AI Act) and improves operations (vulnerability management, audits, decision traceability).

Concrete benefits:

• Lowers operational risk: you know which model versions are in production and their dependencies.
• Speeds incident response: you can quickly identify which artifacts to update or withdraw.
• Eases compliance: provides the technical documentation required by ENS and the AI Act for high‑risk systems.
• Accelerates supplier checks and audits: evidence of licenses, data provenance and validation tests.

What a Model & Data SBOM should include (practical fields)

Design a minimal format to get started; then automate it. Recommended fields:

• Artifact identifier
  • Unique ID (e.g. internal URN)
  • Commercial name / version
• Component type
  • Model (e.g. "Case classifier v2.1")
  • Dataset (e.g. "Cadastral register 2023 - anonymized")
  • Library / dependency (e.g. TensorFlow 2.11)
• Provenance and provider
  • Authoring organization (internal/external)
  • Technical and contractual contact
  • Date of acquisition/training
• Licenses and use restrictions
  • Code and data licenses
  • Reuse, retention and portability clauses
• Fingerprints and artifacts
  • Checksum (SHA‑256) of binaries and weights
  • Hash of the dataset or a representative sample
• Training metadata
  • Data period, sampling, transformations applied
  • Labeling: human/automatic; source
• Evaluation and assurances
  • Key metrics (accuracy, F1, AUC) on a test set
  • Summary of robustness tests and bias assessments
  • Risk level under the EU AI Act (if applicable)
• Deployment configuration
  • Endpoints, versions across environments (dev/stage/prod)
  • Hardware requirements and expected lifetime
• Security and privacy controls
  • ENS measures (encryption, network segregation)
  • GDPR handling: legal basis, deletion, retention, data subject rights (access, rectification, erasure, objection)
• Change history
  • Version log, owners and deployment dates
• Verified external dependencies
  • APIs, third‑party models, acquired datasets

Minimal template (quick)

To start, one line per artifact with these mandatory fields: ID | Type | Name | Version | Provider | Checksum | License | Environment(s) | Deployment date | Responsible.

How to create an SBOM in three practical phases

1. Identify and prioritize (0–30 days)

   • Map services that interact with citizens or make automated decisions (grants, inspections, citizen support).
   • Prioritize by impact and compliance (high risk under the EU AI Act, services that process personal data).

2. Produce an initial inventory and template (30–60 days)

   • Collect information manually from teams and contracts.
   • Use the minimal template; store it in a central repository (CMDB or asset management tool).
   • Link contractual records (Law 9/2017) and grant files (Law 38/2003) where relevant.

3. Automate and integrate (60–120 days)

   • Integrate SBOM generation into CI/CD pipelines: each build/new weights should create or update entries.
   • Expose the SBOM in a machine‑readable format (SPDX, CycloneDX adapted) for automated scans.
   • Connect it to your vulnerability management process and to AI continuity/incident response plans.

Legal and security aspects to connect

• ENS (Royal Decree 311/2022): an SBOM helps demonstrate technical controls (version management, encryption, access control) required by the ENS for systems handling public and sensitive information.
• GDPR: an SBOM helps locate which models use personal data, their legal bases, retention periods and minimization/pseudonymization measures. It’s useful for handling data subject requests and for conducting Data Protection Impact Assessments (DPIAs).
• EU AI Act: for high‑risk systems the technical file requires documentation about data, performance, risks and mitigations. The SBOM is a key component of that technical documentation.

Avoid making specific legal claims without consulting legal counsel; use the SBOM as an evidentiary and operational tool that facilitates compliance.

Governance and operations: minimum responsibilities

• Service owner: responsible for keeping the SBOM up to date.
• Security team: integrates the SBOM into vulnerability scans.
• Procurement/Legal: requires an SBOM or minimal metadata in tender documents (procurement in accordance with Law 9/2017).
• Internal audit: periodically verifies consistency between deployments and the SBOM.

Integration with existing processes

• Link it to the CMDB and ENS system records.
• Include it in contract clauses: versions, change notifications and audit rights.
• Use the SBOM in AI incident drills to practice rollback and mitigations.

Call to action (clear, prioritized step)

Recommended action within 90 days: launch an SBOM pilot for the three AI services with the most citizen contact or highest risk (e.g. grants management, customer support chatbot and automated bid evaluation). Define a minimal template, assign owners, require checksum and license for each artifact, and automate export from the deployment pipeline.

A well‑maintained SBOM reduces compliance burden and improves operational resilience. For municipal teams with limited resources, starting with a simple inventory and progressively automating it is the most practical path. OptimGov can help integrate SBOMs with service catalogs and existing governance processes, but the first step is always identifying which systems should be part of the inventory.