En resumen: El red-teaming automatizado proporciona una forma escalable de encontrar los modos de fallo naturales y no provocados de un modelo de IA, no solo los forzados. Este cambio de «jailbreaking» a descubrir riesgos inherentes se está convirtiendo en un componente no negociable de la seguridad de la IA empresarial.

En qué consiste

Los líderes empresariales están, con razón, preocupados por la seguridad y fiabilidad de los Modelos Lingüísticos Grandes (LLM). El método principal para probar estos modelos ha sido el «red-teaming», una práctica tomada de la ciberseguridad donde los expertos intentan provocar manualmente que un modelo genere resultados dañinos, sesgados o indeseables. Aunque valioso, este enfoque manual es lento, costoso y a menudo está limitado por la creatividad de los probadores humanos. Tiende a centrarse en el «jailbreaking», es decir, en engañar a un modelo para que viole sus políticas de seguridad mediante prompts ingeniosos y adversariales.

Un nuevo enfoque, que vemos como una evolución crítica, es el red-teaming automatizado. Esto implica el uso de sistemas de IA para sondear sistemática y eficientemente otros modelos de IA en busca de vulnerabilidades. Un artículo de investigación reciente presenta un método potente en este campo llamado BLOOM-WILT: on-policy examples of any LLM behaviour, from a one-line description and logits alone. Esta técnica puede provocar comportamientos raros y potencialmente dañinos de un LLM utilizando solo una descripción de alto nivel del comportamiento objetivo (por ejemplo, «expresar estereotipos dañinos») y el acceso a las probabilidades de salida del modelo. Representa un cambio radical en nuestra capacidad para auditar los modelos en busca de riesgos que podrían exhibir espontáneamente en condiciones reales, no solo cuando están bajo un ataque deliberado.

Cómo funciona

La distinción clave que hace que métodos como BLOOM-WILT sean tan potentes es la diferencia entre encontrar fallos «off-policy» y «on-policy». Pensemos en ello como si estuviéramos probando un coche. El jailbreaking es una prueba «off-policy»; equivale a estrellar el coche contra un muro para ver si se despliegan los airbags. Es una prueba de estrés válida, pero no nos dice cómo se comportará el coche en condiciones normales de conducción. Un fallo «on-policy» es un defecto que el coche podría exhibir durante el uso diario, como un sensor de freno defectuoso. Estos suelen ser más raros y difíciles de encontrar, pero representan una amenaza más realista para el usuario.

El red-teaming tradicional a menudo encuentra fallos off-policy. En contraste, los sistemas de red-teaming automatizado como BLOOM-WILT están diseñados para encontrar fallos on-policy. No se limitan a forzar el modelo con prompts adversariales. En su lugar, analizan los logits del modelo —las puntuaciones de probabilidad brutas que el modelo asigna a las posibles siguientes palabras— para entender su «pensamiento» interno. Al observar estas probabilidades, el sistema de auditoría puede guiar suavemente al modelo por rutas conversacionales que podría tomar de forma natural, llevándolo finalmente a expresar un comportamiento emergente e indeseable. Se trata menos de romper las reglas del modelo y más de descubrir las reglas indeseables que ha aprendido por sí mismo.

Este método es mucho más escalable y completo que las pruebas manuales. Puede ejecutarse continuamente, probando miles de posibles modos de fallo en las actualizaciones del modelo. A medida que las organizaciones dependen cada vez más de la IA para funciones críticas, comprender estos riesgos de comportamiento inherentes es fundamental para construir sistemas fiables, una piedra angular de lo que muchos expertos llaman desarrollo responsable de la IA.

Por qué es importante para la empresa

Para los CIO, CTO y CDO de las empresas, el auge del red-teaming automatizado convierte la seguridad de los LLM de un arte cualitativo a una ciencia cuantitativa. Cambia las reglas del juego, pasando de simplemente prevenir el uso malicioso a identificar y mitigar proactivamente el riesgo inherente del modelo. Esto tiene implicaciones profundas para el gobierno, el cumplimiento normativo y la reputación de la marca. Un LLM que genera espontáneamente recomendaciones de contratación sesgadas, filtra patrones de datos sensibles u ofrece consejos financieros erróneos supone una amenaza directa para el negocio, incluso si nadie intenta activamente hacer un mal uso de él.

Estos fallos «on-policy» son las incógnitas desconocidas que quitan el sueño a los responsables de riesgos. Son propiedades emergentes del entrenamiento y el ajuste fino del modelo que son imposibles de predecir solo a partir de la documentación. Al sacar a la luz sistemáticamente estos comportamientos antes de que un modelo se despliegue a clientes o empleados, las organizaciones pueden tomar decisiones informadas. Esto podría implicar añadir nuevas barreras de protección, ajustar aún más el modelo para corregir el comportamiento o seleccionar un modelo diferente por completo. Esta capacidad ya no es un «extra» para los desarrolladores de modelos; se está convirtiendo en un componente esencial de cualquier marco de Gobierno y Riesgo de la IA de una empresa.

