Capítulo 33 — Seguridad de la IA y del aprendizaje automático: seguridad funcional y resiliencia
Mapa de la lección
Lección 33 publicada. Mapa, ejemplo, EX097.
flowchart TD
N0["Resultados de aprendizaje"]
N1["33.1 Fallo seguro"]
N2["33.2 Resiliencia"]
N3["33.3 Supervisión humana efectiva"]
N4["33.4 Mal uso de las capacidades generativas"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX097"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["33.1 Fallo seguro"]
N2["33.2 Resiliencia"]
N3["33.3 Supervisión humana efectiva"]
N4["33.4 Mal uso de las capacidades generativas"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX097"]
[Resultados de aprendizaje]
|
v
[33.1 Fallo seguro]
|
v
[33.2 Resiliencia]
|
v
[33.3 Supervisión humana efectiva]
|
v
[33.4 Mal uso de las capacidades generativas]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX097]
Resultados de aprendizaje
Usted será capaz de (1) diseñar sistemas de IA que sigan siendo seguros cuando sus componentes fallan o son atacados; (2) aplicar los conceptos de resiliencia (anticipar, resistir, recuperarse, adaptarse); (3) definir una supervisión humana que sea efectiva y no meramente nominal; y (4) planificar frente al mal uso de las capacidades generativas.
33.1 Fallo seguro
Cada vía de decisión de la IA necesita un estado seguro definido: inspección manual, un valor predeterminado conservador, rechazar una acción o escalar a una persona. Los casos de seguridad argumentan, con evidencia, que los peligros están controlados hasta niveles aceptables, incluidos los peligros causados por adversarios. Para TrackEye, el estado seguro es la inspección manual del tramo afectado; para Wrench, es rechazar la acción de herramienta y explicar al técnico por qué. Elegir los estados seguros es una decisión de diseño con costes: la inspección manual consume tiempo del personal y los rechazos ralentizan el trabajo. El caso de seguridad expone esos costes y muestra que son aceptables, lo que también deja claro qué ocurriría si un atacante forzara deliberada y repetidamente al sistema a entrar en su estado seguro.
33.2 Resiliencia
La resiliencia es la capacidad de anticipar condiciones adversas, resistirlas, recuperarse de ellas y adaptarse a ellas. En la IA: anticipar con modelos de amenazas y monitorización; resistir con controles en capas; recuperarse con reversiones, reentrenamiento a partir de datos verificados y revocación de credenciales; adaptarse actualizando las pruebas y los controles después de los incidentes. El NIST AI RMF incluye secure and resilient (segura y resiliente) entre las características de una IA digna de confianza. La recuperación depende de la preparación hecha antes. Reentrenar a partir de datos verificados solo es posible si se conservaron las versiones y los hashes de los datos. Revocar credenciales con rapidez exige un procedimiento probado y credenciales de alcance estrecho que puedan revocarse sin detenerlo todo. Adaptarse significa que cada incidente deja una huella en el sistema: una prueba nueva en el conjunto, un umbral modificado o un manual de operación actualizado, de modo que el mismo fallo sea menos probable la próxima vez.
33.3 Supervisión humana efectiva
La supervisión falla cuando las personas aprueban por costumbre («sesgo de automatización») o carecen de información. Una supervisión efectiva muestra la evidencia en la que se basa una propuesta (fuentes, confianza, qué es inusual), limita el volumen para que los revisores puedan concentrarse y hace un seguimiento de la calidad de las aprobaciones (por ejemplo, insertando propuestas de prueba que se sabe que son erróneas para medir las tasas de detección, con el consentimiento de los revisores y una política clara). El Reglamento de IA de la UE exige que los sistemas de alto riesgo se diseñen para permitir una supervisión humana efectiva (artículo 14).
Las propuestas que se sabe que son erróneas deben poder identificarse claramente después, para que nunca se ejecuten. Los resultados se comparten con los revisores como grupo y nunca se usan para clasificar a las personas.
33.4 Mal uso de las capacidades generativas
Los sistemas generativos pueden usarse indebidamente para producir contenido dañino o para facilitar ataques. NIST AI 600-1 analiza riesgos que incluyen la seguridad de la información y el contenido peligroso, con acciones sugeridas. Las respuestas de ingeniería incluyen políticas de uso, monitorización de abusos, entrenamiento para el rechazo, límites de frecuencia y la restricción de las capacidades de alto riesgo a usuarios autenticados que rindan cuentas. Restringir las capacidades a usuarios autenticados hace que el mal uso sea atribuible, lo que lo disuade y facilita la investigación. Para Wrench, el riesgo es moderado, ya que sus herramientas son limitadas, pero a un generador de texto general conectado a documentos internos se le podría pedir que redactara un phishing convincente con nombres reales de proveedores. La monitorización de abusos busca patrones de ese tipo, y las políticas de uso indican al personal qué es aceptable antes de que nadie tenga que hacerlas cumplir.
33.5 Ejemplo resuelto (caso sintético de NRS)
Sam midió que los técnicos aprobaban el 97 % de las propuestas de órdenes de trabajo de Wrench en una mediana de 4 segundos. Con el acuerdo de los técnicos, un ejercicio mensual insertó propuestas de prueba sintéticas, claramente marcadas, con activos equivocados; solo se rechazó el 60 %. El equipo rediseñó la pantalla de aprobación para resaltar los activos fuera de las rutas habituales del técnico y cualquier texto de origen con apariencia de instrucción; en el ejercicio siguiente, la tasa de detección subió al 88 %. La alta tasa de aprobación y la mediana de cuatro segundos eran las señales de alarma, ya que nadie lee un documento de origen en cuatro segundos. Una tasa de detección del 60 % significaba que se habrían aprobado dos de cada cinco propuestas erróneas. El rediseño hizo visible la información importante en lugar de pedir a las personas que se esforzaran más, y el ejercicio siguiente midió el efecto en lugar de darlo por supuesto.
33.6 Errores y límites
- La revisión humana como mera casilla de verificación.
- Ausencia de un estado seguro definido.
- Planes de recuperación que suponen que hay datos limpios disponibles sin haberlos conservado.
Una revisión de casilla de verificación crea la apariencia de control mientras lo aprueba casi todo. Sin un estado seguro definido, un componente que falla puede seguir funcionando en un modo inseguro o detenerse en uno no planificado. Los planes de recuperación fracasan el día que se necesitan si nunca se conservaron los datos limpios, los modelos firmados o las credenciales en los que se basan. Cada uno de estos puntos se comprueba mediante ejercicios, no leyendo el plan, porque los planes suelen dar por supuestas cosas que nadie ha probado.
Ejercicios — capítulo 33
- EX097 — Estados seguros. Defina los estados seguros de TrackEye, Wrench y Pulse. Rúbrica: 3 = inspección manual, ninguna acción/escalar, alerta conservadora/comprobación manual; 2 = dos; 1 = uno; 0 = ninguno.
- EX098 — Resiliencia. Dé una acción para cada una de las fases anticipar, resistir, recuperarse y adaptarse en Wrench. Rúbrica: 3 = cuatro adecuadas; 2 = tres; 1 = una o dos; 0 = ninguna.
- EX099 — Supervisión. ¿Por qué insertar propuestas de prueba reveló un problema y qué mejoró la supervisión? Rúbrica: 3 = midió la tasa de detección real (60 %) frente a la supuesta; resaltar lo inusual y la información de la fuente; 2 = parcial; 1 = vago; 0 = nada.
Síntesis del capítulo
La seguridad funcional y la resiliencia parten de que los controles fallarán a veces. Los estados seguros, los planes de recuperación y una supervisión humana medida y bien diseñada mantienen acotados los fallos.
Siga estudiando — capítulo 33 de 50
← Capítulo 32 (borrador) · Índice de capítulos del curso · Capítulo 34 (borrador) →