3 reglas de prompting que evitaron que mi IA adivinara

Perdí un cliente porque GPT-4o me dijo con total confianza las condiciones de pago incorrectas de un contrato.

No "más o menos mal." No "ligeramente errado." Extrajo una cifra de net-30 de la página 8 de un acuerdo con proveedor de 22 páginas, ignorando completamente la enmienda de net-45 en la página 14. Construí el calendario de facturación alrededor de ese número. El cliente pagó a tiempo — según el calendario equivocado. El proveedor señaló la discrepancia. El cliente preguntó por qué no lo había detectado. No tuve una buena respuesta.

La IA había acertado en otros 47 campos de esa misma extracción. Direcciones, fechas, partidas, identificaciones fiscales — todo perfecto. Eso es lo que hizo el error en las condiciones de pago tan peligroso. Cuando un sistema acierta el 98% de las cosas, dejas de verificar el otro 2%. Y ese 2% es donde se esconde el daño.

Ese incidente con el contrato ocurrió en octubre de 2025. Desde entonces, he estado obsesionado con una sola pregunta: ¿cómo impides que la IA adivine cuando no sabe?

No "cómo reduces las hallucinations" en el sentido abstracto y académico. Me refiero específicamente — cuando le entregas a un modelo de IA un documento y le pides que extraiga datos estructurados, ¿cómo evitas que rellene una respuesta segura cuando la respuesta real es ambigua, faltante o contradictoria?

Encontré tres reglas que funcionan. Son extremadamente simples. No requieren fine-tuning, pipelines de RAG ni entrenamiento de modelos personalizados. Son simplemente estrategias de prompting — pero cambian fundamentalmente cómo se comporta la IA. Las he ejecutado en producción durante cinco meses en revisión de contratos, procesamiento de facturas y entrada de datos en CRM, y la diferencia es abismal.

Esto es lo que la mayoría de las guías de prompt engineering no te dicen: el problema no es que los modelos de IA carezcan de inteligencia. El problema es que tienen demasiada — combinada con cero honestidad sobre lo que no saben.

Por qué los modelos más inteligentes adivinan con más confianza (no menos)

Hay un patrón con el que me encuentro constantemente y del que nadie habla lo suficiente. A medida que los modelos de IA se vuelven más capaces, no se vuelven más honestos. Se equivocan de manera más convincente.

Lo llamo la Brecha Inteligencia-Honestidad. Y la investigación lo respalda.

Investigadores del MIT descubrieron en enero de 2025 que cuando los modelos de IA alucinan, tienen un 34% más de probabilidad de usar lenguaje de alta confianza — palabras como "definitivamente", "ciertamente" y "sin duda". El modelo no duda cuando está adivinando. Redobla la apuesta.

Esto no es un bug en un modelo específico. Es un problema estructural incorporado en cómo se entrenan todos los large language models. Un estudio de 2025 publicado en Science lo expuso claramente: los LLM aprenden a farolear porque su entrenamiento recompensa las respuestas seguras y penaliza la incertidumbre. La estructura de incentivos es idéntica a un examen de opción múltiple donde dejar una pregunta en blanco puntúa cero, pero adivinar tiene posibilidad de puntuar. Así que el modelo siempre adivina.

Investigadores de Carnegie Mellon confirmaron esto en julio de 2025 — los chatbots de IA permanecen sobreconfiados incluso cuando se equivocan, y los usuarios no pueden detectar de manera fiable la diferencia entre una respuesta correcta y segura y una hallucination segura.

La implicación práctica me golpeó fuerte: los modelos de reasoning — por los que estaba pagando precios premium — en realidad alucinan más en tareas ambiguas, no menos. Benchmarks recientes de principios de 2026 muestran que GPT-5, Claude Sonnet 4.5 y Gemini-3-Pro superaron todos el 10% de tasa de hallucination en benchmarks más difíciles. ¿La hipótesis? Los modelos de reasoning "sobreanalizan" — invierten esfuerzo computacional en construir respuestas que suenan plausibles a partir de evidencia insuficiente, en lugar de señalar que la evidencia es insuficiente.

Cuando usaba Claude para extraer datos de contratos, esencialmente le estaba entregando a un empleado brillante un documento y diciéndole "rellena todos los campos." Y como cualquier empleado brillante que ha sido entrenado para nunca decir "no lo sé", rellenó cada campo. Con confianza. Incluyendo aquellos donde la respuesta correcta era "este documento no lo especifica claramente."

Esa es la brecha. Inteligencia sin honestidad. Capacidad sin calibración.

