Migración de modelos de datos con IA: cuándo acelera y cuándo es un riesgo

¿Cuánto tardarías en migrar decenas de informes pegados a su fuente, sin parar de desarrollar, y con la certeza de que la traducción es correcta?

ÁLVARO GONZÁLEZ-IGLESIAS
Data Engineer

Imagina tener un conjunto de informes que ya funciona, que responde a necesidades reales del negocio y que se conecta directamente a la fuente sin ninguna capa de control en medio y tienes que levantar una plataforma de datos sobre él. ¿Cómo abordas esa migración de modelos de datos sin frenar lo que ya está en producción? ¿Ayudaría la IA a migrar decenas de informes pegados a su fuente, sin parar de desarrollar, y con la certeza de que la traducción es correcta? Y, más interesante aún, ¿dónde tiene sentido apoyarse en un modelo de lenguaje (LLM) y dónde no?

Estas, y algunas preguntas más, son las que intento responder en este artículo en el que cuento mi experiencia real de una migración de modelos de datos con IA.

La gravedad invisible: silos de conocimiento y trabajo duplicado

El escenario de partida es más común de lo que parece: cada informe tenía su propia conexión directa a la fuente y su propio modelo de datos. No se trataba de un error de diseño, sino del resultado natural de resolver problemas concretos con los medios disponibles, pero al crecer el sistema es cuando aparece el verdadero coste.

El problema es que el conocimiento completo de cada cadena vive en la persona que la construyó: sabe qué datos fluyen, cómo se transforman y qué lógica de negocio se aplicó por el camino. Si esa persona no está disponible, el informe se convierte en una caja negra que nadie se atreve a tocar. Eso es un silo de conocimiento y es la clase de obstáculo que conviene evitar siempre que se pueda.

La segunda consecuencia es puramente operativa. Cuando cada informe está pegado a su propia conexión, la lógica no se hereda: se reescribe, por lo que si la regla de negocio cambia, has de modificarla en cada sitio donde aparece, sin tener garantía de que todas las copias acaben igual. El esfuerzo se multiplica y la consistencia se vuelve un acto de fe, algo que ya vivimos al integrar datos fragmentados de decenas de adquisiciones en una sola plataforma.

Frente a eso, un enfoque centralizado invierte la ecuación:

• Se trabaja una vez: el dato se procesa, se documenta y se valida en un único lugar.
• Se explota muchas veces: cualquier informe o herramienta de BI consume esa misma fuente.
• El conocimiento deja de ser personal: pasa a estar en la plataforma, no en la cabeza de quien lo montó.

El conocimiento que vive solo en una persona no es un activo. Es una dependencia.

ÁLVARO GONZÁLEZ-IGLESIAS
Data Engineer

En este contexto, la centralización no es una preferencia estética, sino que es lo que diferencia una plataforma escalable a un conjunto de informes que solo crece en deuda.

La nueva órbita: centralizar sin parar de desarrollar

El objetivo estaba claro: una plataforma centralizada con control y gobernanza de la información, donde el dato tenga una única fuente de verdad. Una vez que ya está descrito ese destino, lo difícil es llegar a él sin apagar lo que ya funciona.

Y aquí aparece la restricción que condiciona todo el proyecto: no puedes congelar el desarrollo mientras montas la arquitectura nueva porque el negocio sigue pidiendo informes y nadie va a esperar meses a que la plataforma esté lista. La migración no es un proyecto con un corte limpio entre el antes y el después, sino que implica desarrollar una nueva plataforma en paralelo hasta llegar a alcanzar aquella que va a sustituir, la cual, además, ha seguido avanzando durante ese tiempo.

Eso significa que necesitas paridad funcional antes de poder retirar nada: el sistema nuevo tiene que producir exactamente lo que produce el viejo, hasta poder sustituirlo sin que nadie note el cambio salvo por lo que mejora detrás. Mientras no llegues a esa paridad, conviven los dos mundos, y cada semana que la migración tarda, la distancia entre ambos puede crecer. La arquitectura deja de ser un asunto puramente técnico —igual que cuando una arquitectura desacoplada reduce el time-to-market en entornos complejos— y se convierte en la pieza que acelera o frena todo lo demás.

Es un reto tanto técnico como de velocidad porque si migrar cada modelo a mano tarda lo mismo que construirlo desde cero, nunca alcanzas al sistema en movimiento y es entonces cuando surge la pregunta operativa: ¿cómo acelero la traducción de modelos sin sacrificar el control y la gobernanza que son precisamente la razón de hacer la migración? Ahí es donde aparece la IA como herramienta con un encaje muy específico.

