El mapa para orientarte y entender la IA y sus engineerings – Parte 1

Cuando hablamos de inteligencia artificial hay bastante confusión. Una parte viene del hype, demasiadas veces interesado, y otra de algo más simple: esto se está construyendo ahora mismo y a una velocidad que no le da margen a mucha gente para pararse, entenderlo y colocarlo mentalmente.

Por eso creo que, antes de hablar de herramientas, modelos, agentes o automatizaciones, conviene hacer una cosa mucho más básica: dibujar el mapa. Si queremos entender un sistema, lo primero es identificar sus partes y ponerles nombre.

Para mí, en este sistema hay tres entidades básicas.

1. Las personas que usan la IA para trabajar, que son las operadoras.
2. La IA, que son las herramientas que esas personas usan para trabajar sobre información, datos y otras herramientas.
3. El conocimiento, que es donde viven esos datos e informaciones en distintos formatos y tecnologías.

El flujo base sería ese: personas usando herramientas de IA para trabajar sobre conocimiento.

Y un aviso antes de entrar, porque me parece de higiene decirlo: lo que viene es un modelo mental, no un estándar. Nadie ha cerrado esta taxonomía y las fronteras se están moviendo mientras escribo esto. Lo comparto porque me sirve para ordenar proyectos, conversaciones y decisiones de inversión, no porque sea la definición oficial de nada. Donde tengo criterio propio lo digo, y donde está en disputa también.

El prompting: comunicarse con la IA

La parte más visible del sistema es el prompting. Las personas interactuamos con las herramientas de IA en lenguaje natural, escribiendo o hablando. A eso se le llamó prompt engineering, en el momento alto del hype de la novedad de la IA y las nuevas profesiones que iba a traer. Aunque siendo sinceros, el nombre siempre me ha parecido un poco exagerado.

Yo suelo llamarlo simplemente prompting. Al final es la forma de interactuar con la herramienta llamada IA, es decir, la nueva interfaz. Y sí, claro que hay niveles de conocimiento y experiencia, igual que los hay usando cualquier software, pero tampoco creo que haga falta inflarlo como si estuviéramos hablando de una nueva ingeniería espacial.

La IA entiende lenguaje natural y tiene cierta capacidad semántica para interpretar contexto dentro del propio texto, pero también conviene recordar algo importante: muchas veces recoge las instrucciones de forma bastante literal. Por eso no solo importa qué le pides, sino cómo se lo pides.

La IA no es una sola cosa

Aquí suele haber otra confusión habitual. Mucha gente visualiza las herramientas de IA que usamos como si fueran una sola cosa cerrada. Y como producto tiene sentido pensarlo así, igual que piensas en un coche como una unidad. Pero si levantas el capó, la cosa cambia.

Una herramienta de IA suele tener al menos dos partes fundamentales. Por un lado está el modelo LLM, que sería el motor y la mecánica que hay debajo. Por otro está la herramienta o interfaz desde la que lo usamos, que sería la carrocería y el interior del coche.

Esa separación es importante porque aunque casi siempre vienen juntas por marca de IA, no tienen por qué ir unidas. Lo intuímos porque las herramientas de IA nos permiten usar varios modelos de una misma marca, pero también hay ya también otras herramietnas que conectan con modelos de muchas marcas distintas, incluyendo modelos open source en local en tu propio ordenador o servidor.

Entender esto evita muchas conversaciones absurdas de «qué IA es mejor» como si todo fuera una única pieza indivisible. Muchas veces lo que estás comparando no es solo el modelo, sino también la herramienta, (en su versión web, app de escritorio o cli) la experiencia de uso y todo lo que esa herramienta lleva alrededor.

El conocimiento: donde realmente está el valor

La tercera pata del sistema es el conocimiento. Normalmente hablamos de información y datos. Según el contexto profesional se le pone un nombre u otro, pero por simplificar, la información suele vivir en documentos y los datos suelen vivir en bases de datos ( y aquí meto también muchos excels, como tablas o mini bases de datos).

Hay además una parte del conocimiento que suele pasar bastante desapercibida: la información que vive dentro de herramientas operativas. El gestor de proyectos, el CRM, el ERP, el software de inventario, la plataforma de ecommerce, el sistema de tickets, el gestor de llamadas.

Técnicamente todo eso también son datos, muchas veces en bases de datos, pero nosotros no solemos acceder directamente a ellas. Operamos ese conocimiento desde interfaces, mediante APIs o, con suerte podemos extraer la info mediante exportaciones y copias en formatos más o menos estándar.

