SECOP para una consultora: ruta comprobada al producto

Investigación y pruebas: 25 de septiembre de 2026. Alcance: una sola empresa, uso propio.

Decisión

Sí hay una ruta viable. La búsqueda no necesita depender del navegador de SECOP y ya conseguimos descargar y leer una invitación pública real sin resolver CAPTCHA. Recomiendo continuar con un servicio propio que ingiera datos abiertos, conserve los documentos, analice evidencia y mantenga una cola de excepciones. Una restricción de una fuente debe detener esa operación concreta, no toda la aplicación.

La entrega anterior fue demasiado fácil de interpretar como «todo está resuelto salvo el CAPTCHA». La investigación práctica de esta segunda etapa permite precisar tres cosas:

1. La descarga automática sí funcionó para un documento real completo. El primer 403 no permitía concluir que todos los archivos necesitaran intervención manual.
2. Un aplicativo disponible las 24 horas no puede garantizar que las fuentes publiquen o respondan las 24 horas. Puede seguir buscando y analizando su copia local, indicando su antigüedad y los pendientes.
3. El principal trabajo restante es convertir documentos y versiones en una evaluación verificable. El CAPTCHA es solo una posible incidencia de acceso.

No hace falta construir facturación SaaS, planes ni aislamiento multiempresa. Sí hacen falta acceso privado, copias de seguridad, control del gasto de IA y una persona responsable de revisar las excepciones jurídicas.

1. Qué encontré en Salvedad y AXSoftware

La implementación existe en SalvedadBackend/src/services/datosGov/. sodaClient.js consulta SODA mediante X-App-Token, aplica reintentos y ofrece paginación. trmService.js y ciiuService.js guardan resultados en PostgreSQL mediante Prisma. datosGovSyncWorker.js utiliza BullMQ/Redis para trabajos y programación. El documento técnico de AXSoftware describe la misma integración.

Es una base reutilizable, pero actualmente integra TRM y CIIU; no encontré allí un conector SECOP ni un descargador de pliegos. Podemos reutilizar el patrón de sincronización y la separación entre consulta externa y datos propios. CIIU y UNSPSC son clasificaciones distintas: un código de actividad empresarial no sustituye el código del bien o servicio a contratar.

Encontré y reproduje dos defectos del adaptador existente en una ejecución aislada, sin modificar Salvedad ni consultar su producción:

Evidencia reproducible: evidencia-salvedad.json y test_salvedad_adapter.cjs. Referencias de código: sodaClient.js, líneas 49–53, 98 y 110–111. No extrapolo estos casos simulados como incidentes que ya hayan ocurrido en producción.

Antes de copiar el worker también conviene revisar zona horaria explícita, configuración TLS de Redis, consumo de memoria de la paginación y el alcance real del timeout sobre el cuerpo de la respuesta. Son puntos de revisión de código, no fallas de producción demostradas.

2. Canales disponibles y pruebas reales

Las latencias anteriores corresponden a una petición por caso, no son percentiles ni acuerdos de servicio. Evidencia: evidencia-fuentes-publicas.json.

Socrata documenta que SODA 3 requiere identificación/autenticación para consultas y que SODA 2.1 continúa disponible. El token de aplicación mejora la atribución y manejo de cuotas; no es una clave de acceso a PDFs de SECOP y no elimina sus verificaciones. No debemos cambiar de interfaz para esquivar un 429: se respeta la pausa del proveedor. SODA 3, tokens.

:updated_at permite trabajar incrementalmente, pero Socrata advierte que una sustitución completa del conjunto puede cambiar la marca de todas las filas. Por eso hacen falta hashes de contenido, conciliación periódica y cuidado con borrados y páginas movidas durante la descarga. Campos de sistema.

3. La descarga documental: lo que realmente cambió

El catálogo oficial describe dmgg-8hin como referencias para descarga desde 2025, con actualización diaria. Los archivos se alojan en otro servicio; disponer de su fila no prueba que la descarga esté disponible. Descripción oficial de CCE.

En esta investigación:

• Tres enlaces publicados entregaron HTTP 200 y firma PDF al inspeccionar el comienzo de la respuesta. Esta primera prueba no verificaba el archivo completo.
• Una descarga posterior con el cliente predeterminado obtuvo HTTP 403 para tres archivos.
• Al utilizar el enlace publicado, encabezados explícitos y un User-Agent que identifica verazmente el aplicativo, se obtuvo la invitación completa. El nuevo conector volvió a descargarla y la sirvió desde el almacenamiento local.
• No se resolvió un CAPTCHA, no se reutilizaron cookies de navegador, no se rotaron IP ni se simuló ser otro cliente humano. La explicación causal exacta del rechazo previo requeriría registros del servidor o una prueba controlada más amplia; no atribuyo todo el resultado exclusivamente a un encabezado.

