Su equipo trabaja bien con inteligencia artificial. Le encarga análisis, le pide borradores, revisa lo que produce y corrige lo que no encaja. Y aun así hay una escena que se repite: la sesión de ayer terminó en un punto exacto —tres cosas resueltas, una descartada por un motivo concreto, una a medias— y la de hoy empieza en blanco.
La reacción natural es intentar que no olvide: alargar la conversación, arrastrarlo todo dentro, no cerrar nunca. Es exactamente la decisión que empeora el resultado, y conviene ver por qué antes de hablar de ninguna solución.
La conversación larga no sale gratis: el resultado se degrada
Un modelo de lenguaje responde a partir de todo lo que tiene delante en ese momento: sus instrucciones permanentes, los documentos que ha leído y la conversación entera hasta ese punto. A ese conjunto se lo llama contexto. Y lo que está medido —no supuesto— es que el contexto no se aprovecha por igual según cuánto ocupe y dónde esté cada cosa.
Tres resultados publicados, que conviene tener a mano cuando alguien proponga «meterlo todo en el mismo hilo»:
- Lo del medio se pierde. El rendimiento es más alto cuando la información relevante está al principio o al final del contexto, y se degrada de forma significativa cuando el modelo debe acceder a información situada en la mitad de contextos largos (Fuente: Liu et al., «Lost in the Middle», Transactions of the ACL, vol. 12, 2024). Es una curva en U: lo que quedó a mitad de una conversación larga es lo más difícil de recuperar.
- Cuanto más largo, peor razona. En una evaluación diseñada para exigir deducción —no localizar una frase literal—, al llegar a 32.000 tokens (la unidad en que el modelo cuenta el texto, aproximadamente trozos de palabra) 11 de los 13 modelos evaluados rinden por debajo de la mitad de su nivel con textos cortos (Fuente: Modarressi et al., «NoLiMa», ICML 2025).
- La degradación no espera a las tareas difíciles. Sobre 18 modelos: «no usan su contexto de manera uniforme; su rendimiento se vuelve cada vez menos fiable conforme crece la entrada», y ocurre incluso en tareas sencillas, de forma no uniforme (Fuente: Hong, Troynikov y Huber, «Context Rot», Chroma, 2025).
Lo relevante para quien decide no es la cifra: es la forma del fallo. El modelo no devuelve un error ni avisa de que ha dejado de tener en cuenta algo. Sigue respondiendo con el mismo tono seguro, y el dato que se perdió a mitad de la conversación no reaparece con una advertencia — simplemente no está en la respuesta. Un resultado degradado se parece mucho a un resultado bueno hasta que alguien lo comprueba contra la fuente.
Por qué ocurre, en dos frases
No es un defecto de una herramienta concreta ni algo que se arregle con la versión siguiente. Son dos causas estructurales:
La atención es un presupuesto. Cada pieza del texto puede relacionarse con todas las demás: para n piezas hay n² relaciones posibles, de modo que al duplicar el texto no se duplican las relaciones a atender, se cuadruplican. La capacidad del modelo de capturar esas relaciones «se estira y se diluye» (Fuente: Anthropic, «Effective context engineering for AI agents», 2025). Y cómo se entrenó: los modelos aprendieron sobre datos donde las secuencias cortas son mucho más frecuentes que las largas, y tienen menos experiencia con dependencias que cruzan un contexto entero ([Fuente: Anthropic, 2025, misma URL]).
De ahí se sigue algo que ahorra dinero saber: contratar un modelo con una ventana de contexto más grande amplía el espacio disponible, no el presupuesto de atención que se reparte dentro de él. El límite que importa no es cuánto cabe; es cuánto se atiende bien.
Administrar eso tiene nombre: ingeniería de contexto
Si la calidad de la respuesta depende de qué hay delante del modelo cuando responde, entonces esa composición deja de ser un accidente y pasa a ser una decisión. Esa decisión, tomada a propósito y de forma sistemática, es lo que se llama ingeniería de contexto (context engineering): el conjunto de estrategias para seleccionar y mantener la información óptima mientras el modelo trabaja, incluida toda la que llega ahí sin que usted la haya escrito — documentos que el sistema decidió leer, herramientas conectadas, el historial completo de la conversación ([Fuente: Anthropic, 2025, misma URL]). No es lo mismo que la ingeniería de instrucciones (prompt engineering), que se ocupa de cómo se formula la pregunta.
El principio rector, en la formulación de quien construye estos sistemas, es contraintuitivo para quien lleva años oyendo que a la IA hay que darle «todo el contexto posible»: dar al modelo el conjunto más pequeño posible de información de alta señal que maximice la probabilidad del resultado buscado ([Fuente: Anthropic, 2025, misma URL]).
Dicho en términos de gestión: la calidad de una respuesta se decide antes de la pregunta. Y eso es, exactamente, lo que aprende una persona formada de verdad en esta herramienta. No escribe preguntas más ingeniosas: decide qué tiene el sistema delante cuando pregunta —qué documentos, qué historial, qué reglas— y mantiene ese conjunto pequeño y limpio. Es la diferencia entre un usuario avanzado y uno ocasional, y no se adquiere leyendo un manual: se adquiere trabajando con alguien que ya administra su contexto así.
El cierre escrito: la pieza que hace posible trabajar corto
Aquí es donde vuelve la escena del principio. Si la sesión corta y limpia es donde el modelo rinde mejor, hay que poder cerrar. Y cerrar sin perder el hilo exige que algo transporte el estado del trabajo de una sesión a la siguiente. La conversación no puede: es justo lo que hay que soltar. Un archivo, sí.
El mecanismo es corto de describir. Antes de terminar, la sesión deja escritas tres cosas: qué se cerró de verdad, qué queda abierto y con qué arranca la siguiente. La sesión del día siguiente empieza leyendo eso, y solo eso — información de alta señal, sin el historial completo detrás.
Lo que cuesta no es el archivo: es saber qué merece entrar en él. Dos decisiones concentran casi todo el valor, y son las que ningún automatismo toma:
- Reconciliar lo cerrado contra el resto de la lista. Lo que se resolvió hoy en un sitio suele estar pedido en dos más, con otras palabras. Si no se cruza en el momento, la lista sigue reclamando durante semanas algo que ya está hecho — y una lista que miente se abandona.
- Cazar los cabos sueltos. El criterio que se acordó de palabra, el documento nuevo que nadie apuntó donde se busca, el material ya consumido que mañana se releería como pendiente. Es la última hora en la que ese conocimiento existe.
Hay tres reglas más que impiden que el cuaderno degenere en un diario, y van con el sistema. Pero la parte que no se automatiza es la de arriba: advertir lo que falta. Una ausencia, por definición, no está escrita en ninguna parte; solo la ve quien tiene el trabajo entero delante, y solo mientras lo tiene delante.
Lo que gana la empresa, no solo la persona
Hasta aquí el beneficio parece individual: mejores respuestas para quien trabaja. El que importa está un paso más allá.
Cuando el cierre es una práctica y no una virtud personal, el estado del proyecto sale de una cabeza y entra en un archivo que la empresa conserva. Quien retoma el trabajo tras una semana fuera empieza leyendo en vez de reconstruir; un relevo o una baja dejan de ser un agujero; y quien se incorpora no depende de que otra persona tenga tiempo de contarle el proyecto.
También cambia lo que queda cuando termina un proveedor. Un sistema entregado sin su historia es un sistema mudo: funciona hasta que hay que cambiarlo, y entonces nadie sabe por qué está hecho así. En nuestro método el registro de cómo se construyó forma parte de lo entregado, por la misma razón por la que el departamento se construye con la gente del cliente y no delante de ella: la construcción es la formación, y ese registro es lo que la sostiene cuando nosotros ya no estamos.
Conviene además no confundir dos piezas que se parecen. Las reglas que el sistema obedece fijan el criterio permanente —lo que vale para todos los casos, y se carga en cada sesión— y el cierre fija el estado, que cambia cada día. Juntas son lo que hace que un negocio sea operable por IA: descrito de forma que un sistema pueda leerlo y actuar sobre él sin una persona traduciendo en cada paso.
De dónde sale esto
En nuestras formaciones la ingeniería de contexto no se explica en una diapositiva: se practica. La persona ve el contexto llenarse mientras trabaja, aprende a leer cuándo conviene cerrar, escribe su propio cierre sobre su trabajo real y lo ejecuta antes de terminar el día.
Y el sistema que se instala no es un ejercicio didáctico: es el que sostiene nuestro proyecto interno de mayor volumen, afinado a lo largo de meses de uso diario y reducido después a lo que un equipo necesita. Lo que se transfiere no es el archivo —un archivo se copia en un minuto—: es el criterio de qué merece quedar escrito, que es la parte que tardó meses en ganarse.
El viento de cola: la norma pide el mismo artefacto
Para los sistemas que la ley europea considera de alto riesgo, esto deja de ser una buena práctica. El reglamento exige a quien los provee un sistema de gestión de la calidad documentado por escrito que incluya, entre sus trece aspectos, «sistemas y procedimientos de registro de toda la documentación e información pertinentes» (Fuente: Reglamento (UE) 2024/1689, art. 17(1)(k), EUR-Lex, 2024).
Si su sistema no está en esa categoría, la obligación no le alcanza. El artefacto, en cambio, es el mismo — y quien ya trabaja así no tiene que construirlo el día que alguien se lo pida.
La pregunta para llevarse
No es qué modelo ha contratado. Es qué tiene ese modelo delante cuando su gente le pregunta — y quién decide eso: alguien, a propósito, o la inercia de una conversación que lleva tres semanas abierta. La diferencia entre esas dos situaciones no se ve en la respuesta, porque las dos suenan igual de seguras. Se ve al comprobarlas.