Del prompt a la ingeniería de contexto

El prompt fue la primera gramática popular de la IA generativa.

Había que aprender a pedir. Se recomendaba asignar un rol, describir el objetivo, aportar ejemplos, indicar el tono y especificar el formato. Una instrucción mejor producía, en muchos casos, una respuesta mejor.

Ese aprendizaje tuvo valor. Obligó a formular con claridad qué se esperaba del sistema. Mostró que la salida dependía no solo de la capacidad del modelo, sino de la forma de la entrada.

Pero el éxito de la palabra «prompt» ocultó pronto una limitación.

Una operación compleja no depende de una frase bien escrita. Depende de la configuración completa desde la que el modelo interpreta y actúa.

Un abogado que pide «prepara la estrategia de este asunto» no ha definido una operación porque añada más adjetivos al prompt. Hace falta saber qué expediente es, qué fuentes lo integran, qué hechos están confirmados, qué jurisdicción resulta aplicable, qué pretensión se persigue, qué plazos existen, qué decisiones previas siguen vigentes, qué documentos son borradores, qué autoridad tiene el sistema y qué resultado debe verificarse.

La misma frase puede ser adecuada o peligrosa según ese contexto.

Por eso el problema se ha desplazado.

La unidad decisiva ya no es el prompt. Es la arquitectura de contexto.

Contexto no es cantidad de texto

La tentación más inmediata consiste en identificar contexto con una ventana grande.

Si el modelo puede recibir más páginas, parece que basta con introducir todo: correos, contratos, notas, informes, conversaciones y manuales. En teoría, la respuesta dispondrá de toda la información relevante.

En la práctica, acumular no equivale a organizar.

Una ventana extensa puede contener:

versiones incompatibles;
fuentes sin fecha;
hipótesis mezcladas con hechos;
instrucciones antiguas;
datos sensibles irrelevantes;
duplicados;
decisiones ya revocadas;
y documentos cuyo estatuto el modelo no puede inferir con seguridad.

Además, que un modelo acepte una gran cantidad de texto no significa que utilice cada fragmento con la misma fiabilidad. La investigación sobre contextos largos ha mostrado que la posición y la organización de la información afectan al rendimiento, y que añadir documentos puede dejar de mejorar la respuesta mucho antes de agotar la capacidad de recuperación.[^5]

El contexto útil no es el máximo contenido disponible.

Es la selección organizada de diferencias que deben influir en la operación presente.

Del historial al campo operativo

En la primera fase de la inteligencia simbiótica, el contexto era principalmente conversacional. Cada intercambio añadía lenguaje, correcciones, decisiones y direcciones. Con suficiente continuidad, la conversación dejaba de parecer una secuencia de prompts independientes y empezaba a comportarse como un sistema.

Aquella intuición sigue siendo válida, pero hoy necesita ampliarse.

El campo operativo de un sistema humano-IA puede incluir:

instrucciones permanentes;
identidad de la unidad de trabajo;
objetivo actual;
estado y transiciones previas;
fuentes documentales;
memoria de decisiones;
herramientas disponibles;
resultados de herramientas;
permisos;
criterios de calidad;
reglas de seguridad;
personas con autoridad;
y condiciones de cierre.

No todo debe estar presente como texto en cada inferencia. Parte puede recuperarse cuando resulta necesaria. Parte vive en un sistema de registro. Parte se expresa en permisos técnicos. Parte se materializa en tests. Parte corresponde al humano.

La ingeniería de contexto consiste precisamente en decidir:

qué necesita conocer el modelo;
cuándo debe conocerlo;
de qué fuente procede;
con qué estatuto entra;
cuánto tiempo debe conservarse;
qué no debe recibir;
y qué debe permanecer fuera de su competencia.

Las once capas del contexto operativo

Una arquitectura suficiente puede distinguir once capas. No todas deben aparecer visiblemente en cada interacción, pero todas necesitan una forma de gobierno.

1. Mandato

El mandato responde a la pregunta: ¿para qué existe esta operación?

