Por qué 'nunca uses la terminal' en un prompt no alcanza

Imaginá un agente de IA con acceso técnico a ejecutar comandos en un servidor. La única regla que le impide borrar archivos, correr scripts o tocar credenciales es una línea en su system prompt: “nunca uses la terminal, solo lee y edita archivos”. El agente la respeta el 98% de las veces. El otro 2%, no.

Ese 2% es el problema de este artículo.

En síntesis

• Una instrucción de prompt es probabilística: el modelo la sigue casi siempre, no siempre.
• Cuando la consecuencia de un desvío es financiera, de seguridad o irreversible, “casi siempre” no alcanza.
• La alternativa es el enforcement programático: hacer que la acción no deseada sea estructuralmente imposible, no solo desaconsejada.
• Es exactamente el criterio que evalúa la certificación oficial de arquitectura de agentes de Anthropic, y el que aplicamos cuando auditamos sistemas agénticos propios y de terceros.

El prompt no es un contrato

Un modelo de lenguaje no “cumple” una instrucción de prompt de la misma forma que un programa ejecuta una línea de código. La sigue con muy alta probabilidad, pero probabilidad no es garantía. Cuanto más largo el contexto, más ambigua la situación, o más presión tenga el modelo para resolver una tarea, mayor la chance de que se salte una regla de prosa que nunca debió depender de su buena voluntad.

Esto no es un defecto raro. Es una propiedad estructural de cómo funcionan estos sistemas. Y se vuelve peligroso apenas la instrucción que puede fallar protege algo con costo real: dinero, datos de terceros, o una acción que no se puede deshacer.

Instrucción vs. gate: la diferencia que importa

Pensemos en un caso típico de agente de atención al cliente. Antes de procesar un reembolso, el agente tiene que verificar la identidad del cliente. La forma más común de resolver esto es agregarlo al prompt: “siempre verificá la identidad antes de procesar un reembolso”.

Funciona casi siempre. El problema es ese “casi”: en la práctica, un porcentaje bajo pero real de los casos termina en reembolsos procesados sobre la cuenta equivocada, porque el modelo saltó el paso de verificación.

La alternativa no es escribir la regla con más énfasis. Es sacarla del prompt y ponerla en el código: una precondición que bloquea la acción de reembolso hasta que la herramienta de verificación de identidad devolvió un resultado válido. El siguiente pseudocódigo ilustra la idea — no es la API literal de ningún SDK, es el concepto:

def before_tool_call(tool_name, context):
    if tool_name == "process_refund" and not context.get("verified_customer_id"):
        return block("Falta verificación de identidad")
    return allow()

La diferencia no es de estilo. Un gate como este es determinístico: cero fallos posibles, porque la acción protegida ni siquiera se ejecuta si falta la condición. Una instrucción de prompt, en cambio, sigue siendo una sugerencia con una tasa de error mayor a cero, sin importar cuántas veces se repita o con qué énfasis se escriba.

La regla práctica es simple: si la consecuencia de un desvío es financiera, de seguridad, o irreversible, la respuesta es un gate programático. Si es una preferencia de estilo o una guía, una instrucción de prompt alcanza.

Por qué esto pesa más en sistemas multi-tenant

El ejemplo del reembolso es útil porque es simple, pero el riesgo real crece con la superficie del sistema. Un backend legaltech multi-tenant —donde un mismo servicio atiende a varios estudios o clientes distintos, cada uno con sus propias credenciales y datos— multiplica el costo de cualquier desvío: no es solo un reembolso mal procesado, es información de un cliente filtrándose hacia otro, o una acción ejecutada con las credenciales equivocadas.

En ese contexto, la pregunta que hay que hacerle a cualquier proveedor de IA agéntica no es “¿tu agente sabe que no debe hacer X?”. Es “¿es técnicamente posible que tu agente haga X, aunque lo sepa?”. Si la respuesta es sí, hay una brecha entre lo que el sistema promete y lo que el sistema garantiza.

En Arteclaw ayudamos a organizaciones a adoptar arquitecturas agénticas de forma segura. Como parte de ese trabajo, sometemos sistemas —los nuestros y los de las organizaciones que asesoramos— a auditorías periódicas contra un framework propio de buenas prácticas de arquitectura de agentes, informado por los criterios de la certificación oficial de arquitectos de Claude que ofrece Anthropic. En nuestras auditorías, el criterio que más se repite es exactamente este: enforcement programático donde hay plata, seguridad o datos de terceros de por medio, no una instrucción que el modelo puede, eventualmente, no seguir.

La pregunta que conviene hacerse

Si estás evaluando o construyendo un sistema con agentes de IA, hay una pregunta que separa una arquitectura sólida de una que solo parece sólida: para cada regla crítica del sistema, ¿qué pasa si el modelo la ignora una sola vez? Si la respuesta es “nada grave”, una instrucción de prompt puede alcanzar. Si la respuesta involucra dinero, datos ajenos, o algo que no se puede deshacer, la regla tiene que vivir en el código, no en la prosa.

Inspirado en la serie de BridgeIntoAI sobre la certificación oficial Claude Certified Architect Foundations de Anthropic.