No encontramos 22.177 casos: descartamos 22.092 — el valor de un sistema de auditoría está en lo que se niega a afirmar

28 de octubre de 2026. Día 3 de 10. A la 01:40 de la madrugada corrí el detector sobre el país entero: cinco años de compras públicas, 4.950.443 órdenes de compra, 103.220 proveedores, 1.400 organismos. Tardó 91 segundos y pico 3,3 GB de memoria. Al final, el archivo de salida tenía 22.177 patrones sospechosos.

Me quedé mirando el número. Veintidós mil ciento setenta y siete. Si el producto fuera «detectar corrupción», ese número era el éxito: un país entero radiografiado, veintidós mil cosas raras encontradas, material para un titular. Lo que hice a continuación fue lo contrario de lo que haría cualquiera que está construyendo para un hackatón con un millón de dólares en juego.

Empecé a borrar.

No porque no creyera en los datos. Porque cada uno de esos 22.177 patrones le iba a costar tiempo a un auditor que no existe. Un sistema que produce veintidós mil alertas no produce veintidós mil hallazgos: produce cero. Produce la decisión, silenciosa y perfectamente racional, de que nadie va a revisar ninguna.

Al final de la noche, después de tres calibraciones que nos corrigieron a nosotros, quedaron 85 señales. Ochenta y cinco. El 0,38% de lo que el detector fue capaz de encontrar.

Este artículo es sobre las 22.092 que borramos.

Una advertencia antes de entrar, porque es la regla de esta casa: 85 no son 85 casos de corrupción. Son 85 señales que cumplen umbrales declarados, con la aritmética a la vista, y que un auditor humano puede abrir una por una. Una señal no es una acusación. Este artículo no denuncia a nadie: describe el método que nos obligó a no denunciar a casi nadie.

Y una segunda advertencia, de forma: los nombres propios están fuera a propósito. El artículo es sobre el método, no sobre el expediente. Cuando el sistema pueda sostener una afirmación con evidencia verificable —documento, página, línea, monto— ese caso se publica completo. Mientras tanto, lo que se publica es la decisión de no publicarlo. Eso también es un resultado.

1. Cuatro millones novecientas cincuenta mil órdenes y 22.177 sospechas

Empecemos por el tamaño de la cancha, porque sin eso el número de descartes no se entiende. El sistema que construimos en estos diez días no es un buscador de noticias: es un grafo de compras públicas chilenas de cinco años, armado desde 43 archivos de datos abiertos que suman 2,0 GB comprimidos.

Etapa	Medición
Descarga	43 archivos .7z · 2,0 GB · ~2 min (7,5 MB/s)
Agregación	601 s → 13.368.668 filas → 4.950.443 órdenes de compra
Exportación a grafo	285 s → 64.792.071 tripletas · 8,57 GB → 428 MB (compresión 19,1×)
Importación	144 s → 3,1 GB de base
Grafo en producción	64.792.053 tripletas · 4.950.440 OC · 103.220 proveedores · 1.400 organismos
Consulta del total 5 años	CLP 45.906.337.852.807 (≈ US$ 48 mil millones) en menos de 1 segundo
Detectores a escala	91 s · pico 3,3 GB
Patrones detectados	22.177

Cuarenta y cinco billones de pesos. Ese es el universo. Ahora la pregunta que define el producto: ¿qué significa «detectar» sobre 4,95 millones de órdenes?

Significa preguntar, por ejemplo, si un mismo proveedor recibió muchas órdenes del mismo organismo en un periodo corto. Si esas órdenes quedaron todas justo por debajo del monto que obliga a licitar. Si los montos son idénticos una y otra vez. Si un proveedor concentra una categoría completa de compra en una región.

Cada una de esas preguntas es una regla. Y cada regla, aplicada a 4,95 millones de registros, devuelve casos. Muchos. Porque el país real es más raro que el país que uno imagina: hay organismos que compran el mismo insumo todos los días, hay programas que emiten una orden por paciente, hay convenios marco que no requieren licitación y por eso no tienen por qué licitar.

La primera versión del detector no distinguía nada de eso. Y ahí empezó la primera derrota.

2. Calibración #1: el mecanismo equivocado

El detector de fraccionamiento tenía una lógica razonable, incluso obvia: si un proveedor recibe muchas órdenes del mismo organismo en un mes, algo raro pasa. Es la definición de manual: partir una compra grande en pedazos chicos para no tener que licitarla.