Aquí merece la pena hacer una distinción importante. El conocimiento que reside en documentos y bases de datos suele ser más permanente y, en cierto modo, más nuestro. Aunque esté alojado en sistemas de terceros, normalmente una empresa no da de baja esos sistemas sin preocuparse por descargar o migrar la información.

En cambio, el conocimiento que queda encerrado dentro de herramientas es mucho más frágil. No porque sea menos valioso por definición, sino porque depende de sistemas más temporales y a veces más invisibles. Una herramienta se cambia, se cancela o se deja de usar, y de repente nadie se acuerda de que allí dentro también había conocimiento.

Y no, no toda esa información merece el mismo esfuerzo de migración. Los contactos y empresas de un CRM seguramente sí. Toda la micro-operativa diaria de un gestor de proyectos, quizá no, pero igual nos interesa sacar una «foto» del estado mensual para guardarlo, igual que hacemos con los informes a los clientes. Pero justo por eso conviene pensar qué información es estratégica, cuál merece conservarse y en qué formato debería salir de esas herramientas para pasar a formar parte de un conocimiento más estable.

Desde mi punto de vista, aquí entra un tema importante de soberanía digital. No se trata solo de si la IA puede o no puede ver esos datos. Se trata de si esa información relevante realmente es tuya, si la puedes mover, si la puedes conservar y si sigue siendo útil cuando cambias de software.

Los asistentes y los agentes

Cuando metemos a la IA a trabajar sobre conocimiento aparecen los asistentes, muchas veces mal llamados agentes. En realidad, en muchos casos son más bien roles o configuraciones que le damos a la herramienta de IA para especializarla.

Le damos instrucciones específicas, definimos un rol para que la IA que se centre mucho en una parte específica de su conocimiento y darle instrucciones específicas (system prompt), e incluso un tipo de personalidad al interactuar con nosotros. Al que le podemos añadir o conectar conocimiento propio nuestro (contexto o conocimientos), podemos decirle que hacer y como (procedimientos o recetas), que no hacer (normas o guardarailes) y darle habilidades concretas (explicaciones de como se hacen ciertas cosas) o que use las conexiones a determinadas herramientas (email, calendario, crm, gestor de tareas, …)

Dicho de otra forma, modelamos la IA para que se comporte más a nuestro gusto, para que se especialice en un área y para que trabaje dentro de unos límites. Es como versionar la herramienta para distintos usos. Puedes tener una IA más enfocada a redactar, otra a analizar, otra a organizar, otra a programar, y todas ser en el fondo la misma base usando distintos «disfraces» o «personajes».

Aquí sí conviene hacer una precisión, porque es donde más se lía el vocabulario. Lo que separa a un asistente de un agente no es cuánto rato aguanta trabajando ni lo listo que parece, es un mecanismo concreto: el bucle.

• Asistente: responde por turnos. Puede tener contexto, normas, habilidades y personalidad, pero espera a que le hables. Cada paso se lo das tú.
• Agente: tiene bucle. Se llama a sí mismo, decide el siguiente paso, elige qué herramienta usa y sigue iterando hasta cerrar el objetivo que le diste.
• Agente autónomo: lo mismo, pero con más independencia operativa y menos supervisión humana inmediata.

Que trabaje mucho rato seguido es la consecuencia, no la definición.

Por eso la mayoría de lo que hoy se vende como «agente» son en realidad asistentes bien configurados. El disfraz no hace al agente: un asistente muy bien definido, con su contexto, sus normas y sus habilidades, sigue siendo alguien a quien hay que darle cada paso. Lo que lo convierte en agente es el bucle, y eso ya no se define escribiendo un archivo de texto, se configura en la herramienta.

Aun así, la idea práctica sirve: esa capa de configuración cambia mucho lo que la herramienta puede hacer y cómo lo hace.

Si lo de las personalidades te parece raro o no terminas de entender de que va, piensa en compañeros de trabajo que teniendo la misma función cada uno tiene su personalidad distinta.

Si usas chat gpt ve a la parte de GPT y busca el GPT llamado Monday, de la propia empresa de chat gpt. Ten una conversación con él y verás que es la misma IA pero con una personalidad totalmente distinta, en este caso el hermano borde, o ese compañero sarcástico y casi tóxico.

El conocimiento también necesita traducción

