El 90% de los Pipelines de Datos para RaaS Mueren Antes de la Primera Ingesta. No es un Problema de Tecnología.

Crees que un pipeline de datos falla por tecnología. Que elegiste el orquestador equivocado, la base de datos equivocada, la cola de mensajes equivocada. Que si hubieras puesto Airflow en lugar de cron jobs, o un lakehouse en lugar de PostgreSQL, todo habría funcionado.

Te has equivocado de diagnóstico.

Nueve de cada diez pipelines de datos para Research-as-a-Service fallan antes de ingerir el primer registro. No por falta de tecnología. Por exceso de suposiciones.

Suposiciones silenciosas sobre la fuente donde el pipeline ni siquiera ha tocado todavía: que está limpia, que llega a tiempo, que el esquema documentado es el esquema real. Cada una de esas suposiciones es una bomba de relojería esperando la primera deriva del esquema.

Y en RaaS, la fuente nunca está limpia. Nunca lo estará.

---

El Problema: Diseñar Contra un Snapshot Limpio que Nunca Existió

Por Qué el Error Ocurre Antes de Escribir Código

En Research-as-a-Service, tus fuentes suelen ser terceros. APIs de datos abiertos, scraping de web, exports internos de clientes. Y los terceros cambian de formato sin avisar. Reutilizan campos dándoles significados nuevos. Degradan su frescura sin ningún aviso de breaking change.

Diseñas contra un snapshot documentado. La doc dice que el campo industry viene en string. Perfecto. Seis meses después, el dueño de la fuente decide que industry ahora es un entero que referencia otra tabla. Tu pipeline explota a las 3 de la madrugada.

Pero el problema no es la explosión a las 3 de la madrugada. El problema es que no diseñaste para que eso fuera el estado normal del sistema.

El Paralelismo con el Smoke Test

Ya viste el mismo patrón con el smoke test: la conversación y las encuestas miden interés, no intención de pago. La documentación mide confort, no realidad.

Diseñar el pipeline a partir de conversaciones con el dueño de la fuente y de la documentación oficial es exactamente una encuesta. Preguntas por el dato en lugar de observarlo.

El perfilado de datos real es la "acción con coste" del pipeline. Observa el dato. No preguntes por él.

La Lección del Lado Equivocado de la Guía

La mayoría de guías de pipelines se centran en la capa de ingesta y orquestación. Cómo mover bytes. Dónde meter los bytes. Cómo programar los bytes.

Se equivocan de capa. La capa que decide el éxito es el contrato con la fuente y la pregunta de investigación. No importa que tu Airflow esté perfecto si asumiste que una fuente con nulos llegaría sin nulos.

❌ Enfoque convencional: Elegir herramientas → Diseñar esquema → Escribir transformaciones → Descubrir el dato sucio en producción.

✅ Enfoque correcto: Inventariar suposiciones → Perfilar la fuente real → Construir un slice vertical con una pregunta → Diseñar validación y cuarentena como estructura → Medir suposiciones rotas.

---

La Evidencia: Por Qué el Dato Sucio es el Estado Normal, No la Excepción

El 90% No es un Estudio. Es una Heurística — y Eso es Suficiente

Te adelanto la objeción antes de que la formulas: el 90% no sale de un paper académico. Sale de la experiencia de despliegues RaaS reales.

¿Y eso lo invalida? No. Lo convierte en heurística de diseño. Y puedes validarla en tu propio contexto en una tarde.

Haz el ejercicio de auditoría local: cuenta los pipelines de datos que has construido o visto construir en servicios de investigación. Clasifica su causa raíz de fallo en dos categorías. Tecnología — orquestador roto, base de datos lenta, cola saturada. O suposiciones de fuente — esquema que cambió, campo reutilizado, frescura degradada, nulos inesperados.

No te sorprendas si el ratio se acerca al 90% en tu propia cuenta.

Lo importante no es el número exacto. Es el mecanismo causal: suposiciones no contrastadas sobre fuentes que no controlas. Ese mecanismo es independiente de la cifra.

El Dato que la Fuente No Completó

La fuente original del hilo contenía un análisis de concentración del valor — la frase "El 80% del Valor…" quedó truncada, sin completar. No voy a inventar la cifra que falta.

Lo que sí puedo argumentar, sin números inventados, es el principio cualitativo: el valor en RaaS se concentra de forma muy desigual entre fuentes y preguntas. Es el mismo patrón distributivo que ya conoces.

Eso implica una decisión de diseño: prioriza la pregunta de investigación y el slice vertical antes que cubrir exhaustivamente todas las fuentes disponibles. No construyas un pipeline para todas tus fuentes. Construye uno que responda la pregunta que el cliente paga — y luego escala.

---

El Análisis: Qué Significa Todo Esto para Tu Servicio

La Limpieza de Datos es un Servicio Continuo, No un Requisito

El error conceptual más caro en RaaS es tratar la limpieza de datos como un paso inicial que "se hace una vez y se olvida".

En la práctica, la limpieza es un servicio continuo del pipeline. Las fuentes derivan. Los esquemas cambian. Los significados de los campos mutan. Si tu pipeline no asume esa deriva como condición permanente, la primera vez que la fuente cambie de formato, tu servicio de investigación entero queda en cuarentena.

Esto tiene una implicación directa para tu productized services business model: el pipeline robusto no es un coste hundido que pagas una vez. Es una infraestructura viva que consume mantenimiento. Y eso debe estar en tu modelado de servicio, no como un parche.