Migración de modelos de datos con IA: traducción con validación objetiva

Migrar un modelo directo a la plataforma nueva es, en su mayor parte, mecánico: analizar un esquema, entender su estructura y mapearlo a la arquitectura de destino. Es repetitivo, tedioso y consume tiempo de gente que podría dedicarse a problemas más difíciles. Es justo el tipo de tarea donde un modelo de lenguaje multiplica de verdad.

Le pasé a Claude los esquemas de los informes —nunca los datos—, es decir, el modelo de lenguaje debe trabajar desde la estructura y no con el contenido. Esa decisión es el eje del ejercicio, pero antes conviene explicar por qué la aceleración fue real y no un espejismo.

La clave es que partíamos de un objetivo de validación contrastable. El informe antiguo, el que está en producción hoy, actúa como fuente de verdad: no necesito revisar paso a paso si cada decisión de la traducción es correcta, porque tengo un resultado de referencia conocido contra el que contrastar el comportamiento. El criterio es simple:

1. Claude traduce el esquema a la nueva plataforma.
2. Ejecuto el modelo nuevo con los datos reales, mes a mes.
3. Comparo la salida con la del informe antiguo.
4. Si coinciden, la traducción es correcta. Si no, sé exactamente dónde mirar.

Esto cambia la naturaleza del trabajo porque la validación deja de ser una auditoría manual exhaustiva y se convierte en una comprobación de resultado. No porque mapear esquemas y reconstruir transformaciones sea trivial, sino porque el coste de verificar se desploma cuando tienes contra qué contrastar.

Y hay un beneficio que no esperaba: al contrastar el modelo nuevo con los datos reales, el proceso sacó a la luz lo que en un desarrollo normal pasaría desapercibido como errores latentes en los modelos antiguos, partes frágiles o puntos donde se gana rendimiento. Es algo que cualquiera que haya reconstruido una plataforma legacy reconoce de inmediato. Lo que sería un equipo paralelo de auditoría y optimización aquí cae como subproducto de la traducción.

No solo gané la migración. Gané un análisis completo del estado real de los modelos que estaba migrando.

ÁLVARO GONZÁLEZ-IGLESIAS
Data Engineer

La IA no diseñó nada, sino que tradujo con velocidad y, de paso, expuso el terreno. Las decisiones sobre qué hacer con lo que exponía siguieron siendo mías y del equipo.

Cuándo la IA es herramienta y cuándo es riesgo

La IA funcionó aquí porque el input era estructural y no sensible. La estructura de una tabla no compromete la protección de datos de nadie y yo le di esquemas al modelo, no datos. Meter información real cambia la naturaleza del problema y no basta con pensar «ya está anonimizado».

Aunque proveedores como Anthropic no usan los datos que les envías para entrenar los modelos de sus productos comerciales, el riesgo no está solo en que el dato salga fuera, sino que es mucho más sutil: por ejemplo, un modelo puede hacer inferencias entre campos aparentemente desconectados. Basta un identificador mal ofuscado o una combinación de atributos inocuos por separado para que reconstruya contexto que nunca quisiste revelar. Y como advierte la propia guía de anonimización de la AEPD, las mismas capacidades que sirven para anonimizar sirven para reidentificar: la ofuscación parcial da una falsa sensación de seguridad.

Por eso el análisis de cuándo apoyarse en IA se reduce a una distinción bastante clara:

• Donde sí: tareas estructurales, repetitivas, con un objetivo de validación contrastable y sin datos sensibles de por medio. Ahí la IA es un acelerador con muy poco riesgo.
• Donde no, o solo con extrema cautela: cualquier proceso que cargue información sensible en un agente sin garantía rigurosa de que no se pueda inferir nada a partir de ella.

La IA es una herramienta de doble filo y un multiplicador: amplifica el buen criterio en velocidad y el mal criterio en exposición. La responsabilidad nunca está en la herramienta, sino en el criterio de quien decide qué entra en ella. Es la misma idea que defendemos cuando hablamos de clean code con agentes de IA: la IA cambia el coste de ejecutar, pero no la necesidad de criterio humano.

Si vas a abordar una migración parecida, antes de elegir el modelo o la plataforma, decide qué información puede salir de tu perímetro y cuál no, para que la IA solo toque lo primero. Después, busca un objetivo de validación contra el que contrastar resultados sin revisar cada paso a mano. Con esas dos piezas, la velocidad llega sola sin comprometer el control que justificaba migrar.