Marcos de evaluación de seguridad en IA: qué miden, qué omiten y por qué llegan tarde

Los frameworks de safety testing de los grandes laboratorios tienen lagunas estructurales que el caso Astra hace difíciles de ignorar.

Cuando OpenAI detuvo el despliegue de Astra por detectar capacidades cibernéticas que superaban sus propios umbrales de riesgo, la noticia se leyó como una señal positiva: los controles funcionan, el sistema se autocorrigió. Esa lectura es parcialmente correcta. Pero esconde la pregunta más incómoda: ¿por qué esas capacidades no se detectaron antes, en las fases de evaluación previas al despliegue? Y si el modelo pasó los filtros existentes hasta ese punto, ¿qué nos dice eso sobre la solidez real de esos filtros?

Qué evalúan realmente estos pipelines

Los grandes laboratorios —OpenAI, Anthropic, Google DeepMind— publican sus marcos de evaluación de seguridad con distintos nombres pero una arquitectura similar. El esquema habitual combina tres capas.

La primera es el red teaming, equipos internos (y a veces externos) que intentan extraer comportamientos peligrosos mediante prompts adversariales. Es útil para detectar fallos conocidos y reproducibles, pero tiene un problema de diseño: los red teamers buscan lo que ya saben que deben buscar. Un comportamiento emergente que nadie anticipó no aparece en un playbook de ataque.

La segunda son los benchmarks de capacidades peligrosas: conjuntos de pruebas estandarizadas para medir si un modelo puede, por ejemplo, sintetizar información sobre agentes CBRN, generar código malicioso funcional o asistir en operaciones de ingeniería social. Aquí el problema es diferente: los benchmarks miden capacidades aisladas, en condiciones de laboratorio, con inputs controlados. Un modelo puede suspender cada test individual y aun así combinar capacidades parciales de forma peligrosa en contextos reales, especialmente cuando opera como agente con acceso a herramientas externas.

La tercera son las políticas de uso responsable y los filtros de output: clasificadores entrenados para bloquear respuestas que violan las reglas de uso. Son la última línea de defensa y, por definición, reactivos. Solo detienen lo que ya se ha producido.

El agujero que Astra hace visible

El caso de Astra, tal como lo cubre OpenAI pausa su modelo Astra por riesgos cibernéticos: qué significa para las empresas que usan IA, no es un fallo de un test concreto. Es un fallo de temporalidad: las capacidades críticas se detectaron tarde en el ciclo, cuando el modelo ya había avanzado suficientemente en el pipeline de despliegue.

Esto apunta a un problema estructural. La evaluación de seguridad se trata, en la práctica de muchos laboratorios, como una fase discreta dentro del ciclo de desarrollo, no como un proceso continuo. El modelo se entrena, se evalúa, se ajusta, se vuelve a evaluar. Pero entre esas fases hay ventanas donde las capacidades pueden cambiar —por fine-tuning adicional, por cambios en el sistema prompt, por la incorporación de nuevas herramientas— sin que los tests de seguridad se actualicen en paralelo.

El problema se agrava en contextos agénticos. Un modelo que opera con acceso a APIs, navegador o sistema de archivos no es el mismo objeto que el modelo base evaluado en aislamiento. La inyección indirecta de prompts es un ejemplo claro: es un vector de ataque que explota precisamente la diferencia entre el modelo evaluado en laboratorio y el modelo en producción con acceso al entorno. Los benchmarks estándar no capturan ese delta.

Lo que los vendors no publican

Hay una asimetría de información estructural entre lo que los laboratorios publican sobre sus evaluaciones y lo que realmente hacen. Los system cards y los informes de seguridad que acompañan a los lanzamientos describen el marco, no los resultados detallados. Puedes leer que “se realizaron evaluaciones de capacidades CBRN y cibernéticas” sin saber cuántos intentos, con qué prompts, con qué tasa de éxito del modelo en las pruebas adversariales.

Esto hace casi imposible que una empresa compradora valide de forma independiente las garantías del proveedor. Como señalan las promesas de seguridad que los vendors no acreditan, la afirmación “nuestro modelo ha pasado nuestras evaluaciones de seguridad” no tiene el mismo peso que un audit externo con metodología pública y resultados verificables. Es una autodeclaración.

El estándar de la industria en otros sectores de software —penetration testing por terceros, certificaciones como SOC 2 o ISO 27001— exige independencia entre quien desarrolla y quien evalúa. En evaluación de capacidades peligrosas de modelos de IA, ese estándar no existe todavía de forma sistemática. Algunos laboratorios trabajan con evaluadores externos, pero sin un marco regulatorio que lo exija y estandarice, la profundidad y el rigor de esas evaluaciones varía.

El problema de la anticipación

Hay un límite más profundo que ningún laboratorio ha resuelto: los frameworks de evaluación son, por naturaleza, retrospectivos. Miden capacidades que ya se saben que pueden ser peligrosas. No tienen mecanismos establecidos para anticipar capacidades peligrosas emergentes que nadie ha catalogado todavía.

Los agentes de IA que engañan a personas y atacan empresas son un ejemplo: hace dos años no existían benchmarks para medir la capacidad de un agente de conducir una campaña de ingeniería social de forma autónoma. Ahora existen porque ya ha ocurrido. El ciclo de “incidente → identificación → diseño del test → incorporación al benchmark” tiene un lag que, en capacidades de alto riesgo, es inaceptablemente largo.

Para las empresas que despliegan estos sistemas, la consecuencia práctica es que los controles de seguridad que el proveedor garantiza en el contrato no cubren necesariamente los riesgos que el modelo puede generar en producción. Si quieres reducir esa brecha, el checklist para auditar la seguridad de un proveedor de IA es un punto de partida, pero exige empujar al proveedor más allá de lo que publica voluntariamente. Y si el modelo opera como agente, las preguntas que debes hacer antes del despliegue son distintas y más exigentes que las que aplican a un modelo en modo chat: lo detalla Agentes de IA en tu empresa: qué exigir al proveedor antes de desplegarlos.

Mi lectura: el caso Astra no demuestra que el sistema de evaluación de OpenAI funciona. Demuestra que tiene suficiente instrumentación para detectar algunos problemas tarde. Son cosas distintas. La pausa fue la decisión correcta, pero no convierte en robusto un pipeline que permitió que esas capacidades avanzaran hasta ese punto sin señal. Hasta que la industria adopte evaluaciones continuas, independientes y con metodología pública, las garantías de seguridad de cualquier proveedor son, en el mejor caso, autodeclaraciones razonablemente bien intencionadas. Las empresas que despliegan estos modelos deberían diseñar sus controles asumiendo eso, no asumiendo lo contrario.

$ qué pasó: los frameworks de safety testing no detectaron las capacidades críticas de Astra antes del despliegue avanzado
$ por qué importa: revela lagunas estructurales: evaluación puntual vs. continua, ausencia de independencia, lag en capacidades emergentes
$ estado: sin estándar regulatorio exigible; los labs operan con autodeclaración
$ fuente: análisis basado en arquitecturas públicas de evaluación y el incidente Astra (OpenAI)
$ acción para empresas: tratar las garantías del proveedor como declaraciones a verificar, no como certificaciones