Confiar, pero verificar

Los tres módulos anteriores fueron sobre poner la IA a trabajar: proyectos y conectores, investigar y escribir, automatizar. Este es sobre la otra mitad: saber que lo que salió está bien antes de que llegue a un cliente, a un contrato o a una decisión. En el marco 4D esto es el discernimiento, y aquí lo llevamos de "leer con ojo crítico" a un conjunto de controles que diseñas una vez y se repiten cada vez.

¿Por qué la verificación hay que diseñarla y no dejarla a la buena voluntad?

Porque tres cosas que ya viste en el curso se juntan en tu contra. Primera: el modelo responde con la misma seguridad cuando acierta y cuando inventa (módulo 1); el tono no te da ninguna pista, y a nadie le alcanza la atención para dudar de cada frase que suena bien. Segunda: la complacencia (módulo 5): si le preguntas "¿quedó bien?", lo más probable es que te diga que sí, y si le muestras tu opinión antes de pedir la suya, va a coincidir contigo. Tercera: en una automatización (módulo 8) nadie está mirando. Un error que en un chat corriges en dos segundos, en un flujo que corre cada noche se repite cien veces y se mezcla con los aciertos; cuando alguien lo nota, toca revisar todo hacia atrás.

Las buenas intenciones ("yo siempre reviso") fallan porque revisar es aburrido, el borrador casi siempre se ve bien y a la décima vez ya no lees, solo pasas la vista. Por eso la verificación no es un hábito, es una pieza del flujo de trabajo: un paso con nombre, con un responsable y con una pregunta concreta que se responde sí o no. En este módulo construyes tres piezas: una lista de qué revisar según el tipo de salida, un set de pruebas para cada flujo y un punto fijo donde una persona aprueba.

¿Cómo verifico según el tipo de salida?

No todo se revisa igual. Un texto se lee; una cifra se recalcula; una tabla extraída se muestrea. Esta es la lista que usamos, por tipo:

• Hechos (nombres, fechas, artículos de ley, cifras citadas, precios). La única verificación válida es abrir la fuente. Si el modelo usó búsqueda web, abre el enlace y confirma que la página diga eso; si trabajó sobre un documento que le diste, pídele la cita textual y búscala en el original con Ctrl+F. Un dato sin fuente que puedas abrir se trata como no verificado y se quita.
• Números y cálculos (totales, porcentajes, proyecciones). Un modelo de lenguaje predice texto; no calcula. Recalcula tú lo que importe o pídele que use ejecución de código y muestre la operación. Un control barato: pide siempre que el total aparezca junto a sus partes, y comprueba que sumen.
• Documentos largos (resúmenes, contratos revisados, traducciones). Compara contra el original, no contra tu recuerdo del original. Para un resumen: toma tres afirmaciones del resumen y búscalas en el documento, y tres puntos del documento y búscalos en el resumen. Para un contrato o una traducción: lee lado a lado las cláusulas que importan (plazos, montos, obligaciones).
• Textos para clientes (respuestas, cotizaciones, publicaciones). Tres preguntas: ¿el tono es el nuestro?, ¿promete algo que no podemos cumplir (un descuento, una fecha, una excepción)? y ¿contradice una política? La tercera se resuelve poniendo la política en el documento de contexto y pidiendo que marque cualquier frase que se salga de ella.
• Datos extraídos (de facturas, correos o formularios a una tabla). No vas a leer mil filas. Dos controles: reglas de validación que se aplican a todas (subtotal más IVA igual al total, NIT que exista en tu lista de proveedores, fechas dentro del rango, campos obligatorios llenos) y una muestra al azar que una persona compara con el documento original, contando los errores por campo y no por documento. Lo que no pase una regla va a revisión manual. El artículo sobre extraer datos de facturas desarrolla este caso.

Voy a darte dos cosas: una FUENTE y un TEXTO que supuestamente se basa en ella. Tu trabajo es verificar el texto contra la fuente, no contra lo que tú sabes.

Instrucciones:
1. Divide el TEXTO en afirmaciones individuales (una por hecho, cifra, fecha, nombre, promesa o conclusión).
2. Para cada afirmación, busca en la FUENTE la cita textual que la respalda.
3. Clasifica cada una en: RESPALDADA (hay una cita textual que lo dice), NO RESPALDADA (la fuente dice otra cosa o lo contradice) o NO ESTÁ EN LA FUENTE (la fuente no habla de eso).
4. Usa solo la FUENTE. Si algo es cierto según tu conocimiento general pero no está en la fuente, va en NO ESTÁ EN LA FUENTE.