Aplicado al país, el ranking se ordenó solo. En la cima apareció un par de entidades con 369 órdenes de compra por mes. Trescientas sesenta y nueve. Al mes. Eso son más de doce órdenes por día hábil, del mismo proveedor al mismo comprador, durante cinco años.

Era el hallazgo estrella. Doce veces más que el segundo lugar. Y era falso.

Ahí está la primera lección, y es más profunda de lo que parece: el detector no medía fraccionamiento. Medía frecuencia. Y la frecuencia, por sí sola, no dice nada. Un organismo que compra pasajes todos los días tiene una frecuencia altísima y cero fraccionamiento. Un hospital que emite una orden por paciente tiene una frecuencia altísima y cero fraccionamiento. Un proveedor de insumos que abastece a cuarenta organismos tiene una frecuencia altísima y cero fraccionamiento.

La regla de negocio que salió de esto es una sola frase: solo cuenta el Trato Directo. Es el mecanismo donde el fraccionamiento es aritméticamente posible, porque es el que tiene un umbral que se puede esquivar. Todo lo que se compra por Convenio Marco, por compra ágil o por licitación pública queda fuera del detector, no porque sea limpio, sino porque la pregunta no aplica.

Una regla menos. Un universo más chico. Y una advertencia que se repetiría tres veces: cada señal que emitimos tenía un mecanismo equivocado detrás, y solo abriendo el caso uno por uno nos dimos cuenta.

Esto, en un dashboard, no se ve. En un dashboard solo se ve que bajó el número de alertas, y bajar el número de alertas se lee como un retroceso. Es exactamente al revés: acabábamos de eliminar una clase entera de falsos positivos, y el sistema se volvió más útil perdiendo miles de resultados.

3. Calibración #2: la materialidad

Con el mecanismo corregido quedaba un segundo problema, y era de sentido común. El detector seguía marcando como fraccionamiento a cualquier proveedor que hubiera recibido tres o más órdenes directas en un periodo. Tres órdenes.

Tres órdenes de cuarenta mil pesos cada una son ciento veinte mil pesos. En un hospital, eso es una compra de insumos de una tarde. En una municipalidad, es papelería. Marcarlo como «fraccionamiento» no es técnicamente falso —hubo tres órdenes directas— pero es humanamente inútil: nadie va a abrir un expediente por ciento veinte mil pesos, y quien lo abriera estaría perdiendo el tiempo que no dedicó a los casos grandes.

La corrección fue agregar una condición de materialidad: el conjunto de órdenes tenía que superar al menos tres veces el umbral de Trato Directo para siquiera entrar a la lista. No basta con que la suma de las partes sea mayor que el umbral: tiene que serlo de forma que valga la pena mirar.

Esta segunda calibración tiene un costo que hay que decir en voz alta, porque es el corazón del artículo: al agregar materialidad, dejamos de detectar fraccionamientos pequeños. Fraccionamientos reales, incluso. Un proveedor que se lleva diez compras de 300 mil pesos cuando debía licitar por 3 millones está cometiendo exactamente el mismo acto que el que se lleva diez de 30 millones. Nuestro sistema ya no lo va a señalar.

Eso es una pérdida. No un trade-off elegante: una pérdida. Y la asumimos porque un sistema que señala todo no señala nada, y porque tenemos una capacidad de revisión humana limitada que preferimos gastar en los casos donde el monto justifica la hora de un auditor.

Cuando un vendor te diga que su sistema «detecta todos los casos», la pregunta correcta no es cuántos detecta. Es cuántos descarta y con qué criterio declarado. Si no puede responder eso, no tiene un sistema: tiene un generador de colas.

4. Calibración #3: la forma del grupo

La tercera calibración es la que nos hizo reescribir el detector entero, y es la mejor historia del proyecto porque el caso que nos emocionó resultó ser el que nos enseñó que estábamos equivocados.

Con las dos correcciones anteriores, el ranking de fraccionamiento tenía un outlier: un proveedor en una región del sur, con 59 veces el patrón esperado. Cinco nueve. El equipo lo celebró. Era el caso que íbamos a mostrar en el pitch: montos bajo el umbral, mismo comprador, mismo proveedor, patrón sostenido en el tiempo. Todo lo que un auditor quiere ver.

Entonces abrimos las órdenes una por una. Y nos encontramos con esto:

No era fraccionamiento. Era la forma del grupo la que se parecía a fraccionamiento. Y ahí entendimos que estábamos midiendo una silueta, no un acto: dos fenómenos completamente distintos —partir una compra para evadir un umbral, y ejecutar un programa con una orden por beneficiario— producen exactamente la misma firma estadística si solo miras montos y frecuencias.

