Agentes autónomos que vigilan los portales de contratación

Los portales de contratación pública se construyeron para humanos que hacen clic por las páginas, no para software que las lee. Cada uno tiene su propia maquetación, su propio formulario de búsqueda, su propia manera de listar los anuncios y su propia costumbre de cambiar esa maquetación sin avisar. Vigilar de forma fiable aunque sea un puñado de estos portales, todos los días, sin perderse un anuncio nuevo ni contar dos veces uno viejo, es un problema más difícil de lo que parece desde fuera. Es lo que los agentes autónomos de vigilancia existen para resolver, y entender cómo funcionan explica por qué algunos enfoques aguantan meses de operación continua y otros se rompen sin ruido en pocas semanas.

Qué hace realmente un agente de vigilancia

En su forma más simple, un agente de vigilancia visita una fuente según un calendario, extrae el contenido nuevo que haya aparecido y lo convierte en un registro estructurado: un título, un comprador, un plazo, una categoría y un enlace de vuelta al anuncio original. Repetido en cientos de fuentes y ejecutado cada día, esto produce una vista continuamente actualizada de lo que está abierto en todo un mercado, algo que ningún equipo podría mantener a mano a un costo razonable.

La complejidad no está en el concepto. Está en hacerlo de forma fiable contra fuentes que nunca se diseñaron para que las leyeran máquinas, que cambian de estructura sin aviso y que a veces fallan, agotan el tiempo de espera o devuelven páginas incompletas por razones ajenas al propio agente.

Conectores por portal: por qué un solo enfoque no sirve para todos

El enfoque ingenuo trata todos los portales de contratación igual: descargar la página, buscar algo que se parezca a un listado de licitaciones y extraerlo. Funciona con las fuentes más simples y estandarizadas y falla casi en todas las demás. Una plataforma nacional de contratación electrónica con una API documentada es un problema completamente distinto de una autoridad sanitaria regional que publica anuncios en PDF dentro de una página estática, que a su vez es distinto de un portal que renderiza sus listados mediante JavaScript después de la carga inicial.

El enfoque más resistente construye un conector dedicado para cada fuente: una pieza de lógica pequeña y hecha a medida que entiende exactamente cómo estructura sus datos ese portal concreto, dónde vive el campo del plazo y cómo distinguir un anuncio realmente nuevo de otro que simplemente ha vuelto a subir al principio de una lista. Un conector para un endpoint de API estructurada no se parece en nada a uno para un portal basado en PDF, y ninguno se parece a uno hecho para un sitio que exige iniciar sesión antes de que los resultados sean visibles. Tratar cada fuente como su propio problema bien entendido, en lugar de forzar a un raspador genérico a manejarlo todo, es lo que hace que la vigilancia aguante en cientos de portales genuinamente distintos.

Detección de cambios: saber qué es realmente nuevo

Un portal rara vez anuncia que un aviso es nuevo. Los agentes tienen que inferirlo, normalmente guardando un registro de lo ya visto, indexado por alguna combinación de identificador de fuente, número de referencia y fecha de publicación, y comparando cada nueva descarga contra ese registro. Si se equivoca en un sentido, la misma licitación aparece tres veces en una semana. Si se equivoca en el otro, una oportunidad realmente nueva se trata en silencio como duplicada y no aparece nunca, el fallo más caro, porque permanece invisible hasta que alguien nota el hueco.

La detección de cambios también tiene que manejar las actualizaciones de anuncios ya existentes. Una prórroga de plazo, una cantidad corregida, un anuncio cancelado: son cambios sobre un registro que ya está en el sistema, y un agente necesita distinguir entre una licitación nueva y una modificación de una ya capturada.

Recuperación de errores: la parte poco glamorosa que más importa

Las fuentes se caen. Las páginas cargan lento y agotan el tiempo de espera. El certificado de un portal caduca por un día. Un cambio de maquetación rompe en silencio el campo que solía contener el plazo. Nada de esto es excepcional; a lo largo de meses de operación continua en cientos de fuentes, es la línea base diaria. Lo que separa una vigilancia confiable de una que se pudre en silencio es cómo se maneja el fallo.

Un agente bien construido no falla en silencio. Cuando no se puede alcanzar una fuente, o los datos extraídos parecen estructuralmente mal (un campo de plazo vacío, un listado que devuelve cero resultados cuando normalmente devuelve decenas), el fallo se señala para que una persona o una comprobación posterior detecte un conector roto antes de que produzca semanas de datos faltantes. Un sistema que falla en silencio es peor que no tener vigilancia, porque crea una falsa confianza en que un mercado está siendo vigilado cuando no lo está.

Por qué lo determinista gana a lo generativo en la recolección

Es tentador apuntar un modelo de lenguaje de propósito general a un portal y pedirle que extraiga lo que parezca una licitación. Para una lectura puntual, puede funcionar razonablemente bien. Como motor de una vigilancia diaria y sin supervisión en cientos de fuentes, es la herramienta equivocada. Un modelo generativo puede parafrasear un plazo, malinterpretar una moneda o producir una respuesta plausible pero errónea sin señal alguna de que algo se torció, y lo hace de forma inconsistente, de modo que la misma página puede leerse bien un día y mal al siguiente.

La extracción determinista, un conector que siempre busca en el mismo lugar el mismo campo dentro de la misma estructura, es aburrida en comparación. También es predecible, comprobable y, sobre todo, falla de maneras detectables en lugar de maneras que corrompen los datos en silencio. Los modelos generativos siguen teniendo un papel real en esta cadena, en particular al leer una licitación una vez recolectada de forma fiable y juzgar si es relevante para una empresa dada. Recolectar el hecho bruto de un anuncio y su plazo es una tarea estrecha y repetitiva donde la lógica determinista es más confiable que un modelo adivinando la estructura.

Dónde encaja esto en un flujo de trabajo de licitación

Nada de esto sustituye el criterio sobre qué licitaciones vale la pena perseguir. Sustituye el trabajo manual y repetitivo de encontrarlas en primer lugar. TRINTA lee lo que una empresa vende y muestra a diario las licitaciones que coinciden desde fuentes oficiales, usando por debajo exactamente este tipo de capa de conectores vigilados de forma continua.