Dossier técnico — Argos · Radar del Gasto Público

Caso ancla: Sector Hacienda y Crédito Público

Documento técnico para el Ministerio de Hacienda y los órganos de control. Explica qué es la plataforma, cómo analiza, con qué datos, cómo se limita a sí misma, y presenta los descubrimientos verificados del sector. Toda alerta es preliminar y requiere revisión humana: el modelo prioriza, la autoridad competente decide. Ninguna cifra es una acusación ni una prueba de irregularidad.

Convención metodológica (en todo el documento): [H] hecho · [HIP] hipótesis · [INF] inferencia · [REC] recomendación · [RISK] riesgo · [TODO] dato faltante. Sensibilidad: 🟢 público/gestión · 🟡 base legal/cuidado · 🔴 sensible.

0. Alcance y límites

• [H] Argos analiza dinero y gestión pública, no al ciudadano. El objeto son presupuestos, contratos, procesos y entidades del Estado; nunca la vida privada de las personas.
• [H] Es una prueba de concepto de transparencia fiscal, independiente; no representa ni suplanta a MinHacienda, la DNP, la Contraloría, la Procuraduría ni la Fiscalía.
• [H] Ninguna alerta produce efectos sancionatorios automáticos. El output abre una revisión ante la autoridad competente; no la cierra. *«Señal de auditoría, no prueba.»*
• [H] El modelo prioriza; el humano decide. Todo hallazgo es refutable, trazable a su fuente y sujeto a debido proceso.

1. Qué es Argos y qué analiza

Argos es una plataforma analítica del Estado colombiano —diseño de referencia inspirado en el modelo Palantir (Foundry+AIP+Apollo) pero acotado a la Constitución— que convierte datos dispersos del Estado en decisiones auditables con consecuencias institucionales. Su módulo central es el Radar de Eficiencia.

Principio rector: el modelo prioriza, el humano decide. La plataforma analiza dinero y gestión pública, no al ciudadano.

Los 6 focos del análisis

• Eficiencia institucional — ¿cuánto cuesta cada entidad frente a lo que entrega?
• Auditoría del gasto — ¿a dónde va el dinero público y cómo se contrata?
• Riesgo contractual — ¿qué patrones disparan revisión (concentración, directa, adiciones)?
• Duplicidad funcional — ¿qué entidades hacen lo mismo sobre la misma población?
• Valor público — ¿la entidad produce resultados que justifiquen su costo?
• Escenarios de reforma — mantener, fusionar, trasladar, liquidar, privatizar… con ahorro, riesgo y ruta normativa.

El Radar: 5 índices 0–100 por entidad

Cada entidad recibe un vector de 5 puntajes (ninguno es un veredicto; cada uno abre revisión):

La prioridad combina alto costo + alta duplicidad + alto riesgo + bajo valor, modulada por la reformabilidad. Ningún puntaje es un veredicto: abre revisión humana.

Las 6 preguntas que responde por entidad

Costo (¿cuánto cuesta realmente?) · Función (¿mandato legal vigente?) · Duplicidad (¿quién hace lo mismo?) · Riesgo (¿hallazgos, investigaciones, captura?) · Resultados (¿qué entrega y a cuántos?) · Escenarios de reforma (mantener…liquidar, con ahorro y ruta).

Los 8 arquetipos de clasificación (FICHA-MODELO)

Del vector de 5 índices —nunca de un juicio único— sale una hipótesis de reforma: Estratégica eficiente → mantener · Estratégica ineficiente → reformar · Riesgosa → auditar · Redundante → fusionar · Obsoleta → liquidar/rediseñar · Patrimonial → evaluar venta/concesión · Sensible → reformar con cautela · No reformable en corto plazo → plan de mediano/largo plazo.

[H] En este dossier el análisis se instancia sobre 18 entidades del sector Hacienda (§2).

2. A quién analiza

[H] El sujeto de análisis es el Estado y su dinero, no el ciudadano: *dinero público → público; dato personal → reservado*. El perímetro de este dossier es el Sector Hacienda y Crédito Público: el ministerio cabeza de sector más sus entidades adscritas y vinculadas, identificadas por NIT (derivadas del organigrama de la rama ejecutiva nacional).