La corrección fue dejar de asumir una sola forma y clasificar el patrón declarando la ambigüedad:

pattern_kind	Definición operativa	Qué se afirma	Casos
mismo_objeto	Similitud de descripciones ≥ 0,8: el mismo objeto, una y otra vez	Hay un patrón de compra repetida del mismo bien. Verificable por descripción.	1.087
por_caso	Montos idénticos en ≥ 50% de las órdenes y similitud < 0,8	Hay una ejecución por caso o beneficiario. No se afirma fraccionamiento.	148
indeterminado	No alcanza el criterio para ninguna de las dos	Nada. Se declara la ambigüedad, no se adivina.	1.208

Suma: 2.443 patrones materiales. Y fíjate en la tercera fila, porque es la decisión de diseño más importante de todo el sistema: 1.208 casos quedaron en «indeterminado». Casi la mitad. No los forzamos a una categoría, no los escondimos, no los borramos. Se declaran como lo que son: casos donde la evidencia no alcanza para afirmar nada y donde un humano tiene que mirar.

Eso es lo opuesto a lo que hace un clasificador optimizado para precisión aparente. Un clasificador te va a decir, con 94% de confianza, que ese patrón es fraccionamiento, porque tiene que devolver una etiqueta. Nosotros preferimos devolver tres etiquetas, una de las cuales es «no sé», y que el auditor sepa exactamente dónde está parado.

5. La aritmética del descarte: de 2.443 a 85

Ahora la parte que nadie pone en un slide. Tenemos 2.443 patrones materiales, clasificados, con la aritmética a la vista. ¿Cuántos se convierten en señales dentro del grafo?

85. Sesenta de fraccionamiento y veinticinco de concentración, materializadas como 1.756 aristas en el grafo, consultables por API, cada una con sus órdenes y sus montos.

La pregunta obvia: ¿por qué 85 y no 2.443? Y la respuesta no es una sola: son cuatro filtros distintos, cada uno con su propia justificación.

Filtro	Qué elimina	Por qué
Mecanismo	Todo lo que no es Trato Directo	Sin umbral que esquivar, no hay fraccionamiento posible
Materialidad	Conjuntos bajo 3× el umbral	No justifican la hora de un auditor
Forma	Patrones por_caso e indeterminado	No se puede afirmar fraccionamiento sin abrir la evidencia
Verificación	Los que no resistieron revisión registro por registro	Si no se sostiene, no se publica

De los que sí pasaron todo, uno merece contarse, porque es el que define qué significa «sostener» una señal. Un hospital regional del sur, un proveedor de insumos médicos, diciembre de 2021. 73 órdenes del mismo insumo, cada una por una receta distinta, todas por debajo del umbral de Trato Directo. Suma: CLP 54.582.378, que es 54,6 veces el umbral.

Ese caso lo validamos registro por registro: 73 órdenes, 73 recetas, 73 fechas, cero excepciones. Lo que el expediente afirma es la aritmética y la trazabilidad: este conjunto de órdenes existe, estos son sus montos, esta es su suma, y esa suma supera 54,6 veces el umbral que obligaba a licitar. Lo que no afirma es el dolo. No dice que alguien haya querido evadir nada. Dice que hay 73 registros que, juntos, configuran un hecho que un auditor puede verificar en una tarde.

Esa distinción —entre afirmar el hecho y afirmar la intención— es todo el producto. Y es la razón por la que el número bajó de 22.177 a 85: cada afirmación que sobrevive tiene que poder ser defendida por alguien que no la escribió.

6. El costo invisible del falso positivo

Vale la pena detenerse en la economía de esto, porque es donde la mayoría de los sistemas de detección se equivocan de modelo de negocio.

Un falso positivo no es un error neutro. Es una transferencia de costo: el sistema se ahorra el trabajo de decidir y se lo pasa al humano. Y como el humano tiene una capacidad fija de atención, cada falso positivo desplaza a un caso real. No es que el error «no ayude»: es que resta.

Hagamos la cuenta con los números de esta noche. Si un auditor puede revisar veinte señales por semana, un sistema que entrega 22.177 patrones le da trabajo para veintiún años. Un sistema que entrega 85 le da trabajo para un mes, con la posibilidad real de terminarlo.

