Última actualización: Octubre 2026
¿Son los constitutional classifiers una capa de seguridad fiable para despliegues empresariales de Claude?
La investigación de Anthropic muestra que la segunda generación reduce las tasas de éxito de jailbreak a 0,005 por cada mil consultas, frente al 86 % de un modelo sin protección. Pero dos categorías de bypass siguen siendo activas en producción, y los equipos de seguridad suelen auditar solo las salidas que fallan de forma visible, no las que no lo hacen.
TL;DR: Puntos clave
- Los constitutional classifiers son capas de filtrado entrenadas que se sitúan antes y después de Claude, bloqueando peticiones dañinas antes de que el modelo las procese y respuestas dañinas antes de que lleguen al usuario.
- La segunda generación (CC++) reduce el éxito de jailbreak del 86 % a 0,005 por cada mil consultas, usando activaciones internas del propio modelo en lugar de un clasificador separado, y reduciendo el coste computacional del 23,7 % a aproximadamente el 1 %.
- Dos categorías de ataque persisten en producción: los ataques de reconstrucción, que fragmentan información dañina en segmentos inocuos, y la ofuscación de salida mediante términos en clave o metáforas. Según el paper de Anthropic de 2026, no se encontró ningún jailbreak universal en 1.700 horas de pruebas adversariales, aunque sí se identificó una vulnerabilidad de alto riesgo.
- El OWASP LLM Top 10 incluye la inyección de prompt (LLM01) y el manejo inseguro de salidas (LLM02) como las superficies de ataque principales que los constitutional classifiers abordan, aunque no eliminan.
- Las empresas que despliegan Claude a través de la API son responsables de auditar la cobertura del clasificador en el contexto específico de su system prompt. Los constitutional classifiers se entrenan con datos sintéticos basados en una constitución general, no en los datos de tu organización.
| Métrica | Modelo sin protección | CC v1 (2025) | CC v2: CC++ (2026) |
|---|---|---|---|
| Tasa de éxito de jailbreak | 86 % | 4,4 % | 0,005 por cada 1.000 consultas |
| Coste computacional adicional | referencia | +23,7 % | ~1 % |
| Incremento en falsas denegaciones | referencia | +0,38 % | +0,05 % |
| Horas de red team | n/a | 3.000+ horas | 1.700 horas |
| Jailbreaks universales encontrados | n/a | 1 (demo en vivo) | 0 (pruebas) |
Qué Son los Constitutional Classifiers (y Qué No Son)
Los constitutional classifiers son filtros de entrada y salida entrenados que se despliegan delante de los grandes modelos de lenguaje para interceptar peticiones y respuestas que violan una constitución de seguridad definida. Anthropic presentó el sistema v1 públicamente en enero de 2025, seguido de una segunda generación (CC++) a principios de 2026.
La palabra "constitucional" no hace referencia a marcos legales, sino a un documento de políticas estructurado, una constitución, que define qué categorías de contenido debe bloquear el sistema. Un ejemplo simplificado: "las recetas con ingredientes de cocina comunes están permitidas; las instrucciones para sintetizar compuestos peligrosos, no". La constitución especifica ambos extremos del espectro, y el clasificador se entrena para operar en esa frontera.
Lo que no son: una solución de seguridad completa. Los constitutional classifiers apuntan a categorías específicas de daño definidas en el momento del entrenamiento. No abordan la inyección de prompt desde herramientas externas, la exfiltración de datos a través de salidas del modelo ni el rango completo de patrones de abuso catalogados en el OWASP LLM Top 10. Tampoco se aplican a versiones de Claude ajustadas o autoalojadas, a menos que esos despliegues incluyan explícitamente los clasificadores.
Cómo Funcionan los Constitutional Classifiers: La Arquitectura
Paso 1: Creación de la constitución
Anthropic define una lista escalonada de categorías de contenido. Cada entrada especifica qué está permitido y qué está prohibido, con suficiente especificidad para generar ejemplos de entrenamiento inequívocos. La constitución puede actualizarse cuando emergen nuevos vectores de ataque, lo que significa que los clasificadores están diseñados para mejora iterativa.
Paso 2: Generación de datos sintéticos
El propio Claude genera decenas de miles de ejemplos de prompts y completions en cada categoría. Estos ejemplos sintéticos se aumentan mediante traducción a múltiples idiomas, transformación en estilos de jailbreak conocidos (role-play, codificación con cifrado, sustitución de palabras clave) y variación estructural. Este proceso construye un corpus de entrenamiento que cubre la superficie de ataque documentada en repositorios públicos de jailbreak.
Paso 3: Entrenamiento del clasificador
Los clasificadores de entrada y salida se entrenan por separado. El clasificador de entrada detecta prompts dañinos antes de que lleguen al modelo. El clasificador de salida detecta completions dañinas antes de que lleguen al usuario. CC++ cambia este pipeline de forma significativa: en lugar de entrenar una red independiente, usa activaciones internas del modelo del propio Claude, una técnica llamada reutilización de representaciones. Una sonda ligera se ejecuta sobre esos estados internos con un coste computacional casi nulo. Si la sonda detecta algo, un clasificador ensemble más potente reevalúa antes de tomar una decisión.
Paso 4: Enrutamiento en cascada
La arquitectura CC++ es una cascada de dos etapas. La etapa uno es la sonda ligera, que procesa cada consulta con aproximadamente un 1 % de coste computacional adicional sobre Claude Opus 4.0. La etapa dos es el clasificador ensemble, que solo gestiona el subconjunto de consultas que la sonda escala. Este diseño hace que el despliegue en producción sea económicamente viable a escala, de una forma que la arquitectura v1 no permitía.
Rendimiento en Números: v1 vs CC++
Los constitutional classifiers v1, probados en Claude 3.5 Sonnet contra 10.000 ataques sintéticos, redujeron el éxito de jailbreak del 86 % al 4,4 %. En una demo adversarial en vivo realizada del 3 al 10 de febrero de 2025, 339 jailbreakers experimentados en más de 300.000 interacciones mantuvieron el sistema durante cinco días antes del primer breach. Cuatro participantes pasaron finalmente los ocho niveles del desafío, y uno logró lo que Anthropic clasificó como un jailbreak universal.
CC++ produjo un resultado sustancialmente diferente. En 1.700 horas de pruebas adversariales con 198.000 intentos de ataque, no se identificó ningún jailbreak universal. La tasa de éxito de jailbreak medida es de 0,005 por cada mil consultas. Las falsas denegaciones en contenido inocuo bajaron del incremento del 0,38 % de v1 a solo el 0,05 % tras un mes de despliegue en producción.
El coste también cambió. La reutilización de representaciones permite que una sola capa reentrenada iguale el rendimiento de un clasificador dedicado, añadiendo aproximadamente el 4 % del coste computacional de un sistema independiente comparable. Usando sondas EMA (Exponential Moving Average) como filtro de primera etapa, los investigadores de Anthropic lograron una reducción de coste de más de 10 veces frente a una arquitectura de clasificador completamente dedicada. Según su paper de 2025 sobre monitores de bajo coste, este enfoque alcanza estos resultados sin degradación medible del rendimiento en benchmarks estándar.
Cómo Comparan los Constitutional Classifiers con Alternativas
| Método de defensa | Reducción de jailbreak | Coste computacional | Cubre ataques nuevos | Mantenible |
|---|---|---|---|---|
| Constitutional classifiers (CC++) | 99,995 % de ataques probados | ~1 % de sobrecarga | Parcial (hay que actualizar la constitución) | Sí, de forma iterativa |
| Safety fine-tuning | Alto en categorías entrenadas | Significativo (coste de entrenamiento) | No | Requiere reentrenamiento |
| Hardening del system prompt | Variable | Ninguno | No | Sí, manualmente |
| Monitorización solo de salidas | Parcial | Bajo | Parcial | Sí |
| Sin defensa | 0 % | 0 % | n/a | n/a |
Técnicas de Bypass Conocidas en los Constitutional Classifiers: Lo Que Encontraron los Red Teams
El único jailbreak universal encontrado en la demo en vivo de v1 combinó codificación con cifrado y prompts de role-play. Los red teamers emplearon estas técnicas documentadas:
- Métodos de cifrado y codificación: envolviendo peticiones dañinas en Base64, ROT13 o sustituciones de caracteres personalizadas para eludir el clasificador de entrada, manteniendo el significado semántico intacto para el modelo
- System prompts de role-play: instrucciones que pedían a Claude que "actuara como" un personaje sin las directrices de seguridad habituales
- Sustitución de palabras clave: reemplazando términos de la lista de categorías prohibidas con sinónimos o palabras inventadas que el clasificador no había visto durante el entrenamiento
- Patrones de inyección de prompt: técnicas estándar de inyección alineadas con OWASP LLM01
Dos categorías persisten en CC++ según el paper de Anthropic de 2026:
| Categoría de bypass | Cómo funciona | Nivel de riesgo observado | Estado de mitigación |
|---|---|---|---|
| Ataques de reconstrucción | Contenido dañino fragmentado en múltiples consultas inocuas, ensamblado por el usuario | Alto para información dañina paso a paso | Sin solución sistemática; requiere monitorización conductual |
| Ofuscación de salida | Términos en clave, metáforas o nombres alternativos en las respuestas | Medio; requiere interpretación del usuario | Parcialmente mitigado por ajuste del clasificador de salida |
Un dato destacable: las técnicas de jailbreak que logran superar los constitutional classifiers suelen degradar la calidad del modelo. Las pruebas de red team de Anthropic encontraron que el rendimiento en GPQA Diamond bajó del 74 % al 32 % en casos donde los atacantes usaron jailbreaks complejos de múltiples pasos. Este intercambio entre coste del ataque y capacidad limita la utilidad práctica de los bypasses exitosos para la mayoría de los actores de amenaza.
El Problema de las Falsas Denegaciones
Un sistema de seguridad que bloquea todo logra una tasa de jailbreak del 0 % pero no es útil. La tasa de falsas denegaciones mide con qué frecuencia los constitutional classifiers bloquean peticiones legítimas. Esta métrica importa para los compradores empresariales porque el exceso de falsas denegaciones se traduce en frustración del usuario, adopción de IA en la sombra y pérdida de productividad.
En las pruebas v1 con 5.000 conversaciones, las falsas denegaciones aumentaron un 0,38 %, no significativo estadísticamente pero visible en casos extremos relacionados con consultas médicas, legales y de investigación de seguridad. CC++ redujo esto al 0,05 % tras un mes de despliegue en producción, una mejora del 87 %. La mejora proviene de una mejor calibración del umbral de la sonda y de una representación más diversa de consultas profesionales legítimas en los datos de entrenamiento.
Para despliegues empresariales, la implicación práctica es que los constitutional classifiers han alcanzado un punto donde las tasas de falsas denegaciones son manejables, pero los equipos de seguridad deben documentar los casos extremos específicos de su contexto de uso, especialmente para despliegues en entornos de salud, legal o investigación de seguridad.
Seguridad y Gobernanza: Modelo de Riesgo Empresarial para Constitutional Classifiers
Los constitutional classifiers abordan capas específicas del stack de seguridad de IA, pero la superficie de riesgo empresarial es más amplia. Según la investigación de IA adversarial de Gray Swan, la superficie de ataque residual tras el despliegue de constitutional classifiers cubre la manipulación multi-turno, el abuso de herramientas a través de pipelines agentes y la exfiltración de datos a través de salidas aparentemente inocuas.
El OWASP LLM Top 10 2025 identifica tres riesgos que los constitutional classifiers abordan directamente (LLM01 inyección de prompt, LLM02 manejo inseguro de salidas, LLM05 manejo inadecuado de salidas) y tres que no abordan (LLM03 envenenamiento de datos de entrenamiento, LLM06 agencia excesiva, LLM08 debilidades en vectores y embeddings). El Hype Cycle de Gartner 2026 para seguridad de IA señala que las defensas de una sola capa siguen siendo insuficientes para despliegues de agentes de IA en producción, y recomienda arquitecturas de defensa en profundidad que combinen filtrado a nivel de clasificador con monitorización conductual en tiempo de ejecución.
Aquí es donde Agent Gateway (TrustGate) y Agent Runtime Security (TrustGuard) amplían lo que cubren los constitutional classifiers. TrustGate intercepta cada petición y respuesta en la capa de gateway, aplicando reglas de política que complementan la salida probabilística del clasificador, incluyendo limitación de velocidad, redacción de PII y gobernanza de llamadas a herramientas. TrustGuard añade monitorización conductual continua a través de sesiones multi-turno de agentes, detectando patrones de ataque de reconstrucción y ofuscación de salida que abarcan múltiples interacciones. Estas dos capas abordan las categorías de ataque que permanecen activas tras el despliegue de constitutional classifiers: las que operan por debajo del nivel de consulta o a través de sesiones.
Para las empresas que adquieren Claude a través de la API, la arquitectura de seguridad debe tratar los constitutional classifiers como la línea base a nivel de modelo y añadir controles de red y nivel de sesión por separado. Los constitutional classifiers no pueden ser auditados ni ajustados por los clientes de API. Son la capa de Anthropic, no de la empresa.
Cómo Auditar los Constitutional Classifiers en tu Despliegue
Una auditoría de cobertura de constitutional classifiers no requiere intentar eludir el clasificador. Requiere confirmar que tu system prompt, interfaz de usuario e integración de herramientas no crean las condiciones para las categorías de bypass documentadas.
| Área de auditoría | Qué comprobar | Prioridad |
|---|---|---|
| Instrucciones de role-play en el system prompt | ¿Contiene tu prompt instrucciones de "actúa como" o de persona que puedan deshabilitar el marco de seguridad? | Alta |
| Salidas de llamadas a herramientas | ¿Las respuestas de herramientas (ejecución de código, navegación web, recuperación) se devuelven al modelo sin un canal cubierto por el clasificador? | Alta |
| Estructura de sesión multi-turno | ¿Tus sesiones permiten ataques de reconstrucción entre múltiples consultas sin detección de patrones? | Alta |
| Manejo de idiomas y codificación | ¿Tu aplicación acepta entradas en idiomas no ingleses o codificadas sin normalización? | Media |
| Registro de falsas denegaciones | ¿Estás rastreando las denegaciones en producción para identificar patrones en casos de uso legítimos que se estén bloqueando? | Media |
| Alcance de la constitución | ¿La constitución pública de Anthropic cubre las categorías de riesgo específicas de tu industria (sanidad, finanzas, legal)? | Media |
| Despliegue de clasificador personalizado | Si tienes acceso a constitutional classifiers a través de un nivel de API, ¿estás probando tus actualizaciones de constitución personalizadas? | Baja (si aplica) |
¿Qué Plataforma de IA Deberías Elegir?
Los constitutional classifiers son una implementación propietaria de Anthropic. La pila de seguridad de GPT-5 de OpenAI se basa en un comportamiento de rechazo alineado con RLHF y una API de moderación separada. Los modelos Gemini de Google incluyen filtros de seguridad en múltiples niveles. Los modelos Llama de código abierto de Meta incluyen Llama Guard como capa de clasificador opcional.
Para la selección empresarial, la pregunta clave es si el sistema de seguridad es auditable y configurable. Los constitutional classifiers no son configurables a través de la API estándar de Claude, lo que significa que los clientes de API heredan los valores predeterminados de Anthropic sin la posibilidad de modificar la constitución para su contexto específico. Las empresas con requisitos de cumplimiento especializados, especialmente en industrias reguladas, deben evaluar si esta restricción es aceptable o si es necesaria una plataforma con controles de seguridad configurables.
Conclusión
Los constitutional classifiers representan la defensa contra jailbreaks más sistemáticamente probada desplegada actualmente en un LLM comercial. CC++ demuestra que 0,005 jailbreaks por cada mil consultas es alcanzable con aproximadamente un 1 % de sobrecarga computacional, y tasas de falsas denegaciones por debajo del 0,1 %. Para las empresas que usan Claude, la capa de clasificador está activa y es significativa. Sin embargo, los constitutional classifiers no cubren la superficie completa de seguridad de IA empresarial: los ataques de reconstrucción, el abuso de herramientas en pipelines agentes y los patrones conductuales multi-sesión requieren controles adicionales. Una arquitectura en capas que trate los constitutional classifiers como la línea base del modelo y añada monitorización a nivel de tiempo de ejecución y gateway por encima es el marco correcto para despliegues en producción.
Asegura tu Despliegue de Claude en Producción con NeuralTrust
Los constitutional classifiers cubren la capa del modelo. NeuralTrust asegura todo lo que está por encima y alrededor: enrutamiento de peticiones, gobernanza de llamadas a herramientas, monitorización de sesiones y pruebas de red team diseñadas para el contexto específico de tu despliegue.
Comparativas relacionadas
- Claude Opus 5.5 Enterprise: Capacidades, Precios y Seguridad
- GPT-6 Astra: Implicaciones de Seguridad para CISOs
Preguntas frecuentes sobre constitutional classifiers
1. ¿Qué son los constitutional classifiers en términos sencillos?
Los constitutional classifiers son filtros entrenados con IA que se sitúan delante y detrás de un modelo de lenguaje. Comprueban si una petición o respuesta se encuentra dentro de un conjunto definido de comportamientos aceptables (la "constitución") antes de dejarla pasar. El clasificador se entrena con ejemplos sintéticos de contenido permitido y prohibido, no con reglas codificadas a mano.
2. ¿Los constitutional classifiers previenen todos los jailbreaks?
No. Reducen significativamente las tasas de éxito de jailbreak, del 86 % en un modelo sin protección a 0,005 por cada mil consultas con CC++. Dos categorías de ataque siguen siendo viables: los ataques de reconstrucción, donde el contenido dañino se fragmenta en consultas inocuas, y la ofuscación de salida mediante términos en clave o metáforas. Ningún sistema de seguridad elimina los jailbreaks por completo.
3. ¿Cuál es la diferencia entre los constitutional classifiers v1 y CC++?
CC++ usa activaciones internas del modelo en lugar de una red clasificadora separada, reduciendo la sobrecarga computacional del 23,7 % (v1) a aproximadamente el 1 % en Claude Opus 4.0, y recortando las falsas denegaciones de un incremento del 0,38 % al 0,05 %. La tasa de éxito de jailbreak también bajó del 4,4 % a 0,005 por cada mil consultas.
4. ¿Pueden los clientes empresariales de la API configurar los constitutional classifiers?
No a través de la API estándar de Claude. Los constitutional classifiers los mantiene Anthropic y se aplican a todas las peticiones de la API de Claude por defecto. La constitución no está expuesta para personalización empresarial en los niveles estándar de API. Las empresas con necesidades específicas de cumplimiento deben verificar con Anthropic si el acceso constitucional personalizado está disponible bajo acuerdos empresariales.
5. ¿Cómo se relacionan los constitutional classifiers con los riesgos de seguridad OWASP LLM?
Abordan directamente LLM01 (inyección de prompt), LLM02 (manejo inseguro de salidas) y LLM05 (manejo inadecuado de salidas). No abordan LLM03, LLM06 ni LLM08. Una arquitectura de seguridad empresarial completa requiere controles más allá del filtrado a nivel de clasificador.
6. ¿Qué ocurre cuando un constitutional classifier detecta una petición?
La petición se bloquea antes de que llegue al modelo de lenguaje (clasificador de entrada) o antes de que la respuesta llegue al usuario (clasificador de salida). Claude devuelve un mensaje de rechazo. El usuario no ve la decisión interna del clasificador ni qué regla se activó.
7. ¿Cómo deben las empresas probar la cobertura de los constitutional classifiers en su despliegue?
Las pruebas no requieren intentar eludir el clasificador. Requieren auditar tu system prompt en busca de instrucciones de persona, tu pipeline de llamadas a herramientas en busca de canales no monitorizados, y tu estructura de sesión en busca de patrones que puedan permitir ataques de reconstrucción. AI Red Teaming (TrustTest) de NeuralTrust proporciona pruebas adversariales estructuradas en el contexto específico de tu despliegue, cubriendo las categorías de bypass que sobreviven al despliegue de constitutional classifiers.
Acerca del autor
Roger Howroyd es Head of Global SEO and AI en NeuralTrust, donde lidera la estrategia de búsqueda de la empresa en SEO, AEO, GEO y optimización para LLM. Está especializado en búsqueda potenciada por IA, estrategia de contenido y SEM. Conéctate en LinkedIn.
NeuralTrust es la plataforma líder para asegurar y escalar agentes de IA. Nombrada Pioneer en el Gartner Emerging Market Quadrant for AI Application Security 2026, reconocida en cuatro informes Gartner Hype Cycle en 2026, y destacada en el Gartner Market Guide for Guardian Agents 2026, el Gartner Market Guide for AI Gateways 2025 y el KuppingerCole Leadership Compass for Generative AI Defense 2025. Sede central en Barcelona, con oficinas en Londres y Nueva York. Certificada ISO 27001.
)
)
)