¿Puede SOC 2 aceptar una prueba de penetración realizada por IA?

Idea errónea: SOC 2 exige que un consultor humano realice su prueba de penetración, sin excepciones. En ninguna parte de los Trust Services Criteria se dice eso, pero la creencia está tan extendida que sorprende a muchos equipos. Cada vez más equipos de seguridad ejecutan pruebas de penetración continuas e impulsadas por IA durante todo el año, en lugar de contratar un único trabajo anual, y llegan a su auditoría SOC 2 con una pregunta que su auditor aún no había recibido: ¿aceptará un informe de pruebas de penetración en el que las pruebas las realizó un agente de IA y no un consultor humano?

¿Acepta SOC 2 las pruebas de penetración realizadas por IA? Sí, pero con condiciones. Veamos cuáles son las que realmente importan a un auditor.

El resto de este artículo explica por qué es así: qué exige realmente SOC 2, por qué las pruebas continuas con IA se ajustan mejor al periodo de auditoría que un pentest anual, y qué distingue la evidencia generada por IA que un auditor aceptará del ruido generado por IA que rechazará.

SOC 2 no dice realmente «prueba de penetración»

A mucha gente le sorprende esto la primera vez que lee con atención los Trust Services Criteria. El AICPA define los Trust Services Criteria en la TSP Section 100 (los criterios de 2017, con puntos de enfoque revisados publicados en 2022). Si se lee con detenimiento la documentación oficial, se comprueba que el texto nunca exige una prueba de penetración por su nombre. Lo que exige es que una organización evalúe si sus controles funcionan de forma eficaz, y la prueba de penetración se ha convertido en la forma estándar en el mercado con la que los auditores esperan que se realice esa evaluación para los controles técnicos, no porque el marco exija ese método concreto, sino porque ninguna otra cosa demuestra que un control resiste realmente un ataque en lugar de existir solo sobre el papel.

Tres criterios concentran la mayor parte del peso:

Criterio	Qué exige	Por qué el método de pruebas es la forma en que los auditores lo evalúan
CC4.1 — Actividades de supervisión	La entidad evalúa si sus controles existen y funcionan	Inspeccionar un control (leer una configuración, revisar un documento de políticas) confirma que existe; atacarlo confirma que funciona
CC7.1 — Identificación de vulnerabilidades	La entidad identifica las vulnerabilidades de su infraestructura	Implica una actividad continua: las vulnerabilidades no aparecen según un calendario anual fijo, por lo que la evidencia debe cubrir el periodo de auditoría y no una sola fecha dentro de él
CC7.2 — Detección de eventos de seguridad	La entidad implementa procedimientos de detección para identificar anomalías	Un ataque real es una de las pocas formas de generar un evento real y observar si la detección se activa de verdad

Así, «necesitamos un pentest para SOC 2» es en realidad una forma abreviada de decir «necesitamos evidencia creíble de que nuestros controles resisten un intento activo de vulnerarlos, a lo largo del periodo auditado». Esa distinción es importante, porque significa que la pregunta real del auditor nunca fue quién o qué ejecutó la prueba, sino si el resultado es una evidencia creíble y reproducible de la eficacia de los controles. Un agente de IA se juzga con exactamente el mismo criterio que un evaluador humano.

Las auditorías Type II están pensadas para evidencia continua, no para una instantánea única

SOC 2 se presenta en dos variantes, y la diferencia cambia incluso lo que significa «evidencia aceptable».

• Type I certifica que los controles estaban diseñados adecuadamente en un momento determinado.
• Type II certifica que los controles operaron de forma eficaz durante un periodo de auditoría, normalmente de seis a doce meses.

Una prueba de penetración anual tradicional produce un único dato: un informe fechado un día cualquiera dentro de esa ventana. Para una auditoría Type I, es un ajuste razonable. Para una auditoría Type II, es una desalineación estructural: se pide que una sola instantánea represente doce meses de operación de los controles, y todo lo ocurrido antes o después de las fechas de ese trabajo queda simplemente sin evidencia.

Aquí es donde las pruebas continuas impulsadas por IA cambian la forma de la evidencia, y no solo su volumen. Como una plataforma de pentesting agéntico puede ejecutar ciclos de prueba recurrentes a lo largo del periodo de auditoría, en lugar de un único trabajo dentro de él, el rastro de evidencia abarca de forma natural la misma ventana que certifica la opinión Type II. Un nuevo CVE divulgado en el séptimo mes del periodo de auditoría se prueba contra su entorno en ese séptimo mes, y no se descubre con carácter retroactivo cuando el pentest anual del año siguiente lo detecta por casualidad. Es un ajuste estructural mejor para lo que una auditoría Type II intenta realmente demostrar: no es un atajo para eludir el requisito, sino una correspondencia más cercana con él.