Las tres reglas que estoy a punto de compartir no hacen a la IA más inteligente. La hacen honesta. Y honesta, resulta, vale mucho más que inteligente cuando estás construyendo sistemas en producción.

Regla 1: Forzar respuestas en blanco ante la incertidumbre

Esta es la regla que lo cambió todo para mí. Es tan simple que casi parece trampa.

La instrucción: Dile a la IA que deje un campo en blanco si los datos son ambiguos, faltantes o contradictorios — y exige una explicación de una oración de por qué se dejó en blanco.

Aquí está la estructura exacta de prompt que uso para la extracción de datos de contratos:

Extract the following fields from this document.

CRITICAL RULE: If any field's value is ambiguous, missing,
or if conflicting information exists in the document, leave
the field BLANK. Do not guess. Do not infer. Do not fill in
a "most likely" answer.

For every blank field, provide a one-sentence explanation of
why it was left blank.

Your job is to extract only what the document explicitly states.
If a value cannot be determined with certainty from the source
text, it must remain empty.

Fields to extract:
- Vendor name
- Payment terms
- Contract start date
- Contract end date
- Total contract value
- Renewal clause (auto-renew / manual / none)
- Governing law jurisdiction
...

La magia está en lo que sucede después. En lugar de obtener una extracción completamente rellenada con errores ocultos dispersos aleatoriamente en 50 campos, obtengo algo como esto:

Vendor name: Meridian Supply Co.
Payment terms: [BLANK]
  → Two different payment terms found: "net 30" on page 8
    (Section 4.2) and "net 45" on page 14 (Amendment A,
    dated March 2024).
Contract start date: January 15, 2024
Contract end date: January 14, 2026
Total contract value: $847,500
Renewal clause: [BLANK]
  → Section 9.1 references "automatic renewal" but
    Amendment A, Section 3 states "renewal subject to
    mutual written agreement." These conflict.
Governing law jurisdiction: State of Delaware

Mira lo que acaba de pasar. ¿El problema de las condiciones de pago que me costó un cliente? La IA lo detectó. No porque se hizo más inteligente — sino porque le di permiso para decir "encontré un conflicto y no voy a tomar partido."

Por qué funciona psicológicamente

Esta regla funciona porque cambia fundamentalmente la tarea de la IA. Sin ella, la instrucción implícita del modelo es: "rellena todos los campos." Esa es una tarea de completar. El modelo está optimizado para completar. Los espacios en blanco se sienten como fracaso para un sistema orientado a completar.

Con la regla, la tarea cambia a: "rellena lo que tengas seguro, y marca todo lo demás." Esa es una tarea de clasificación — seguro versus incierto. Los modelos son sustancialmente mejores en clasificación binaria que en generar respuestas precisas a partir de entradas ambiguas.

No le estoy pidiendo al modelo que sea más inteligente. Le estoy pidiendo que haga un trabajo diferente y más fácil.

La explicación de una oración no es negociable

Al principio, probé la regla sin requerir la explicación. El modelo dejaba campos en blanco, pero no tenía idea de por qué. ¿Faltaban realmente los datos? ¿Había un conflicto? ¿El modelo simplemente no los encontró?

El requisito de explicación resuelve esto completamente. "Se encontraron dos condiciones de pago diferentes en las páginas 8 y 14" me dice exactamente qué pasó y exactamente dónde buscar. Puedo resolver la ambigüedad en 30 segundos leyendo esas dos páginas yo mismo. Compara eso con releer el contrato completo de 22 páginas para descifrar por qué un campo está en blanco.

La explicación también actúa como un mecanismo de grounding. Cuando el modelo tiene que articular por qué tiene incertidumbre, se ve forzado a referenciar evidencia específica (o la ausencia de evidencia) en el documento fuente. Esto previene un modo de fallo que vi al principio donde el modelo dejaba cosas en blanco no porque los datos fueran genuinamente ambiguos, sino porque estaba siendo excesivamente cauteloso. El requisito de explicación crea una calibración natural — el modelo tiene que justificar su incertidumbre, lo que hace que la incertidumbre sea significativa.

Resultados en el mundo real

He estado ejecutando esta regla en flujos de trabajo de revisión de contratos durante cinco meses. El patrón es consistente: en lugar de obtener una extracción de aspecto limpio con 2-4 errores ocultos enterrados en 50+ campos, obtengo una extracción con 3-7 campos en blanco que están obviamente marcados para revisión humana.

El ahorro de tiempo se acumula rápido. Antes de esta regla, mi proceso de revisión era: verificar cada campo contra el documento fuente. Eso tomaba 25-35 minutos por contrato. Ahora mi proceso de revisión es: escanear los campos completados buscando problemas obvios, luego dedicar tiempo enfocado a los campos en blanco. Eso toma 8-12 minutos. Misma precisión. Menos de la mitad del tiempo.

