Cómo obtener JSON con la IA: datos estructurados fiables

Le pides a la IA que saque la información de una factura «en JSON», y responde: «¡Claro! Aquí tienes el JSON solicitado», seguido de un bloque de código y luego de una nota que explica sus decisiones. Al día siguiente, el campo importe se llama total, la fecha pasa a estar en letras y el precio se convierte en "125,50 €", una cadena de caracteres. Para una persona, es legible. Para un script o una hoja de cálculo, es una avería.

JSON es un formato de texto que ordena los datos en pares de nombre y valor. No hace falta saber programar para aprovecharlo, y si tu destino es una hoja de cálculo, el CSV será todavía más sencillo. En ambos casos, el principio es el mismo: decides el formato de antemano, sin margen de interpretación.

Describir el esquema en lugar de decir «en JSON»

La sola palabra «JSON» deja al modelo libre de elegir la estructura, los nombres y los tipos. Hay que darle el molde completo. Piensa en un restaurador que quiere llevar el control de sus facturas de proveedores.

Antes:

Extrae la información de esta factura en JSON.

Después:

Extrae los datos de la factura de abajo. Responde únicamente con un objeto JSON válido, sin texto antes ni después y sin etiquetas de código Markdown.

Respeta exactamente esta estructura y estos nombres de campos:

{
  "proveedor": "cadena",
  "numero_factura": "cadena",
  "fecha": "AAAA-MM-DD",
  "total_sin_iva": número,
  "total_con_iva": número,
  "lineas": [
    { "descripcion": "cadena", "cantidad": número, "precio_unitario_sin_iva": número }
  ],
  "categoria": "bebidas" | "frescos" | "ultramarinos" | "otros"
}

Reglas:
- Los números se escriben con punto decimal, sin símbolo de moneda.
- Si falta una información o es ilegible, pon null. No la adivines nunca ni la calcules.
- No añadas ningún campo.

Factura:
[TEXTO DE LA FACTURA]

Cuatro decisiones marcan la diferencia. El esquema se muestra entero, así que los nombres de los campos ya no cambian. La fecha tiene un formato inequívoco: 2026-03-04 no se confunde de un país a otro. La categoría es una lista cerrada, lo que evita tener «Bebidas», «bebida» y «Vinos» en el mismo archivo. Por último, el null le da a la IA una salida honesta cuando falta la información.

Los campos que faltan, origen de la mayoría de los errores

Cuando un campo es obligatorio en tu esquema y la información no está en el documento, el modelo tiende a producir una. Puede aparecer un número de IVA donde no había ninguno. El JSON será perfectamente válido y falso.

Dos precauciones ayudan. La primera es la regla del null de arriba, para cada campo. La segunda es pedir la prueba cuando lo que está en juego lo justifique: añade un campo extracto_fuente que copie el pasaje de donde sale el valor. Así puedes comparar rápidamente sobre una muestra. Para la lógica general, el artículo para reducir las alucinaciones profundiza más.

El caso más habitual: un CSV para Excel

Si tu destino es una hoja de cálculo, olvida JSON: pide directamente un CSV. Una dificultad habitual que conviene conocer: con la configuración regional española, Excel espera en general un punto y coma como separador y una coma para los decimales. Un CSV con comas puede abrirse, por tanto, con todo en una sola columna.

Ejemplo para una tesorera de asociación que transforma inscripciones recibidas por correo, aquí con datos ficticios:

Transforma los mensajes de abajo en una tabla CSV, sin ningún texto alrededor y sin etiquetas de código.

Parámetros:
- separador: punto y coma ;
- decimales: coma;
- primera línea, exactamente: apellidos;nombre;actividad;importe;medio_pago;a_verificar
- actividad: entre [LISTA DE ACTIVIDADES]
- medio_pago: cheque, transferencia, efectivo o vacío si no se indica.

Una línea por persona inscrita. Si un mensaje inscribe a dos personas, haz dos líneas. Si falta una información o es ambigua, deja la casilla vacía y pon «sí» en a_verificar.

Mensajes:
[PEGA LOS MENSAJES]

Pega el resultado en un archivo .csv, o en tu hoja de cálculo usando la función de importación de texto. Ojo con los datos personales: antes de pegar los mensajes de personas reales, mira lo que no hay que meter en un chatbot y las condiciones de tu plan.

Validar el resultado, siempre

Una salida estructurada puede fallar de tres maneras: el texto no es un JSON válido, la estructura no corresponde al esquema o los valores son falsos. Las dos primeras se controlan automáticamente. Aquí tienes un script corto en Python que se detiene en cuanto aparece un problema:

import json

CAMPOS = {"proveedor", "numero_factura", "fecha", "total_sin_iva",
          "total_con_iva", "lineas", "categoria"}
CATEGORIAS = {"bebidas", "frescos", "ultramarinos", "otros"}

def validar(respuesta: str) -> dict:
    data = json.loads(respuesta)  # falla si no es JSON
    if set(data) != CAMPOS:
        raise ValueError(f"Campos incorrectos: {set(data) ^ CAMPOS}")
    if data["categoria"] not in CATEGORIAS:
        raise ValueError(f"Categoría desconocida: {data['categoria']}")
    con_iva, sin_iva = data["total_con_iva"], data["total_sin_iva"]
    if con_iva is not None and sin_iva is not None and con_iva < sin_iva:
        raise ValueError("Total con IVA inferior al total sin IVA")
    return data

El control del total con IVA es sentido común de negocio, y atrapa errores que ningún esquema vería. Para los valores, prevé un control por muestreo: compara diez documentos a mano antes de fiarte del procesamiento, y luego algunos de vez en cuando.

Sin código, puedes pedirle al modelo que te señale las líneas sospechosas en una conversación nueva, pero puede pasarse alguna por alto. Una suma recalculada en la hoja de cálculo sigue siendo más segura.

Pasar a la API cuando sube el volumen

Si tratas decenas de documentos con un programa, el prompt solo no es la mejor solución. Las API de los principales proveedores ofrecen opciones para obligar a la salida a ajustarse a un esquema JSON. Sus nombres y sus garantías evolucionan, mira la documentación de tu proveedor cuando te pongas con ello. Estas opciones te garantizan una estructura conforme, no valores correctos: conserva la regla del null y los controles de negocio.

Para un flujo en varios pasos, una salida JSON sirve también de puente entre dos modelos o dos prompts, como en una cadena de prompts.

Haz la prueba con tres documentos reales

Elige tres documentos del mismo tipo, uno de ellos mal hecho: una factura escaneada, un mensaje incompleto. Pásalos por el prompt que prefieras con un esquema de solo cinco campos y compara después cada valor con el original. El documento mal hecho te dirá qué reglas añadir antes de ampliar el esquema.