Contexto técnico: veo en AISVS la capa faltante de la arquitectura de IA
He analizado de cerca OWASP AISVS e inmediatamente reconocí una lógica familiar: es un intento de dar a las aplicaciones de IA el mismo estándar claro de verificación que ASVS le dio en su momento al desarrollo web. La fuente aquí es directa y sólida: el proyecto oficial de OWASP y el repositorio de AISVS en GitHub. A partir de marzo de 2026, el estándar aún no es definitivo: el proyecto se encuentra en la Fase 2, donde se están formulando los requisitos.
Para mí, esto no es una desventaja, sino una señal clave. El mercado por fin deja de debatir la seguridad de la IA generativa de forma abstracta y pasa a criterios verificables: qué probar exactamente, dónde colocar los controles y cómo registrar la madurez del sistema. Llevo tiempo diciendo a mis clientes que sin un marco de este tipo, la adopción de inteligencia artificial en el perímetro corporativo se estancaría entre el entusiasmo del negocio y la cautela de seguridad de la información (CISO).
A nivel de contenido, AISVS ya se ve muy robusto. Veo 13 categorías que cubren no solo lo habitual, como el control de acceso, el registro de logs y la seguridad de implementación, sino también áreas que los ciclos de vida de desarrollo seguro (SDLC) clásicos casi nunca detectan: envenenamiento de datos (data poisoning), manipulación de modelos, la seguridad de los embeddings y bases de datos vectoriales, el control de acciones de agentes, la robustez ante adversarios y la supervisión humana.
Es especialmente revelador que OWASP no se haya limitado únicamente a la seguridad de los prompts de los LLM. Considero que esta es una decisión madura: los riesgos de la IA corporativa no residen solo en las inyecciones de prompts, sino en toda la cadena, desde el origen de los datos y los modelos hasta la orquestación de agentes y los permisos para realizar acciones externas.
Impacto en el negocio y la automatización: yo ya estaría cambiando los requisitos para proyectos de IA
Desde un punto de vista práctico, AISVS no cambia las presentaciones, sino las decisiones arquitectónicas. Si una empresa está creando automatización con IA para soporte, ventas, compras, compliance o escenarios de copilot internos, ya no basta con decir: «tenemos un modelo y barandillas (guardrails)». Ahora existe un lenguaje para formalizar los requisitos entre negocio, seguridad, desarrollo y los proveedores externos.
Las empresas ganadoras serán aquellas que ya están construyendo su arquitectura de IA a través de procesos definidos: inventario de sistemas de IA, control de versiones de modelos, políticas de acceso, logging, pruebas de red-team, observabilidad y procedimientos de human-in-the-loop (supervisión humana). Perderán los equipos que hayan montado su producción usando un stack rápido de APIs, plugins y una base de datos vectorial sin un modelo formal de amenazas.
Según mi experiencia en Nahornyi AI Lab, el punto más débil casi nunca está en el modelo en sí, sino en las intersecciones entre componentes. Ahí es donde surgen las fugas de datos (retrieval leaks), las acciones incontroladas de los agentes, los errores en la asignación de permisos y los cambios de comportamiento «silenciosos» después de actualizar un modelo. Es exactamente por esto que integrar IA en un entorno corporativo no solo requiere desarrolladores, sino un equipo que sepa fusionar la seguridad, la automatización y la arquitectura de soluciones de IA en un sistema unificado.
Recomendaría a las empresas que empiecen a utilizar AISVS desde ya como un checklist previo al estándar. No esperen al lanzamiento de la versión 1.0; adóptenlo como una base de trabajo para auditorías: qué tenemos actualmente, qué categorías están cubiertas, dónde falta un propietario (owner) y qué comprobaciones se pueden automatizar en CI/CD y en la observabilidad.
Visión estratégica: el estándar empuja al mercado desde las demos hacia los sistemas de IA gestionables
Creo que el principal impacto de AISVS no será un simple check de compliance. Cambiará la propia economía de los proyectos de IA. Cuando una empresa cuenta con un marco de verificación, le resulta más fácil calcular riesgos, justificar presupuestos, elegir proveedores y exigir una seguridad demostrable en lugar de meras promesas de marketing.
También hay un cambio menos obvio. Espero que en 2026 los ganadores no sean solo los que hicieron un piloto más rápido, sino aquellos que integraron tempranamente controles de integridad de modelos, seguridad en la cadena de suministro (supply chain) y gestión del cambio de comportamiento en el desarrollo de soluciones de IA. Para los sistemas basados en agentes, esto será absolutamente obligatorio, porque una acción autónoma sin una verificación rigurosa pronto se considerará una negligencia arquitectónica.
En los proyectos de Nahornyi AI Lab ya observo este patrón: el negocio quiere automatización mediante IA, pero la solución solo escala cuando diseñamos desde el principio políticas de acceso, entornos seguros (sandbox) para acciones, rastreo de las decisiones del modelo, control sobre las fuentes de datos y puntos de parada manual. Lo bueno de AISVS es que otorga a este enfoque un formato estándar en la industria. Ayuda a traducir la «intuición de los expertos» en un estándar repetible.
Este análisis fue preparado por Vadym Nahornyi, experto principal en Nahornyi AI Lab sobre IA, automatización con IA y arquitectura corporativa de sistemas de IA. Te invito a discutir tu proyecto específico con Nahornyi AI Lab: auditaré tu solución de IA actual, te ayudaré a construir una arquitectura de IA segura y convertiré los requisitos de seguridad en un sistema operativo, no en un documento formal.