Entrega una tabla con cuatro columnas: afirmación, clasificación, cita textual de la fuente (o "ninguna") y nota breve. Al final, una lista de las afirmaciones que yo debería quitar o corregir antes de usar el texto.

FUENTE:
[PEGA EL DOCUMENTO O EL TEXTO DE LA PÁGINA]

TEXTO:
[PEGA EL BORRADOR]

¿Cómo pruebo un flujo antes de confiar en él?

Todo lo anterior sirve para revisar una salida. Cuando el mismo prompt va a correr cien veces (un clasificador de correos, un extractor de datos, un redactor de respuestas), revisar una salida no te dice nada sobre las otras noventa y nueve. Para eso necesitas probar el flujo, y la forma de hacerlo es la misma que usan los equipos que construyen con IA en serio, solo que en pequeño: un set de pruebas con casos reales y una rúbrica escrita.

1. 1Reúne de 10 a 20 casos reales del pasado con la respuesta correcta ya conocida: diez correos que ya clasificaste, veinte facturas que ya digitaste, quince mensajes de clientes que ya respondiste bien. Incluye los feos: el correo ambiguo, la factura con la foto torcida, el mensaje en dos idiomas. Anthropic recomienda que los casos de prueba reflejen la distribución real del trabajo y que no se olviden los casos límite.
2. 2Escribe la rúbrica: para cada caso, qué tiene que cumplir la salida para contar como correcta. Criterios específicos y medibles, no "que quede bien": "la categoría coincide con la mía", "los seis campos son idénticos al original", "no promete nada que no esté en la política", "tiene menos de 120 palabras". La guía de Anthropic lo resume así: en vez de "buen desempeño", especifica "clasificación precisa".
3. 3Corre los casos con el prompt tal como está hoy y califica cada uno contra la rúbrica. Anota el resultado por criterio, no un "más o menos bien" global.
4. 4Mide: 14 de 20 correctos es un número; "casi siempre acierta" no lo es. Mira dónde falla: si todos los errores están en el mismo campo o en el mismo tipo de caso, ya sabes qué arreglar.
5. 5Arregla una cosa y vuelve a correr. Cambia el prompt, agrega un ejemplo, ajusta el documento de contexto, y repite los 20 casos. Si subió, conserva el cambio; si bajó, deshazlo. Un cambio a la vez, para saber qué fue lo que ayudó.
6. 6Guarda el set y repítelo cada vez que cambies el prompt, el modelo o el contexto. Es tu seguro contra "funcionaba la semana pasada".

Esto, en lenguaje sencillo, son evaluaciones: lo que en el módulo 20 vas a ver con herramientas y en volumen. Anthropic recomienda automatizar la calificación cuando se pueda y prefiere muchos casos calificados automáticamente, aunque la señal sea algo menos fina, a pocos casos calificados a mano. Con 20 casos y una hoja de cálculo ya sabes si puedes confiar, en qué y cuánto.

Tengo un flujo de IA que hace lo siguiente: [QUÉ HACE: por ejemplo, "clasifica los correos de clientes en cotización, soporte, queja y otro", o "extrae NIT, número, fecha, subtotal, IVA y total de remisiones en PDF"]. El prompt actual es:

[PEGA EL PROMPT]

Quiero construir un set de pruebas para medirlo. Ayúdame en tres pasos y no avances al siguiente sin mi respuesta:

Paso 1. Pídeme de 10 a 20 casos reales del pasado con la respuesta correcta ya conocida. Dime qué variedad necesito cubrir (casos típicos, ambiguos, mal formados, raros) para que el set refleje mi trabajo real, y pídeme que te los pegue anonimizados.

Paso 2. Con los casos, escribe una rúbrica: para cada criterio, una frase específica que se responda sí o no (por ejemplo, "la categoría coincide con la mía", "los seis campos son idénticos al documento", "no promete nada que no esté en la política"). Evita criterios como "que quede bien".

Paso 3. Entrégame una tabla con una fila por caso y una columna por criterio, lista para que yo corra el prompt y marque sí o no, con una fila final que cuente aciertos por criterio.

¿Dónde pongo a la persona que revisa?

