Qué es una revisión de seguridad de IA

Por Brian Tr · Actualizado el 6 de octubre de 2026

Una revisión de seguridad de IA es la verificación formal que un comprador empresarial hace del producto de IA de un proveedor antes de permitirle tocar los datos de la empresa. Empieza como una revisión normal de proveedores de software: cuestionarios, certificaciones, preguntas de arquitectura, términos contractuales. Luego agrega una segunda capa de preguntas sobre riesgos que solo existen porque el producto contiene un modelo, como la inyección de prompts, la filtración de información sensible y el software que realiza acciones en nombre de un usuario.

Para una startup de IA, esta revisión suele ser el punto en que un acuerdo que parecía seguro se frena durante semanas. También es predecible. Los marcos que usan los revisores son públicos, las preguntas se repiten de un comprador a otro y la mayor parte del trabajo consiste en tener la evidencia lista antes de que alguien la pida. Esta página explica qué es la revisión, en qué se diferencia de una revisión estándar de SaaS, los marcos reconocidos que la sustentan, las etapas por las que pasa y qué preparar.

Qué es una revisión de seguridad de IA

Una revisión de seguridad es un proceso de debida diligencia del lado del comprador. El equipo de seguridad, riesgos o TI del comprador decide si el producto de un proveedor puede usarse con los datos del comprador y en qué condiciones. El resultado suele ser una aprobación, una aprobación condicionada a correcciones obligatorias o un rechazo.

Dos cosas la distinguen de una conversación de ventas general. La audiencia es un responsable de riesgos, no la persona que quiere el producto. Y la evidencia tiene que quedar por escrito, porque el revisor tendrá que defender la decisión ante otra persona más adelante.

En la venta de IA, la revisión rara vez va sola. Avanza en paralelo con la revisión legal de los términos sobre datos y, cada vez más, con un análisis aparte de gobernanza de la IA. Consulte el comité de compra de IA para saber quién está del otro lado de la mesa y por qué seguridad suele tener poder de veto.

En qué se diferencia de una revisión estándar de SaaS

Una revisión de seguridad estándar de SaaS pregunta si el proveedor protege los datos y opera con disciplina. Una revisión de IA pregunta todo eso y además si la capa de modelo introduce nuevas formas de perder datos, de ser manipulado o de causar daño. La base se mantiene; la capa de IA se suma.

La fila de comportamiento es la que los fundadores subestiman. El software convencional es determinista, así que un revisor puede razonar a partir del diseño. Los resultados de un modelo no son fijos, así que el revisor pide en cambio evidencia de pruebas. Eso conecta con el trabajo de evaluación descrito en por qué las demos importan más en los productos de IA.

La base: cuestionarios y certificaciones

Antes de cualquier pregunta específica de IA, la mayoría de las revisiones verifica los mismos fundamentos.

Cuestionarios de seguridad. Los compradores suelen enviar un cuestionario estandarizado o uno propio. Dos formatos estandarizados muy usados son el cuestionario SIG (Standardized Information Gathering) de Shared Assessments y el CAIQ de la Cloud Security Alliance. La página de la Cloud Controls Matrix de la CSA describe la CCM como un metamarco de controles de seguridad específicos de la nube, mapeados a los estándares principales, y distribuye el CAIQ junto con ella, incluida una versión STAR Level 1 para enviar al CSA STAR Registry. Responder el mismo cuestionario una y otra vez es un desperdicio, así que una startup con un CAIQ o un SIG completo y actualizado puede reutilizar la mayor parte.

SOC 2. Un informe SOC 2 es un examen independiente de los controles de una organización de servicios. La página del conjunto de servicios SOC del AICPA enumera las cinco áreas con las que se relacionan estos servicios: seguridad, disponibilidad, integridad del procesamiento, confidencialidad y privacidad. Un informe que cubre un periodo determinado es el documento individual que más piden los revisores empresariales.

ISO/IEC 27001. El estándar internacional de gestión de la seguridad de la información es la otra solicitud habitual, sobre todo de compradores fuera de EE. UU.

Un SOC 2 o un ISO 27001 no responde las preguntas de IA. Le dice al revisor que su organización opera procesos controlados, que es el requisito de entrada. Si todavía no tiene ninguno, dígalo, indique su cronograma y esté listo para responder directamente las preguntas de fondo. Las startups en etapa temprana suelen superar revisiones con respuestas escritas claras y una hoja de ruta definida, pero eso reduce qué compradores asumirán el riesgo.

Los riesgos específicos de IA que buscan los revisores

Los revisores no inventan categorías de riesgo de IA desde cero. La mayoría se apoya en el OWASP Top 10 for LLM Applications, publicado por el OWASP GenAI Security Project. La edición de 2025 enumera diez riesgos:

1. Inyección de prompts (Prompt Injection)
2. Divulgación de información sensible (Sensitive Information Disclosure)
3. Cadena de suministro (Supply Chain)
4. Envenenamiento de datos y del modelo (Data and Model Poisoning)
5. Manejo inadecuado de los resultados (Improper Output Handling)
6. Autonomía excesiva (Excessive Agency)
7. Filtración del prompt del sistema (System Prompt Leakage)
8. Debilidades de vectores y embeddings (Vector and Embedding Weaknesses)
9. Desinformación (Misinformation)
10. Consumo sin límites (Unbounded Consumption)

Cinco de ellos aparecen en casi todas las revisiones.

Inyección de prompts. Texto que manipula al modelo para que ignore sus instrucciones. Puede llegar directamente de un usuario o indirectamente a través del contenido que lee el modelo, como un documento, una página web o un correo electrónico. La pregunta del revisor es qué podría hacer o revelar su producto si lo controla un atacante, y qué límites existen si el modelo es engañado.

Divulgación de información sensible. ¿Puede el producto exponer los datos de un cliente a otro, o revelar datos confidenciales en los resultados o en los registros? Aquí se examinan el aislamiento entre clientes, los controles de acceso en la recuperación de información y las prácticas de registro.

Cadena de suministro. Es probable que su producto dependa de un modelo de terceros, componentes de código abierto, conjuntos de datos y posiblemente plugins. Los revisores quieren saber cuáles, quién los actualiza y qué pasa cuando un proveedor cambia sus términos o sufre un incidente.

Manejo inadecuado de los resultados. Los resultados del modelo son una entrada no confiable para el resto de su sistema. Si se pasan sin validación a una base de datos, a un navegador o a una terminal, se convierten en una vía de inyección. El caso clásico es un modelo que escribe un comando que luego alguien ejecuta.

Autonomía excesiva. OWASP la define como la vulnerabilidad que permite que ocurran acciones dañinas en respuesta a resultados del modelo inesperados, ambiguos o manipulados. Enumera tres causas: funcionalidad excesiva, permisos excesivos y autonomía excesiva. En los productos de agentes, esta suele ser la pregunta central, ya que el producto actúa, no solo responde. Para la perspectiva específica de los agentes, consulte seguridad de los agentes de IA.

Los marcos que citan los revisores

Cuatro nombres aparecen en cuestionarios y documentos de políticas. Saber qué es cada uno, y qué no es, le evita hacer afirmaciones exageradas.

NIST AI RMF. El NIST indica que el AI RMF 1.0, publicado el 26 de enero de 2023, está pensado para uso voluntario, con el fin de mejorar la forma en que las organizaciones incorporan la confiabilidad en el diseño, el desarrollo, el uso y la evaluación de la IA. El NIST publicó el Generative AI Profile (NIST-AI-600-1) el 26 de julio de 2024. Según el propio perfil, un perfil es una implementación de las funciones del marco para un contexto específico, y este define riesgos nuevos o agravados por la IA generativa y luego sugiere acciones para gobernarlos, mapearlos, medirlos y gestionarlos. No existe la «certificación NIST». Diga «alineado con» solo si realmente ha mapeado sus prácticas.

ISO/IEC 42001. El estándar especifica requisitos para establecer, implementar, mantener y mejorar continuamente un sistema de gestión de IA, y se aplica a cualquier organización que desarrolle, ofrezca o use productos o servicios basados en IA. Se publicó el 18 de diciembre de 2023. Como es un estándar de sistema de gestión, la certificación significa que un auditor evaluó sus procesos. No es una garantía de que un resultado concreto del modelo sea seguro, y hoy no se exige en la mayoría de las revisiones. Para una startup, es un diferenciador cuando vende a compradores que lo piden.

MITRE ATLAS. Inspirado en la matriz ATT&CK de MITRE, ATLAS organiza la manera en que los adversarios atacan los sistemas con IA. Los equipos de seguridad lo usan para construir modelos de amenazas y escenarios de red team. Rara vez se le pide a una startup que sea «compatible con ATLAS», pero citarlo en su modelo de amenazas demuestra que el trabajo se hizo.

Las etapas de una revisión

El proceso de cada comprador es distinto, pero la mayoría sigue el mismo recorrido.

