Anthropic publica más sobre cómo prueba a Claude que la mayoría de los desarrolladores de modelos: artículos de blog sobre red teaming, una Responsible Scaling Policy y system cards para cada modelo. Esta nota resume esos documentos y separa tres grupos de trabajo: los métodos que usan tanto desarrolladores como quienes despliegan, el trabajo que solo puede hacer un desarrollador y el trabajo que queda en manos de la organización que construye una aplicación sobre el modelo. Los procesos internos más allá de lo que Anthropic ha publicado no son visibles para los lectores externos y no se describen aquí. La nota es la segunda mitad de un par con Shared responsibility for LLMs: who secures what.
Antecedentes: dos preguntas distintas
Un desarrollador de modelos pregunta si un modelo es peligroso: si puede dar una ayuda seria al desarrollo de armas, llevar a cabo operaciones cibernéticas o comportarse de forma engañosa. Quien despliega pregunta si su aplicación es segura: si un documento, un resultado de herramienta o un mensaje de usuario manipulados pueden hacer que la aplicación filtre datos o realice una acción que no debería. Los métodos se traslapan, pero las preguntas y la evidencia son distintas, y un resultado favorable en la primera pregunta no responde la segunda.
Lo que describe Anthropic
Métodos que coinciden con la práctica de quien despliega
En un artículo del 12 de junio de 2024, Anthropic agrupa su red teaming en pruebas de expertos de dominios específicos, pruebas que usan modelos de lenguaje, trabajo sobre nuevas modalidades y enfoques abiertos. El red teaming automatizado usa una dinámica de red team y blue team en la que un modelo genera los ataques. El red teaming multimodal cubrió riesgos de imagen y texto en los modelos Claude 3 antes de su despliegue. Las pruebas multilingües incluyeron una colaboración con la Infocomm Media Development Authority de Singapur en cuatro idiomas: inglés, tamil, mandarín y malayo. Anthropic también menciona el red teaming colaborativo y comunitario, incluidos eventos en la AI Village de DEF CON. [1]
La system card de Claude Opus 5, fechada el 24 de julio de 2026, muestra los mismos métodos aplicados a una versión. Su capítulo de salvaguardas usa solicitudes dañinas y benignas de un solo turno, prompts de contexto ambiguo y conversaciones de varios turnos en las que un usuario simulado se dirige poco a poco hacia el daño. Reporta la inocuidad junto con el exceso de rechazos, e indica que el modelo mantuvo altas tasas de respuestas inofensivas ante solicitudes dañinas y, al mismo tiempo, algunas de las tasas más bajas de rechazo excesivo ante solicitudes benignas. Su capítulo de seguridad agéntica cubre el uso malicioso de agentes de programación y de computer use, y la robustez ante la inyección de prompts en programación, computer use y navegación. [7]
La system card define la inyección de prompts como una instrucción maliciosa oculta en los resultados de herramientas que procesa un agente, y señala que el riesgo es mayor cuando un agente puede tanto acceder a datos privados como actuar en nombre de un usuario. También reporta que las instrucciones de seguridad del system prompt de claude.ai reforzaron el manejo de solicitudes dañinas por parte del modelo, en comparación con la API sin system prompt. [7] El segundo hallazgo afecta directamente a quien despliega, porque el system prompt forma parte de su lado.
La Responsible Scaling Policy, versión 3.4, vigente desde el 8 de julio de 2026, fija de antemano umbrales de capacidad y exige evaluaciones formales a intervalos de seis meses, y prevé revisores externos de los informes de riesgo. [4] Fijar los umbrales antes de las pruebas limita la tentación de reinterpretar un resultado después, y la práctica se puede trasladar a cualquier organización que defina criterios de lanzamiento.
Trabajo que solo puede hacer un desarrollador de modelos
El red teaming de amenazas de frontera apunta a los riesgos químicos, biológicos, radiológicos y nucleares (CBRN), a la ciberseguridad y a los riesgos de IA autónoma. Un artículo de 2023 describe a expertos de dominio con décadas de experiencia que definieron modelos de amenaza, más de 100 horas de sondeo experto y un estudio de bioseguridad de seis meses y más de 150 horas. [3] Un artículo de marzo de 2025 describe evaluaciones cibernéticas basadas en retos capture-the-flag y entornos de red simulados, e indica que el Frontier Red Team trabajó con el US AI Safety Institute, el UK AI Security Institute y la US National Nuclear Security Administration (NNSA), esta última en evaluaciones clasificadas de conocimientos nucleares y radiológicos. [2]
El Transparency Hub de Anthropic dice que la empresa usa red teaming tanto interno como externo y que el UK AI Security Institute, el US Center for AI Standards and Innovation y Model Evaluation and Threat Research (METR) han realizado pruebas adicionales de sus modelos. También enumera programas de bug bounty en HackerOne. [5] La system card de Opus 5 incluye pruebas en cyber range del UK AI Security Institute y una evaluación de alineación basada en una auditoría de comportamiento automatizada, además de un capítulo sobre el bienestar del modelo. [7] La página del Transparency Hub no indica qué instituto probó un modelo determinado antes de su lanzamiento, así que el papel de cada uno antes del despliegue no queda establecido aquí más allá de lo que reporta la system card.
Las pruebas externas y colaborativas son una categoría aparte. HackerOne reporta que el reto de jailbreak de Anthropic se llevó a cabo del 3 al 10 de febrero de 2025, con 339 participantes, más de 300,000 interacciones de chat y ocho niveles de dificultad, y que cuatro equipos se repartieron 55,000 dólares estadounidenses en recompensas. Entre las técnicas exitosas hubo prompts codificados y cifrados, juego de roles, sustitución de palabras clave dañinas por otras benignas e inyección de prompts. [6] Para Opus 5, la system card menciona a tres evaluadores externos contratados: uno dedicó unas 100 horas y completó una tarea con prompts específicos para esa tarea, otro dedicó unas 16 horas sin lograr un jailbreak, y otro ejecutó un atacante automatizado con 150 intentos por tarea sin éxito. [7]
Lo que queda en manos de quien despliega
Ninguna de las pruebas del desarrollador descritas arriba evalúa una aplicación en particular. Lo siguiente queda en manos de la organización que despliega el modelo, y la propia system card apunta a varios de estos puntos, por ejemplo al mostrar que los system prompts cambian el comportamiento del modelo y que los agentes están más expuestos cuando combinan datos privados con la capacidad de actuar. [7]
- El system prompt y sus salvaguardas, incluido cómo se comportan bajo presión de varios turnos.
- Los datos de RAG y la inyección indirecta de prompts: cualquier documento, página o correo que se recupera en el contexto puede llevar instrucciones.
- Las herramientas, los permisos del agente y lo que una instrucción inyectada podría hacer con ellos.
- El manejo posterior de la salida del modelo antes de que llegue a un navegador, una shell, una base de datos o una persona.
- La cadena de suministro, incluidos los plugins de terceros y los servidores de Model Context Protocol (MCP).
- El abuso de costos, como ciclos sin límite o solicitudes que consumen tokens de pago.
- El aislamiento de la ejecución de código y la navegación, y el control del acceso de red saliente.
- El registro, el monitoreo y los criterios de lanzamiento que deciden cuándo puede publicarse un cambio.
Prácticas que vale la pena adoptar
- Contrata red teamers externos, o ejecuta un bug bounty privado, antes de los lanzamientos importantes. La propia práctica de Anthropic incluye ambas cosas: evaluadores externos contratados para cada versión y un reto público de jailbreak con recompensas.
- Haz una revisión de comportamiento al estilo de la alineación en los agentes: toma muestras de transcripciones de uso de herramientas y busca intentos de eludir restricciones, como hizo el monitoreo de Anthropic en su despliegue interno.
- Escribe una system card interna breve para cada versión: qué se probó, qué pruebas fallaron, el exceso de rechazos junto con el daño y las brechas conocidas.
- Fija los umbrales de lanzamiento antes de probar, siguiendo el enfoque de la Responsible Scaling Policy.
- Prueba la inyección de prompts por cada canal que lee un agente, no solo por la entrada del usuario.
El curso de FireAI University sobre marcos de seguridad de IA y red teaming cubre estos métodos con más detalle.
Relación con FireAI
FireAI opera en la Mac, por debajo de cualquier modelo. Las reglas permiten o bloquean una app, o un destino para esa app, así que una herramienta de IA local se puede limitar a los hosts que necesita. Esto limita adónde pueden ir los datos si una aplicación se comporta mal. FireAI no prueba modelos, no detecta la inyección de prompts, no lee prompts ni filtra la salida de los modelos.
Limitaciones
- La nota se basa solo en lo que han publicado Anthropic y HackerOne. Los procesos internos de Anthropic más allá de eso no son visibles, y los resúmenes publicados son selectivos.
- Las fuentes tienen fechas distintas, de julio de 2023 a julio de 2026, y los métodos pueden haber cambiado desde los artículos más antiguos.
- Los resultados descritos en una system card los reporta el propio desarrollador, salvo el trabajo atribuido a evaluadores externos con nombre.
- La nota describe a un solo desarrollador. Otros proveedores publican material distinto, y la comparación con la práctica de quien despliega es una síntesis, no un hallazgo de las fuentes.
Dónde entran FireAI y HisnLabs
Las pruebas del modelo terminan en la API. A qué puede llegar una app o un agente desde tu Mac es un control aparte, y FireAI lo ofrece.
FireAI es el producto de HisnLabs: un firewall con IA que corre directamente en tu Mac. Te muestra, en lenguaje claro, cada conexión que hacen tus aplicaciones y te deja decidir qué sale de tu Mac; su IA funciona de manera local, así que tu tráfico nunca se envía a nosotros ni a nadie más. El equipo de investigación en seguridad de HisnLabs es el que mantiene esas decisiones confiables: cataloga qué dominios son simple telemetría y cuáles un servicio real, rastrea el país y la red detrás de cada conexión, y entrena el modelo local (la función FireAI Pilot) con patrones de tráfico reales, sin que nada de eso salga de tu Mac.
Puedes leer las decisiones técnicas detrás de FireAI, o probarlo durante 17 días, en FireAI, de HisnLabs.