Los primeros 30 días de la construcción de un pipeline de datos de IA empresarial
Un recorrido semanal detrás de escena de la construcción de un pipeline de datos de IA empresarial: qué sucede, qué sale mal y cómo se ve el éxito en cada etapa.
Las líneas de tiempo de IA empresarial se ven limpias en las presentaciones. Fases ordenadas, flechas suaves, todo llegando a tiempo. La realidad es más desordenada. Los datos están en formatos que nadie documentó. La provisión de acceso toma una semana en lugar de un día. El experto de dominio que se suponía estaría disponible a tiempo completo está disponible dos horas el jueves.
Este es un recorrido semana a semana de lo que realmente sucede durante los primeros 30 días de la construcción de un pipeline de datos de IA empresarial. No la versión idealizada — la real, incluyendo las partes que se desvían y cómo manejarlas.
Semana 1: Auditoría de datos y definición de alcance
Lo que se supone que debe pasar
El ingeniero desplegado llega (física o virtualmente), conoce al equipo y realiza una auditoría exhaustiva del panorama de datos. El objetivo es responder tres preguntas: ¿Qué datos existen? ¿Dónde viven? ¿En qué estado se encuentran?
Simultáneamente, el ingeniero trabaja con TI para obtener acceso al entorno: recursos de cómputo, credenciales de red, acceso al almacenamiento, autorizaciones de seguridad.
Lo que realmente sucede
Día 1-2: Presentaciones y solicitudes de acceso. El ingeniero conoce a los stakeholders, recibe un recorrido por los sistemas y envía solicitudes de acceso. En la mayoría de las empresas, aquí es donde ocurre el primer retraso. Las revisiones de seguridad, verificaciones de antecedentes y provisión de acceso en entornos regulados pueden tomar de 2 a 5 días hábiles. Los buenos engagements anticipan esto e inician las solicitudes de acceso durante la fase previa al engagement.
Día 3-4: Descubrimiento de datos. El ingeniero comienza a mapear las fuentes de datos. Esto casi siempre es sorprendente. Los datos que el cliente describió durante el proceso de ventas son un subconjunto de lo que realmente existe. Hay bases de datos adicionales, comparticiones de archivos legacy, exportaciones de sistemas que se desmantelaron hace tres años, y hojas de cálculo en el escritorio de alguien que contienen datos de referencia críticos.
Descubrimientos comunes:
- Los datos están distribuidos en más sistemas de los que alguien se imaginaba
- Los formatos de archivo son inconsistentes incluso dentro de una sola fuente
- Los metadatos están incompletos o no son confiables
- El volumen de datos es de 3 a 10 veces más de lo que se estimó
- Algunos datos están en formatos que requieren parsers especializados (PDFs escaneados, exportaciones de bases de datos propietarias, extractos de mainframe)
Día 5: Ajuste de alcance. El alcance original, definido durante el proceso de ventas basado en la descripción del cliente, se revisa basándose en lo que la auditoría de datos realmente encontró. Esto no es aumento de alcance — es corrección de alcance. El trabajo siempre fue de este tamaño; el estimado simplemente no lo sabía.
Lo que sale mal
Los retrasos de acceso son el problema más común de la Semana 1. Si el ingeniero no puede acceder a los sistemas de datos, todo se detiene. La mitigación es iniciar la provisión de acceso antes de que el engagement comience oficialmente.
El segundo problema más común: el stakeholder principal (la persona que compró el engagement) tiene un entendimiento diferente de los datos que las personas que realmente trabajan con ellos. El stakeholder dice: "Nuestros contratos están todos en una carpeta de SharePoint." El equipo de contratos dice: "Bueno, los recientes están en SharePoint. Los de antes de 2022 están en el antiguo sistema de gestión de documentos. Y las enmiendas están en el correo electrónico."
Semana 2: Arquitectura del pipeline y pruebas de ingestión
Lo que se supone que debe pasar
Basándose en la auditoría de la Semana 1, el ingeniero diseña la arquitectura del pipeline y comienza a construir la capa de ingestión — la parte que extrae datos de los sistemas fuente hacia el entorno de preparación.
Lo que realmente sucede
Día 6-7: Diseño de la arquitectura. El ingeniero mapea el pipeline: conectores de fuente, pasos de transformación, flujo de trabajo de etiquetado, formato de exportación. Esto se revisa con el equipo técnico del cliente. Las decisiones de arquitectura tomadas esta semana — dónde procesar, cómo manejar errores, qué registrar — determinan la mantenibilidad a largo plazo del pipeline.
Día 8-9: Construcción y prueba de ingestión. Los primeros conectores se construyen y prueban. Aquí es donde los problemas de formato de datos se vuelven concretos. Un parser de PDF funciona en el 90% de los documentos pero falla en el 10% que son imágenes escaneadas. Un conector de base de datos extrae registros exitosamente pero las marcas de tiempo están en tres formatos diferentes. Una exportación CSV tiene saltos de línea incrustados que rompen el parser.
Cada uno de estos problemas es resoluble. Pero cada uno toma tiempo y se acumulan. Un ingeniero que ha hecho esto antes no se sorprenderá. Un ingeniero haciéndolo por primera vez subestimará el esfuerzo de 2 a 3 veces.
Día 10: Primer flujo de datos de extremo a extremo. Para el final de la Semana 2, los datos crudos deberían estar fluyendo desde al menos un sistema fuente hacia el entorno de preparación. No estarán limpios. No estarán etiquetados. Pero estarán moviéndose, y esa es la base sobre la que se construye todo lo demás.
Lo que sale mal
Los problemas de integración con sistemas legacy son el problema más común de la Semana 2. Las APIs modernas son predecibles. Las exportaciones de bases de datos legacy, los formatos de archivo propietarios y los sistemas sin documentación no lo son. Presupuesta tiempo extra si tus datos viven en sistemas con más de 10 años.
El rendimiento también puede sorprender. Un pipeline que procesa 100 documentos de prueba en segundos puede ahogarse con 100,000 documentos de producción. La Semana 2 es donde estos cuellos de botella se hacen visibles.
Semana 3: Reglas de limpieza, esquema de etiquetas e incorporación de expertos de dominio
Lo que se supone que debe pasar
Con los datos fluyendo hacia el pipeline, el enfoque cambia a la transformación: reglas de limpieza que estandarizan los datos, y un esquema de etiquetas que los expertos de dominio usarán para anotar datos para el entrenamiento de modelos.
Lo que realmente sucede
Día 11-13: Reglas de limpieza y transformación. El ingeniero construye las reglas que limpian los datos crudos: deduplicación, normalización, manejo de valores faltantes, estandarización de formato, detección y redacción de PII (si corresponde). Esto es iterativo — las reglas se escriben, se prueban contra datos de muestra, se refinan y se prueban nuevamente.
La idea clave: las reglas de limpieza codifican conocimiento de dominio. Una regla que dice "si el campo de fecha contiene 'TBD', trátalo como nulo" es una decisión de dominio, no técnica. Por esto los expertos de dominio necesitan estar involucrados, no solo los ingenieros.
Día 14-15: Diseño del esquema de etiquetas. El ingeniero trabaja con los expertos de dominio para definir el esquema de etiquetas — las categorías, tags o anotaciones que se aplicarán a los datos. Esta es la parte más intelectualmente demandante del engagement.
Un buen esquema de etiquetas es:
- Exhaustivo (cubre todos los casos en los datos)
- Mutuamente exclusivo (sin superposiciones ambiguas)
- Práctico (los anotadores pueden aplicar las etiquetas de manera consistente)
- Alineado con la tarea del modelo downstream
Un mal esquema de etiquetas es obvio en retrospectiva pero invisible durante el diseño. "Tipo de contrato" parece una etiqueta clara hasta que encuentras un documento que es tanto una enmienda como una renovación. "Severidad" parece sencillo hasta que dos expertos de dominio no están de acuerdo en si un hallazgo es "moderado" o "alto."
Día 15 continuación: Incorporación de expertos de dominio. Los expertos de dominio se capacitan en la interfaz de etiquetado y el esquema de etiquetas. Etiquetan un conjunto de muestra. Se mide el acuerdo inter-anotador. Si el acuerdo es bajo, el esquema necesita revisión.
Lo que sale mal
La disponibilidad de expertos de dominio es el riesgo crítico en la Semana 3. Si los expertos de dominio están demasiado ocupados para participar, el esquema de etiquetas será diseñado por ingenieros que no entienden el dominio, y los datos de entrenamiento resultantes serán mediocres.
El otro problema común: desacuerdo en el esquema de etiquetas. Diferentes expertos de dominio tienen diferentes modelos mentales. Un abogado senior clasifica contratos de manera diferente que un abogado junior. Un cardiólogo y un radiólogo interpretan el mismo informe de imágenes de manera diferente. Resolver estos desacuerdos toma tiempo y diplomacia.
Semana 4: Validación, métricas de calidad y configuración de cumplimiento
Lo que se supone que debe pasar
El pipeline está completo. La Semana 4 es sobre probar, medir y documentar.
Lo que realmente sucede
Día 16-18: Validación del pipeline. El pipeline completo se ejecuta de extremo a extremo con datos a escala de producción. Se miden métricas de calidad:
- Completitud de ingestión: ¿Qué porcentaje de registros fuente se ingirieron exitosamente?
- Precisión de limpieza: ¿Qué porcentaje de transformaciones produjo resultados correctos?
- Calidad de etiquetado: ¿Cuál es el acuerdo inter-anotador? ¿Cuál es la precisión/recall en una muestra estándar de referencia?
- Integridad de exportación: ¿El formato de salida coincide con la especificación? ¿El framework de ML downstream puede ingerirlo sin errores?
Los objetivos varían según el caso de uso, pero los benchmarks típicos son: más del 99% de completitud de ingestión, más del 95% de precisión de limpieza, más del 85% de acuerdo inter-anotador (kappa de Cohen mayor a 0.7).
Día 19: Documentación de cumplimiento. Para industrias reguladas, la pista de auditoría del pipeline se revisa y documenta: informes de trazabilidad de datos, registros de acceso, historiales de transformación, registros de manejo de PII. Esta documentación es el entregable que más le importa a los equipos de cumplimiento — y es el que más frecuentemente se omite o se apresura.
Día 20: Entrega y capacitación. El ingeniero realiza una entrega estructurada: recorrido del pipeline, documentación de configuración, procedimientos de mantenimiento, guía de resolución de problemas. El equipo técnico del cliente debería poder ejecutar, monitorear y modificar el pipeline de forma independiente después de esta sesión.
Lo que sale mal
La validación a menudo revela problemas que requieren modificaciones al pipeline. Una regla de limpieza que funcionó con datos de muestra produce resultados incorrectos a escala. Una categoría de etiqueta que parecía clara durante el diseño es ambigua en la práctica. El formato de exportación tiene un caso límite que el framework downstream no maneja.
Esto no es un fracaso. Para esto es la validación. El riesgo no es que surjan problemas — es que la Semana 4 no tenga suficiente margen para abordarlos. Los buenos engagements planifican al menos 2 días de retrabajo en la Semana 4.
Después del día 30
El pipeline está en producción. Tu equipo es el dueño. El ingeniero del proveedor está disponible por 30-60 días de soporte remoto, pero el sistema es tuyo para operar.
Los primeros 30 días son los más difíciles. Las sorpresas de datos quedaron atrás. Los problemas de integración están resueltos. Los expertos de dominio saben cómo usar el sistema. A partir de aquí, el trabajo cambia de construir a operar — ejecutar el pipeline, monitorear la calidad y extenderlo a nuevas fuentes de datos o casos de uso a medida que las necesidades evolucionan.
Planificando tus primeros 30 días
Si te estás preparando para construir un pipeline de datos de IA y quieres entender cómo se ven los primeros 30 días para tus datos y entorno específicos, agenda una llamada de descubrimiento con Ertas. Recorreremos tu panorama de datos, señalaremos las sorpresas probables de la Semana 1 y te daremos una línea de tiempo realista — no la versión de presentación.
Turn unstructured data into AI-ready datasets — without it leaving the building.
On-premise data preparation with full audit trail. No data egress. No fragmented toolchains. EU AI Act Article 30 compliance built in.
Keep reading
What Is Forward Deployment? How AI Companies Embed with Enterprise Teams
Forward deployment means AI vendor engineers embed with your team on-site. How it works, why it matters for enterprise AI, and what a typical engagement looks like.
Why Your RAG Pipeline Fails Silently — And How to Make It Observable
Most RAG pipelines are invisible glue code. When retrieval quality drops, there is no logging, no node-level metrics, and no way to trace which document caused the bad answer. Here is how to build observable RAG infrastructure.
Best Visual RAG Pipeline Builder: From Documents to Retrieval Endpoint Without Writing Code
Building RAG pipelines typically requires Python expertise across five or more libraries. A visual pipeline builder lets domain experts and engineers alike build production RAG by dragging and connecting nodes on a canvas.