El problema
Una canalización de datos procesa información financiera de contratos legales y devuelve un JSON perfectamente estructurado: claves exactas, tipos de datos correctos y validación de esquema sin ningún fallo. El equipo despliega el flujo en producción porque "la salida valida". Tres semanas después descubren que el campo valor_total estaba sistemáticamente equivocado en contratos que incluían cláusulas de ajuste — el JSON siempre fue válido a nivel de sintaxis, pero el número extraído era erróneo desde el primer día.
La canalización validó la forma de la respuesta, pero nunca validó su contenido. Son dos tipos de fallos totalmente independientes, y confundirlos es el error más costoso de esta lección.
La corrección del formato no equivale a la exactitud del contenido
Existen dos tipos de fallo completamente independientes:
- Fallo de forma: la salida no cumple el esquema esperado — falta un campo, el tipo de dato es incorrecto o la estructura JSON está truncada. Esto es detectable de manera automatizada mediante un validador de esquemas, sin requerir conocimiento del dominio de negocio.
- Fallo de contenido: la salida cumple el esquema a la perfección, pero la información que contiene es errónea, incompleta o inventada. Detectar esto exige verificación del dominio — ningún validador de esquemas genérico identificará un valor numérico verosímil pero incorrecto.
Una canalización que solo valida esquemas es ciega ante los fallos de contenido, que suelen ser los más caros porque pasan desapercibidos bajo la apariencia de que la salida "se ve correcta".
Cuándo un resultado exige revisión humana
No toda salida requiere revisión humana antes de utilizarse — imponerla universalmente destruye la viabilidad económica de la automatización. La pregunta arquitectónica adecuada no es "¿puede esto fallar?" (casi todo puede), sino: ¿el error, de ocurrir, es lo bastante costoso y la evidencia de que está bien es lo bastante débil como para justificar una revisión manual?
Dos factores determinan esta decisión:
- Costo del error: una sugerencia de borrador revisada posteriormente por un editor humano tiene un costo de error bajo. Una afirmación factual publicada directamente a clientes como verdad verificada, o una acción irreversible ejecutada de forma autónoma, tiene un costo de error alto.
- Fuerza de la evidencia: una extracción de un valor que aparece textualmente (verbatim) en el documento fuente cuenta con evidencia sólida. Una inferencia sintetizada a partir de distintas cláusulas del documento tiene evidencia más débil, aunque la redacción suene convincente.
Un alto costo de error combinado con evidencia débil es el caso indiscutible que exige revisión humana antes de continuar. Un bajo costo de error con evidencia sólida puede ejecutarse directamente. El antipatrón recurrente es decidir en función de "lo convincente que suena el texto" — los modelos pueden redactar alucinaciones con el mismo tono de seguridad que un hecho comprobado. La confianza percibida en la prosa no constituye evidencia de exactitud.
Registrar errores para preservar la causa raíz
Cuando una salida se marca como errónea — ya sea por revisión humana o por pruebas automatizadas —, lo que queda registrado en la bitácora importa tanto como haber detectado el error. Un log que solo indica "esta respuesta fue incorrecta" resulta inútil meses después: se pierde el contexto y el mismo fallo arquitectónico vuelve a repetirse.
Un registro de error útil guarda como mínimo:
- La restricción específica violada (no solo "estaba mal", sino "omitió la cláusula de ajuste por inflación").
- Qué hizo que la alternativa incorrecta pareciera plausible al modelo.
- La regla, prueba o salvaguarda determinista que evitará la repetición del error en el futuro.
Este tercer elemento es el que convierte el registro de errores en una mejora estructural del sistema, en lugar de una pila de incidencias que nunca genera aprendizaje real.
Dónde falla la intuición
- "Si el JSON validó contra el esquema, la extracción es correcta." Confunde estructura con contenido — pasar la validación sintáctica no garantiza la veracidad de los datos.
- "Una respuesta que suena segura probablemente es correcta." La fluidez del texto es un producto probabilístico, no evidencia factual; la fuerza de la evidencia proviene del anclaje en la fuente, no de la soltura gramatical.
- "Revisión humana para todo es siempre la opción más segura." Ignora el costo operativo de revisar todo — la postura correcta calibra la revisión en proporción al costo del error y a la fuerza de la evidencia.
Ponlo en práctica
En el laboratorio de esta lección implementarás un validador de dos niveles — uno que comprueba la forma (esquema) y otro que evalúa señales de contenido (evidencia en la fuente) — junto con una función de enrutamiento que decide, a partir del costo del error y la solidez de la evidencia, si una salida puede avanzar automáticamente o requiere revisión humana.