Pero aquí es donde se pone aún más interesante — la regla mejoró la precisión de los campos no vacíos también. Cuando el modelo sabe que puede pasar en campos inciertos, deja de intentar forzar datos ambiguos en respuestas limpias. Los campos que sí completa tienden a ser genuinamente limpios.

Regla 2: Cambia el incentivo — Haz que las respuestas incorrectas sean costosas

La Regla 1 le da a la IA permiso para dejar cosas en blanco. La Regla 2 le da una razón para preferir blanco sobre incorrecto.

La instrucción: Dile explícitamente a la IA que una respuesta incorrecta cuesta tres veces más que un campo en blanco.

Así es como lo formulo:

Scoring for this task:
- A correct extraction: +1 point
- A blank field with explanation: 0 points
- An incorrect extraction: -3 points

Your goal is to maximize your total score. A wrong answer is
three times worse than leaving a field blank. When in doubt,
leave it blank.

Esto parece demasiado simple para funcionar. Es una línea de texto en un prompt. El modelo no recibe puntuación real. No hay un bucle de reinforcement learning aquí. Entonces, ¿por qué cambia el comportamiento?

El cambio de comportamiento es real

Porque los modelos de lenguaje han internalizado el concepto de estructuras de incentivos de sus datos de entrenamiento. Han visto millones de ejemplos de cómo los humanos se comportan cuando las penalizaciones son asimétricas — pólizas de seguros, diagnósticos médicos, presentaciones legales, procesos de control de calidad. Cuando enmarcas la tarea con costos explícitos por errores, el modelo activa patrones asociados con toma de decisiones de alto riesgo y aversión a penalizaciones.

Piénsalo así. Si contratas a un nuevo contratista y le dices "rellena esta hoja de cálculo — necesito todos los campos completados", completará todos los campos. Algunas respuestas serán adivinanzas. Quiere parecer competente. Quiere parecer minucioso.

Ahora imagina decirle a ese mismo contratista: "Rellena lo que tengas seguro. Para todo lo demás, déjalo en blanco y dime por qué. Ah, y una cosa más — si encuentro una respuesta incorrecta, cuenta tres veces en tu contra comparado con un campo en blanco."

Comportamiento diferente. Inmediatamente. No porque el contratista se hizo más hábil. Sino porque la estructura de incentivos cambió de "recompensar completar" a "penalizar errores."

Eso es exactamente lo que pasa con el modelo. La formulación de penalización de -3 activa patrones de comportamiento conservador y orientado a la verificación. El modelo se vuelve notablemente más cauteloso con casos límite y datos ambiguos.

Cómo descubrí esta regla

No inventé este concepto — lo adapté de cómo incorporo a desarrolladores junior en proyectos de clientes.

Cuando un nuevo desarrollador se une a uno de mis proyectos, siempre le digo lo mismo durante la primera semana: "Si no estás seguro sobre un requisito, pregunta. No adivines y construyas lo incorrecto. Deshacer código incorrecto le cuesta al equipo tres veces más que la demora de hacer una pregunta." Todo líder de ingeniería experimentado dice alguna versión de esto. Funciona con humanos porque reenmarca "no lo sé" de una señal de incompetencia a una señal de profesionalismo.

Funciona con LLMs por la misma razón. La propia investigación de OpenAI sobre por qué los modelos alucinan señala exactamente esta dinámica — el entrenamiento actual incentiva adivinar con confianza sobre la incertidumbre honesta. El prompt de penalización -3 es una forma cruda pero efectiva de invertir ese incentivo en tiempo de inferencia, sin tocar los pesos del modelo.

Investigadores de la University of Maryland formalizaron esto a finales de 2025 con una técnica que llamaron "Reinforced Hesitation" — un enfoque de entrenamiento usando recompensas ternarias (+1 correcto, 0 abstención, -lambda por error). ¿El hallazgo? Los modelos entrenados con penalizaciones asimétricas produjeron comportamiento distinto a lo largo de lo que llamaron una "frontera de Pareto" — cada nivel de penalización produjo el modelo óptimo para su régimen de riesgo. Mi enfoque de prompting no es tan riguroso como reentrenar, pero empuja hacia el mismo cambio de comportamiento a nivel de prompt.

Combinando Regla 1 y Regla 2

Las Reglas 1 y 2 están diseñadas para apilarse. La Regla 1 da al modelo permiso para dejar campos en blanco. La Regla 2 le da motivación para preferir blanco sobre incorrecto.