¿Qué criterios debe cumplir un informe de pentest con IA para SOC 2?

En una auditoría SOC 2, la herramienta que produjo un hallazgo no es la preocupación real del auditor. Los auditores ya aceptan numerosas entradas automatizadas (escáneres de vulnerabilidades, herramientas de cumplimiento de configuración, monitorización basada en registros) como evidencia complementaria. Lo que determina si un informe de pruebas de penetración, ya sea realizado por IA o por una persona, resiste el examen es la misma lista breve de propiedades:

1. Prueba reproducible, no una puntuación de severidad. Un hallazgo necesita un par de solicitud y respuesta, una ruta de reproducción u otro artefacto que un tercero pueda utilizar para confirmar de forma independiente el impacto, y no una calificación de confianza asociada a una coincidencia de patrones.
2. Una metodología documentada e inspeccionable. El auditor debe poder leer qué se probó realmente (qué puntos de entrada, qué hipótesis, qué pasos de validación) en lugar de aceptar por fe una afirmación de caja negra del tipo «confíe en el modelo». Los auditores desconfían profesionalmente de las cajas negras, y con razón.
3. Una aprobación humana con nombre y responsabilidad. En algún punto de la cadena, una persona concreta y cualificada revisó los resultados y responde de la exactitud del informe, exactamente igual que un trabajo realizado por humanos nombraría al evaluador que lo firmó.
4. Un alcance definido y acordado. Qué sistemas cubre el programa, durante qué periodo y cómo se corresponde con el límite de la auditoría. Un alcance indefinido o cambiante socava la calidad de la evidencia, con independencia de quién ejecutó la prueba.
5. Coherencia del formato de la evidencia a lo largo del periodo. Si la evidencia en la que se apoya una auditoría Type II cambia de forma a mitad de camino (otra estructura de informe, otra cobertura, sin explicación), se interpreta como una señal de alerta y no como innovación.

Así se ven los puntos 1 y 2 en la práctica, a partir de un hallazgo real de Broken Object-Level Authorization en un backend móvil. Los nombres de los endpoints, los tokens y los valores identificativos están redactados.

Figura 1: El hallazgo en sí: la severidad, una descripción en lenguaje sencillo del fallo y una confirmación de la causa raíz que muestra que el endpoint vulnerable ignora una cabecera que un endpoint comparable sí aplica correctamente. Las figuras siguientes muestran cómo se planificó, reprodujo y revalidó este hallazgo concreto.

Figura 2: Los dos primeros pasos de la ruta de reproducción: un bearer token global obtenido de credenciales de cliente incrustadas en el código y, a continuación, una carga útil de solicitud cifrada para ajustarse al esquema del objetivo. Redactada para su publicación.

Figura 3: La respuesta que produjo realmente la solicitud de la Figura 2: un objeto completo de PII devuelto para una cuenta válida, sin que se proporcionara ningún token de usuario. Esta es la «prueba reproducible» del punto 1: un tercero puede volver a ejecutar exactamente esta solicitud y obtener el mismo resultado.

Figura 4: El plan de pruebas que respalda el mismo hallazgo: un agente de planificación identificado por su nombre, objetivos explícitos (confirmar la omisión de la cabecera, verificar que el token es suficiente, comprobar la persistencia tras las rotaciones, etc.) y una lista de tareas por fases que comienza con la documentación de referencia y el mapeo de la superficie de ataque. Esto es lo que significa «inspeccionable» en el punto 2: un auditor puede leer exactamente qué se planificó y se probó, y no solo el resultado.

Ninguna de estas cinco propiedades es específica de la IA. Son el mismo criterio que también incumple un informe de pentest humano mediocre: hallazgos vagos sin pasos de reproducción, un subcontratista al que nadie puede nombrar, un alcance que nunca se puso por escrito. Las pruebas realizadas por IA no se califican con indulgencia, ni lo necesitan: las pruebas agénticas que validan realmente sus hallazgos superan este criterio con más constancia que un trabajo manual apresurado o un escaneo basado en firmas.

Dónde falla discretamente la IA como evidencia

El modo de fallo al que hay que prestar atención no es «el auditor lo rechazó porque intervino la IA». Es confundir un escáner de IA con un pentest de IA y entregar al auditor el primero etiquetado como el segundo.

