Verificador adversarial: un prompt que le hace red-team a una respuesta antes de que confíes en ella

Un LLM que produce una respuesta y después se pone a revisar su propia respuesta casi siempre termina aprobándose. Vuelve a leer su razonamiento, lo encuentra convincente, claro, lo escribió él, y le da el visto bueno. Los defectos sobreviven porque el mismo modelo que cometió el error es el que lo anda buscando. La solución a la que llegamos en ThinkTank AI es estructural, no de estilo: una segunda pasada premiada por encontrar fallos, que corre en un contexto limpio y que nunca ve el razonamiento que produjo la respuesta. Esta página te entrega ese prompt de verificación, listo para pegar, más cómo conectarlo, las variables que tienes que rellenar, variantes para código y citas, y los modos de fallo que en silencio lo dejan inservible.

01 · Por qué falla la autoverificación (y por qué la independencia la arregla)

Pídele a un modelo que "revise su respuesta dos veces" y casi siempre te da puro teatro. Repite la conclusión, le mete un "sí, esto se ve bien" lleno de seguridad, y sigue de largo. La razón es mecánica: la respuesta y la revisión comparten contexto, así que la revisión arrastra cada suposición, cada paso que se saltó, cada requisito que entendió mal y que la respuesta dejó cocinado adentro. Un punto ciego es, por definición, invisible desde adentro.

La independencia rompe eso. Tienen que cumplirse dos cosas a la vez:

• Incentivo distinto. Al verificador se le califica por los defectos que encuentra, no por estar de acuerdo. Si "esto está bien" es la salida fácil, el modelo va a tirar para ahí. Haz que el resultado vacío sea un veredicto deliberado, con nombre propio, al que tenga que comprometerse.
• Contexto distinto. El verificador recibe la afirmación y el material de soporte, nada más. Quítale el chain-of-thought original. Si lo dejas adentro, el verificador lee el razonamiento, lo encuentra convincente y lo confirma. Acabas de reconstruir el lazo cerrado, pero con pasos de más.

Es el mismo instinto que hay detrás del code review y del testing adversarial: quien escribió algo es la peor persona para encontrarle lo que está mal. No le estás pidiendo al modelo que sea más inteligente. Le estás pidiendo a una instancia limpia que ataque un trabajo en el que no tiene nada que perder.

02 · El prompt del verificador

Aquí tienes el template. Es directo a propósito: parte de que la respuesta está mal hasta que se demuestre lo contrario, trabaja afirmación por afirmación, y cierra con un veredicto sobre el que puedes ramificar en código. Pégalo como system prompt de un subagente verificador, o como primer mensaje de un chat nuevo, seguido nada más por la afirmación y sus fuentes.

Eres un verificador adversarial. Abajo hay una RESPUESTA producida por otro sistema.
Tu trabajo es encontrar por qué está MAL — no confirmarla, no mejorarla.
Asume que contiene al menos un defecto hasta que hayas intentado activamente
romperla y no lo hayas logrado. No encontrar nada es un resultado real, pero hay
que ganárselo, no asumirlo.

Solo puedes usar:
- La RESPUESTA de abajo.
- El MATERIAL DE FUENTE de abajo.
NO puedes usar ningún razonamiento, notas ni chain-of-thought del sistema original.
Si una afirmación no se puede comprobar contra el material de fuente, eso es un hallazgo.

Trabaja en este orden:

1. EXTRAE las afirmaciones clave — los enunciados de los que depende la respuesta.
   Salta lo decorativo. Lístalas como C1, C2, C3...

2. Para cada afirmación, ponla a prueba:
   - ¿Es comprobable contra el MATERIAL DE FUENTE? Si no → márcala SIN SOPORTE.
   - Construye el contraejemplo, el caso límite que falla o la línea de fuente
     que la contradice más fuerte que puedas. Cita el texto exacto en que te apoyas.
   - Di si la afirmación sobrevive al ataque.

