Infraestructura de datos: cuánto cuesta operar sobre fuentes públicas a escala
Hay una conversación que casi nunca ocurre antes de que un proyecto de análisis de fuentes públicas entre en producción: la del coste real de infraestructura. No el coste de la herramienta o la API. El coste de operar de verdad sobre el universo público de Internet, con volumen, con continuidad y con las garantías de calidad que un análisis serio exige.
Ese silencio es caro. No porque nadie sepa que existe ese coste, sino porque se tiende a subestimarlo sistemáticamente hasta que el proyecto ya no puede dar marcha atrás.
Este post no habla de servidores ni de precios de nube. Habla de las decisiones de infraestructura que determinan si un análisis basado en fuentes públicas puede sostener su promesa operativa en el tiempo.
El error de medir solo el coste de entrada
La mayoría de los equipos que evalúan infraestructura para Text and Data Mining (TDM) miden lo que cuesta acceder al dato. Es un error de marco.
El dato público tiene un ciclo: aparece, se actualiza, se elimina, se duplica, cambia de estructura. Una infraestructura que solo mide el coste de acceso ignora todo lo que ocurre después: la normalización, la deduplicación, la gestión de versiones, la resolución de inconsistencias entre fuentes.
En proyectos que monitorizan miles de fuentes simultáneas, ese trabajo posterior puede suponer entre el 40 % y el 60 % del esfuerzo computacional total. Quien no lo contabiliza al inicio descubre más tarde que su arquitectura no escala porque estaba diseñada solo para la mitad del problema.
Latencia y frecuencia: los dos parámetros que nadie sincroniza bien
Una fuente pública no emite señales a ritmo constante. Algunos dominios actualizan su contenido cada hora; otros, una vez a la semana. La mayoría, de forma irregular. Una infraestructura rígida —que consulta todas las fuentes con la misma frecuencia— genera dos problemas simultáneos.
Por exceso: consume recursos procesando fuentes que no han cambiado, infla los costes operacionales y genera ruido en los análisis derivados.
Por defecto: pierde señales relevantes en fuentes de alta actividad porque el intervalo de consulta es demasiado amplio para su cadencia real.
La solución no es técnica en el sentido estrecho. Es de diseño. Una infraestructura de datos madura ajusta dinámicamente la frecuencia de procesamiento según el comportamiento histórico de cada fuente. Eso requiere memoria del sistema, no solo capacidad de acceso.
Sin esa adaptación, el análisis no falla de golpe. Falla de forma silenciosa: los patrones que detecta son ligeramente incorrectos, los volúmenes están sesgados, y las tendencias aparecen con retraso.
El coste oculto de la cobertura incompleta
Otro factor que raramente entra en los cálculos iniciales: el coste de lo que no se procesa.
Una infraestructura con cobertura del 70 % del universo relevante para un análisis no produce resultados que sean el 70 % de los correctos. Produce resultados que pueden ser sistemáticamente incorrectos si ese 30 % ausente tiene un sesgo geográfico, temático o temporal específico.
En análisis de menciones, por ejemplo, ignorar fuentes de nicho o de ámbito regional puede hacer que un fenómeno emergente parezca marginal cuando en realidad está concentrado en segmentos que la infraestructura no cubre. El modelo analítico no sabe lo que no ve. Y no avisa.
Esto convierte la cobertura en una variable de calidad, no solo de cantidad. Y medir la calidad de la cobertura requiere infraestructura adicional: un sistema que registre lo que debería haber procesado y no procesó, no solo lo que procesó.
Escalabilidad no lineal: cuándo el volumen rompe el diseño
Existe una ilusión habitual en los proyectos de datos a escala: que una arquitectura que funciona bien con 10.000 fuentes seguirá funcionando igual con 100.000. En la mayor parte de los casos, no es así.
El problema no está en el procesamiento bruto. Está en las capas de coordinación: la gestión de prioridades, la resolución de conflictos entre fuentes, la coherencia del índice, la trazabilidad del dato desde su origen hasta el análisis final.
A partir de ciertos umbrales de volumen, estos procesos de coordinación crecen de forma no lineal. Una infraestructura diseñada para ser barata en los primeros estadios puede volverse prohibitivamente costosa cuando el proyecto escala, precisamente porque sus decisiones de diseño iniciales optimizaron para el caso pequeño.
El parámetro que mejor anticipa este problema no es el número de fuentes, sino el número de relaciones entre fuentes: duplicados cruzados, actualizaciones que invalidan análisis anteriores, fuentes que citan a otras fuentes. Cuanto más denso el grafo de relaciones, más cara la coordinación.
Qué distingue una infraestructura de datos sostenible
No existe una arquitectura perfecta para operar sobre el universo público de Internet. Sí existen principios que distinguen las infraestructuras que aguantan en producción de las que se colapsan bajo su propio peso.
Modularidad real. Cada componente —acceso, procesamiento, normalización, indexación— debe poder evolucionar de forma independiente. Las arquitecturas monolíticas parecen más simples al principio y son más caras a mediano plazo.
Observabilidad nativa. Una infraestructura que no expone métricas internas de forma continua no permite detectar degradación hasta que ya ha afectado al análisis. El monitoreo no es una capa adicional; es parte del diseño desde el inicio.
Gestión explícita de la incertidumbre. El dato público no es determinista. Las fuentes fallan, cambian de estructura, desaparecen y reaparecen. Una infraestructura robusta modela esa incertidumbre y la traslada al análisis de forma transparente, en lugar de esconderla.
Alineación con el marco legal. En el contexto del Art. 4 de la Directiva (UE) 2019/790 sobre Text and Data Mining, el diseño de infraestructura no es solo una decisión técnica. El modo en que se accede, procesa y retiene el dato tiene implicaciones directas sobre la base legal que ampara el análisis. Una infraestructura bien diseñada documenta ese flujo, no lo oscurece.
La infraestructura no es el fondo del stack, es su base
En TrawlingWeb, el trabajo sobre fuentes públicas ha puesto de manifiesto algo que los proyectos aprenden tarde: la infraestructura no es lo que hay debajo del análisis. Es lo que determina si el análisis es posible.
Un modelo brillante alimentado por datos mal gestionados produce conclusiones erróneas con gran precisión técnica. Y un equipo analítico sin visibilidad sobre cómo llega el dato no puede saber en qué momento sus inferencias dejaron de ser fiables.
La pregunta que vale la pena hacerse antes de escalar no es "¿tenemos suficiente potencia de cómputo?" sino "¿entendemos completamente cómo se mueve el dato desde que existe hasta que lo usamos?". Si la respuesta no es clara, la infraestructura todavía no está lista para producción.