Sin la Regla 1, el modelo no tiene opción de dejar en blanco — intenta responder todo. Sin la Regla 2, el modelo tiene la opción de dejar en blanco pero ninguna razón fuerte para usarla. Juntas, crean un sistema donde el modelo prefiere activamente la incertidumbre honesta sobre adivinar con confianza.

En la práctica, noté que la Regla 1 sola redujo los errores de extracción en aproximadamente un 60% en mis flujos de trabajo de contratos. Agregar la Regla 2 llevó eso a aproximadamente un 80%. Los errores restantes tienden a ser genuinamente difíciles — casos donde el lenguaje del documento es claro pero engañoso, o donde se requiere conocimiento del dominio para detectar el problema. Esos todavía necesitan revisión humana. Pero ¿80% de reducción de errores con dos líneas en un prompt? Eso es una ganancia enorme.

La siguiente regla maneja los casos límite restantes — y es la que convierte esto de un truco de prompting agradable en un sistema de auditoría listo para producción.

Regla 3: Atribución de fuente — La pista de auditoría que lo cambia todo

Las Reglas 1 y 2 manejan la decisión de "¿debo responder?". La Regla 3 maneja la pregunta de "¿cómo obtuve esta respuesta?".

La instrucción: Para cada valor extraído, agrega una columna indicando si el valor fue "extracted" (declarado directamente en el documento) o "inferred" (derivado de contexto, cálculo o interpretación). Si es inferred, exige una explicación de una oración de qué se infirió y de dónde.

Aquí está la adición al prompt:

For each field, include a "Source" column with one of two values:

EXTRACTED — The value appears verbatim or near-verbatim in the
source document. Include the page/section reference.

INFERRED — The value was derived from context, calculation, or
interpretation rather than directly stated. Include a one-sentence
explanation of what was inferred and the evidence used.

Examples:
- Total value: $847,500 | EXTRACTED | Page 3, Section 2.1
- Annual value: $423,750 | INFERRED | Calculated as total value
  ($847,500) divided by contract duration (2 years)
- Auto-renewal: Yes | INFERRED | Section 9.1 states "this agreement
  shall continue in effect unless terminated" — interpreted as
  auto-renewal language

Por qué importa la distinción Extracted/Inferred

Esta es la regla que hace el sistema auditable. Y la auditabilidad es lo que separa un "truco de IA genial" de algo en lo que realmente puedes confiar en un negocio.

Cuando cada campo viene etiquetado con su tipo de fuente, tu flujo de trabajo de revisión se vuelve quirúrgico. Así es como luce mi proceso de revisión actual con las tres reglas activas:

Paso 1: Escanea los campos EXTRACTED. Estos vinieron directamente del documento con referencias de página. Verifico por muestreo quizás el 10-15% de ellos. Los errores aquí son raros — el modelo es bueno en extracción literal cuando no se le pide que interprete.

Paso 2: Revisa cada campo INFERRED. Estos son donde el modelo hizo un juicio. Las explicaciones me dicen exactamente qué lógica usó, así puedo validar rápidamente si la inferencia es razonable. Toma 2-3 minutos para un contrato típico.

Paso 3: Revisa cada campo BLANK. Estos son los que el modelo pasó. Las explicaciones me dicen qué es ambiguo o faltante, así sé exactamente dónde buscar en el documento fuente. Toma otros 2-3 minutos.

Paso 4: Listo. Tiempo total de revisión: 8-12 minutos para un contrato que solía tomar 30+ minutos de verificación línea por línea.

La idea clave: en lugar de revisar todo, solo reviso campos en blanco e inferencias. Los campos EXTRACTED con referencias de página son verificables pero de bajo riesgo. El sistema se autoordena en niveles de confianza, y mi atención va donde más importa.

El beneficio oculto: Detectar respuestas "correctas pero inferidas"

Antes de la Regla 3, tenía un punto ciego del que ni siquiera sabía. El modelo a veces me daba la respuesta correcta — pero por la razón equivocada. "Extraía" un valor de contrato que en realidad estaba calculado a partir de partidas, o "extraía" una jurisdicción que en realidad estaba inferida de la dirección registrada de la empresa.

Estas respuestas parecían correctas. A menudo eran correctas. Pero eran frágiles. Si la suposición subyacente cambiaba — diferente estructura de partidas, empresa registrada en un estado diferente al de su dirección operativa — la inferencia fallaría silenciosamente.