Que haya una persona en el proceso no significa que alguien mire de vez en cuando. Significa un punto fijo donde el flujo se detiene y espera una aprobación. La regla para ubicarlo: antes de que la acción tenga efecto fuera de tu empresa o sobre tus datos. Un borrador de respuesta espera antes de enviarse; una tabla extraída espera antes de entrar al sistema contable. Si pones el control después (revisar lo ya enviado), no es un control, es una auditoría.

Cuánto revisar cambia con el tiempo:

• Al principio, el 100 %. Las primeras semanas de cualquier flujo revisas todo, y cada error que encuentres entra al set de pruebas como caso nuevo. Eso no es desconfianza: es como se construye el set.
• Después, una muestra. Cuando el set de pruebas da resultados estables y llevas semanas sin encontrar errores en la revisión completa, pasa a revisar una muestra al azar (uno de cada diez, por ejemplo) y sigue mirando el 100 % de lo que caiga en una señal de alerta.
• Nunca por debajo del 100 % en lo que no se puede deshacer: pagos, contratos, respuestas a una queja formal, cualquier cosa que lleve tu firma. Ahí la IA prepara y la persona envía, siempre.

Y hay señales que deben disparar revisión humana sin importar la muestra. Escríbelas en el flujo como reglas, no como criterio de quien revisa:

• Aparece dinero: un monto, un descuento, un reembolso, un plazo de pago.
• Aparece un compromiso: una fecha, una excepción, una promesa de que algo "se soluciona".
• El tono del cliente es de queja, enojo o amenaza legal.
• La salida dice "no sé", "no tengo esa información" o deja un campo vacío. Es la respuesta correcta del modelo y la señal de que una persona tiene que entrar.
• La salida se sale del formato acordado (una columna de más, un texto donde iba un número, un idioma que no era).
• El caso no se parece a ninguno del set de pruebas: proveedor nuevo, tipo de documento nuevo, pregunta que nunca habías visto.
• Involucra datos personales o decisiones sobre personas: contratar, cobrar, negar algo.

¿Sirve que otra IA revise lo que hizo la primera?

Sí, con un límite claro. Pedirle a un segundo modelo, o a un chat nuevo sin el contexto de la conversación, que revise una salida es útil por lo mismo que una segunda persona: no tiene el sesgo de haberla escrito. Encuentra contradicciones, afirmaciones sin respaldo, un cambio de tono, una promesa que no estaba en el brief. Anthropic lo usa en sus propias guías de evaluación y recomienda que el modelo que califica sea distinto del que produjo la salida.

El límite: un revisor de IA compara el texto con lo que él sabe, y lo que él sabe tiene los mismos problemas que lo que sabía el primero. Dos modelos pueden estar de acuerdo en un dato falso. Si el revisor no tiene acceso a la fuente (el documento original, la página, la cifra real), puede decirte que el texto es coherente, no que es cierto. Por eso el reparto es: el segundo modelo revisa forma, consistencia y cumplimiento de las reglas que le diste; la fuente verifica los hechos; la persona aprueba. Un revisor de IA te ahorra tiempo en los dos primeros pasos y nunca reemplaza el tercero.

Actúa como un revisor escéptico. Tu trabajo es encontrar problemas en el texto de abajo, no mejorarlo ni elogiarlo. Asume que lo escribió alguien competente pero apurado, y que una persona va a responder por él frente a un cliente.

Contexto: el texto es [QUÉ ES: una respuesta a un cliente, una cotización, un resumen de contrato, un artículo] y va dirigido a [QUIÉN]. Las reglas que debe cumplir son: [PEGA LA POLÍTICA, EL BRIEF O LAS REGLAS].

Revisa en este orden y reporta solo lo que encuentres:
1. Afirmaciones de hecho sin respaldo en el material que te di (lista cada una).
2. Promesas, fechas, montos o excepciones que las reglas no autorizan.
3. Contradicciones internas o con las reglas.
4. Tono: frases que no sonarían como nosotros.
5. Lo que falta: algo que el lector esperaría y no está.

No corrijas el texto. Para cada problema, cita la frase exacta y di por qué es un problema. Si no encuentras nada en una categoría, dilo en una línea. Termina con tu recomendación en una palabra: ENVIAR, CORREGIR o NO ENVIAR.

TEXTO:
[PEGA EL BORRADOR]

El módulo 10, "Llevar la IA a tu equipo", cierra la parte 2: políticas de uso, capacitación, qué medir y cómo pasar de cada uno con su ChatGPT a un método compartido. Lo que construiste aquí es justo lo que ese método necesita para que la confianza no dependa de quién revisa ese día.