# Un hallazgo no es un veredicto

> La IA puede generar hoy miles de hallazgos de vulnerabilidad en una tarde. Un hallazgo es un testigo, no un veredicto — y el único campo que nadie puede comprobar es el que todos inflan. Así se lee la avalancha sin ahogarse en ella.

Source: https://counterproof.io/es/notes/un-hallazgo-no-es-un-veredicto/ · Published 25 August 2026 · CounterProof es una práctica de Clavestra Capital Limited (Malta, C 113987).


En unas 108 horas de tiempo de máquina, en agosto de 2026, una sola campaña de voluntarios hizo
pasar un modelo de pesos abiertos por 501 proyectos open source del ecosistema Bitcoin y registró
**7 958 hallazgos de seguridad potenciales, 1 280 de ellos clasificados altos o críticos**.
Contamos esa campaña — y el reglamento con el que colisiona — en
[*Las máquinas están leyendo el código*](https://counterproof.io/es/notes/las-maquinas-estan-leyendo-el-codigo/). Esta
nota trata de la cifra en sí.

Porque un proveedor de seguridad ha publicado un banco de pruebas que enfrenta tres sistemas de
revisión de código por IA a una aplicación de prueba privada: uno encontró 68 de las 89
vulnerabilidades implantadas, otro 60, un tercero 58. Los proveedores compiten ahora en ese
ratio — más hallazgos, a menor coste. Encontrar se ha vuelto una mercancía en una guerra de
precios.

Merece la pena, pues, decir con claridad qué es realmente un hallazgo — porque el recuento mide
lo que no es.

## Un hallazgo es un testigo, no un veredicto

La filología resolvió esto hace cinco siglos, y su palabra es exacta.

Cuando un texto antiguo sobrevive en muchos manuscritos copiados a mano, ninguna copia *es* el
texto. Cada una es un **testigo**: un documento derivado que porta el original — más los
deslices, los hábitos y la deriva heredada de su copista. Que tres manuscritos coincidan puede
significar que la lectura es genuina — o que los tres descienden del mismo ejemplar defectuoso.
La disciplina que desenreda esto produce una **edición crítica**: el texto tal como mejor puede
establecerse, con un aparato debajo que registra cada testigo sopesado, cada variante, cada
juicio editorial y sus razones.

Un hallazgo de vulnerabilidad generado por IA es un testigo exactamente en ese sentido. No es el
defecto. Es el *informe* de un modelo sobre un defecto — las propiedades reales del código,
mezcladas con los hábitos del modelo, su linaje de entrenamiento y el prompt que lo produjo. Que
dos escáneres coincidan puede significar que el fallo es real — o que ambos comparten los mismos
puntos ciegos y las mismas plantillas. Entrenados sobre un corpus público en gran parte común, a
menudo es el caso. La coincidencia de testigos correlacionados es evidencia sobre los testigos,
no sobre el código.

Y la regla más duramente ganada de los filólogos se transfiere intacta: la lectura *fluida* es
la sospechosa. Los copistas alisan un pasaje difícil hasta el cliché cómodo, y la versión lisa
es más a menudo la mejora del copista que las palabras del autor. Un informe de vulnerabilidad
tiene un género fijo: título, clase de debilidad, gravedad, una cita, un párrafo de «un atacante
podría…». Un modelo de lenguaje produce esa forma de manera convincente — **exista el defecto o
no**. El pulido no lleva información sobre la verdad. En este género, la fluidez no es una
credencial. Es lo que hay que comprobar.

Por eso el recuento es la unidad equivocada. Cuenta testigos y los declara veredictos.

## La gravedad es donde los informes exageran

La inflación no es uniforme. Se concentra en un punto, por una razón estructural que merece
nombre.

*«Esta función compara una marca de tiempo en milisegundos con una columna de precisión de
segundos»* es una afirmación que cita algo — un fichero, una línea, un commit. Puede abrirse y
resolverse en un minuto. **«Crítico»** no cita nada. No hay ninguna línea de código que diga
*Crítico*. La gravedad es un juicio sobre alcanzabilidad, aprovechabilidad y radio de impacto —
y como no tiene anclaje en el código fuente, es exactamente donde un generador fluido deriva
hacia arriba sin contrapeso. La lectura dramática es la más fácil; cada incentivo de la cadena
de reporte premia la cifra mayor; y nada en el artefacto se resiste.

Así que cuando una campaña informa de 1 280 hallazgos «altos o críticos», la lectura honesta es:
1 280 hallazgos que un generador *etiquetó* así. La etiqueta es el campo menos comprobable del
documento — y es el que carga con el titular.

## ¿Son aprovechables? Nadie lo ha dicho todavía

Entre un hallazgo y un defecto hay un paso que el recuento se salta: la **valoración** — decidir
qué hallazgos son reales, cuáles son alcanzables, cuáles importan. Ese paso sigue siendo humano,
y no escala con la generación.

La medición pública más clara de lo que ocurre cuando se salta viene de curl. Su equipo
voluntario de seguridad, de siete personas, vio caer la proporción de informes de vulnerabilidad
*confirmados* de más del 15 % a menos del 5 % con la llegada de los envíos asistidos por IA —
cada informe infundado seguía costando horas de refutación. Uno llegó completo, con sesiones de
GDB y volcados de registros, para un exploit de HTTP/3 en una función que no existe en curl. Su
mantenedor describió la carga de triaje como equivalente a un DDoS («tantamount to a DDoS»), y
el proyecto acabó cerrando su programa de recompensas — declarando no haber visto un solo
informe de seguridad válido producido con ayuda de IA.

Lea esa cifra en el sentido correcto. No prueba que los hallazgos de IA no valgan nada — prueba
que **la fluidez de un hallazgo y su validez son independientes**, y que al quitar el paso de
valoración, la relación señal-ruido se derrumba. Los informes se volvieron más numerosos y más
seguros de sí; la fracción que sobrevivía a la comprobación *bajó*.

## La avalancha es un problema de seguridad, no una molestia

Es tentador archivar «demasiados hallazgos» como fastidio. No lo es. Cuando la generación deja
atrás a la valoración, el hallazgo real no desaparece — queda enterrado en la cola detrás de
doscientos plausibles, y una cola que nadie puede vaciar es una cola que esconde cosas. La
palabra de curl — DDoS — es el registro correcto. Un equipo que se ahoga en informes seguros de
sí no es más seguro que un equipo sin informes; es un equipo cuya atención se agotó en testigos
que nunca pasaron por el interrogatorio.

## Mantener separadas las dos alarmas

Aquí se confunden dos afirmaciones, y separarlas es toda la disciplina.

**En agregado, el peligro es real.** Existen genuinamente cantidades enormes de defectos sin
corregir en código viejo, y un buscador barato e incansable sacará a la superficie algunos.
Despachar toda la categoría como bombo es un error.

**Por hallazgo, la criticidad declarada está sistemáticamente sobrevalorada** — hacia arriba,
porque el único campo que nadie puede comprobar es el que todos inflan. Tratar cada alerta como
un veredicto también es un error, en el sentido contrario.

El error consiste en responder a la pregunta de una con la alarma de la otra. «Existen muchos
fallos reales en algún lugar de este ecosistema» no hace que *este* hallazgo, en *su* línea, sea
aprovechable. Y «la mayoría de estas alertas concretas son ruido» no significa que su base de
código esté limpia.

## Lo que ve con claridad

El editor medieval no podía descontaminar toda la tradición. Lo que sí podía hacer: atar
condiciones a cada lectura y hacer las condiciones explícitas. El mismo movimiento funciona
aquí. Cuando le entreguen un hallazgo, pregunte:

1. **¿Qué peldaño de evidencia alcanza realmente?** Trazado en el código fuente, compilado,
   probado o reproducido en ejecución — no son la misma afirmación. Un hallazgo nunca debería
   vestir una certeza superior al trabajo que lo respalda.
2. **¿Es alcanzable en su build, o alcanzable en principio?** Una gravedad sin argumento de
   alcanzabilidad es un estado de ánimo, no una medición.
3. **¿Fue valorado, o promediado?** Que tres herramientas coincidan no son tres confirmaciones si
   las herramientas comparten un punto ciego. Un hallazgo minoritario merece una comprobación de
   oráculo barata — ejecutar el test, leer la especificación, recorrer la ruta — no una votación.
4. **¿Está ya corregido, o ya es conocido?** Un hallazgo que los mantenedores cerraron el mes
   pasado es un testigo de la historia, no de su riesgo.

Nada de eso es exótico. Es lo que una edición crítica hace con una pila de manuscritos: colacionar
los testigos, valorarlos contra evidencia más fuerte que otra opinión, y conservar el aparato —
los juicios, la incertidumbre, las lecturas consideradas y rechazadas.

## No todos los hallazgos muertos murieron la misma muerte

La mayoría de los hallazgos no sobreviven. Eso es normal, y es la cuestión — pero *cómo* murió un
hallazgo es información, y una revisión que los vuelca todos en un mismo cubo marcado
«descartados» ha tirado esa información.

La filología separa los casos, y la distinción es lo bastante antigua como para tener nombre. Un
manuscrito del que se demuestra que fue copiado de otro manuscrito conservado se tacha del
cómputo — *eliminatio codicum descriptorum* — no porque sea falso, sino porque no aporta ningún
testimonio independiente. Su coincidencia nunca fue evidencia.

Tres muertes, y no significan lo mismo:

- **Redundante.** Varias herramientas produjeron el mismo hallazgo. Donde esas herramientas no
  son independientes — y compartiendo datos de entrenamiento y plantillas, a menudo no lo son —,
  su coincidencia es una lectura en tres copias y no tres confirmaciones; contarla tres veces es
  la manera en que se fabrica la falsa confianza. Tache los duplicados, pero registre el supuesto
  de independencia en lugar de darlo por hecho: la coincidencia de revisores genuinamente
  independientes no es nada desdeñable.
- **Falso.** El hallazgo dice que el código hace algo que el código no hace. Se resuelve abriendo
  el fichero. Esta es la única categoría que la mayoría tiene en mente cuando dice «falso
  positivo».
- **Verdadero, pero sobre un texto que ya no existe.** El hallazgo es exacto — sobre una revisión
  corregida desde entonces. El testigo es honesto; el código se movió debajo de él. Un defecto
  cerrado en una revisión upstream fijada no es un falso positivo para esa revisión y no debería
  registrarse como tal. Eso solo vale si el hallazgo dice qué revisión leyó: un informe que no
  puede nombrar su revisión no es un testigo honesto de un texto superado — es una afirmación
  caducada sobre el actual.

Solo la segunda es un error de la propia lectura; el caso sin fijar de la tercera es un error de
la cadena que lo reportó. Un expediente que dice qué muerte murió cada hallazgo puede auditarlo
alguien que no estuvo allí. Un ratio — «triamos doscientos hallazgos hasta seis» — no puede, y
tampoco es una señal de calidad: una cadena perezosa alcanza ese ratio generando desechos y
tirándolos. **La eliminación no es el producto. La evidencia detrás de los supervivientes lo
es.**

## Para qué sirve una edición

La razón para construir una edición en lugar de una lista: alguien tiene que llegar a un
veredicto, y no será el revisor.

Un mantenedor decide si parchear. Un fabricante decide qué entra en la documentación técnica. El
equipo de seguridad de un cliente corporativo decide si firma. Cada uno de ellos alcanza un
veredicto, y a cada uno se le pedirá después — alguien menos amistoso, con más tiempo — que
muestre cómo lo alcanzó. Lo que necesitan de un revisor no es una opinión más que sopesar. Es la
evidencia, ordenada de modo que su propia decisión sobreviva a la pregunta.

En Europa esto está pasando de buena práctica a exigencia legal. El Cyber Resilience Act exige a
los fabricantes que *«llevarán a cabo exámenes y pruebas eficaces y periódicos de la seguridad
del producto con elementos digitales»* (anexo I, parte II, punto 3)), y la documentación técnica
debe contener *«informes de las pruebas realizadas para verificar la conformidad …»* (anexo VII,
punto 6)) — conservados un mínimo de diez años a partir de la introducción en el mercado, o
durante el período de soporte si fuera más largo (artículo 13, apartado 13). La notificación del
artículo 14 sobre vulnerabilidades activamente explotadas e incidentes graves comienza el 11 de
septiembre de 2026; el Reglamento se aplica íntegramente desde el 11 de diciembre de 2027.