[TODO] Fuera de la trazabilidad de SECOP (operan bajo régimen de derecho privado y no reportan): Central de Inversiones (CISA), FOGAFIN, FOGACOOP — su gasto no es visible por esta vía; se solicita por sus canales.

3. Cómo lo analiza

Arquitectura de datos (híbrida)

datos.gov.co (Socrata API) ──pipeline/*.py──▶ live/*.json ──publish──▶ Vercel Blob
     (registro: store/datasets.json)                                      │
                                                 vercel.json rewrite /live/(.*)
                                                                          ▼
                                          frontend fetch('/live/*.json') (runtime, fresco)

Un cron diario recalcula y escribe a un store; el frontend lee del store al cargar (rápido, sin redeploy). Solo stdlib (urllib): reproducible y auditable. Nada sintético: si una fuente no responde, se marca —no se inventa (CLAUDE.md §5).

Cómo se produce cada cifra

• Agregación server-side (SoQL). Todo sale de $select=sum(valor)/count(...)&$group=... sobre la API abierta, filtrado por el perímetro (nit_entidad IN(...)). Cero estimaciones; misma consulta → misma cifra.
• Normalización de sector y NIT (base de 9 dígitos, tolera dígito de verificación); persona natural por tipodocproveedor (cédula), dato autoritativo de SECOP.
• Valor reportado vs validado. Se separa el crudo de SECOP de un techo de plausibilidad: un contrato individual con valor imposible para el sector se marca *atípico*/*error_probable* y se excluye del validado (pero se reporta cuánto y cuántos).
• Banderas jurídicas derivadas de campos reales: contratación directa, régimen especial, fiducia/patrimonio autónomo, ESAL, comunitario, paz.
• Scoring 0–100 por entidad y por contrato/proceso, con pesos explícitos y auditables (monto, modalidad, etapa, atipicidad, adiciones, falta de link/ID, fiducia, dependencia). Clasificación 🔴 rojo · 🟠 naranja · 🟡 amarillo · 🟢 verde · ⚪ gris.
• Decisión de empalme sobre procesos: *adjudicado=Sí* → derecho adquirido (causal taxativa) → continuar; *adjudicado=No y no cancelado* → sin derecho adquirido → revisar/suspender por conveniencia. Nunca automático.

Cruces que marcan anomalías (señal, no prueba)

Concentración (dependencia de un proveedor) · Fraccionamiento (≥3 mínimas cuantías mismo proveedor/categoría/año) · Sobrecosto-señal (brecha de valor por categoría vs promedio nacional — *no* sobreprecio: falta costo unitario) · Proveedor nuevo (matrícula RUES ≤90 días antes del 1er contrato) · OPS recurrente (persona con múltiples contratos) · Duplicidad (misma categoría UNSPSC en varias entidades).

Saneamiento del dato — un caso real del sector

[H] La plataforma distingue concentración real de artefacto de captura. En Hacienda, un proveedor placeholder (documento_proveedor = 'No Definido') agrupaba contratos de proveedores distintos en un mega-proveedor falso, y varios contratos traían valores billonarios mal capturados. Argos los separa a un bucket «sin proveedor identificado» (dato faltante) y excluye los valores imposibles del validado, en vez de leerlos como gasto real. Esto cambió el titular del sector (§7) y es exactamente lo que un tablero ingenuo reportaría mal.

4. Qué datos usa

[H] Todo traza al registro de datasets (store/datasets.json, corte 2026-06-25): 18 fuentes, cada una con su ID Socrata y entidad productora. La frescura se mide con la última actualización real de la fuente (rowsUpdatedAt), no con la hora de descarga: al corte, 14 fuentes abiertas OK y 5 pendientes (sin API abierta → convenio/ingesta manual).

Núcleo del caso Hacienda: SECOP II (jbjy-vk9h) y SECOP I (x6v4-i8gf) para contratos, Procesos (p6dx-8zbt) para selección en curso, PGN (xjxk-qhsc) para presupuesto, RUES (c82u-588k) y Responsabilidad Fiscal (jr8e-e8tu) para verificación cruzada (§9). El detalle de lectura está en /guia y /fuentes.

