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

Los pilotos de IA en empresas grandes casi nunca se rompen por culpa del modelo. Normalmente el problema aparece antes, en un sitio bastante menos interesante: el agente no consigue llegar a los datos.

La demo se hizo con un extracto en una hoja de cálculo y todo funcionaba perfectamente. Luego toca conectarlo al sistema real y aparece la situación de verdad: los datos están en un ERP al que se accede mediante un protocolo de hace veinte años, en un CRM cuyo modelo nadie ha terminado de documentar y en un servicio que funciona bien siempre que los campos lleguen exactamente en el orden que espera.

El sistema heredado no suele ser el problema.

El problema es que falta una pieza entre ese sistema y lo que queremos construir ahora.

La tentación de reescribirlo todo

Cuando esto se hace evidente, suele aparecer la misma propuesta: modernizar el sistema.

En ese momento, normalmente es una mala idea.

Primero está el plazo. Sustituir un ERP puede llevar años. Si el proyecto de IA necesita esperar a que termine esa transformación, probablemente no llegará a producción.

Pero hay una razón más importante: el sistema heredado normalmente funciona.

Puede llevar quince años haciendo correctamente los cálculos y aplicando las reglas de negocio que necesita la empresa. Lo que no tiene es una forma cómoda de que otros sistemas puedan consultarlo o utilizar sus operaciones.

Eso no significa que haya que tirarlo.

Significa que le falta una capa de acceso.

Reescribir un sistema entero para poder integrar un agente es, en muchos casos, tirar por la borda años de reglas de negocio que ya han sido probadas y validadas simplemente porque ahora necesitamos acceder a ellas de otra manera.

La pieza que hay que construir

La solución está delante del sistema, no en sustituirlo.

Hace falta una capa que permita exponer sus datos y operaciones de una forma que otros sistemas puedan consumir, con permisos y control sobre quién puede hacer cada cosa.

Aquí aparece una decisión que se suele tomar mal.

La opción rápida es exponer el sistema prácticamente tal cual está: una operación por tabla, un endpoint por entidad, nombres heredados directamente de la base de datos.

Para una aplicación tradicional puede funcionar. La aplicación ya sabe lo que quiere hacer y cómo tiene que combinar esas operaciones.

Un agente no parte de esa información.

Si le damos treinta operaciones con nombres heredados de las tablas del ERP, tendrá que reconstruir el modelo de negocio antes de poder decidir qué hacer. Y no es precisamente el mejor trabajo que podemos pedirle.

Es mucho mejor exponer capacidades expresadas en términos de negocio:

• Consultar el estado de un pedido.
• Dar de alta un cliente.
• Comprobar si una factura está conciliada.
• Consultar el límite de crédito de un cliente.
• Actualizar determinada información de un pedido.

Cada una de esas operaciones puede implicar cuatro tablas, varias consultas y bastante lógica interna.

Al agente le da igual.

No necesita conocer cómo está construido el ERP. Necesita saber qué cosas puede pedirle.

Ese cambio de granularidad es, probablemente, la parte más importante del trabajo.

Lo demás es infraestructura.

El orden que suele funcionar

Empieza por el proceso, no por el sistema

Elige una tarea concreta que quieras que el agente pueda resolver de principio a fin. Todo lo que no sea necesario para ese caso puede esperar.

Intentar inventariar primero todo un ERP es una forma bastante sofisticada de retrasar el proyecto indefinidamente.

Define qué información necesita consultar y qué acciones necesita ejecutar

Son dos listas diferentes.

La primera suele ser relativamente sencilla. La segunda merece bastante más atención, porque escribir o modificar información en un sistema heredado es donde aparece buena parte del riesgo.

Expón las operaciones con permisos y trazabilidad desde el principio

No lo dejes para una futura fase de «seguridad».

Un agente que puede escribir sin límites en producción es, básicamente, un problema esperando a ocurrir. Y añadir los controles después significa que probablemente tendrás que rehacer parte de la integración.

Conecta el agente a esa capa, nunca directamente al sistema

Si el agente tiene credenciales contra el ERP y puede operar directamente sobre él, has creado una dependencia difícil de controlar.

¿Quién sabe qué puede hacer?

¿Quién puede revocarlo?

¿Quién puede revisar lo que ha hecho?

¿Y cómo sabes exactamente qué ocurrió cuando algo salga mal?

La capa intermedia debería responder a esas preguntas.

Lo que esta capa aporta además

Hay un beneficio que muchas veces no se ve al principio.

Esa capa no tiene por qué servir únicamente para el agente que estás construyendo ahora.

Mañana puede utilizarla otro agente. También una aplicación móvil, un portal de clientes o una automatización que alguien necesite dentro de seis meses.

La inversión se reutiliza.

En cambio, una conexión directa entre cada nuevo consumidor y el sistema heredado obliga a repetir el problema una y otra vez.

Pero hay algo todavía más importante: esa capa se convierte en el lugar donde puedes poner límites.

Cuando alguien pregunte qué puede hacer exactamente un agente contra los sistemas de la empresa, la respuesta debería estar ahí.

No hace falta intentar auditar cada decisión interna del modelo para saber qué operaciones tiene disponibles. Basta con revisar qué capacidades están expuestas y con qué permisos.

Eso hace que la integración sea mucho más fácil de gobernar y, sobre todo, de aprobar.

¿Y si el sistema ya tiene una buena API?

En ese caso, no hay que complicarlo.

Si el sistema al que necesitas llegar ya dispone de una API moderna, bien diseñada y con los controles adecuados, conecta el agente y continúa.

Tampoco hace falta construir toda esta infraestructura para descubrir si un caso de uso merece la pena.

Si todavía estás explorando la idea, utiliza datos ficticios y haz el piloto.

La capa de integración tiene sentido cuando ya sabes que quieres llevar el caso a producción, no como requisito para averiguar si el caso funciona.

Lo que suele salir mal es quedarse a medio camino.

Un piloto que toca sistemas reales por la puerta de atrás con la promesa de «ya lo ordenaremos después» acaba generando una integración provisional que se convierte en definitiva.

Y cuando eso ocurre, nadie quiere tocarla.

La regla sencilla

Si tuviera que resumirlo en una idea, sería esta:

No modernices todo el sistema para poder conectar un agente. Construye la capa que necesitas para que el agente pueda utilizar lo que ya funciona.

Empieza por un proceso concreto. Expón capacidades de negocio, no tablas. Controla los permisos desde el primer día y registra lo que ocurre.

Y, sobre todo, evita que el agente tenga acceso directo al sistema heredado.

El objetivo no es hacer que un ERP de hace veinte años parezca moderno.

Es conseguir que un sistema nuevo pueda utilizarlo sin tener que conocer todos los secretos que se han acumulado dentro durante esos veinte años.

---

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