Hazle red-team a tu plan antes de que te lo haga la realidad

Todo plan se ve sólido desde adentro. Lo escribiste tú, así que ya te crees las suposiciones, y ahí está el fallo. Las formas de fallar que no ves no tienen nada de exótico; son justo las que dejaste de cuestionar. La simulación adversarial es una manera barata de sacarlas a flote antes de que lo haga la realidad: armas un oponente cuyo único trabajo es hacer fallar tu plan, lo corres a propósito y tratas lo que se rompe como una cola de trabajo. Al terminar esto vas a tener un montaje concreto y repetible, unos cuantos agentes de Claude y tres prompts estrictos, que ha enterrado más malas ideas mías que toda la planificación optimista del mundo.

Esto no es teatro de juegos de guerra. Es una práctica de ingeniería, y como toda práctica tiene su filo y una forma equivocada de empuñarlo. La uso en mis propios roadmaps de NexoString y en decisiones de clientes, y las concesiones honestas pesan tanto como la técnica.

01 · El premortem, pero con un oponente de verdad

El premortem es un truco conocido: imagina que ya pasaron seis meses y el plan fracasó; ahora explica por qué. Funciona porque te saca de defender el plan y te pone a atacarlo. La debilidad es que una persona haciendo un premortem sola sigue siendo demasiado blanda con sus propias ideas. Sacas tres riesgos obvios, sientes que cumpliste y paras. Esos tres que nombras casi nunca son los tres que te van a tumbar.

Un agente no se cansa ni le importan tus sentimientos. Así que le doy el encuadre del futuro fallido y lo obligo a producir dos cosas que a los humanos nos cuesta sacar por nuestra cuenta: volumen y precisión.

const redTeamSystem = `Eres un revisor hostil. El plan de abajo YA falló en
producción. Tu trabajo NO es ser balanceado. Produce 15 causas de fallo
distintas y concretas. Cada una debe nombrar: la suposición equivocada, el
detonante, el primer síntoma observable y quién lo nota primero. Nada de
riesgos genéricos ("se descontroló el alcance", "mala comunicación"). Si un
fallo es barato de provocar, súbele la prioridad.`

const result = await claude.messages.create({
  model: "claude-opus-4-1",
  system: redTeamSystem,
  max_tokens: 4000,
  messages: [{ role: "user", content: planMarkdown }],
})

La restricción de "nombra el primer síntoma observable" es la parte que vale oro. Las listas de riesgos vagas no sirven. Un síntoma, como "el sync nocturno empieza a tardar 40 minutos en vez de 4", te dice exactamente qué alarma montar. El premortem deja de ser una corazonada y se vuelve una especificación de monitoreo que le puedes pasar a quien sea dueño de las alertas.

02 · Dale al atacante una mentalidad real, no una lista de tareas

Un prompt genérico de "encuentra riesgos" produce riesgos genéricos. La calidad da un salto cuando le entregas al agente una postura. Un atacante es flojo, oportunista y se va por el camino más barato hacia tu peor resultado. Ese encuadre cambia lo que sale a flote, porque cambia dónde mira el modelo.

Corro varias personas distintas contra el mismo plan y comparo lo que entrega cada una:

• El empleado flojo. Alguien del equipo que sigue la letra del plan e ignora el espíritu. ¿Qué permite el plan que tú no querías permitir? Esto atrapa los fallos de incentivos: ese punto donde hacer lo fácil y mal es justo lo que te premian.
• El atacante externo paciente. ¿Dónde está el punto blando si alguien tiene semanas y poco presupuesto? Esta es la que más uso para decisiones de seguridad, porque se parece a cómo pasa un compromiso real: despacio, por el camino que nadie vigila.
• El operador con mala suerte. Sin malicia, solo mal timing. El deploy cae justo en un pico de tráfico; la única persona que entendía la migración está de vacaciones; el script de rollback nunca se probó.
• El adversario económico. Un competidor, o simplemente el mercado. ¿Qué le pasa a este plan cuando la suposición "la API sigue gratis" o "el fondo cubre el cómputo" deja de ser cierta?

Cada persona encuentra cosas que las demás no ven. El atacante paciente encontró una falla de diseño real en una versión temprana de Infuse, mi gestor de secretos de API; no en la capa de almacenamiento, que ya había blindado, sino en el flujo de recuperación. Las rutas de reset son más blandas que las rutas principales casi en todos lados, porque probamos el login feliz mil veces y la ruta de "perdí mi dispositivo" dos. El agente no sabía eso como dato; sabía mirar donde el testing no había puesto atención.

Por qué las personas le ganan a un prompt más largo

Podrías meter las cuatro mentalidades en un solo prompt gigante. No lo hagas. Las corridas separadas mantienen disciplinada a cada persona: a un solo agente al que le pides ser cuatro cosas a la vez las promedia hasta volverlas papilla y te entrega cuatro tomas superficiales en lugar de una profunda por cada una. Córrelas como cuatro requests y después compara. Los desacuerdos entre personas son en sí mismos un hallazgo: cuando el empleado flojo y el atacante externo marcan el mismo flujo, ese flujo es tu punto más débil.

