Integrar agentes de IA con sistemas heredados: por dónde empezar

Los pilotos de IA en empresas grandes casi nunca se caen por el modelo. Se caen antes, en un sitio mucho menos vistoso: el agente no llega a los datos.

La demo se hizo con un extracto en una hoja de cálculo y funcionaba. En cuanto hay que consultar el sistema real aparece la verdad: los datos viven en un ERP al que se accede por un protocolo de hace veinte años, en un CRM cuyo modelo nadie ha documentado nunca del todo, y en un servicio que solo responde bien si le mandas los campos en cierto orden.

El sistema heredado no es el problema. El problema es que nadie ha construido la pieza intermedia.

La tentación de reescribir

Cuando esto se ve claro, la primera propuesta que aparece siempre es la misma: modernizar el sistema. Es la peor decisión posible en ese momento, por dos razones.

La primera es de plazos. Sustituir un ERP es un proyecto de años, y el proyecto de IA se muere esperando.

La segunda es de fondo, y es la que importa: el sistema heredado suele funcionar. Lleva quince años calculando bien lo que tiene que calcular. Lo que no tiene es una forma razonable de ser consultado desde fuera. Eso no es un defecto del sistema, es una capa que le falta.

Reescribir para poder integrar es tirar quince años de reglas de negocio validadas por un problema de acceso.

Lo que hay que construir

Delante del sistema, no en su lugar. Una capa que expone sus datos y sus operaciones de forma consumible, con control sobre quién hace qué.

Y aquí hay una decisión que se toma mal muy a menudo. La tentación es exponer el sistema tal cual: una operación por tabla, un endpoint por entidad. Sale rápido y funciona para una aplicación, porque la aplicación ya sabe qué quiere.

Un agente no lo sabe. Si le das treinta operaciones llamadas como las tablas del ERP, tiene que reconstruir el modelo de negocio a partir de nombres técnicos antes de poder decidir nada. Y lo va a hacer regular.

Lo que hay que exponer son capacidades con nombre de negocio: consultar el estado de un pedido, dar de alta un cliente, comprobar si una factura está conciliada. Cada una puede estar tocando cuatro tablas por debajo, y da igual. El agente no necesita saber cómo está montado el sistema, necesita saber qué puede pedirle.

Ese cambio de granularidad es el trabajo de verdad. Todo lo demás es fontanería.

El orden que funciona

Empieza por el proceso, no por el sistema. Elige una cosa concreta que quieras que el agente resuelva de principio a fin. Todo lo que no haga falta para eso no se toca. Inventariar el ERP entero antes de empezar es una forma elegante de no empezar nunca.

Averigua qué necesita saber y qué necesita poder hacer. Son dos listas distintas y la segunda es la que da miedo, porque escribir en un sistema heredado es donde está el riesgo real.

Expón esas operaciones con permisos y trazabilidad desde el primer día. No como una fase posterior de endurecimiento. Un agente que puede escribir sin límite en producción es un incidente esperando fecha, y añadir el control después obliga a rehacer la capa.

Conecta el agente ahí, nunca al sistema en crudo. Si el agente tiene credenciales directas contra el ERP, has creado una dependencia que nadie va a poder auditar ni revocar.

Lo que esta capa te da además

Merece la pena verlo, porque cambia el cálculo de si compensa.

Esa capa no la consume solo el agente. La consume el siguiente agente, y la aplicación móvil, y el portal del cliente, y la automatización que alguien pedirá dentro de seis meses. Es la inversión que se amortiza sola, mientras que la conexión directa hay que rehacerla cada vez.

Y da algo menos evidente: un sitio donde poner el freno. Cuando alguien pregunte qué puede hacer exactamente el agente contra los sistemas de la empresa, la respuesta es esa capa. No hay que auditar el comportamiento del modelo, hay que mirar qué operaciones están expuestas. Eso es lo que convierte un experimento en algo que se puede aprobar.

Cuándo esto es exagerado

Si el sistema al que hay que llegar ya tiene una API moderna y bien pensada, no hace falta capa ninguna. Conecta el agente y sigue.

Y si lo que quieres es explorar si un caso de uso tiene sentido, no montes infraestructura: haz la prueba con datos de mentira y sal de dudas. La capa de integración se construye cuando ya sabes que vas a producción, no para averiguarlo.

Lo que no funciona es lo intermedio: un piloto que toca sistemas reales por la puerta de atrás con la promesa de ordenarlo más adelante. Eso no se ordena nunca, se queda.

---

Sobre cómo debería estar diseñada esa capa cuando quien la consume es un agente y no una aplicación, escribí Tu arquitectura de integración no está preparada para lo que viene.