¿Podemos confiar realmente en un agente LLM con una terminal bash y una tarjeta de crédito corporativa? Sí, pero solo si dejamos de tratar el system prompt como un contrato legalmente vinculante.
El estado actual de la “seguridad de la IA” es en gran medida una broma. Le decimos a un agente que “sea útil e inofensivo”, y luego actuamos sorprendidos cuando elimina un bucket de S3 de producción porque pensó que estaba realizando una tarea de “limpieza”. El problema es que los system prompts son solo sugerencias; son pesos probabilísticos, no restricciones estrictas. Puedes pasar cien horas perfeccionando el prompt perfecto para evitar que un agente acceda a un directorio específico, y el modelo seguirá encontrando la manera de alucinar una ruta alternativa o simplemente ignorará la instrucción cuando la ventana de contexto se sature. Básicamente, estamos intentando asegurar un data center poniendo un cartel de “Por favor, no entre” en la puerta principal.
El artículo sobre Políticas Deónticas argumenta que necesitamos una capa en tiempo de ejecución que no le importe la “intención” del agente ni su “razonamiento”, sino que se centre exclusivamente en la acción real. Es la diferencia entre pedirle a un adolescente que tenga cuidado con el coche de la familia e instalar un limitador mecánico que tope la velocidad a 55 mph. Uno es una petición de buen comportamiento; el otro es una imposibilidad física de fallar. Al utilizar la lógica deóntica —el estudio formal de lo que está permitido y obligado—, este marco crea un guardián formal que se sitúa entre el LLM y las herramientas que invoca. Si el modelo intenta ejecutar un rm -rf / en una ruta restringida, la capa de gobernanza mata el proceso antes de que el comando llegue a la shell.
Por supuesto, esto no es un almuerzo gratis. (Sospecho que la sobrecarga operativa será una pesadilla). Si cada llamada a una herramienta tiene que pasar por un verificador de lógica, estamos introduciendo latencia que hará que los agentes “en tiempo real” parezcan estar pensando a través de una pajita. Hay una fricción real aquí: cada milisegundo gastado en el proxy de gobernanza es un milisegundo que el usuario pasa mirando un cursor parpadeante. Es esencialmente añadir un oficial de cumplimiento corporativo al bucle que debe aprobar cada informe de gastos antes de que se pase la tarjeta. Si el motor de lógica es lento, todo el flujo de trabajo del agente se colapsa en una serie de pausas entrecortadas.
La verdadera fricción, sin embargo, será la definición de políticas. ¿Quién escribe realmente estas reglas deónticas? Si las reglas son demasiado estrictas, el agente se convierte en un pesapapeles de lujo; si son demasiado laxas, vuelves exactamente al punto de partida. Ya hemos visto esta película antes con los primeros sistemas RBAC en infraestructura en la nube: todos terminaron simplemente dándole el rol de administrador a la cuenta de servicio porque no lograron descifrar los permisos granulares. A pesar de esto, la demanda de “hard” guardrails está alcanzando su punto máximo. Para el Q4, veremos emerger el primer “proxy de gobernanza” de grado empresarial como un producto SaaS independiente, probablemente comercializado como un AI Firewall.
Movernos hacia una gobernanza formal en tiempo de ejecución es la única salida del desastre actual. El prompt engineering para seguridad es un juego de matarratas que estamos perdiendo. Necesitamos un disyuntor codificado que viva fuera de los pesos del LLM y que no sufra la misma deriva probabilística que el modelo en sí. Si la capa de gobernanza está desacoplada del modelo, podemos auditar realmente por qué se bloqueó una solicitud sin preguntarnos si el agente simplemente alucinó con sus propias reglas. Dejamos de pedirle al modelo que se policié a sí mismo y en su lugar construimos una jaula que realmente aguanta.
La lógica formal es una solución aburrida, pero es la única que realmente funciona.
