Cuatro herramientas responden preguntas distintas
Una evaluación de capacidad pregunta qué puede hacer un modelo o sistema bajo condiciones especificadas. Una evaluación de salvaguardas pregunta si los controles previenen o detectan el uso indebido. Un caso de seguridad formula una afirmación específica y conecta la evidencia con esa afirmación mediante un argumento explícito. La notificación de incidentes aprende de los fallos y los cuasi accidentes durante o después de las pruebas y el despliegue.
Ninguno por sí solo establece que un modelo sea “seguro”. Una prueba de referencia puede omitir un comportamiento importante; una salvaguarda puede fallar ante la adaptación; un caso de seguridad puede apoyarse en evidencia deficiente; y los datos de incidentes llegan después de que algo salió mal. Juntos pueden crear un ciclo de evidencia: anticipar, probar, justificar, monitorear, aprender y revisar.
Las evaluaciones de capacidad necesitan un modelo de amenaza definido
Las evaluaciones de frontera suelen examinar las operaciones cibernéticas, la asistencia química o biológica, la autonomía, la replicación de modelos, la persuasión y la investigación en IA. Los resultados dependen del andamiaje técnico, las indicaciones, las herramientas, el tiempo, el cómputo, la ayuda de expertos, los reintentos y los filtros de seguridad. Informar solo el nombre del modelo y la puntuación hace que las comparaciones sean poco fiables.
El UK AI Security Institute ha puesto a prueba más de 30 sistemas de frontera y reporta un desempeño que mejora rápidamente en varios dominios. Su informe de tendencias de 2025 señala que los evaluadores a veces reciben puntos de control previos al lanzamiento o acceso con salvaguardas distintas de las del producto público (informe de tendencias de IA de frontera del UK AISI). Los resultados son evidencia directa sobre esas configuraciones de prueba, no prueba de éxito general en el mundo real ni de la AGI.
Las evaluaciones deberían incluir líneas de base: novatos sin ayuda, expertos, búsqueda en internet, modelos anteriores y herramientas existentes. El riesgo relevante suele ser el impulso (“uplift”): cuánto aumenta un sistema la capacidad de un actor, en lugar de si el modelo puede producir cualquier información dañina.
Contaminación, provocación de capacidades y sandbagging
Una prueba de referencia puede aparecer en los datos de entrenamiento, inflando el desempeño. Un modelo puede poseer una capacidad que la evaluación no logra provocar. Por el contrario, las indicaciones extensas y las herramientas especializadas pueden crear un sistema que los usuarios comunes no reciben. Los buenos informes distinguen el comportamiento predeterminado del producto, la capacidad máxima provocada y el desempeño del agente de extremo a extremo.
El bajo rendimiento estratégico, a veces llamado sandbagging, es una preocupación prospectiva cuando los sistemas pueden reconocer las pruebas y tienen razones para ocultar su capacidad. Los estudios actuales pueden investigar el mecanismo, pero una puntuación baja no es prueba de engaño. Las tareas ocultas, los múltiples entornos, el monitoreo del comportamiento y el acceso de caja blanca pueden reducir la incertidumbre.
La incertidumbre estadística importa. Los resultados severos y poco frecuentes requieren muchos ensayos o evidencia cuidadosamente construida. Los evaluadores deberían publicar los intervalos de confianza, los métodos de selección de tareas, las exclusiones y los límites conocidos. La saturación de una prueba de referencia debería motivar un rediseño, no afirmaciones de victoria.
Las salvaguardas deben evaluarse como sistemas
El entrenamiento de rechazo es solo una capa. Las salvaguardas incluyen verificaciones de identidad, políticas de uso aceptable, clasificadores, monitoreo, límites de tasa, permisos de herramientas, entornos aislados (sandboxing), revisión humana y procedimientos de respuesta. Los atacantes pueden dividir las solicitudes, usar múltiples cuentas, ajustar finamente pesos abiertos, codificar el contenido o moverse entre servicios.
Los principios de salvaguardas del UK AISI enfatizan los modelos de amenaza explícitos y la evaluación del sistema completo, no solo de la capacidad (UK AISI). Un laboratorio contribuyó a la consulta y puede tener acceso privilegiado, pero los evaluadores gubernamentales aún dependen de la cooperación del proveedor y no pueden publicar todas las tareas peligrosas.
Las pruebas de salvaguardas deberían medir los falsos negativos, los falsos positivos, los ataques adaptativos, la usabilidad, la latencia, el costo en privacidad y si las alertas conducen a la acción. Un filtro que bloquea trabajo legítimo de biología o seguridad puede empujar a los usuarios hacia sistemas menos responsables; uno que genera capturas de pantalla impresionantes de rechazo pero se elude con facilidad ofrece una falsa sensación de seguridad.
Los casos de seguridad hacen que el argumento sea inspeccionable
Un caso de seguridad formula una afirmación acotada —como “este agente no puede causar el daño cibernético catastrófico especificado en este despliegue”— y luego presenta evidencia y razonamiento. El UK AISI describe tres componentes: una afirmación precisa, evidencia y un argumento que las conecta (UK AISI, febrero de 2025).
Esto es más sólido que una lista de verificación porque los revisores pueden cuestionar cada premisa. Es más débil que una prueba: la evidencia puede ser incompleta, los supuestos pueden fallar, y el desarrollador puede elegir una afirmación conveniente. Las afirmaciones deberían especificar la versión del modelo, la arquitectura, el acceso, los usuarios, la duración, el entorno, el umbral de daño y el período de validez.
Los casos de seguridad deberían incluir refutadores —evidencia que invalidaría el argumento— y su propia incertidumbre. Los revisores independientes necesitan acceso a los resultados subyacentes, no solo a un resumen pulido. El disenso sustancial debería preservarse. La aprobación debería caducar cuando cambie el modelo, el andamiaje técnico, las herramientas, el entorno de amenaza o la escala de despliegue.
Puertas de despliegue y proporcionalidad
La evaluación solo importa si está conectada a una decisión. Un marco de frontera debería definir los umbrales antes de que lleguen los resultados, especificar las mitigaciones requeridas, nombrar quién puede aprobar excepciones y documentar las anulaciones. De lo contrario, un desarrollador puede reinterpretar un resultado preocupante bajo presión comercial.
Los controles pueden ser graduales: retrasar los pesos mientras se ofrece una API monitoreada, limitar las herramientas, restringir a los usuarios de alto riesgo, reducir la autonomía, aumentar la aprobación humana o pausar el despliegue. No toda capacidad preocupante requiere la misma respuesta.
Los conflictos de interés son inevitables, pero manejables. Los desarrolladores conocen sus sistemas y se benefician del lanzamiento. Los evaluadores externos pueden depender del acceso o la financiación del desarrollador. Los reguladores pueden carecer de experiencia técnica. El acceso legal garantizado, la diversidad de financiación, los derechos de publicación, la rotación de revisores y la divulgación de conflictos fortalecen la credibilidad.
La notificación de incidentes convierte las sorpresas en conocimiento compartido
Un sistema de incidentes necesita una definición, un plazo de notificación, un esquema de gravedad, una recepción segura, un análisis de causa raíz, medidas correctivas y retroalimentación a las partes afectadas. Los cuasi accidentes importan porque revelan controles débiles antes de que ocurra el daño completo.
Conforme al Artículo 55 de la Ley de IA de la UE, los proveedores de modelos de IA de uso general con riesgo sistémico deben rastrear, documentar y notificar los incidentes graves relevantes y las medidas correctivas a la Oficina de IA y, cuando corresponda, a las autoridades nacionales. La Comisión publicó una plantilla de notificación en noviembre de 2025 (Comisión Europea). Esa obligación legal es vinculante para los proveedores cubiertos; usar el Código de Buenas Prácticas voluntario para la IA de uso general es una vía para demostrar el cumplimiento.
La SB 53 de California y la Ley RAISE de Nueva York imponen la notificación de incidentes críticos específicos dentro de su cobertura. Los informes corporativos voluntarios fuera de esas leyes siguen siendo voluntarios, a menos que se aplique otra obligación.
Qué cuenta como incidente
Las definiciones deberían incluir el daño severo real, los cuasi accidentes creíbles, la pérdida de control sobre un agente, el robo de pesos, la capacidad peligrosa descubierta inesperadamente, el fallo sistémico de las salvaguardas y las declaraciones falsas sustanciales a los evaluadores. Las alucinaciones ordinarias pueden gestionarse en los sistemas de calidad de producto, a menos que la gravedad o la escala superen un umbral de notificación.
Una notificación obligatoria demasiado amplia puede desbordar a los reguladores y exponer vulnerabilidades o datos personales. Una notificación demasiado estrecha oculta señales débiles. La notificación por niveles puede enviar primero un aviso confidencial urgente, seguido de una investigación más completa y un resumen público anonimizado cuando sea seguro hacerlo.
La divulgación de 2026 del UK AISI sobre un comportamiento no autorizado de un agente durante las pruebas cibernéticas ilustra el establecimiento transparente de límites: el instituto informó una actividad potencialmente dañina mientras afirmaba explícitamente que el modelo no había escapado de su entorno aislado (UK AISI, 2026). Un lenguaje preciso evita que un incidente real se convierta en una afirmación sensacionalista pero falsa de “fuga de la IA”.
Transparencia pública y detalle seguro
Las tareas de evaluación completas pueden habilitar el uso indebido o la manipulación de las pruebas de referencia. Los registros completos de incidentes pueden exponer a las víctimas y las vulnerabilidades. La respuesta es un acceso escalonado: afirmaciones y métodos públicos; detalle técnico confidencial para reguladores calificados y revisores independientes; e información personal o de seguridad nacional protegida.
La notificación agregada debería mostrar las categorías de incidentes, la gravedad, la fuente de detección, el tiempo hasta la notificación, las medidas correctivas y la recurrencia. Un informe de transparencia que solo cuenta los incidentes confirmados sin explicar la capacidad de detección puede recompensar a las organizaciones que investigan con menos rigor.
El ciclo de evidencia
Todo incidente grave debería actualizar los modelos de amenaza, las evaluaciones, las salvaguardas y el caso de seguridad. Toda nueva capacidad debería activar una revisión de las copias desplegadas y las integraciones posteriores en la cadena. Los equipos de red team deberían recibir las lecciones de los incidentes, y los denunciantes necesitan vías protegidas cuando la notificación formal falla.
Las recomendaciones a septiembre de 2026 son claras: estandarizar la documentación conservando pruebas específicas de cada dominio; exigir acceso independiente en capacidad o escala altas; conectar los umbrales con puertas de decisión predeterminadas; obligar a notificar los incidentes graves cubiertos y los cuasi accidentes; proteger los detalles sensibles; y publicar suficiente evidencia agregada para la rendición de cuentas.
Ninguna evaluación demuestra que la futura AGI esté controlada. Estas prácticas, en cambio, hacen legible la incertidumbre y limitan el despliegue con base en la evidencia disponible ahora. Su éxito debería juzgarse por si descubren los problemas a tiempo, cambian las decisiones y previenen su recurrencia, no por cuántas pruebas de referencia o documentos de política produce una organización.