Respuestas estructuradas de chatbots de IA: esquema JSON, validación y alternativas seguras

Un chatbot de IA puede redactar una respuesta convincente y, aun así, dañar un proceso posterior. Basta con que falte un campo, haya una categoría inventada o un enlace no verificado para que el CRM, el sistema de tickets o el frontend del sitio web procesen datos erróneos. Las respuestas estructuradas de chatbots de IA reducen este riesgo al describir de forma vinculante el formato y los tipos de datos. Sin embargo, solo se vuelven fiables cuando el esquema, el significado técnico, los permisos y los casos de error se evalúan por separado.

Esta guía está dirigida a equipos de sitios web, productos y operaciones que procesan sistemáticamente las respuestas de los modelos. Muestra lo que puede ofrecer un esquema JSON, dónde están sus límites y cómo construir una ruta segura desde la respuesta del modelo hasta la acción real.

Un JSON válido no es aún un contrato fiable

El antiguo modo JSON de muchas API de modelos se asegura principalmente de que una respuesta se pueda analizar sintácticamente como JSON. No garantiza que los campos esperados estén presentes o que se respeten los tipos acordados. La documentación oficial de OpenAI sobre Structured Outputs distingue expresamente entre un JSON válido y la fidelidad al esquema. También Microsoft Foundry describe los Structured Outputs como la vinculación de la respuesta a un esquema JSON adjunto.

Este es un avance importante: en lugar de adivinar nombres de campos cambiantes a posteriori, la aplicación recibe una estructura predecible. A pesar de ello, los proveedores a menudo solo admiten una parte de la especificación completa. La documentación de Gemini para respuestas estructuradas menciona los tipos y propiedades admitidos, pero señala al mismo tiempo subconjuntos y límites de complejidad. Por lo tanto, se debe probar un esquema para el modelo realmente utilizado y la ruta de API concreta.

El esquema describe la forma, no la verdad

JSON Schema es un lenguaje declarativo para describir la estructura y las restricciones de los datos JSON. Un campo se puede definir, por ejemplo, como obligatorio, número, enumeración o matriz. Sin embargo, de esto no se deduce que un valor sea técnicamente correcto. La cadena de caracteres 2026-02-31 puede encajar formalmente como texto, aunque la fecha no exista. Un ID de producto permitido puede ser sintácticamente correcto y, sin embargo, ser desconocido en el cliente actual.

Por este motivo, para los chatbots en producción se necesitan varias capas de validación:

Capa de validación	Pregunta típica	Ejemplo
Transporte	¿Es la respuesta completa y analizable?	Sin interrupción a mitad del JSON
Esquema	¿Coinciden los campos, tipos y valores permitidos?	priority solo es low, medium o high
Semántica	¿Es el contenido técnicamente plausible e internamente coherente?	La fecha de fin no es anterior a la fecha de inicio
Política y acceso	¿Tiene este usuario permiso para ver o usar este valor?	El ticket pertenece a la cuenta de cliente autenticada
Contexto de salida	¿Se renderiza o transmite el valor de forma segura?	El texto se codifica para HTML, no se interpreta como script

Esta separación evita que se confunda la fidelidad al esquema con la aprobación técnica. Para mediciones y pruebas de regresión, se puede combinar con un Golden Set para medir la calidad de las respuestas de chatbots de IA.

Diseñar esquemas pequeños y específicos para cada tarea

Un único objeto de respuesta universal se vuelve rápidamente muy anidado, difícil de entender y costoso de mantener. Es mejor usar un esquema pequeño para cada tarea clara, como clasificar opiniones, estructurar previamente una solicitud de soporte o marcar datos faltantes para una consulta de seguimiento. El nombre y la descripción de cada campo deben explicar su significado técnico.