Documento comprobado: Invitación Pública.pdf, ID 861728476, proceso CO1.REQ.11087573, referencia MB-MC-027-2026, Municipio de Belén, Boyacá.

SHA-256: 8564dc33330d9dd39db2c2b72c214a85925fc6cb81c2a6a9eaba9b182e9e34b0.

Esto demuestra un documento completo descargable, no una tasa nacional de éxito de 100%. Tampoco demuestra que imágenes, firmas o gráficos hayan sido interpretados por la extracción de texto. Se conserva el original para verificarlos. URL oficial del documento.

Una segunda vía oficial que debemos tramitar

El PETI 2026 de CCE, página 21, incluye en su inventario una aplicación denominada «Api descarga archivos SECOP» para SECOP I y II. La existencia inventariada está comprobada; no encontré en las fuentes revisadas un contrato público de acceso con URL, autenticación, cuotas y SLA que permita integrarla ya. No se debe presentar una herramienta interna como API pública disponible sin comprobarlo. PETI 2026.

Dejé redactada una solicitud concreta para CCE en SOLICITUD-CCE.md: documentación, acceso para uso empresarial propio, cuota, versión documental, cronogramas y canal de incidentes. No fue enviada. Esta gestión puede convertir la descarga pública observada en una integración con condiciones explícitas, pero su aprobación no está garantizada.

Alternativa comercial verificable

El proveedor de la cuenta mencionada inicialmente, Licitacionescolombia.co, sí anuncia integraciones mediante API. Por tanto, existe una vía comercial concreta para evaluar, distinta de automatizar su interfaz de usuario. Su anuncio público no acredita que nuestra suscripción incluya API, PDFs completos, adendas o derecho de almacenamiento y análisis con IA. API anunciada por el proveedor, reportes e integración.

La API secop-co documentada por Apitude consulta empresas; esa documentación no demuestra una descarga integral de expedientes. No la contrataría como solución al problema de PDFs sin una demostración específica. Documentación del proveedor.

Antes de pagar a cualquier proveedor exigiría una prueba sobre 20 procesos nuestros, con pliego vigente, anexos, adendas, ID oficial, actualización, errores informados y permisos de conservación. Pediría precio por documentos y límites, no solo por búsqueda. Dejé ese cuestionario en EVALUACION-PROVEEDOR.md.

4. Problemas reales que permanecen, con su solución

Ejemplos concretos del documento descargado

La página 9 contiene exigencias sobre actividad CIIU 4761, objeto social, facultades de representación y documentos empresariales. La página 10 pide experiencia sobre un contrato liquidado, con cuantía comparada en SMMLV y ponderación según participación cuando procede. Son criterios observados de ese documento, no reglas universales para toda contratación ni una validación de su legalidad.

La página 15 fija la entrega de propuestas para 25/09/2026 a las 16:00. Esa hora fue extraída del PDF; no se confirmó contra adendas posteriores ni contra el cronograma transaccional, por lo que no debe emplearse como certificación de plazo vigente.

Para este caso, una ficha que solo diga «experiencia: 100 millones» resulta insuficiente. Debe poder probar número de contratos admitidos, objeto, liquidación, fechas, participación, soporte y conversión aplicable. Tampoco se deben inventar índices financieros solo porque existan campos financieros en nuestra aplicación.

5. Cómo debe funcionar el servicio siempre disponible

La disponibilidad debe medirse en tres planos separados:

El sistema debe responder, por ejemplo: «Puede consultar los 42 procesos ya guardados. La última sincronización válida fue ayer a las 10:31. No he podido comprobar nuevas adendas. La búsqueda local funciona; la vigencia del expediente está pendiente». Los números de ese ejemplo son ilustrativos.

Arquitectura para una empresa

SODA / catálogo documental / API contratada autorizada
                    ↓
Sincronizador con trabajos persistentes y controles por fuente
                    ↓
PostgreSQL: procesos, versiones, requisitos, eventos y evidencia
                    +
Almacén de archivos: originales, hashes, OCR y extracciones
                    ↓
Extracción por páginas → reglas numéricas → consolidación y conflictos
                    ↓
Ficha empresarial verificable + análisis Vertex + revisión humana
                    ↓
Aplicación web privada, buscador, chat, bandeja de pendientes y alertas