La etiqueta INFERRED saca estos casos a la superficie. Cuando veo "INFERRED: Calculado de partidas en páginas 4-6," sé que debo verificar el cálculo. Cuando veo "INFERRED: Jurisdicción asumida de la dirección de registro de la empresa en Delaware," sé que debo verificar si el contrato especifica explícitamente la ley aplicable.

Esta es la diferencia entre una extracción que está correcta hoy y un proceso de extracción que es confiablemente correcto a lo largo del tiempo.

Un prompt completo combinando las tres reglas

Aquí está la plantilla de prompt completa que uso para la extracción de datos de contratos. La he refinado durante cinco meses y docenas de contratos:

You are extracting structured data from a legal document.
Follow these rules exactly:

RULE 1 — BLANK WHEN UNCERTAIN
If any field's value is ambiguous, missing, or if conflicting
information exists in the document, leave the field BLANK.
Provide a one-sentence explanation of why it was left blank.

RULE 2 — ERROR PENALTY
Scoring: Correct = +1, Blank with explanation = 0, Wrong = -3.
A wrong answer is three times worse than a blank. When in doubt,
leave it blank.

RULE 3 — SOURCE ATTRIBUTION
For each completed field, mark it as:
- EXTRACTED (value appears verbatim; cite page/section)
- INFERRED (value derived from context; explain the inference)

OUTPUT FORMAT:
| Field | Value | Source | Notes |
|-------|-------|--------|-------|
| Vendor | [value or BLANK] | EXTRACTED/INFERRED | [page ref or explanation] |

DOCUMENT:
[paste document here]

FIELDS TO EXTRACT:
1. Vendor legal name
2. Payment terms
3. Contract effective date
4. Contract end date
5. Total contract value
6. Currency
7. Renewal type (auto/manual/none)
8. Termination notice period
9. Governing law jurisdiction
10. Liability cap

Ese es todo el sistema. Sin fine-tuning. Sin bases de datos vectoriales. Sin entrenamiento de modelos personalizado. Tres reglas en un prompt que cambian fundamentalmente cómo la IA aborda la tarea de extracción.

Más allá de los contratos: Donde estas reglas realmente brillan

Empecé con contratos porque ahí fue donde el error de condiciones de pago me quemó. Pero estas tres reglas aplican a cualquier flujo de trabajo donde la IA extrae o resume información estructurada de fuentes no estructuradas. Las he desplegado en cuatro otros casos de uso, y los resultados han sido consistentes.

Elementos de acción de transcripciones de reuniones

Las transcripciones de reuniones son un campo minado para la extracción con IA. Las personas dicen cosas contradictorias. Asignan tareas verbalmente y luego las reasignan cinco minutos después. Referencian plazos informalmente — "intentemos tener eso listo para fin de semana" — lo que podría significar viernes, o podría significar "cuando sea."

Sin mis tres reglas, la IA generaba una lista limpia de elementos de acción con propietarios específicos y fechas para todo. Se veía genial. Frecuentemente se equivocaba sobre quién realmente era responsable de qué y cuándo vencían las cosas.

Con las reglas aplicadas:

Action item: Migrate staging database to new cluster
Owner: Sarah Chen | EXTRACTED | Timestamp 14:32 — "Sarah,
  can you handle the staging migration?"
Deadline: [BLANK]
  → No specific deadline stated. Jake mentioned "before the
    next sprint" at 22:15, but no date was confirmed.
Priority: High | INFERRED | Based on discussion context —
  team discussed this as blocking the release pipeline

El plazo en blanco es la respuesta correcta aquí. Un "viernes" o "fin del sprint" fabricado habría creado una expectativa falsa con la que nadie realmente estuvo de acuerdo.

Procesamiento de facturas

La extracción de facturas comparte los mismos modos de fallo que los contratos — nombres de proveedores que no coinciden exactamente con registros de órdenes de compra, cálculos de impuestos que deberían ser verificables, condiciones de pago que hacen referencia a un acuerdo marco en lugar de declararlas directamente.

La etiqueta INFERRED detecta algo específico en flujos de trabajo de facturas: campos calculados. Cuando la IA extrae un subtotal y un total, puede verificar si el cálculo de impuestos es internamente consistente. Cuando no puede reconciliar los números, lo marca:

Subtotal: $14,250.00 | EXTRACTED | Line items total, page 1
Tax (8.25%): $1,175.63 | EXTRACTED | Page 1, tax line
Total: $15,450.00 | EXTRACTED | Page 1, total line
Verification: [BLANK]
  → Calculated total ($14,250 + $1,175.63 = $15,425.63) does
    not match stated total ($15,450.00). Discrepancy of $24.37.

