- Convertir una petición vaga en un contrato de entrada, salida y límites.
- Hacer que un flujo basado en documentos cite su evidencia o se abstenga.
- Validar campos críticos antes de que una persona apruebe el resultado.
La diferencia entre una demo y un flujo
Una demo responde algo aparentemente bueno a un ejemplo. Un flujo debe responder de manera controlada a muchos ejemplos, incluidos los incompletos y los equivocados. Para conseguirlo, separa las etapas: recibe una entrada autorizada, limpia lo innecesario, busca evidencia si trabaja con documentos, genera un borrador estructurado, valida reglas simples y lo entrega para revisión. Solo una acción posterior y explícita podría usar ese resultado.
Entrada autorizada -> normalizar y minimizar datos -> recuperar fuentes permitidas si hacen falta -> generar borrador con esquema fijo -> validar formato, campos y reglas de negocio -> revisión humana -> acción posterior solo si se aprueba
Escribe el contrato antes del prompt
El prompt ayuda a orientar al modelo, pero no es el contrato completo. Primero define el trabajo sin mencionar marcas ni modelos. Para extraer una factura, por ejemplo, la salida no es «un resumen útil»: es un borrador con campos concretos, una fuente identificable y una lista de dudas. Si el campo no se encuentra o no pasa una regla básica, debe quedar vacío y marcado para revisión.
nombre: extracción de factura a borrador finalidad: preparar una fila revisable; no contabilizar entrada: PDF autorizado y su identificador interno datos_no_permitidos: contraseñas, datos ajenos al documento salida: emisor, fecha, número, base, IVA, total, dudas, fuente regla_de_evidencia: cada campo crítico indica página o zona leída abstención: si no puede leer o no encuentra un campo, usa null y explica por qué validación: fecha válida; importes numéricos; total coherente o marcado revisor: administración acción_prohibida: exportar a contabilidad, pagar o modificar registros
Fuentes: evidencia antes que seguridad aparente
Si el flujo responde sobre una política, un catálogo o una base documental, el modelo no debe completar huecos con frases plausibles. Entrega junto a la respuesta el identificador, versión y fragmento de la fuente que la sostiene. Si no hay evidencia suficiente, la salida correcta es una abstención útil: «no encuentro una fuente autorizada para afirmarlo; revisa este documento o escala la consulta».
- Limita la búsqueda al conjunto de documentos y permisos correspondientes.
- Guarda versión, fecha y fragmento de la fuente, no solo el texto final.
- Distingue un dato extraído, una inferencia y una propuesta de redacción.
- No conviertas una puntuación de similitud en una garantía de que la respuesta es correcta.
Valida fuera del modelo lo que sea objetivo
Un modelo puede proponer una fecha, un importe o un código, pero una regla determinista debe comprobar después que el formato existe y tiene sentido. Valida tipos, campos obligatorios, rangos, duplicados y relaciones simples. La revisión humana decide el significado; las reglas evitan que una salida incompleta parezca lista para usar.
salida_borrador:
emisor: ACME S.L.
fecha: 2026-07-18
numero: F-204
base: 100
iva: 21
total: 121
evidencia:
total: pagina 1, bloque inferior
dudas: []
validaciones:
- todos los campos críticos existen o están marcados null
- total = base + iva, con tolerancia explícita
- fecha se puede interpretar
- número no está duplicado en la muestra
- si falla una regla: estado = revisar, nunca = listoSi has guardado la evidencia de esta lección, continúa con «Pruebas de fallo y métricas». Si no, repite la comprobación antes de avanzar.