Propuesta: un backend y un worker permanente, PostgreSQL y almacenamiento de archivos; Redis/BullMQ si se reutiliza el ecosistema Salvedad. Una sola organización y pocos usuarios internos. Railway puede alojarlo aprovechando la experiencia existente, pero requiere definir proyecto, persistencia, acceso y presupuesto antes de desplegar. No se modifica ni carga de trabajo adicional a la producción de Salvedad como parte de esta investigación.

No necesitamos un motor vectorial aparte al inicio: filtros SQL y búsqueda de texto son suficientes para descubrimiento y trazabilidad; la búsqueda semántica puede añadirse cuando mejore resultados medidos.

Sincronización propuesta

1. Definir universo de búsqueda: sectores, modalidades, geografía y horizonte, con posibilidad de ampliarlo. La cobertura debe ser explícita.
2. Carga inicial paginada por ventanas; guardar registros y documentos de interés de forma idempotente. No acumular todo el país en memoria.
3. Detectar cambios con :updated_at, orden total y ventana de solapamiento. Guardar punto de avance solo tras persistir el lote completo. Si hay reemplazo masivo, ejecutar reconciliación por contenido.
4. Actualizar primero procesos próximos al cierre y expedientes seguidos. Una consulta de metadatos cada 30 minutos supone 48 comprobaciones diarias por catálogo; es una política inicial propuesta, no una frecuencia que garantice el proveedor.
5. Ante error, conservar la última copia; pausar la fuente correspondiente; reintentar de forma acotada y con variación controlada. No borrar procesos porque una respuesta falló o llegó incompleta.
6. Conciliar periódicamente bajas, fases, versiones y adendas. Una reanudación tras caída debe alcanzar los cambios pendientes sin duplicar documentos ni llamadas de IA.
7. Alertar por cambio relevante, plazo o falta de vigencia; agrupar fallas repetidas. La interfaz seguirá funcionando con el navegador cerrado porque la sincronización vive en el servidor.

SODA, CSV y OData comparten plataforma. Diversificar formatos puede resolver una incompatibilidad de interfaz, pero no protege contra una caída del dominio o contra datos que aún no se publicaron. La independencia real proviene de nuestra copia, otra fuente con permiso y respaldo operativo.

6. Cómo reconocer el límite sin pedirle al modelo que lo adivine

La clasificación debe derivarse de señales técnicas y evidencia guardada, no de una explicación inventada por IA:

Cada incidente debe registrar canal, consulta o documento, fecha, HTTP, formato, último éxito, próxima acción y grado de certeza de la causa. El usuario debe ver si falla nuestra implementación, la comunicación, el acceso de origen o la evidencia, sin ocultarlo bajo «error de IA».

7. Cambios concretos realizados en el prototipo

Versión local 0.2 preparada y probada:

• Descarga a partir de la URL recuperada del catálogo oficial, con dominio/ruta/ID validados y sin seguir redirecciones arbitrarias.
• Identificación explícita y veraz del cliente HTTP, validación de firma PDF y aviso de diferencia de tamaño.
• Conservación de originales y SHA-256; descarga del original desde el expediente. Los documentos cargados antes de esta versión solo conservan su texto, salvo que se vuelvan a cargar.
• Caché SQLite persistente del último resultado correcto: hasta 1.000 consultas, expiración de consulta normal de 60 s y metadatos de 300 s. Si falla la actualización, permite mostrar una copia de hasta siete días, rotulada sin actualizar. Una copia más antigua no se presenta como respuesta operativa.
• Clasificación de errores, respeto de Retry-After, reintento acotado de timeout/5xx y pausa tras fallos temporales repetidos. Los diagnósticos no ocultan una caída mostrando caché como conexión exitosa.
• Pruebas de conservación tras reinicio, fallo sin caché, HTML inesperado, esquema inválido, cuota, 403, lectura diagnóstica y preservación del original.

39 pruebas automáticas aprobadas. La importación real devolvió 30 páginas, preservó el hash y permitió recuperar el original local con HTTP 200. Evidencia: evidencia-importacion-v2.json.

Esta caché es de consultas previamente ejecutadas; no es todavía el índice completo ni la sincronización continua propuesta. No se ha desplegado un servicio de producción 24/7. La versión sigue siendo local, con Flask de desarrollo y tareas de IA dentro del proceso del servidor; la cola persistente y el despliegue supervisado forman parte de la siguiente fase.

Prueba real de IA: fallas que no detectaba la muestra ficticia

La extracción de la invitación real terminó seis lotes y produjo 97 condiciones con cita encontrada en el texto. Se descartaron otras 16 propuestas por citas que no superaron el control literal. No se midió todavía qué proporción de esas 97 interpretaciones era correcta ni la exhaustividad frente a revisión jurídica.