El Canon del 80/20 de los Informes

Ya sabes que el 80% del valor de un informe listo para cliente está en la plantilla y la narrativa, no en la ingesta de datos. Este artículo es el otro lado de esa moneda.

El pipeline que alimenta esa plantilla con datos estructurados tiene su propio patrón de concentración: unas pocas fuentes y unas pocas preguntas generan el grueso del valor entregado al cliente. Diseña para esas.

---

El Marco: El Método de las Suposiciones Explícitas

Llamo a esto El Método de las Suposiciones Explícitas. Cinco pasos. Cada uno convierte una debilidad estructural en una prueba medible.

Paso 1: Inventario Explícito de Suposiciones

Antes de diseñar nada, abre un documento. Escribe cada suposición sobre cada fuente:

Formato esperado (¿el campo date viene como ISO 8601 o como timestamp Unix?)
Frescura esperada (¿la fuente se actualiza cada hora o cada trimestre?)
Unicidad (¿hay una clave primaria estable o es un export que puede repetir filas?)
Nulos (¿qué campos son opcionales de verdad?)
Volumen (¿qué rango de registros esperas por ciclo?)
Estabilidad del esquema (¿cuándo fue la última vez que cambió la estructura?)

Cada suposición es una hipótesis comprobable, no un hecho. El inventario se convierte en la checklist de validación de todo el diseño.

Objeción legítima: "Un pipeline sin suposiciones no existe — los esquemas son suposiciones por definición." Correcto. El problema no es suponer. Es suponer de forma implícita, permanente y sin prueba. Este paso no elimina las suposiciones. Las convierte en explícitas, fechadas y comprobables antes de escalar.

Paso 2: Perfilado de Datos Previo al Diseño

Ejecuta un audit sobre las fuentes reales, no sobre los ejemplos ni la documentación.

Para cada campo: tipos reales, porcentaje de nulos, duplicados, outliers, cambios de formato entre muestras. Si la fuente es una API, prueba el endpoint real con varios paginados. Si es scraping, ejecuta el parseador contra la página de producción, no contra una copia guardada.

El perfil resultante es el input del diseño. El esquema soñado no lo es.

En RaaS esto es especialmente crítico porque las fuentes suelen ser de terceros. No controlas nada. Solo observas.

Paso 3: Slice Vertical Mínimo

No construyas el pipeline completo. Construye UNA pregunta de investigación de extremo a extremo.

Fuente → limpieza → estructura → output de investigación. Una pregunta. Una fuente. Un informe.

Esto expone el dato sucio real en días, no en meses. Valida el valor antes de escalar infraestructura. Y si la pregunta que elegiste no se puede responder con los datos disponibles, lo descubres con un coste mínimo en lugar de después de tres meses de desarrollo.

El slice vertical es la versión en datos del smoke test: no preguntes si la pregunta se puede responder. __Intenta responderla__ con el dato real.

Paso 4: Capa de Validación, Cuarentena y Reproceso por Diseño

Asume que el dato llega sucio. Asume que las fuentes derivan. Diseña en consecuencia.

Las reglas de validación, el área de cuarentena y los reprocesos son parte estructural del pipeline, no parches posteriores. Si necesitas una herramienta, herramientas como Great Expectations o dbt tests te ayudan en la capa de ejecución — pero recuerda que el fallo del 90% ocurre en la capa de diseño, no aquí.

Ninguna herramienta sustituye a perfilar la fuente real ni a cuestionar las suposiciones de partida. Las herramientas de validación de esquemas actúan después de que el pipeline existe. El fallo del 90% ocurre antes.

Paso 5: Mide el Ratio de Suposiciones Rotas

Instrumenta cuántas suposiciones del inventario inicial se rompen en producción.

Cada instancia de: esquema que cambió, campo reutilizado con significado nuevo, frescura degradada, volumen inesperado, se registra como una suposición rota.

Ese dato realimenta la siguiente iteración del diseño. La primera iteración de un pipeline no debería tener más del 30-40% de suposiciones intactas. La tercera debería acercarse al 80-90%.

El aprendizaje se convierte en evidencia acumulada que informa cómo estructuras contratos con fuentes futuras y cómo modelas el coste de mantenimiento en tu productized services business model. Cada pipeline que construyes con este método te enseña algo sobre el siguiente, y sobre el siguiente después de ese.

---

Conclusión: El Pipeline No Asume, Observa

La próxima vez que diseñes un pipeline de datos para un servicio de investigación, empieza por el documento de suposiciones, no por el diagrama de arquitectura.

La tecnología no es tu problema. El dato sucio no es tu enemigo. Tu enemigo es la suposición que no escribiste.

El dato llega sucio. Las fuentes derivan. Los esquemas mienten. Si diseñas para ese estado como la norma — con perfilado real, slice vertical y validación estructural — tu pipeline no solo sobrevive al primer registro. Sobrevive a la primera deriva del esquema, a la primera fuente que cambia de formato y al primer trimestre de operación continuada.

Y un pipeline que sobrevive es la infraestructura que sostiene un RaaS que escala. Porque cuando el dato llega limpio al la capa de investigación, el valor se concentra donde debe: en la narrativa, en el informe, en el cliente.

La regla de oro: si no lo has perfilado, no lo has asumido. Si no lo has asumido por escrito, lo vas a pagar en producción.

El 90% de los Pipelines de Datos para RaaS Mueren Antes de la Primera Ingesta. No es un Problema de Tecnología.