Datos para LLMs: por qué el modelo aprende lo que le das, no lo que imaginas
Hay una discusión que domina el sector de la inteligencia artificial aplicada a datos: qué modelo usar, qué arquitectura, qué proveedor de infraestructura. La semana pasada, varios medios cubrían con atención los acuerdos entre grandes jugadores para expandir capacidad de cómputo en nuevas regiones. La narrativa es siempre la misma: más potencia, más escala, mejores resultados.
Lo que esa narrativa no cuenta es lo que ocurre antes del cómputo. Antes de que el modelo procese nada, alguien tiene que decidir qué datos entran. Y ahí es donde los proyectos de IA aplicada a fuentes públicas suelen fracasar en silencio.
No por falta de modelo. Por falta de criterio sobre el dato.
El supuesto silencioso que rompe los pipelines
Cuando un equipo decide usar un LLM para analizar el universo público de Internet —tendencias, menciones, señales sectoriales, discurso público—, suele partir de un supuesto implícito: que los datos ya están listos para entrar al modelo. Que el texto es texto, que las fuentes son equivalentes entre sí, y que más volumen produce más precisión.
Los tres supuestos son falsos.
El texto que proviene de fuentes públicas no es homogéneo. Una señal publicada en un foro técnico, un comunicado institucional y un hilo de red social tienen estructuras, registros y densidades informativas radicalmente distintas. Si el pipeline no diferencia el origen antes de alimentar el modelo, el modelo tampoco diferencia. Generaliza sobre ruido.
El volumen, por su parte, no resuelve la ambigüedad. La amplifica. Un LLM que procesa diez mil menciones irrelevantes no produce un análisis más robusto: produce un análisis más contaminado con más apariencia de solidez.
Qué significa "calidad del dato" en contexto LLM
La calidad del dato en este contexto no es una propiedad del texto en sí. Es una relación entre el texto, el propósito del análisis y el momento en que se recoge.
Tres dimensiones concretas:
Procedencia verificable. ¿De qué tipo de fuente proviene el dato? ¿Cuál es su alcance real? ¿Publica con regularidad o de forma errática? Un modelo entrenado o consultado sobre datos cuya procedencia es opaca no puede producir conclusiones auditables. Y en contextos regulados —o simplemente en contextos donde alguien tiene que firmar una decisión basada en ese análisis—, la trazabilidad no es opcional.
Temporalidad del dato. Los LLMs no tienen problema con el lenguaje. Tienen problema con el tiempo. Un modelo que procesa datos de hace seis meses como si fueran de hoy genera respuestas coherentes sobre una realidad que ya no existe. En análisis de entorno, donde el discurso público puede cambiar en horas, la latencia del dato no es un detalle técnico: es la diferencia entre una señal útil y una señal inútil con buena gramática.
Cobertura real frente a cobertura aparente. Es posible tener acceso a muchas fuentes y perder las que importan. Si el universo de fuentes no está bien diseñado —si hay vacíos geográficos, sectoriales o por tipo de medio—, el modelo trabaja sobre una muestra sesgada. Y el sesgo de la muestra no desaparece al escalar el modelo: se amplifica.
El marco legal que nadie menciona cuando habla de LLMs y datos públicos
El Art. 4 de la Directiva (UE) 2019/790 establece que el Text and Data Mining sobre fuentes a las que se tiene acceso legítimo es una excepción permitida por defecto, siempre que el titular de los derechos no lo haya restringido expresamente. Esto crea un espacio legal claro para el análisis de datos públicos con fines de investigación, desarrollo y aplicación de IA.
Pero ese espacio legal tiene condiciones que los proyectos de IA suelen ignorar: la copia debe estar justificada por el análisis, no ser el fin en sí misma. El procesamiento debe producir análisis derivado, no redistribución de contenidos. Y la cadena de custodia del dato —de dónde vino, cuándo, con qué condiciones de acceso— debe poder reconstruirse.
Cuando un equipo conecta un LLM a un flujo de datos públicos sin haber resuelto estas preguntas, no está en zona gris. Está en zona de riesgo documentado. El hecho de que nadie haya reclamado todavía no significa que el marco legal sea irrelevante.
Dónde falla realmente el pipeline antes del modelo
La experiencia acumulada en análisis del universo público de Internet muestra que los fallos no suelen estar en el modelo. Están en tres puntos anteriores:
Normalización inconsistente. Fuentes distintas usan formatos distintos, convenciones distintas, estructuras de metadatos distintas. Si el pipeline no normaliza antes de alimentar al modelo, el modelo recibe entradas heterogéneas que interpreta como si fueran homogéneas.
Ausencia de filtros semánticos en la entrada. No todo lo que menciona un término es relevante para el análisis de ese término. Alimentar un LLM con todo lo que contiene una palabra clave sin filtro de contexto produce el mismo efecto que buscar en un diccionario sin saber qué acepción necesitas.
Falta de actualización continua. Un análisis de entorno basado en datos estáticos no es análisis de entorno. Es arqueología. Los modelos necesitan flujos vivos, no volcados puntuales, para producir señales accionables sobre el presente.
Lo que el proveedor de infraestructura no te va a resolver
La expansión de capacidad de cómputo en nuevas regiones, los acuerdos entre grandes plataformas de IA para escalar sus centros de datos, la proliferación de agentes especializados para análisis empresarial: todo esto mejora lo que ocurre dentro del modelo. No mejora lo que ocurre antes.
La calidad del dato de entrada es responsabilidad de quien diseña el pipeline. No del proveedor del modelo, no de la arquitectura de inferencia, no del hardware subyacente.
TrawlingWeb opera sobre esta convicción: el valor no está solo en procesar texto, sino en garantizar que el texto que entra al análisis sea el adecuado, en el momento adecuado, con la trazabilidad necesaria para que el resultado sea defendible. El análisis derivado que emerge de fuentes públicas bien estructuradas —bajo el marco del Art. 4 Directiva (UE) 2019/790— no es un subproducto del modelo. Es una decisión de diseño anterior al modelo.
Quien entienda esto antes escalará mejor. Quien lo ignore seguirá invirtiendo en cómputo para procesar ruido más rápido.