Cómo pedir a una IA una salida que puedas comprobar
Una respuesta bonita es difícil de reutilizar. Un esquema con campos, tipos y huecos explícitos permite validar lo que la IA produjo antes de pasarlo a otra herramienta.
Pedir a una IA «resume este contrato» puede dar una respuesta útil, pero deja todo el trabajo difícil del otro lado: alguien tiene que localizar las fechas, copiar los importes y adivinar si un silencio significa que no había dato o que el modelo lo omitió. Si el resultado va a viajar a una hoja de cálculo, una base de datos o una decisión, conviene pedir una forma antes que una redacción. La capacidad que se lleva usted de aquí es convertir una tarea abierta en un esquema verificable —campos, tipos, valores permitidos y un tratamiento explícito de lo que falta— para que comprobar la respuesta deje de ser una lectura atenta y pase a ser una revisión mecánica.
La prosa es cómoda; el esquema es comprobable
La diferencia práctica es de a quién le toca el esfuerzo. Una respuesta en prosa es agradable de leer y cara de verificar: el revisor tiene que releerla entera para saber qué dato hay y qué falta. Una respuesta con forma —una tabla, un objeto de datos— es menos elegante y mucho más barata de comprobar: se ve de un vistazo qué campos están, cuáles vienen vacíos y cuáles habría que contrastar. Cuando el destino de una respuesta no es un lector humano sino otro sistema, la prosa es directamente un estorbo: hay que volver a extraer de ella lo que se podría haber pedido ya estructurado.
Define el contenedor y sus reglas
El formato más común para esto es JSON, una sintaxis para intercambiar datos estructurados descrita en el RFC 8259. Conviene entender qué hace y qué no: JSON no vuelve verdadera una respuesta, solo hace visible su forma. Un objeto puede estar perfectamente bien formado y contener una cifra inventada. Para extraer, por ejemplo, las obligaciones de un documento, se definen campos concretos —fecha, parte_responsable, acción, fuente, confianza_de_extracción— en vez de dejar que el modelo elija cómo organizar la respuesta.
Después vienen las reglas, que son las que convierten un contenedor en un control. Una fecha debe usar un formato fijo; un importe debe llevar su moneda; una categoría debe pertenecer a una lista cerrada de valores permitidos; un campo desconocido vale null y no una cadena vacía, un cero ni una invención — cada uno de esos tres se leería después como un dato real. JSON Schema es el lenguaje estándar para expresar estas restricciones: tipos, campos obligatorios, patrones, formatos y enumeraciones. Ese último punto —la enumeración— es el más infravalorado: si a un campo «riesgo» solo se le permiten los valores «alto», «medio» o «bajo», el modelo no puede colar un cuarto matiz inventado; la forma le cierra la puerta.
Pide huecos, no relleno
La instrucción decisiva es una sola frase: «No inventes valores; si el documento no contiene el dato, usa null y explica qué falta». Sin ella, un modelo tiende a rellenar el hueco con algo plausible, y ese relleno es indistinguible de un dato real hasta que alguien lo comprueba. Con ella, se separa el error de la ausencia: un null declarado es una pregunta abierta y honesta; una fecha inventada es una trampa. Pida además, para cada campo que importe, una referencia al fragmento exacto de la fuente de donde salió — no como adorno, sino como el gancho que hace verificable el dato.
Hay un campo tentador del que conviene desconfiar: la «confianza» que el propio modelo se asigna. Un número que dice «estoy 0,9 seguro» no está calibrado: no significa que acierte nueve de cada diez veces, solo que el modelo escribió 0,9. Sirve como señal blanda para ordenar qué revisar primero, nunca como sustituto de la comprobación. La autoevaluación de un sistema no es evidencia sobre sí mismo.
Dos controles, en este orden
De todo lo anterior sale una verificación en dos capas que no hay que confundir. La primera es estructural: comprobar que la respuesta cumple el esquema —los tipos correctos, los campos obligatorios presentes, los valores dentro de las listas permitidas—. Esto lo hace una máquina en un instante y descarta las respuestas mal formadas — y conviene automatizarlo con un validador de esquema, no revisarlo a ojo, porque el ojo humano se cansa y da por bueno un objeto largo con un campo mal tipado en el medio. La segunda es factual: comprobar los campos importantes contra el documento original, usando las citas que se pidieron. Un objeto puede pasar la primera capa con una cifra falsa; solo la segunda la caza. El perfil de IA generativa de NIST insiste en medir y gestionar el riesgo, y aplicado aquí se resume en una advertencia: no confundir «se pudo importar» con «es correcto». Que un dato encaje en la casilla no dice nada de si es verdad.
Los fallos que la forma no arregla
Conviene no vender la estructura como una cura, porque tiene sus propias trampas y todas se resuelven en la segunda capa. Un modelo puede devolver JSON impecable y, a la vez, omitir en silencio una obligación que sí estaba en el documento: la forma es válida, pero incompleta, y nada en el objeto avisa de lo que falta. Puede también forzar un valor para que encaje en la lista permitida —marcar «medio» un riesgo que no supo clasificar— y así esconder su incertidumbre detrás de una casilla correcta. Y puede rellenar el campo de cita con un fragmento que suena a la fuente pero no dice lo que el campo afirma. Ninguno de estos fallos lo detecta el validador de esquema, porque todos producen un objeto bien formado. Por eso la comprobación contra el original no es opcional: es la única que ve lo que la estructura, por definición, oculta.
Una plantilla reutilizable
La instrucción que junta todo esto cabe en unas líneas y sirve para casi cualquier extracción. Indique la tarea, el esquema, los valores permitidos, qué hacer cuando falta un dato y qué evidencia se exige. Por ejemplo: «Extrae las obligaciones del contrato. Devuelve solo JSON, sin texto alrededor. Para cada obligación incluye: acción, responsable, fecha en formato ISO o null, cita_literal y página. No infieras lo que no esté escrito; si algo es ambiguo, anótalo en un campo notas». Esa plantilla es reutilizable porque no depende del documento concreto: cambia el esquema según la tarea, pero la disciplina —forma, valores cerrados, null honesto y cita— es siempre la misma.
El hábito que queda
La regla que sobrevive a cualquier modelo es sencilla: cuanto más lejos vaya a viajar una respuesta —a una persona, a una tabla, a una automatización que actúa sola— más debe parecerse a un formulario revisable y menos a una improvisación elegante. La prosa bonita es para leer; la forma comprobable es para confiar. Y no es una técnica solo para programadores: cualquiera que pegue la respuesta de una IA en una hoja de cálculo ya está, sin saberlo, pidiéndole una forma — la diferencia es si la pide explícita, con sus reglas, o la deja implícita y luego pelea con lo que salga. Y el orden importa: primero se valida la forma, que es barata y automática, y solo después la verdad de los datos, que es cara y humana. Pedir una salida con forma no hace al modelo más veraz; hace que su falta de veracidad sea fácil de encontrar, que en la práctica es casi lo mismo.
Fuentes primarias
Este artículo se ha elaborado con inteligencia artificial bajo supervisión editorial humana.