No es una descripción genérica del rol de la IA. Define el resultado que se persigue, el ámbito de actuación y los límites que no deben atravesarse.

Un mandato útil incluye:

finalidad;
unidad;
alcance;
exclusiones;
autoridad;
resultado esperado;
y condición de parada.

«Ayuda con el expediente» es una invitación abierta. «Localiza los documentos incorporados desde la última revisión, identifica hechos nuevos, separa fuentes de interpretaciones y prepara una propuesta de actualización sin modificar nada hasta aprobación» es un mandato operativo.

2. Identidad de la unidad

El sistema debe saber sobre qué objeto trabaja.

Una coincidencia de nombre no basta. Un número aislado puede referirse a asuntos distintos. Una empresa puede participar en varios contratos. Un cliente puede tener varios expedientes.

La identidad debe ser estable y verificable:

código completo;
ID técnico;
carpeta canónica;
entidad;
versión;
o combinación de identificadores.

Sin unidad, el contexto se contamina entre asuntos.

3. Estado

El estado no es la suma de todo lo ocurrido. Es la configuración vigente desde la que puede continuar la operación.

Debe permitir responder:

qué está confirmado;
qué sigue abierto;
qué se decidió;
qué actuación está pendiente;
qué bloqueo existe;
y cuál es el siguiente paso legítimo.

Un historial puede ser extenso y no contener estado. Un estado puede ser breve y conservar la continuidad decisiva.

4. Evidencia

Las fuentes deben comparecer con identidad propia.

El sistema necesita distinguir:

documento original;
copia;
resumen;
nota interna;
inferencia;
dato externo;
versión vigente;
y documento sustituido.

La evidencia no debe disolverse en la prosa del modelo. Una respuesta bien escrita no reemplaza el archivo del que procede.

Aquí la integración sin pérdida de identidad se vuelve una exigencia técnica. La fuente sigue siendo fuente. El modelo la interpreta, pero no la absorbe ni se convierte en su propietario epistemológico.

5. Memoria

La memoria es una inscripción que modifica operaciones futuras.

No todo lo recordado merece conservarse. Una memoria útil selecciona diferencias con capacidad de alterar:

una decisión;
una recuperación;
una prioridad;
una restricción;
una relación;
o una forma de verificación.

Conviene distinguir al menos cuatro tipos:

Memoria de trabajo

Mantiene los elementos necesarios durante la tarea presente.

Memoria episódica

Conserva qué ocurrió en actuaciones anteriores: acciones, incidencias, decisiones y resultados.

Memoria semántica

Conserva conceptos, relaciones, entidades y conocimiento relativamente estable.

Memoria procedimental

Conserva cómo se realiza una operación: protocolos, skills, checklists, tests y reglas de transición.

Mezclar estas memorias produce confusión. Una anécdota puede terminar gobernando como regla. Una instrucción temporal puede reaparecer meses después como criterio permanente.

6. Recuperación

La recuperación decide qué parte de las fuentes y la memoria entra en una operación concreta.

Los sistemas RAG —generación aumentada por recuperación— responden a esta necesidad: buscan fragmentos relevantes y los aportan al modelo en el momento de generar.[^6]

La recuperación resuelve un problema y crea otros.

Puede fallar porque:

no encuentra el documento;
selecciona un fragmento sin contexto;
confunde una versión antigua;
prioriza similitud léxica sobre autoridad;
recupera demasiado;
o devuelve una respuesta plausible sin haber recuperado nada útil.

Por eso el retrieval necesita identidad, metadatos, recencia, jerarquía de fuentes y trazabilidad.

7. Herramientas

El contexto no está formado solo por información. También incluye posibilidades de acción.

Una IA interpreta de manera distinta una tarea cuando sabe que puede:

buscar;
consultar un registro;
escribir un archivo;
ejecutar una prueba;
enviar un borrador;
o pedir aprobación.

Las herramientas definen el adyacente operativo del sistema: qué transiciones están disponibles desde el estado actual.

8. Permisos y autoridad