3. Revisa el CONJUNTO en busca de defectos que ninguna afirmación suelta muestra:
   una suposición no declarada, un hueco entre dos pasos, una pregunta que la
   respuesta redefinió por lo bajo, un alcance que recortó en silencio.

SALIDA, exactamente con esta estructura:

DEFECTOS (ordenados por impacto, peor primero):
- [Cn | severidad: alta/media/baja] <qué está mal> | <por qué importa> | <la
  evidencia o el contraejemplo>

VEREDICTO: uno de
- SÓLIDO              — de verdad intentaste romperla y no pudiste.
- SÓLIDO-CON-RESERVAS — se sostiene, pero con límites declarados o afirmaciones sin verificar.
- ROTO               — al menos un defecto de severidad alta.

Si el VEREDICTO es SÓLIDO, incluye una línea: "Ataques intentados: <lista>" para
que quien lea vea el trabajo. Sin elogios. Sin repetir la respuesta. Sin sugerencias
de mejora — eso es otro trabajo.

Tres decisiones de diseño cargan con el trabajo pesado:

• "Asume que contiene al menos un defecto" le da vuelta al punto de partida, de aprobar a sospechar. Sin eso, el modelo trata la verificación como una confirmación.
• "No encontrar nada hay que ganárselo" más la línea de "Ataques intentados" evita que el modelo se vaya directo a SÓLIDO. Tiene que mostrar qué intentó.
• El enum fijo de veredicto hace que el resultado sea legible por máquina. Tu harness ramifica sobre tres tokens, no sobre el tono de un párrafo.

03 · Conectarlo a un loop de agentes

En un setup multi-agente, el verificador es un rol aparte con su propio contexto, no un turno más dentro de la conversación del autor. El patrón es así: el autor produce una respuesta, tú extraes la afirmación y las fuentes, levantas una llamada de verificación nueva con solo eso, y ramificas según el veredicto.

Un loop manual mínimo con el SDK de Anthropic. Fíjate que el verificador nunca recibe el historial de mensajes del autor, solo el texto de la afirmación y las fuentes.

import Anthropic from "@anthropic-ai/sdk"

const client = new Anthropic()
const MODEL = "claude-opus-4-8"

async function verify(claim: string, sources: string) {
  const res = await client.messages.create({
    model: MODEL,
    max_tokens: 4000,
    thinking: { type: "adaptive" },
    output_config: { effort: "high" }, // la verificación es sensible a la corrección
    system: VERIFIER_PROMPT, // el template de la sección 02
    messages: [
      {
        role: "user",
        content: `RESPUESTA:\n${claim}\n\nMATERIAL DE FUENTE:\n${sources}`,
      },
    ],
  })
  const text = res.content.find((b) => b.type === "text")?.text ?? ""
  const verdict = /VEREDICTO:\s*(SÓLIDO-CON-RESERVAS|SÓLIDO|ROTO)/.exec(text)?.[1]
  return { verdict, report: text }
}

// Autor → verify → si sale ROTO, devuelve los defectos para un rewrite.

Cuando el veredicto es ROTO, devuélvele al autor solo los defectos, no el transcript completo del verificador, y pídele una reescritura puntual. Después verificas de nuevo. Dos rondas es el punto justo al que seguimos llegando: la primera atrapa los errores obvios, la segunda atrapa lo que metió la reescritura. Pasadas las dos, el loop tiende a dar vueltas, el autor y el verificador se ponen a discutir criterios que ninguno puede zanjar solo con las fuentes, y te conviene más escalar a una persona.

04 · Variables, variantes y cómo adaptarlo

El template tiene unas cuantas piezas móviles que defines según el uso. Si las tienes claras, el prompt se mueve limpio entre dominios.

Las variables que rellenas

