# Cómo Trinta monitorea cientos de fuentes cada día: por dentro de la arquitectura

> Por dentro de la arquitectura de monitoreo de Trinta: conectores escritos a mano, escaneos diarios programados, enriquecimiento documental y agentes de auditoría.

Source: https://trinta.ai/es/blog/inside-trinta-architecture-382-sources · Published: 2026-07-27 · Category: Technology · 7 min read
Keywords: tender monitoring, public procurement, tender connectors, e-procurement portals, bid intelligence, TED PNCP scanning

Un responsable de propuestas que exporta equipos a África occidental, el Golfo y América Latina tiene, en el papel, un solo trabajo: no perderse nunca una licitación relevante. En la práctica ese trabajo es casi imposible a mano. Los anuncios viven en más de 380 lugares distintos: TED de la UE, PNCP de Brasil, SECOP de Colombia, DNCP de Paraguay, el Banco Mundial y UNGM, más decenas de portales nacionales de contratación electrónica, almacenes centrales de medicamentos (NUPCO, KEMSA, CENAME, SALAMA), redes hospitalarias de la seguridad social (IMSS, EsSalud, CCSS) y hospitales de referencia sueltos que publican un único PDF y siguen adelante. Cada uno usa un idioma, una maquetación, un formato de plazo y una política de acceso diferentes. Revisar aunque sea treinta de ellos cada mañana es un puesto de tiempo completo, y el que usted se salta el martes es el que cerró el viernes.

Ese problema de monitoreo es exactamente lo que la arquitectura de Trinta existe para resolver. Así funciona realmente por dentro.

## Más de 750 conectores escritos a mano, no un scraper mágico

El atajo tentador, cuando hay que leer cientos de fuentes, es construir un scraper universal ingenioso y apuntarlo a todas partes. Probamos ese camino y lo descartamos a propósito. Cada portal tiene sus propias manías: esquemas de paginación, verificaciones anti falsificación de peticiones (CSRF), archivos masivos de contratación abierta (OCDS) entregados como ZIP mensuales, sesiones de invitado en dos pasos que le entregan una cookie de visitante antes de mostrarle nada. Un único motor genérico maneja mal todo eso.

Por eso Trinta funciona con **conectores deterministas escritos a mano**: un componente pequeño y hecho a medida por fuente, cada uno afinado al comportamiento real de ese portal. La flota creció de unos 15 conectores a más de 750, y sigue creciendo. Un conector para una API estructurada como TED o PNCP es simple. Un conector para un portal que muestra un botón de "Iniciar sesión" pero que sirve en silencio su lista de licitaciones desde un endpoint público, sin autenticación, exige trabajo de detective: renderizamos la página una vez, observamos qué llamada de API devuelve realmente los datos y después llamamos a ese endpoint directamente. Esa técnica por sí sola abrió decenas de portales que desde afuera parecían amurallados.

Algunos principios mantienen honesta a la flota:

- **Solo fuentes oficiales.** Rastreamos los agregadores (esos sitios revendedores de "licitaciones globales") hasta el anuncio original y guardamos únicamente la URL oficial. El enlace de un agregador nunca cuenta como fuente.
- **Nunca inventar un plazo.** Si la fecha de cierre vive solo dentro de un PDF, el conector lo deja en blanco en vez de adivinar, y un paso posterior lo verifica.
- **Un archivo, un portal.** Cada conector está aislado, así que un portal que cambia su maquetación rompe solo su propio conector, nunca el escaneo completo.

## Un escaneo programado que corre sin que nadie mire

Los conectores no sirven de nada si alguien tiene que apretar el botón de inicio. Todo el proceso corre sobre una **tarea programada en la nube** (un cron diario en GitHub Actions) que no necesita ningún portátil abierto ni ninguna persona despierta. Cada ejecución hace la misma secuencia disciplinada:

1. **Recolección.** Todos los conectores corren en paralelo, con un tiempo límite estricto por fuente para que un portal lento o roto nunca pueda frenar ni tumbar el escaneo entero.
2. **Ingesta y triaje.** Los anuncios nuevos se integran al repositorio, los vencidos se descartan y el ruido evidente se filtra.
3. **Enriquecer, auditar, publicar.** Se descargan los documentos, se revisa cada licitación y los resultados se despliegan al feed en vivo.

Dos filtros hacen el trabajo pesado durante la recolección. Un **filtro de relevancia** compara cada anuncio con un perfil multilingüe de palabras clave (inglés, francés, español, portugués, árabe, hebreo), de modo que un anuncio turco o brasileño se juzga en su propio idioma y no en una traducción aproximada. Y un **filtro de alcance** descarta lo que parece correcto pero no lo es: para quien compra sistemas, un anuncio de pura reposición de consumibles o de alquiler de equipos queda fuera, y el filtro conoce el vocabulario del alquiler en cinco idiomas, así que "locacao", "alquiler" y "location" lo activan por igual.

