Guía técnica
Analizar el código de tus pipelines con IA sin que salga de tu infraestructura
Para extraer linaje de verdad hay que leer el código y el SQL de los procesos. Esa es la objeción que frena muchos proyectos, y tiene solución: ejecutar el modelo dentro de tu propia red.
Última actualización: 16 de agosto de 2026
Por qué hay que leer el código
Los metadatos no contienen la relación. El catálogo sabe que una tabla existe, pero la
frase que dice «esta columna sale de aquella, pasada por un cast» está
escrita en un script de PySpark o en una sentencia SQL dentro del job.
Cualquier herramienta que prometa linaje de columna sin mirar el código está infiriéndolo de nombres o pidiéndote que lo escribas tú. Leer los artefactos no es un capricho de diseño: es el único sitio donde está la información.
Qué implica enviarlo a una API externa
Si el análisis se hace con una API de terceros, el código de tus procesos sale de tu red. Conviene ser preciso sobre lo que eso significa, sin dramatizarlo ni minimizarlo:
- Los scripts de ETL suelen incluir nombres de tablas, esquemas y rutas que revelan la estructura del negocio.
- A veces incluyen lógica de negocio que es en sí misma información sensible: cómo se calcula un scoring, qué reglas determinan un segmento.
- Aunque el proveedor no entrene con tus datos, aparece un encargado del tratamiento más y, si está fuera del EEE, una transferencia internacional que documentar.
Para muchas organizaciones eso es perfectamente asumible con un contrato. Para otras —banca, salud, sector público— es un no rotundo, y la conversación se acaba ahí.
La alternativa: el modelo dentro de tu red
Un modelo de lenguaje ejecutándose en local, por ejemplo mediante Ollama, cambia el planteamiento por completo. El código y el SQL se analizan en tu propia infraestructura y nunca viajan a un tercero. No hay proveedor nuevo, no hay transferencia internacional y no hay que negociar un anexo de tratamiento de datos para arrancar una prueba.
El compromiso real está en la capacidad: los modelos que caben en una máquina propia son menos potentes que los mejores modelos comerciales. En una tarea acotada como interpretar lecturas y escrituras de un script de ETL, con el contexto adecuado, el resultado es utilizable, pero es honesto decir que hay una diferencia.
Cómo decidir en cada caso
No tiene por qué ser una elección permanente ni única para toda la plataforma:
- Modelo local cuando el código es sensible, cuando el cliente no permite salida de datos, o para una primera prueba sin pasar por compras y legal.
- API externa cuando el código no es especialmente sensible y quieres la máxima precisión en procesos complejos.
Lo importante es que la decisión sea explícita y por extracción, no una condición impuesta por la herramienta.
Lo que no cambia: evidencia y revisión
Ejecutar el modelo en local no lo convierte en infalible. Un linaje generado por IA sigue necesitando las mismas garantías: nivel de confianza por relación, evidencia trazable al fichero y la línea, y revisión humana antes de publicar.
La IA propone; una persona confirma, rechaza o deja pendiente. Sin eso, da igual dónde se ejecute el modelo: sigue siendo una caja negra.
Cómo lo resuelve AI Data Lineage Mapper
El proveedor del modelo se elige en cada extracción: Ollama ejecutándose en local, o las APIs de Anthropic u OpenAI. Junto a esa elección se configura el objetivo de confianza y si el análisis debe incluir SQL, configuración, variables de entorno y dependencias.
La conexión a AWS es de solo lectura, mediante un rol asumido con ExternalId o como appliance desplegado en tu propia cuenta, y el linaje resultante se persiste en PostgreSQL con sincronización opcional del grafo en Neo4j. Todo el recorrido puede quedarse dentro de tu perímetro.