• Elegir los campos obligatorios con criterio: Solicitar solo los valores que el proceso realmente necesita. Representar los valores desconocidos explícitamente como null o con un estado propio, en lugar de permitir que se inventen.
• Usar enumeraciones en lugar de texto libre: Una lista corta y versionada evita variantes ortográficas en estados, categorías o siguientes pasos.
• Rechazar campos adicionales: Cuando el proveedor lo admita, additionalProperties: false evita claves sorprendentes.
• Repetir los límites en el código de la aplicación: No dejar las longitudes, rangos de valores, hosts de URL y relaciones cruzadas únicamente en manos del modelo o de un subconjunto de esquemas específico del proveedor.
• Versionar el esquema: Un identificador estable y un hash hacen visible qué contrato generó y verificó una respuesta.

"Desconocido" es un estado propio

Un campo vacío, un campo inexistente y un valor explícitamente desconocido no significan lo mismo. Si falta información en la fuente, el esquema debe prever un estado permitido para ello. De lo contrario, el contrato recompensa indirectamente al modelo por insertar una cadena de caracteres plausible. Para valores críticos, una combinación de value, status y un reason opcional suele ser más sólida que un solo campo de texto libre.

Acreditar la versión y el hash de forma conjunta

Por lo tanto, la respuesta no solo debe incluir la versión del modelo y del prompt, sino también la versión del esquema y del validador. Un hash del esquema realmente enviado protege contra desviaciones silenciosas debidas a cambios de compilación o configuración. Durante una migración, el mismo resultado del modelo se puede comprobar inicialmente contra ambas versiones del contrato. Solo se escribe a través de la ruta activa; las diferencias quedan registrados como datos de comparación en control de calidad.

Los prompts no deben trasladar secretos o decisiones de permisos internas al esquema. El modelo puede, por ejemplo, clasificar un siguiente paso deseado. Sin embargo, si ese paso está permitido lo decide posteriormente el servidor en función de la identidad y la directiva actuales.

Tratar las interrupciones y los rechazos como estados independientes

Una respuesta con un formato estricto puede no llegar a producirse. Los límites de salida, los tiempos de espera, los filtros de contenido, los errores del proveedor o un rechazo deliberado del modelo son estados operativos normales. OpenAI documenta para Structured Outputs tanto respuestas incompletas como una ruta de rechazo propia que no sigue necesariamente el esquema solicitado. Por lo tanto, las aplicaciones no deben acceder a ciegas al primer campo esperado.

Un contenedor interno neutral respecto al proveedor separa al menos success, refused, incomplete, provider_error y validation_failed. Solo con success se entrega el contenido estructurado a la siguiente capa de validación. Para el resto de los estados, los usuarios ven un mensaje breve y sincero o una transferencia segura, pero nunca datos de reemplazo inventados.

Comprobar las reglas semánticas en el lado del servidor

Tras la verificación del esquema comienza la validación técnica. Esta debe ser determinista y, en la medida de lo posible, independiente del modelo. Los identificadores de productos se verifican con la fuente de datos actual, las URL con los protocolos y hosts permitidos, y los códigos de localización con los idiomas realmente admitidos. Las sumas, los periodos de tiempo y los cambios de estado necesitan comprobaciones cruzadas. En las respuestas RAG, una fuente indicada debe figurar efectivamente en el resultado de recuperación autorizado.

Esto también se aplica a campos de texto aparentemente inofensivos. El Proyecto de Seguridad GenAI de OWASP advierte contra las salidas del modelo insuficientemente verificadas cuando se transmiten a navegadores, bases de datos, sistemas de archivos u otras herramientas. Para el HTML se codifica según el contexto, el acceso a la base de datos se mantiene parametrizado y las órdenes del sistema nunca se construyen a partir de texto generado libremente. Una salida estructurada es una entrada procedente de una fuente no confiable, no un objeto interno privilegiado.

Una alternativa segura no repara a cualquier precio

Ante una respuesta errónea, un reintento idéntico e inmediato rara vez es la mejor reacción estándar. Puede aumentar los costes y repetir el mismo error. Una ruta alternativa (fallback) delimitada distingue la causa:

