Cómo integrar IA en sistemas heredados sin sustituirlos (guía 2027)

Respuesta corta: sí se puede añadir IA a un sistema heredado sin sustituirlo. La clave es no tocarlo al principio. Primero se leen sus datos (una exportación, una réplica de solo lectura, una vista de base de datos), se trabaja con ellos fuera y solo se escribe de vuelta cuando el flujo está probado, con permisos mínimos, un registro de cada acción y una persona que aprueba lo que cambia. Primero va la integración; la IA entra donde compensa: clasificar, extraer, resumir y redactar.

Esta guía es para quien tiene un ERP de hace veinte años, una base de datos de Access que solo entiende una persona, procesos que viven en Excel, un AS/400 o un programa de proveedor sin API, y quiere automatizar sin meterse en un proyecto de sustitución completo.

Por qué no hace falta sustituir el sistema

Un sistema heredado suele hacer bien lo que hace. Lleva años facturando, guardando pedidos o controlando el stock. El problema casi nunca está en el núcleo, sino en todo lo que lo rodea: datos que se copian a mano de una pantalla a otra, informes que alguien rehace cada lunes, correos que se leen y se vuelven a teclear. Ahí es donde entra la automatización, y para eso el sistema no tiene que cambiar.

Microsoft describe en su Azure Architecture Center el patrón de la higuera estranguladora: una fachada delante del sistema antiguo que permite sustituir funciones poco a poco mientras el sistema sigue funcionando. No hace falta llegar a sustituir nada para aprovechar la idea de fondo: el sistema viejo sigue siendo la fuente de verdad y lo nuevo se construye a su alrededor.

Patrones de integración, de menos a más invasivo

Empieza siempre por el primero que resuelva tu caso. Cada paso hacia abajo da más capacidad, y también más riesgo.

1. Exportación o réplica de solo lectura. Casi todos los sistemas exportan a CSV o Excel, o permiten programar un informe. Si la base de datos lo admite, una réplica o un usuario de solo lectura es todavía mejor. No se puede romper nada porque no se escribe nada.
2. Carpeta vigilada. El sistema deja un fichero en una carpeta y un proceso lo recoge. O al revés: generas un fichero con el formato que el sistema ya sabe importar. Muchos ERP antiguos llevan décadas importando ficheros planos; es una puerta que ya existe.
3. Vistas de base de datos. Una vista es una consulta guardada que se comporta como una tabla (la documentación de SQL Server lo explica con detalle). Sirve para exponer solo las columnas necesarias, con nombres claros, a un usuario que no ve nada más.
4. La API del proveedor, si existe. Antes de construir nada, pregunta. Muchos programas tienen una API o un módulo de integración que nadie en la empresa ha activado. Es el camino soportado y respeta las reglas de negocio del propio sistema.
5. Un servicio intermedio delante del sistema. Cuando no hay API, se construye una capa pequeña que traduce: recibe peticiones limpias y habla con el sistema antiguo en su idioma. Microsoft la llama capa contra daños, porque protege el diseño nuevo de las rarezas del viejo. Es el sitio natural para los permisos, la validación y el registro.
6. RPA o automatización de pantalla, como último recurso. Un robot que hace clic donde lo haría una persona. Funciona cuando no hay otra puerta, pero se rompe con cualquier cambio en la pantalla y cuesta auditarlo. Úsalo para un paso concreto y con fecha de retirada, no como base de nada.

Dónde ayuda la IA y dónde es mejor código normal

La IA es buena con el lenguaje y con el texto desordenado. Encaja en cuatro tareas:

• Clasificar: qué tipo de correo, incidencia o pedido es, y a quién le toca.
• Extraer: número de pedido, importe, fecha o referencia de un PDF, un correo o la foto de un albarán, para que alguien lo revise en lugar de teclearlo.
• Resumir: un historial largo de cliente o de incidencia, en cinco líneas.
• Redactar: un borrador de respuesta que una persona aprueba antes de enviarlo.

Todo lo que tiene una regla clara va mejor en código: cálculos, totales, impuestos, stock, fechas, validar un NIF, sincronizar dos sistemas, mover un fichero. Si se puede escribir como regla, escríbelo como regla. Cuesta menos ejecutarlo, da siempre el mismo resultado y se puede probar. Lo contamos con un caso real en agentes de IA vs flujos de trabajo: el modelo propone y el código decide.

En la práctica, la mayor parte de un proyecto así es integración y datos. La IA ocupa un tramo concreto del flujo, y es mejor así.

Calidad y propiedad de los datos

Un sistema heredado arrastra años de historia: clientes duplicados, campos que se usan para otra cosa, códigos que solo entiende quien los creó. La IA no arregla eso. Lo amplifica. Antes de automatizar:

• Decide cuál es la fuente de verdad de cada dato. Si un cliente existe en el ERP y en una hoja de Excel, uno de los dos manda.
• Apunta los campos que no significan lo que dice su nombre. Ese campo «observaciones» que en realidad guarda el teléfono de contacto.
• Mide antes de empezar. Cuántos registros están incompletos, cuántos duplicados. Así sabrás si la automatización mejora algo.
• Nombra un responsable de negocio para cada flujo. No de TI: alguien que sepa decir si un resultado es correcto.

El RGPD ya pide que los datos personales sean exactos y estén actualizados (artículo 5.1.d). Un proyecto de automatización es un buen momento para tomárselo en serio.

