Las instrucciones del prompt no son una capa de aplicación para agentes de empresa

¿Qué es esto?

El 9 de julio de 2026 se publicó en arXiv un preprint titulado “From Prompts to Contracts: Harness Engineering for Auditable Enterprise LLM Agents” (2607.08028). Plantea una pregunta que subyace a la mayoría de los despliegues de agentes en la empresa: cuando una aplicación LLM empieza como un prototipo guiado por prompt y luego debe pasar a producción con requisitos reales —límites de fuentes, enrutamiento de entidades, contratos de respuesta, trazas reproducibles—, ¿cuáles de esas garantías pueden hacerse cumplir realmente escribiéndolas en el prompt y cuáles deben aplicarse mediante código alrededor del modelo?

La respuesta del artículo es contundente. Las garantías que solo viven en las instrucciones del prompt se filtran: las violaciones llegan al lector. Las mismas garantías, trasladadas a una capa de aplicación en código alrededor del modelo, se sostienen. Es un hallazgo de arquitectura, no un exploit, pero tiene consecuencias de seguridad directas para cualquier equipo que dependa de los prompts de sistema para mantener a un agente dentro de los límites.

Cómo funciona

Los autores describen un arnés: el comportamiento determinista se extrae del prompt y se traslada al código —manifiestos, esquemas y artefactos de validación— organizado en torno a una frontera de composición, el punto reemplazable donde el LLM compone realmente una respuesta. Las afirmaciones respaldadas por fuentes siguen siendo la autoridad para las respuestas en ejecución, pero las reglas sobre cómo puede formarse una respuesta (anclaje, enrutamiento, formato, lenguaje permitido) se convierten en contratos verificables por máquina en lugar de peticiones corteses dentro de un prompt.

Instancian este enfoque sobre un conjunto de datos públicos de cinco grupos (25 empresas cotizadas) y prueban cinco contratos: anclaje a fuentes, enrutamiento de entidades, traza, higiene de salida y lenguaje de recomendación. Un control por inyección de fallos rompe deliberadamente cada contrato para confirmar que los validadores se activan, en lugar de dejar pasar todo por defecto.

El experimento central fija el modelo y varía únicamente la capa de aplicación:

Capa de aplicación        Contrato fuga-de-traza / lenguaje-de-recomendación
------------------------  ------------------------------------------------
Solo instrucciones de     Las violaciones llegan al lector
prompt
Guardarraíl externo       Bloquea las violaciones, pero sobre-rechaza (utilidad 88/120)
Arnés en código           Bloquea las violaciones, utilidad completa (120/120)

No se necesita ningún payload de ataque para establecer el punto, y aquí no se reproduce ninguno. El hallazgo trata de dónde vive un control, no de una cadena ingeniosa.

Por qué importa

Dos cifras sostienen el artículo. Primero, con el modelo fijo, solo las instrucciones del prompt dejan que las violaciones de lenguaje de recomendación y de fuga de traza interna lleguen al lector, mientras que el arnés en código las bloquea por completo. Para un agente de empresa, una fuga de traza interna puede exponer razonamientos, contexto recuperado o detalles del sistema que un usuario nunca debió ver, y un fraseo de «recomendación» prohibido puede ser un problema real de cumplimiento en entornos regulados. Ninguno se corrige añadiendo más texto al prompt.

Segundo, los contratos se mantuvieron bajo la sustitución de modelo: en tres modelos alojados, las verificaciones del arnés pasaron en las 270 ejecuciones en la frontera de composición, y cuando el lado compuesto por el modelo fallaba, los fallos se detectaban y registraban en lugar de entregarse en silencio. Esa robustez importa porque los equipos cambian de modelo base constantemente, y una garantía que depende encubiertamente del comportamiento de un modelo no es una garantía.

El resultado de sobre-rechazo es el contrapeso honesto. Un guardarraíl externo añadido también bloqueó las violaciones, pero hizo caer la utilidad a 88/120 allí donde el arnés conservaba los 120/120 completos: el impuesto familiar de un filtro demasiado amplio que rechaza en exceso. Solo una aplicación en código y acotada preservó a la vez la seguridad y la utilidad.

Esto encaja con una lección que el sector reaprende una y otra vez. El equipo de seguridad de Microsoft, en mayo de 2026, lo dijo con claridad: un LLM no es una frontera de seguridad, y cualquier parámetro de herramienta que el modelo pueda influir debe tratarse como entrada controlada por el atacante. La literatura sobre patrones de diseño para proteger a los agentes frente a la inyección de prompts hace el mismo razonamiento estructural: colocar controles deterministas alrededor del modelo, no pedirle al modelo que se vigile a sí mismo.

Defensas

Puntos concretos para los equipos que despliegan agentes LLM en la empresa:

1. Trate los prompts como modelado de comportamiento, no como aplicación. Toda garantía que deba cumplirse —anclaje a fuentes, ausencia de fuga de traza interna, formato de salida, lenguaje permitido— pertenece al código: esquemas y validadores en la frontera de composición, no frases en un prompt de sistema.

2. Coloque una frontera validada entre la salida del modelo y el usuario. Verifique cada respuesta compuesta por el modelo contra contratos verificables por máquina antes de su difusión, y falle en posición cerrada ante una violación.

3. Haga que la aplicación sea independiente del modelo. Si cambiar el modelo base altera el cumplimiento de un contrato, el contrato no está realmente aplicado. Vuelva a ejecutar sus verificaciones de contrato en cada sustitución de modelo.

4. Prefiera verificaciones en código y acotadas frente a guardarraíles externos amplios. Los filtros externos compran seguridad a costa de sobre-rechazo. Los validadores específicos de un contrato preservan la utilidad y siguen bloqueando la violación.

5. Versione y archive sus artefactos de control. Manifiestos, esquemas, validadores y trazas deben versionarse como código para que una auditoría pueda reconstruir exactamente por qué se permitió que una respuesta llegara a un lector.

6. Añada pruebas por inyección de fallos. Rompa deliberadamente cada contrato en una prueba y confirme que el validador lo señala. Un guardarraíl que nunca vio fallar es un guardarraíl en el que no puede confiar.

Estado

Elemento	Referencia	Fecha	Notas
Preprint de ingeniería de arnés	arXiv:2607.08028	2026-07-09	Contratos en código vs aplicación solo por prompt
Prueba de sustitución de modelo	Artículo	2026-07-09	270/270 ejecuciones en la frontera de composición superadas, 3 modelos alojados
Aplicación solo por prompt	Artículo	2026-07-09	Fuga de traza y lenguaje de recomendación llegan al lector
Arnés vs guardarraíl externo	Artículo	2026-07-09	Arnés utilidad completa (120/120); guardarraíl añadido sobre-rechaza (88/120)
Contexto de la industria	Microsoft Security	2026-05-07	«Su LLM no es una frontera de seguridad»

Se trata de un único estudio de caso sobre un conjunto de datos financieros públicos, con una implementación de referencia y artefactos de evaluación archivados por los autores; queda pendiente una réplica independiente más amplia. Pero la dirección merece interiorizarse desde ya: a medida que los agentes se adentran en los flujos de trabajo regulados de la empresa, las garantías que sobreviven son las que puede señalar en el código, no las que le pidió al modelo que recordara.