Infraestructura de datos públicos: los puntos de fallo que nadie revisa hasta que es tarde

Hay un tipo de problema que no aparece en ningún dashboard. No lanza alertas. No interrumpe el servicio. Simplemente hace que los datos que recibes sean ligeramente incorrectos, ligeramente incompletos o ligeramente desfasados — y tú no lo sabes hasta que alguien toma una decisión basada en esa información y los resultados no cuadran.

En infraestructura de datos públicos, estos fallos silenciosos son los más peligrosos. Los fallos ruidosos se detectan y se corrigen. Los silenciosos se acumulan.

Este post no trata sobre arquitectura de sistemas en abstracto. Trata sobre los puntos concretos donde las infraestructuras de análisis del universo público de Internet se degradan sin avisar, y qué hacer al respecto.

El error de medir disponibilidad en lugar de integridad

La métrica más vigilada en cualquier infraestructura de datos es el uptime. Si el sistema responde, se asume que funciona. Es un error de enfoque.

Una infraestructura puede estar al 99,9 % de disponibilidad y al mismo tiempo estar procesando datos con un sesgo sistemático. Esto ocurre cuando:

• Una fuente pública cambia su estructura interna y el procesamiento sigue funcionando, pero extrayendo campos incorrectos.
• Una categoría de contenido empieza a estar sobrerrepresentada porque otras categorías han cambiado su cadencia de publicación y el sistema no lo detecta.
• La normalización de fechas falla para un subconjunto de fuentes internacionales con formatos distintos, corrompiendo las series temporales.

En los tres casos, el sistema "funciona". Pero el análisis derivado que produces es incorrecto. La diferencia entre medir disponibilidad e integridad es la diferencia entre saber que el agua llega y saber si el agua es potable.

Los tres cuellos de botella que no aparecen en el mapa técnico

Cuando los equipos de datos dibujan su infraestructura, suelen representar los componentes principales: ingesta, almacenamiento, procesamiento, entrega. Lo que raramente aparece en ese mapa son las capas intermedias donde el dato se transforma de forma implícita.

1. La normalización de fuentes heterogéneas

El universo público de Internet no es homogéneo. Fuentes de distinta tipología, idioma, zona geográfica y estructura técnica conviven en el mismo pipeline. Cada transformación que se aplica para unificarlas introduce una decisión de diseño. Esas decisiones, tomadas en un momento concreto, pueden quedar obsoletas cuando el ecosistema de fuentes evoluciona. Y evolucionan constantemente.

2. La gestión de duplicados a escala

Un mismo contenido puede aparecer en múltiples fuentes con variaciones mínimas: diferente fecha, diferente autor declarado, diferente URL canónica. Sin una capa de deduplicación robusta, el volumen de datos crece, pero la densidad informativa cae. El equipo que consume esos datos recibe más señales, pero la proporción de señales nuevas disminuye. El efecto es un análisis inflado que parece más completo de lo que es.

3. El decalaje entre el ritmo de la fuente y el ritmo del sistema

No todas las fuentes públicas publican al mismo ritmo. Algunas tienen picos muy marcados (eventos, crisis, ciclos informativos). Una infraestructura diseñada para un flujo constante se comporta mal ante esos picos: o descarta datos por sobrecarga, o los encola con un retraso que invalida su utilidad en contextos de análisis en tiempo real.

Cuándo la escala se convierte en un problema de calidad

Escalar la infraestructura sin escalar los mecanismos de control de calidad es uno de los patrones más comunes en equipos que crecen rápido. Al principio, el volumen bajo permite revisiones manuales o semi-manuales. Cuando el volumen se multiplica, esas revisiones desaparecen y nadie las reemplaza con procesos automatizados equivalentes.

El resultado es predecible: la infraestructura procesa más datos, pero la proporción de datos utilizables —los que tienen la estructura correcta, la atribución correcta, la fecha correcta— puede caer. El coste no es técnico inmediato. Es analítico: los modelos que consumen esos datos, los informes que se generan, las alertas que se lanzan, todos se basan en un insumo degradado.

Escalar bien significa escalar también los controles. No como auditoría retrospectiva, sino como parte del pipeline activo.

Qué distingue una infraestructura resiliente de una frágil

La resiliencia en infraestructura de datos públicos no es sinónimo de redundancia hardware. Es la capacidad del sistema de detectar cuándo su propio output ha cambiado de naturaleza, aunque siga funcionando con normalidad aparente.

Algunas señales prácticas que indican resiliencia real:

• Monitorización de distribuciones, no solo de volúmenes. Si el sistema procesa 10.000 elementos al día, ¿la distribución por fuente, idioma o tipología es estable o ha cambiado? Un cambio brusco en la distribución sin causa externa conocida es una señal de fallo interno.
• Alertas sobre ausencia, no solo sobre error. Un pipeline puede fallar silenciosamente simplemente dejando de ingerir datos de una fuente. Si no hay alertas sobre ausencia prolongada de señal de una fuente activa, el fallo no se detecta.
• Trazabilidad del dato desde el origen hasta el análisis. Si no puedes seguir un dato concreto desde su fuente original hasta su forma procesada final, no puedes diagnosticar dónde ocurrió la degradación cuando la detectas.

El coste real de posponer la revisión

En infraestructura de datos, el coste de no revisar se acumula de forma no lineal. Durante semanas o meses, los fallos silenciosos son absorbibles. Los analistas los perciben como "ruido normal". Los modelos los promedian. Los informes los suavizan.

Pero cuando alguien toma una decisión estratégica basada en una tendencia que en realidad era un artefacto del pipeline, el coste se materializa de golpe. Y en ese momento, el rastro de cuándo empezó el problema suele haberse perdido.

La infraestructura de datos que procesa el universo público de Internet —especialmente en el marco del Text and Data Mining (TDM) que regula el Art. 4 de la Directiva (UE) 2019/790— no es un componente estático. Es un sistema vivo que necesita revisión activa, no solo mantenimiento reactivo.

En TrawlingWeb, la respuesta a este problema pasa por un diseño de infraestructura donde los controles de integridad son parte del flujo de producción, no una capa añadida a posteriori. No es una solución perfecta. Es una apuesta por hacer visible lo que suele permanecer oculto.

Si estás evaluando la solidez de tu infraestructura de análisis de datos públicos, la pregunta más útil no es "¿cuántos datos procesas?" sino "¿cómo sabes cuándo tu propio sistema te está fallando?"

Esa pregunta tiene que tener una respuesta operativa, no teórica.