Un escáner, con o sin ayuda de IA, busca coincidencias de patrones en una base de código o en un objetivo activo e informa de lo que cree que podría estar mal. Sin validar, esa salida es una lista de hipótesis, no de hallazgos: un alto volumen de falsos positivos, ninguna ruta de reproducción y ninguna evidencia de que algo demostrara un impacto real. Eso es una evidencia de auditoría más débil que un pentest humano modesto, no más fuerte, porque el revisor aún tiene que rehacer el trabajo para saber qué es real. Escanear más superficie de ataque a la vez tampoco cambia esa ecuación: ejecutar escaneos de múltiples activos en paralelo sobre activos web, móviles y de API solo produce más hipótesis sin validar por hora, a menos que algo posterior confirme cuáles son reales.

Un pentest de IA es distinto en esencia, no solo en velocidad: reconocimiento, hipótesis, prueba, validación y, de forma crucial, un paso que se pregunta si un hallazgo se combina con otro para formar algo más grave. La distinción que importa para la evidencia de CC7.1 en concreto es si el informe muestra que una credencial se comprobó como activa contra un endpoint real, o si simplemente se marcó como «posible secreto incrustado en el código». Una es una prueba; la otra es una pista que todavía requiere que una persona la investigue.

Este es el mismo principio en torno al cual se ha diseñado Agentic Deep Scan de Ostorlab, precisamente por esta razón: una fase de detección encuentra y explota el problema, y produce una solicitud ejecutable, la respuesta que generó y la afirmación concreta que esa respuesta sustenta. A continuación, una fase de validación independiente vuelve a ejecutar el exploit de forma autónoma antes de que una persona lo vea: con un token nuevo, no el que ya se tenía; con una comprobación comparativa contra un endpoint que aplica correctamente el control, para descartar una configuración incorrecta global; y con formatos de entrada alternativos y ejecuciones repetidas a lo largo del tiempo, para confirmar que el problema no es una casualidad de una solicitud concreta. Esa es la diferencia entre una evidencia sobre la que un auditor puede actuar y un informe que se limita a trasladar el trabajo de verificación a la fase siguiente.

Figura 5: La fase de validación del mismo hallazgo: el exploit se vuelve a ejecutar sobre un lote de cuentas para descartar un resultado aislado y se repite después con un token recién obtenido para confirmar que el problema no está ligado a la sesión original. Esto se ejecuta después de la detección y antes de que el hallazgo llegue a presentarse a una persona.

El paquete de evidencia que un auditor quiere ver realmente

Tanto si las pruebas fueron continuas como si fueron un único trabajo, y las realizara una persona o una IA, un paquete de evidencia listo para Type II necesita, por lo general, los mismos componentes:

Componente	Qué demuestra
Documento de metodología	Qué se probó, cómo y mediante qué proceso, incluida la manera en que se generaron y validaron las hipótesis del agente de IA
Declaración de alcance	Qué sistemas, entornos y ventana temporal cubre el programa de pruebas, en correspondencia con el límite de la auditoría
Prueba por hallazgo	Pares de solicitud y respuesta, pasos de reproducción, capturas de pantalla o registros que muestran un impacto real, y no solo una etiqueta de severidad
Registro de revisión humana	Quién revisó los hallazgos, cuándo y qué criterio aplicó: la responsabilidad nominal a la que un auditor puede remitirse
Evidencia de corrección y nueva prueba	Confirmación de que los problemas notificados se corrigieron y de que la corrección se verificó de forma independiente, y no solo se marcaron como cerrados
Mapa de cobertura	Qué partes del periodo de auditoría abarca realmente la evidencia de las pruebas, de modo que las lagunas sean visibles y no se den por inexistentes

Si un programa puede producir los seis para todo el periodo de auditoría, el hecho de que un agente de IA ejecutara los ciclos de prueba individuales es un detalle de implementación, no una objeción.

Cómo introducir pruebas continuas con IA sin descarrilar una auditoría en curso

El error práctico no es ejecutar pruebas impulsadas por IA, sino cambiar la forma de su evidencia a mitad del periodo de auditoría sin avisar a nadie. Algunas medidas hacen que la transición sea fluida en lugar de una sorpresa:

• Hable con su auditor antes de que comience el periodo, no cuando se acerque la fecha de entrega del informe. A la mayoría de los auditores no les molesta recibir más evidencia y de mejor calidad; lo que les molesta es que aparezca en un formato desconocido y sin previo aviso.
• Muestre un informe de ejemplo con antelación. Deje que vean cómo es un hallazgo, con su prueba incluida, antes de que sea la única evidencia que respalde un control.
• Acuerden la cadencia y el formato de antemano. Los ciclos de prueba semanales, continuos o mensuales son todos viables; lo que rompe la confianza es cambiar de formato a mitad de camino sin documentar el motivo.
• Mantenga un punto de anclaje conocido si su auditor lo desea. Algunas firmas todavía se sienten más cómodas con un trabajo anual, más revisado por personas, como una instancia dentro de un programa continuo, al menos durante el primer ciclo. Es un paso transitorio razonable, no una concesión que implique que las pruebas con IA no cuentan.

