Qué campos deben ser obligatorios en la respuesta de un agente
Haz obligatorio un campo cuando su presencia permita interpretar, verificar o tramitar la respuesta.
Equipo enginerIT· 2 min de lectura
Haz obligatorio un campo cuando su presencia permita interpretar, verificar o tramitar la respuesta. La obligatoriedad técnica no obliga a inventar un valor: algunos campos deberán admitir un estado desconocido y detener el paso siguiente.
El mínimo cambia según la tarea
Para extraer una factura pueden importar documento, campo, valor, moneda y localización de origen. Para clasificar una consulta serán más útiles identificador, categoría y motivo comprobable. Evita imponer el mismo formulario a todas las tareas. Pregunta qué ocurre si eliminas cada campo: si nadie lo utiliza ni sirve para revisar errores, quizá solo añada mantenimiento y datos almacenados innecesarios.
Obligatorio no significa conocido
En JSON Schema, exigir presencia y permitir un valor nulo son decisiones distintas. Puedes requerir que se informe del estado de un dato sin exigir que exista un dato confirmado. Define cómo se combinan valor y motivo: si falta el importe, el campo no debe recibir un cero para completar el formulario. El consumidor necesita distinguir ausencia, ilegibilidad y falta de permiso para consultarlo.
Escribe dependencias verificables
Establece reglas entre campos. Un resultado declarado resuelto necesita la evidencia que hayas acordado; una derivación necesita motivo y destino; un importe necesita moneda. Decide qué dependencias valida el esquema y cuáles comprobará la aplicación. La documentación de salidas estructuradas de cada proveedor determina qué restricciones admite: no traslades opciones entre servicios suponiendo que son equivalentes. Mantén las reglas de negocio fuera de una confianza ciega en el formato.
Ensaya quitar campos
Prepara respuestas con clave ausente, cadena vacía, nulo, categoría desconocida y evidencia que apunta a otro caso. Comprueba que el consumidor distingue esos defectos y no rellena valores por defecto peligrosos. Involucra al equipo que recibe la salida: debe poder explicar por qué se rechazó. Versiona el contrato y comprueba consumidores antiguos antes de añadir un requisito nuevo; una respuesta más completa puede romper una integración que esperaba otro formato. Incluye una prueba en la que el estado sea correcto pero falte su motivo obligatorio.
Comprobaciones para cerrar la tarea
- ✓ Justifica cada campo obligatorio con una necesidad del consumidor.
- ✓ Define qué valores admiten nulo y qué significa.
- ✓ Rechaza dependencias incoherentes antes de tramitar.
- ✓ Prueba claves ausentes y consumidores de la versión anterior.
Fuentes y documentación
- JSON Schema · Objetos — Presencia, tipos y propiedades adicionales; no valida la verdad de un dato.
- OpenAI · Structured Outputs — El formato estructurado no evita errores de contenido; comprueba las condiciones del proveedor.
Aplicarlo en tu empresa
Podemos revisar el entorno y acordar qué actuaciones, validaciones y mantenimiento necesitas.
Conocer el servicio relacionado →