Lo que todavía falla

Las primeras críticas a la IA generativa se concentraron en la alucinación.

El modelo podía inventar un dato, una referencia, una sentencia o una explicación plausible. La respuesta parecía segura precisamente porque el sistema estaba diseñado para continuar con fluidez.

Ese problema no ha desaparecido. Los modelos más recientes reducen errores en muchas tareas, pero incluso sus propios desarrolladores reconocen que las alucinaciones siguen siendo una dificultad fundamental. Parte del problema procede de una estructura de incentivos que premia acertar y, en determinadas evaluaciones, puede favorecer la conjetura frente al reconocimiento explícito de incertidumbre.[^7]

Sin embargo, cuando la IA deja de limitarse a contestar y empieza a recuperar información, utilizar herramientas y actuar, la alucinación ya no describe todo el riesgo.

Una respuesta falsa es un error de contenido.

Un agente puede cometer errores de trayectoria.

Puede partir de una fuente correcta y elegir la acción equivocada. Puede ejecutar bien un paso innecesario. Puede interpretar un error de herramienta como éxito. Puede conservar en memoria una instrucción contaminada. Puede completar una tarea formalmente y dejar sin resolver el problema real.

La pregunta ya no es solo «¿es verdad lo que ha dicho?».

También debemos preguntar:

¿estaba trabajando sobre la unidad correcta?;
¿recuperó la fuente vigente?;
¿tenía autoridad?;
¿la herramienta respondió realmente?;
¿la acción produjo el efecto esperado?;
¿el sistema debía continuar?;
¿qué quedó inscrito después?;
¿y quién puede reconstruir lo ocurrido?

Una anatomía del fallo

Los fallos de un sistema generativo conectado pueden agruparse en diez familias. Se relacionan entre sí, pero conviene distinguirlas porque requieren controles diferentes.

1. Alucinación factual

El modelo produce una afirmación plausible que no está sustentada.

Puede inventar:

un hecho;
una cita;
una norma;
una fecha;
una persona;
un precedente;
una función técnica;
o una relación causal.

La fluidez agrava el problema porque la forma lingüística no señala necesariamente el grado de certeza.

La respuesta madura no consiste en confiar más en el modelo ni en prohibir toda generación. Consiste en separar estatutos:

hecho confirmado;
fuente recuperada;
inferencia;
hipótesis;
posibilidad;
y desconocimiento.

Una arquitectura que obliga a citar fuentes puede reducir el riesgo, pero no lo elimina. La cita puede ser incorrecta, irrelevante o no sostener la afirmación exacta.

La verificación sigue siendo una operación propia.

2. Fallo de recuperación

El sistema dispone de la fuente correcta, pero no la recupera.

Puede ocurrir porque:

el documento no fue indexado;
el OCR o la extracción fallaron;
el fragmento perdió contexto;
la consulta no coincidió semánticamente;
una versión antigua recibió mayor puntuación;
o el modelo respondió sin utilizar el resultado recuperado.

Este fallo es especialmente peligroso porque el sistema parece estar «conectado a la documentación». La existencia de un RAG puede generar una confianza que la recuperación concreta no merece.

Por eso una respuesta documental debería poder mostrar:

qué buscó;
qué encontró;
qué fragmentos utilizó;
qué documento representa cada fragmento;
y qué información relevante no pudo localizar.

3. Saturación y desorganización del contexto

Más contexto puede ayudar. También puede degradar.

El modelo debe decidir qué partes pesan en cada generación. Si la evidencia relevante queda enterrada entre duplicados, conversaciones y versiones incompatibles, su mera presencia no garantiza influencia.

Los estudios sobre contexto largo han mostrado degradaciones relacionadas con la posición y una utilización imperfecta de la información intermedia.[^5] Los modelos han mejorado desde aquellas primeras evaluaciones, pero la conclusión de diseño permanece: una ventana grande no sustituye la selección, la jerarquía y la estructura.

El fallo puede manifestarse como:

