Integrar inteligencia artificial en sistemas legacy no empieza con la elección de un modelo, si no con una pregunta mucho más difícil: ¿qué parte del sistema actual puede evolucionar sin poner en riesgo la operación?
Muchas organizaciones que han demostrado interés en la IA han probado copilotos, herramientas de automatización, asistentes internos o modelos predictivos. Sin embargo, cuando intentan llevar esos casos de uso a producción, se encuentran con una realidad bastante incomoda: datos fragmentados, reglas de negocio embebidas en sistemas antiguos, dependencias no documentadas, procesos manuales, pruebas insuficientes y restricciones regulatorias.
El problema no es la IA; es la base tecnológica que debe sostenerla.
En sistemas legacy, añadir IA de forma superficial puede acelerar la creación de deuda técnica. Un prototipo puede funcionar bien en un entorno controlado, pero fallar cuando debe integrarse con procesos críticos, datos incompletos, controles de acceso heredados o flujos que no pueden detenerse. Por eso, la integración de IA debe tratarse como una iniciativa de modernización de software, no como un experimento aislado.
Desde la experiencia de Codurance en proyectos de modernización, el enfoque más efectivo es incremental, pragmático y gobernado. No se trata de sustituir sistemas críticos de golpe ni de envolverlos indefinidamente con soluciones tácticas. Se trata de proteger el Business As Usual, identificar dónde se genera valor, reducir riesgo progresivamente y construir capacidades modernas alrededor del legacy hasta que la organización pueda evolucionar con seguridad.
Esta guía presenta un playbook para integrar IA en sistemas legacy desde una perspectiva de Software Craftsmanship: arquitectura clara, pruebas automatizadas, observabilidad, gobierno del dato, decisiones explícitas y entrega fiable. También refleja una idea central: la velocidad solo tiene valor cuando se mantiene el control. En Codurance, esa disciplina se traduce en un 96,25% de proyectos entregados a tiempo, una señal de que la modernización efectiva depende tanto del diseño técnico como de la ejecución sostenida.
Aunque cada entorno legacy tiene sus particularidades, en la práctica la integración de IA suele adoptar tres patrones arquitectónicos: capa API wrapper, integración orientada a eventos y strangler fig con módulos de IA. La elección depende del nivel de deuda técnica, la criticidad del sistema, la calidad de los datos y la urgencia del caso de negocio.
La capa API wrapper consiste en crear una interfaz moderna alrededor del sistema heredado para exponer datos o capacidades sin modificar profundamente el core. Es útil cuando el sistema sigue siendo crítico, estable y difícil de cambiar, pero necesita conectarse con nuevos servicios o módulos de IA.
En un caso de IA, este patrón puede permitir que un modelo consulte información operativa, genere recomendaciones o enriquezca un proceso sin acceder directamente a la complejidad interna del legacy. Por ejemplo, un módulo de priorización de riesgos puede consultar datos históricos a través de APIs controladas mientras el sistema core conserva la ejecución transaccional.
La ventaja principal es que permite avanzar rápido con un perímetro seguro. También facilita aplicar autenticación, autorización, trazabilidad y límites de uso. El riesgo es que el wrapper se convierta en una capa permanente de complejidad si no se gobierna bien. Por eso debe incluir contratos claros, tests de contrato, métricas de consumo y una hoja de ruta para reducir acoplamientos con el tiempo.
Este patrón encaja cuando el sistema legacy no puede tocarse fácilmente, pero el caso de IA puede generar valor desde el perímetro.
La integración orientada a eventos permite que nuevos módulos reaccionen a hechos de negocio sin bloquear el sistema principal. En lugar de depender de llamadas síncronas punto a punto, el legacy publica eventos relevantes: una transacción validada, un expediente actualizado, una solicitud recibida o una alerta generada.
Para IA, este patrón es especialmente útil porque muchos casos de uso no necesitan controlar el flujo completo. Necesitan observar, clasificar, detectar anomalías, recomendar o enriquecer información. Un modelo puede consumir eventos, procesarlos y devolver una recomendación sin interrumpir el proceso transaccional.
Por ejemplo, un sistema core puede seguir procesando operaciones mientras un componente de IA analiza patrones anómalos o prioriza revisiones. Del mismo modo, una plataforma legacy puede continuar gestionando documentación mientras un módulo clasifica archivos o detecta casos incompletos.
La ventaja es el desacoplamiento, ya que permite introducir inteligencia alrededor del sistema sin invadirlo. Y su dificultad está en la disciplina, ya que los eventos deben tener semántica clara, versionado, idempotencia, trazabilidad y políticas de reintento. En entornos regulados, además, debe quedar claro qué evento alimentó qué recomendación, con qué datos y bajo qué versión del modelo.
El patrón strangler fig permite reemplazar progresivamente partes del sistema legacy por componentes modernos. En lugar de una migración masiva, se extraen dominios concretos y se redirige gradualmente la demanda hacia nuevas capacidades.
Cuando se combina con IA, este patrón permite construir módulos nuevos ya preparados para datos, modelos, auditoría, observabilidad y despliegue continuo. Por ejemplo, una organización puede mantener el core transaccional, pero extraer el dominio de scoring, recomendación, clasificación documental o asignación de casos hacia un servicio moderno con IA integrada desde el diseño.
Este patrón es más transformador que los anteriores, pero también exige más disciplina. Hay que tener en cuenta que requiere convivencia controlada, sincronización de datos, pruebas de regresión, mecanismos de reversibilidad y criterios explícitos para retirar funcionalidad legacy. Su valor está en que no solo integra IA, si no que además reduce deuda técnica y aumenta la capacidad futura de cambio.
Es el enfoque adecuado cuando una parte del legacy limita claramente el crecimiento o cuando el caso de IA afecta a un dominio que conviene modernizar de raíz.
Compartimos algunos ejemplos reales que sintetizan patrones habituales en proyectos de modernización que ya hemos puesto en práctica. No representan una única implementación literal, sino decisiones arquitectónicas recurrentes en organizaciones que necesitan evolucionar sistemas críticos sin interrumpir la operación.
Desafío: Una multinacional operaba sobre un core legacy estable, pero sus equipos dedicaban demasiado tiempo a revisar operaciones manualmente. El negocio quería usar IA para priorizar casos, detectar anomalías y reducir carga operativa, pero el sistema central no podía interrumpirse. Además, los datos estaban distribuidos entre el core, herramientas departamentales y conocimiento experto no documentado.
Decisión arquitectónica: Se evitó integrar el modelo directamente en el core. Primero se definió una capa API wrapper para exponer datos mínimos y controlados. Después se incorporó un flujo orientado a eventos para capturar hechos relevantes sin bloquear la operación. El módulo de IA generaba recomendaciones y niveles de prioridad, pero la decisión final permanecía bajo control humano.
Se registraba la versión del modelo, la fuente de datos, el evento que disparaba el análisis y la acción tomada por el usuario. También se definió un fallback: si el componente de IA no estaba disponible, el proceso manual anterior seguiría funcionando.
Resultado: La organización redujo los tiempos de revisión en casos de baja complejidad, mejoró la trazabilidad y creó una base para automatización futura sin comprometer el core. El aprendizaje más importante fue que el verdadero valor no vino de sustituir decisiones humanas, sino de hacer el proceso más observable, consistente y priorizable.
Desafío: Una organización (con una estructura fuertemente jerarquizada que condicionaba el acceso a la información) gestionaba grandes volúmenes de documentación en una plataforma heredada con años de adaptaciones funcionales. El volumen de información crecía y los tiempos de tramitación dependían de clasificación manual. La organización quería usar IA para clasificar documentos, detectar casos incompletos y asistir a los equipos, pero una sustitución completa del sistema era inviable por riesgo operativo y restricciones presupuestarias.
Decisión arquitectónica: Se eligió un enfoque strangler fig limitado al dominio de entrada documental. El legacy siguió siendo el sistema de registro principal, pero se construyó un módulo moderno para recibir documentos, extraer metadatos, aplicar clasificación asistida por IA y enviar resultados validados al flujo existente.
El diseño incluyó revisión humana en decisiones sensibles, minimización de datos personales, registro de accesos y trazabilidad de cada recomendación. La IA no actuaba como autoridad final, sino como asistente operativo dentro de un proceso gobernado.
Resultado: La organización pudo introducir IA sin reemplazar todo el ecosistema. Se redujo la carga manual en la clasificación inicial y se mejoró la consistencia del proceso. Más importante aún, el nuevo módulo creó una base reutilizable para futuros servicios digitales sin aumentar la dependencia del legacy.
Desafío: Una organización financiera quería avanzar hacia analítica avanzada e IA predictiva, pero sus datos procedían de múltiples sistemas históricos con definiciones inconsistentes. Los informes requerían reconciliación manual y los equipos no confiaban plenamente en los datasets disponibles.
Decisión arquitectónica: La organización decidió no empezar por el modelo. Primero se modernizó la plataforma de datos: dominios de información, contratos de datos, reglas de calidad, linaje y controles de acceso. La integración orientada a eventos permitió construir una vista más consistente sin reemplazar todos los sistemas fuente.
Los primeros casos de IA se limitaron a usos de bajo riesgo: detección de anomalías, sugerencias de limpieza y alertas operativas. Cada resultado se contrastaba con reglas deterministas y revisión humana.
Resultado: La organización redujo el esfuerzo de reconciliación, aumentó la confianza en los datos y creó una base gobernada para casos de IA más ambiciosos. La decisión crítica fue asumir que “tener datos” no equivale a “tener datos preparados para IA”.
Las guías genéricas de IA descreiben muchas veces una secuencia limpia: identificar caso de uso, preparar datos, elegir modelo, integrar y desplegar. En legacy, la realidad con la que hay que lidiar es bastante más compleja. Los problemas aparecen en los margenes: datos ambiguos, reglas no documentadas, procesos manuales, restricciones regulatorias y flujos imposibles de detener.
La IA necesita datos accesibles, consistentes, representativos y trazables. Los sistemas legacy suelen fallar en alguna de estas dimensiones. Lo más habitual es que haya clientes duplicados, campos reutilizados con significados distintos, históricos incompletos o reglas aplicadas fuera del sistema.
Antes de integrar IA, hay que evaluar cuatro aspectos: disponibilidad, consistencia, trazabilidad y adecuación al uso. La pregunta no es solo si el dato existe, sino si puede sostener una recomendación o decisión en producción.
En modernización, preparar el dato no es una fase administrativa, si no parte fundamental de la arquitectura del producto.
En software tradicional se versiona el código. En IA también hay que versionar modelos, datasets, prompts, features, umbrales y configuraciones. Sin esto, la organización no puede responder a una pregunta básica: ¿por qué se generó esta recomendación en este momento?
En entornos regulados, cada salida relevante debería poder asociarse a la versión del modelo, la fecha de inferencia, la fuente de datos, las variables utilizadas, el nivel de confianza, la intervención humana y la decisión final.
Esto no es burocracia, es la base para las auditorías, las reclamaciones, y poder explicar decisiones e iniciativas de mejora continua.
Probar IA integrada en legacy no consiste solo en medir precisión del modelo. Hay que probar el flujo completo. Un enfoque robusto combina tests de caracterización para capturar el comportamiento actual, tests de contrato entre sistemas, pruebas de regresión funcional, golden datasets para casos conocidos, pruebas de privacidad y tests de reversibilidad.
La pregunta clave no es si el modelo acierta, sino si el sistema completo sigue siendo correcto, auditable y recuperable cuando el modelo se equivoca o no está disponible.
La observabilidad debe cubrir tanto el sistema como el modelo. Además de latencia, disponibilidad y errores, hay que monitorizar drift, distribución de inputs, confianza media, porcentaje de casos automatizados, revisiones humanas, decisiones revertidas e impacto operativo.
Sin observabilidad, la IA se convierte en una caja negra dentro de otra caja negra. Con observabilidad, puede gestionarse como una capacidad de negocio.
No todos los sistemas legacy deben modernizarse antes de integrar IA, pero tampoco conviene integrar IA en cualquier sistema sin evaluar antes si la arquitectura, los datos y los controles existentes pueden sostenerla con seguridad. La decisión debe basarse en criterios concretos.
Tiene sentido integrar antes de modernizar profundamente si el sistema es estable, crítico y difícil de modificar, pero el caso de IA puede generar valor desde el perímetro. Esto aplica cuando los datos necesarios pueden exponerse de forma segura, el caso de uso es asistivo o recomendacional, y existe una forma clara de revertir al proceso anterior.
Ejemplos: priorización de casos, clasificación inicial, detección de anomalías, generación de resúmenes o asistencia a equipos internos.
Conviene modernizar antes de integrar IA cuando el sistema no permite cambios seguros. Señales claras son: alto nivel de incidencias tras despliegues, ausencia de pruebas automatizadas, datos inconsistentes, reglas de negocio opacas, dependencias sin soporte, falta de observabilidad o decisiones de alto impacto regulatorio.
En estos casos, añadir IA probablemente aumentará la complejidad. La prioridad debe ser estabilizar, desacoplar y crear una base gobernada.
En muchos contextos, la respuesta correcta es una mezcla de ambas aproximaciones. Se puede integrar IA en un dominio acotado mientras se moderniza progresivamente la arquitectura. La condición es que cada integración táctica contribuya a la arquitectura futura y no se convierta en un parche permanente.
Una matriz práctica puede ir en esta linea:
| Criterio | Señal favorable para integrar | Señal favorable para modernizar primero |
|---|---|---|
| Edad y soporte del sistema | Stack soportado y estable | Dependencias obsoletas o sin soporte |
| Deuda técnica | Cambios localizados y comprensibles | Cambios lentos, frágiles y costosos |
| Criticidad de negocio | Uso de apoyo a equipos humanos o bajo riesgo |
Decisiones críticas o reguladas |
| Calidad de datos | Datos trazables y suficientes | Datos inconsistentes o no gobernados |
| Capacidad de cambio | Tests, despliegue y rollback razonables | Sin pruebas, sin observabilidad, sin reversibilidad |
Si la criticidad es alta y la capacidad de cambio baja, modernizar primero es más seguro. Si la capacidad de cambio es razonable y el caso de IA está acotado, integrar puede ser una vía efectiva para generar valor temprano.
En España y la Unión Europea, integrar IA en sistemas legacy implica considerar privacidad, seguridad, residencia de datos y gobernanza desde el diseño. Esto es especialmente relevante en banca, seguros, salud, administración pública y cualquier entorno con datos personales o decisiones de impacto.
El GDPR exige base legítima, finalidad clara y tratamiento proporcionado. En IA, esto obliga a responder preguntas concretas: qué datos se usan, por qué son necesarios, si se reutilizan para una finalidad distinta, cuánto tiempo se conservan y cómo se explican las recomendaciones.
La minimización es clave: No todo dato disponible debe usarse. En legacy, donde la clasificación de información suele ser débil, conviene mapear datos sensibles, aplicar seudonimización cuando sea posible y evitar que datos reales pasen a entornos de prueba sin controles.
La residencia de datos no puede revisarse al final, y es algo que debe formar parte de la arquitectura. Si se utilizan servicios cloud o proveedores de IA, hay que evaluar regiones de procesamiento, acuerdos de tratamiento de datos, políticas de retención y garantías de no reutilización de datos para entrenamiento externo.
En casos sensibles, puede ser preferible desplegar modelos en entornos controlados o limitar el uso de servicios externos a datos anonimizados.
La IA amplía la superficie de ataque. Un módulo que resume expedientes, consulta clientes o clasifica documentos puede exponer información sensible si no tiene controles estrictos. Hay que revisar identidad, autorización, cifrado, logging, secretos, cuentas de servicio y límites de acceso.
También deben contemplarse riesgos específicos como manipulación de inputs, prompt injection en soluciones basadas en LLMs o exposición accidental de datos en respuestas generadas.
La gobernanza define quién aprueba casos de uso, quién valida modelos, quién monitoriza resultados, quién puede cambiar umbrales y quién responde ante incidencias.
Un marco mínimo debería incluir clasificación de casos por riesgo, revisión legal y de privacidad, criterios de aceptación, documentación de datasets y modelos, revisión humana en decisiones sensibles, monitorización continua y procedimiento de rollback.
La IA puede acelerar la operación, pero es la gobernanza la que asegura que esa velocidad no erosione la confianza.
Mapear flujos de valor, sistemas críticos, dependencias, datos, restricciones regulatorias y capacidad del equipo. La salida debe ser un diagnóstico priorizado: dominios candidatos, riesgos, readiness de datos y oportunidades de valor temprano.
Elegir entre API wrapper, eventos o strangler fig según criticidad, deuda técnica y objetivo de negocio. Documentar trade-offs: velocidad, coste, riesgo, reversibilidad y contribución a la arquitectura futura.
Definir inventario de datos, calidad, linaje, permisos, retención y datasets de validación. Establecer roles, aprobaciones, criterios de riesgo y requisitos de auditoría antes de escalar.
Empezar con un dominio acotado y preferiblemente asistivo. Integrar IA con contratos claros, pruebas automatizadas, logs, métricas, feature flags y mecanismos de fallback.
Validar precisión, estabilidad, seguridad, privacidad, latencia, sesgos, explicabilidad, impacto operativo y capacidad de reversión. Incluir a negocio, tecnología, seguridad, legal y operaciones.
Desplegar por fases: pilotos controlados, grupos limitados, monitorización intensiva y ampliación gradual. Después del despliegue, mantener revisión continua de drift, rendimiento, calidad de datos y evolución arquitectónica.
La mayoría de guías sobre IA y legacy son demasiado genéricas. Recomiendan modernizar, integrar APIs, preparar datos o elegir modelos, pero no explican cómo tomar decisiones cuando el sistema no puede detenerse, el conocimiento está concentrado en pocas personas y el negocio necesita resultados en plazos concretos.
El enfoque de Codurance se diferencia por su pragmatismo y la capacidad para operar manteniendo el negocio 100% operativo en todo momento. Integrar IA no consiste en aplicar una receta, sino en tomar decisiones de arquitectura bajo restricciones reales. A veces conviene envolver el legacy con APIs, otras veces conviene escuchar eventos, otras quizá hay que extraer un dominio completo, y otras la decisión responsable es no integrar IA todavía, sino modernizar primero la base.
Nuestra filosofía Software Craftsmanship aporta una disciplina concreta para navegar esos trade-offs: diseño simple, código mantenible, pruebas automatizadas, integración continua, refactorización segura, colaboración estrecha con negocio y responsabilidad compartida sobre el resultado. Los principios del Software Craftsmanship en la era de la IA son aún más importantes, porque el riesgo de crear “legacy instantáneo” es alto cuando se prioriza la velocidad sobre la comprensión.
La integración efectiva de IA en sistemas legacy no se mide por cuántos modelos se despliegan, sino por la capacidad de la organización para cambiar con seguridad. Esa capacidad se construye con arquitectura evolutiva, datos gobernados, observabilidad, equipos preparados y una ejecución fiable.
El objetivo no es añadir IA al legacy, si no transformar progresivamente sistemas heredados en plataformas capaces de sostener innovación continua.
La IA aporta aceleración. La modernización aporta control. El oficio de ingeniería convierte ambas cosas en ventaja competitiva.