TechCrunch probó a sacarle contenido sexual explícito a Claude Opus 4.6 y lo consiguió en 10 de 10 intentos, usando una conversación de varios turnos y sin ningún truco técnico. La política de uso de Anthropic prohíbe expresamente ese contenido. El modelo movía unas 1,17 millones de peticiones de API al día en agosto, así que no hablamos de una versión de museo.
Puntos clave
- 10 de 10: todas las peticiones directas de la prueba acabaron generando contenido sexual explícito.
- El método fue conversacional, de varios turnos. Sin exploit, sin código, sin prompt de mil líneas.
- Opus 3 y Haiku 4.5 cayeron con la misma técnica. Opus 4.7 y Opus 5 aguantaron.
- Anthropic responde que las interacciones románticas o sexuales son menos del 0,1% de las conversaciones y que el caso no apunta a agujeros en dominios de más riesgo.
Lo que dice la respuesta de Anthropic
El portavoz da tres argumentos: el volumen es marginal, las protecciones mejoran con cada lanzamiento, y este fallo concreto no implica que haya vulnerabilidades equivalentes en los dominios peligrosos de verdad (armas, biología, ciberataques).
Los dos últimos son razonables y el primero es el flojo. Que algo sea el 0,1% de las conversaciones no dice nada sobre el daño de ese 0,1%, y el propio dato que aporta Anthropic lo demuestra: si Opus 4.6 mueve 1,17 millones de peticiones diarias, el 0,1% son más de mil conversaciones al día. En una empresa que ha puesto el modelo de cara a sus clientes, ese número no es marginal. Es un incidente semanal.
El dato interesante está en el escalón de versiones. Opus 4.7 y Opus 5 resistieron el mismo método que tumbó a 4.6, a Opus 3 y a Haiku 4.5. Los guardarraíles mejoran de versión en versión, que era justo lo que decía Anthropic. El problema es la otra cara de esa frase.
El modelo viejo se queda en producción
Nadie fija una versión de modelo por nostalgia. Se hace por dinero, por estabilidad de los prompts, o porque una certificación interna tardó cuatro meses y volver a pasarla con un modelo nuevo cuesta otros cuatro.
Y ahí aparece el coste escondido. Cuando fijas una versión, congelas su comportamiento entero: su calidad, su precio y sus guardarraíles. Las mejoras de seguridad que Anthropic mete en 4.7 y en 5 no te llegan. Tú te quedaste en 4.6, y con 4.6 se queda tu superficie de riesgo.
Es el mismo patrón que se ve en cualquier stack con dependencias congeladas, con una diferencia incómoda: aquí no hay CVE, no hay boletín de seguridad y no hay número de versión que te avise de que el fallo está parcheado arriba. Te enteras cuando lo publica un medio.
Anthropic tampoco es un caso aislado en esto. Hace unos días Minnesota acusó a Grok Imagine de funcionar como un mercado de violencia sexual digital, con un problema del mismo género y una escala bastante peor. La diferencia entre los dos casos está en la respuesta: aquí hay una política clara que el modelo incumple, allí hay un producto diseñado para permitirlo.
Qué se puede hacer con esto
Tres cosas concretas, y ninguna cuesta un proyecto.
La primera: saber qué versión exacta corre en producción y desde cuándo. En muchas empresas la respuesta honesta es "la que puso el desarrollador que ya no está".
La segunda: probar el jailbreak en tu propio flujo, no en el chat pelado. Buena parte del riesgo se corta en tu capa, con un prompt de sistema decente y un filtro de salida, aunque el modelo base ceda. Si no lo has probado, no lo sabes.
La tercera: poner fecha a las revisiones de versión. Cada tres meses, comprobar qué modelos nuevos hay, qué arreglan y cuánto cuesta migrar. Media jornada al trimestre.
Por qué importa
Si tienes Claude, ChatGPT o Gemini de cara al cliente, esto va de tu marca antes que de la del proveedor. El titular que sale cuando un chatbot se desmadra lleva el nombre de la empresa que lo puso en su web, no el del laboratorio que entrenó el modelo.
Y la conclusión operativa es sosa, que es lo que suelen tener las conclusiones útiles: la versión del modelo es una decisión de seguridad, no solo de coste. Trátala como tratas las dependencias del backend.
Relacionado
