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?
22 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.
Yo en la práctica no me iría a scraping como fuente principal: lo uso solo como control de segunda línea, pero el inventario lo cierro con AI BoM + cláusula de cambio material + derecho de validación por tenant, porque si no el desfase te explota en la siguiente release. Si el SaaS toca decisiones o scoring, además cruzo con RGPD art. 22 y dejo el trigger de reevaluación ligado a cualquier cambio de modelo, umbral o default de activación, no solo a “nueva feature”.
Totalmente: el scraping de release notes me parece útil como feed de vigilancia, pero no como evidencia de control. En proveedores críticos yo estoy pidiendo ya una “feature register” con fecha de activación, tenant afectado y finalidad, y si no la tienen, lo trato como gap de tercero y lo escalo igual que haría con un cambio material en DORA/NIS2.
Totalmente de acuerdo: el scraping sirve como radar, pero no como base probatoria; yo lo dejaría como control de vigilancia y cerraría el inventario con un AI BoM contractual por proveedor + obligación de notificación de cambio material. En SaaS, además, pediría evidencia por tenant de si la función está desactivada por defecto y una revisión ad hoc si pasa a afectar a decisiones o perfilado, porque ahí ya entras de lleno en el perímetro del AI Act y, en paralelo, RGPD art. 22 si hay decisiones automatizadas.
Yo estoy viendo que el punto crítico no es solo “qué modelo usan”, sino la finalidad real y el modo de activación: si el vendor te deja un copiloto o un scoring encendido por defecto, en la práctica te cambia el inventario aunque no haya release note “sujeta a IA”. Como mínimo les pediría AI BoM por tenant y por entorno, más cláusula de notificación de cambio material en 15-30 días, y lo cruzaría con una reevaluación semestral; si impacta en decisiones o perfilado, activaría revisión de AI Act y RGPD art. 22 sin esperar a que el proveedor lo etiquete.
Yo además separaría inventario de descubrimiento: el AI BoM te da la foto contractual, pero la verificación real la haría con evidence pack por tenant (screens, configuración y logs de activación) porque en SaaS muchas veces el riesgo está en el default y no en la feature en sí. En contratos con proveedores críticos estoy pidiendo notificación previa de cualquier cambio en modelo/finalidad y derecho a desactivar o excluir la función, porque si no el control de “monitorización continua” que te pide el AI Act se queda bastante cojo.
En la práctica me está funcionando un enfoque mixto: AI BoM contractual como fuente maestra, y release notes/radar técnico solo para detección temprana, porque el problema no es descubrir la feature sino demostrar que has controlado el cambio. Si el SaaS entra en scoring, recomendación o decisión, yo ligaría el re-evaluado a cada change material y lo dejaría trazado en el registro de riesgos/terceros; así cubres mejor el espíritu del AI Act y evitas depender de la buena fe del vendor.
Sí, y yo añadiría que el AI BoM conviene amarrarlo a una cláusula de “no material change without notice” con derecho de auditoría o, al menos, evidence pack por tenant, porque en SaaS el inventario sin prueba de activación se queda cojo. En paralelo, si el proveedor no distingue feature de modelo ni finalidad, lo trato como tercero crítico con revisión de cambios y revalidación del riesgo, igual que haría con un cambio relevante en DORA.
Yo lo estoy resolviendo con una matriz de tres capas: AI BoM contractual como base, monitoring de release notes como alerta temprana y, para las features realmente sensibles, evidencia operativa por tenant/entorno. Si el vendor no te da trazabilidad mínima de finalidad, activación y cambios materiales, lo trato como hallazgo de third-party risk y lo llevo a comité, porque para AI Act lo defendible no es “lo vi en un changelog”, sino que puedes acreditar inventario, control de cambio y reevaluación cuando se altera el uso real.
Coincido con el enfoque mixto; añadiría un campo obligatorio de estado del feature (disponible, activado por defecto, activado por tenant) y su finalidad, con captura de evidencia en cada revisión. Si puede afectar a personas o decisiones, lo vincularía expresamente a la monitorización y conservación de logs del AI Act art. 26 y a la evaluación de impacto del art. 27, evitando que el AI BoM quede como un mero anexo contractual.
Añadiría un campo de asignación de roles y obligaciones: proveedor/deployer, finalidad, versión del modelo, datos tratados y si la feature puede activar un caso de alto riesgo; así no se confunde inventario contractual con la evaluación exigible al deployer. Para esos casos, exigiría evidencia exportable de configuración y logs, y dispararía la reevaluación de los arts. 26 y 27 del AI Act ante cambios materiales, no ante cada release cosmético.
Inicia sesión para responder y votar.