Hay otra idea que suele pasarse por alto. La IA entiende especialmente bien el texto plano. Y esto, que parece una obviedad, tiene bastante importancia.

Mentalmente pensamos que un Word o un PDF son «texto», pero no son texto plano. Son formatos que necesitan una capa de interpretación. Si abres uno de esos archivos en un bloc de notas, lo normal es que veas ruido ilegible.

Por eso la IA, para leer bien esos formatos, necesita conectores, librerías o funciones específicas que los interpreten. Hoy eso está bastante resuelto en herramientas modernas para formatos habituales como Word, Excel, PowerPoint o PDF, pero sigue siendo una capa adicional entre la IA y el conocimiento, que además gasta tokens en el uso interno de la herramienta para la «traducción»

Y precisamente por eso, entre la IA y el conocimiento muchas veces aparece otra capa de software complementario: sistemas RAG, bases de datos vectoriales, memorias, índices, buscadores, conectores, APIs, scripts, MCPs y otras piezas que mejoran la forma en la que la IA encuentra, recupera, interpreta o usa esa información.

Los «engineerings» de la IA

Si dibujamos el mapa completo, entonces aparecen con bastante claridad los distintos «engineerings».

Prompt engineering

El primero es el prompt engineering, o si lo prefieres, el prompting. Es la capa de interacción entre la persona operadora y la herramienta de IA. Es la conversación, la instrucción, la petición. La interfaz que ahora deja de ser botones en pantalla, para volverse conversacional.

Context engineering

El segundo es el context engineering. Aquí entramos en algo bastante más importante de lo que parece: tener el conocimiento escrito, estructurado, conectado y disponible para la IA.

Y como este sí es un término con una historia corta y bastante clara, merece la pena contarla, porque ayuda a entender de qué se está hablando exactamente.

El término se popularizó en junio de 2025. La formulación que se ha quedado como canónica es la de Tobi Lütke, el consejero delegado de Shopify: el context engineering es el arte de proporcionar todo el contexto necesario para que la tarea sea plausiblemente resoluble por el modelo. Una semana después Andrej Karpathy lo amplificó con una definición más precisa y que a mí me parece la mejor de todas: el arte y la ciencia, delicados, de llenar la ventana de contexto con la información justa para el siguiente paso.

Hay quien atribuye la acuñación a otras personas, así que no me voy a poner a repartir medallas. Lo que importa es que las dos definiciones dicen lo mismo desde ángulos distintos: una habla de suficiencia (que esté todo lo que hace falta) y la otra de precisión (que esté solo lo que hace falta). Y el oficio consiste justo en sostener las dos cosas a la vez.

Desde el lado académico se ha formalizado como una disciplina que trasciende el simple diseño de prompts, con tres bloques de trabajo que a mí me sirven mucho para ordenar proyectos: la generación del contexto, su procesamiento y su gestión. Es decir, de dónde sale, qué se le hace y cómo se mantiene vivo en el tiempo.

Y si quieres la versión más aterrizada de todas, la de Lance Martin en LangChain lo reduce a cuatro verbos que describen bastante bien el trabajo real del día a día: escribir contexto (guardarlo fuera de la ventana para que no se pierda), seleccionar (traer solo lo que hace falta en cada paso), comprimir (quedarse con lo justo cuando no cabe) y aislar (separar lo que estorba). Cuatro verbos y ya tienes casi todo el oficio descrito.

En mi opinión, este es uno de los puntos más infravalorados ahora mismo. Muchas empresas están descubriendo la IA sin tener mínimamente ordenado lo que saben. No tienen manuales al día, no tienen procesos bien escritos, no tienen un sistema claro para documentar decisiones o procedimientos, y gran parte del conocimiento sigue difuso entre correos, documentos sueltos y cabezas humanas.

La buena noticia es que la propia IA puede ayudar a hacer ese trabajo. Puede ayudar a ordenar, resumir, convertir información dispersa en conocimiento más útil y desbloquear parte de ese saber que antes estaba escondido o sin formalizar. Desde documentos viejos batiburrillo que alguien escribió una vez, a dictarle a un documento o a lA como se hace algo y que lo procese o grabar y transcribir la siguiente vez que alguien le cuente al compañero nuevo como se trabaja. La IA se puede encargar del trabajo pesado de entenderlo, ordenarlo, trocearlo y escribirlo de forma eficiente.