Esa discrepancia de $24.37 habría pasado por una extracción estándar. El sistema de tres reglas la detectó porque la Regla 3 forzó al modelo a mostrar su cálculo, y el cálculo no cuadraba.

Revisión de documentos legales

Los documentos legales son donde la etiqueta INFERRED demuestra su valor de manera más dramática. El lenguaje legal está lleno de implicaciones, referencias cruzadas y términos definidos que significan algo diferente de su significado común. "Esfuerzos razonables" tiene un peso legal diferente a "mejores esfuerzos." "Cambio adverso material" es un término definido en la mayoría de los acuerdos de M&A, pero la definición varía por contrato.

Cuando la IA marca algo como INFERRED en un contexto legal, está señalando exactamente los campos donde un abogado necesita opinar. La extracción maneja lo sencillo — nombres, fechas, montos — mientras etiqueta explícitamente los campos interpretativos para revisión experta.

Entrada de datos CRM y puntuación de proveedores

Los datos de CRM provenientes de correos electrónicos, formularios y notas de reuniones son notoriamente desordenados. Un prospecto dice que tiene "alrededor de 200 empleados" — ¿son 200? ¿Es 150-250? El trabajo de la IA es extraer los datos; mis tres reglas aseguran que no redondee silenciosamente a un número preciso que nunca fue declarado.

Company size: ~200 | INFERRED | Contact stated "around 200"
  in email dated March 3 — exact figure not confirmed
Annual revenue: [BLANK]
  → Revenue not disclosed. Contact mentioned "eight-figure
    range" in call notes but declined to specify.

Esa tilde y ese campo en blanco son honestos. Un CRM poblado con precisión fabricada es peor que uno con brechas honestas, porque los datos fabricados se usan para segmentación, scoring y pronósticos — y los errores se acumulan aguas abajo.

Si estás construyendo flujos de trabajo impulsados por IA para revisión de contratos, extracción de datos, o cualquiera de estos casos de uso, y prefieres que alguien configure el sistema completo de prompting e lo integre en tu pipeline, acepto este tipo de proyectos en Fiverr.

Lo que estas reglas no solucionan (y qué hacer al respecto)

Quiero ser honesto sobre las limitaciones, porque prometer de más es exactamente el tipo de problema del que trata este artículo entero.

Brechas de conocimiento del dominio

Las tres reglas ayudan con la ambigüedad y los datos faltantes. No ayudan cuando el modelo carece del conocimiento del dominio para reconocer que algo está mal. Si un contrato dice "condiciones de pago: net 30 desde fecha de factura" y el estándar de la industria para esa categoría de proveedor es net 60, el modelo extraerá alegremente "net 30" y lo marcará como EXTRACTED. No lo señalará como inusual porque no sabe qué es usual.

Para validación específica del dominio, todavía necesitas un experto humano o un conjunto de datos de referencia contra el cual el modelo pueda verificar. Las tres reglas hacen el trabajo del humano más rápido, pero no eliminan al humano.

Documentos deliberadamente engañosos

Si un documento está diseñado para engañar — ocultando términos contradictorios en apéndices, usando términos definidos que anulan el significado común — el modelo puede no detectarlo incluso con estas reglas. Las reglas ayudan con la ambigüedad accidental (que es el 90%+ de los errores de extracción del mundo real). No ayudan con la ofuscación intencional.

La tasa de error residual del 2-3%

Incluso con las tres reglas activas, todavía veo una pequeña tasa de error residual — aproximadamente 2-3% de los campos en lotes grandes. Estos tienden a ser casos donde el lenguaje del documento es claro e inequívoco, pero la IA lo interpreta diferente a como lo haría un humano debido a contexto sutil que le falta. Formatos de fecha poco comunes, abreviaciones específicas de la industria, o referencias a documentos externos a los que el modelo no tiene acceso.

Las reglas redujeron mi tasa de error de aproximadamente 12-15% (sin ninguna mitigación) a 2-3%. Esa es una mejora enorme. Pero no es cero. Planifica en consecuencia.

La selección de modelo sigue importando

He probado estas reglas con GPT-4o, Claude Sonnet 4, Claude Opus 4 y Gemini 2.0 Pro. Funcionan en todos, pero el comportamiento no es idéntico. Los modelos de Claude tienden a ser más conservadores con los campos en blanco — dejan más campos vacíos incluso cuando los datos son bastante claros. GPT-4o tiende a ser más agresivo infiriendo — marca cosas como INFERRED en lugar de BLANK en casos límite.