5. Cómo usa los datos

• [H] Reproducibilidad. Solo stdlib; agregación server-side determinista; rutas de publicación estables (sin sufijo aleatorio). Comandos de una línea: python3 -m pipeline.run, python3 -m pipeline.hacienda. Cliente Socrata con QPS acotado (3 sin app-token, 10 con) y backoff exponencial compartido.
• [H] No inventar cifras (§5). Cada builder está aislado: si una fuente falla, conserva su último snapshot válido o no se crea; jamás se rellena con un número plausible. El SGP muestra «s/d (fuente SICODIS)» hasta que exista el CSV real.
• [H] Etiquetas de evidencia. Toda afirmación separa [H]/[HIP]/[INF]/[REC]/[RISK]/[TODO]; sin fuente, es [HIP] o [TODO], nunca un hecho.
• [H] Sensibilidad. 🟢 dinero público/gestión (abierto) · 🟡 requiere base legal · 🔴 dato personal sensible (no se cruza sin base legal explícita).
• [H] Regla de normalización de sobrecosto. *Nunca* comparar montos sin normalizar por la unidad; un código UNSPSC común es señal de clasificación, no de precio. Prohíbe el falso «X paga N× más» sin costo unitario.

6. Cómo se piensa a sí misma (gobernanza y autocontención)

La tesis de legitimidad de Argos es explícita: *«La misma caja de herramientas sirve para auditar el gasto y para vigilar opositores. La diferencia no está en la tecnología sino en los límites que se ponen antes de encenderla.»* El riesgo de abuso no es hipotético en Colombia (el escándalo de las «chuzadas» del DAS es el antecedente). Por eso la autocontención se diseña antes, no después.

Los 7 principios

• No-abuso por diseño — los límites se ponen antes de encender la herramienta.
• Trazabilidad de evidencia — toda afirmación se ancla a una fuente con linaje.
• Debido proceso — ninguna alerta produce efectos sancionatorios automáticos.
• Separación de poderes — el control de los logs y remisiones no reside solo en el Ejecutivo.
• Minimización de datos personales — dinero público → público; dato personal → reservado.
• Preferencia por dinero público y gestión estatal — no por datos personales del ciudadano.
• Toda alerta es preliminar — el output abre una revisión, no la cierra.

Gobernanza de 4 niveles + 7 garantías estructurales

Consejo Estratégico · Comité de Control y Legalidad («quien controla los logs no debe ser solo el Ejecutivo») · Unidad Técnica · Mesa Ciudadana y Académica. Garantías: ley estatutaria con finalidad taxativa que prohíba el perfilamiento político; contrapesos; minimización y finalidad (autorización judicial cuando toque intimidad); trazabilidad inmutable auditable por Contraloría/Procuraduría sin pedir permiso al Ejecutivo y no borrable; auditoría externa algorítmica con publicación de falsos positivos; debido proceso; cláusula anti-captura (reglas que sobrevivan al cambio de gobierno).

Las reglas rojas — lo que la plataforma NO hará jamás

❌ Vigilancia política o perfilamiento por afiliación/protesta/ideología · ❌ acceso indiscriminado a datos sensibles sin base legal · ❌ modelos secretos (caja negra): toda alerta debe ser explicable · ❌ decisiones automáticas sancionatorias · ❌ mezclar inteligencia de seguridad con programas sociales · ❌ reemplazar a Fiscalía/Contraloría/Procuraduría/jueces.

Debido proceso (enrutamiento)

Detección → dossier explicable → REVISIÓN HUMANA (la IA prioriza; el humano decide) → enrutamiento a la competencia: Administrativa · Fiscal (Contraloría, art. 267) · Disciplinaria (Procuraduría, art. 277) · Penal (Fiscalía, art. 250). *Una alerta es una alerta de auditoría, no una prueba penal.*

Cómo se analiza a sí misma: equipo de agentes + abogado del diablo

El análisis por entidad corre como un equipo de 6 roles (coordinador; abogado administrativo→Reformabilidad; financiero→Costo; contratación→Riesgo; datos/ontología→Duplicidad; valor público→Valor), y un abogado del diablo que ataca las conclusiones débiles antes de consolidar («no produce hallazgos propios»; su éxito se mide en falsos positivos evitados). La consolidación recibe hallazgos ya impugnados, no crudos.