olvido de una restricción;
confusión entre asuntos;
pérdida de una excepción;
predominio de la información más reciente;
o síntesis que elimina precisamente la diferencia decisiva.

4. Pulsión de completitud

La pulsión de completitud fue identificada en SIMBIOS antes de convertirse en una preocupación general de ingeniería.

El modelo está orientado a producir una continuación. Cuando recibe una estructura incompleta, tiende a cerrarla.

Esa capacidad permite:

terminar un texto;
proponer una arquitectura;
reconstruir una secuencia;
o completar un plan.

Pero también puede:

inventar el puente que falta;
convertir una correlación en explicación;
resolver una ambigüedad sin evidencia;
declarar que una tarea ha terminado;
o cerrar una investigación en la primera forma coherente.

La completitud no es un error ocasional. Es una propiedad productiva que necesita corte.

Un sistema robusto debe contener espacios formales para:

«no consta»;
«no puedo determinarlo»;
«hay dos hipótesis»;
«falta fuente»;
«requiere decisión humana»;
y «debe detenerse».

5. Error de herramienta

Una herramienta puede fallar de múltiples maneras:

devolver un error explícito;
devolver datos vacíos;
producir un resultado parcial;
responder con latencia;
cambiar de formato;
ejecutar una acción distinta;
o completar técnicamente sin producir el efecto esperado.

El agente puede no interpretar correctamente ese fallo.

Por ejemplo, una operación de carga puede devolver un identificador aunque el documento quede en una ubicación incorrecta. Un correo puede aparecer como enviado cuando sigue en borradores. Un test puede pasar porque no cubre el caso relevante. Una consulta puede devolver cero resultados por un problema de permisos y no porque la información no exista.

La regla debe ser:

La respuesta de una herramienta es evidencia sobre la ejecución, no prueba automática del resultado.

La verificación puede exigir una segunda lectura del estado, un control independiente o una confirmación humana.

6. Contaminación de memoria y estado

La memoria persistente convierte un error local en una posibilidad de error recurrente.

Puede contaminarse por:

una clasificación equivocada;
una decisión provisional guardada como permanente;
una instrucción externa maliciosa;
un resultado de herramienta incompleto;
una identidad confundida;
o una corrección que no se propagó.

La memoria puede además omitir actuaciones importantes. Si un sistema conserva la respuesta del modelo pero no la llamada a herramienta y su resultado, pierde precisamente la evidencia que permitiría reconstruir la decisión.

Por eso el registro no debe limitarse al texto final. Debe conservar, según el riesgo:

entradas relevantes;
herramientas usadas;
resultados;
cambios de estado;
aprobaciones;
versiones;
y excepciones.

Recordar más no siempre mejora el sistema. A veces amplía la superficie temporal de ataque y error.

7. Inyección de instrucciones

Cuando un agente consulta contenido externo, ese contenido puede incluir instrucciones diseñadas para manipularlo.

Una página web, un archivo, un correo o un comentario pueden intentar que el sistema ignore el mandato, revele información o ejecute una acción no solicitada.

Los ataques más eficaces ya no se parecen necesariamente a una frase explícita como «ignora las instrucciones anteriores». Pueden adoptar la forma de ingeniería social contextual: contenido que parece legítimo, introduce urgencia, simula autoridad o convence al agente de que una acción forma parte del objetivo.[^8]

No basta con filtrar cadenas maliciosas.

Hace falta limitar el radio de daño:

separar lectura de ejecución;
aplicar mínimos privilegios;
restringir red y escritura;
aislar entornos;
confirmar transiciones de riesgo;
y evitar que contenido recuperado adquiera autoridad sobre el mandato.

Aquí vuelve a aparecer la integración sin absorción. El contenido externo es una fuente. No debe convertirse silenciosamente en una instrucción del sistema.

8. Fatiga de aprobación

La solución intuitiva a los riesgos agentivos es pedir permiso a la persona antes de cada acción.

Sobre el papel, el humano conserva control.

