Capítulo 28 — Seguridad de la IA y del aprendizaje automático: implementación I
Mapa de la lección
Lección 28 publicada. Mapa, ejemplo, EX082.
flowchart TD
N0["Resultados de aprendizaje"]
N1["28.1 Punto de aplicación de políticas"]
N2["28.2 Etiquetado de la procedencia"]
N3["28.3 Validación de salidas y búsqueda de secretos"]
N4["28.4 Pruebas de la implementación"]
N5["28.6b Fallar de forma cerrada en el punto de aplicac"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX082"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["28.1 Punto de aplicación de políticas"]
N2["28.2 Etiquetado de la procedencia"]
N3["28.3 Validación de salidas y búsqueda de secretos"]
N4["28.4 Pruebas de la implementación"]
N5["28.6b Fallar de forma cerrada en el punto de aplicac"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX082"]
[Resultados de aprendizaje]
|
v
[28.1 Punto de aplicación de políticas]
|
v
[28.2 Etiquetado de la procedencia]
|
v
[28.3 Validación de salidas y búsqueda de secretos]
|
v
[28.4 Pruebas de la implementación]
|
v
[28.6b Fallar de forma cerrada en el punto de aplicac]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX082]
Resultados de aprendizaje
Usted será capaz de (1) implementar un punto de aplicación de políticas para las acciones propuestas por el modelo; (2) implementar el etiquetado de la procedencia en los prompts; (3) implementar la validación de salidas y la búsqueda de secretos; y (4) probar la implementación con pruebas unitarias, pruebas basadas en propiedades y pruebas adversariales.
28.1 Punto de aplicación de políticas
El modelo emite una propuesta (nombre de la herramienta y argumentos según un esquema). El punto de aplicación valida el esquema, comprueba la herramienta frente al rol del usuario, comprueba los argumentos frente al ámbito (depósito, activo), comprueba si los argumentos están contaminados por contenido no confiable y decide: permitir, exigir confirmación o denegar. Las decisiones se registran con sus motivos.
ROLE_TOOLS = {"technician": {"search", "create_work_order"}, "viewer": {"search"}}
def decide(role, tool, args, tainted):
if tool not in ROLE_TOOLS.get(role, set()):
return "deny: tool not allowed for role"
if tool == "create_work_order":
return "confirm: tainted arguments" if tainted else "confirm: high impact"
return "allow"
for case in [("viewer", "create_work_order", {}, False), ("technician", "search", {}, True),
("technician", "create_work_order", {"asset": "AX12"}, True)]:
print(case[:2], "->", decide(*case))
Imprime deny, allow y confirm: tainted arguments para los tres casos.
El orden de las comprobaciones importa: primero el rol, de modo que la petición de un usuario con rol de consulta se rechaza antes de examinar nada más, y después el impacto y la contaminación. La búsqueda de un técnico con argumentos contaminados se permite, porque la búsqueda no cambia nada, mientras que cualquier orden de trabajo necesita confirmación y la contaminada indica por qué.
28.2 Etiquetado de la procedencia
Al montar un prompt, envuelva cada fragmento recuperado con su fuente y su nivel de confianza, e indique en las instrucciones del sistema que el contenido etiquetado como no confiable son datos. Esto ayuda al modelo, pero no es una frontera de seguridad; el punto de aplicación sigue siendo el que tiene la autoridad. Un envoltorio típico dice: '[source: supplier bulletin SB-2291, trust: external] … [end source]'. Las etiquetas mejoran de media el comportamiento del modelo y dan contexto a los técnicos cuando revisan una propuesta, ya que la pantalla de confirmación puede mostrar qué fuentes etiquetadas influyeron en ella. Pero un atacante puede escribir texto que imite una etiqueta o que diga al modelo que la ignore, y por eso la etiqueta informa y el punto de aplicación decide.
28.3 Validación de salidas y búsqueda de secretos
Valide las salidas estructuradas con analizadores estrictos. Busque en las salidas de texto libre secretos (patrones de claves de API, nombres de equipos internos) y datos personales antes de mostrarlas o enviarlas. Escape las salidas antes de representarlas en páginas web para evitar la inyección de scripts (OWASP LLM05). Un analizador estricto rechaza todo lo que esté fuera de la estructura esperada en lugar de adivinar qué se quería decir. La búsqueda de secretos usa los mismos patrones que los repositorios de código y añade nombres internos que nunca deberían salir de la organización. El escapado importa porque se puede inducir a un modelo a emitir etiquetas de script o enlaces, y una interfaz de chat que los representara ejecutaría el código de un atacante en el navegador de un técnico.
28.4 Pruebas de la implementación
Las pruebas unitarias cubren cada regla; las pruebas basadas en propiedades generan propuestas aleatorias y comprueban invariantes; las pruebas adversariales reproducen de principio a fin un corpus de documentos inyectados y verifican que no se ejecuta ninguna acción prohibida. Los tres tipos detectan fallos distintos. Las pruebas unitarias muestran que cada regla hace lo que dice. Las pruebas basadas en propiedades encuentran combinaciones en las que nadie había pensado, como una cadena de rol vacía. La reproducción de principio a fin comprueba toda la vía, incluidos los adaptadores y el registro, que es donde se esconden los errores de orden. El corpus de reproducción crece con cada nuevo patrón de ataque encontrado, y un caso, una vez añadido, nunca se retira, de modo que las debilidades antiguas no pueden volver sin que nadie lo note.
28.5 Ejemplo resuelto (caso sintético de NRS)
Sam implementó el punto de aplicación como un servicio independiente con 140 líneas de código de políticas y 60 pruebas. Una reproducción adversarial de 600 boletines sintéticos con inyecciones produjo 41 propuestas del modelo de órdenes de trabajo; las 41 se dirigieron a confirmación con la marca de contaminación y ninguna se ejecutó automáticamente. Cuarenta y una propuestas de 600 son aproximadamente un 6,8 %, muy por encima del 2 % que el requisito permite para las propuestas, así que la reproducción también produjo un hallazgo para el equipo de prompts. El punto de aplicación cumplió su propia función: las propuestas en exceso llegaron a la pantalla de confirmación de un técnico marcadas como contaminadas, y no se ejecutó nada. Las 60 pruebas forman parte de la compilación, de modo que cualquier cambio en el código de políticas debe superarlas antes de su publicación.
28.6 Errores y límites
- La aplicación de políticas dentro del prompt del modelo.
- Representar la salida del modelo como HTML sin escaparla.
- Pruebas que solo cubren el camino feliz.
Las reglas enunciadas solo en el prompt son sugerencias para el modelo, no aplicación de políticas. La salida sin escapar convierte la ventana de chat en una superficie de ataque para la inyección de scripts. Las pruebas del camino feliz confirman que las acciones permitidas funcionan, pero nunca muestran que las prohibidas se rechazan. La prueba de fallo cerrado que se describe a continuación es un ejemplo de las pruebas negativas que necesita cada regla del punto de aplicación, junto con la reproducción de documentos inyectados.
28.6b Fallar de forma cerrada en el punto de aplicación
Si el punto de aplicación de políticas de Wrench no puede cargar sus reglas o no llega a su servicio de decisión, rechaza la acción de herramienta solicitada y le explica al técnico por qué, en lugar de permitirla. NRS prueba esta vía en cada publicación arrancando el servicio sin el archivo de políticas. La prueba importa porque el fallo opuesto es silencioso: un punto de aplicación que permite las acciones cuando falta su archivo de políticas parece sano en todas las pruebas funcionales. En la reproducción de 600 boletines de Sam, las 41 propuestas de órdenes de trabajo llegaron a la pantalla de confirmación de un técnico; con un servicio que fallara de forma abierta y sin políticas cargadas, esas mismas 41 se habrían convertido en órdenes de trabajo sin que nadie las revisara.
Ejercicios — capítulo 28
- EX082 — Decidir. ¿Qué devuelve
decide("viewer", "search", {}, True)y por qué? Rúbrica: 3 = "allow"; la búsqueda está permitida para el rol de consulta; aquí la contaminación solo importa para la herramienta de alto impacto; 2 = solo el valor; 1 = incorrecto pero razonado; 0 = nada. - EX083 — Límites del etiquetado. ¿Por qué el etiquetado de la procedencia en el prompt no es una frontera de seguridad? Rúbrica: 3 = el modelo puede seguir aún el texto inyectado; la aplicación debe ser externa; 2 = parcial; 1 = vago; 0 = incorrecto.
- EX084 — Reproducción adversarial. Describa la prueba adversarial de principio a fin y su criterio de superación. Rúbrica: 3 = reproducir el corpus inyectado a través del sistema completo; se supera con cero ejecuciones no autorizadas y todas las propuestas contaminadas confirmadas; 2 = parcial; 1 = vago; 0 = nada.
Síntesis del capítulo
La implementación hace real la arquitectura: un punto de aplicación pequeño y probado, la procedencia etiquetada, un tratamiento estricto de las salidas y pruebas de reproducción adversarial.
Siga estudiando — capítulo 28 de 50
← Capítulo 27 (borrador) · Índice de capítulos del curso · Capítulo 29 (borrador) →