IA aplicada a datos públicos: qué determina que el modelo acierte o falle

Hay una conversación que se repite en muchos equipos de inteligencia de negocio: el modelo está entrenado, la infraestructura lista, y aun así los resultados no sirven para tomar decisiones. No porque el algoritmo sea malo. Sino porque nadie dedicó el tiempo suficiente a examinar qué datos entran, desde dónde vienen y en qué condiciones llegan.

Aplicar IA sobre datos del universo público de Internet es una de las apuestas más sólidas del momento. El volumen disponible es inmenso, la variedad de fuentes es real y la señal existe. Pero existe en bruto, distribuida, a veces incompleta, a veces redundante. Y los modelos no saben distinguir cuándo están procesando información útil y cuándo están procesando ruido bien formateado.

Este post no trata de arquitecturas de modelos. Trata de las condiciones que hacen que la IA sobre datos públicos produzca análisis accionable, y de las que la condenan a producir resultados que parecen correctos pero no lo son.

La ilusión de la cobertura completa

El primer error operativo es asumir que más fuentes equivale a mejor análisis. Un sistema que indexa diez mil fuentes puede producir peores insights que uno que indexa dos mil, si las diez mil incluyen duplicados sistémicos, fuentes de baja cadencia o señales que no son representativas del fenómeno que se quiere analizar.

Cuando un modelo de clasificación o de detección de tendencias trabaja sobre un corpus con alto porcentaje de duplicación, aprende a reconocer patrones que son artefactos del pipeline, no del mundo real. El modelo se "acostumbra" a ver ciertos términos sobrerepresentados sencillamente porque una misma pieza se procesa quince veces con ligeras variaciones de titular.

La consecuencia práctica: las tendencias detectadas están sesgadas hacia las fuentes más ruidosas, no hacia las más informativas. Y eso no lo corrige ningún ajuste de hiperparámetros.

Latencia, frescura y ventanas temporales mal calibradas

Un modelo que analiza menciones o señales del entorno tiene una variable crítica que a menudo se trata como secundaria: el tiempo que transcurre entre que un evento ocurre en el universo público y el momento en que el dato llega al sistema de análisis.

Si la latencia media de ingesta es de seis horas, el modelo opera con una visión retrasada del entorno. Esto importa poco cuando el análisis es estratégico y la ventana temporal es semanal. Importa mucho cuando el caso de uso exige detección de riesgo reputacional, movimientos de competencia o señales de mercado que tienen un ciclo de vida de horas.

El problema no siempre es la velocidad de procesamiento del modelo. Con frecuencia es la velocidad a la que los datos llegan al pipeline. Un modelo rápido que trabaja sobre datos lentos produce análisis rápido de realidades pasadas. La precisión aparente es alta; la utilidad, baja.

Heterogeneidad de fuentes: ventaja o trampa

La riqueza del universo público reside en su diversidad: foros especializados, publicaciones sectoriales, fuentes institucionales, agregadores temáticos, plataformas de discusión profesional. Cada tipo de fuente tiene su propio registro lingüístico, su propio ciclo de actualización y su propia lógica de relevancia.

Un modelo entrenado o ajustado principalmente sobre un tipo de fuente generaliza mal sobre los demás. La terminología que usa un foro técnico para referirse a un riesgo de seguridad no es la misma que usa una publicación de análisis financiero para describir el mismo evento. Si el modelo no ha visto ambos registros con suficiente representación, clasificará uno de los dos de forma sistemáticamente incorrecta.

La solución no es técnica en primera instancia: es de diseño del corpus. Antes de ajustar ningún modelo, hay que mapear con precisión qué tipos de fuentes componen el universo relevante para el caso de uso, qué peso relativo tiene cada segmento y si ese peso está representado en los datos de entrenamiento o ajuste.

El rol del preprocesamiento: donde se gana o se pierde

Entre el dato público en bruto y el dato que entra al modelo existe una cadena de transformaciones que habitualmente recibe menos atención que el modelo mismo. Normalización de caracteres, detección de idioma, deduplicación, identificación de la fuente original frente a fuentes sindicadas, extracción de metadatos relevantes.

Cada uno de estos pasos introduce decisiones que afectan directamente a la calidad del análisis. Una deduplicación demasiado agresiva elimina matices importantes: no es lo mismo que el mismo hecho lo cubran veinte fuentes sin añadir perspectiva que que lo cubran veinte con enfoques distintos. Una deduplicación insuficiente infla artificialmente el volumen y distorsiona el análisis de tendencias.

El preprocesamiento no es un paso técnico neutro. Es una decisión editorial sobre qué información se considera relevante y qué se descarta. Cuando ese paso no está documentado ni auditado, el equipo que interpreta los resultados del modelo no sabe exactamente sobre qué está razonando.

Cuándo la IA sobre datos públicos sí funciona

Hay casos de uso donde la combinación de Text and Data Mining (TDM) con modelos de IA produce resultados consistentemente útiles. La clave está en que el problema esté bien definido antes de elegir el modelo.

Detección de variaciones en el tono de las menciones sobre una entidad en un sector específico, a lo largo del tiempo, con cobertura de fuentes acotada y auditada: funciona. Identificación de señales de entrada de nuevos actores en un mercado, a partir del análisis de menciones en fuentes sectoriales con latencia controlada: funciona. Clasificación de riesgos regulatorios emergentes a partir de fuentes institucionales y publicaciones especializadas: funciona, cuando el corpus está bien diseñado.

Lo que no funciona es pedir al modelo que produzca inteligencia accionable sobre un corpus que no ha sido diseñado para el caso de uso, con latencia desconocida, sin deduplicación auditada y sin representación equilibrada de los tipos de fuente relevantes.

Antes de ajustar el modelo, audita el dato

Si hay una conclusión práctica que emerge de observar cómo los equipos trabajan con IA sobre datos públicos, es esta: la mayoría de los problemas de rendimiento no se resuelven ajustando el modelo. Se resuelven mejorando el entendimiento de qué datos entran, en qué estado y desde qué fuentes.

Esto implica auditar el pipeline antes de invertir en el algoritmo. Implica definir la cobertura de fuentes como una decisión estratégica, no como un parámetro técnico por defecto. Y implica establecer métricas de calidad del dato —latencia, deduplicación, representatividad— antes de establecer métricas de rendimiento del modelo.

En TrawlingWeb, el marco de trabajo sobre el universo público de Internet parte precisamente de ahí: del dato estructurado y procesado conforme al Art. 4 de la Directiva (UE) 2019/790, antes de cualquier capa de análisis. Porque sin ese orden, la inteligencia que produce la IA no es inteligencia: es confusión bien presentada.