• «RESPUESTA»: la afirmación o el artefacto bajo prueba. Una respuesta coherente por corrida; no juntes afirmaciones que no tienen relación, porque el verificador termina dispersando su atención.
• «MATERIAL DE FUENTE»: la verdad de base contra la que la afirmación tiene que poder comprobarse: los documentos recuperados, el spec, las filas del dataset, el contrato de la API. Es contra esto que se mide el "SIN SOPORTE". Si es flojo, el verificador solo puede marcar afirmaciones sin soporte, no afirmaciones equivocadas.
• «barra de severidad»: qué cuenta como alta y qué como baja. El default (alta = cambia la conclusión) sirve para la mayoría; apriétala más en dominios de alto riesgo.

Variantes

Para código. Cambia el paso de extraer afirmaciones por uno de comportamiento: "Extrae las propiedades que este código dice garantizar (maneja input vacío, sin off-by-one, sin fuga de recursos). Para cada una, construye el input que la rompe." El material de fuente pasa a ser los requisitos o el test que falla. El veredicto ramifica igual.

Para citas / RAG. Agrega un paso antes del veredicto: "Para cada afirmación factual, ubica el fragmento exacto de la fuente que la respalda. Si ningún fragmento la respalda, la afirmación es SIN SOPORTE por más plausible que suene." Esto atrapa el fallo más común de RAG, una respuesta fluida que las fuentes en realidad no sostienen.

Para una recomendación de negociación o de decisión (el tipo de cosa que construimos para Proyección y el trabajo de opponent-modeling): replantea los ataques como "encuentra la jugada de la contraparte o el estado del mundo en el que esta recomendación sale peor." Mismo esqueleto, el marco adversarial apuntado a la decisión en vez de a un dato.

05 · Detalles que en silencio convierten al verificador en un adulador

Estas son las formas en que el patrón falla en la práctica. Cada una parece inofensiva y cada una termina reconstruyendo el lazo cerrado.

1. Dejar el chain-of-thought original en el contexto. El error más común, por lejos. El verificador lee el razonamiento del autor, lo encuentra convincente y lo confirma. Quítalo. Pásale la afirmación y las fuentes, nada más.

2. Dejar que "se ve bien" salga barato. Si el prompt no obliga a un "intenté estos ataques en concreto y fallaron", el modelo cae por default en una aprobación llena de seguridad. La línea de "Ataques intentados" no es adorno: es el costo que hace honesto al SÓLIDO.

3. Mismo modelo, cache compartido, contexto que se filtra. Si corres el verificador como otro turno en la misma conversación, el prompt caching y el historial de mensajes le pasan el contexto del autor de todas formas. Usa una llamada aparte, con su propio system prompt y una lista de mensajes limpia. La independencia se trata de los bytes que el modelo de verdad ve, no de tus buenas intenciones.

4. Pedirle que arregle y juzgue a la vez. Un verificador que además reescribe empieza a defender su propio arreglo y a suavizar su propio veredicto. Mantén los trabajos separados: el verificador encuentra defectos, el autor (una pasada distinta) los arregla.

5. Material de fuente flojo. Sin una verdad de base contra la cual comprobar, el verificador solo puede marcar afirmaciones como SIN SOPORTE. No puede decirte que están equivocadas. Si todos tus veredictos salen SÓLIDO-CON-RESERVAS, lo que falta suele ser fuentes, no un verificador más duro.

6. Rondas infinitas. Hacer loop hasta que salga SÓLIDO se siente riguroso, pero en realidad es quemar tokens mientras las dos pasadas negocian. Tópalo en dos y escala.

Córrelo con honestidad y el valor no está en que el modelo se vuelva correcto: está en que dejas de confiar en respuestas que nunca fueron atacadas. El veredicto te da dónde ramificar: despliega en SÓLIDO, pon una compuerta en SÓLIDO-CON-RESERVAS, reescribe en ROTO. Esa única pieza de estructura es lo que convierte el "lo dijo el modelo" en algo sobre lo que de verdad puedes construir.