Salida del sistema	Cola de revisión	Qué pasa en la práctica
22.177 patrones	≈ 21 años de revisión	Nadie empieza. La herramienta se abandona en la segunda semana.
2.443 materiales	≈ 2,3 años	Se revisan los primeros veinte y se decide que el resto «debe ser ruido».
85 señales	≈ 4 semanas	Se termina. Y al terminarse, se puede firmar.

La tercera fila es la única que produce un artefacto terminado. Y un artefacto terminado es la única cosa que sirve en un contexto donde alguien tiene que responder por lo que afirma: un auditor, un contralor, un periodista, un comité.

Hay una segunda economía, más incómoda: el falso positivo destruye la confianza más rápido de lo que el verdadero positivo la construye. Si un auditor abre tres alertas y las tres son pasajes por Convenio Marco, no concluye «el sistema tiene ruido»: concluye «el sistema no entiende el negocio». Y a partir de ahí, ninguna de las ochenta y dos restantes se va a mirar con atención. La asimetría es brutal: se necesitan decenas de aciertos para recuperar la credibilidad que se pierde con tres errores tontos.

Por eso el descarte no es una etapa de limpieza posterior al producto. El descarte ES el producto. El detector es la parte commodity —aplicar reglas a 4,95 millones de filas lo hace cualquiera con SQL y una tarde—. Lo que no es commodity es la capa que decide qué no decir, con criterios declarados y auditables.

7. El falso negativo: lo que borramos y no volvemos a ver

Todo lo anterior tiene un problema de honestidad que hay que resolver, y es el más incómodo del artículo: hablamos de los falsos positivos porque los vemos. Los abrimos, los leemos, nos damos cuenta de que eran pasajes. El falso negativo, en cambio, no se ve nunca. Es el caso real que descartamos y que a partir de esa noche no existe para nadie.

Y no tenemos forma de saber cuántos son. Ese es el punto.

Para medir cuántos casos verdaderos botamos haría falta algo que no existe: la lista completa de los fraccionamientos reales del Estado chileno en cinco años. Nadie la tiene. Ni nosotros, ni el Estado, ni Contraloría. Si existiera, el problema estaría resuelto y no habría producto. Un sistema de detección se mueve, por definición, en un terreno donde la verdad de referencia es parcial o inexistente.

Lo que sí podemos hacer es acotar el daño con lo que hay. Tres ejercicios, todos imperfectos, todos declarados:

Ejercicio	Qué mide	Qué no puede medir
Muestreo de descartes	Tomar 50 patrones eliminados al azar y revisarlos a mano	Los descartes que caen fuera del muestreo, y si el azar fue representativo
Contraste con Contraloría	Si algún informe publicado coincide con un patrón que descartamos	Todo lo que Contraloría no audita —que es la mayor parte del universo
Sensibilidad al umbral	Cuántas señales aparecen o desaparecen al mover el umbral de materialidad	Si el umbral correcto existe. No existe: hay una decisión, no una verdad

El tercero es el más útil y el más incómodo. Si al bajar el umbral de 3× a 1× el número de señales se multiplica por diez, sabemos que estamos parados en una zona de alta sensibilidad, es decir, que la decisión de umbral está eligiendo el resultado. Y eso hay que decirlo en voz alta: el umbral no es una medida, es una política. Alguien decidió que tres veces era suficiente. Ese alguien debería poder ser cuestionado.

Por eso el sistema declara sus umbrales en vez de esconderlos. Un vendor que te entrega un score sin mostrarte los cortes está escondiendo una decisión política detrás de un número técnico. Nosotros preferimos lo contrario: aquí está el corte, aquí está lo que entra, aquí está lo que queda afuera, y aquí está el botón para moverlo y ver qué pasa.

Hay un nombre técnico para esto, precision-recall trade-off, y está en cualquier manual. Lo que no está en el manual es la parte que importa: ese trade-off no lo resuelve el algoritmo, lo resuelve el contexto de uso. En un motor de búsqueda, el recall manda: si no aparece, el usuario no lo encuentra y se va. En un expediente que alguien va a firmar, la precisión manda: si aparece algo que no se sostiene, se cae todo el documento y con él la credibilidad de quien lo firmó.

Nosotros estamos construyendo lo segundo. Y por eso el número bajó.

8. Por qué compras públicas y no otra cosa

Alguien podría preguntar, con razón, por qué este proyecto se metió en compras públicas y no en un vertical más cómodo. La respuesta no es ideológica: es estructural, y define qué clase de problemas se pueden resolver en diez días y cuáles no.

