Salidas estructuradas con IA: cómo validar datos antes de guardarlos o actuar

El formato procesable no garantiza un dato correcto

Una salida estructurada es una respuesta de un modelo organizada para que una aplicación pueda interpretarla de manera previsible: por ejemplo, un objeto JSON con campos y tipos definidos. Puede servir para extraer datos de documentos, clasificar solicitudes o preparar información para otro componente. Su ventaja principal es que reduce la ambigüedad del formato; no convierte, por sí sola, el contenido generado en un hecho comprobado.

Conviene separar cuatro preguntas. ¿Se puede analizar la respuesta como JSON? ¿Tiene los campos y tipos acordados? ¿Sus valores concuerdan entre sí y con la información de origen? ¿Está permitido usarla para el propósito previsto? Una respuesta puede superar las primeras comprobaciones y fallar en cualquiera de las siguientes. Que un objeto incluya una fecha con el formato esperado no demuestra que esa fecha aparezca en el documento; que incluya una categoría válida no demuestra que la clasificación sea correcta.

Esta distinción también ayuda a elegir el mecanismo de salida. Un modo JSON o una generación restringida por esquema se orientan a producir una respuesta final con una forma determinada. Una llamada a herramientas, en cambio, presenta argumentos para que la aplicación decida si ejecuta una operación. Los argumentos bien formados no autorizan automáticamente esa operación: la ejecución sigue bajo control del sistema que integra el modelo.

El foco de esta guía es el contrato de datos que se comprueba en cada ejecución. No sustituye la gestión de cambios de modelos, SDK o herramientas, que requiere controlar compatibilidad entre versiones. Aunque no haya cambiado la API, una entrada ambigua, un documento incompleto o una interpretación equivocada pueden producir un resultado que no debe guardarse como confirmado.

Define el contrato antes de escribir el prompt

Empieza por el uso que recibirá la respuesta, no por una lista de campos que parezca cómoda para el modelo. Si otro sistema debe guardar el resultado, especifica qué representa cada campo, qué tipo tiene y qué hará la aplicación con él. Un contrato útil reduce interpretaciones distintas entre quien genera la respuesta y quien la consume.

Para cada campo, decide si es obligatorio, opcional o puede ser nulo. No uses una cadena vacía, un valor ficticio o una cifra cero como sustituto universal de «desconocido»: esos valores pueden confundirse con información real. Define también las unidades —por ejemplo, si un importe está expresado en una moneda concreta—, los formatos de fecha, los límites aceptables y las enumeraciones permitidas. Si hay categorías, indica qué significa cada una y qué hacer cuando ninguna encaja.

Las reglas de negocio suelen ir más allá de los tipos. Un esquema puede permitir que dos importes sean números, pero la aplicación puede exigir que el total coincida con la suma de las líneas dentro de una tolerancia definida. Puede aceptar que una confianza sea un número, sin que eso establezca un umbral apropiado para confirmar un dato. Mantén esas reglas explícitas y fuera de la suposición de que el modelo las aplicará siempre.

El estándar JSON Schema permite describir estructuras y restricciones, pero cada canal de un proveedor puede admitir solo un subconjunto de sus capacidades. Antes de depender de una palabra clave concreta, verifica la documentación vigente del modelo y del modo de salida elegido. Cuando una restricción no esté disponible en ese canal, compruébala en la aplicación; no la elimines silenciosamente ni des por hecho que el modelo la respetará por la instrucción del prompt.

Elige el canal según el resultado que necesitas

La salida estructurada final es apropiada cuando la aplicación necesita recibir datos organizados como respuesta. El modo JSON puede orientar la forma general; la generación restringida por esquema puede imponer restricciones adicionales si el proveedor, el modelo y el canal las admiten. No son garantías universales de veracidad y tampoco eliminan la necesidad de validar la respuesta recibida.

La llamada a herramientas sirve para proponer argumentos destinados a una función que la aplicación conoce. El ciclo no termina al recibir esos argumentos: el sistema los inspecciona, decide si puede ejecutarlos y, si corresponde, realiza la operación. Conviene mantener esa separación visible en el diseño. Un campo como «enviar_pago» no debería ser una instrucción que se ejecute solo porque el modelo lo produjo.

Antes de poner una integración en producción, comprueba cómo representa el canal los resultados normales, las respuestas incompletas y los rechazos. Esos estados no deben tratarse como objetos válidos solo porque aparezcan durante una transmisión o puedan convertirse parcialmente en texto. En respuestas transmitidas por partes, espera a disponer de un resultado final identificable antes de tomar una decisión de negocio.

Si una restricción del esquema no es compatible, adopta una alternativa explícita: validar esa restricción localmente, simplificar el contrato sin perder el control esencial o cambiar a un canal compatible. Registra la diferencia. Un contrato que parece estricto en el prompt, pero que el canal no aplica, puede dar una falsa sensación de seguridad.

Valida en capas, no con una sola comprobación

