Data pipeline para IA: cómo construirlo, de las fuentes al modelo

Publicado: 2026-06-29 · Actualizado: 2026-10-28

Por Goiko, Founder & AI Solutions CTO de GUGŌ Creative

Cómo construir el data pipeline que alimenta un sistema de IA: fuentes, ETL o ELT, calidad, versionado, carga incremental, observabilidad, RGPD y costes.

Un data pipeline para IA es el conjunto de procesos automáticos que extrae datos de los sistemas de origen —ERP, CRM, gestor documental, bases de datos o eventos—, los guarda en bruto, los limpia y transforma, comprueba su calidad, los versiona y los entrega al sistema de IA: como conjunto de entrenamiento de un modelo predictivo, como índice de documentos de un RAG o como contexto de una automatización. Su función es que el modelo reciba datos correctos, recientes y trazables.

Para construirlo, empieza por la tarea que debe resolver la IA y las fuentes mínimas que necesita, no por la herramienta. Un patrón sensato por defecto es ELT: copia en bruto inmutable, transformaciones en código versionado, pruebas de calidad que bloquean la publicación, carga incremental que se puede repetir sin duplicar, linaje y alertas. El RGPD entra desde el diseño. Rara vez se presupuesta solo: va dentro del proyecto de IA, desde 10.000 € en una automatización acotada.

Qué es un data pipeline para IA y en qué se diferencia de uno de BI

Un pipeline de BI alimenta cuadros de mando: le basta con que los datos de ayer estén bien agregados. Uno para IA alimenta un sistema que aprende o responde con ellos, y eso exige más: reproducir el conjunto exacto de cada entrenamiento, no colar información del futuro en los datos de entrenamiento, tratar documentos además de tablas y llevar los permisos hasta el índice. El artículo Hidden Technical Debt in Machine Learning Systems (NIPS 2015) ya identificaba las dependencias de datos como uno de los factores de riesgo que generan deuda técnica en estos sistemas.

Según a qué alimente, el pipeline entrega cosas distintas:

Modelos predictivos —previsión de demanda, scoring, clasificación—: tablas de entrenamiento con etiquetas y variables, versionadas por entrenamiento.
Sistemas RAG y asistentes: documentos extraídos, troceados e indexados con metadatos y permisos; el detalle está en arquitectura RAG.
Automatizaciones y agentes: datos de contexto actuales, leídos en el momento o con pocos minutos de retraso.

Arquitectura de un data pipeline para IA, capa a capa

Fuentes y conectores: API, réplicas de lectura, captura de cambios o exportaciones, con permisos mínimos.
Zona bruta: copia fiel e inmutable de lo extraído, con fecha de carga y origen.
Transformación: limpieza, normalización, deduplicación y unión de fuentes, en código versionado.
Validación: pruebas de calidad que deciden si la nueva versión se publica.
Publicación versionada: el conjunto de entrenamiento, el índice o la tabla de variables que consume la IA.
Orquestación y observabilidad: programación, reintentos, linaje y alertas.

Fuentes e ingesta: carga completa, incremental o captura de cambios

Primero, un inventario: qué fuentes hay, quién es su responsable y qué sistema manda cuando dos discrepan. Después se elige cómo extraer. Airbyte, por ejemplo, documenta los modos de sincronización habituales: carga completa, incremental mediante un cursor —normalmente la fecha de modificación— y captura de cambios (CDC), que lee el registro de cambios de la base de datos. Debezium es una herramienta de CDC que convierte los cambios de cada fila en un flujo de eventos ordenado.

Un cursor por fecha de modificación no detecta los borrados físicos, y en IA un dato borrado que sigue en el índice es un error. Conviene además extraer de réplicas o de la API, no con consultas pesadas contra la base de datos de producción.

ETL o ELT

En ETL los datos se transforman antes de cargarlos en el destino; en ELT se cargan en bruto en el almacén o lago de datos y se transforman allí, normalmente con SQL. Para IA, ELT suele ser la mejor opción por defecto: si cambian las reglas de limpieza, se reprocesa desde la zona bruta sin volver a extraer. La excepción son los datos personales que no se necesitan: se eliminan o seudonimizan antes de cargar, porque guardarlos en bruto ya es un tratamiento.

Transformación y limpieza

Aquí se deduplican registros, se normalizan fechas y unidades, se resuelve que el «Cliente S.L.» del CRM y el «CLIENTE SL» del ERP son la misma empresa y se extrae el texto de los documentos. Todo en código versionado en Git y con pruebas, nunca en scripts manuales. Con dbt, por ejemplo, los modelos incrementales transforman solo las filas nuevas o modificadas desde la última ejecución y, con una clave única, actualizan las existentes en lugar de duplicarlas.

Calidad de datos: pruebas que bloquean la publicación