Poder ejecutar no equivale a estar autorizado.

El permiso técnico responde a qué puede hacer el sistema. La autoridad responde a quién puede decidir legítimamente que se haga.

Ambas capas deben relacionarse sin confundirse.

Un agente puede tener permiso de escritura en un repositorio, pero no autoridad para publicar. Puede leer un correo, pero no asumir que su contenido debe incorporarse a un expediente. Puede preparar una respuesta, pero no enviarla en nombre de una persona sin el cierre correspondiente.

La autoridad no puede quedar implícita en la disponibilidad de una herramienta.

9. Entorno

El entorno es el espacio en el que la acción produce consecuencias.

Puede ser:

una carpeta local;
un sandbox;
una rama de Git;
un staging;
una base de datos de pruebas;
o un sistema de producción.

La misma acción tiene riesgos distintos según el entorno. Borrar un archivo temporal dentro de un sandbox no equivale a borrar un documento canónico. Ejecutar una migración en staging no equivale a ejecutarla sobre datos reales.

Diseñar el entorno es una forma de limitar el daño incluso cuando la interpretación falla.

10. Estándares y verificación

El sistema necesita saber qué cuenta como resultado correcto.

Una salida puede parecer completa y no satisfacer el encargo. Para evitarlo hacen falta estándares observables:

schema válido;
fuentes citadas;
cálculo comprobado;
tests superados;
campos obligatorios;
ausencia de duplicados;
revisión humana;
o comparación con un estado esperado.

La verificación debe distinguir entre «la herramienta respondió» y «la operación produjo el resultado correcto».

11. Cierre

El contexto también debe decir cuándo terminar.

Los modelos generativos tienden a completar y los agentes tienden a continuar mientras detectan pasos posibles. Sin una condición de cierre, pueden:

seguir investigando sin mejorar la decisión;
modificar más de lo necesario;
producir documentación redundante;
o declarar éxito porque la secuencia terminó.

El cierre puede requerir:

resultado verificado;
aprobación;
límite de tiempo;
coste máximo;
ausencia de evidencia suficiente;
o aparición de una incertidumbre que excede la autoridad del sistema.

El contexto como arquitectura de diferencias

La ingeniería de contexto suele presentarse como una disciplina técnica: seleccionar mensajes del sistema, ejemplos, documentos, herramientas y memorias.

Desde la Morfogénesis puede formularse de manera más precisa.

El contexto es la arquitectura de diferencias que deben seguir influyendo.

Una fuente importa porque se diferencia de una inferencia. Un permiso importa porque se diferencia de una autoridad. Una versión vigente importa porque se diferencia de una anterior. Un estado importa porque se diferencia de la cronología completa. Una herramienta importa porque abre una transición que otras no permiten.

Cuando esas diferencias se borran, el contexto aumenta en volumen y disminuye en capacidad.

La inteligencia simbiótica no necesita que todos los componentes se conviertan en un bloque de texto uniforme. Necesita que cada uno permanezca reconocible dentro de una operación común.

Memoria no es almacenamiento

Las organizaciones ya almacenan cantidades enormes de información. Eso no significa que posean memoria operativa.

Un archivo se convierte en memoria cuando puede modificar correctamente una operación futura.

Para ello debe ser:

recuperable;
identificable;
interpretable;
vigente;
relacionado con una unidad;
y capaz de comparecer en el momento adecuado.

Un repositorio lleno de documentos sin estado ni relaciones puede aumentar el coste de recuperación. Una base vectorial que contiene fragmentos duplicados puede devolver una apariencia de relevancia. Una conversación guardada puede conservar decisiones sin distinguir cuáles fueron revocadas.

El problema de la memoria no se resuelve añadiendo una capa que «recuerde todo».

Se resuelve diseñando qué merece inscripción, bajo qué estatuto, con qué duración y qué mecanismo de corrección.

El riesgo de la memoria persistente

Recordar mejora continuidad. También prolonga el error.