La primera capa es el estado de la respuesta: determina si se recibió una respuesta final procesable o si el proveedor indicó rechazo, interrupción o incompletitud. Si el resultado está truncado o no ha terminado, no lo conviertas en una aceptación parcial salvo que tu producto haya definido y probado expresamente ese comportamiento.

La segunda capa es el parseo y la estructura. Comprueba que el texto pueda interpretarse en el formato esperado, que la raíz tenga el tipo acordado y que los campos, tipos, valores permitidos y restricciones aplicables sean válidos. No omitas el manejo de errores de parseo ni conviertas automáticamente valores con una coerción ambigua, como texto a número, sin una regla documentada.

La tercera capa examina el significado y las relaciones entre campos. Verifica rangos, consistencia, combinaciones incompatibles y condiciones de negocio. La cuarta contrasta la propuesta con la entrada original: una factura, un ticket o una solicitud. Cuando sea posible, confirma los datos relevantes en el documento o en un registro autorizado. La quinta decide si el uso está permitido: mostrar una sugerencia no tiene el mismo efecto que cambiar una cuenta o ejecutar una operación externa.

Mantén separado el valor propuesto del valor confirmado. Si un campo necesita revisión, la interfaz y el almacenamiento deben poder representarlo como pendiente o no verificado. Sobrescribir la evidencia original con una extracción dudosa hace más difícil corregir el error y reconstruir por qué se tomó una decisión.

Tres recorridos prácticos

Los ejemplos siguientes muestran cómo un mismo diseño distingue la forma de la respuesta de su aceptación. Los campos son ilustrativos: una implementación real debe ajustarlos a sus documentos, reglas contables, taxonomía y controles de acceso.

blocks

Responde a los fallos de forma controlada

No todos los fallos requieren la misma respuesta. Un error de formato puede permitir una nueva generación con una instrucción más acotada. Una respuesta incompleta puede requerir volver a solicitarla o detener el proceso. Una contradicción con la fuente puede necesitar revisión humana. Una falta de autorización debe bloquear la acción, no provocar un reintento orientado a obtener una respuesta más conveniente.

Define de antemano cuándo se acepta, cuándo se reintenta, cuándo se pone en cuarentena y cuándo se rechaza. Limita los reintentos y guarda el resultado fallido para poder entender qué ocurrió. Si el sistema reintenta, no acumules respuestas incompatibles ni selecciones simplemente la que parezca más completa. El nuevo intento debe tener un propósito concreto —por ejemplo, corregir un campo ausente— y volver a pasar por las mismas validaciones.

Evita las correcciones silenciosas que pueden transformar un fallo visible en un dato aparentemente fiable. Normalizar espacios o una representación inequívoca puede ser seguro si está documentado; inventar un campo ausente, elegir entre dos importes contradictorios o ajustar una categoría para que pase una regla no lo es. Conserva suficiente información para distinguir el valor original del valor normalizado.

Prueba y registra el flujo completo

Una prueba útil incluye tanto ejemplos ordinarios como casos límite: campos ausentes, nulos, valores fuera de rango, documentos borrosos o contradictorios, categorías que no encajan, respuestas incompletas y solicitudes que superan los permisos disponibles. Prueba también cada etapa por separado. Así puedes distinguir un fallo del canal de generación de un error del validador o de una regla de negocio demasiado restrictiva.

Mide la proporción de respuestas que se pueden usar sin intervención, los errores por campo, las contradicciones detectadas, los rechazos, los reintentos y los casos enviados a revisión. Una tasa alta de conformidad de esquema no equivale a una tasa alta de corrección semántica. Mantén esas métricas separadas y examina una muestra de los resultados aceptados frente a la fuente original.

Para depurar sin almacenar datos innecesarios, conserva la versión del esquema, la identificación del canal y del modelo cuando proceda, el estado final de la respuesta, el resultado de cada capa de validación y la decisión posterior. Registra la entrada o una referencia segura a ella solo cuando la política de datos lo permita. Evita guardar información sensible por defecto si basta con una referencia, un resumen técnico o una señal de error.

Versiona el contrato y clasifica sus cambios. Añadir un campo opcional puede ser compatible con consumidores preparados para ignorarlo; cambiar el tipo de un campo, alterar el significado de una categoría o convertir un campo opcional en obligatorio puede romperlos. Prueba consumidores y migraciones antes de desplegar cambios, y conserva trazas suficientes para saber qué versión produjo cada dato.

Criterio final: aceptar solo lo que se haya verificado para su uso

La decisión de aceptar una salida depende de su destino. Un borrador visible para una persona puede tolerar incertidumbre si está claramente marcado; un dato contable confirmado o una operación externa requiere controles más estrictos. No hay un único esquema que resuelva estas diferencias: el contrato describe la forma, las reglas de negocio comprueban el significado y los permisos gobiernan la acción.

Antes de poner el flujo en marcha, asegúrate de poder responder qué se valida, dónde se valida, qué evidencia respalda cada valor, qué sucede si una comprobación falla y quién puede autorizar el paso siguiente. Si la aplicación no puede distinguir entre propuesta, dato verificado y acción aprobada, todavía no está lista para confiar en la salida.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.