Seguridad y RGPD: lo básico

Esto no es asesoría legal, pero estas prácticas salen de las normas y de las guías oficiales:

• Mínimo privilegio. Cada integración con su propio usuario y solo los permisos que necesita. INCIBE lo recomienda en su política de control de acceso para pymes, junto con registrar quién accede a la información. Nunca uses la cuenta de administrador del ERP para una integración.
• Solo lectura primero. Un flujo que solo lee no puede estropear la base de datos. La escritura llega después, cuando el flujo está probado.
• Minimización. El RGPD pide datos «adecuados, pertinentes y limitados a lo necesario» (artículo 5.1.c) y protección de datos desde el diseño y por defecto (artículo 25). Si el modelo solo necesita el texto de la incidencia, no le mandes el nombre y el teléfono del cliente. La Guía de Privacidad desde el Diseño de la AEPD es un buen punto de partida.
• Registro. Cada lectura, cada propuesta de la IA y cada escritura, con fecha y origen. Si algo sale mal, tiene que poder reconstruirse.
• Una persona antes de cualquier escritura. OWASP incluye la agencia excesiva entre los riesgos principales de las aplicaciones con modelos de lenguaje, y recomienda limitar los permisos al mínimo y que una persona apruebe las acciones de alto impacto. Además, el artículo 22 del RGPD limita las decisiones basadas únicamente en un tratamiento automatizado que afecten de forma significativa a una persona.
• Transparencia. Si la IA habla directamente con clientes, el Reglamento europeo de IA exige que sepan que están hablando con un sistema de IA (artículo 50). También pide que quien lo use en la empresa tenga una formación suficiente (artículo 4).
• Proveedor. Si mandas datos personales a un servicio de IA externo, ese proveedor trata datos por cuenta tuya y necesitas un contrato de encargado con él (artículo 28 del RGPD).

Cómo hacerlo: diagnóstico y construcción hasta producción

Lo que funciona es separar dos fases.

Un diagnóstico corto y acotado. Se mapea un flujo concreto de principio a fin: de dónde salen los datos, quién los toca, dónde se pierde el tiempo. Se revisan las puertas que tiene el sistema (exportaciones, base de datos, API, ficheros) y se elige el patrón menos invasivo que sirva. El resultado es un plan con alcance cerrado, los riesgos a la vista y una decisión clara sobre qué va en código y qué en IA. En SME Analytica lo llamamos Reconocimiento.

Una construcción de alcance cerrado hasta producción. Un solo flujo, con usuarios reales y en el entorno real, empezando en solo lectura. Se pasa a escribir cuando los resultados se han revisado y el responsable de negocio lo aprueba. Lo llamamos Lanzamiento. Lo importante es que termine en producción, no en una demo.

Es como hemos construido nuestros propios sistemas: Conversa, un agente de WhatsApp conectado al CRM de una inmobiliaria, y Facturia, automatización de facturación. Si tu caso toca la facturación, el contexto normativo está en nuestra guía de VeriFactu 2027.

Por qué fallan estos proyectos

• Pilotos que se quedan en demo. Funciona con diez ejemplos elegidos y nadie lo conecta al sistema real. Si el piloto no toca datos reales desde el principio, aunque sea en solo lectura, no está probando lo difícil.
• Escribir en el sistema heredado demasiado pronto. Una integración que escribe sin haberse probado antes en lectura puede crear duplicados o pisar datos en un sistema que no tiene una forma fácil de deshacer.
• Nadie es el dueño. Sin una persona de negocio responsable del flujo, nadie revisa los resultados, nadie decide cuándo pasar a escribir y el proyecto se apaga solo.
• Empezar por la IA. Elegir modelo antes de saber qué datos hay y por dónde salen. El orden es el contrario: flujo, datos, integración y, al final, IA.
• RPA como cimiento. Un robot de pantalla que lleva todo el flujo se rompe con la próxima actualización del proveedor.
• Ningún plan para cuando algo falla. Si la IA no está segura o el sistema no responde, el caso tiene que pasar a una persona con todo el contexto, no perderse. Lo explicamos en la guía de traspaso humano y RGPD.

Checklist para guardar

• Hay un flujo concreto elegido y una persona de negocio responsable.
• Sabemos qué puertas tiene el sistema: exportación, base de datos, API, ficheros.
• Empezamos por el patrón menos invasivo que resuelve el caso.
• La integración tiene su propio usuario, con permisos mínimos y en solo lectura.
• Al modelo solo le llegan los datos que necesita.
• Lo que tiene una regla clara va en código; la IA clasifica, extrae, resume o redacta.
• Cada lectura, propuesta y escritura queda registrada.
• Una persona aprueba cualquier escritura en el sistema heredado.
• Si la IA habla con clientes, saben que es una IA.
• Hay contrato de encargado con el proveedor de IA.
• El piloto usa datos reales y tiene fecha para pasar a producción.
• Cuando algo falla, el caso pasa a una persona.

Cómo trabajamos en SME Analytica

Hacemos integración de sistemas, software a medida e IA: conectamos datos, aplicaciones y sistemas heredados, con IA donde compensa. Trabajamos con tu equipo de TI o junto a tu proveedor actual, no en su contra. Si tienes un sistema que no quieres tocar y un proceso que sí quieres automatizar, empieza por un Reconocimiento. Cuéntanos qué tienes.