Hay cuatro propiedades que hacen de las compras públicas un terreno donde un sistema de evidencia se puede construir rápido y sostener después.

Uno: los datos existen el día uno. No hay que pedir permiso a nadie, ni firmar un convenio, ni esperar una API que prometieron para el próximo trimestre. Son 43 archivos públicos de 2,0 GB. Eso significa que el día 1 del proyecto se puede trabajar sobre el universo completo y no sobre una muestra de cortesía. Cualquier vertical donde los datos están cerrados obliga a construir primero la puerta y después la casa.

Dos: hay una regla objetiva contra la cual medir. El umbral de Trato Directo es una cifra publicada. No es una opinión, no es un estándar interpretable: es un número. Eso convierte la aritmética en verificable. Estas 73 órdenes suman 54,6 veces el umbral es una afirmación que se puede comprobar con una calculadora, sin discutir criterios. La mayoría de los dominios no tienen eso: tienen «riesgo», «anomalía», «comportamiento sospechoso», categorías donde dos expertos razonables discrepan y por lo tanto ninguna afirmación se puede cerrar.

Tres: el daño es agregado y no individual. Un caso de fraccionamiento no destruye una vida: desvía dinero público. Eso permite construir un sistema que señala conjuntos de registros sin señalar personas, con un margen de error que se puede declarar sin arruinar a nadie en el proceso. La trazabilidad reemplaza a la acusación.

Cuatro: existe una verdad de referencia parcial. Contraloría publica informes. No cubren todo, pero cubren algo, y ese algo sirve para calibrar. Un dominio sin ninguna verdad de referencia externa no permite saber si el sistema funciona: solo permite creerlo.

Propiedad	Compras públicas	Ejemplo de vertical que no la tiene
Datos abiertos desde el día 1	✅ 43 archivos · 2,0 GB · 4,95 M OC	Evaluación de desempeño laboral: datos privados de la empresa
Regla objetiva verificable	✅ Umbral de Trato Directo (cifra publicada)	«Cultura organizacional»: sin métrica compartida
Daño agregado, no individual	✅ Se señala un conjunto de registros, no a una persona	Diagnóstico médico: el error tiene un paciente con nombre
Verdad de referencia parcial	✅ Informes de Contraloría	Predicción de demanda: no hay contrafactual observable

Ninguna de estas cuatro propiedades es un mérito nuestro. Son una ventaja del terreno. Y esa distinción importa mucho para cualquiera que esté pensando en construir algo parecido: el error más común no es elegir mal el modelo, es elegir un vertical donde la afirmación final no se puede cerrar. Ahí el sistema puede ser técnicamente impecable y no servir para nada, porque nunca va a poder entregar el único artefacto que importa: algo que alguien pueda firmar.

Construir en compras públicas es, en ese sentido, hacer trampa a favor de la verificabilidad. Y lo haríamos otra vez.

9. La infraestructura que hace posible decir «no»

Hay un detalle de ingeniería que parece irrelevante para esta discusión y no lo es: para poder descartar hay que poder verificar rápido. Si comprobar un caso cuesta veinte segundos, descartar 22.092 es imposible y el equipo termina aceptando lo que vino. La velocidad de la verificación es lo que hace viable la honestidad.

Tres decisiones de diseño sostienen eso.

Primera: el grafo en vez del archivo. Navegar 64,79 millones de tripletas en menos de un segundo es la diferencia entre «puedo abrir este caso ahora» y «lo reviso mañana». La consulta del total de cinco años —45,9 billones de pesos— tarda menos de un segundo. Esa latencia no es una métrica de vanidad: es la condición material del descarte.

Segunda: lecturas imposibles de romper. La API pública es read-only por construcción: no existe un camino de escritura en el código. El motor SPARQL —el único que puede modificar— vive en loopback, sin exposición. Ocho endpoints (/health, /stats, /search, /neighbours, /paths, /citation, /signals, /signals/{id}) con TLS y respuestas entre 0,78 y 0,87 segundos, después de un warm-up que bajó /stats de 45 segundos a menos de uno.

Tercera: un comportamiento, dos transportes. Los handlers de la API son importados del servidor MCP. No hay dos implementaciones que se puedan desincronizar: hay una sola lógica expuesta por HTTP y por MCP. Si el agente y el auditor consultan distinto, uno de los dos está mintiendo.

