¿Tu integración necesita razonar o solo necesita una regla bien escrita?
¿Cuándo aporta valor la IA en integración de sistemas? Comparamos agentes y automatización determinista para separar razonamiento, reglas y ejecución.
Si llevas un tiempo mirando el mundo de la integración de sistemas, probablemente te haya pasado esto: herramientas que conocías perfectamente bien —Airbyte, Workato, Celigo o el conector ERP-ecommerce de turno— de pronto se presentan como “capa de contexto para agentes IA”, “agentic orchestration” o “MCP para AI agents”.
Y tú, que sabes lo que hacían hasta ayer, te preguntas legítimamente: ¿ha cambiado realmente el producto o ha cambiado la categoría con la que quiere ser reconocido?
Las dos cosas pueden ser ciertas a la vez.
Una herramienta útil para analizar estos cambios es el extrañamiento: mirar algo conocido como si fuera nuevo y dejar de aceptar temporalmente las categorías con las que la propia industria lo describe. En lugar de empezar preguntando qué es una “agentic integration platform”, podemos preguntar algo mucho más concreto:
¿Qué hacía esta herramienta hace tres años, qué hace ahora y qué problema nuevo puede resolver?
Cuando hacemos ese ejercicio, parte del cambio resulta ser vocabulario. Pero no todo.
Hay una transformación técnica real detrás: los sistemas de integración ya no tienen por qué servir únicamente a procesos que saben de antemano qué datos necesitan y qué deben hacer con ellos. Ahora también pueden servir a agentes que investigan, consultan contexto y deciden qué necesitan saber a medida que avanzan.
La cuestión interesante no es, por tanto, si la integración se está volviendo “agentic”.
Es qué partes deberían hacerlo y cuáles probablemente no.
El vocabulario mínimo para seguir la conversación sobre IA en integración de sistemas
Antes de comparar herramientas necesitamos cuatro conceptos.
| Término | En una frase |
|---|---|
| Sistema determinista | Reglas definidas: dadas las mismas condiciones, ejecuta la misma decisión. |
| Agente IA | Decide qué hacer a continuación según el contexto que va encontrando. |
| MCP | Un estándar para que aplicaciones y agentes descubran y utilicen herramientas y contexto externos. |
| Human-in-the-loop | Un punto donde el proceso requiere aprobación humana antes de continuar. |
Sistema determinista
Es el mundo de la automatización que conocemos bien: “si ocurre X y se cumplen estas condiciones, haz Y”.
Eso no significa que tenga que ser simple.
Imagina un pedido confirmado y pagado en Shopify. La integración identifica al cliente porque ya está relacionado con su ficha en el ERP, recupera la tarifa que le corresponde, resuelve qué referencia del ERP representa cada variante comprada, crea el pedido en Sage 200 con esas condiciones y actualiza el Stock del almacén correspondiente.
Hay bastante conocimiento de negocio dentro de ese proceso.
Pero no hay nada que “pensar” durante su ejecución.
Las relaciones cliente→tarifa, variante→referencia o venta→almacén estaban definidas antes de que llegara el pedido. El sistema las ejecuta.
Esa es una distinción importante: tener semántica no implica tener razonamiento.
Un sistema determinista puede entender bastante sobre el dominio en el que trabaja y seguir siendo predecible, reproducible y auditable.
Agente IA
Un agente funciona de otra manera.
Dispone de un modelo capaz de utilizar herramientas —consultar un sistema, buscar información, ejecutar una acción— y puede decidir qué hacer después según lo que descubre.
No tiene necesariamente un camino completamente definido antes de empezar.
Ante una discrepancia de stock, por ejemplo, podría consultar primero los movimientos del ERP, después los Pedidos del ecommerce, detectar una devolución sospechosa, revisar el log de sincronización correspondiente y, con esa nueva evidencia, decidir qué investigar a continuación.
La diferencia fundamental no es que utilice lenguaje natural.
Es que el camino para llegar a la respuesta puede decidirse durante la ejecución.
MCP
MCP (Model Context Protocol) estandariza la forma en que aplicaciones compatibles pueden exponer herramientas y contexto a modelos y agentes.
La analogía con un enchufe universal es útil siempre que no la llevemos demasiado lejos. Antes de MCP ya existían APIs, function calling, plugins y frameworks para conectar modelos con herramientas externas.
Lo que aporta MCP es un protocolo común para reducir la cantidad de mecanismos específicos necesarios para esas conexiones.
Y eso importa porque, si cada agente necesita acceder a CRM, ERP, ecommerce, soporte, facturación y documentación, el problema deja de ser únicamente qué puede razonar el modelo.
También hay que resolver cómo accede de manera consistente y gobernada a los sistemas donde vive el negocio.
Human-in-the-loop
Es el punto donde un proceso se detiene y espera aprobación humana antes de ejecutar una acción sensible.
No es una idea nueva: las organizaciones llevan mucho tiempo utilizando aprobaciones.
Lo que cambia en un sistema agentic es su función.
Si parte del camino no está completamente predeterminado, la aprobación humana se convierte también en un mecanismo para limitar hasta dónde puede llegar esa autonomía.
Pero decir “human-in-the-loop” explica muy poco por sí solo.
Hay que preguntar: ¿qué acciones requieren aprobación?, ¿quién las clasifica como sensibles?, ¿qué información recibe la persona que aprueba?, ¿puede modificar la propuesta?, ¿qué ocurre después de rechazarla?
Aquí resulta útil otra herramienta: triangular.
No evaluar una capacidad únicamente por cómo la llama el proveedor, sino contrastar al menos tres cosas: lo que promete el discurso comercial, lo que permite realmente la arquitectura y lo que ocurre en un caso concreto.
Con IA, esa distancia importa bastante.
Qué ha cambiado realmente
Podemos mirar la evolución de la integración así:
| Era | Qué mueve | Quién consume el resultado | Qué dispara la acción | Unidad de trabajo |
|---|---|---|---|---|
| ETL/ELT | Datos, normalmente en lote | Dashboards, analistas, modelos de datos | Un horario o proceso | Filas, tablas |
| iPaaS | Datos + acciones | Procesos de negocio predefinidos | Un evento | Un flujo |
| Integración para agentes | Contexto + herramientas + acciones gobernadas | Un agente que decide qué necesita | Una intención o problema | Investigación + acción |
Lo interesante es que los conectores no han dejado de ser conectores.
Salesforce sigue teniendo sus objetos. Shopify sigue teniendo productos y pedidos. Sage sigue teniendo Clientes, artículos, tarifas y documentos. Las APIs continúan imponiendo sus límites.
Lo que cambia es quién está al otro lado de la integración.
Un dashboard sabe de antemano qué columnas necesita.
Un workflow sabe qué datos necesita para ejecutar el siguiente paso.
Un agente puede no saberlo hasta que empieza a investigar.
Eso introduce un problema diferente: darle acceso a suficiente contexto para razonar sin obligarlo a reconstruir el estado del negocio mediante una sucesión caótica de llamadas a APIs.
Un cliente, por ejemplo, no es realmente “un registro de Salesforce + unos tickets de soporte + unas facturas + unos pedidos”.
Esa fragmentación pertenece a nuestra arquitectura de software, no al negocio.
Visto desde fuera —otro pequeño ejercicio de extrañamiento— resulta incluso extraño que consideremos natural tener que reconstruir una entidad empresarial cada vez que queremos hacer una pregunta sobre ella.
Ahí hay una necesidad real detrás de buena parte del nuevo vocabulario.
Pero hay tres formas muy diferentes de poner IA en una integración
Buena parte de la confusión actual viene de meter bajo la misma etiqueta tres usos distintos.
1. IA para construir la automatización
Le dices:
Cuando se apruebe una devolución, genera la nota de crédito correspondiente y utiliza el tratamiento fiscal adecuado.
La IA ayuda a convertir esa intención en configuración, reglas, mappings o un workflow.
Puede ahorrar muchísimo trabajo.
Pero una vez creado el proceso, la ejecución puede seguir siendo completamente determinista.
2. IA para investigar o decidir
Le preguntas:
¿Por qué estos 17 productos no se han publicado en el ecommerce?
Aquí no sabemos necesariamente qué información será relevante.
Quizá tenga que revisar atributos obligatorios, categorías, imágenes, reglas de publicación, errores anteriores, variantes o logs de sincronización.
La IA puede formular hipótesis, buscar evidencia y decidir qué consultar después.
Aquí sí aparece razonamiento.
3. IA para ejecutar
Después de investigar, el agente puede además modificar sistemas:
Corrige los productos y vuelve a publicarlos.
Eso introduce un nivel distinto de autonomía y, por tanto, de riesgo.
Las tres cosas pueden utilizar el mismo modelo y aparecer bajo el mismo botón de “AI”.
Pero arquitectónicamente no son equivalentes.
Interfaz con IA ≠ razonamiento ≠ ejecución autónoma.
Y probablemente deberíamos evaluarlas por separado.
Entonces, ¿cuándo necesita razonar una integración?
La pregunta no es:
¿Hay varios sistemas implicados?
Una integración ERP-ecommerce cruza sistemas constantemente sin necesitar ningún agente.
Tampoco es:
¿El proceso es complejo?
Un proceso determinista puede tener cientos de condiciones y seguir teniendo una respuesta perfectamente definida.
La pregunta más útil es:
¿Podemos definir de antemano cómo llegar a la respuesta correcta?
Si podemos hacerlo, probablemente tenemos un problema de automatización determinista.
Si para llegar a la respuesta necesitamos formular hipótesis, buscar evidencia, interpretar contexto y decidir qué investigar después, empieza a aparecer un buen caso para razonamiento.
Un ejemplo: hay 40 unidades en la web y 12 en el ERP
Una integración clásica puede detectar perfectamente:
Stock ecommerce: 40
Stock ERP: 12
Diferencia: 28
Incluso puede ejecutar una regla:
Si ERP != ecommerce
→ actualizar ecommerce con stock ERP
Pero eso no explica por qué existen 28 unidades de diferencia.
Podrían proceder de un pedido que no reservó stock correctamente, una devolución procesada dos veces, una venta simultánea en otro canal, un ajuste manual en el ERP que no generó el evento esperado o una sincronización que falló después de leer el dato pero antes de escribirlo.
Ahora ya no tenemos una simple condición.
Tenemos hipótesis.
Un agente puede consultar movimientos de almacén, pedidos, devoluciones y logs; comparar timestamps; descartar explicaciones y decidir qué evidencia necesita después.
Ahí el razonamiento aporta algo que una regla fija difícilmente puede representar sin construir previamente un enorme árbol de excepciones.
Pero hay una consecuencia importante:
que utilicemos razonamiento para diagnosticar el problema no significa que debamos utilizarlo también para ejecutar la solución.
El agente podría concluir:
El pedido 18342 reservó 28 unidades en Shopify, pero la actualización de Sage falló a las 14:03.
Y a partir de ahí, una operación determinista y gobernada puede aplicar la corrección correspondiente.
Una arquitectura razonable puede ser:
detectar → investigar → decidir → ejecutar
donde solo las partes que realmente necesitan razonamiento son probabilísticas.
No conviertas en probabilístico lo que ya sabes resolver de forma determinista.
Qué están haciendo las plataformas de integración
Mirarlas con esta separación permite entender mejor por qué productos aparentemente similares están tomando caminos diferentes.
Airbyte: preparar contexto para que otro razone
Airbyte parte de su infraestructura de conectores y replicación de datos y está desarrollando capacidades orientadas a proporcionar contexto preparado para aplicaciones y agentes.
La idea es importante porque un agente no debería tener que reconstruir cada pregunta consultando en vivo media docena de APIs si ese contexto puede prepararse previamente.
También aparece aquí el problema de relacionar entidades procedentes de distintos sistemas.
Que “Acme Inc.” en un CRM y “acme.com” en facturación representen la misma empresa no es un problema inventado por la IA —MDM, identity resolution y entity resolution llevan mucho tiempo intentando resolverlo—.
Lo nuevo es que ahora ese conocimiento puede formar parte del contexto que un agente necesita consultar dinámicamente para responder preguntas no previstas de antemano.
Workato y Celigo: gobernar herramientas y acciones
Workato y Celigo parten de otra posición: ya disponían de procesos y acciones sobre aplicaciones empresariales.
La evolución natural consiste en hacer que parte de esas capacidades puedan utilizarse desde experiencias basadas en IA y agentes, manteniendo permisos, trazabilidad y controles sobre las acciones.
También aparecen interfaces en lenguaje natural para describir automatizaciones.
Pero conviene volver a nuestra separación anterior:
que una IA construya un workflow no convierte necesariamente ese workflow en agentic.
Y eso no es una limitación.
En muchos casos es exactamente lo deseable: utilizar IA para reducir el coste de expresar la intención y mantener determinismo cuando llega el momento de procesar miles de operaciones reales.
Distillsync: modelar el significado antes de decidir quién lo consume
En integración ERP-ecommerce aparece además otro problema: no basta con conectar APIs.
Hay que entender qué representan sus datos.
PRODUCTO, VARIANTE, PRECIO, STOCK, CLIENTE o PEDIDO no son simplemente nombres equivalentes para tablas distintas. Cada sistema los modela de una forma diferente y las relaciones entre esas entidades condicionan qué operaciones tienen sentido.
Por eso un modelo semántico va más allá de resolver si dos registros representan la misma entidad.
También necesita expresar:
- qué tipo de entidad es;
- cómo se relaciona con las demás;
- qué información necesita una operación;
- qué transformaciones son válidas;
- qué decisiones existen dentro del proceso.
Ese conocimiento puede ser utilizado por un workflow determinista, por un asistente que ayude a configurar una integración o, eventualmente, por un agente que necesite investigar un problema.
El modelo de negocio subyacente y la interfaz agentic son capas distintas.
Y construir una buena segunda capa no elimina la necesidad de la primera.
¿Y qué pasa con el precio?
También cambia la economía del proceso.
El ETL y el iPaaS tradicional suelen facturar utilizando variables relativamente observables: conectores, registros, operaciones, tareas o flujos.
Con sistemas que razonan aparece otra variable.
Resolver un caso puede requerir varias búsquedas, recuperación de contexto y llamadas al modelo antes de llegar a una conclusión.
Dos incidencias que para el negocio parecen equivalentes pueden tener costes computacionales diferentes porque una requiere mucha más investigación que la otra.
Eso no hace que el modelo sea necesariamente peor.
Parte del valor consiste precisamente en evitar que una persona tenga que realizar esa investigación.
Pero cambia una pregunta importante para el comprador.
Ya no basta con saber:
¿Cuánto cuesta procesar mis 50.000 pedidos mensuales?
También puede ser necesario preguntar:
¿Cuánto cuesta investigar los casos que no siguen el camino previsto?
La segunda cifra es bastante más difícil de estimar.
Qué preguntarle a cualquier proveedor
Aquí también ayuda triangular. No basta con la feature list: hay que contrastar promesa, mecanismo y comportamiento real.
- ¿Qué parte utiliza realmente IA? ¿Configuración, diagnóstico, decisión, ejecución o varias?
- ¿Dónde vive el contexto? Si existe un Context Store, índice semántico o equivalente, ¿dónde se almacena, durante cuánto tiempo y cómo se elimina?
- ¿Cómo se separan datos e instrucciones? Un ticket, descripción de producto o comentario de cliente es información del negocio, pero para un modelo también es texto. ¿Cómo se evita que contenido no confiable se interprete como una instrucción?
- ¿Qué puede hacer el agente sin aprobación? “Human-in-the-loop” no basta como respuesta: necesitamos conocer la granularidad real de los permisos.
- ¿Qué ocurre después de una acción incorrecta? Auditoría no es rollback. Saber quién hizo algo no significa poder deshacerlo.
- ¿Cómo se factura el razonamiento? Especialmente en excepciones y casos que requieren varias consultas.
- ¿Qué conocimiento queda encerrado en la plataforma? Reglas, modelos semánticos, resolución de entidades, contexto y decisiones pueden convertirse en una forma nueva de lock-in.
- ¿Qué está realmente en producción? En un mercado que cambia tan rápido, una demo, una beta y una capacidad con SLA no son la misma cosa.
La arquitectura interesante quizá no sea “agentic”
Las categorías tecnológicas tienden a simplificar porque necesitan crear fronteras reconocibles: esto es ETL, aquello es iPaaS, esto otro es agentic AI.
Pero las organizaciones reales rara vez funcionan con fronteras tan limpias.
Un proceso empresarial contiene partes rutinarias, excepciones, decisiones, investigación, autorizaciones y acciones irreversibles.
No hay ninguna razón para que todas necesiten el mismo mecanismo.
Quizá la arquitectura más útil no sea sustituir workflows por agentes, sino combinar:
determinismo donde conocemos la respuesta; razonamiento donde necesitamos descubrirla.
Un agente puede investigar por qué un producto no se publica.
No necesitamos que improvise cómo se calcula su IVA.
Puede analizar por qué dos sistemas discrepan sobre el stock.
No necesitamos que decida libremente qué almacén descontar cada vez que llega un pedido.
Puede proponer cómo resolver una excepción que nunca habíamos visto.
No necesitamos darle libertad para reinterpretar las reglas que ya sabemos que deben cumplirse.
Mirado así, la llegada de los agentes no hace obsoleta la integración determinista.
Hace más visible algo que quizá habíamos simplificado demasiado: automatizar y razonar son problemas distintos.
Para cerrar
Cuando toda una industria cambia simultáneamente el vocabulario con el que se describe, merece la pena no aceptar inmediatamente ni el término nuevo ni la reacción contraria de que “todo es marketing”.
Podemos hacer algo más útil: extrañar lo conocido y triangular lo que se nos presenta como nuevo.
¿Qué hacía realmente el producto antes?
¿Qué puede hacer ahora que antes no podía?
¿Qué parte depende de un modelo?
¿Qué parte sigue siendo un workflow?
¿Dónde está la decisión?
¿Dónde está el riesgo?
En la integración para agentes hay sustancia real. Dar acceso gobernado a contexto empresarial disperso, permitir investigar situaciones no anticipadas y decidir dinámicamente qué información consultar son problemas genuinos.
Pero eso no significa que cada pedido, precio, factura o movimiento de stock deba convertirse en una decisión probabilística.
Por eso, antes de preguntar a un proveedor si su plataforma “es agentic”, quizá conviene empezar por una pregunta bastante menos de moda:
¿Este proceso necesita razonar o solo necesita una regla bien escrita?
Y si necesita ambas cosas, todavía mejor:
¿en qué punto termina una y debería empezar la otra?
Preguntas frecuentes
¿“Capa de contexto para agentes” es simplemente ETL o iPaaS con otro nombre?
En parte reutiliza la misma infraestructura: conectores, APIs, replicación, transformaciones y acciones siguen siendo necesarias. Lo nuevo es el consumidor. Un agente puede no saber de antemano qué información necesitará y decidir qué consultar mientras investiga. Eso exige preparar contexto, gobernar el acceso a herramientas y relacionar información distribuida entre sistemas.
¿Qué diferencia hay entre una automatización determinista y un agente IA?
Una automatización determinista ejecuta decisiones definidas de antemano: dadas las mismas condiciones, aplica la misma lógica. Un agente puede decidir durante la ejecución qué investigar, qué herramienta utilizar y cuál debería ser el siguiente paso según la evidencia que encuentra.
¿Un proceso complejo necesita necesariamente un agente?
No. Complejidad y razonamiento no son lo mismo. Una integración puede contener cientos de reglas y seguir siendo completamente determinista. La pregunta relevante es si podemos definir de antemano cómo llegar a la respuesta correcta. Si podemos, probablemente no necesitamos que un agente improvise el camino.
¿Cruzar datos de varios sistemas significa que necesito IA?
Tampoco. Una integración ERP-ecommerce cruza sistemas constantemente sin necesidad de razonamiento. La IA empieza a resultar interesante cuando no sabemos de antemano qué datos serán relevantes y necesitamos formular hipótesis, buscar evidencia y decidir qué investigar después.
¿Usar lenguaje natural convierte una automatización en “agentic”?
No. Podemos utilizar IA para describir un proceso, generar mappings o configurar reglas y después ejecutar el resultado de forma completamente determinista. Interfaz con IA, razonamiento y ejecución autónoma son capacidades diferentes y conviene evaluarlas por separado.
¿Dónde tiene más sentido aplicar razonamiento en una integración ERP-ecommerce?
Especialmente en diagnóstico, excepciones y situaciones ambiguas. Investigar por qué no se publicó un producto, explicar una discrepancia de stock o determinar la causa de un pedido que quedó en un estado incoherente son buenos candidatos. Sincronizar el stock conocido, aplicar una tarifa definida o crear un pedido siguiendo reglas establecidas normalmente no lo son.
¿Puede un agente investigar un problema sin ejecutar directamente la solución?
Sí, y en muchos casos esa separación es deseable. El agente puede recopilar evidencia, descartar hipótesis y proponer una causa o una solución. Después, una persona puede aprobarla o una operación determinista puede ejecutarla. Usar razonamiento en una parte del proceso no obliga a convertir todo el proceso en probabilístico.
¿Qué aporta MCP a todo esto?
MCP estandariza cómo aplicaciones compatibles pueden ofrecer herramientas y contexto a modelos y agentes. No sustituye las APIs ni resuelve por sí mismo la semántica de los datos, los permisos o las reglas de negocio. Facilita el acceso; entender correctamente qué significa y qué se puede hacer con aquello a lo que se accede sigue siendo otro problema.
¿Qué es human-in-the-loop y resuelve el problema de confianza?
Es un mecanismo para exigir aprobación humana antes de determinadas acciones. Reduce el riesgo, pero no lo elimina. Lo importante es conocer qué acciones requieren aprobación, quién lo decide, qué contexto recibe la persona que aprueba y qué ocurre cuando rechaza o modifica la propuesta.
¿Cómo cambia el coste cuando introducimos agentes?
En una integración clásica, buena parte del coste puede relacionarse con variables previsibles como operaciones, registros o flujos. Un agente puede añadir búsquedas, recuperación de contexto y llamadas de razonamiento cuyo número depende de la dificultad del caso. El coste puede empezar a depender no solo del volumen de negocio, sino también de la cantidad de investigación necesaria para resolver sus excepciones.
¿La IA sustituirá entonces a las integraciones y workflows tradicionales?
No necesariamente. Es más probable que ambos mecanismos convivan. Los workflows son especialmente adecuados cuando conocemos las reglas y queremos una ejecución predecible. Los agentes aportan valor cuando necesitamos investigar situaciones que no podemos anticipar completamente. Una arquitectura puede utilizar razonamiento para descubrir qué ocurre y determinismo para ejecutar después la acción correcta.
¿Cuál es la pregunta que debería hacerme antes de aplicar IA a un proceso?
No “¿podría hacerlo un agente?”, porque técnicamente cada vez más veces la respuesta será sí. La pregunta útil es: ¿este proceso necesita razonar o solo necesita una regla bien escrita? Y, si necesita ambas cosas: ¿en qué punto termina una y debería empezar la otra?