Blog de SchemaSafe

Validación de esquema JSON sin LLM

La validación de esquema pertenece a herramientas deterministas: la misma entrada produce el mismo resultado de aprobación o rechazo, cada vez. Un LLM puede explicar por qué un documento falló o crear un esquema a partir de un ejemplo, pero la parte de aprobación o rechazo debería provenir de un validador real. Cuando el límite entre la explicación y la decisión permanece claro, el contrato sigue siendo algo que se puede probar y confiar.

El determinismo es el producto

Cuando diseño un validador, me enfoco en el recorrido a través del árbol de instancias. Cada paso produce un objeto de error que lleva una ruta de puntero JSON, la palabra clave que falla y un mensaje corto. Debido a que el recorrido sigue el mismo algoritmo para los mismos datos, la lista de errores es idéntica en cada ejecución. Esa repetibilidad permite a los equipos tratar la validación como una puerta que nunca cambia su veredicto sin un cambio real en el esquema o la entrada.

Las rutas de puntero JSON se asignan directamente a campos de formulario o claves de respuesta de API. Un frontend puede tomar el puntero /items/2/name y resaltar el campo de nombre del tercer elemento sin ninguna capa de traducción adicional. Este mapeo es determinista, por lo que el mismo puntero siempre apunta a la misma ubicación en la misma forma de documento.

En CI, ejecuto el validador contra la suite de pruebas y contra cualquier fixture generada. Si el validador devuelve una matriz de errores vacía, la compilación continúa; cualquier matriz no vacía falla la compilación y la carga de error se publica como un artifacto. Debido a que la salida es legible por máquina, los pasos posteriores pueden contar errores, agruparlos por puntero o publicar un comentario en la solicitud de extracción que muestra las rutas exactas que fallan.

Donde un LLM gana su lugar

Solo uso un modelo de lenguaje para tareas que no requieren un veredicto verdadero/falso. El modelo nunca decide pasar o fallar; solo produce sugerencias que un humano o una herramienta pueden revisar.

Dado un puñado de documentos JSON de muestra, le pido al modelo que emita un esquema Draft 2020-12 que capture los tipos observados, los campos requeridos y los patrones básicos. La salida es un punto de partida; lo ejecuto a través del validador para ver si acepta los ejemplos y luego ajusto o relajo las restricciones manualmente.

Cuando el validador devuelve una matriz de errores, le doy cada objeto de error al modelo con una solicitud para reescribir el mensaje en lenguaje plano. El modelo puede convertir “falló la palabra clave “requerido” en el puntero /user/profile/age” en “El perfil de usuario falta un campo de edad, que su servicio espera que sea un entero.” Esto ayuda a los consumidores de la API que no están familiarizados con las palabras clave del esquema JSON.

Al mostrar al modelo una lista de errores de validación frecuentes, puedo pedirle que proponga restricciones adicionales, como una longitud mínima de cadena o un patrón para un identificador. Reviso cada sugerencia, agrego las que tienen sentido y ejecuto el validador nuevamente para confirmar que el nuevo esquema aún pasa las muestras buenas conocidas.

Por seguridad, mantengo el modelo detrás de una API interna y registro cada prompt y respuesta. El registro me permite auditar si el modelo alguna vez intentó influir en el límite de decisión, lo que no puede hacer porque nunca paso su salida al validador como regla.

Ejecutar validación en CI y en el borde

El mismo esquema debe proteger el repositorio de código y el servicio en vivo. Ejecuto el validador en dos lugares:

Ejecutar la validación solo en un gateway deja el servicio interno expuesto a desviaciones; si el esquema del gateway se actualiza pero un servicio downstream olvida realizar el cambio, los datos incorrectos pueden pasar desapercibidos. Al incrustar el validador en el servicio, garantizo que el contrato se haga cumplir dondequiera que viva el código.

Cuando la validación falla, devuelvo HTTP 400 con un cuerpo JSON que contiene una matriz de objetos de error. Cada objeto de error incluye:

Los clientes pueden analizar esta matriz y mostrar errores de formulario en línea, lo que acelera el trabajo de integración en comparación con una cadena genérica de "validación fallida".

Dado que el validador es sin estado y determinista, puedo utilizar el mismo binario o biblioteca en ambos lugares sin preocuparme por un estado oculto que podría causar divergencia.

Generación de borradores versus gobernanza

SchemaSafe separa las preocupaciones de manera clara:

Esta división mantiene el contrato auditable. Puedo señalar un archivo de esquema específico en el repositorio, anotar la versión del validador y mostrar que la misma entrada siempre produce el mismo resultado. La contribución del modelo vive en registros separados o en comentarios adjuntos a la solicitud de extracción; nunca se convierte en parte del registro de decisión inmutable.

Cuando necesito actualizar el esquema, sigo estos pasos:

A lo largo de este flujo, el validador es el guardián; el modelo nunca tiene la última palabra.

Qué no es esto

Este enfoque no es una promesa de que cada documento inválido sea detectado antes de que llegue a un usuario. Si un desarrollador omite intencionalmente el middleware o si un error en el validador permite que se escape un error, los datos incorrectos aún pueden aparecer. No afirmo una cobertura del 100 %; solo afirmo que la verificación es determinista y repetible.

No es un reemplazo para un diseño de API reflexivo. Un esquema puede describir la forma y las restricciones básicas, pero no puede expresar reglas de negocio que dependan de un estado externo o de una lógica de campo cruzado compleja. Esas reglas aún necesitan pruebas unitarias o guardias de tiempo de ejecución.

No es una garantía de que el LLM siempre produzca explicaciones útiles. El modelo puede ocasionalmente perder matices o producir una reescritura engañosa. Trato su salida como una sugerencia que un ser humano puede aceptar, editar o descartar.

Finalmente, no es una bala de plata para la seguridad. Si bien la validación de la entrada reduce muchos riesgos de inyección, sigo las pautas de OWASP sobre la inyección de prompts (https://genai.owasp.org/llmrisk/llm01-prompt-injection) y sobre la higiene de credenciales en CI/CD (https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene) para mantener la seguridad del pipeline circundante.

Referencias

https://genai.owasp.org/llmrisk/llm01-prompt-injection

https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene

https://ajv.js.org/json-schema.html

https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html

Preguntas frecuentes

La validación debe ser reproducible: misma entrada, mismo resultado. El juicio de un modelo puede variar entre ejecuciones, lo que es inaceptable para un contrato que controla una implementación. El validador decide; el modelo explica.

Crear un esquema a partir de un ejemplo, reescribir un error de validación para un ser humano o sugerir por qué un campo fue omitido. Esas son ayudas adicionales a un validador real, no un sustituto de uno.

No. Valida las solicitudes de entrada en el servicio que controlas para que los mensajes de error incluyan el contexto del dominio. Ejecuta el mismo esquema en CI contra fixtures y trata los cambios de esquema como posibles cambios de ruptura.

El borrador 2020-12 es la versión estable compatible con validadores modernos como Ajv v8 y alineada con OpenAPI 3.1. Fija la URL del esquema en cada archivo para que el comportamiento no se desvíe.

Prueba el producto: SchemaSafe

2026-09-16 · solo fuentes primarias · sin métricas de tráfico fabricadas