1. Interrupción técnica: En caso de un error del proveedor claramente temporal, reintentar de forma estrictamente limitada utilizando el mismo ID de idempotencia.
2. Esquema demasiado complejo: Dividir la tarea en pasos más pequeños y validables individualmente. Esto es un cambio de producto planificado, no la omisión espontánea de campos obligatorios.
3. Error semántico: No activar ninguna acción automática. Solicitar específicamente los datos faltantes o transferir el caso a una revisión humana.
4. Rechazo o límite de directiva: Respetar el rechazo y ofrecer una ruta de información o de transferencia permitida.
5. Estado incierto tras una escritura: Leer primero el sistema de destino mediante el ID de idempotencia antes de iniciar un segundo intento de escritura.

Para cambios mayores, se recomienda una prueba en modo sombra antes del lanzamiento en el sitio web. En ella, la nueva ruta estructurada ya genera resultados, pero aún no ejecuta ninguna acción del usuario.

Las pruebas de contrato cubren más que diálogos de ejemplo

Un buen conjunto de pruebas no contiene solo solicitudes ideales. Entradas vacías, textos muy largos, datos contradictorios, categorías desconocidas, múltiples idiomas, intentos de inyección de prompts, rechazos del proveedor y límites de tokens intencionadamente reducidos también forman parte de él. Para cada caso, el estado operativo esperado, el resultado del esquema y la decisión técnica se registran por separado.

Al realizar cambios en el esquema, el equipo debe validar ejemplos antiguos guardados con la nueva versión. Durante una migración, la aplicación puede verificar temporalmente frente a la versión antigua y la nueva sin ejecutar dos acciones. Solo cuando la tasa de éxito, los rechazos semánticos y la latencia son estables, el nuevo contrato se convierte en la ruta de escritura. Los errores se pueden asignar a la versión del modelo, del prompt y del esquema utilizados mediante una observabilidad integral del chatbot de IA, sin registrar respuestas confidenciales completas.

Métricas para las operaciones continuas

La métrica más importante no es solo la proporción de respuestas sintácticamente válidas. Resultan de utilidad la tasa de esquema al primer intento, la tasa de rechazo semántico, la proporción de respuestas incompletas, los rechazos, los intentos de reparación limitados, las transferencias a humanos, así como la latencia y el coste por resultado validado con éxito. Los valores se analizan por separado según la versión del modelo, prompt, esquema, caso de uso e idioma.

Un aumento repentino de los errores semánticos manteniendo constante la tasa de esquema es especialmente revelador: la forma sigue siendo correcta, pero los contenidos o la referencia de datos se desvían. En ese caso, el proceso debe cambiar a un modo seguro. La guía existente sobre modo degradado y rollback en chatbots de IA muestra cómo preparar una ruta de repliegue de este tipo.

Lista de comprobación antes de la primera acción automática

• ¿Se ha probado la ruta concreta de la API y del modelo con este esquema exacto?
• ¿Se detectan las respuestas incompletas, los rechazos y los errores del proveedor antes del análisis sintáctico?
• ¿Valida el servidor el esquema y las reglas técnicas de forma independiente del modelo?
• ¿Se verifican de nuevo la identidad, el cliente y los permisos inmediatamente antes de cada acción?
• ¿Están protegidos adecuadamente según el contexto el HTML, las URL, los valores de la base de datos y los parámetros de las herramientas?
• ¿Evitan la idempotencia y la relectura las escrituras duplicadas?
• ¿Existen pruebas de conjunto dorado, de ataques, de localización y de migración?
• ¿Son observables la versión del esquema, la clase de error y las métricas de calidad?
• ¿Puede el equipo cambiar a un modo seguro de información o transferencia sin pérdida de datos?

Las salidas estructuradas hacen que los chatbots de IA sean más fáciles de integrar, pero no transfieren autoridad al modelo. Quien trata la forma, la semántica, el acceso y el contexto de salida como controles independientes obtiene un contrato transparente en lugar de una fachada JSON aparentemente segura. Para un nuevo flujo de trabajo en un sitio web, vale la pena comenzar con un caso de uso acotado, un esquema versionado pequeño y una prueba en modo sombra que se pueda medir.