Y una cuarta, que no es de diseño sino de disciplina: 137 tests en local, 144 con el motor real conectado. Los nueve bugs que encontramos en el camino no fueron errores de lógica: fueron errores de silencio. Dos namespaces distintos entre el escritor y el exportador devolvían cero aristas sin lanzar una excepción: el grafo se veía perfectamente sano y era completamente inavegable. Un OPTIONAL de más convertía una consulta de 1,1 segundos en 61.

10. Lo que no medimos (y por qué lo decimos)

Esta sección existe porque el artículo sería publicidad si no existiera. Hay tres cosas que este sistema no puede hacer hoy, y ninguna es un detalle menor.

Lo que no se midió	Por qué	Consecuencia
Modificaciones posteriores de las órdenes	El conjunto de datos público no trae fecha de última modificación ni de cancelación	No podemos detectar el patrón clásico de «adjudico y después ajusto el monto»
Colicotización (proveedores que se turnan)	Requiere el detalle de quiénes cotizaron, que no viene en el bulk de Compra Ágil	El patrón de reparto de mercado queda fuera del alcance actual
Veinticuatro siglas de la primera tabla de organismos	No resolvían contra ninguna entidad del grafo	Se borraron en vez de inventar un mapeo plausible

La tercera fila es la que más dice sobre el método. Teníamos una tabla de siglas —nombres de organismos abreviados como aparecen en los datos— y veinticuatro no resolvían a ninguna entidad del grafo. La tentación obvia era asignarlas por parecido: esta sigla se parece a este organismo, la mapeo. Eso habría subido el conteo de casos. Y habría metido un error silencioso en la base, del tipo que nadie detecta hasta que un auditor abre el expediente y descubre que el organismo citado no existe.

Las borramos. Perdimos cobertura. Ganamos algo que no se puede recuperar después: la posibilidad de que cada línea del expediente apunte a algo real.

Y hay una cuarta cosa que no medimos, más grande que las tres: no medimos si los 85 casos son corrupción. No tenemos la capacidad, ni el mandato, ni la evidencia. Medimos una cosa mucho más humilde y mucho más verificable: que existe un conjunto de registros públicos cuya aritmética no cierra con las reglas que el propio Estado se puso. Qué significa eso, lo decide un humano con acceso a los papeles.

11. Qué significa «85» para los siete días que quedan

Faltan siete días para el cierre. Y con este número en la mano, la estrategia del proyecto cambió por completo, porque cambió la frase que lo define.

La versión débil, la que iba a decir el pitch el domingo, era: «detectamos 22.177 patrones sospechosos en las compras públicas de Chile». Suena impresionante y es una promesa que no se puede cumplir: cualquiera que abra el sistema va a encontrar un pasaje aéreo marcado como fraccionamiento y va a cerrar la pestaña.

La versión que sí se sostiene es la inversa, y es la frase con la que vamos a abrir:

Esa frase no se puede copiar en una semana, y no porque sea difícil de escribir. Se puede copiar porque el trabajo que la respalda —tres calibraciones, cuatro filtros, 1.208 casos declarados como indeterminados, veinticuatro siglas borradas, nueve bugs de silencio convertidos en tests— no se puede fabricar en un demo. Es la única clase de foso que sobrevive a que alguien vea tu repositorio: no el código, sino los criterios.

Hay una ironía que vale la pena nombrar, porque conecta este artículo con el de ayer. La industria entera está construyendo agentes que producen cada vez más: más texto, más análisis, más reportes, más hallazgos. Y el cuello de botella se está moviendo, silenciosamente, hacia el otro lado: la capacidad de producir afirmaciones creció mil veces; la capacidad de verificarlas creció cero. Ahí es donde va a estar el valor de los próximos años, y no es un lugar glamoroso. Es el lugar donde alguien tiene que decir «esto no lo sé» y firmarlo.

Durante los próximos siete días vamos a seguir abriendo casos, uno por uno, y probablemente el número baje otra vez. Si baja a setenta, no vamos a esconderlo: vamos a publicar por qué. Un sistema que solo mejora sus números hacia arriba no está midiendo nada.

Nota metodológica: todas las cifras de este artículo son mediciones propias sobre datos abiertos de compras públicas chilenas, reproducibles con el pipeline descrito. Los montos están en pesos chilenos nominales, sin ajuste por inflación. Los nombres de organismos y proveedores se omiten deliberadamente; los casos se publicarán con evidencia completa cuando la cadena de evidencia —documento, página, línea— esté cerrada. Este artículo no constituye una acusación ni una imputación legal contra ninguna entidad.