Tres cosas distintas. Una sola palabra en el catálogo.

Serie «Entender la IA», nota 3 de 12. Las dos primeras explicaron qué es la inteligencia artificial y cómo trabaja por dentro un modelo de lenguaje. Esta sale de la máquina y entra en la sala de reuniones.

Martes, 9:30, la sala grande de una empresa de logística en Zúrich. Tres proveedores, tres presentaciones, una misma palabra en las tres portadas. El primero enseña un sistema que lee los pedidos del correo y los mete en el programa de gestión. El segundo, un «robot» que copia datos de una pantalla a otra sin que nadie toque el ratón. El tercero, un «agente» que contesta a los clientes solo. Los tres dicen inteligencia artificial. Los tres cuestan más de lo que costaba el camión nuevo. Y la propietaria, que lleva treinta años distinguiendo un buen transportista de uno malo en cinco minutos, se da cuenta de que no sabe por dónde empezar a comparar.

La escena es imaginaria. La confusión, no. Se produce porque tres tecnologías con sesenta años de diferencia entre ellas se han metido en la misma palabra, y porque a quien vende le conviene que sea así. En esta nota le doy las tres definiciones, una imagen para no olvidarlas, un criterio para saber cuál necesita en cada caso y las siete preguntas que uso para desmontar una presentación en media hora. Al terminar, la próxima vez que alguien le diga «esto es IA», sabrá qué le está diciendo exactamente. Y qué no.

El software sigue reglas. El robot de proceso imita manos. El modelo predice. Las tres cosas automatizan, pero solo una de ellas puede equivocarse con elegancia.

Primero: el software, o las reglas escritas.

Un programa clásico es una receta. Alguien escribió, paso a paso, qué hay que hacer con cada dato: si la factura supera los 10 000 francos, pide una segunda firma; si el cliente está en Italia, aplica este impuesto; si el campo está vacío, muestra un error. Cada regla la pensó una persona y la escribió otra, o la misma. El programa no entiende nada. Ejecuta.

Esto tiene una virtud enorme que solemos dar por supuesta: es determinista. Con los mismos datos de entrada produce siempre la misma salida. Si falla, falla siempre igual, y alguien puede leer la regla y corregirla. Su programa de contabilidad, su sistema de reservas y la hoja de cálculo con la que calcula los márgenes son software en este sentido. Automatizan desde hace décadas, y bien. La mayoría de lo que una empresa necesita automatizar sigue siendo, en 2026, software de toda la vida. Conviene recordarlo antes de la segunda presentación.

Su límite es igual de claro. Solo hace lo que alguien supo escribir como regla. Y hay cosas que nadie sabe escribir como regla: reconocer que un correo es una queja aunque no contenga la palabra queja, resumir un contrato, decidir qué pedido es urgente leyendo el tono del cliente. Ahí el software clásico se detiene.

Segundo: la automatización robótica de procesos, o las manos que imitan.

A finales de los años 2000 apareció una idea sencilla y muy rentable. Muchas empresas tienen programas que no se hablan entre sí: el de pedidos no conecta con el de facturación, el banco no conecta con la contabilidad. Alguien, cada mañana, copia datos de una pantalla a otra. ¿Y si un programa imitara a esa persona? Abre la aplicación, pincha donde ella pincha, copia lo que ella copia, pega donde ella pega. A eso se le llamó automatización robótica de procesos, RPA por sus siglas en inglés. El «robot» no es una máquina: es un programa que mueve el ratón y teclea.

IBM lo define con una distinción que vale oro en una reunión. La RPA está guiada por el proceso: sigue flujos definidos, paso a paso, y trabaja con datos estructurados, los que ya están en campos y columnas. La inteligencia artificial está guiada por los datos: aprende patrones y puede trabajar con datos sin estructura, como texto libre, imágenes o voz. Son complementarias, dice IBM, y es cierto. Pero no son lo mismo, y un robot de proceso es, en el fondo, software clásico con una interfaz distinta: tan determinista y tan ciego como cualquier receta.

La imagen que uso es la de una cocina. El software es la receta. El robot de proceso es un ayudante que sigue la receta al pie de la letra, abre los cajones y aprieta los botones del horno, pero no prueba la salsa. Es muy útil mientras la cocina no cambie: si alguien mueve el cajón de los cuchillos, el ayudante abre el aire. Por eso los proyectos de RPA se rompen cada vez que un proveedor cambia el diseño de una pantalla. Si le han vendido un robot que «se adapta» a los cambios de las pantallas, pregunte cómo. Casi siempre la respuesta es: con una persona que lo arregla.