Cómo hacerlo bien

Integrar el red-teaming automatizado requiere un cambio en el ciclo de vida de la IA en la empresa. No puede ser una ocurrencia tardía que se realiza justo antes del lanzamiento. En su lugar, debe convertirse en una parte continua y automatizada del pipeline de MLOps o LLMOps, ejecutándose cada vez que un modelo se actualiza o se ajusta con nuevos datos de la empresa. Esto se debe a que el ajuste fino (fine-tuning), el mismo proceso utilizado para hacer que un modelo general sea útil para un contexto empresarial específico, puede introducir modos de fallo nuevos e inesperados.

Una implementación competente implica más que simplemente ejecutar una herramienta. Comienza con una definición estratégica de comportamientos inaceptables adaptados a su sector y casos de uso. Para un banco, esto podría incluir la generación de texto que pudiera interpretarse como asesoramiento de inversión sin licencia. Para un proveedor de atención médica, podría ser expresar opiniones de diagnóstico sin las debidas advertencias. Una vez que se definen estos riesgos, las herramientas automatizadas pueden configurarse para buscarlos específicamente. A medida que las organizaciones maduren, necesitarán decidir si desarrollar esta capacidad internamente, lo que requiere talento especializado, o adquirirla de una nueva generación de proveedores de seguridad de la IA. Nuestra orientación en la Guía de Adopción de IA para Empresas 2025 enfatiza que exigir este nivel de pruebas a sus proveedores de modelos y plataformas es un primer paso fundamental.

Preguntas frecuentes

P: ¿El red-teaming automatizado es solo para creadores de modelos como OpenAI, o lo necesitamos para los modelos que solo ajustamos (fine-tuning)?

R: Es esencial para ambos. Cuando ajustas un modelo con tus datos propietarios o lo usas en un sistema de Generación Aumentada por Recuperación (RAG), estás alterando su comportamiento. El red-teaming automatizado es crucial para descubrir consecuencias no deseadas y nuevas vulnerabilidades introducidas por tus datos y caso de uso específicos.

P: ¿En qué se diferencia esto de nuestras pruebas de ciberseguridad existentes?

R: La ciberseguridad generalmente prueba la infraestructura —los servidores, las API y los pipelines de datos— en busca de vulnerabilidades a ataques externos. El red-teaming automatizado prueba la integridad conductual del modelo de IA. No busca una inyección de código; busca la propensión del modelo a generar contenido dañino, sesgado o fácticamente incorrecto en condiciones normales de funcionamiento.

P: ¿Podemos comprar esto como un servicio o necesitamos crear un equipo interno?

R: El mercado de herramientas de seguridad de la IA aún está emergiendo, pero esperamos que el «red-teaming como servicio» se convierta en una oferta estándar. Por ahora, un enfoque híbrido es lo mejor: desarrollar experiencia interna en la definición de riesgos específicos del negocio mientras se exige transparencia e informes de pruebas robustos a los proveedores de modelos y plataformas.

P: ¿Cuál es el primer paso práctico que nuestra organización puede dar?

R: Comience por crear una taxonomía de riesgos específica para sus casos de uso de IA planificados. Identifique los 5-10 principales resultados dañinos que necesita prevenir (por ejemplo, revelar información de identificación personal, dar consejos legales, generar lenguaje tóxico). Utilice esta taxonomía para evaluar a los proveedores de modelos y para diseñar sus propios protocolos internos de prueba y seguimiento.

P: ¿Este proceso garantiza que un modelo es 100 % seguro?

R: No, y es importante ver la seguridad como un proceso de reducción continua del riesgo, no como una garantía única de perfección. El red-teaming automatizado amplía drásticamente el alcance y la escala de las pruebas, permitiéndole encontrar y corregir fallos que de otro modo pasaría por alto. Hace que los modelos sean significativamente más seguros, pero la supervisión humana y un seguimiento robusto en producción siguen siendo fundamentales.

Conclusión

El paso del jailbreaking manual y adversarial al red-teaming escalable y automatizado marca una maduración significativa en el campo de la seguridad de la IA. Proporciona a los líderes empresariales las herramientas para mirar más allá de las capacidades declaradas de un modelo y sondear sus comportamientos inherentes y emergentes. Creemos que este enfoque proactivo y basado en la evidencia para descubrir fallos on-policy se convertirá en el estándar de referencia para el despliegue responsable de la IA. Ya no basta con esperar que un modelo se comporte como se espera; debemos contar con los sistemas para verificarlo. En Thinkia, ayudamos a las organizaciones a construir los marcos de gobierno y la infraestructura técnica para integrar esta capa esencial de garantía en su estrategia de IA, convirtiendo el riesgo en un componente gestionado y medible de la innovación.