En la práctica, una secuencia continua de avisos puede producir aprobación automática. Anthropic informó en 2026 de que los usuarios de Claude Code aprobaban aproximadamente el 93 % de los prompts de permiso, y utilizó ese dato para explicar por qué la supervisión paso a paso puede degradarse por fatiga.[^9]

La presencia humana no puede reducirse a hacer clic.

Las aprobaciones deben situarse en puntos con significado:

antes de comunicar externamente;
antes de modificar una fuente canónica;
antes de ejecutar una operación irreversible;
antes de asumir un coste relevante;
o cuando aparece una incertidumbre que modifica el riesgo.

El resto debe gobernarse mediante entornos, permisos y verificaciones automáticas.

La autoridad humana es más efectiva cuando decide transiciones que cuando vigila cada microacción.

9. Deriva y exceso de agencia

Un agente puede empezar correctamente y desviarse a medida que avanza.

La deriva puede aparecer porque:

interpreta mal un resultado intermedio;
añade un objetivo implícito;
optimiza una métrica local;
intenta reparar un error creando otros cambios;
o continúa explorando después de haber alcanzado una forma suficiente.

Los sistemas más capaces pueden sostener tareas más largas, pero eso no significa que mantengan una trayectoria fiable en cualquier entorno. Las evaluaciones de horizonte de tareas miden éxito sobre conjuntos de trabajos de software relativamente definidos y advierten sobre los límites de extrapolar resultados a tareas abiertas, desordenadas o por encima de la saturación del benchmark.[^10]

La autonomía útil no es la máxima duración sin intervención.

Es la capacidad de mantener una dirección bajo límites, reconocer cuándo falta contexto y detenerse antes de convertir una desviación en resultado.

10. Desplazamiento del cuello de botella

La IA puede acelerar una etapa y empeorar el sistema completo.

Si genera más código, documentos, investigaciones o propuestas, alguien debe:

revisar;
probar;
decidir;
integrar;
mantener;
y responder.

Un estudio longitudinal de 2026 sobre una empresa tecnológica encontró que el volumen de pull requests por desarrollador llegó a duplicarse, mientras la carga por revisor también se duplicó y la revisión automatizada pasó a ocupar un lugar central. Los autores fueron cuidadosos con la atribución causal, pero el caso ilustra una regularidad importante: aumentar producción desplaza el límite hacia verificación e integración.[^11]

Un sistema puede parecer más productivo porque genera más unidades, mientras acumula deuda de revisión.

La capacidad ampliada no se mide solo por output.

Debe incluir la capacidad de absorber, verificar y convertir ese output en resultados sostenibles.

Del error de respuesta al error de forma

Estas diez familias muestran una evolución.

En el chat aislado, el riesgo principal era una respuesta falsa o mediocre.

En el sistema conectado, el riesgo puede estar en la forma completa:

fuente mal jerarquizada;
memoria contaminada;
permiso excesivo;
aprobación vacía;
herramienta no verificada;
o cierre incorrecto.

Por eso mejorar el modelo no basta.

Un modelo más capaz puede reducir errores locales y, al mismo tiempo, aumentar el alcance de los errores que conserva. Cuando solo redacta un párrafo, una alucinación exige corrección. Cuando modifica archivos, comunica, compra o actualiza un registro, la misma confusión puede producir una consecuencia.

La seguridad debe crecer con la capacidad.

La escalera de control

No todos los usos necesitan la misma arquitectura. Una forma práctica de diseñar controles consiste en ordenar la operación por impacto.

Nivel 1 · Generación reversible

Ejemplos: ideas, esquemas, borradores privados.

Controles:

revisión ordinaria;
separación de hechos e inferencias;
no publicación automática.

Nivel 2 · Recuperación y análisis

Ejemplos: consulta documental, comparación, resumen de expedientes.

Controles:

identidad de fuentes;
citación;
versiones;
registro de documentos utilizados;
reconocimiento de ausencia.

Nivel 3 · Producción estructurada