Tercero: la inteligencia artificial, o el cocinero que prueba la salsa.

La tercera tecnología es la que explicamos en las dos notas anteriores. Un modelo entrenado con cantidades enormes de ejemplos que, en vez de seguir reglas escritas, predice: la siguiente palabra, la categoría de un correo, el contenido de un campo a partir de un PDF escaneado. Nadie le escribió la regla «esto es una queja». Ha visto millones de quejas y reconoce una nueva aunque esté redactada con cortesía suiza.

En la cocina, es el cocinero. Prueba la salsa, nota que falta sal y la corrige. Puede improvisar con lo que hay en la nevera. Y puede equivocarse: confundir el azúcar con la sal con la misma seguridad con la que acierta el resto de las veces. Esa es la diferencia decisiva con las otras dos tecnologías y la razón de toda esta serie. El software y el robot fallan de forma previsible. El modelo falla de forma plausible. Una regla mal escrita produce un error visible; un modelo mal configurado produce una respuesta que parece correcta.

De aquí sale la pregunta que más valor me ha dado en una reunión, y que le regalo: «Si lo ejecuto dos veces con los mismos datos, ¿sale exactamente lo mismo?» Si la respuesta es sí, le están vendiendo software o un robot de proceso, por mucho que la portada diga IA. Si la respuesta es «casi», le están vendiendo un modelo, y a partir de ese momento todas las demás preguntas tienen que ser sobre cómo se mide y cómo se controla ese «casi».

Cuál necesita usted, y cuándo.

No es una competición. Casi todos los proyectos buenos que he visto combinan las tres, y el error habitual es poner un modelo donde bastaba una regla, o una regla donde hacía falta un modelo. Mi criterio cabe en una tabla mental con dos preguntas: ¿están las reglas claras? y ¿están los datos ordenados?

• Reglas claras, datos ordenados. Software. Una fórmula, una validación, un flujo de aprobación. Es lo más barato, lo más fiable y lo que menos vigilancia necesita. Ejemplo: avisar cuando una factura lleva 30 días vencida.
• Reglas claras, datos ordenados, programas que no se hablan. Robot de proceso, mientras se construye la conexión de verdad. Ejemplo: pasar cada mañana los movimientos bancarios al programa de contabilidad. Sepa que es una muleta, no una solución, y que se romperá con el próximo cambio de pantalla.
• Reglas difusas o datos sin estructura. Modelo de IA. Ejemplo: leer los correos que llegan a info@, decidir de qué tratan, extraer el pedido y proponer una respuesta. Aquí sí hay algo que ninguna regla sabía hacer.
• Juicio con consecuencias. Modelo que propone y persona que decide. Ejemplo: clasificar las reclamaciones por gravedad. La máquina ordena la bandeja; la decisión de indemnizar la firma alguien.

Observe que en los dos últimos casos el modelo rara vez trabaja solo. Lo normal es que lea algo desordenado, lo convierta en datos ordenados y se los entregue al software de toda la vida, que a partir de ahí aplica las reglas. La IA ordena; el software ejecuta; el robot, si hace falta, mueve el ratón. Cuando un proveedor le enseña un sistema, pídale que le señale en el diagrama dónde está cada una de las tres piezas. Si no sabe, no lo ha construido él.

La palabra más gastada del catálogo: agente.

Queda la cuarta palabra, la que estaba en la tercera presentación. En 2026 casi todo se llama agente. Conviene saber de dónde viene y cuánto hay detrás.

Anthropic publicó en diciembre de 2024 una guía técnica para quienes construyen estos sistemas, y en ella traza una línea que le servirá: un flujo de trabajo es un sistema en el que el modelo y las herramientas se orquestan por caminos definidos de antemano en código; un agente es un sistema en el que el modelo decide por sí mismo qué pasos dar y qué herramientas usar para cumplir una tarea. La misma guía añade dos consejos que un vendedor rara vez repite: busque siempre la solución más simple posible, y use agentes solo para problemas abiertos en los que no se puede predecir el número de pasos. Para casi todo lo demás, dice, basta con una sola llamada al modelo bien hecha. Le dedico a esta distinción la nota 5.