Actualmente uso Claude Sonnet 4 para la mayoría del trabajo de extracción. Alcanza el punto ideal entre costo, velocidad y cautela apropiada. Para contratos de alto riesgo donde quiero máxima precaución, paso a Opus 4. Si te interesa optimizar tu selección de modelos para diferentes tipos de tareas, escribí una guía detallada sobre arquitecturas de agentes optimizadas en costos que cubre exactamente esto.

El panorama general: Por qué este framework importa ahora

Un estudio multi-modelo de 2025 encontró que la mitigación simple basada en prompts redujo la tasa de hallucination de GPT-4o del 53% al 23%. Esa es una reducción significativa solo con cambios de prompt — sin cambios arquitectónicos, sin fine-tuning, sin RAG.

Mi sistema de tres reglas va más allá porque no solo le dice al modelo que "sea más preciso." Reestructura la tarea en sí. Al modelo no se le pide que se esfuerce más. Se le pide que haga un tipo de trabajo fundamentalmente diferente — clasificación (seguro versus incierto), atribución (extracted versus inferred), y explicación (¿por qué se dejó esto en blanco?). Estas son tareas que los LLM manejan bien, lo cual explica por qué las tasas de error caen tan dramáticamente.

Esto es lo que creo que está pasando a un nivel más profundo. El comportamiento predeterminado de estos modelos — adivinar con confianza, completar cada campo, nunca decir "no sé" — viene de su entrenamiento. Como explica el artículo de Science sobre los orígenes de las hallucinations, los LLM esencialmente se entrenan en un examen donde las respuestas en blanco puntúan cero. Adivinar es siempre la estrategia racional.

Mis tres reglas crean un examen diferente. Uno donde las respuestas en blanco puntúan cero (neutral), pero las respuestas incorrectas puntúan -3 (activamente malo). Esa es la penalización asimétrica que los investigadores de Reinforced Hesitation en Maryland encontraron que cambia el comportamiento del modelo a nivel de entrenamiento. Estoy aplicando la misma lógica a nivel de prompt, y funciona — imperfectamente, menos rigurosamente, pero de manera práctica e inmediata.

¿La parte emocionante? Anthropic, OpenAI y Google están investigando activamente el entrenamiento consciente de calibración — construyendo el equivalente de estas reglas directamente en los pesos del modelo. Pero eso es un programa de investigación de varios años. Mis tres reglas funcionan hoy, en producción, ahora mismo.

Y honestamente, incluso cuando los modelos mejoren en la autocalibración de forma nativa, probablemente seguiré usando reglas de prompting explícitas. Cinturón y tirantes. El costo de una extracción incorrecta en un contexto empresarial — una factura pagada con el monto equivocado, un término de contrato omitido, un campo de cumplimiento sin verificar — siempre es mayor que el costo de ser ligeramente precavido.

Cómo implementar esto en tu flujo de trabajo mañana

Si has llegado hasta aquí, ya entiendes el framework. Aquí está el camino de implementación práctico que seguiría si empezara desde cero hoy.

Paso 1: Elige un flujo de trabajo de extracción

No intentes renovar todo de una vez. Elige el flujo de trabajo donde las salidas incorrectas de IA han causado más dolor. Para la mayoría, eso es uno de: revisión de contratos, procesamiento de facturas, elementos de acción de reuniones, o entrada de datos CRM.

Paso 2: Escribe tu plantilla de prompt

Comienza con mi plantilla de contratos de arriba y modifícala para tu caso de uso. Las tres reglas permanecen iguales — blanco cuando hay incertidumbre, penalización de -3 por errores, atribución extracted/inferred. Lo que cambia es la lista de campos y el formato de salida.

Paso 3: Ejecuta 10 documentos con y sin las reglas

Así es como validé el enfoque. Procesé 10 contratos con extracción estándar (sin reglas) y 10 con el sistema de tres reglas, luego verifiqué manualmente cada campo. La extracción estándar tuvo 14 errores en 10 documentos. La extracción con tres reglas tuvo 3 errores — y los tres estaban en la categoría residual (lenguaje claro, interpretación errónea sutil).

Paso 4: Calibra el umbral de campos en blanco

Diferentes modelos tienen diferentes sensibilidades para dejar campos en blanco. Si tu modelo está dejando demasiados campos en blanco (más del 20% en documentos limpios), puede que necesites suavizar el lenguaje ligeramente: "Deja en blanco solo cuando genuinamente no puedas determinar el valor con confianza razonable." Si todavía está adivinando demasiado agresivamente, ajústalo: "Ante la más mínima duda, prefiere blanco sobre una adivinanza."

Paso 5: Construye el flujo de trabajo de revisión alrededor de la salida