Ejemplos: informes, contratos, código, bases de conocimiento.

Controles:

schemas;
tests;
checklists;
revisión por riesgo;
trazabilidad de cambios.

Nivel 4 · Acción interna reversible

Ejemplos: crear borradores, actualizar staging, clasificar, mover archivos dentro de un área controlada.

Controles:

sandbox o entorno limitado;
permisos mínimos;
logs;
rollback;
confirmación por muestreo o excepción.

Nivel 5 · Acción externa o irreversible

Ejemplos: enviar, publicar, firmar, pagar, borrar, presentar, decidir sobre derechos o recursos.

Controles:

autoridad explícita;
doble verificación cuando proceda;
aprobación situada;
evidencia conservada;
límites de cuantía o alcance;
plan de incidente.

La autonomía debe ajustarse al nivel de consecuencia, no a la espectacularidad de la demostración.

Nueve órganos de una arquitectura fiable

Un sistema no elimina el error. Puede convertirlo en una diferencia detectable, limitada y reparable.

Para ello necesita nueve órganos.

1. Separación de estatutos

Hechos, fuentes, inferencias, hipótesis y decisiones no deben aparecer como una misma clase de texto.

2. Procedencia

Toda información relevante debe poder volver a su fuente.

3. Verificación independiente

El mismo modelo que genera no debería ser la única instancia que certifica su propia salida. Puede utilizarse otro método, otro agente, una prueba o una persona.

4. Entorno acotado

La capacidad de actuar debe estar contenida por diseño: workspace, sandbox, rama, permisos y límites de red.

5. Autoridad situada

Las decisiones deben quedar asignadas a quien puede asumirlas y responder por ellas.

6. Parada

El sistema debe saber cuándo no continuar.

7. Rollback y reparación

Una actuación reversible reduce el coste del error. Cuando no puede revertirse, la puerta de decisión debe ser más fuerte.

8. Observabilidad

No basta con saber el resultado. Debe poder reconstruirse la trayectoria suficiente para comprender un incidente.

9. Aprendizaje

El error relevante debe modificar el sistema: una regla, una prueba, una memoria, un permiso, una herramienta o una formación.

Sin aprendizaje, la organización corrige casos. No desarrolla capacidad.

La autoridad del corte

La inteligencia generativa tiene una competencia extraordinaria para abrir y completar.

La inteligencia humana aporta, entre otras funciones, la capacidad de reconocer que una posibilidad no debe realizarse.

Eso no significa que el humano siempre tenga razón ni que la IA deba limitarse a obedecer. Significa que una integración responsable necesita una función de corte con autoridad.

El corte puede decir:

esta fuente no entra;
este argumento no se sostiene;
esta acción excede el mandato;
esta memoria debe retirarse;
este agente ha perdido dirección;
este resultado no está verificado;
o este proceso debe volver a una etapa anterior.

La tercera inteligencia no aparece cuando la IA actúa sin fricción.

Aparece cuando la relación puede producir, contradecir, verificar, detener y aprender sin que ninguna de esas funciones absorba a las demás.

El error que revela la forma

Un fallo bien leído puede mostrar más que un éxito.

Si el agente inventa una referencia, revela una ausencia de procedencia. Si repite una acción, revela un fallo de memoria. Si continúa después de completar, revela un fallo de cierre. Si la persona aprueba sin leer, revela un diseño equivocado de autoridad. Si la organización produce más pero tarda lo mismo en entregar, revela un desplazamiento del cuello de botella.

El error no debe utilizarse para concluir que la IA «no sirve» ni para justificar una confianza ciega cuando el rendimiento mejora.

Debe utilizarse para localizar la diferencia estructural que falta.

Esa lectura nos lleva al último capítulo de esta parte.

Muchas organizaciones conocen ya estos riesgos, disponen de modelos potentes y acumulan pilotos. Sin embargo, los beneficios siguen siendo desiguales.

El problema no está únicamente en los fallos del modelo.

Está en la forma empresarial que lo recibe.