El mercado ha ido por otro lado. El 25 de junio de 2025, Gartner publicó una previsión que debería estar colgada en todas las salas de compras: más del 40 % de los proyectos de agentes de IA se cancelarán antes de finales de 2027, por costes crecientes, valor poco claro o controles de riesgo insuficientes. En la misma nota acuñó un término, «agent washing», para describir la práctica de rebautizar como agentes productos que no lo son: asistentes, robots de proceso, automatizaciones clásicas con una capa nueva de pintura. Gartner estimaba que, entre los miles de proveedores que decían vender agentes, solo unos 130 eran reales. Y en una encuesta a 3412 directivos, el 19 % había hecho inversiones importantes en agentes, el 42 % inversiones prudentes, el 8 % ninguna y el 31 % estaba esperando a ver.

No le cuento esto para que no compre agentes. Se los contaré, y bien, en dos notas. Se lo cuento para que, cuando oiga la palabra, haga la pregunta de antes: ¿decide el modelo los pasos, o los decidió un programador? La mayoría de las veces los decidió un programador, y eso es una buena noticia, porque es más barato, más previsible y más fácil de controlar. Solo es una mala noticia si lo pagó a precio de otra cosa.

Siete preguntas para media hora.

Las hago en este orden, y la calidad de las respuestas me dice más que la demostración.

• ¿Si lo ejecuto dos veces con los mismos datos, sale lo mismo? Separa el software del modelo. Es la primera porque cambia todas las demás.
• ¿Qué parte es modelo, qué parte es regla y qué parte es robot? Pida que lo señalen en un diagrama. Quien lo construyó lo sabe de memoria.
• ¿Qué modelo, de quién y de qué versión? Si la respuesta es «nuestro propio motor de IA», insista. En 2026 casi nadie entrena su propio modelo; casi todos usan el de un gran proveedor. Eso es legítimo, pero cambia quién controla el precio y los cambios.
• ¿Con qué cincuenta casos míos lo medimos? No con los suyos. Con cincuenta correos, facturas o llamadas reales de su empresa, con la respuesta correcta conocida. Si no se puede, no se puede evaluar.
• ¿Qué pasa cuando no sabe? La respuesta buena es: lo dice y lo pasa a una persona. La mala es: siempre responde.
• ¿Qué se rompe cuando cambie algo? Una pantalla, un formato de factura, la versión del modelo. Quién lo arregla, en cuánto tiempo y a qué precio.
• ¿Dónde van mis datos? A qué proveedor, en qué país, si se usan para entrenar y cómo se borran. Lo trataremos con calma en la nota sobre datos y ley, pero la pregunta se hace en la primera reunión.

1. Esta semana, 30 minutos

   Haga el inventario de las tres piezas

   Liste los programas que ya tiene y marque cada uno: receta, ayudante o cocinero. Descubrirá que casi todo es receta, y que funciona.

2. En la próxima presentación

   Haga la pregunta de las dos ejecuciones

   Antes de ver la demostración. Observe si el vendedor la entiende a la primera.

3. Antes de pedir precio

   Pida el diagrama con las tres piezas señaladas

   Y que le digan de quién es el modelo y qué versión. Guarde la respuesta por escrito.

4. Antes de firmar

   Prepare sus cincuenta casos

   Reales, con la respuesta correcta al lado. Es su conjunto de oro, y vale para comparar a los tres proveedores con la misma vara.

Cómo lo planteo yo.

En mis proyectos, la primera semana no se escribe código: se dibuja el diagrama con las tres piezas. Casi siempre hay más receta de la que el cliente esperaba y menos modelo del que le habían vendido. El modelo se reserva para lo que ninguna regla sabe hacer, se mide con los cincuenta casos antes de encenderlo y se le da permiso para decir «no lo sé». El resto es software, y el software, cuando está bien hecho, no necesita apellido.

Antes de la siguiente nota, piense en la última propuesta de «IA» que llegó a su mesa. Táchele mentalmente esa palabra y pregúntese qué queda: ¿una regla que se podría escribir, un robot que copia clics o un modelo que de verdad tiene que entender algo?

Si no sabe en cuál de las tres casillas caería, no es un defecto suyo. Es justo la pregunta que la propuesta debería haber contestado por usted. Y quizá valga la pena preguntarse por qué no lo hizo.

Siguiente nota: el mapa. Qué sabe hacer hoy un modelo de lenguaje dentro de una empresa, departamento por departamento, con lo que los estudios han medido de verdad y lo que todavía es promesa.