SBOM para IA en la administración pública: inventario práctico de modelos y datos

Por qué una "SBOM" (Bill of Materials) importa para IA en la administración

Un SBOM —software bill of materials— es un inventario formal de componentes de un sistema. Para proyectos de IA en el sector público conviene extender ese concepto a modelos, datos y dependencias: un "Model & Data SBOM". No es sólo buena práctica técnica: apoya cumplimiento legal (ENS RD 311/2022, RGPD, obligaciones de documentación del EU AI Act) y facilita operativa (gestión de vulnerabilidades, auditorías, trazabilidad de decisiones).

Beneficios concretos:

• Reduce riesgo operativo: sabes qué versiones de modelos están en producción y sus dependencias.
• Mejora respuesta a incidentes: localizas rápidamente qué artefactos actualizar o retirar.
• Facilita cumplimiento: aporta la documentación técnica que exigen ENS y el AI Act para sistemas de alto riesgo.
• Acelera control de proveedores y auditorías: evidencia de licencias, origen de datos y pruebas de validación.

Qué debe incluir un Model & Data SBOM (campos prácticos)

Diseña un formato mínimo para empezar; luego automatízalo. Campos recomendados:

• Identificador del artefacto
  • ID único (p. ej. URN interno)
  • Nombre comercial / versión
• Tipo de componente
  • Modelo (p. ej. "Clasificador de expedientes v2.1")
  • Conjunto de datos (p. ej. "Registro catastral 2023 - anonimizado")
  • Librería / dependencia (p. ej. TensorFlow 2.11)
• Proveniencia y proveedor
  • Organización autora (interno/externo)
  • Contacto técnico y contractual
  • Fecha de adquisición/entrenamiento
• Licencias y restricciones de uso
  • Licencia de código y de datos
  • Cláusulas de reuso, conservación y portabilidad
• Huellas y artefactos
  • Checksum (SHA-256) de binarios y pesos
  • Hash del dataset o muestra representativa
• Metadatos de entrenamiento
  • Periodo de datos, muestreo, transformaciones aplicadas
  • Etiquetado: humano/autómatico; procedencia
• Evaluación y garantías
  • Métricas clave (precisión, F1, AUC) con conjunto de prueba
  • Tests de robustez y bias assessment resumidos
  • Nivel de riesgo según EU AI Act (si aplica)
• Configuración de despliegue
  • Endpoints, versiones en entornos (dev/stage/prod)
  • Requisitos de hardware y tiempo de vida esperado
• Controles de seguridad y privacidad
  • Medidas ENS (cifrado, segregación de red)
  • Tratamiento RGPD: base legal, supresión, retención, derechos ARCO
• Historial de cambios
  • Registro de versiones, responsables y fecha de despliegue
• Dependencias externas verificadas
  • APIs, modelos terceros, datasets adquiridos

Plantilla mínima (rápida)

Para arrancar, una sola línea por artefacto con estos campos obligatorios: ID | Tipo | Nombre | Versión | Proveedor | Checksum | Licencia | Entorno(s) | Fecha despliegue | Responsable.

Cómo crear un SBOM en tres fases prácticas

1. Identificar y priorizar (0–30 días)

   • Mapea servicios que interactúan con ciudadanos o que tomen decisiones automáticas (subvenciones, inspecciones, atención ciudadana).
   • Prioriza por impacto y cumplimiento (alto riesgo según EU AI Act, servicios que procesan datos personales).

2. Generar inventario inicial y plantilla (30–60 días)

   • Recoge información manualmente de los equipos y contratos.
   • Usa la plantilla mínima; guarda en un repositorio central (CMDB o herramienta de gestión de activos).
   • Vincula registros contractuales (Ley 9/2017) y expedientes de subvención (Ley 38/2003) cuando proceda.

3. Automatizar e integrar (60–120 días)

   • Integra generación de SBOM en pipelines CI/CD: cada build/pesos nuevos generan o actualizan entradas.
   • Exponer SBOM en formato machine-readable (SPDX, CycloneDX adaptado) para escaneos automáticos.
   • Conecta con el proceso de gestión de vulnerabilidades y con el plan de continuidad/Respuesta a incidentes de IA.

Aspectos legales y de seguridad a vincular

• ENS (RD 311/2022): el SBOM facilita demostrar controles técnicos (gestión de versiones, cifrado, control de accesos) exigidos por ENS para sistemas que manejan información pública y sensible.
• RGPD: el SBOM ayuda a localizar qué modelos usan datos personales, sus bases legales, plazos de retención y medidas de minimización/pseudonimización. Útil frente a peticiones de derechos ARCO y para realizar evaluaciones de impacto (EIPD).
• EU AI Act: para sistemas de alto riesgo el expediente técnico exige documentación sobre datos, rendimiento, riesgos y mitigaciones. El SBOM es un componente clave de esa documentación técnica.

Evite afirmaciones legales concretas sin consultar asesoría jurídica; utilice el SBOM como herramienta probatoria y operativa que facilita cumplimiento.

Gobernanza y operaciones: responsabilidades mínimas

• Dueño del servicio (owner): responsable de mantener el SBOM actualizado.
• Equipo de seguridad: integra SBOM en escaneos de vulnerabilidades.
• Compras/Legal: exige SBOM o metadatos mínimos en pliegos (contratación conforme a Ley 9/2017).
• Auditoría interna: revisa periódicamente coherencia entre despliegue y SBOM.

Integración con procesos existentes

• Vincúlelo con CMDB y registros de sistemas ENS.
• Añádalo a las cláusulas contractuales: versiones, notificaciones de cambios y derecho a auditoría.
• Use el SBOM en simulacros de incidentes de IA para practicar rollback y mitigaciones.

Toma de acción (acción clara y prioritaria)

Acción recomendada en 90 días: lanza un piloto SBOM para los tres servicios de IA con mayor contacto ciudadano o mayor riesgo (p. ej. gestión de subvenciones, chatbot de atención y evaluación automática de ofertas). Define plantilla mínima, asigna responsables, exige checksum y licencia para cada artefacto, y automatiza su exportación desde el pipeline de despliegue.

Un SBOM bien mantenido reduce la carga de cumplimiento y mejora la resiliencia operacional. Para equipos municipales con recursos limitados, empezar con un inventario sencillo y automatizar progresivamente es la ruta más práctica. OptimGov puede ayudar a integrar SBOMs con catálogos de servicios y procesos de gobernanza existentes, pero el primer paso siempre es identificar qué sistemas deben formar parte del inventario.