Doble verificación de datos (ver §9)

(a) Segundo testigo (pipeline/verificacion.py): contrasta una cifra contra una segunda fuente/institución distinta de la que la produjo (PGN↔SECOP, RUES, Contraloría) y emite veredicto explícito. (b) Motor de *drift* (verifica-data): re-deriva las cifras publicadas consultando la fuente hoy y compara (tolerancia 2%); si diverge, marca *drift* (snapshot desfasado o bug), nunca «la fuente está mal».

7. Descubrimientos y alertas — Sector Hacienda

Todo lo de esta sección se deriva del store verificado (§9). Señal de auditoría, no prueba.

Titular: leer el validado, no el reportado

• [RISK] La calidad del dato es el primer hallazgo. El valor reportado por SECOP es $3.58 B en 12.749 contratos, pero $0 (0% del total) se concentra en solo 0 contratos con valor de captura errónea. El validado del sector es $3.58 B; esos 0 registros deben depurarse en SECOP (Colombia Compra Eficiente) antes de leer cualquier total.
• [INF] 16.4% del valor por régimen especial y 40.0% por contratación directa (fuera de licitación abierta) — la mayor palanca de revisión contractual. 76.4% de los contratos (por número) son de prestación de servicios.

Procesos en curso (decisión de empalme)

• [H] 7.085 procesos de selección EN CURSO (no adjudicados, ventana desde 2025-07-01) y 598 adjudicados no suscritos → decisión temprana continuar/revisar/suspender.

Patrones que requieren validación

• [HIP] 1215 personas naturales (cédula) con ≥3 contratos de servicios → posible patrón de dependencia estructural / «posible nómina paralela»; requiere validación funcional y jurídica (no es, por sí solo, nómina paralela).
• [INF] 242 categorías de gasto (UNSPSC) aparecen en ≥2 entidades → posible duplicidad / racionalización (compras conjuntas, acuerdos marco).
• [HIP] 419 contratos con adiciones > 50% de la cuantía inicial → posible sobrecosto o elusión de la selección; validar expediente.

Concentración y dato faltante

• [INF] Mayor proveedor identificado: UT Nueva Logística ($211.981 M, 1 entidad(es)) → mapear red contractual.
• [TODO] $200.953 M en 50 contratos sin proveedor identificado en SECOP (placeholder) → dato faltante, no concentración; requiere validación documental.

Ranking de riesgo por entidad

[INF] Score preliminar 0–100 (concentración de proveedor real, participación de valor, ejecución). 3 entidades en rojo, 1 en naranja. El score del ranking coincide con la ficha de cada entidad (misma fuente autoritativa).

Contratos de mayor riesgo preliminar

[INF] Priorizados por score (monto, modalidad, etapa, atipicidad, adiciones). Los de mayor score del sector están marcados error_probable (valor imposible → validar el dato primero):

8. Datos faltantes y límites del caso

• [TODO] Central de Inversiones (CISA) — Sin registros en SECOP II (opera bajo régimen de derecho privado, Ley 80 art. 14/exceptuado). [TODO] pedir contratación por sus canales.
• [TODO] FOGAFIN — Sin registros en SECOP II (opera bajo régimen de derecho privado, Ley 80 art. 14/exceptuado). [TODO] pedir contratación por sus canales.
• [TODO] FOGACOOP — Sin registros en SECOP II (opera bajo régimen de derecho privado, Ley 80 art. 14/exceptuado). [TODO] pedir contratación por sus canales.
• [TODO] SIIF Nación, PAA, BPIN/SUIFP/SPI, RUES/RUP, SIGEP, Contraloría/SIA Observa, Procuraduría/SIRI, ANDJE/eKogui — no están en esta corrida; limitan separar funcionamiento/inversión, el cruce plan-ejecución y el enriquecimiento de proveedores/litigios.
• [H] SECOP I congelado (~2022): las obligaciones heredadas se ven, pero «en curso» solo aplica a SECOP II.
• [RISK] Registros con valor mal capturado inflan totales; requieren saneamiento antes de cualquier lectura fiscal (§7).

