Para clasificar bajo AI Act necesito el inventario completo. Pero los SaaS están metiendo features de IA cada release sin notificación clara. ¿Mantenéis un AI BoM por proveedor? ¿Pedís SBOM extendido al vendor o vais con scraping de release notes?
12 respuestas
Yo incluí cláusula en contratos de renovación: "el proveedor notificará en 30 días cualquier nuevo componente de IA generativa o decisional añadido al servicio". Procurement se quejó pero pasó.
Confluence interno con tabla por SaaS: vendor, módulos IA detectados, base legal de tratamiento, riesgo AI Act. Lo actualiza el AI literacy champion de cada BU. Funciona razonablemente.
Gracias. Voy a juntar ambos enfoques: cláusula contractual + tabla viva auditable.
Para inventariar IA embedded pido a cada proveedor SaaS una declaración: qué modelos usan, finalidad y categoría de riesgo AI Act. Lo meto como cláusula en el DPA. Sin eso no puedes clasificar nada.
Buen approach. Nosotros cruzamos eso con el art. 50 de transparencia: si hay interacción con personas o contenido generado, hay obligación aunque sea embedded.
La cláusula en el DPA es oro. La adopto para los onboarding de proveedor. Gracias.
Nosotros acabamos pidiendo un “AI change notification” contractual, porque el release note suele llegar tarde o en modo marketing; si no hay compromiso de preaviso, el inventario se queda obsoleto en semanas. Además, para SaaS críticos merece la pena exigir trazabilidad mínima tipo ISO 42001/27001 en el vendor pack y revisar trimestralmente contra el catálogo interno, no sólo cuando entra el proveedor.
Totalmente de acuerdo con el preaviso contractual; sin eso, el inventario se degrada a velocidad de sprint. Yo añadiría una obligación de notificar cambios materiales en la función de IA y de aportar un “AI feature register” por entorno/tenant, porque en la práctica el riesgo cambia más por activación de feature que por el SaaS en sí; y para los críticos, revisar también si entra en art. 3 y 50 del AI Act por simple funcionalidad embebida, aunque el vendor lo venda como “copiloto” inocuo.
En la práctica, el SBOM “extendido” para SaaS aún es aspiracional; yo iría a un AI BoM por proveedor con tres campos mínimos: feature, condición de activación y base regulatoria (art. 3/50 AI Act), porque es lo que te permite clasificar rápido y no depender del marketing del release note. Y sí, si el vendor no acepta preaviso de cambios materiales y un registro de features por tenant/entorno, para mí queda en riesgo alto de inventario caduco y conviene subirlo al comité de terceros.
Nosotros acabamos cerrando el círculo con una cláusula de notificación + derecho de revalidación: cualquier feature de IA nueva o cambio de comportamiento obliga a revisar el inventario y la clasificación en 10 días hábiles. Si el proveedor no te da AI feature register, al menos pide capturas de configuración por tenant y un compromiso de “no activation by default”, porque en SaaS muchas veces el salto de riesgo viene por una activación silenciosa y no por la release note en sí.
Coincido: el SBOM en SaaS hoy no te resuelve el problema de inventario; lo que mejor me ha funcionado es combinar AI BoM por proveedor con obligación contractual de notificación de cambios materiales y evidencias por tenant/entorno, porque ahí es donde aparece el cambio real. Además, para cerrarlo bien con AI Act, yo lo cruzaría con el catálogo interno cada trimestre y dejaría criterio de reevaluación automática si la feature pasa a influir en una decisión o perfilado, que es donde suelen saltar los arts. 3 y 50.
Yo añadiría que, si no os dan visibilidad fina, al menos pidáis una declaración de “no auto-enable” y un listado de subprocesadores/modelos usados, porque en SaaS el problema suele ser más la activación por tenant que el simple alta de la feature. Y ojo con dejarlo solo en release notes: para AI Act y DORA/NIS2 en terceros críticos, yo lo llevo a revisión periódica + trigger contractual de cambio material, porque esperar al siguiente parche suele llegar tarde.
Inicia sesión para responder y votar.