Haz concretos los riesgos: radio de impacto, reversibilidad, costo de tiempo
"Podría causar problemas" no es una evaluación de riesgo.
Cuando tu agente plantea una decisión y describe los riesgos como "esto podría causar problemas" o "ten cuidado aquí", no te dio nada con qué actuar. Los riesgos vagos son la forma que tiene el modelo de gesticular hacia el peligro sin hacer el trabajo de medirlo. No puedes sopesar una decisión contra una advertencia que le calza a cualquier decisión. La razón por la que le pediste al agente que marcara el riesgo era para distinguir uno grande de uno pequeño — y una línea de riesgo difusa borra justo esa distinción.
Por qué los riesgos vagos no sirven
El riesgo solo ayuda a elegir cuando es comparable. "Podría causar problemas" le calza igual a corregir un typo y a borrar una tabla de producción, así que no puede jerarquizar nada. Para decidir, necesitas saber cuánto está en juego y qué tan recuperable es el resultado. Una decisión trivialmente reversible merece un sí rápido; una que toca estado de producción irreversible merece una pausa, una revisión, quizás un humano. La cautela indiferenciada colapsa ambas en el mismo encogimiento de hombros.
La solución: tres dimensiones concretas
Exige que todo riesgo planteado nombre tres cosas:
- Radio de impacto (blast radius) — qué toca en realidad. ¿Una función? ¿Un servicio? ¿Cada registro de usuario? ¿La base de datos de producción compartida?
- Reversibilidad — ¿se puede deshacer, y qué tan difícil? Un commit revertible es un animal distinto de una migración de esquema corrida contra datos en vivo.
- Costo de tiempo — cuánto toma recuperarse si sale mal. ¿Minutos para revertir, o días para reconstruir y reconciliar?
Ponlo directo en las instrucciones del agente:
When you surface a decision, state the stakes concretely. For each option:
- BLAST RADIUS: exactly what it touches (files, services, data, users)
- REVERSIBLE?: yes/no + how you'd undo it
- TIME COST: realistic recovery time if it goes wrong
Never write "could cause issues." Name the specific consequence.
Vago frente a concreto, lado a lado:
| Vago | Concreto |
|---|---|
| "Esto podría causar problemas." | "Toca la tabla users; la migración es irreversible sobre datos en vivo; una corrida mala son ~2 días de reconciliar desde backups." |
| "Ten cuidado con este cambio." | "Acotado a una función auxiliar; totalmente reversible con git revert; la recuperación es menos de un minuto." |
Ahora sí puedes elegir. Un camino es reversible y local; otro toca una migración de producción que no puedes deshacer. La misma superficie de decisión, una llamada completamente distinta — y ahora la diferencia es visible.
Movidas avanzadas
- Jerarquiza por irreversibilidad, no por esfuerzo. El cuadrante más temible es radio de impacto alto más baja reversibilidad. Deriva esos a un control de revisión humana automáticamente.
- Pide el plan de recuperación, no solo el riesgo. "¿Cómo deshacerías esto?" obliga al modelo a demostrar la reversibilidad en vez de afirmarla.
- Reutiliza el vocabulario en toda la organización. Radio de impacto / reversibilidad / costo de tiempo es el mismo lenguaje que ya usan las buenas prácticas de incidentes y gestión de cambios, así que la salida del agente encaja directo en tu proceso de revisión.
- Que sea un control, no una nota al pie. Para un agente autónomo, "irreversible + radio de impacto amplio" debería detenerse y preguntar, igual que las decisiones de puerta de un solo sentido se escalan en vez de resolverse por defecto.
Recursos
- Two-way and one-way door decisions — Amazon shareholder letter (2015)
- Google SRE Book — Postmortem culture and change management
- Anthropic — Prompt engineering overview
- OpenAI — Prompt engineering guide
¿Desarrollas sistemas de IA o en la nube? Yeda AI audita y refuerza pipelines de LLM y contenedores en producción. Hablemos · Lee el blog