1. Recepción. El equipo de compras o de seguridad del comprador abre una solicitud de proveedor, clasifica los datos involucrados y decide qué tan a fondo revisar. Un producto que toca datos personales de clientes o se conecta a sistemas centrales recibe una revisión más profunda que uno que trabaja con contenido público.
2. Intercambio de documentos. Usted envía lo que tiene: resumen de seguridad, informe SOC 2 o ISO, cuestionario completo, términos de tratamiento de datos, lista de subencargados del tratamiento, diagrama de arquitectura.
3. Cuestionario y aclaraciones. El revisor analiza las respuestas y envía preguntas de seguimiento. Aquí suelen llegar las preguntas específicas de IA: entrenamiento con datos del cliente, proveedores de modelos, salvaguardas, registros.
4. Análisis técnico a fondo. Para despliegues de mayor riesgo, una llamada con los ingenieros de seguridad del comprador. Pueden pedir ver la arquitectura, el aislamiento entre clientes, cómo se manejan los prompts y las herramientas, y los resultados de las pruebas.
5. Pruebas, cuando se requieren. Algunos compradores realizan o solicitan pruebas de penetración, o piden evidencia de pruebas adversarias de la capa de modelo.
6. Decisión de riesgo y corrección. El revisor aprueba, aprueba con condiciones o rechaza. Las condiciones suelen convertirse en compromisos contractuales o en un plan de corrección con fechas.
7. Contratación y nueva revisión. Los hallazgos se incorporan al acuerdo. Muchos compradores vuelven a revisar de forma periódica o cuando cambia algo importante, como un nuevo proveedor de modelos o una nueva función autónoma.

El costo en tiempo es real, y por eso importa el paquete de evidencia. Cómo se conecta el resultado con los términos del acuerdo se explica en de pilotos de IA a contratos.

Qué evidencia debe tener lista una startup de IA

Los revisores avanzan más rápido cuando las respuestas ya están escritas. El enfoque práctico es un paquete de confianza permanente, mantenido al día, que pueda enviar cuando se lo pidan.

Redacte las respuestas para que resistan el escrutinio. Una afirmación como «estamos protegidos contra la inyección de prompts» invita a una pregunta de seguimiento que no podrá satisfacer, porque ningún proveedor puede prometer eso. Una afirmación como «el contenido no confiable se trata como datos, las llamadas a herramientas se limitan a estos alcances y las acciones de alto impacto requieren aprobación» le da al revisor algo específico que verificar. La misma disciplina de respaldar cada afirmación con evidencia recorre vender IA a compradores escépticos.

Errores comunes

• Exagerar el cumplimiento. Decir «cumplimos con NIST» o «tenemos certificación ISO 42001» cuando ninguna de las dos cosas es cierta es la manera más rápida de perder credibilidad y generar exposición legal.
• No conocer su propia cadena de suministro. Si no puede decir qué proveedores de modelos ven datos de clientes, la revisión se estanca.
• Ignorar los permisos de los agentes. Darle a un agente credenciales amplias porque es cómodo es exactamente lo que describe la autonomía excesiva.
• Ocultar los límites. Los revisores respetan mucho más «esta es una limitación conocida y este es el control» que el silencio. Para los aspectos de cumplimiento de los agentes, consulte cumplimiento normativo de los agentes de IA.

Datos clave

• Base más capa de IA: una revisión de seguridad de IA ejecuta las verificaciones estándar de proveedores (cuestionario, SOC 2 o ISO 27001, términos sobre datos) y luego agrega riesgos específicos del modelo.
• Lista de OWASP: la edición de 2025 del OWASP Top 10 for LLM Applications nombra diez riesgos, desde la inyección de prompts hasta el consumo sin límites.
• La autonomía excesiva tiene tres causas: OWASP enumera la funcionalidad excesiva, los permisos excesivos y la autonomía excesiva.
• El NIST AI RMF es voluntario: el NIST publicó el AI RMF 1.0 el 26 de enero de 2023 y el Generative AI Profile el 26 de julio de 2024. Ninguno es una certificación.
• ISO/IEC 42001 es certificable: publicado el 18 de diciembre de 2023, especifica requisitos para un sistema de gestión de IA.
• SOC 2 cubre cinco áreas: según el AICPA, seguridad, disponibilidad, integridad del procesamiento, confidencialidad y privacidad.
• Existen cuestionarios reutilizables: la CSA distribuye el CAIQ junto con su Cloud Controls Matrix, incluida una versión STAR Level 1.

Lecturas relacionadas

• Preguntas sobre privacidad de datos que hacen los compradores de IA
• La confianza y la evaluación como activo de ventas
• ¿Qué es una política de IA responsable?
• Vender IA a compradores escépticos
• El comité de compra de IA
• De pilotos de IA a contratos
• Por qué las demos importan más en los productos de IA
• Seguridad de los agentes de IA
• Cumplimiento normativo de los agentes de IA