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 exigen o recomiendan la realización de pruebas de penetración son SOC 2, ISO 27001, HIPAA y PCI DSS. En la mayoría de ellos, ninguno exige explícitamente que la prueba la lleve a cabo una persona. Lo que especifican es la cobertura, la metodología y la documentación. PCI DSS es menos claro: sus directrices definen las pruebas de penetración como «esencialmente una tarea manual» y establecen que las herramientas automatizadas por sí solas no satisfacen el requisito ( pentesting de IA veremos qué significa esto para pentesting de IA ).
Analicemos el SOC 2. En realidad, este marco no exige en absoluto la realización de pruebas de penetración. Lo que sí exige es que se demuestre que los controles son eficaces, especialmente en lo que respecta 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 acordado que las pruebas de penetración son la forma más creíble de demostrar dichos controles, ya que demuestran que alguien realmente intentó vulnerarlos. Un informe de pruebas de penetración que relacione los hallazgos con estos criterios, documente lo que se ha probado y muestre la corrección de cualquier aspecto crítico es lo que cumple el requisito. Resulta que el marco no dice nada sobre quién o qué realizó la prueba.
La norma ISO 27001 sigue un patrón similar y recomienda realizar pruebas de penetración como parte de la evaluación continua de riesgos.
Históricamente, la HIPAA ha considerado las pruebas de penetración como una buena práctica más que como un requisito imprescindible, pero eso está cambiando. En diciembre de 2024, el HHS propuso actualizaciones a la Norma de Seguridad de la HIPAA que harían obligatorias las pruebas de penetración anuales para todas las entidades cubiertas y socios comerciales, debiendo ser realizadas por personal cualificado con los conocimientos adecuados en ciberseguridad. Se espera que dicha norma esté finalizada a mediados de 2026. Si trabajas en el sector sanitario, consulta directamente con tu equipo de cumplimiento sobre la situación actual.
Todos los marcos exigen un informe estructurado que incluya un resumen ejecutivo, una sección sobre la metodología, hallazgos validados con pruebas y pasos para reproducirlos, clasificaciones de gravedad y recomendaciones de corrección. La Guía de pruebas de seguridad de aplicaciones web de OWASP es el punto de referencia que siguen la mayoría de los evaluadores en cuanto a cobertura (y es una lista muy extensa). Ni siquiera un equipo humano que cuente con el presupuesto de una semana puede, de manera realista, abarcarlo todo en profundidad. Tienen que clasificar y priorizar los aspectos más importantes. La frecuencia y la amplitud son restricciones que ya no limitan el alcance de nuestras 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 adapta perfectamente a las necesidades de los equipos de cumplimiento normativo. Para SOC 2 e ISO 27001 se proporciona un PDF completo con pruebas, instrucciones detalladas para la corrección de deficiencias y los pasos a seguir para volver a realizar las pruebas una vez aplicadas las correcciones. Se incluyen los requisitos de la HIPAA.
Los plazos de ejecución pentesting de IA del orden de unas horas (sin duda menos de un día), lo cual resulta muy útil cuando hay que cumplir con los plazos de una certificación o responder a una solicitud de auditoría que incluye activos dentro del alcance que no se han sometido a pruebas anteriormente.
¿Qué no puede hacer el pentesting de IA para el cumplimiento?
Aunque las pruebas de penetración basadas en IA gozan de una aceptación cada vez mayor, se trata de una tecnología aún bastante nueva, y algunos sectores y sus organismos reguladores siguen definiendo su postura al respecto.
La norma PCI DSS es más prescriptiva que SOC 2 o ISO 27001 y exige explícitamente la realización de pruebas de penetración al menos una vez al año, con una cobertura específica de los entornos de datos de los titulares de tarjetas. Su guía oficial sobre pruebas de penetración, actualizada por última vez en 2017, describe estas pruebas como «una tarea esencialmente manual» y establece que el mero uso de herramientas automatizadas no cumple con el requisito. El espíritu de este requisito siempre ha girado en torno a la explotación activa, las pruebas validadas y el análisis de los resultados. Los pentesters humanos pueden utilizar pentesting de IA herramienta para gestionar gran parte del trabajo pesado en el lado de la aplicación. Dicho esto, PCI DSS también exige pruebas de la capa de red y de segmentación, además de las pruebas de la capa de aplicación, que las pruebas de penetración con IA no cubren en ningún caso.
En el caso de algunos organismos reguladores de los servicios financieros o de determinados requisitos del sector público, las empresas deberán consultar directamente con su auditor para evaluar su disposición a considerar que monitorización continua las pruebas no solo son equivalentes a las pruebas puntuales, sino que constituyen una prueba significativamente superior de la eficacia de los controles de seguridad y del rigor de los programas.
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 comentábamos sobre el PCI DSS. El texto de 2017 que describía las pruebas de penetración como «una tarea esencialmente manual» se redactó específicamente para abordar el problema de que las organizaciones presentaran los resultados de los escáneres como si fueran informes de pruebas de penetración. La guía marcaba una línea divisoria frente a esa práctica, sin prever un mundo en el que los agentes de IA explotaran y validaran activamente los hallazgos de la misma manera que lo hacen los evaluadores humanos. Aunque las pruebas de penetración con IA no cubren todos los requisitos de las pruebas de penetración de PCI DSS (como las pruebas de la capa de red y de segmentación), las herramientas de pruebas de penetración con IA pueden ayudar a las organizaciones a realizar pruebas de penetración de aplicaciones de manera más eficiente, y es posible que veamos cómo estas normativas actualizan su redacción en el futuro para abordar este matiz. El sector tiende a avanzar 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 normativos exigen, como mínimo, pruebas anuales, además de nuevas pruebas tras la introducción de cambios significativos en la aplicación o la infraestructura. Las pruebas de penetración con IA pueden cubrir estos requisitos para SOC 2 e ISO 27001. PCI DSS es el marco más prescriptivo, ya que exige explícitamente pruebas tanto internas como externas anualmente y tras cualquier cambio significativo en el entorno de datos de los titulares de tarjetas. pentesting de IA gran parte del componente de la capa de aplicación de ese requisito, pero deben ser realizadas por un pentester humano. Las pruebas de la capa de red y de segmentación requieren una cobertura independiente, normalmente a cargo 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 quedan fuera del alcance de cualquier prueba de penetración centrada en las aplicaciones, ya sea basada en IA o de otro tipo. La norma PCI DSS requiere, como mínimo, un evaluador de seguridad humano para las pruebas de red y de segmentación. Los sectores con requisitos de acreditación específicos, como CREST en el Reino Unido o los requisitos de 3PAO en el marco de FedRAMP, pueden necesitar medidas adicionales antes de que una prueba de penetración basada en IA cumpla plenamente con sus obligaciones de cumplimiento normativo.
