El red teaming continuo se perfila como una práctica necesaria para las empresas que utilizan modelos, asistentes o agentes de inteligencia artificial. Check Point propone sustituir las revisiones aisladas por un ciclo permanente de pruebas controladas, corrección y monitorización, ya que los riesgos pueden cambiar al actualizar el modelo, modificar las instrucciones o ampliar el acceso a datos y herramientas.
El red teaming continuo responde a sistemas que cambian
Una prueba de seguridad realizada antes de poner en funcionamiento una aplicación de inteligencia artificial no garantiza que el sistema mantenga el mismo nivel de protección durante toda su vida útil.
Los modelos, asistentes y agentes empresariales evolucionan. Una organización puede cambiar el proveedor tecnológico, actualizar la versión del modelo, modificar el prompt del sistema, incorporar nuevas fuentes documentales o conectar la aplicación con herramientas adicionales.
Cada cambio puede alterar el comportamiento de la solución y abrir vías de ataque que no existían durante la evaluación inicial. También pueden aparecer regresiones, es decir, fallos que vuelven a producirse después de una actualización pese a haber sido corregidos anteriormente.
Check Point plantea por este motivo un enfoque de red teaming continuo. Consiste en someter periódicamente los sistemas de IA a ataques simulados y escenarios de uso indebido para detectar vulnerabilidades antes de que puedan ser aprovechadas en un entorno real.
La compañía recomienda realizar pruebas durante el desarrollo, validar las aplicaciones antes de su puesta en producción y repetir las evaluaciones después de introducir modificaciones en los modelos, las instrucciones, las configuraciones o las capacidades disponibles.
De la identificación del riesgo a una nueva prueba
El proceso comienza con la identificación de los activos que deben protegerse. La empresa necesita conocer qué modelos utiliza, qué información procesan, qué aplicaciones están conectadas y qué acciones puede ejecutar cada sistema.
A partir de ese inventario se definen los posibles escenarios de ataque. Entre ellos pueden encontrarse la manipulación de las instrucciones, el acceso indebido a información sensible, la generación de respuestas contrarias a las políticas internas o la utilización de herramientas conectadas para realizar acciones no autorizadas.
Las pruebas deben reproducir estas situaciones de forma controlada. Después, la organización clasifica los fallos según su gravedad, corrige las vulnerabilidades y comprueba si las medidas adoptadas funcionan.
El ciclo no concluye con la primera corrección. Las pruebas deben repetirse para verificar que el problema se ha resuelto y que la modificación no ha generado nuevas debilidades en otra parte de la aplicación.
Este procedimiento permite pasar de una auditoría entendida como una fotografía puntual a una supervisión vinculada a la evolución real del sistema.
Cada aplicación necesita medidas diferentes
No todas las herramientas de inteligencia artificial representan el mismo nivel de riesgo. Un asistente interno que resume documentos públicos no requiere las mismas medidas que un agente con acceso a datos de clientes, facturación, sistemas de pago o correo electrónico.
La evaluación debe considerar qué información puede consultar la aplicación, qué operaciones puede realizar y qué consecuencias tendría un funcionamiento incorrecto.
Un sistema que únicamente genera borradores para su revisión tiene un margen de actuación limitado. El riesgo aumenta cuando el agente puede enviar mensajes, modificar registros, realizar consultas en bases de datos o ejecutar procesos sin una validación humana previa.
OWASP identifica la agencia excesiva como uno de los riesgos de las aplicaciones basadas en modelos de lenguaje. Este problema aparece cuando un sistema dispone de demasiadas funciones, permisos o autonomía y puede realizar acciones perjudiciales a partir de instrucciones manipuladas, ambiguas o incorrectas.
La empresa debe aplicar el principio de mínimo privilegio: cada aplicación solo debería tener acceso a los datos y herramientas imprescindibles para cumplir su función. Los permisos deben revisarse cuando cambien sus capacidades o responsabilidades.
Las pruebas deben incluir ataques propios de la IA
Las evaluaciones tradicionales de ciberseguridad continúan siendo necesarias para comprobar la protección de redes, dispositivos, aplicaciones, interfaces y bases de datos. Sin embargo, pueden no detectar fallos específicos de los sistemas generativos.
El red teaming de inteligencia artificial analiza riesgos como las inyecciones de prompt, los intentos de eludir las restricciones, la exposición de información sensible, el uso inseguro de herramientas y la manipulación de los flujos de trabajo de los agentes.
Una inyección de prompt se produce cuando una entrada altera de forma no prevista el comportamiento o la respuesta de un modelo. La instrucción maliciosa puede introducirse directamente mediante una conversación o aparecer dentro de un documento, una página web o una fuente externa procesada por el sistema.
Las pruebas también deben comprobar qué ocurre cuando la información recibida es contradictoria, incompleta o deliberadamente engañosa. El objetivo es conocer cómo responde el sistema bajo presión y qué barreras impiden que una respuesta incorrecta se convierta en una acción real.
El red teaming no sustituye los controles de seguridad
El red teaming continuo no reemplaza los controles de acceso, la protección de datos, la gestión de identidades, el cifrado ni los procedimientos de respuesta ante incidentes.
Las empresas deben registrar las acciones realizadas por los agentes, conservar evidencias suficientes para investigar comportamientos anómalos y establecer alertas cuando se produzcan operaciones fuera de los límites previstos.
También resulta necesario disponer de mecanismos para detener el sistema, revocar sus permisos y recuperar la actividad cuando se detecte un incidente. En los procesos de mayor riesgo, determinadas acciones deberían requerir la autorización de una persona antes de ejecutarse.
El perfil de gestión de riesgos para inteligencia artificial generativa de NIST incluye los ejercicios adversariales y el red teaming entre las prácticas destinadas a identificar fallos imprevistos. También plantea que la evaluación y la gestión del riesgo se mantengan durante el ciclo de vida del sistema, en lugar de limitarse al momento anterior al despliegue.
Cómo puede empezar una pyme
Una pyme puede comenzar elaborando un inventario de sus herramientas de inteligencia artificial. Este registro debe indicar para qué se utiliza cada solución, qué información procesa, quién puede acceder a ella y si está conectada con otros sistemas.
El siguiente paso consiste en clasificar las aplicaciones según su riesgo. Las herramientas con acceso a datos personales, información financiera, comunicaciones internas o capacidad para ejecutar acciones deberían recibir una atención prioritaria.
La empresa también necesita definir cuándo repetirá las pruebas. Además de establecer revisiones periódicas, conviene realizar una nueva evaluación cuando se cambie el modelo, el prompt principal, las fuentes de información, las integraciones o los permisos.
Cada vulnerabilidad detectada debe quedar documentada junto con su gravedad, la medida correctora, la persona responsable y el resultado de la comprobación posterior.
El objetivo no es declarar que una aplicación será segura para siempre. La finalidad es reducir la probabilidad y el impacto de los incidentes, detectar los fallos con mayor rapidez y mantener las defensas alineadas con los cambios del sistema.
