Infraestructura de datos públicos: disponibilidad no es lo mismo que consistencia

Hay un error de diagnóstico que aparece con frecuencia en equipos que trabajan con datos del universo público de Internet: confundir que los datos están con que los datos sirven. Un sistema puede tener cobertura alta, tiempo de acceso bajo y volumen aparentemente correcto — y aun así producir análisis defectuosos. El motivo casi siempre es el mismo: se ha optimizado la disponibilidad, pero no la consistencia.

Son dos propiedades distintas. Y entender exactamente dónde divergen es lo que separa una infraestructura funcional de una infraestructura fiable.

Qué significa disponibilidad en un contexto de datos públicos

En infraestructura de datos, disponibilidad quiere decir que el sistema puede acceder a las fuentes, procesar los contenidos y devolver resultados dentro de un margen de tiempo aceptable. Es una métrica operativa: tiempo de actividad, tasa de error, latencia de respuesta.

Es necesaria. Pero no suficiente.

Una fuente puede estar disponible y devolver datos estructuralmente incorrectos. Puede entregar un campo de fecha en formato inconsistente con el resto del corpus. Puede incluir fragmentos duplicados por cambios en la paginación original. Puede omitir secciones completas porque el marcado HTML de la fuente cambió sin previo aviso y el parser no lo detectó como error — simplemente silenció el fallo.

En todos esos casos, el sistema reportará disponibilidad del 99,x%. El análisis derivado, sin embargo, estará contaminado.

Por qué la consistencia es más difícil de medir — y más cara de ignorar

La consistencia en datos públicos tiene al menos tres dimensiones que conviene separar:

Consistencia estructural. Los campos llegan en el formato y con la semántica esperada. Una fecha es una fecha, no un string libre. Un identificador de fuente no varía entre registros del mismo origen. El esquema no muta silenciosamente entre ejecuciones.

Consistencia temporal. El dato corresponde al momento que el sistema indica. Un contenido indexado hoy no puede llevar marca temporal de hace tres semanas salvo que el sistema lo identifique explícitamente como retroalimentación histórica. En análisis de tendencias o monitorización de señales, un desfase temporal no etiquetado introduce ruido que se comporta como señal.

Consistencia de cobertura. Las fuentes que el sistema procesa hoy son las mismas que procesó ayer, con las mismas reglas. Si una fuente se cae y se reincorpora tres días después, ese vacío debe ser trazable. Si no lo es, el analista ve una caída de menciones y no sabe si es real o es un artefacto de la infraestructura.

Estas tres dimensiones no se monitorizan con las mismas herramientas que la disponibilidad. Requieren validación activa del dato, no solo del pipeline.

Dónde se introducen las roturas más habituales

En la práctica, los problemas de consistencia en infraestructuras de datos públicos tienden a concentrarse en tres puntos:

En el procesamiento de fuentes heterogéneas. El universo público de Internet no tiene un estándar único. Foros, bases de datos regulatorias, repositorios institucionales, medios digitales y redes sociales abiertas utilizan estructuras radicalmente distintas. Un pipeline que no tiene capas de normalización robustas produce datos que parecen comparables pero no lo son.

En las actualizaciones de fuentes. Las fuentes cambian: rediseños, cambios de CMS, nuevas políticas de acceso, variaciones en la estructura de los contenidos. Cada cambio es un potencial punto de rotura silenciosa. Los sistemas que no tienen detección de drift estructural en sus fuentes acumulan inconsistencias que solo afloran cuando alguien intenta cruzar series temporales largas.

En la integración aguas abajo. Incluso cuando el dato llega limpio, el modelo o sistema que lo consume puede introducir inconsistencias si no valida la conformidad del esquema en tiempo real. Un campo que debería ser obligatorio y llega vacío no siempre genera un error visible — a veces simplemente produce un resultado degradado que nadie atribuye a la infraestructura.

Qué implica esto en términos de diseño

Una infraestructura de datos públicos diseñada para análisis serio necesita, como mínimo, tres capacidades que van más allá de la disponibilidad:

Observabilidad del dato, no solo del sistema. Saber que el servidor responde no es suficiente. Es necesario saber que el dato que devuelve es conforme con el esquema esperado, que la cobertura de fuentes no ha tenido variaciones no controladas y que las marcas temporales son fiables. Esto requiere instrumentación específica a nivel de dato.

Trazabilidad de anomalías. Cuando un análisis produce un resultado inesperado, debe ser posible remontar el origen: ¿fue un cambio en la fuente? ¿Un fallo de normalización? ¿Una variación en la cobertura? Sin trazabilidad, cada anomalía se convierte en una investigación manual.

Separación entre dato crudo y dato validado. Los sistemas que mezclan ambos en el mismo flujo sin distinción explícita son fuentes de error estructural. El dato crudo tiene valor para ciertos usos; el dato validado tiene valor para el análisis. Tratarlos como equivalentes es el origen de muchos fallos difíciles de diagnosticar.

La pregunta que conviene hacerse antes de escalar

Cuando un equipo plantea escalar su infraestructura de datos públicos — más fuentes, más volumen, más frecuencia de actualización — la pregunta operativa suele ser: ¿aguanta el sistema? Pero hay una pregunta previa que raramente se formula con la misma claridad: ¿los problemas de consistencia que ya existen se escalarán también?

Porque escalar disponibilidad es relativamente directo. Escalar consistencia requiere haber resuelto primero los problemas de validación, trazabilidad y normalización. Si no se resuelven antes, el crecimiento en volumen solo amplifica el ruido.

En TrawlingWeb, el procesamiento del universo público de Internet bajo el marco del Text and Data Mining (Art. 4 Directiva UE 2019/790) está diseñado con esta distinción como criterio operativo central. La disponibilidad es el punto de partida, no el objetivo.

Si estás evaluando qué exigirle a tu infraestructura de datos públicos, la documentación técnica de TrawlingWeb puede ser un punto de referencia útil para establecer los criterios correctos.