Qué sigue sin estar resuelto

Los Trust Services Criteria del AICPA todavía no contienen un lenguaje explícito sobre las pruebas realizadas por IA, y las firmas de auditoría varían en cuánta participación de agentes de IA se sienten cómodas evaluando hoy. Las plataformas de automatización del cumplimiento que alimentan directamente las auditorías SOC 2 con evidencia ya han empezado a aceptar los informes de pruebas de penetración realizadas por IA como evidencia complementaria válida: el lado de las herramientas del mercado avanza por delante del lenguaje de los estándares, aunque cada firma de auditoría siga fijando su propio listón caso por caso. Algunas aceptarán un informe de pentest con IA bien documentado con una fricción mínima; otras pedirán que una persona identificada y con credenciales revise y cofirme los hallazgos antes de apoyarse en él, lo cual es una petición razonable y conviene planificarla en lugar de resistirse a ella. Hasta que la guía alcance a la práctica, la postura más segura es documentar de más: mantener la metodología explícita, mantener a una persona responsable de cada informe y tratar las objeciones del auditor como una conversación sobre el alcance, no como un rechazo del enfoque.

Preguntas frecuentes

¿Exige SOC 2 una prueba de penetración? No de forma explícita. Los Trust Services Criteria exigen evidencia de que los controles son eficaces (CC4.1) y de que se identifican las vulnerabilidades (CC7.1), y la prueba de penetración se ha convertido en la forma aceptada de producir esa evidencia, pero es una expectativa del auditor construida sobre los criterios, no un requisito expreso del texto del marco.

¿Pueden los hallazgos de un agente de IA satisfacer los requisitos de evidencia de CC7.1? Sí, si los hallazgos están validados y no son una salida bruta del modelo: cada uno necesita una prueba reproducible de explotabilidad, no una puntuación de severidad asignada a una coincidencia de patrones. Las pistas generadas por IA sin validar no cumplen el criterio, igual que no lo cumpliría una alerta de escáner sin validar.

¿Es aceptable para SOC 2 un informe de pentest con IA totalmente autónomo y sin revisión? En general, no. Los auditores esperan que haya una persona identificada y responsable detrás de cualquier informe en el que se apoyen. Un agente de IA puede ejecutar las pruebas; una persona cualificada sigue necesitando revisar los resultados y respaldarlos.

¿En qué se diferencia un pentest con IA de un escaneo de vulnerabilidades a efectos de cumplimiento? Un escaneo informa de lo que podría estar mal; un pentest, ya sea realizado por IA o por una persona, demuestra lo que es realmente explotable mediante reconocimiento, hipótesis, prueba y validación. Los auditores consideran que la salida de un escaneo sin validar es una evidencia más débil, porque aún requiere que una persona determine qué es real.

¿Debemos mantener un pentest manual anual junto con las pruebas continuas con IA? Muchas organizaciones lo hacen, al menos durante la transición, ya sea porque su auditor quiere un punto de anclaje conocido o porque un trabajo periódico dirigido por personas añade pruebas basadas en el juicio (lógica de negocio, escenarios cercanos a la ingeniería social) que complementan la cobertura sistemática de la IA en lugar de duplicarla.

Conclusión

SOC 2 nunca evaluó la herramienta: evaluaba la evidencia. Una prueba de penetración realizada íntegramente por un agente de IA puede satisfacer una auditoría SOC 2 Type II y, en ciertos aspectos, encaja mejor con el modelo de evidencia basado en periodos que un único trabajo anual, porque las pruebas continuas abarcan de forma natural la ventana que la auditoría certifica. Lo que no puede hacer es saltarse las partes que nunca tuvieron que ver con la herramienta: una prueba reproducible, una metodología que un auditor pueda leer realmente, una persona identificada que respalde el informe y un alcance acordado por todos antes de que empezara el reloj. Si todo eso está bien resuelto, que las pruebas se ejecutaran según un calendario fijado por una firma consultora o por un agente que razona sobre hipótesis a las 2 a. m. deja de ser la pregunta interesante.

La pregunta más interesante es qué ocurre cuando esta misma lógica se aplica fuera de SOC 2. PCI DSS, HIPAA y el resto del alfabeto del cumplimiento se apoyan en la misma idea: controles que resisten un ataque, no solo controles que existen sobre el papel. Si están listos para aceptar una respuesta de una IA a esa pregunta es algo que abordaremos en otro artículo.