El pentesting de IA ha estado causando sensación y rivaliza con el poder de los hackers humanos de formas que no esperábamos. Sin embargo, con frecuencia, las empresas buscan el pentesting para obtener y respaldar sus certificaciones de cumplimiento.
En el pasado, los auditores han rechazado los resultados de herramientas automatizadas. Pero esto no se debe a que se requiriera un humano para realizar todas las pruebas, sino a que esas herramientas antiguas no se acercaban a realizar pentests adecuados. Un pentest de IA que ejecuta 250 agentes orquestados contra su aplicación se asemeja mucho a cómo los pentesters humanos realizan sus evaluaciones. Esto implica explorar la aplicación, comprender cómo funcionan las características, encontrar formas de romperlas y validar que el problema es realmente explotable antes de incluirlo en el informe.
Los verdaderos pentests de IA son hoy aceptados regularmente por los auditores. En esta publicación, discutiremos las ideas erróneas sobre el pentesting de IA y cómo se relaciona con el cumplimiento, y explicaremos cómo y cuándo puede utilizar el pentesting de IA para satisfacer sus requisitos de cumplimiento.
¿Qué necesita realmente para el pentesting de cumplimiento?
Cuando un auditor solicita una prueba de penetración, está pidiendo documentación que demuestre que su aplicación fue probada contra un conjunto definido de vectores de ataque y metodologías de prueba, que los hallazgos fueron validados y registrados, y que usted tiene un plan de remediación para cualquier elemento crítico. La cuestión no es si fue un humano el que estuvo frente a un terminal durante dos semanas o agentes de IA los que dedicaron un día a ello. También es cierto que la infraestructura cambiaba mucho más lentamente en el pasado, con lanzamientos trimestrales, por lo que la idea de realizar pruebas de penetración semanales era algo absurdo. Definitivamente, ese no es el caso ahora.
Los marcos más comunes que requieren o recomiendan pentesting son SOC 2, ISO 27001, HIPAA y PCI DSS. Para la mayoría de ellos, ninguno exige explícitamente que un humano haya realizado la prueba. Lo que especifican es la cobertura, la metodología y la documentación. PCI DSS es menos directo: su guía define las pruebas de penetración como 'esencialmente un esfuerzo manual' y afirma que las herramientas automatizadas por sí solas no satisfacen el requisito (analizaremos lo que esto significa para el pentesting de IA más adelante).
Veamos SOC 2. El marco no exige pentesting en absoluto. Lo que sí exige es que demuestre que sus controles son efectivos, particularmente en torno al acceso lógico (CC6.1), la gestión de cambios (CC8.1) y la mitigación de riesgos (CC7.1 a CC7.4). Los auditores han optado por el pentesting como la forma más creíble de evidenciar esos controles, porque demuestra que alguien realmente intentó vulnerarlos. Un informe de pentest que mapea los hallazgos a estos criterios, documenta lo que se probó y muestra la remediación de cualquier elemento crítico, es lo que satisface el requisito. Resulta que el marco no dice nada sobre quién o qué realizó la prueba.
ISO 27001 sigue un patrón similar, recomendando el pentesting como parte de la evaluación continua de riesgos.
Históricamente, HIPAA ha tratado el pentesting como una buena práctica más que como un requisito estricto, pero eso está cambiando. En diciembre de 2024, el HHS propuso actualizaciones a la Regla de Seguridad de HIPAA que harían obligatorias las pruebas de penetración anuales para todas las entidades cubiertas y asociados comerciales, con pruebas que deberán ser realizadas por personal cualificado con los conocimientos adecuados en ciberseguridad. Se espera que esa regla se finalice a mediados de 2026. Si trabaja en el sector sanitario, consulte directamente con su equipo de cumplimiento sobre el estado actual.
Todos los marcos requieren un informe estructurado con un resumen ejecutivo, una sección de metodología, hallazgos validados con evidencia y pasos de reproducción, clasificaciones de severidad y guía de remediación. La Guía de Pruebas de Seguridad de Aplicaciones Web de OWASP es el referente que la mayoría de los probadores siguen para la cobertura (y es una lista larga). Incluso un equipo humano que trabaje con un presupuesto de una semana no puede abordar de forma realista todo con profundidad. Tienen que priorizar y clasificar las cosas más importantes. La frecuencia y la amplitud son limitaciones que ya no restringen nuestro alcance de pruebas.
La suposición de que el pentesting de cumplimiento significa pentesting humano no está escrita en la mayoría de los frameworks. Ha sido cierto por defecto porque, hasta la llegada de los LLM, ninguna tecnología podía acercarse a realizarlos realmente. Para los equipos en sectores altamente regulados con requisitos de cumplimiento específicos, vale la pena tener esa conversación directamente con su auditor. Para la mayoría, sin embargo, el informe no levantará ninguna bandera. El pentesting de IA cubre los requisitos.
Donde el pentesting de IA ya cumple con el cumplimiento
Registros de auditoría
La pista de auditoría de un pentest de IA es extensa y detallada, a menudo mejor que muchos informes de pentest humanos. Cada solicitud enviada, cada payload probado, cada acción realizada por cada agente queda registrada. Puede ver exactamente qué se probó, cómo se realizó la prueba y qué se encontró. La mayoría de los informes de pentest humanos le proporcionan hallazgos y una sección de metodología. No le dan un rastro completo de cada paso dado. Si su auditor pregunta: "¿Cómo sabemos que probaron X?", el informe generado por un pentest de IA puede mostrar el registro exacto de eso.
Cobertura de las pruebas
El pentesting de IA cubre un terreno significativo. Para aquellos que preguntan: "¿Cómo sabemos que lo intentó todo?", la preocupación se aplica igualmente a los pentesters humanos. Un informe de pentest manual que regresa con cero hallazgos y sin una pista de auditoría de lo que se probó se toma completamente por fe. Existe una especie de servidumbre al ritual de la prueba de penetración anual. De todos modos, no se puede probar que un humano lo intentó todo. Con un pentest de IA, puede enumerar la cobertura detallada de las pruebas a través de los logs.
Los agentes pueden abordar el Top 10 OWASP completo en cuestión de horas. Prueban los controles de autorización en cada endpoint, no solo en una muestra representativa. Intentan cada vector de ataque en cada característica, no solo aquellos a los que un probador humano tuvo tiempo de llegar antes de que finalizara el encargo.
Las IA están mejorando exponencialmente en su capacidad para razonar y comprender el código. Están encontrando nuevas vulnerabilidades dependientes del contexto que los humanos han pasado por alto durante años. Los escépticos asumen que las IA no pueden manejar las vulnerabilidades de lógica de negocio. Esto ya no es así. En la práctica, los agentes leen la base de código, comprenden el comportamiento previsto y encuentran formas creativas de romperlo. La frase «Si todo lo que tienes es un martillo, cada problema parece un clavo» es apropiada aquí. Incluso si un probador humano es realmente bueno encontrando vulnerabilidades XSRF y gana una recompensa por errores de seis cifras, la verdad es que las pruebas de IA aportan un saco lleno de martillos al trabajo.
En la comparativa directa de Aikido Security en cuatro aplicaciones web no triviales, los agentes de IA encontraron el doble de vulnerabilidades de control de acceso roto que los probadores humanos sénior. También descubrieron una falsificación de firma electrónica en una aplicación de pagos que los probadores manuales no detectaron en absoluto. Las IA, hay que admitirlo, tuvieron una enorme ventaja porque tenían acceso al código fuente. Una IA absorbe una base de código completa casi instantáneamente, mientras que los probadores humanos suelen trabajar sin ella por razones logísticas y de NDA. Pero las pruebas de caja blanca, caja gris o caja negra se elevan definitivamente gracias al paralelismo que el pentesting agéntico aporta.
La comparativa también reveló que los probadores humanos obtuvieron mejores resultados en la detección de un endurecimiento deficiente de la configuración y en la identificación de controles de higiene de cumplimiento. Desde entonces, el pentesting de IA ha seguido mejorando. El pentesting de IA de Aikido, por ejemplo, detecta regularmente vulnerabilidades IDOR complejas, que implican autenticarse como usuarios reales y seguir flujos de trabajo largos de principio a fin.
Las integraciones de terceros, especialmente los flujos OAuth complejos y las implementaciones de SSO, son más difíciles de navegar de forma consistente para los agentes. El pentesting de IA de Aikido ha realizado el esfuerzo necesario para resolver estos problemas, pero no dé por sentado que todos los productos de pentesting de IA pueden hacerlo.
Informes
El formato del informe se ajusta directamente a lo que necesitan los equipos de cumplimiento. SOC 2 e ISO 27001 obtienen un PDF completo con evidencia, guía detallada de remediación y pasos de reproducción para volver a probar después de aplicar las remediaciones. Los requisitos de HIPAA están cubiertos.
Los tiempos de respuesta para el pentesting de IA son del orden de horas (definitivamente menos de un día), lo cual es realmente útil cuando se está en un cronograma de certificación o se responde a una solicitud de auditoría que incluye activos dentro del alcance que no se habían probado previamente.
¿Qué no puede hacer el pentesting de IA para el cumplimiento?
Aunque los pentests de IA están siendo cada vez más aceptados, la tecnología aún es bastante nueva, y algunas industrias y sus reguladores todavía están definiendo su postura al respecto.
PCI DSS es más prescriptivo que SOC 2 o ISO 27001 y exige explícitamente pruebas de penetración al menos anualmente, con una cobertura específica de los entornos de datos de titulares de tarjetas. Su guía oficial para el pentesting, actualizada por última vez en 2017, describe las pruebas de penetración como 'esencialmente un esfuerzo manual' y afirma que la ejecución de herramientas automatizadas por sí sola no satisface el requisito. El espíritu del requisito siempre ha sido la explotación activa, la evidencia validada y el juicio aplicado a los resultados. Los pentesters humanos pueden utilizar el pentesting de IA como herramienta para gestionar gran parte del trabajo pesado en el lado de la aplicación. Dicho esto, PCI DSS también requiere pruebas de capa de red y segmentación junto con pruebas de capa de aplicación, que el pentesting de IA no cubrirá de todos modos.
Para algunos reguladores de servicios financieros o requisitos del sector gubernamental, las empresas deberán consultar directamente con su auditor para evaluar su apertura a considerar la monitorización continua y las pruebas no solo como equivalente a las pruebas puntuales, sino como una evidencia significativamente superior de los controles de seguridad y el rigor del programa.
Los ejemplos más claros de esto son CREST en el Reino Unido y FedRAMP en EE. UU. Ambos tienen el mismo problema subyacente: requieren que una organización humana acreditada respalde la evaluación, independientemente de cómo se hayan realizado las pruebas. La certificación CREST se originó en el Reino Unido, pero es un programa de acreditación internacional y una condición para la contratación de pentesting para muchas industrias reguladas del Reino Unido, y las herramientas de pentesting de IA aún no la poseen. Aikido está en proceso de obtener la certificación CREST para su pentesting de IA, por lo que es probable que esto cambie pronto.
FedRAMP, que se aplica a los proveedores de servicios en la nube que venden a agencias federales de EE. UU., requiere que las evaluaciones sean realizadas por organizaciones de evaluación de terceros acreditadas (3PAO). Sin embargo, las RFC recientes para FedRAMP 20x indican que el programa está trabajando en encontrar formas de modernizar su enfoque para la verificación de soluciones SaaS con el fin de proteger la infraestructura crítica y las aplicaciones y servicios gubernamentales.
Las pruebas de seguridad física y la ingeniería social están completamente fuera de alcance (las pruebas de phishing son obligatorias para FedRAMP). Estamos lejos de tener pentesters de IA caminando y girando pomos de puertas para ver si están cerradas y enviando correos electrónicos de phishing (probablemente para bien).
Es más probable que veamos a empresas acreditadas utilizando el pentesting de IA en lugares discretos como herramientas, en lugar de como reemplazos completos para su reconocimiento y pentesting. Hoy en día, los pentests de IA pueden utilizarse en un modelo de asociación donde una empresa acreditada revisa y corrobora el trabajo y los artefactos de prueba. Ese enfoque vale la pena explorarlo si opera en cualquiera de esos mercados.
¿Los auditores no rechazan las herramientas de pentesting de IA como escáneres?
La objeción más común ni siquiera es sobre el pentesting de IA. El problema son los escáneres automatizados que se hacen pasar por pentesting de IA.
Durante años, organizaciones menos escrupulosas han intentado hacer pasar la salida de un escáner de vulnerabilidades básico por un informe de pentest. Herramientas como Nessus u OpenVAS producen largas listas de problemas señalados con calificaciones de severidad que parecen creíbles sobre el papel, pero nada ha sido validado, explotado o contextualizado. Confunden el concepto de una posible vulnerabilidad con una ruta de ataque demostrable. Los auditores han visto suficientes de estos casos como para ser escépticos ante cualquier cosa que parezca un escaneo disfrazado de pentest. Por lo tanto, debe asegurarse de que su pentest de IA sea verdaderamente pentesting de IA, en lugar de un escáner o DAST con "maquillaje" de IA.
Un pentest de IA real explota y confirma vulnerabilidades contra un objetivo real antes de presentarlas en un informe. La diferencia se puede apreciar en el lenguaje y los detalles del informe. Los hallazgos validados vienen con pruebas de concepto y pasos de reproducción que muestran cómo se ejecutó realmente el exploit, mientras que los hallazgos no validados del escáner solo describen un problema potencial con una calificación de severidad genérica y no incluyen ninguna prueba de que se haya intentado algo. Si un informe devuelve cientos de hallazgos y ninguno de ellos muestra evidencia de explotación, probablemente tienes un escáner en tus manos, independientemente de lo que diga la etiqueta.
Esto nos lleva de nuevo a lo que decíamos sobre PCI DSS. El lenguaje de 2017 que describe el pentesting como 'esencialmente un esfuerzo manual' fue redactado específicamente para abordar el problema de las organizaciones que presentaban la salida del escáner como un informe de pentest. La guía estaba trazando una línea contra esa práctica, sin anticipar un mundo donde los agentes de IA exploten y validen activamente los hallazgos de la misma manera que lo hacen los testers humanos. Aunque los pentests de IA no cubren todos los requisitos de pentesting de PCI DSS (como las pruebas de capa de red y segmentación), las herramientas de pentesting de IA pueden ayudar a las organizaciones a realizar pentesting de aplicaciones de manera más eficiente, y es posible que veamos que estas regulaciones actualicen su redacción en el futuro para abordar el matiz. La industria tiende a moverse más rápido que los marcos de cumplimiento.
Cumplimiento continuo
Más allá de la casilla de verificación de cumplimiento, el pentesting puntual o de instantánea es un modelo obsoleto para cualquier cosa que publique código con más regularidad que una vez al año.
Un pentest anual le dice cómo era su aplicación el día o la semana en que se realizó la prueba. Pero es probable que su equipo de desarrollo haya implementado nuevos cambios al día siguiente. Tres meses después, el informe de cumplimiento sigue siendo válido sobre el papel, pero su superficie de ataque ha cambiado significativamente. El 85 % de los CISO y líderes de ingeniería encuestados que afirman que los hallazgos están desactualizados al menos algunas veces no se equivocan sobre su situación. El retraso es palpable y de alto riesgo.
El pentesting continuo convierte su afirmación puntual en un registro vivo. En lugar de decir a un auditor "realizamos un pentest en los activos de producción en marzo", puede mostrarle un historial de pruebas de seguridad que se sitúa justo al lado de su historial de despliegues. Y no solo en producción, sino también en los entornos inferiores. Cada cambio que afectaba a su superficie de ataque fue probado, por lo que los problemas se detectaron y corrigieron antes de que llegaran a producción.
Los bancos y las industrias altamente reguladas se ven obligados actualmente a ralentizar los ciclos de lanzamiento, específicamente para realizar pentesting a las características y funcionalidades antes de su lanzamiento. El pentesting de IA continuo cambia eso, porque las pruebas se ejecutan al ritmo de su cadencia de despliegue, comprobando solo lo que ha cambiado, por lo que los lanzamientos no tienen que esperar a las revisiones de seguridad.
Vea cómo es un pentest de IA de nivel de auditoría
Los auditores verifican que se realizó una prueba, que siguió una metodología de prueba definida, que los hallazgos de la prueba se documentaron con pruebas y que los problemas críticos se abordaron. Un informe de pentest de IA satisface todos esos requisitos. Los marcos que definen lo que se considera un informe de prueba y un artefacto de cumplimiento no especifican quién o qué realizó la prueba.
Si está trabajando para el cumplimiento SOC 2, ISO 27001, HITRUST o una certificación similar y desea ver cómo es el informe antes de comprometerse, puede solicitar un informe de muestra o ejecutar un escaneo de características en su aplicación. La mayoría de los equipos encuentran que el formato del pentest de IA no sorprende en absoluto a sus auditores.
En Aikido, hemos visto muy buenos resultados con nuestros clientes que utilizan el pentesting de IA para el cumplimiento. Aunque prometemos realizar un pentest manual si su pentest de IA es rechazado por un auditor, hasta ahora, no hemos visto que suceda. Hable con nosotros hoy mismo para desbloquear un pentesting rápido y conforme hoy mismo.
Preguntas frecuentes
¿Funciona el pentesting de IA para el cumplimiento SOC 2?
Sí, en la mayoría de los casos. SOC 2 no especifica quién o qué realiza un pentest, solo que se realizó la prueba, se documentaron los hallazgos con pruebas y se abordaron los problemas críticos.
¿Aceptarán los auditores un informe de pentest de IA?
La mayoría lo hará, siempre que el informe incluya hallazgos validados con pruebas de concepto, una sección de metodología, clasificaciones de gravedad y orientación para la remediación. El principal riesgo de rechazo es presentar la salida de un escáner automatizado disfrazada de pentest, y no un pentest de IA genuino.
¿Cuál es la diferencia entre el pentesting de IA y el escaneo automatizado?
Los escáneres automatizados comparan patrones con firmas de vulnerabilidades conocidas y señalan posibles problemas sin confirmar si son realmente explotables. Un pentest de IA genuino razona sobre cómo funciona la aplicación, intenta explotar los hallazgos contra un objetivo en vivo y solo revela vulnerabilidades que fueron realmente confirmadas.
¿Requiere SOC 2 un pentester humano?
No. SOC 2 se basa en resultados, lo que significa que define lo que sus controles deben demostrar según sus políticas de seguridad escritas, en lugar de cómo deben realizarse las pruebas. El marco se alinea con los controles de Criterios Comunes como CC4.1 y CC7.1, y un informe de pentest de IA bien documentado satisface esos requisitos.
¿Puede el pentesting de IA reemplazar al pentesting manual para el cumplimiento?
Para la mayoría de los programas SOC 2, ISO 27001 y HIPAA, sí. Ciertos entornos regulados, como las industrias del Reino Unido que requieren la certificación CREST o las agencias federales de EE. UU. que requieren la autorización FedRAMP, tienen requisitos de acreditación que actualmente necesitan que un humano correfrende el trabajo.
¿Con qué frecuencia necesito realizar un pentest para el cumplimiento?
La mayoría de los marcos esperan pruebas anuales como mínimo, además de nuevas pruebas después de que se introduzcan cambios significativos en su aplicación o infraestructura. El pentesting de IA puede cubrir esto para SOC 2 e ISO 27001. PCI DSS es un marco más prescriptivo, que exige explícitamente pruebas internas y externas anualmente y después de cualquier cambio significativo en el entorno de datos de titulares de tarjetas. El pentesting de IA cubre gran parte de la porción de capa de aplicación de ese requisito, pero debe ser utilizado por un pentester humano. Las pruebas de capa de red y segmentación requieren una cobertura separada, típicamente de un pentester humano.
¿Qué marcos requieren explícitamente pentesting?
PCI DSS lo exige explícitamente en la sección 11.4, y FedRAMP lo requiere como parte de la autorización de proveedores de servicios en la nube. SOC 2, ISO 27001 y HIPAA no lo exigen directamente, pero los auditores lo esperan rutinariamente como prueba de que los controles de seguridad están funcionando.
¿Qué debe incluir un informe de pentest para el cumplimiento?
Como mínimo: un resumen ejecutivo, una sección de metodología y alcance, hallazgos validados con pruebas de concepto y pasos de reproducción, clasificaciones de gravedad y un plan de remediación. Específicamente para SOC 2, los hallazgos deben alinearse con los Criterios de Servicios de Confianza relevantes.
¿Se acepta el pentesting de IA para ISO 27001?
Sí. ISO 27001 recomienda el pentesting como parte de la evaluación de riesgos continua, pero no especifica cómo debe realizarse. Un informe que documente qué se probó, cómo y qué se encontró satisface los requisitos de evidencia del marco.
¿Cuáles son las limitaciones del pentesting de IA en relación con el cumplimiento?
Las pruebas de seguridad física y la ingeniería social están fuera del alcance de cualquier pentest centrado en aplicaciones, ya sea de IA o de otro tipo. PCI DSS necesita un pentester humano para las pruebas de red y segmentación como mínimo. Las industrias con requisitos de acreditación específicos, como CREST en el Reino Unido o los requisitos 3PAO bajo FedRAMP, pueden necesitar pasos adicionales antes de que un pentest de IA satisfaga completamente sus obligaciones de cumplimiento.
