Capítulo 10 — Diseño de arquitecturas seguras para LLM

Décima entrega del recorrido capítulo por capítulo de LLM Primer VII: Seguridad de la IA. El capítulo que trata la arquitectura como la disciplina primaria de seguridad — porque la configuración más segura de un componente probabilístico es aquella cuyo radio de daño está acotado por la estructura, no por la propia moderación del componente.

Por qué existe este capítulo

Los capítulos de las partes I a III han nombrado las amenazas y las defensas del lado del modelo. El capítulo 10 recorre la arquitectura alrededor del modelo — las fronteras de aislamiento, los niveles de validación, los motores de políticas, los contratos de API y los principios zero-trust que dan al sistema sus propiedades estructurales. La premisa es la de siempre en ingeniería de seguridad: asume el compromiso, contén el daño, haz que el compromiso sea legible. Lo nuevo es que el componente a contener es un orquestador guiado por lenguaje natural cuyas instrucciones pueden llegar por cualquier canal de entrada. Los patrones arquitectónicos se transfieren de eras anteriores; los detalles de cómo se aplican a los LLM son donde este capítulo hace su trabajo.

10.1 El aislamiento acota el radio de daño

Una frontera de aislamiento es una costura deliberada a través de la cual un componente a un lado no puede afectar directamente a un componente al otro lado sin atravesar una interfaz controlada. La razón de seguridad para el aislamiento es que el daño por compromiso está acotado por lo que el componente comprometido podría alcanzar a través de sus interfaces legítimas. Para sistemas LLM la cuestión de aislamiento más importante es entre el modelo y todo lo demás a lo que el sistema tiene acceso. Un modelo que corre en un proceso con acceso irrestricto al sistema de ficheros, acceso irrestricto a la red y una herramienta de ejecución de shell sin allow-list tiene un radio de daño grande. Un modelo cuyo proceso corre en un sandbox con un conjunto de syscalls definido, cuyo acceso a red va a través de un proxy de egress con allow-listing a nivel de dominio, cuyas herramientas se invocan mediante tokens de capacidad que el código circundante emite por petición, tiene uno mucho más pequeño. El patrón se extiende a la ejecución de código — herramientas sandbox como las que OpenAI y Anthropic usan para sus entornos de code-interpreter ejecutan código generado en VMs efímeras de gVisor o Firecracker — y al browsing, donde navegadores headless corren en namespaces de red aislados sin acceso a endpoints internos. El aislamiento es una decisión de diseño tomada antes de que ocurra ningún ataque específico, y es la inversión de seguridad más barata por unidad de reducción de radio de daño que el campo ofrece.

10.2 La validación es por capas y la política es declarativa

Un único punto de validación es un único punto de fallo. Los endpoints LLM de producción componen típicamente cinco capas entre la petición del cliente y la respuesta. La autenticación verifica la credencial del principal. La validación de petición comprueba la petición contra el esquema de la API — tipos, rangos, longitudes, conjuntos de caracteres. La evaluación de política pregunta si el principal autenticado, la petición validada y el estado actual del sistema permiten esta acción. La llamada al modelo corre con el system prompt, la entrada de usuario validada, la lista de herramientas restringida a lo que la política permite y las restricciones de salida. El filtrado de salida comprueba la respuesta en busca de contenido que no debe devolverse — secretos filtrados, contenido prohibido, llamadas a herramientas inseguras — antes de enviarse. La lógica de política crece con el tiempo y, si está dispersa por el código de aplicación, se convierte en la unión de muchos condicionales difícil de inspeccionar, probar o evolucionar. El campo ha convergido en separar política del código. Open Policy Agent (OPA), proyecto CNCF, evalúa políticas escritas en Rego. AWS Cedar, publicado en 2023, es un lenguaje de autorización más enfocado con propiedades de verificación formal. Ambos están listos para producción; la elección suele ser de alineamiento organizacional. Las políticas se convierten en artefactos versionados y revisables, y la política de seguridad efectiva del sistema siempre es legible en un solo sitio.

10.3 Zero-trust aplicado a las llamadas al modelo

La API es el contrato entre el sistema LLM y sus llamadores. El diseño seguro de API es la disciplina de dar forma al contrato para que sus invariantes sobrevivan al contacto con llamadores adversariales. Los esquemas de entrada explícitos — tipos estrictos, rangos, enumeraciones allow-listed — cuestan poco y acotan la confianza implícita que la API deposita en el llamador. Las respuestas de error estructuradas que no filtran estado interno evitan la recopilación de inteligencia que los errores vagamente redactados habilitan. Las claves de idempotencia, los request IDs y el versionado dan al sistema observabilidad sobre el comportamiento del llamador sin requerir estado extra. El modelo zero-trust, articulado en el artículo BeyondCorp de Google de 2014 y formalizado en NIST SP 800-207 en 2020, extiende el principio: ningún llamador es confiable por virtud de la ubicación en la red. Cada petición se autentica, se autoriza contra política explícita, se evalúa contra dispositivo y contexto, y se registra. Aplicado a sistemas LLM, la llamada al modelo en sí se convierte en un principal — una petición del modelo a una herramienta downstream se autentica como el modelo, carga la identidad del humano en cuyo nombre el modelo está operando, y se autoriza contra política que conoce ambas identidades. Los tokens de capacidad con alcance estrecho y TTL corto son lo que hace esto composicional. El resultado es que un prompt comprometido no puede escalarse a compromiso completo del sistema porque las propias capacidades del modelo están acotadas por tokens que el código circundante emitió para una petición específica.

Lo que prepara el Capítulo 10

La estructura sin visibilidad falla de forma invisible. El capítulo 11 examina la capa de observabilidad que convierte las defensas arquitectónicas en un sistema que puede operarse — qué registrar cuando un LLM está en el bucle, cómo estructurar la telemetría para servir al alertado en tiempo real, la investigación posterior, la planificación de capacidad, el cumplimiento y la evaluación continua desde los mismos registros. Las convenciones semánticas OpenTelemetry GenAI, que empezaron a estandarizar spans y atributos específicos de LLM en 2024, proporcionan el cimiento neutral al proveedor. Implementaciones específicas — Langfuse, Helicone, Arize Phoenix, Datadog LLM Observability — se sientan encima con distintas contrapartidas. El capítulo 12 maneja después la dimensión de identidad y acceso — OAuth, mTLS, RBAC frente a ABAC, aislamiento multi-tenant, límites de tasa y los controles de gobernanza empresarial que hacen usable el sistema en entornos regulados.

Próximamente — Capítulo 11: Observabilidad, registro y respuesta a incidentes. Qué registrar con las convenciones OpenTelemetry GenAI, cómo detectar patrones de abuso, y cómo ejecutar una respuesta a incidentes con forma NIST para un sistema cuyos fallos son probabilísticos.