Una instrucción maliciosa incorporada a memoria puede influir en sesiones futuras. Un dato equivocado puede adquirir autoridad por repetición. Una interpretación provisional puede reaparecer como hecho. Un permiso temporal puede quedar implícitamente normalizado.

Por eso la memoria necesita:

procedencia;
fecha;
autor o sistema de origen;
ámbito;
vigencia;
posibilidad de impugnación;
y trazabilidad de cambios.

La memoria simbiótica no absorbe el pasado. Lo conserva de forma que pueda ser revisado.

El humano no es el contexto del modelo

Existe una forma peligrosa de diseñar sistemas humano-IA: tratar al humano como una fuente más que debe alimentar a la máquina.

La persona aporta información, corrige, aprueba y completa lagunas. El centro operativo sigue siendo el agente.

Eso no es necesariamente simbiosis.

En una integración operativa real, el humano conserva funciones propias:

presencia ante la diferencia;
experiencia situada;
formación de criterio;
definición de finalidad;
autoridad;
responsabilidad;
y capacidad de cortar.

No todas esas funciones deben traducirse a tokens para existir. Algunas se expresan precisamente en la decisión de no delegar, en la selección de una fuente, en la interrupción de una trayectoria o en la revisión de una consecuencia.

La ingeniería de contexto debe diseñar el lugar del humano, no limitarse a capturar su conocimiento.

De prompt a expediente

El expediente ofrece un ejemplo claro de este cambio.

Un prompt es una petición dentro de una sesión.

Un expediente es una unidad persistente con:

identidad;
fuentes;
historia;
estado;
autoridad;
tareas;
decisiones;
documentos;
relaciones;
y continuidad.

Cuando la IA trabaja sobre un expediente, no recibe simplemente más información. Entra en una forma profesional que ya distingue qué pertenece al asunto, qué fuente conserva el original, qué actuación requiere verificación y quién puede cerrar una decisión.

La evolución puede representarse así:

prompt
→ conversación
→ contexto acumulado
→ memoria seleccionada
→ unidad de trabajo
→ sistema operativo

El prompt no desaparece. Se convierte en una operación local dentro de una arquitectura mayor.

El ciclo de vida del contexto

Un contexto profesional necesita un ciclo de vida.

Captura

¿Qué hecho, documento, decisión o resultado entra en el sistema?

Clasificación

¿Es fuente, interpretación, tarea, estado, regla, incidente o aprendizaje?

Vinculación

¿A qué unidad, persona, versión, proceso o decisión pertenece?

Activación

¿Cuándo debe influir en una operación?

Verificación

¿Sigue siendo correcto, vigente y suficientemente autorizado?

Retirada

¿Cuándo deja de formar parte del contexto activo sin desaparecer de la historia?

Aprendizaje

¿Qué diferencia merece convertirse en una regla, una herramienta, una memoria o una modificación del sistema?

Sin ciclo de vida, el contexto solo crece.

Con ciclo de vida, se convierte en infraestructura.

El límite del contexto perfecto

Nunca dispondremos de un contexto completo.

Siempre faltará información, habrá documentos ambiguos, aparecerán contradicciones y se producirán acontecimientos fuera del sistema. Diseñar bien no significa eliminar la incertidumbre.

Significa hacerla visible y asignarle un tratamiento.

Un sistema maduro debe poder decir:

no he encontrado la fuente;
existen dos versiones incompatibles;
esta conclusión es una inferencia;
no dispongo de autoridad;
la herramienta ha fallado;
falta aprobación;
o el coste de continuar supera el valor esperado.

La ingeniería de contexto alcanza su madurez cuando no solo ayuda a responder, sino también a no completar lo que todavía no puede cerrarse.

La siguiente dificultad aparece precisamente ahí.

Aunque el contexto esté bien diseñado, la IA sigue siendo un sistema probabilístico. Puede generar una falsedad, seleccionar mal una fuente, desviarse durante una secuencia o ejecutar una acción correcta dentro de una trayectoria equivocada.

La capacidad ha crecido.

También lo ha hecho el tipo de error.