revisión de código adversarial independiente
Lo que estamos leyendo en el Cyber Resilience Act — y lo que estamos descubriendo sobre cómo se evalúa el trabajo generado por máquinas. Fechado, con fuentes, y corregido por escrito cuando nos equivocamos.
Modelos de otros proveedores ayudaron a escribir, seleccionar y juzgar los datos de entrenamiento de Kolibri-1. El resumen europeo enumera siete nombres; el informe técnico explica las distintas funciones. Estas divulgaciones muestran cómo un modelo construido para un despliegue soberano y especializado puede apoyarse en modelos de otros proveedores durante el entrenamiento. No establecen qué comportamientos, si alguno, se heredaron.
De doce configuraciones de agente, la que más veces produjo código que funcionaba lo hizo en el 57 % de las tareas; solo en el 11,8 % su código funcionó y además superó el test de seguridad. Informar al agente del riesgo ayudó un poco. El estudio pudo comprobar la presencia de cada fallo porque ya se había encontrado y corregido, y la corrección venía con un test de seguridad. El código nuevo de su agente todavía no tiene un test así.
El Reglamento nunca menciona los monederos cripto. Se aplica a los productos con elementos digitales. Desde diciembre de 2027, exige además exámenes y pruebas eficaces y periódicos de la seguridad del producto. Según nuestra lectura, ese deber incide en si un fabricante encuentra un fallo antes que un atacante. Esta nota explica el ámbito de aplicación, los plazos de notificación y el papel de una revisión independiente.
Encontrar salió barato; el resto del ciclo de vida no. Un recorrido etapa por etapa (identificar, dictaminar, decidir, subsanar, notificar, conservar) con lo que el Cyber Resilience Act europeo exige en cada una, y el lugar donde se sitúa una revisión adversarial independiente: en las etapas posteriores a la primera.
Dos comparaciones preregistradas y puntuadas a ciegas entre nuestro dispositivo de revisión completo y una sola pasada económica, con auditorías profesionales públicas como plantilla de respuestas. El dispositivo perdió una diana con claridad; en la otra activó su propio umbral de precisión solo eliminando los hallazgos que el auditor había dictaminado reales (0–1 de 4, según el puntuador). Qué cambiamos, qué volvimos a medir, y los agujeros que una auditoría posterior encontró en la medición misma.
El Jev de TypeSafe AI es un modelo de un tipo nuevo: nunca escribe texto, solo devuelve decisiones tipadas con probabilidades. Su banco de pruebas lo califica contra la media de otros dos modelos de IA. Abrimos los casos que TypeSafe publica y contamos. En 8 de los 19 casos en que ambos calificadores respondieron, los calificadores discrepaban entre sí. Cada uno de los cuatro casos que TypeSafe publica bajo la etiqueta «los tres fallan la referencia» es un caso en que la referencia misma estaba en disputa. Una nota en lenguaje llano sobre lo que eso significa para cómo juzgamos la IA.
La expresión abarca ya cuatro prácticas, desde la instrucción crítica hasta los revisores humanos con mentalidad de atacante. Cada una aporta el encuadre del atacante; ninguna aporta por sí sola un expediente firmado por revisores independientes del autor de su código y graduado según la evidencia que alcanzó cada hallazgo. Qué entregamos, qué no puede producir un segundo modelo, y qué le decimos antes de comprar.
Tres estudios independientes, tres métodos distintos — un estudio dirigido de vulnerabilidades, una comparación controlada humano-modelo y un año de observación de repositorios reales — convergen en el mismo hallazgo: el código generado por IA acarrea un coste de calidad medible que sobrevive a la ganancia de productividad con la que llegó.
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.
La IA ha hundido el coste de encontrar vulnerabilidades. En el ecosistema open source de Bitcoin esa colisión llegó este mes — y Bruselas ha puesto un reloj sobre lo que viene después.
Un proyecto de modificación retrasaría las normas de gestión de vulnerabilidades del CRA. El artículo 14 no se mueve — lo que deja a los fabricantes documentando un deber cuya vara de medir todavía se está redactando.