Un sistema extrae datos de una factura con un agente de IA: dos ítems de $75 y $70, un total declarado de $150. La validación de esquema pasa sin ningún error. El problema es que 75 más 70 es 145, no 150. Nadie lo nota, porque nadie le pidió al sistema que sumara.

En síntesis

  • Un esquema de datos estricto garantiza que la salida tenga la forma correcta: tipos, campos requeridos, estructura. No garantiza que el contenido sea correcto.
  • Errores sintácticos y errores semánticos son categorías distintas, y requieren mecanismos distintos para detectarse.
  • La validación de contenido —lógica de negocio, aritmética, coherencia— tiene que vivir en una capa separada, después de que el formato ya pasó.
  • Es uno de los criterios que evaluamos cuando auditamos sistemas de extracción y generación de datos con IA.

Dos tipos de error, una sola validación

Cuando un sistema le pide a un modelo de IA que devuelva datos estructurados —un objeto con campos definidos, no texto libre— existe una forma confiable de garantizar que la respuesta tenga exactamente esa forma: usar herramientas nativas de salida estructurada más un esquema explícito que define qué campos existen, de qué tipo son, y cuáles son obligatorios. Es el mecanismo correcto, mucho más confiable que pedirle al modelo en un prompt que “devuelva JSON válido” y confiar en que lo haga.

Pero ese esquema resuelve solo un tipo de problema: la forma. Un campo total que efectivamente contiene un número, un campo fecha que efectivamente contiene una fecha. Lo que el esquema no puede evaluar es si ese número es el número correcto dado el resto de los datos. La factura del ejemplo pasa la validación de esquema perfectamente: todos los campos están, todos tienen el tipo correcto. Y aun así, la cifra del total es incorrecta.

Por qué esto sorprende a tanta gente

Es fácil asumir que si el esquema es “estricto”, automáticamente se están evitando errores de contenido. La palabra “estricto” invita a esa lectura. Pero un esquema estricto es estricto sobre la estructura, no sobre la lógica. Eso no es una falla del mecanismo: es exactamente el alcance para el que fue diseñado. El error no está en el esquema, está en esperar que resuelva algo para lo que no fue construido.

La capa que falta: validación semántica

La solución no es intentar forzar reglas aritméticas dentro del esquema de estructura —eso lo vuelve frágil y difícil de mantener. La solución es una segunda capa, después de que el esquema ya validó la forma, que corre reglas de negocio explícitas sobre el contenido: ¿la suma de los ítems coincide con el total declarado? ¿la fecha está dentro de un rango razonable? ¿el campo obligatorio tiene un valor con sentido, no solo un valor presente?

Esta capa suele implementarse con librerías de validación de datos que permiten definir reglas personalizadas más allá del tipo —no solo “esto es un número”, sino “esto es un número que tiene que ser igual a la suma de aquellos otros dos”. Cuando esa validación falla, el sistema tiene una segunda oportunidad: reenviar el documento original, la extracción que falló, y el motivo específico del error, para que el modelo pueda corregir con contexto real de qué salió mal, en vez de intentar adivinar de nuevo desde cero.

Cuándo el reintento deja de tener sentido

No todos los errores de validación se resuelven reintentando. Si el problema es de formato o de una lectura incorrecta de un dato que sí está en el documento fuente, un reintento con el error explicado suele corregirlo. Pero si la información que se busca extraer simplemente no está en el documento —porque nunca existió, o porque el documento está incompleto—, reintentar indefinidamente solo desperdicia tiempo y recursos sin cambiar el resultado. Un buen sistema distingue entre estos dos casos y sabe cuándo detener el loop.

Por qué esto es parte de una auditoría seria

En Arteclaw ayudamos a organizaciones a adoptar arquitecturas agénticas de forma segura. Como parte de ese trabajo, sometemos sistemas —los nuestros y los de las organizaciones que asesoramos— a auditorías periódicas contra un framework propio, informado por los criterios de la certificación oficial de arquitectos de Claude de Anthropic. La confusión entre validación de formato y validación de contenido es uno de los puntos que con más frecuencia aparece en sistemas que procesan documentos: el esquema da una falsa sensación de seguridad completa cuando en realidad solo cubrió la mitad del problema.

La pregunta que conviene hacerse

Si tu sistema extrae o genera datos estructurados con IA, la pregunta no es solo “¿el JSON es válido?”. Es “¿alguien —código, no el modelo— verificó que el contenido tenga sentido?”. Un esquema que pasa no es lo mismo que un dato correcto. Son dos preguntas distintas, y las dos necesitan su propia respuesta.

Inspirado en la serie de BridgeIntoAI sobre la certificación oficial Claude Certified Architect Foundations de Anthropic.