Todo el punto de estas reglas es cambiar cómo revisas la salida de IA. Entrena a tu equipo (o a ti mismo) para seguir la revisión de tres niveles: muestreo de EXTRACTED, revisión de todos los INFERRED, investigación de todos los BLANK. Una vez que este flujo de trabajo se vuelve hábito, el ahorro de tiempo es permanente.

Consejo profesional: Versiona tus prompts

Mantengo cada plantilla de prompt en un archivo markdown con control de versiones. Cuando ajusto la redacción — modificando la sensibilidad de campos en blanco, agregando nuevos campos, cambiando el formato de salida — hago commit del cambio con una nota de por qué. En tres meses, cuando te preguntes por qué cambiaste "ambiguo" por "poco claro" en la regla de campos en blanco, te lo agradecerás.

La pregunta que nadie hace hasta que es demasiado tarde

Pasé el primer año trabajando con IA bajo una suposición fundamentalmente errónea: que la precisión era la métrica que importaba. Lograr que el modelo produzca más respuestas correctas. Fine-tunear para precisión. Optimizar para la respuesta correcta.

Ese incidente con el contrato me enseñó que la verdadera métrica no es la precisión. Es la confiabilidad. Un sistema que es 98% preciso pero no te da forma de identificar el 2% que está mal es menos útil que un sistema que es 95% preciso pero marca claramente cada salida incierta.

Mis tres reglas no hacen la IA más precisa (aunque lo hacen, como efecto secundario). Hacen la IA más confiable. Crean un sistema donde sabes exactamente sobre qué tiene confianza el modelo, qué infirió y qué no pudo determinar. Esa transparencia transforma la IA de una caja negra que tienes que verificar completamente en un colaborador cuyo trabajo puedes auditar eficientemente.

La pregunta que te dejo: ahora mismo, hoy, en cualquier flujo de trabajo de IA que estés ejecutando — ¿sabes cuáles salidas de tu modelo son seguras y cuáles fueron adivinadas?

Porque si no puedes notar la diferencia, estás en la misma posición en la que yo estaba antes de que ese contrato explotara. Simplemente no has encontrado tus condiciones de pago incorrectas todavía.

Preguntas frecuentes

¿Funcionan estas reglas de prompting con todos los modelos de IA?

Sí — las he probado con GPT-4o, Claude Sonnet 4, Claude Opus 4 y Gemini 2.0 Pro con resultados consistentes. Los modelos de Claude tienden a dejar más campos en blanco de manera conservadora mientras que GPT-4o infiere más agresivamente. Ajusta el lenguaje del umbral de campos en blanco para calibrar según tu modelo preferido.

¿Cuánto reducen estas reglas la hallucination de IA en la extracción de datos?

En mis flujos de trabajo de revisión de contratos, el sistema de tres reglas redujo los errores de extracción de aproximadamente 12-15% a 2-3% — aproximadamente 80% de reducción de errores. Un estudio multi-modelo de 2025 encontró que la mitigación basada en prompts sola redujo la hallucination de GPT-4o del 53% al 23%. Los resultados varían según la complejidad del documento y la elección del modelo.

¿Puedo usar estas reglas para tareas más allá de la extracción de documentos?

El framework aplica a cualquier flujo de trabajo donde la IA procesa entrada no estructurada en salida estructurada — transcripciones de reuniones, procesamiento de facturas, entrada de datos CRM, revisión legal y puntuación de proveedores. Las tres reglas (blanco ante incertidumbre, penalización por error, atribución de fuente) se traducen directamente. Ajusta la lista de campos y el formato de salida para tu caso de uso.

¿La puntuación de penalización de -3 realmente afecta el comportamiento del modelo de IA?

Sí, de manera medible. Los modelos de lenguaje han internalizado estructuras de incentivos de los datos de entrenamiento. Enmarcar costos asimétricos en el prompt activa patrones de comportamiento conservador y orientado a la verificación. Investigadores de la University of Maryland formalizaron este concepto como "Reinforced Hesitation" a finales de 2025, confirmando que las penalizaciones asimétricas desplazan el comportamiento del modelo a lo largo de una frontera de riesgo-precisión.

¿Cuánto tiempo toma revisar la salida de IA con estas tres reglas?

Mi tiempo de revisión de contratos bajó de 25-35 minutos (verificando cada campo) a 8-12 minutos (muestreando campos extracted, revisando campos inferred y en blanco). El flujo de trabajo de revisión de tres niveles — escanear extracted, verificar inferred, investigar blank — elimina la necesidad de releer documentos fuente línea por línea.

Trabajemos juntos

¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudar.

• Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise solutions): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security services): xcybersecurity.io