Lea lo que realmente se pide. Ni un escaneo limpio, ni una cifra baja. Un *informe de pruebas
realizadas*, conservado una década, legible para alguien que no estuvo en la sala. Una lista de
hallazgos con gravedades seguras de sí, sin aparato debajo y sin registro de qué se rechazó y
por qué, no sobrevive a esa lectura. Una edición sí — porque cada afirmación nombra la evidencia
que la respalda, cada lectura eliminada queda registrada con su razón, y cada corrección se hace
por escrito.

Las obligaciones recaen sobre el fabricante, no sobre un revisor externo. Una revisión externa
del tipo aquí descrito apoya la documentación técnica que usted reúne; no es el expediente
completo, y no sustituye a la evaluación de la conformidad por un organismo notificado allí donde
el Reglamento la exige. Pero es la parte de ese expediente más difícil de producir sobre el
propio trabajo — porque la única propiedad que debe portar es que la escribió alguien distinto de
usted.

## Por qué nos importa

En CounterProof practicamos la revisión adversarial de código escrito por máquinas, y estas
preguntas no son teóricas para nosotros — son nuestras reglas de funcionamiento. Los hallazgos se
valoran en lugar de promediarse; cada afirmación nombra el peldaño de evidencia que alcanzó, y
ninguno más; un hallazgo ya corregido upstream se retira en lugar de contarse; y cuando una de
nuestras propias afirmaciones no sobrevive,
[la retractamos por escrito, públicamente](https://counterproof.io/notes/we-withdrew-our-own-number/) (en inglés). No
vendemos un número de hallazgos, y le aconsejaríamos no comprar sobre esa base. Los escáneres son
copistas, y el scriptorium funciona ahora día y noche por céntimos. Lo escaso nunca fue la copia.
Es la edición.

El argumento largo — incluida la forma condicional de cada afirmación de arriba y los límites de
nuestro propio método — está en nuestro documento de trabajo sobre colación y procedencia del
texto generado por máquinas, [legible íntegramente aquí](https://research.counterproof.io/) (en
inglés). Es un preprint en estado de borrador, sin revisión por pares, y así lo dice.

---

*Las cifras de arriba tienen fuente: la campaña sobre 501 proyectos está documentada en nuestra
nota anterior; los ratios del banco de pruebas de los tres sistemas proceden de la publicación
del proveedor; la tasa de confirmación de curl, el informe de la función fantasma y el cierre de
su programa de recompensas los reportan The New Stack, BleepingComputer y The Register. Las
citas del Cyber Resilience Act remiten al Reglamento (UE) 2024/2847 en su versión lingüística
española oficial — las mismas referencias que llevamos en nuestra página de inicio. Donde una
afirmación es inferencia nuestra y no un hallazgo citado — que la gravedad se infla hacia
arriba, que fluidez y validez son independientes —, lo hemos dicho. Esta página es una
traducción del original inglés; en caso de divergencia, prevalece el original. Si algo aquí es
erróneo, lo corregiremos por escrito en esta página.*