Capítulo 16 — Arquitectura de seguridad

Mapa de la lección

Lección 16 publicada. Mapa, ejemplo, EX046.

flowchart TD
  N0["Resultados de aprendizaje"]
  N1["16.1 Principios aplicados a la IA"]
  N2["16.2 Fronteras de confianza en las aplicaciones con"]
  N3["16.3 El punto de aplicación de políticas"]
  N4["16.4 Comparar opciones"]
  N5["Síntesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX046"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje"]
  N1["16.1 Principios aplicados a la IA"]
  N2["16.2 Fronteras de confianza en las aplicaciones con"]
  N3["16.3 El punto de aplicación de políticas"]
  N4["16.4 Comparar opciones"]
  N5["Síntesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX046"]

[Resultados de aprendizaje]
    |
    v
[16.1 Principios aplicados a la IA]
    |
    v
[16.2 Fronteras de confianza en las aplicaciones con]
    |
    v
[16.3 El punto de aplicación de políticas]
    |
    v
[16.4 Comparar opciones]
    |
    v
[Síntesis]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX046]

Resultados de aprendizaje

Usted podrá (1) aplicar el mínimo privilegio, la defensa en profundidad, la mediación completa y los valores predeterminados a prueba de fallos a los sistemas de IA; (2) trazar las fronteras de confianza en las aplicaciones con LLM; (3) situar un punto de aplicación de políticas fuera del modelo; y (4) comparar opciones de arquitectura por su riesgo residual.

16.1 Principios aplicados a la IA

Mínimo privilegio: dé al modelo y a sus herramientas solo los permisos necesarios. Defensa en profundidad: combine el etiquetado de la entrada, la validación de la salida, las comprobaciones de políticas, la supervisión y la revisión humana. Mediación completa: compruebe cada acción, cada vez. Valores predeterminados a prueba de fallos: deniegue en caso de duda. En Ask Lumen, el mínimo privilegio es el token delegado; la defensa en profundidad combina el etiquetado del texto recuperado, el análisis de la salida, la comprobación de políticas y el registro; la mediación completa significa que cada reserva pasa por la comprobación de políticas, incluidas las propuestas al final de una conversación larga; los valores predeterminados a prueba de fallos significan que una propuesta que no puede analizarse o resulta dudosa se rechaza, y se indica al paciente cómo reservar por teléfono.

16.2 Fronteras de confianza en las aplicaciones con LLM

Un modelo de lenguaje recibe instrucciones de confianza (de los desarrolladores), entrada de confianza parcial (de los usuarios) y contenido no confiable (documentos recuperados, páginas web, resultados de herramientas) en una única secuencia de tokens. No puede distinguirlos de forma fiable, y por eso funciona la inyección indirecta de instrucciones (Greshake et al., arXiv:2302.12173). Por tanto, la arquitectura debe imponer las consecuencias fuera del modelo. En Ask Lumen, la instrucción del sistema es de confianza, el mensaje del paciente es de confianza parcial y los documentos recuperados de las clínicas, sobre todo las subidas de asociados, son no confiables. Etiquetarlos ayuda al modelo, pero no garantiza que ignore las instrucciones dentro de un documento, así que son las propias comprobaciones de la herramienta de reservas las que acotan el resultado.

16.3 El punto de aplicación de políticas

El modelo propone acciones; un componente aparte, pequeño y probado, decide si ejecutarlas en función de la identidad del usuario, la acción, sus parámetros y si el contenido no confiable influyó en ella. Las acciones de alto impacto requieren confirmación humana. Aquí se aborda OWASP LLM06 (excessive agency, agencia excesiva). Mantener pequeño este componente es deliberado: unos cientos de líneas de código pueden revisarse y probarse a fondo, a diferencia del modelo. En Ask Lumen, el punto de políticas compara el paciente de la reserva con el sujeto del token, comprueba las reglas de clínica y fecha y exige confirmación para las cancelaciones. Cada decisión, permitida o rechazada, se registra con el identificador de petición.

16.4 Comparar opciones

Las opciones para un chatbot de reservas van desde ninguna herramienta (solo respuestas) hasta el uso libre de herramientas. Entre ambos extremos: herramientas con comprobaciones de políticas y confirmaciones. Compare por riesgo residual, utilidad y coste, y registre la decisión con su razonamiento. El riesgo residual es lo que queda después de los controles; la utilidad es cuántos pacientes pueden completar su tarea; el coste incluye construir y operar cada opción. Una tabla con estas tres columnas hace visible el compromiso. Registrar el razonamiento permite que un equipo posterior entienda por qué se tomó la decisión y la revise si cambian las condiciones, por ejemplo si se añade una herramienta nueva.

16.5 Ejemplo resuelto (caso sintético de LCH)

La nota de arquitectura de Rina para Ask Lumen v2 enumeraba tres opciones: (a) el modelo reserva directamente; (b) el modelo propone, la política comprueba la identidad del paciente y la clínica, y el paciente confirma en la interfaz; (c) el chatbot da instrucciones y los pacientes reservan por su cuenta. LCH eligió (b): la confirmación añade un clic, pero el texto inyectado ya no puede reservar ni cancelar sin una acción del paciente. La opción (a) se rechazó porque un solo documento inyectado podía actuar; la opción (c), porque eliminaba la mayor parte del valor del chatbot. El estudio de investigación del capítulo de métodos de investigación midió después el coste del clic adicional de (b).

16.6 Errores y límites

• Reglas de seguridad escritas solo en la instrucción del sistema.
• Herramientas con permisos más amplios que los usuarios.
• Ningún registro de por qué se eligió una arquitectura.

Las reglas escritas solo en la instrucción del sistema pueden anularse con un texto persuasivo, porque el modelo trata ambos como lenguaje. Las herramientas con permisos más amplios que los usuarios permiten que un modelo manipulado supere lo que cualquier usuario podría hacer. Sin un registro de por qué se eligió una arquitectura, los cambios posteriores pueden eliminar un control sin darse cuenta de contra qué protegía, como el paso de confirmación que detiene las reservas inyectadas.

Ejercicios

• EX046 — Principios. Aplique tres principios a DocSort. Rúbrica: 3 = tres aplicaciones concretas; 2 = dos; 1 = solo nombres; 0 = nada.
• EX047 — Frontera. ¿Por qué el modelo no puede imponer por sí mismo la frontera de confianza? Rúbrica: 3 = flujo único de tokens, seguimiento estadístico de instrucciones; 2 = parcial; 1 = vago; 0 = incorrecto.
• EX048 — Elección de opción. Defienda en dos frases la opción (b) frente a la (a). Rúbrica: 3 = impacto acotado de la inyección con una fricción modesta; 2 = parcial; 1 = vago; 0 = nada.

Síntesis

La arquitectura de seguridad saca la aplicación de las reglas fuera del modelo: las fronteras de confianza, un punto de políticas externo y la confirmación humana acotan lo que puede hacer un modelo manipulado.

Siga estudiando — capítulo 16 de 40

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