Las pruebas de calidad son afirmaciones sobre los datos que se comprueban en cada ejecución. dbt incluye cuatro pruebas genéricas: valores únicos, no nulos, valores aceptados e integridad referencial. A esas se suman otras:

Reglas de negocio: importes positivos, entregas posteriores al pedido, estados válidos.
Volumen: filas recibidas frente a lo habitual para esa fuente y ese día.
Frescura: cuándo llegó el último dato correcto de cada fuente.
Distribución: cambios bruscos en categorías o valores medios, que suelen anunciar un cambio en el origen.

Si falla una prueba crítica, la nueva versión no se publica y el sistema de IA sigue con la anterior, menos reciente pero correcta.

Versionado de datos y reproducibilidad

Versionar datos es poder responder con exactitud a «¿con qué datos se entrenó este modelo?» o «¿qué versión del procedimiento tenía el índice el día 3?». Se versionan el código de transformación, su configuración, las instantáneas publicadas y, en RAG, el modelo de embeddings y la versión del índice. DVC versiona datos junto al código: Git guarda un pequeño fichero de metadatos y los datos van a un almacenamiento aparte. Formatos de tabla con historial como Delta Lake permiten consultar una instantánea anterior por versión o fecha, siempre que no se hayan purgado los ficheros antiguos.

La otra cara es la fuga de datos (data leakage), que la guía de errores comunes de scikit-learn define como usar al construir el modelo información que no estaría disponible al predecir; recomienda separar entrenamiento y prueba antes de cualquier preprocesado. Con datos históricos, la defensa son las uniones a fecha, que Feast llama point-in-time joins: cada fila recibe los valores tal como estaban en su fecha, no los actuales.

Actualización incremental sin duplicados

Un pipeline en producción falla de vez en cuando y se reintenta, así que debe poder repetirse sin efectos secundarios. La guía de buenas prácticas de Apache Airflow lo resume en tratar cada tarea como una transacción de base de datos: no dejar resultados a medias, producir el mismo resultado en cada reintento, usar UPSERT en lugar de INSERT y leer una partición concreta, no «lo último disponible».

En un RAG, el equivalente es reprocesar solo los documentos cuyo hash ha cambiado, regenerar sus embeddings y propagar al índice las bajas y los cambios de permisos. Si cambian las reglas de transformación o el modelo de embeddings, toca una recarga completa planificada, no parches.

Observabilidad: saber que el pipeline falla antes que el usuario

Sin observabilidad, un pipeline se rompe en silencio: el asistente sigue respondiendo, pero con datos de hace tres semanas. Como mínimo hay que vigilar:

La frescura de cada fuente y de cada conjunto publicado.
El volumen de filas o documentos procesados, rechazados y pendientes.
Los cambios de esquema en el origen: columnas nuevas, renombradas o con otro tipo.
El resultado de las pruebas, la duración y el coste de cada ejecución.
El linaje: de qué fuentes y transformaciones sale cada conjunto.

Para el linaje existe un estándar abierto, OpenLineage, que describe conjuntos de datos, trabajos y ejecuciones con un formato común. Cada alerta necesita un responsable; la monitorización del modelo está en testing de sistemas de IA.

Tabla comparativa: cómo extraer los datos de cada fuente

El método se elige fuente a fuente, y en un mismo pipeline suelen convivir varios:

Método	Cómo funciona	Cuándo usarlo	Riesgo principal
Carga completa	Extrae toda la tabla o carpeta y reemplaza la copia anterior	Tablas pequeñas, catálogos y datos maestros	Tiempo y coste crecen con el volumen; sin instantáneas no hay historial
Incremental por cursor	Extrae lo creado o modificado desde la última carga	Tablas con una fecha de modificación fiable	No ve los borrados físicos ni los cambios que no actualizan esa fecha
Captura de cambios (CDC)	Lee el registro de cambios de la base de datos y emite cada alta, cambio y baja	Bases de datos con muchos cambios o donde los borrados importan	Más infraestructura y permisos sobre la base de datos de origen
Eventos o webhooks	El sistema de origen avisa de cada cambio	Aplicaciones SaaS con webhooks y flujos casi en tiempo real	Eventos perdidos o duplicados si no hay reintentos ni deduplicación
Exportación de ficheros	El sistema deja un CSV o un Excel en una carpeta periódicamente	Sistemas antiguos sin API	Formatos que cambian sin aviso y errores manuales

RGPD y datos personales en el pipeline

Un pipeline copia datos de un sitio a otro, y cada copia es un tratamiento. El RGPD afecta al diseño en cuatro puntos:

