OWASP AISVS: guía del AI Security Verification Standard
Si has publicado o revisado una función de LLM, ya te has topado con el problema central: todos coinciden en que debe ser «segura», pero no hay una definición común y verificable de qué significa eso. El OWASP AI Security Verification Standard (AISVS) existe para arreglarlo, igual que el Application Security Verification Standard (ASVS) lo hizo con las aplicaciones web hace una década. Convierte «¿es segura esta app de IA?» en una lista de requisitos concretos que un ingeniero o un auditor pueden verificar de verdad. Puedes recorrer sus requisitos tú mismo con el checklist interactivo de AISVS.
Concienciación frente a verificación: dónde encaja AISVS
OWASP ya publica el Top 10 para aplicaciones de LLM, un documento de concienciación que nombra las grandes categorías de riesgo: inyección de prompts, manejo inseguro de salidas, envenenamiento de datos de entrenamiento, agencia excesiva, etc. Eso es esencial para saber qué puede salir mal, pero no te dice si una aplicación concreta tiene los controles para evitarlo. Un estándar de verificación cierra esa brecha: para cada área, indica los controles que deben estar presentes y cómo comprobarlos. AISVS es esa capa de verificación para los sistemas de IA.
Qué cubre AISVS
La superficie de ataque propia de una aplicación de IA se corresponde con dominios en torno a los que se organiza un estándar de verificación:
- Modelo: procedencia, integridad y verificación de la cadena de suministro de los modelos que despliegas.
- Datos: controles sobre los datos de entrenamiento, fine-tuning y recuperación: envenenamiento, fugas y acceso.
- Manejo de prompts: defensas contra la inyección de prompts y el contenido no confiable en el contexto.
- Acceso de herramientas y agentes: mínimo privilegio y salvaguardas para los modelos que pueden llamar a herramientas o tomar acciones (el problema de la «agencia excesiva»).
- Manejo de salidas: tratar la salida del modelo como no confiable antes de que llegue a otros sistemas o usuarios.
- Monitoreo: registro, detección y controles de abuso en torno al comportamiento de la IA.
Como el ASVS, está diseñado para aplicarse a un nivel proporcional al riesgo: una herramienta interna de bajo riesgo se mide con un listón más suave que un agente de cara al cliente con acceso a herramientas.
AISVS, ASVS y el LLM Top 10 juntos
No son competidores. La mayoría de las aplicaciones de IA son también aplicaciones web, así que verificas la superficie de ataque convencional con ASVS, la superficie específica de la IA con AISVS y usas el LLM Top 10 para asegurarte de que el equipo entiende las categorías de riesgo que esos controles abordan. Usados juntos, cubren la concienciación, la appsec convencional y la appsec específica de la IA.
Cómo ponerlo en práctica
Trata AISVS como la columna vertebral de una revisión de seguridad de IA repetible: acótalo al nivel de riesgo de la función, recorre cada dominio, confirma qué controles obligatorios existen y registra las brechas como hallazgos con responsables. Rinde más en el diseño y en la revisión previa al lanzamiento de las funciones de LLM, antes de que llegue a producción la brecha de agencia excesiva o de inyección de prompts.
Haz una primera pasada con la herramienta del checklist OWASP AISVS →, modela las amenazas de la función con el modelo de amenazas de IA y revisa el acceso de herramientas de los agentes con MCP Guard.
Preguntas frecuentes
¿Qué es AISVS? Un estándar de OWASP que expresa la seguridad de las aplicaciones de IA/LLM como requisitos concretos y verificables: un checklist comprobable, no solo una lista de concienciación.
¿En qué se diferencia del LLM Top 10? El Top 10 nombra los riesgos; AISVS indica los controles que deben estar presentes y cómo verificarlos.
¿Cómo se relaciona con ASVS? Está modelado sobre ASVS y añade la capa específica de la IA; verificas la mayoría de las apps de IA con ambos.
¿Cómo lo usan los equipos? Como un checklist de revisión acotado al riesgo, recorrido dominio por dominio, más valioso en el diseño y la revisión previa al lanzamiento.
Preguntas frecuentes
¿Qué es el OWASP AI Security Verification Standard (AISVS)?
AISVS es un estándar comunitario de OWASP que expresa la seguridad de una aplicación de IA o de LLM como un conjunto de requisitos concretos y verificables —controles que deberían estar presentes y que se pueden comprobar— en lugar de una descripción general del riesgo. Sigue el modelo del Application Security Verification Standard (ASVS) de OWASP para las aplicaciones web tradicionales, trasladado a los componentes propios de los sistemas de IA: modelos, datos de entrenamiento y de recuperación, manejo de prompts, acceso de herramientas y agentes, manejo de salidas y monitoreo.
¿En qué se diferencia AISVS del OWASP LLM Top 10?
Son complementarios. El OWASP Top 10 para aplicaciones de LLM es un documento de concienciación: nombra y explica las categorías de riesgo más importantes (inyección de prompts, manejo inseguro de salidas, agencia excesiva, etc.). Un estándar de verificación como AISVS da el siguiente paso: para cada área, indica los controles concretos que deben estar en su sitio y cómo verificarlos, para poder usarlo como checklist en una revisión de seguridad o una auditoría, no solo para concienciar.
¿Cómo se relaciona AISVS con ASVS?
AISVS está modelado sobre ASVS. El ASVS proporciona requisitos verificables para la seguridad de aplicaciones convencional (autenticación, gestión de sesiones, control de acceso, validación de entradas, etc.) y sigue siendo relevante porque la mayoría de las aplicaciones de IA son también aplicaciones web. AISVS añade encima la capa específica de la IA. En la práctica verificas un producto de LLM con ASVS por su superficie de ataque convencional y con AISVS por la específica de la IA.
¿Cómo debería usar un equipo AISVS?
Úsalo como un checklist de revisión acotado al nivel de riesgo de la aplicación: recorre cada dominio (modelo, datos, manejo de prompts, acceso de herramientas/agentes, salida, monitoreo), confirma qué controles obligatorios están presentes y registra las brechas como hallazgos con responsables. Rinde más al principio —en el diseño y la revisión previa al lanzamiento de una función de LLM— y como columna vertebral de una revisión de seguridad de IA repetible en lugar de algo puntual.