Anthropic libera Bloom y Petri para auditar el comportamiento de modelos de IA

Anthropic ha liberado Bloom, un framework open source para evaluaciones automáticas del comportamiento de modelos frontera, y Petri, una herramienta complementaria centrada en auditar interacciones de riesgo. El código de Bloom se publica bajo licencia MIT y la compañía lo acompaña de un informe técnico que explica cómo genera, ejecuta y puntúa sus conjuntos de evaluación. Para quien integra modelos en flujos de trabajo reales, el valor no es un certificado de seguridad: es una forma más ordenada de comprobar si el modelo se comporta como se espera.

Un pipeline de cuatro etapas

El informe describe cuatro fases: Understanding, Ideation, Rollout y Judgment. Se parte de una configuración semilla, se generan ideas de evaluación candidatas, se ejecutan contra los modelos objetivo y se juzga el comportamiento resultante. La estructura importa porque evaluar no es lanzar cuatro prompts y leer la respuesta: hace falta definir el comportamiento de interés, escenarios repetibles, un método para ejecutarlos y criterios para interpretar los resultados.

El trabajo aplica ese esquema a 16 modelos frontera y cuatro comportamientos: sicofancia delirante, sabotaje de horizonte largo bajo instrucción, autoconservación y sesgo de autopreferencia. Reporta métricas como la tasa de elicitación —si el conjunto de pruebas consigue sacar a la luz el comportamiento que dice medir— y la diversidad del conjunto, que indica cuánta variación hay dentro de lo generado. Son métricas de evaluación, no una clasificación general de la seguridad de un modelo ni de su idoneidad para cualquier caso de uso.

Petri cubre otra parte del trabajo: la exploración en paralelo de interacciones de riesgo, como complemento a la capacidad de medición de Bloom.

Lo que no resuelve

Un resultado de benchmark no demuestra que un modelo sea seguro en producción. La evaluación solo cubre el comportamiento, la configuración, el modelo objetivo y el criterio de juicio que se probaron de verdad. Quien despliega un asistente sigue teniendo que validar sus propios prompts, herramientas, accesos a datos, rutas de escalado y salidas de cara al cliente. Bloom informa ese trabajo, no lo sustituye.

La licencia MIT es el detalle práctico que más pesa a la hora de adoptarlo: permite incorporar el código a herramientas internas o adaptarlo, sujeto a sus términos. El repositorio trae instrucciones de instalación desde GitHub con pip, uso de semillas y configuraciones, y el cableado necesario para ejecutar evaluaciones contra modelos. Eso no lo convierte en algo llave en mano. Hace falta acceso a los modelos objetivo, infraestructura para las ejecuciones, semillas que reflejen riesgos relevantes y una manera de conectar los hallazgos con el proceso de revisión que ya tenga el equipo.

Hay además un detalle de gobernanza a seguir. El repositorio de Bloom indica que tiene nueva casa y que, a partir de 2026, lo desarrolla y mantiene Meridian Labs. Quien planee construir encima debería revisar la documentación y el estado de mantenimiento actuales antes de convertirlo en dependencia a largo plazo.

Ahí está el interés real: no en la promesa de una etiqueta de seguridad, sino en poder leer el método, adaptarlo a un caso concreto y decidir con datos propios qué comportamientos son inaceptables en un flujo de trabajo determinado. El resto sigue siendo trabajo de cada equipo.