Minimización de datos (artículo 5.1.c): extrae solo los campos que la tarea necesita y seudonimiza los identificadores cuanto antes.
Limitación del plazo de conservación (artículo 5.1.e): fija cuánto se guarda en cada capa, también en la zona bruta y en las instantáneas, que tienden a acumularse.
Derecho de supresión (artículo 17): el borrado debe llegar al almacén, las instantáneas y el índice vectorial, porque los embeddings salen de esos datos; decide desde el principio cómo se aplica en las instantáneas de entrenamiento.
Encargados del tratamiento (artículo 28): si la nube, la herramienta de ingesta o el proveedor del modelo tratan datos personales, hace falta un contrato con cada uno.

Si el sistema es de alto riesgo según el Reglamento europeo de IA, su artículo 10 exige gobernanza de los datos de entrenamiento, validación y prueba: pertinentes, suficientemente representativos y, en la medida de lo posible, sin errores, con examen de posibles sesgos. Esto es orientación técnica, no asesoramiento jurídico: el encaje concreto lo valida tu delegado de protección de datos. Ver también seguridad y privacidad en proyectos de IA.

Ejemplos de data pipelines para IA

Los escenarios siguientes son hipotéticos e ilustrativos, no casos de clientes.

Previsión de demanda con datos del ERP

Pedidos, stock y promociones salen del ERP por captura de cambios. Las variables se calculan con uniones a fecha para no usar promociones decididas después del pedido, y cada entrenamiento guarda la instantánea exacta que usó. Si el volumen diario cae a la mitad, una prueba bloquea la publicación.

Asistente sobre la documentación de calidad

Procedimientos en un gestor documental con versiones. El pipeline detecta cambios por hash, reindexa solo esos documentos, retira del índice las versiones derogadas y copia los permisos de cada carpeta. La métrica clave es la frescura: un procedimiento aprobado hoy debe poder consultarse mañana.

Clasificación de tickets con las correcciones del equipo

Los tickets llegan por webhook desde el helpdesk, y la clasificación del modelo se guarda junto a la corrección del agente. Esas correcciones, versionadas, son el conjunto con el que se evalúa cada cambio de prompt o de modelo.

Cuánto cuesta un data pipeline para IA

El pipeline casi nunca se presupuesta solo: forma parte del sistema de IA que alimenta. Según nuestro informe de precios de software e IA 2026, suele entrar en estos rangos:

Automatización con IA de un flujo acotado —documentos, correos, CRM o clasificación con revisión humana—: 10.000-20.000 €, en 4-6 semanas.
Chatbot o asistente con RAG, cuya ingesta de documentos es el pipeline: 10.000-25.000 €, en 4-8 semanas.
Copiloto interno con RAG y permisos por rol: 20.000-50.000 €, en 6-12 semanas.
Plataforma interna a medida, si el pipeline forma parte de una herramienta con varios roles, flujos, permisos e integraciones: 35.000-70.000 €, en 12-20 semanas.

Los costes recurrentes son la infraestructura cloud, entre 50 y 500 € al mes según tráfico y datos; el uso de modelos por API, desde unos 100 € al mes con poco volumen; y el mantenimiento, entre el 15 y el 25 % del coste de desarrollo al año. Más que el volumen, el precio lo mueven las fuentes sin API, la calidad de origen y la trazabilidad exigida. Ver cuánto cuesta automatizar procesos con IA.

Errores frecuentes al construir un data pipeline

Empezar por la plataforma: contratar un lago de datos antes de saber qué tarea de IA va a alimentar.
No guardar el bruto: sin la copia original, un error de limpieza obliga a volver a extraer, si todavía se puede.
Pruebas que no bloquean: el modelo se entrena o el índice se actualiza con datos rotos.
Olvidar los borrados: registros eliminados en el origen que siguen en el índice o en las instantáneas.

Preguntas frecuentes

¿Qué partes tiene un data pipeline para IA?

Conectores a las fuentes, una zona bruta inmutable, transformación y limpieza en código versionado, pruebas de calidad, publicación versionada del conjunto de datos o del índice, y orquestación con observabilidad y alertas.

¿ETL o ELT para un proyecto de IA?

ELT suele ser la mejor opción por defecto: cargar en bruto y transformar en el destino permite reprocesar cuando cambian las reglas y auditar qué llegó de cada fuente. Los datos personales innecesarios se eliminan o seudonimizan antes de cargar.

¿Por qué hay que versionar los datos?

Porque si un modelo empieza a fallar necesitas saber exactamente con qué datos se entrenó o qué documentos tenía indexados. Sin versionado no se puede reproducir un resultado ni explicar un cambio de comportamiento.

¿Necesito un data pipeline para un proyecto RAG?

Sí, aunque más sencillo que para entrenar modelos: hay que extraer, limpiar y trocear documentos, generar embeddings, mantenerlos al día y respetar permisos. Ver arquitectura RAG.

¿Cómo afecta el RGPD a un pipeline de datos para IA?

Obliga a extraer solo los datos necesarios, fijar plazos de conservación en cada capa, propagar las supresiones a copias, instantáneas e índices y regular por contrato a los proveedores que traten datos personales.