Se observaron errores reales del modelo: calificó fechas de 2026 como futuras y algunos lotes indicaron que faltaban requisitos o presupuesto que estaban en otras páginas. La extracción había recorrido el texto, pero sus observaciones no estaban consolidadas. Esto demuestra por qué procesar todas las páginas no equivale a comprender correctamente todo el documento.

La implementación se corrigió para aportar la fecha actual, identificar cada observación como parcial y ejecutar una revisión conjunta con todo el texto local antes de cerrar un análisis nuevo. También se comprueban las citas de esa revisión y se invalida la caché de análisis de la versión anterior. El flujo completo se verificó con prueba automatizada; la revisión conjunta se probó adicionalmente sobre el documento real. La evidencia inicial se conserva en evidencia-analisis-real.json para no ocultar esos fallos. La prueba real de revisión conjunta produjo 15 propuestas: 9 conservaron todas sus citas válidas y 6 se descartaron por referencias no verificadas. Este resultado confirma que sigue siendo necesaria la revisión humana y que no puede certificarse exhaustividad. Evidencia: evidencia-revision-conjunta.json.

8. Llegar al producto final: secuencia y condiciones de aceptación

Las jornadas siguientes son estimaciones técnicas para un ingeniero con revisión jurídica disponible, no cotización ni plazo garantizado. Las fases de acceso institucional/comercial pueden transcurrir en paralelo y dependen de terceros.

Total orientativo de ingeniería: 23–40 jornadas, más la disponibilidad del especialista y los tiempos externos. No hace falta esperar una API especial para avanzar con búsqueda, conservación, análisis y descargas públicas que ya funcionen.

No fijo una promesa como «99,9% actualizado»: sería mezclar disponibilidad propia con publicación externa. Podemos adoptar objetivos medibles propios después del piloto. Por ejemplo, 99,5% de disponibilidad de aplicación equivale a un máximo de 216 minutos en un mes de 30 días; es un objetivo propuesto, no un resultado medido ni una garantía de datos frescos.

Modelo de costos sin inventar una tarifa

Costo mensual = infraestructura persistente + almacenamiento/respaldo + OCR por páginas que lo necesiten + tokens de IA realmente procesados + API comercial si se contrata + revisión de excepciones. Se instrumentará consumo por expediente y caché de análisis por hash, para no pagar de nuevo por documentos idénticos. No se verificó aquí una cotización comercial ni se contrató un plan.

Ejemplo de dimensionamiento, no medición de mercado: 100 procesos por mes × 8 archivos × 1 MB supone aproximadamente 0,8 GB nuevos mensuales; si cada proceso aporta 80 páginas analizables, serían 8.000 páginas al mes. Debe sustituirse por la muestra real antes de dimensionar almacenamiento y presupuesto IA.

9. Probabilidad de éxito y decisión de postularse

El producto final sí puede dar una conclusión útil: «con la evidencia disponible cumple estos requisitos, falla estos otros, faltan estos soportes y hay estas alertas». Puede construir escenarios de precio o puntaje cuando existan reglas publicadas.

No convertiría esa conclusión en una probabilidad estadística de adjudicación sin datos históricos, ofertas comparables, definición de resultado, evaluación temporal y calibración. Cumplimiento habilitante, puntaje competitivo y resultado de adjudicación son magnitudes diferentes. Para uso propio de la consultora, empezaría por una decisión postular / subsanar evidencia / consultar a la entidad / descartar, con razones y citas.

Superar mínimos no necesariamente produce puntos. Una tasa de coincidencia entre requisitos registrados no debe disfrazarse como porcentaje de ganar. Esta restricción no impide construir el producto; evita una métrica que perjudicaría decisiones reales.

10. Acciones siguientes ya preparadas

1. Usar el conector corregido y ampliar la muestra documental a los sectores de la empresa.
2. Elegir token propio de la aplicación o autorizar el existente para validar SODA 3; su ausencia no bloqueó las pruebas públicas de esta investigación.
3. Radicar la solicitud técnica a CCE y pedir prueba de la API a Licitacionescolombia.co con el cuestionario adjunto. Los textos están listos; no se enviaron mensajes ni se registraron formularios.
4. Implementar el índice y la cola persistente en un despliegue de una sola empresa, con piloto y medidas de cobertura.
5. Construir la ficha de experiencia y personal por evidencia, antes de automatizar una recomendación de postulación.

La ruta recomendada es avanzar con API pública + repositorio propio + descarga oficial cuando esté disponible + gestión explícita de excepciones. Una respuesta 403 no debe detener el producto; tampoco debe ocultarse. El resultado útil se logra haciendo que la aplicación distinga lo que sabe, lo que conserva y lo que todavía necesita comprobar.