03 · El multiagente pone al ataque a atacarse a sí mismo

Un agente listando riesgos es una lluvia de ideas. El valor se multiplica cuando dejas que los agentes discutan entre ellos. Lo armo con tres roles: un proponente que defiende el plan, un red team que lo ataca y un juez que decide si cada ataque de verdad pega o es pura palabrería. Es el mismo patrón de deliberación detrás de ThinkTank AI, mi plataforma de deliberación multiagente, y es precisamente por esto que construí esa herramienta: un solo modelo es demasiado complaciente como para confiarle una decisión.

El juez importa más de lo que uno cree. Sin él, el red team se infla: lista 15 catástrofes y la mitad asume condiciones imposibles. El prompt del juez va al grano: "Para cada ataque, declara la precondición. Si la precondición es improbable o contradice las restricciones que ya declara el plan, márcala como descartada y di por qué". Lo que sobrevive al juez es tu cola de trabajo real, casi siempre de tres a seis ítems, no quince.

Una orquestación a grandes rasgos, del tipo que Agent Orchestra está hecho para conectar de forma visual:

const attacks = await redTeam(plan)
const scored = await Promise.all(
  attacks.map(async (a) => {
    const verdict = await judge(plan, a) // "pega" | "descartado" | "falta-data"
    return { ...a, verdict }
  }),
)
const realWork = scored.filter((s) => s.verdict.label === "pega")
const goMeasure = scored.filter((s) => s.verdict.label === "falta-data")

La categoría de "falta-data" está subvalorada. Son ataques que el juez no pudo descartar pero tampoco confirmar, casi siempre porque en realidad no conoces algún número. Eso es una señal para ir a medir algo antes de comprometerte, no un riesgo que despachas con un gesto de la mano. La mitad de las veces, ir a buscar ese número es lo más valioso que sale de todo el ejercicio.

04 · Convertir los hallazgos en cambios, no en un documento de miedo

El modo de fallo de toda esta práctica es producir un precioso registro de riesgos que nadie atiende. Un hallazgo no vale nada hasta que se convierte en una de tres cosas: un cambio al plan, una alarma que vas a monitorear o un riesgo aceptado de forma explícita y con nombre.

A cada ataque que sobrevive le exijo exactamente una disposición:

1. Mitigar. Cambia el diseño para que el ataque ya no funcione. El mejor resultado, y el que más cuesta ahora.
2. Detectar. No lo puedes prevenir barato, así que conectas el síntoma de la sección 01 a una alerta y dejas la respuesta escrita de antemano, antes de estar agotado y de guardia a las 2am.
3. Aceptar. Es real pero improbable, o barato de recuperar. Anótalo igual, con un nombre al lado. Aceptado-y-con-nombre está bien; aceptado-porque-se-olvidó es la receta para que te agarren por sorpresa.

Si un hallazgo no encaja en ninguna de esas tres, es que todavía no lo entiendes. Devuélveselo al juez señalándole el hueco. Este paso es donde la mayoría de los equipos falla en silencio: el análisis es divertido, la disposición es trabajo aburrido, y el trabajo aburrido es lo que de verdad mueve el riesgo.

05 · Cuándo no hacerlo, y dónde te miente

La simulación adversarial cuesta tiempo y esfuerzo. No montes un red team de tres agentes sobre una decisión reversible y barata: tómala y deshazla si sale mal. La técnica se gana su costo en decisiones caras de revertir o que se acumulan con el tiempo: elecciones de arquitectura, diseños de seguridad, cualquier cosa que toque datos de usuarios, una negociación donde solo tienes una jugada de apertura. Proyección, mi herramienta de práctica de negociación, existe justo porque hay jugadas que no puedes deshacer, así que primero ensayas contra un oponente.

La otra concesión honesta: los agentes alucinan disparates con toda la seguridad del mundo. Un red team que inventa una vulnerabilidad que no existe te quema la tarde y, peor aún, te puede asustar y hacerte abandonar un buen plan. El rol del juez y la restricción de "nombra la precondición" suavizan esto, pero no lo eliminan. El filtro final sigues siendo tú.

Una lista corta para decidir si vale la pena correrlo:

• ¿La decisión es cara o imposible de revertir? Si no, sáltatela.
• ¿Se acumula, equivocarte empeora con el tiempo? Si es así, córrela.
• ¿Tienes un plan escrito para darle a los agentes? Si todavía son puras intuiciones, el red team no tiene de dónde morder.

No vas a predecir todas las formas en que tu plan se va a romper. Sí puedes predecir muchas más de las que te molestas en predecir hoy, y el costo de preguntar bajó a unas cuantas llamadas de API y veinte minutos. Arma el oponente, déjalo ser de verdad hostil, califica lo que encuentre y convierte a los sobrevivientes en cambios, alarmas o riesgos aceptados con nombre. El pesimismo barato de ahora le gana a la sorpresa cara de después. De eso se trata todo.