Integrar IA con sistemas legados

Integrar un agente de inteligencia artificial con los sistemas existentes de una empresa — ERP, CRM, bases de datos heredadas — es la barrera número uno en producción según la encuesta AI Agent Adoption 2026 de Gartner: el 58% de los CTOs la citan como su principal obstáculo para pasar del piloto a la producción real. El problema no es la tecnología del agente. Es que el agente, sin acceso a los datos reales de la empresa, queda aislado y pierde todo su valor operativo. La buena noticia es que la mayoría de los ERP con más de cinco años — SAP, Oracle NetSuite, Microsoft Dynamics, Epicor — ya tienen APIs que permiten esta conexión sin reemplazar ni tocar el sistema existente.

Por qué la integración es la barrera real — no la tecnología del agente

El error más frecuente al desplegar un agente IA en una empresa mediana es subestimar la complejidad de conectarlo a los sistemas donde ocurre el negocio real. El agente puede razonar perfectamente sobre datos que le das manualmente. Pero sin acceso al CRM no sabe el historial del cliente. Sin acceso al ERP no sabe el nivel de inventario. Sin acceso a la base de datos de pedidos no puede gestionar una devolución.

Un agente desconectado de los sistemas de la empresa es un asistente conversacional sofisticado, no un agente que automatiza procesos reales. La diferencia entre ambos es exactamente lo que separa los proyectos de IA que generan ROI de los que se cancelan a los seis meses.

Según IBM (2026), el 85% de los ejecutivos cree que su personal tomará decisiones en tiempo real basadas en datos mediante recomendaciones de agentes IA antes de que termine 2026. Esa predicción solo se cumple si los agentes tienen acceso a los datos. Y los datos están en los sistemas existentes, no en los LLMs.

Qué significa exactamente «sistema legado» en este contexto

Un sistema legado no es necesariamente un sistema antiguo ni obsoleto. Es cualquier sistema empresarial que no fue diseñado originalmente para integrarse con agentes IA modernos. Eso incluye desde un ERP de SAP implantado hace tres años hasta una base de datos Access desarrollada internamente hace veinte.

La complejidad de la integración depende de tres factores, no del año de implantación del sistema:

• Disponibilidad de APIs documentadas: si el sistema tiene APIs REST o SOAP bien documentadas, la integración es directa y rápida. Si no tiene APIs, requiere una capa intermedia.
• Calidad y estructura de los datos: los datos fragmentados, inconsistentes o no estructurados son el problema más infravalorado. Según CRM.org (2026), los datos incorrectos en CRM cuestan a la empresa media hasta 15 millones de dólares anuales. Un agente que lee datos incorrectos toma decisiones incorrectas.
• Arquitectura de la infraestructura: un único sistema centralizado es más sencillo de conectar que una arquitectura fragmentada con cinco sistemas distintos que no hablan entre sí.

Los 4 patrones de integración: cuál corresponde a tu caso

API directa: el camino más rápido

El agente se conecta directamente a las APIs del sistema usando tokens de autenticación. Es la opción más rápida cuando el sistema tiene APIs bien documentadas y el agente necesita consultar o modificar datos en tiempo real. Un agente conectado a Salesforce por API puede consultar el historial de un cliente, actualizar el estado de una oportunidad o crear una nueva tarea sin que ningún humano intervenga en el proceso.

La mayoría de los ERP empresariales con más de cinco años de antigüedad que han recibido actualizaciones regulares ya están técnicamente preparados para esta integración. El bloqueante habitual no es el sistema — es la documentación de las APIs y los permisos de acceso.

Middleware como puente: para arquitecturas fragmentadas

Cuando la empresa tiene múltiples sistemas distintos que no hablan entre sí — lo más frecuente en empresas que han crecido por adquisiciones o que han acumulado sistemas departamentales a lo largo de los años — el middleware actúa como traductor. El agente habla con el middleware; el middleware habla con cada sistema en su propio lenguaje.

Herramientas como MuleSoft, Dell Boomi o Azure Logic Apps permiten que el agente acceda a datos de SAP, a datos del CRM y a datos del sistema de logística en una sola consulta, aunque esos tres sistemas nunca fueron diseñados para integrarse entre sí.

Webhooks event-driven: para procesos que deben reaccionar en tiempo real

En lugar de que el agente consulte el sistema periódicamente, el sistema notifica al agente cuando ocurre un evento relevante. Ese cambio de paradigma — de polling a event-driven — reduce la latencia y el consumo de recursos significativamente.

Ejemplo real: una empresa manufacturera configura su ERP para enviar un webhook cuando las materias primas bajan del punto de reorden. El agente recibe la notificación, consulta el catálogo de proveedores, genera la solicitud de cotización y la envía por WhatsApp o email. El ERP sigue funcionando exactamente igual — el agente solo lee el evento y ejecuta el proceso que antes hacía un comprador manualmente.

Strangler Fig: para sistemas sin ninguna capacidad de API

Es el patrón más complejo y el menos frecuente. Se aplica a sistemas muy antiguos — AS400, Mainframes, aplicaciones de escritorio con bases de datos propietarias — que no tienen ninguna capacidad de API moderna. El patrón consiste en envolver el sistema existente con una capa de APIs nueva, sin tocar ni reemplazar el código original. El sistema legado sigue funcionando exactamente igual; la capa nueva le da al agente una interfaz moderna para interactuar con él.

Los errores más frecuentes — y los que más cuestan