Pero una cosa es que la IA pueda trabajar con conocimiento desordenado y otra muy distinta es que da igual cómo esté. Yo aquí no compraría demasiado cierto el discurso actual y fácil de «mientras sea accesible, basta».

Sí, la IA puede operar sobre caos. Pero igual que le pasaría a una persona, no puedes esperar el mismo nivel de velocidad, calidad y certeza si consulta una biblioteca ordenada con índice que si entra en un trastero revuelto. La IA potencia el orden, pero también potencia el caos. Y además, cuando tiene que trabajar más para encontrar lo que necesita, consume más tiempo y más tokens. Es decir: más tiempo, menos fiabilidad y mas coste.

Esto, que yo venía diciendo por intuición y por experiencia, tiene desde hace un tiempo respaldo medido. Un estudio de Chroma publicado en julio de 2025, firmado por Kelly Hong, Anton Troynikov y Jeff Huber, evaluó 18 modelos de primera línea y le puso nombre al fenómeno: lo llamaron context rot, la podredumbre del contexto.

El hallazgo es que la fiabilidad de un modelo cae según crece lo que le metes delante, incluso en tareas sencillas, y aquí viene lo importante: empieza a caer mucho antes de llegar al límite de la ventana. Un modelo que admite 200.000 unidades de texto puede estar degradándose ya a 50.000. O sea, que quepa no significa que convenga.

Para un directivo esto se traduce en una frase bastante incómoda: la respuesta fácil de «métele todo, que cabe» no solo es cara, es que además funciona peor. Y no funciona peor por una limitación que se vaya a arreglar el año que viene con un modelo mejor. Funciona peor por cómo estos sistemas reparten la atención.

Por eso el context engineering no va solo de tener información disponible. Va de tenerla razonablemente ordenada, en formatos estándar, bien escrita y bien conectada. Y aquí también entran las definiciones de asistentes o agentes, porque toda esa configuración muchas veces se hace precisamente en archivos de texto que contienen contexto, normas, procedimientos y capacidades.

Aviso de que esto último es discutible y que soy consciente. Hay quien mete la definición de asistentes en el harness, porque al fin y al cabo configura la herramienta, y hay quien la llama directamente de otra manera (scaffolding, el andamiaje) para no tener que elegir. Mi criterio es sencillo y prefiero decirlo en voz alta para que se pueda discutir: si es texto que el modelo lee para decidir cómo comportarse, es contexto. Si es cableado que el modelo no lee, es harness. Que la frontera esté en disputa no es excusa para no tener criterio, pero tampoco para venderlo como si estuviera cerrado.

Y con los guardarraíles conviene aplicar exactamente el mismo corte, porque de ahí depende el nivel de protección que uno tiene de verdad. Una norma escrita en un archivo que el modelo lee es contexto: puede ignorarla, y a veces la ignora. Un permiso que no le has dado, una API deshabilitada o una herramienta que solo puede leer y no escribir son harness: eso no lo puede desobedecer. Las dos cosas hacen falta, pero no son lo mismo ni protegen igual, y conviene saber cuál de las dos tienes puesta antes de confiarte.

Y hay un matiz que para mí es el corazón de este bloque: todo el contenido que entra a la IA como contexto debería estar curado antes.

Podemos tener, y de hecho debemos tener, archivos de fuentes e ingesta de material en crudo. Correos, contratos, actas, transcripciones, catálogos, informes. Todo eso entra y todo eso se guarda intacto, porque es la verdad de partida y porque nunca sabes qué vas a necesitar releer. Pero eso es materia prima, no es contexto todavía.

Entre esa materia prima y la IA tiene que haber algo en medio: un sistema que destile conocimiento. Que lea lo que llega, extraiga lo relevante, lo integre donde toque, marque las contradicciones con lo que ya había y mantenga el resultado al día y con fecha.

Y ese sistema se alimenta de dos corrientes, no de una. Por un lado las fuentes externas que van entrando. Por otro lo que producimos nosotros al trabajar: las respuestas buenas que alguien dio una vez, los criterios que se fijaron en una reunión, las aclaraciones del que más sabe, las conclusiones de un análisis que costó una tarde. Esa segunda corriente es la que casi nadie recoge, y es la que más vale, porque no está escrita en ningún otro sitio del mundo.

La buena noticia, otra vez, es que buena parte de ese destilado puede hacerlo la propia IA con personas revisando. Que es exactamente por lo que ahora sí es un problema abordable y antes no lo era.