Capítulo 39 — Seguridad de la IA y del aprendizaje automático: mantenibilidad
Mapa de la lección
Lección 39 publicada. Mapa, ejemplo, EX115.
flowchart TD
N0["Resultados de aprendizaje"]
N1["39.1 El cambio es constante"]
N2["39.2 Estrategia de actualización"]
N3["39.3 Mantener actualizado el conocimiento"]
N4["39.4 Deuda técnica en la seguridad de la IA"]
N5["39.5 Retirada"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX115"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["39.1 El cambio es constante"]
N2["39.2 Estrategia de actualización"]
N3["39.3 Mantener actualizado el conocimiento"]
N4["39.4 Deuda técnica en la seguridad de la IA"]
N5["39.5 Retirada"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX115"]
[Resultados de aprendizaje]
|
v
[39.1 El cambio es constante]
|
v
[39.2 Estrategia de actualización]
|
v
[39.3 Mantener actualizado el conocimiento]
|
v
[39.4 Deuda técnica en la seguridad de la IA]
|
v
[39.5 Retirada]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX115]
Resultados de aprendizaje
Usted será capaz de (1) diseñar sistemas de IA cuya seguridad pueda mantenerse a medida que cambian los modelos, los datos y las amenazas; (2) gestionar las actualizaciones de modelos y dependencias; (3) mantener al día los conjuntos de evaluación, los modelos de amenazas y la documentación; y (4) planificar la retirada y la eliminación de los datos.
39.1 El cambio es constante
Los modelos alojados se actualizan; los modelos abiertos publican nuevas versiones; las bibliotecas corrigen vulnerabilidades; los atacantes publican técnicas nuevas; los procesos de negocio cambian. Un diseño seguro que no puede actualizarse de forma segura acabará siendo inseguro. Cada fuente de cambio afecta a la seguridad de forma distinta. Una actualización del modelo puede alterar la facilidad con que sigue el texto inyectado; un parche de una biblioteca puede cambiar el comportamiento del análisis sintáctico; una técnica de ataque nueva puede vencer un filtro que funcionaba el mes pasado. La mantenibilidad es la capacidad de absorber estos cambios sin perder los controles que importan, lo que requiere pruebas, responsables y un proceso predecible para las actualizaciones.
39.2 Estrategia de actualización
Fije las versiones y actualice de forma deliberada: cada actualización de un modelo o de una dependencia desencadena el control de evaluación de seguridad, un despliegue canario y un plan de reversión. En el caso de los modelos alojados que cambian sin previo aviso, ejecute el conjunto de evaluación de forma programada y genere alertas ante las regresiones. Mantenga capas de abstracción para poder sustituir un modelo sin reescribir la aplicación de políticas. La capa de abstracción hace que la aplicación de políticas no dependa del comportamiento de ningún modelo concreto. Así, sustituir un modelo solo requiere el control y el despliegue canario, no rediseñar los controles que lo rodean.
39.3 Mantener actualizado el conocimiento
Asigne responsables al modelo de amenazas, a los conjuntos de evaluación, a las fichas de modelo y a los manuales de operación, con fechas de revisión. Añada cada incidente y cada hallazgo del equipo rojo al conjunto de regresión. Siga las fuentes externas (actualizaciones de OWASP, incorporaciones a MITRE ATLAS, publicaciones del NIST) y registre si cada cambio afecta a su sistema. Un responsable con una fecha de revisión convierte «alguien debería actualizar el modelo de amenazas» en una tarea con un nombre asociado. Añadir cada hallazgo al conjunto de regresión hace que las pruebas del sistema crezcan a partir de la experiencia real y no de conjeturas. El seguimiento externo se registra de forma breve, por ejemplo «nueva técnica de ATLAS sobre inyección en descripciones de herramientas: aplica a los conectores, prueba añadida», para que los revisores posteriores puedan ver que los cambios se tuvieron en cuenta.
39.4 Deuda técnica en la seguridad de la IA
La deuda se acumula en forma de filtros puntuales, excepciones y retoques del prompt sin documentar. Refactorice periódicamente: elimine los controles que ya no responden a ninguna amenaza, consolide los filtros en el punto de aplicación y documente las excepciones restantes con fechas de caducidad. Un filtro añadido durante un incidente y nunca retirado puede bloquear ahora peticiones legítimas o duplicar un control del punto de aplicación. Los retoques del prompt sin documentar son especialmente arriesgados, ya que nadie sabe cuál de ellos está conteniendo una debilidad conocida. La refactorización se hace con el conjunto de regresión en ejecución, de modo que retirar un control que todavía importa aparece como una prueba que falla y no como un incidente.
39.5 Retirada
Retirar un modelo incluye revocar sus credenciales, eliminar las vías de acceso, decidir qué hacer con los pesos (pueden codificar datos de entrenamiento), borrar o archivar los datos según las normas de conservación y actualizar los inventarios. ISO/IEC 42001 espera procesos de ciclo de vida de los sistemas de IA que incluyan la retirada. Los modelos olvidados son un riesgo real: un punto de acceso antiguo que sigue funcionando con credenciales válidas puede encontrarse y aprovecharse mucho después de que todos dejaran de usarlo. Los pesos pueden permitir la inferencia de pertenencia o filtrar datos de entrenamiento, así que se tratan con las mismas normas que los propios datos. La actualización del inventario cierra el ciclo, de modo que la monitorización y las auditorías dejan de esperar un sistema que ya no existe y advierten cualquiera que no debería seguir funcionando.
39.6 Ejemplo resuelto (caso sintético de NRS)
El proveedor actualizó en silencio un modelo de embeddings alojado que se usaba para la recuperación de Wrench. La evaluación programada detectó que la recuperación clasificaba ahora más arriba los documentos de RR. HH. en algunas consultas; el filtro de control de acceso seguía bloqueándolos, pero el equipo recibió una alerta. Sam añadió la «versión del modelo de embeddings» a la monitorización y pasó a una versión fijada con actualizaciones programadas. La defensa en profundidad resistió: el cambio de clasificación fue inofensivo solo porque el control de acceso se aplicaba por separado de la recuperación. El episodio también puso de manifiesto una dependencia oculta, ya que nadie había incluido el modelo de embeddings entre las cosas que podían cambiar.
39.7 Errores y límites
- Ningún responsable del modelo de amenazas ni del conjunto de evaluación.
- Excepciones sin fecha de caducidad.
- Retiradas que se olvidan de los pesos y las credenciales.
Sin responsables, los modelos de amenazas y los conjuntos de pruebas dejan de cambiar mientras el sistema sigue cambiando, y la distancia crece sin que nadie la vea. Las excepciones sin caducidad se acumulan hasta que nadie sabe cuáles siguen siendo necesarias. Una retirada que elimina la interfaz, pero deja atrás los pesos y las credenciales, crea un sistema sin monitorizar que guarda material sensible. La revisión trimestral de Sam comprueba los nombres de los responsables, las fechas de las excepciones y el inventario frente a lo que realmente está en funcionamiento.
Ejercicios — capítulo 39
- EX115 — Plan de actualización. Redacte los pasos para actualizar el modelo de lenguaje de Wrench. Rúbrica: 3 = fijar la versión, evaluar con el control, despliegue canario, monitorizar, reversión preparada, documentar; 2 = cuatro; 1 = dos; 0 = nada.
- EX116 — Deuda. Dé dos ejemplos de deuda técnica en la seguridad de la IA y su corrección. Rúbrica: 3 = dos verosímiles con sus correcciones; 2 = uno; 1 = vago; 0 = nada.
- EX117 — Retirada. Enumere cinco pasos de retirada de TrackEye v1. Rúbrica: 3 = revocar credenciales, eliminar puntos de acceso, tratar los pesos, conservación de datos, actualizar el inventario/la documentación; 2 = cuatro; 1 = dos; 0 = nada.
Síntesis del capítulo
La seguridad mantenible de la IA da por supuesto el cambio: actualizaciones con versiones fijadas y controles, conocimiento actualizado y con responsables, deuda gestionada y una retirada deliberada.
Siga estudiando — capítulo 39 de 50
← Capítulo 38 (borrador) · Índice de capítulos del curso · Capítulo 40 (borrador) →