• Empezar por limpiar todos los datos antes de integrar: el error más frecuente en empresas con datos de calidad deficiente es asumir que primero hay que limpiar todos los datos y luego integrar. Eso puede tardar meses o años. La alternativa correcta es identificar el subconjunto de datos que el agente necesita para su caso de uso específico, limpiar solo ese subconjunto, integrar y medir. Después, expandir.
• Dar al agente permisos de escritura desde el primer día: el principio de mínimo privilegio es crítico en la integración. El agente debe empezar con acceso de solo lectura al sistema. Cuando el comportamiento está validado, se amplían los permisos gradualmente. Un agente con acceso de escritura completo desde el primer día puede modificar datos de producción ante cualquier error de configuración.
• No documentar qué datos puede ver el agente: en entornos con datos sensibles — información de clientes, datos financieros, datos de empleados — es imprescindible documentar explícitamente a qué datos tiene acceso el agente y a cuáles no. Sin esa documentación, la auditoría de cumplimiento del AI Act o del RGPD es imposible.
• Integrar sin definir cómo gestiona el agente los errores del sistema: ¿qué hace el agente si el CRM no responde? ¿Si la API devuelve un error 500? ¿Si los datos que recibe son inconsistentes? Sin una política explícita de gestión de errores, el agente improvisa — y la improvisación en producción con acceso a sistemas reales puede tener consecuencias graves.

El diagnóstico previo que evita el 80% de los problemas

Antes de escribir una sola línea de código de integración, responder estas cinco preguntas reduce drásticamente el riesgo del proyecto:

1. ¿Qué datos necesita el agente para completar su tarea, exactamente? No «acceso al CRM» — qué campos concretos del CRM necesita leer y cuáles necesita modificar.
2. ¿El sistema que contiene esos datos tiene APIs documentadas y activas? Si la respuesta es sí, el patrón es API directa. Si no, necesitas determinar qué patrón alternativo aplica.
3. ¿Los datos que va a leer el agente son consistentes y actualizados? Si hay campos que se rellenan manualmente o que no se actualizan con regularidad, el agente tomará decisiones basadas en información incorrecta.
4. ¿Qué ocurre si el sistema no está disponible cuando el agente lo necesita? Definir el comportamiento de fallback antes de la integración, no después del primer incidente en producción.
5. ¿Qué acciones del agente son reversibles y cuáles no? Crear un registro es reversible. Aprobar una transferencia no. Las acciones irreversibles deben tener validación humana obligatoria, al menos durante los primeros meses.

Qué sistemas puedes conectar sin tocar su código

La mayoría de las plataformas empresariales líderes ya tienen conectores nativos o documentados para integrarse con agentes IA. Esta es la situación actual de los sistemas más frecuentes en empresas medianas españolas:

Una vez conectado el agente a los sistemas correctos, el siguiente paso es verificar que la integración funciona correctamente y se mantiene estable con el tiempo. Los AI Evals son el sistema de métricas que confirma que el agente sigue dando respuestas correctas semanas después de la integración. Y si el proyecto implica múltiples agentes especializados trabajando en paralelo, el protocolo A2A (Agent-to-Agent) define cómo se coordinan y delegan tareas entre ellos sin intervención humana.

Preguntas frecuentes sobre integración de IA con sistemas empresariales

• ¿Tengo que reemplazar mi ERP para integrar un agente IA?

  No. La integración de agentes IA no requiere reemplazar los sistemas existentes. Los patrones de integración descritos en este artículo — API directa, middleware, webhooks y Strangler Fig — están diseñados específicamente para conectar el agente con los sistemas actuales sin modificar ni reemplazar su código. El ERP, CRM o sistema legado sigue funcionando exactamente igual; el agente accede a sus datos a través de la capa de integración.

• ¿Cuánto tiempo tarda una integración típica con un CRM o ERP?

  Depende del patrón y del sistema. Una integración por API directa con un CRM como Salesforce o HubSpot puede estar operativa en una a tres semanas. Una integración con middleware para múltiples sistemas heredados requiere entre cuatro y ocho semanas. La integración con sistemas sin APIs (Strangler Fig) puede tardar dos a cuatro meses. El factor que más alarga los plazos no es la tecnología sino la disponibilidad de documentación de los sistemas y los procesos de aprobación de accesos internos.

• ¿Qué pasa con la seguridad de los datos cuando el agente accede al ERP?

  La seguridad en la integración tiene tres capas. Primera: autenticación — el agente accede al sistema con credenciales propias, no con las de un empleado, lo que permite revocar el acceso de forma independiente. Segunda: autorización — el agente solo puede acceder a los datos y acciones que su rol específico permite, aplicando el principio de mínimo privilegio. Tercera: auditoría — cada acción del agente queda registrada en un log con timestamp, identificador y resultado, lo que permite auditar el comportamiento del agente ante cualquier incidente de seguridad o requerimiento regulatorio.

• ¿El agente puede modificar datos en el ERP o solo consultarlos?

  Puede hacer ambas cosas, pero la recomendación es empezar solo con lectura. Una vez validado que el agente consulta correctamente y toma decisiones coherentes, se amplían los permisos para incluir escritura en acciones específicas y controladas. Las acciones de escritura irreversibles — como aprobar pagos, eliminar registros o enviar comunicaciones externas — deben mantener validación humana obligatoria durante al menos los primeros tres meses de producción.

• ¿La integración con el ERP afecta al rendimiento del sistema?

  Con un diseño correcto, el impacto es mínimo. El uso de GraphQL en lugar de REST genérico permite al agente pedir exactamente los campos que necesita en lugar de traer registros completos, reduciendo la carga sobre el sistema. Los webhooks event-driven eliminan las consultas periódicas que consumen recursos continuamente. La recomendación es realizar pruebas de carga antes del despliegue en producción para verificar que el volumen de peticiones del agente no degrada el rendimiento del sistema empresarial.