◇ OpenCyber Academy
Ingeniería · Capítulo 37 · Español

Capítulo 37 — Seguridad de la IA y del aprendizaje automático: operaciones

Aprendizaje gratuito y abierto para quienes desean proteger a las personas y la tecnología. No se necesita una cuenta para estudiar ni consultar las respuestas.

Capítulo 37 — Seguridad de la IA y del aprendizaje automático: operaciones

Mapa de la lección

Lección 37 publicada. Mapa, ejemplo, EX109.

flowchart TD
  N0["Resultados de aprendizaje"]
  N1["37.1 Operaciones de seguridad para la IA"]
  N2["37.2 Manuales de operación para incidentes de IA"]
  N3["37.3 Gestión de vulnerabilidades"]
  N4["37.4 Gestión de cambios"]
  N5["37.5 Métricas operativas"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX109"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje"]
  N1["37.1 Operaciones de seguridad para la IA"]
  N2["37.2 Manuales de operación para incidentes de IA"]
  N3["37.3 Gestión de vulnerabilidades"]
  N4["37.4 Gestión de cambios"]
  N5["37.5 Métricas operativas"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX109"]
[Resultados de aprendizaje]
    |
    v
[37.1 Operaciones de seguridad para la IA]
    |
    v
[37.2 Manuales de operación para incidentes de IA]
    |
    v
[37.3 Gestión de vulnerabilidades]
    |
    v
[37.4 Gestión de cambios]
    |
    v
[37.5 Métricas operativas]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX109]

Resultados de aprendizaje

Usted será capaz de (1) operar sistemas de IA en producción con operaciones de seguridad (monitorización, respuesta a incidentes, gestión de vulnerabilidades); (2) redactar manuales de operación para incidentes propios de la IA; (3) gestionar operativamente los cambios de modelos y de prompts; y (4) informar de las métricas operativas.

37.1 Operaciones de seguridad para la IA

Envíe la telemetría de la IA al centro de operaciones de seguridad (SOC): señales del clasificador de inyecciones, denegaciones de la política, tasas inusuales de llamadas a herramientas, patrones de consulta propios de la extracción, fallos de verificación en la carga de modelos y alarmas de deriva. Defina gravedades y responsables. Los analistas del centro de operaciones de seguridad ya vigilan las señales de identidad, red y puestos finales, así que los sucesos de la IA resultan mucho más útiles junto a ellas: una ráfaga de denegaciones de la política desde una cuenta puede coincidir con un inicio de sesión sospechoso. Cada señal de la IA recibe una gravedad, un responsable y un manual de operación antes de activarse, porque una alerta que nadie entiende pronto se ignora. Sam empieza con unas pocas señales de alto valor y añade más una vez que las primeras están ajustadas y son de confianza.

37.2 Manuales de operación para incidentes de IA

Los manuales de operación dan los pasos para: sospecha de inyección de instrucciones con una acción ya realizada (contener: revocar las credenciales de las herramientas, desactivar la herramienta; investigar: rastrear los ID de petición hasta el documento de origen; recuperar: deshacer las acciones, purgar los documentos envenenados; aprender: añadirlo a las pruebas); sospecha de envenenamiento de datos (congelar el entrenamiento, identificar las versiones afectadas mediante el linaje, revertir a un modelo verificado); sospecha de extracción (limitar el cliente, conservar los registros, notificar al departamento jurídico); fallo de integridad del modelo (detener la carga, verificar la cadena de suministro).

La contención va primero en cada manual porque es rápida y reversible. La investigación viene después, una vez detenido el daño.

37.3 Gestión de vulnerabilidades

Haga un seguimiento de las vulnerabilidades del software de servicio de modelos, de las bibliotecas y de los conectores como con cualquier software. Haga un seguimiento de las debilidades a nivel de modelo (nuevas técnicas de jailbreak, ataques recién publicados) vigilando fuentes como los estudios de casos de MITRE ATLAS, los avisos de los proveedores y la investigación. Vuelva a probar tras las actualizaciones de modelos o de prompts. Las debilidades a nivel de modelo difieren de los errores de software: a menudo no hay parche, solo una mitigación como una prueba nueva, un filtro o un permiso de herramienta más estricto. Cada técnica recién publicada se evalúa frente al modelo de amenazas del propio sistema y se registra como no aplicable, mitigada o abierta. Volver a probar tras las actualizaciones importa porque una nueva versión del modelo puede ser más débil frente a un ataque antiguo que la versión anterior resistía.

37.4 Gestión de cambios

Los cambios en modelos, prompts, herramientas y fuentes de recuperación pasan por el proceso de publicación con controles de seguridad, despliegue canario y reversión. Los cambios de emergencia (p. ej., desactivar una herramienta) están aprobados de antemano en los manuales de operación. Una edición del prompt o una nueva fuente de recuperación pueden cambiar el comportamiento de seguridad tanto como el código nuevo, así que todos pasan por el mismo control. Los cambios de emergencia aprobados de antemano permiten al ingeniero de guardia desactivar una herramienta por la noche sin esperar a una reunión, aunque el cambio se sigue registrando y se revisa al día siguiente. El objetivo es rapidez para la contención y cuidado para todo lo demás.

37.5 Métricas operativas

Informe mensualmente de: denegaciones y confirmaciones de la política, señales de inyección, incidentes por tipo y tiempo hasta la contención, resultados del conjunto de evaluación por publicación, superaciones de cuota y riesgos abiertos. Las tendencias importan más que los números aislados. Un número creciente de confirmaciones puede significar más trabajo legítimo o una nueva campaña de inyección, y la tendencia junto a las señales y los incidentes ayuda a distinguirlo. El tiempo hasta la contención muestra si los manuales de operación funcionan en la práctica. Los resultados de evaluación por publicación muestran si la seguridad mejora o empeora a medida que cambia el sistema. Los riesgos abiertos mantienen visibles los problemas aceptados, para que se revisen en lugar de olvidarse.

37.6 Ejemplo resuelto (caso sintético de NRS)

A las 02:10, el SOC vio una ráfaga de propuestas de Wrench para crear órdenes de trabajo en una línea, todas confirmadas en segundos por una única cuenta del turno de noche. El manual de operación llevó al ingeniero de guardia a suspender el acceso de esa cuenta a las herramientas de Wrench, rastrear las propuestas hasta un boletín subido a la 01:55 y descubrir que contenía texto con apariencia de instrucción. El titular de la cuenta había aprobado sin leer. Las órdenes se cancelaron; la fuente del boletín se bloqueó; la interfaz de aprobación incorporó un límite de aprobaciones por minuto.

Cada confirmación llevó segundos, un patrón que ningún revisor cuidadoso produce.

37.7 Errores y límites

Si la telemetría de la IA se queda en un panel de ingeniería, nadie la vigila a las 02:10. Sin manuales de operación propios de los modelos, quienes responden improvisan, a menudo apagando todo el servicio cuando bastaría con desactivar una herramienta. Los cambios de emergencia que necesitan un comité pierden horas mientras el ataque continúa. El incidente anterior se resolvió bien porque las tres cosas estaban en su sitio: la alerta llegó al SOC, existía un manual de operación y la suspensión del acceso estaba aprobada de antemano.

Ejercicios — capítulo 37

Síntesis del capítulo

Las operaciones mantienen viva la seguridad de la IA después de la publicación: telemetría en el SOC, manuales de operación propios de la IA, gestión de vulnerabilidades y de cambios, e informes de tendencias.

Siga estudiando — capítulo 37 de 50

← Capítulo 36 (borrador) · Índice de capítulos del curso · Capítulo 38 (borrador) →