Capítulo 18 — Seguridad de la IA y del aprendizaje automático: controles
Mapa de la lección
Lección 18 publicada. Mapa, ejemplo, EX052.
flowchart TD
N0["Resultados de aprendizaje"]
N1["18.1 Servicio de políticas"]
N2["18.2 Controles de entrada"]
N3["18.3 Controles de salida"]
N4["18.4 Confirmación humana"]
N5["18.5 Verificación de los controles"]
N6["Síntesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX052"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["18.1 Servicio de políticas"]
N2["18.2 Controles de entrada"]
N3["18.3 Controles de salida"]
N4["18.4 Confirmación humana"]
N5["18.5 Verificación de los controles"]
N6["Síntesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX052"]
[Resultados de aprendizaje]
|
v
[18.1 Servicio de políticas]
|
v
[18.2 Controles de entrada]
|
v
[18.3 Controles de salida]
|
v
[18.4 Confirmación humana]
|
v
[18.5 Verificación de los controles]
|
v
[Síntesis]
|
v
[Ejemplo resuelto] --> [Ejercicio EX052]
Resultados de aprendizaje
Usted podrá (1) implantar un servicio de políticas para las herramientas de los agentes; (2) configurar controles de entrada y de salida; (3) implantar correctamente la confirmación humana; y (4) verificar cada control con pruebas.
18.1 Servicio de políticas
El servicio de políticas recibe una acción propuesta (herramienta, parámetros, identidad del usuario, tipo de conversación) y devuelve permitir o denegar con un motivo. Las reglas son código: "start_return allowed only if order.owner == user and order.status == delivered and today − delivered_date ≤ 30 days and value ≤ €1,000". El modelo nunca ve esta lógica ni puede eludirla. Mantenga las reglas pequeñas y legibles para que los revisores puedan comprobarlas, y registre cada decisión con su motivo. La regla refleja la política de devoluciones de 30 días que publica Brightwell, de modo que el servicio aplica la misma promesa que los clientes leen en el sitio web.
18.2 Controles de entrada
Limite la longitud de los mensajes; restrinja las fuentes de recuperación; marque el contenido no confiable con delimitadores; y, si lo desea, ejecute un clasificador de inyecciones como señal. Los enfoques de consultas estructuradas, como StruQ (arXiv:2402.06363), separan las instrucciones de los datos en la interfaz del modelo; reducen el riesgo, pero no lo eliminan. Los controles de entrada reducen la frecuencia con que se producen salidas dañinas; no acotan el daño cuando una de ellas se cuela. En Ask Brightwell, los controles de entrada son el límite de longitud de la pasarela, la recuperación restringida a documentos públicos sin reseñas y los delimitadores en torno al texto recuperado. El prompt separado redujo las propuestas dañinas en el estudio de Jonas, pero el servicio de políticas sigue siendo el control que acota el daño cuando se cuela una inyección.
18.3 Controles de salida
Valide las acciones estructuradas; escape el texto para su destino; elimine o restrinja con una lista de permitidos los enlaces y las imágenes de las respuestas (para evitar que los datos se filtren a través de URL); y, cuando sea viable, compruebe las respuestas sobre precios o políticas frente a los documentos de origen. En Ask Brightwell, las respuestas solo pueden contener enlaces al propio dominio de Brightwell y las imágenes no se muestran, porque de lo contrario una instrucción inyectada podría ocultar datos de clientes en una URL. Las respuestas sobre el plazo de devolución se comparan con la página de políticas vigente, lo que habría detectado antes la página caducada de la campaña de 60 días. Los controles de salida se prueban con casos colocados, como cualquier otro control.
18.4 Confirmación humana
Muestre al usuario exactamente lo que va a ocurrir, construido a partir de datos estructurados: "Start a return for order 100245 — Oslo sofa, €899 — refund to card ending 4421? Yes / No". No muestre resúmenes escritos por el modelo en la confirmación, porque un texto inyectado puede hacer que acciones dañinas parezcan inofensivas. Haga que las confirmaciones sean lo bastante infrecuentes para que la gente siga leyéndolas. La confirmación de Ask Brightwell usa exactamente este formato, con valores tomados del registro del pedido. Como la confirmación solo aparece para las devoluciones y los cambios de dirección, los clientes la ven pocas veces y es más probable que la lean.
18.5 Verificación de los controles
Cada control recibe pruebas unitarias (las reglas permiten y deniegan los casos correctos) y pruebas de conjunto (los casos de inyección ya no provocan acciones dañinas). Vuelva a ejecutarlas en cada cambio; un control que se rompe en silencio durante una refactorización es peor que uno ausente, porque la gente confía en él. El servicio de políticas de Ask Brightwell tiene 40 pruebas unitarias que cubren casos límite, como una entrega hecha exactamente hace 30 días, y el conjunto reservado de inyecciones se ejecuta cada noche contra preproducción. Cuando más tarde un cambio de prompt de un desarrollador aumentó las propuestas dañinas, estas pruebas y la puerta lo detectaron antes de la publicación. Cada prueba nombra la regla que comprueba, de modo que un fallo indica al desarrollador qué regla se rompió.
18.6 Ejemplo resuelto (caso sintético de Brightwell)
Tras añadir el servicio de políticas y la confirmación estructurada, Jonas vuelve a ejecutar el conjunto reservado: las devoluciones dañinas bajan de 31 de 80 casos indirectos a 0 de 80 (cota superior ≈ 4 %); las devoluciones normales siguen completándose en el 97 % de 500 conversaciones de prueba. Añade 40 pruebas unitarias para las reglas de políticas, incluidos casos límite como pedidos entregados exactamente hace 30 días. La cota superior importa: cero de 80 no demuestra que el riesgo sea nulo, solo que una tasa alta es improbable. Medir a la vez las devoluciones normales muestra que el control no compró la seguridad rechazándolo todo.
18.7 Errores y límites
- Reglas de políticas escritas en el prompt.
- Texto de confirmación redactado por el modelo.
- Controles sin pruebas.
El diseño de Ask Brightwell evita cada uno de ellos. Las reglas de devolución residen en el servicio de políticas, no en el prompt; la pantalla de confirmación se construye a partir del registro del pedido; y cada regla tiene pruebas unitarias. Una regla escrita en el prompt puede sortearse con una reseña colocada. Un control sin pruebas puede desaparecer en una refactorización sin que nadie lo note hasta el siguiente incidente. La pantalla de confirmación tiene ahora su propia prueba.
Ejercicios
- EX052 — Reglas. Redacte reglas de políticas para una herramienta "update delivery address". Rúbrica: 3 = propiedad, estado, verificación, límites, denegación por defecto; 2 = tres o cuatro; 1 = una o dos; 0 = ninguna.
- EX053 — Control de enlaces. ¿Por qué eliminar los enlaces externos de las respuestas? Rúbrica: 3 = exfiltración de datos mediante parámetros de URL o cargas de imágenes; 2 = parcial; 1 = vago; 0 = erróneo.
- EX054 — Resultado. Informe en una frase, con sus condiciones, de los resultados de la nueva ejecución con el servicio de políticas. Rúbrica: 3 = cifras, cota, finalización, condiciones; 2 = falta uno; 1 = vago; 0 = nada.
Síntesis
Los controles que importan son código fuera del modelo (servicios de políticas, validadores, confirmación estructurada), y cada uno se demuestra con pruebas.
Siga estudiando — capítulo 18 de 30
← Capítulo 17 (borrador) · Índice de capítulos del curso · Capítulo 19 (borrador) →