9. Verificación de este dossier

(a) Segundo testigo — re-derivación en vivo (motor de *drift*)

[H] Las cifras del sector se re-derivan consultando la fuente en vivo y se comparan con lo publicado (tolerancia 2%). Estado al 2026-07-01: drift · modo vivo · 14 entidades · 28 cifras re-derivadas · 4 drift · 0 hallazgo(s) crítico(s). Fuente: datos.gov.co · SECOP II jbjy-vk9h.

Sellos de generación: hacienda.json 2026-07-01T19:26:55 · hacienda_entidades.json 2026-07-01T19:17:41.

(b) Segundo testigo — contraste cross-source

[H] Cada cifra se contrasta contra una segunda fuente/institución distinta de la que la produjo (no es re-ejecutar nuestra propia consulta): señal reforzada o desmentida por un tercero, nunca prueba. *«Sin segundo dato» ≠ exoneración.*

[H] Sector Hacienda en el contraste PGN↔SECOP (misma vigencia, dos instituciones): PGN comprometido $10.98 B vs SECOP contratado (vigencia) $260.363 M → concuerda. El comprometido del PGN incluye rubros no contratables (nómina, transferencias, deuda), por eso contratado ≤ comprometido es lo normal.

Vocabulario de veredictos: concuerda 🟢 (las fuentes cohieren) · discrepa 🔴 (no cohieren → bandera) · sin_par ⚪ (la segunda fuente no cubre el caso) · lead 🟡 (coincidencia en fuente parcial → indicio, requiere consulta autoritativa).

10. Cómo se replica para todas las entidades

[H] Este dossier es generado, no escrito a mano: python3 analyses/hacienda/build_dossier.py lee el store y arma el documento. La misma estructura (secciones 0–6 y 10, método y gobernanza) es constante; cambia solo la sección 7 (descubrimientos), que se deriva del perímetro elegido.

• Hoy: sector Hacienda (18 entidades), con su ranking y fichas por entidad en /hacienda/<slug>/.
• Siguiente: una versión por entidad o por sector cambiando el alcance del generador (perímetro por NIT). El motor pipeline/hacienda.py, la verificación (segundo testigo + drift) y las reglas de gobernanza no cambian — solo el conjunto de NITs analizado.
• Garantía: cada versión trae su propio badge de verificación; si una cifra no re-deriva contra la fuente (drift > 2%%), el badge lo marca y no se publica como verificada.

11. Anexos

Glosario de etiquetas y estados

• Evidencia: [H] hecho · [HIP] hipótesis · [INF] inferencia · [REC] recomendación · [RISK] riesgo · [TODO] dato faltante.
• Riesgo (color): 🔴 revisión inmediata · 🟠 prioritaria · 🟡 seguimiento · 🟢 sin alerta inicial · ⚪ información insuficiente.
• Estado del dato: validado · atípico · error_probable · pendiente.
• Verificación: concuerda · discrepa · sin_par · lead (cross-source) · verificado/drift/solo_offline/hallazgos (drift engine).

Comandos reproducibles

python3 -m pipeline.hacienda           # regenera el sector + fichas por entidad
python3 -m pipeline.verificacion       # segundo testigo cross-source
python3 .claude/skills/verifica-data/verifica_hacienda.py --md   # re-derivación + badge
python3 analyses/hacienda/build_report.py     # informe de empalme + matrices CSV
python3 analyses/hacienda/build_dossier.py    # este dossier (.md + .html)

Registro de fuentes (18 datasets, ver §4)

Trazabilidad: cada cifra del repo traza a uno de estos datasets públicos de datos.gov.co.

Enlaces

• Tablero del sector: /hacienda · fichas por entidad: /hacienda/<slug>/
• Cómo leer los datos: /guia · Fuentes y método: /fuentes · Acerca: /acerca
• Tableros: /organigrama · /territorial · /matriz · /mapa

*Generado por analyses/hacienda/build_dossier.py desde el store verificado de Argos (datos.gov.co). Señal de auditoría, no prueba. El modelo prioriza; el humano decide.*

Para PDF: abre este archivo y usa Imprimir → Guardar como PDF.