Inteligencia Artificial
¿Cómo hacer pruebas de seguridad a un sistema de inteligencia artificial?
Respuesta directa
Las pruebas de seguridad de IA evalúan, antes y después de producción, si un sistema resiste riesgos como inyección de prompts, fuga de datos, agencia excesiva o uso indebido de herramientas. Combinan revisión de diseño, evaluaciones adversarias automatizadas, red teaming con alcance autorizado y pruebas de permisos, siguiendo referencias como el OWASP GenAI Security Project. El objetivo es documentar hallazgos, priorizarlos por impacto y verificar que las mitigaciones se implementaron, no solo detectarlos.
Un sistema de inteligencia artificial que funciona bien en pruebas funcionales puede seguir siendo inseguro: responder correctamente a preguntas normales no dice nada sobre lo que hace ante una entrada diseñada para manipularlo, ni sobre qué pasa si alguien intenta usar sus permisos más allá de lo previsto. Las pruebas de seguridad de IA son el proceso que responde esas preguntas de forma sistemática, antes de exponer el sistema a usuarios reales y de manera recurrente después. Este artículo describe, en términos defensivos y sin instrucciones explotables, las clases de riesgo más relevantes, los tipos de prueba disponibles, con qué frecuencia conviene realizarlas y cómo convertir los hallazgos en mejoras concretas.
Clases de riesgo que hay que evaluar
El OWASP GenAI Security Project mantiene una lista de riesgos de aplicaciones basadas en modelos de lenguaje que sirve como referencia común en la industria. En términos generales, y sin entrar en detalles reproducibles, las categorías más relevantes para una empresa son las siguientes.
La inyección de prompts, directa (el usuario intenta manipular las instrucciones del sistema) o indirecta (la manipulación llega a través de un documento, correo o página que el sistema procesa), es uno de los riesgos más citados porque explota la dificultad de separar instrucciones de datos en un modelo de lenguaje. La fuga de datos ocurre cuando el sistema revela información sensible —propia, de clientes o de otros usuarios— a través de sus respuestas.
La agencia excesiva describe un agente al que se le otorgan más permisos o autonomía de los que su caso de uso requiere, de modo que un error o una manipulación tiene un impacto mucho mayor del necesario. El uso indebido de herramientas y los problemas de permisos ocurren cuando el sistema puede invocar una función o sistema externo sin las validaciones adecuadas. Finalmente, las entradas adversarias son insumos diseñados deliberadamente para confundir al modelo o forzar comportamientos fuera de lo previsto.
Relacionado: ¿Cómo hacer una evaluación de riesgos de inteligencia artificial?
Tipos de prueba y cuándo usar cada uno
No existe una única prueba que cubra todos los riesgos; se necesita una combinación de enfoques, cada uno con un propósito y un momento distinto dentro del ciclo de vida del sistema.
Tipos de prueba de seguridad de IA
Revisión de diseño
Análisis de la arquitectura, los permisos otorgados al agente y los flujos de datos antes de escribir una línea de código de producción. Detecta problemas estructurales —como agencia excesiva— que ninguna prueba posterior corrige de raíz.
Evaluaciones adversarias automatizadas
Conjuntos de casos de prueba, ejecutados de forma repetible, que verifican si el sistema mantiene su comportamiento esperado ante entradas diseñadas para desviarlo. Se integran en el ciclo de desarrollo, no solo antes del lanzamiento.
Red teaming con alcance autorizado
Un equipo o proveedor especializado, con reglas de compromiso claras y autorización explícita por escrito, intenta identificar debilidades del sistema en un entorno controlado, documentando hallazgos sin ejecutar acciones dañinas reales.
Pruebas de permisos
Verificación específica de que el agente o el sistema sólo puede acceder a los datos y ejecutar las acciones que su rol autoriza, incluyendo la validación de que los límites se mantienen incluso ante instrucciones que intenten expandirlos.
Relacionado: ¿Qué controles necesita un sistema de IA antes de entrar a producción?
Si quieres aplicar esto a un proceso real de tu empresa, conoce nuestro servicio de IA aplicada a la operación.
De riesgo a mitigación: una tabla de referencia
La siguiente tabla resume, de forma defensiva, qué tipo de prueba corresponde a cada clase de riesgo y qué mitigación suele acompañarla en la práctica.
| Riesgo | Tipo de prueba | Mitigación típica |
|---|---|---|
| Inyección de prompts (directa/indirecta) | Evaluaciones adversarias automatizadas, revisión de diseño | Guardrails de entrada, separación de instrucciones y datos de usuario |
| Fuga de datos | Red teaming con alcance autorizado, pruebas de permisos | Guardrails de salida, minimización de datos en el contexto del modelo |
| Agencia excesiva | Revisión de diseño, pruebas de permisos | Principio de mínimo privilegio, aprobación humana en acciones críticas |
| Uso indebido de herramientas | Red teaming con alcance autorizado | Validación estricta de parámetros y permisos por herramienta |
| Problemas de permisos | Pruebas de permisos periódicas | Revisión regular de roles y accesos, alineados al menor privilegio necesario |
| Entradas adversarias | Evaluaciones adversarias automatizadas | Guardrails de entrada y monitoreo de patrones anómalos |
Relacionado: ¿Cómo gestionar incidentes relacionados con inteligencia artificial?
Cadencia y criterios de aceptación
Las pruebas de seguridad no son un evento único antes del lanzamiento. Un sistema de IA cambia constantemente —se actualiza el modelo subyacente, se agregan herramientas, cambian los datos de contexto— y cada cambio puede introducir un riesgo nuevo. Por eso conviene definir una cadencia: evaluaciones automatizadas en cada cambio relevante, revisión de permisos de forma periódica (por ejemplo trimestral) y red teaming con alcance autorizado antes de lanzamientos mayores o al menos una vez al año para sistemas críticos.
Los criterios de aceptación deben ser explícitos antes de correr las pruebas, no definirse después según el resultado. Es razonable establecer, por ejemplo, que ningún hallazgo de severidad alta puede quedar abierto antes de producción, que los hallazgos de severidad media tienen un plazo máximo de mitigación, y que cualquier hallazgo relacionado con fuga de datos activa una revisión adicional antes de continuar.
Relacionado: ¿Cómo dar acceso seguro a un agente de IA a sistemas empresariales?
Qué hacer con los hallazgos
Un hallazgo de una prueba de seguridad no es útil hasta que se traduce en una acción verificable. Cada hallazgo debe registrarse con severidad, causa raíz probable y responsable de mitigación, y debe volver a probarse una vez implementada la corrección para confirmar que efectivamente se resolvió, no sólo que se aplicó un cambio.
Es igual de valioso registrar los hallazgos que no se van a mitigar de inmediato, junto con la justificación de esa decisión y una fecha de reevaluación. Esto evita que los riesgos aceptados se conviertan en riesgos olvidados, y da a la dirección una vista clara de qué exposición existe en un momento dado.
Checklist de un programa de pruebas de seguridad de IA
- Existe una revisión de diseño previa a producción que evalúa permisos y flujos de datos del sistema
- Hay evaluaciones adversarias automatizadas integradas en el ciclo de desarrollo, no solo antes del lanzamiento
- El red teaming se realiza con alcance y autorización explícitos por escrito, y sin ejecutar daño real
- Las pruebas de permisos se repiten de forma periódica, no solo una vez
- Existen criterios de aceptación definidos antes de correr las pruebas, con severidad y plazos claros
- Cada hallazgo se registra, se asigna a un responsable y se vuelve a probar tras mitigarse
- Los riesgos aceptados sin mitigar cuentan con justificación documentada y fecha de reevaluación
Cómo se relaciona esto con los guardrails y la gobernanza
Las pruebas de seguridad no diseñan controles, los verifican. Los guardrails —filtros de entrada y salida, permisos de herramientas, aprobación humana— son el objeto que estas pruebas ponen a prueba: un guardrail sin evaluación periódica es una suposición no confirmada, y una prueba de seguridad sin guardrails que corregir sólo produce una lista de hallazgos sin forma de cerrarlos.
A un nivel más amplio, este proceso de pruebas se apoya en el marco de gestión de riesgos que la organización haya adoptado —por ejemplo el NIST AI RMF— para decidir qué sistemas requieren evaluación más frecuente según su nivel de exposición e impacto potencial, en lugar de aplicar el mismo rigor a todos los casos de uso por igual.
Referencias y marcos de apoyo
Estas referencias documentan riesgos y buenas prácticas de la industria; no constituyen, por sí mismas, una obligación legal en México o Latinoamérica salvo que una autoridad regulatoria las incorpore explícitamente en normativa vigente.
Referencias técnicas
- OWASP GenAI Security Project
Lista de riesgos de aplicaciones LLM y buenas prácticas.
- OWASP Top 10 for LLM Applications
Los diez riesgos principales para aplicaciones basadas en LLM.
- NIST AI Risk Management Framework
Marco de gestión de riesgos de IA.
- NIST Generative AI Profile (AI 600-1)
Perfil de riesgos específicos de IA generativa.
- Microsoft Learn: Red teaming para IA generativa
Metodología de red teaming aplicada a sistemas de IA.
Preguntas frecuentes
- ¿Qué diferencia hay entre pruebas de seguridad de IA y guardrails?
- Los guardrails son controles preventivos que operan en cada interacción en tiempo real. Las pruebas de seguridad son el proceso de evaluación que verifica, de forma sistemática y periódica, si esos controles —y el sistema en general— resisten intentos de manipulación o abuso. Uno previene, el otro verifica.
- ¿Con qué frecuencia se deben hacer pruebas de seguridad a un sistema de IA?
- Las evaluaciones automatizadas deben correr con cada cambio relevante del sistema; las pruebas de permisos, de forma periódica (trimestral es un punto de partida razonable); y el red teaming con alcance autorizado, antes de lanzamientos mayores y al menos una vez al año para sistemas críticos.
- ¿Puede una empresa mediana hacer estas pruebas con su propio equipo?
- La revisión de diseño y las evaluaciones adversarias automatizadas suelen poder implementarse internamente si el equipo técnico tiene la capacidad. El red teaming con alcance autorizado normalmente se beneficia de un tercero especializado, para aportar objetividad y experiencia frente a técnicas de manipulación que evolucionan constantemente.
- ¿Qué se hace si una prueba encuentra un riesgo que no se puede mitigar de inmediato?
- Se documenta como riesgo aceptado temporalmente, con justificación explícita, severidad, responsable y una fecha de reevaluación. Esto evita que el riesgo se olvide y permite que la dirección decida con información completa si acepta esa exposición mientras se implementa la corrección definitiva.
- ¿Existe una obligación legal en México de hacer pruebas de seguridad a sistemas de IA?
- No existe, al día de hoy, una obligación legal general en México que exija pruebas de seguridad específicas para sistemas de IA; los marcos citados (NIST, OWASP) son referencias voluntarias de buenas prácticas. Las obligaciones legales aplicables dependen del sector y deben confirmarse con asesoría legal específica.