## Enriquecimiento documental: la lista de archivos, no solo el enlace

Encontrar una licitación es la mitad del trabajo. La otra mitad es leerla, y ahí es donde los equipos pierden horas: abrir el portal, buscar el expediente, descargar cada anexo. La **capa de enriquecimiento documental** de Trinta hace eso automáticamente. Un despachador enruta cada anuncio al extractor correcto:

- Los anuncios de **TED** se analizan desde sus datos estructurados eForms para encontrar el enlace a los documentos oficiales, que después se sigue hasta el portal del comprador para listar los archivos.
- El expediente del **PNCP de Brasil** se lee a través de su API limpia de lista de archivos, en lugar de rasparlo de la página.
- **Todo lo demás** pasa por un extractor genérico que lee la página del anuncio y lista los archivos descargables por tipo, excluyendo los enlaces de navegación, de ayuda y de texto legal estándar para que la lista se mantenga precisa.

Este paso es totalmente determinista y no necesita ningún modelo de IA, así que corre barato en cada escaneo. El resultado es que una licitación suele llegar con el enlace a su expediente y una lista de anexos ya adjuntos, de modo que el equipo de propuestas empieza leyendo en lugar de buscando.

## Un agente de auditoría que puntúa cada licitación, y que falla en voz alta

La última etapa es la que casi todas las herramientas de monitoreo se saltan. Después de la recolección y el enriquecimiento, un **agente de auditoría** revisa cada licitación que todavía no fue revisada. Abre los documentos accesibles, lee el alcance, mapea los requisitos contra lo que el cliente realmente suministra y asigna una puntuación de encaje con una justificación breve. Esa puntuación, y no un conteo tosco de palabras clave, es la que ordena el feed, así que un lead con puntuación alta es uno cuyos requisitos ya fueron contrastados por alguien.

Hay una regla de seguridad deliberada grabada en el código, no solo en la documentación: **toda licitación tiene que ser auditada antes de publicarse.** Si el paso de auditoría no puede correr (por ejemplo, por una clave de API faltante) o no audita nada, el escaneo entero falla en voz alta y se detiene. Nada sin revisar llega al feed en vivo. Preferimos no mostrar ninguna actualización antes que mostrar una equivocada.

## Nunca datos falsos

Debajo de todo esto hay una regla que moldea cada decisión de diseño: **nunca fabricamos datos para tapar un hueco.** Si un valor no es público, y los valores de contratación de verdad quedan sellados con sorprendente frecuencia (presupuestos brasileños bajo ciertas leyes, anuncios de obra alemanes, cifras de directorio del Golfo detrás de un acceso), el feed muestra "No divulgado" con el motivo, nunca un número inventado. La tasa por los documentos de licitación no es el valor del contrato, y jamás dejamos que una se haga pasar por el otro. Los anuncios viejos se podan con una ventana de recencia. Los anuncios de adjudicación y de resultado, que no tienen un plazo real, se filtran para que no puedan aparecer como oportunidades vivas.

El beneficio para el dueño de una pyme, el exportador o el consultor es simple. En lugar de patrullar 1.519 portales y confiar en que los cubrió todos, usted abre un único feed diario de licitaciones emparejadas, ya puntuadas por encaje, ya con sus documentos adjuntos, ya limpias de ruido, de contratos de reposición y de anuncios vencidos. El problema de monitoreo no desaparece; simplemente deja de ser suyo. Ese es todo el punto de un feed diario puntuado y emparejado: las cientos de fuentes siguen cambiando cada noche, y usted solo llega a ver el puñado que le importa.

## Frequently asked questions

**¿Cómo monitorea TRINTA cientos de fuentes de contratación pública?**

Con una flota de conectores escritos a mano en lugar de un scraper genérico: cada conector apunta a un portal y extrae de él filas con fecha, sin necesidad de iniciar sesión. Un escaneo programado corre a diario sin supervisión, el enriquecimiento documental recupera la lista de archivos adjunta a cada anuncio, y un agente de auditoría puntúa cada licitación y falla en voz alta en lugar de callarse.

**¿Por qué no usar un único scraper genérico para todos los portales?**

Porque los portales gubernamentales no tienen nada en común a nivel estructural. Difieren en el marcado, la navegación, el manejo de sesiones, los muros de registro y el formato de publicación, y varios publican las licitaciones solo como PDF escondidos en la navegación. Un scraper genérico resuelve los fáciles y se pierde el resto en silencio, que es peor que no cubrirlos.

**¿Cómo evita TRINTA publicar datos inventados?**

Un agente de auditoría puntúa cada licitación y está diseñado para fallar en voz alta en lugar de degradarse en silencio, así que una fuente que deja de devolver filas reales aparece como un error y no como un resultado vacío que parece una semana tranquila. La regla de operación es que ningún registro es preferible a un registro fabricado y verosímil.

---

All guides: https://trinta.ai/blog · Site index for agents: https://trinta.ai/llms.txt