Reglas que se cumplen siempre van en código, no en el prompt

Un modelo sigue instrucciones muy bien, pero no siempre. Si una regla falla en el 2% de los casos, para un estilo de redacción puede alcanzar. Para una regla legal, de seguridad o de negocio, no alcanza.

La pregunta que hay que hacerse

Leé el requisito y buscá las palabras “siempre”, “nunca” o “sin excepciones”. Si aparecen, la regla tiene que estar garantizada por código (programmatic enforcement). Una indicación en el prompt (prompt-based guidance) guía al modelo, pero no lo obliga.

Dónde va la garantía

• Validación previa obligatoria (prerequisite gate): el código bloquea una herramienta hasta que se completó el paso anterior. Por ejemplo, process_refund no se ejecuta hasta que get_customer devolvió un ID de cliente verificado. Verificar la identidad antes de mover plata no se deja en manos del prompt.
• Interceptar la llamada con un hook (hook): en el Agent SDK, un hook revisa cada llamada a una herramienta antes de que se ejecute y bloquea la que viola la política, por ejemplo un reembolso de más de $500, y deriva el caso a otro flujo, como escalar a una persona. Un hook PostToolUse actúa del otro lado: transforma el resultado antes de que lo lea el modelo, por ejemplo para normalizar fechas que llegan en formatos distintos.
• Validar antes de ejecutar: el manejador de la herramienta (tool handler) revisa los parámetros y rechaza lo que no cumple. Por ejemplo, book_meeting rechaza un horario fuera de 09:00–18:00. El rechazo le vuelve al agente como resultado y puede proponer otro.
• Agregar después del modelo: el texto obligatorio (un disclaimer legal) lo agrega el código antes de enviar.
• Sacar antes del modelo: si un dato sensible nunca llega a Claude, Claude no lo puede mostrar. Prevenir le gana a filtrar.
• Leer de la fuente de verdad: si el informe siempre tiene que listar los huecos, el código los toma del mapa de cobertura y los agrega como sección fija.

Las trampas típicas

Todos estos arreglos siguen siendo probabilísticos, así que no garantizan nada:

• repetir la regla, ponerla primero o escribirla en mayúsculas;
• sumar ejemplos (few-shot examples);
• bajar la temperatura a 0;
• agregar un segundo modelo que revise o reescriba.

En el examen

Si el escenario dice que la regla “falla en 1 de cada 200 casos” y pide “la garantía más fuerte”, descartá todo lo que sea una instrucción al modelo y buscá la opción que lo resuelve en código: un hook, una validación previa obligatoria o el manejador de la herramienta.