El pentesting de IA ha causado sensación y rivaliza con el poder de los hackers humanos de formas que no esperábamos. Pero, con frecuencia, las empresas buscan el pentesting para lograr y respaldar sus certificaciones de cumplimiento. Y la presión para hacerlo con mayor frecuencia es real. Según el informe 2026 State of AI in Pentesting de Aikido Security, que encuestó a 400 CISOs y líderes de ingeniería sénior, el 79% está preocupado por no detectar vulnerabilidades introducidas entre pruebas programadas.
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.
{{cta}}
¿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.
Desplázate hasta el final del artículo para obtener más información detallada sobre cómo funcionan las pruebas de penetración con IA en diferentes marcos de trabajo.
Lo que buscan los auditores
En resumen, lo que los auditores o las normas buscan realmente en una prueba de penetración es lo siguiente:
- Una metodología documentada y repetible, no un trasteo improvisado
- Independencia, y que el equipo encargado de las pruebas no sea el mismo que desarrolla o gestiona el sistema
- Pruebas reales de eficacia, que van más allá del análisis automatizado de vulnerabilidades
- Pruebas, como los hallazgos, la gravedad y la evidencia
- Corrección y nueva comprobación de los resultados
Si tu prueba de penetración cumple estos criterios, ya sea realizada por IA o por personas, es muy probable que tu auditor la acepte.
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.
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.
Apéndice: Características específicas del sector
Sector financiero
PCI DSS
El requisito: la norma PCI DSS es el marco normativo más prescriptivo en este ámbito. Exige una metodología documentada para las pruebas de penetración, la realización de pruebas de penetración internas y externas al menos una vez al año y tras cualquier cambio significativo, la repetición de las pruebas en todo lo que se haya corregido, y la realización de pruebas independientes de los controles que segmentan el entorno de datos de los titulares de tarjetas (con mayor frecuencia en el caso de los proveedores de servicios). La prueba debe ser realizada por un evaluador cualificado que sea independiente, desde el punto de vista organizativo, de los sistemas sometidos a prueba.
¿Puede una prueba autónoma cumplir con este requisito? No. La propia Guía de pruebas de penetración de PCI establece una distinción entre una prueba de penetración y un análisis de vulnerabilidades: un análisis es automatizado, mientras que una prueba de penetración es un proceso manual de explotación que depende de la competencia de un evaluador cualificado e independiente. Las herramientas automatizadas pueden servir de ayuda, pero la guía considera que el trabajo manual constituye la prueba en sí misma. Una prueba de penetración autónoma no se aceptará como prueba de penetración de PCI.
Los agentes de Aikido sí que aprovechan la lógica de negocio, BOLA y las vulnerabilidades encadenadas, por lo que merece la pena ejecutarlos como pruebas de seguridad continuas las actividades de seguridad obligatorias, incluso tras cambios significativos. Esto supone una ventaja en materia de seguridad y una fuente de pruebas de corrección, no una certificación PCI. Planifica por separado la prueba de penetración realizada por personal cualificado.
Conclusión: No cumple el requisito. La prueba de penetración debe ser realizada por un evaluador humano cualificado. No se aceptarán pruebas autónomas como prueba de penetración PCI.
Referencia: PCI DSS v4.0.1, requisito 11.4 (11.4.1 a 11.4.6); Guía del PCI SSC sobre pruebas de penetración.
DORA
El requisito: DORA cuenta con dos niveles de pruebas. El nivel general consiste en un programa de pruebas de resiliencia operativa digital que toda entidad financiera debe establecer, y las pruebas de penetración son uno de los métodos que debe utilizar. El nivel avanzado exige la realización de pruebas de penetración basadas en amenazas (TLPT) al menos una vez cada tres años para las entidades financieras importantes, con normas estrictas sobre quién puede llevarlas a cabo.
¿Pueden las pruebas autónomas cumplir este requisito? Sí, en el caso del programa general; no, en el caso del TLPT. El programa general es flexible en cuanto a los métodos y entre los que enumera se incluyen las pruebas de penetración, por lo que las pruebas autónomas continuas se ajustan a él y van más allá del mínimo periódico. El TLPT es diferente. Se basa en el marco TIBER-EU del BCE y requiere la participación de miembros externos y cualificados del «equipo rojo», así como de un proveedor externo de inteligencia sobre amenazas, y las entidades de crédito importantes están obligadas a recurrir exclusivamente a evaluadores externos. Es decir, por su propio diseño, se trata de una intervención del «equipo rojo» con personal humano.
Conclusión: Sí, para el programa de pruebas general. No cumplirá con el requisito del TLPT, que exige la participación de miembros externos del «equipo rojo». Utiliza Aikido para ejecutar y documentar el programa general. El TLPT es una tarea independiente que debe ser realizada por personas.
Referencia: DORA (Reglamento (UE) 2022/2554), artículos 24 y 25 (programa de ensayos) y artículos 26 y 27 (TLPT).
Norma de Salvaguardias de la FTC
Requisito: La Norma de Medidas de Seguridad de la FTC regula la forma en que las entidades financieras protegen la información de sus clientes. Exige que se compruebe periódicamente la eficacia de las medidas de seguridad y ofrece dos formas de hacerlo: monitorización continua o, en su defecto, una prueba de penetración anual, además de evaluaciones de vulnerabilidad al menos cada seis meses. También es obligatorio realizar pruebas tras cambios importantes en las operaciones.
¿Pueden las pruebas autónomas cumplir este requisito? Sí. monitorización continua presenta como una alternativa directa a la prueba de penetración anual, que es precisamente lo que ofrecen las pruebas autónomas continuas. Para una institución que prefiera la vía periódica, un único programa autónomo cubre tanto la prueba anual como las evaluaciones semestrales. La norma no establece ningún requisito relativo al personal ni a la acreditación del evaluador.
Conclusión: Sí. monitorización continua de forma explícita a la prueba de penetración anual.
Referencia: Norma de medidas de protección de la FTC, 16 CFR 314.4(d) y 314.4(d)(2).
Reglamento sobre ciberseguridad del NYDFS
Requisito: La normativa de ciberseguridad para los servicios financieros de Nueva York se aplica a bancos, aseguradoras y otras entidades autorizadas en Nueva York, y se toma como referencia fuera del estado como estándar de referencia para el sector financiero. Su apartado sobre pruebas de penetración exige que las pruebas se basen en la evaluación de riesgos de la entidad, y se estructuren bien como monitorización continua una prueba de penetración anual acompañada de evaluaciones de vulnerabilidad semestrales.
¿Pueden las pruebas autónomas cumplir este requisito? Sí. Al igual que en la norma de la FTC, el reglamento considera monitorización continua la prueba de penetración anual como alternativas. Las pruebas autónomas continuas se corresponden con la vía de la monitorización continua y, para las entidades que elijan la vía periódica, también dan lugar a la prueba anual y a las evaluaciones semestrales. El reglamento no establece ningún requisito de acreditación de los evaluadores.
Conclusión: Sí. monitorización continua por sí sola el requisito.
Referencia: Reglamento de ciberseguridad del NYDFS, 23 NYCRR 500.5 (Segunda enmienda, 2023).
Sector sanitario
HIPAA
El requisito: la Norma de Seguridad de la HIPAA no menciona explícitamente las pruebas de penetración. Su norma de evaluación exige una evaluación periódica, tanto técnica como no técnica, de las medidas de seguridad, ámbito en el que suelen encuadrarse las pruebas de penetración. Una propuesta de actualización de diciembre de 2024 lo dejaría claro, exigiendo la realización de análisis de vulnerabilidades al menos cada seis meses y de pruebas de penetración al menos una vez al año. A mediados de 2026, dicha actualización aún no es definitiva, pero la orientación es clara.
¿Pueden las pruebas autónomas cumplir este requisito? Sí. Ni la norma de evaluación actual ni la actualización propuesta exigen la intervención de un evaluador humano. Un informe autónomo constituye hoy en día una prueba de que se ha llevado a cabo una evaluación técnica periódica, y mañana cumpliría con la obligación propuesta de realizar pruebas de penetración anuales, ya que las pruebas continuas superan la cadencia de una vez al año.
Conclusión: Sí, y estamos preparados para la norma propuesta.
Referencia: Norma de Seguridad de la HIPAA, 45 CFR 164.308(a)(8); Propuesta de norma reglamentaria de 2024 (RIN 0945-AA22).
HITRUST CSF
Requisito: HITRUST CSF es un marco certificable que utilizan las organizaciones sanitarias estadounidenses y sus proveedores para demostrar la protección de la información sanitaria protegida (PHI). Las pruebas de penetración forman parte de sus requisitos de cumplimiento técnico y de evaluación de la seguridad. Para obtener la certificación de nivel superior (r2), las pruebas deben realizarse en un periodo de 12 meses consecutivos y llevarse a cabo como un programa continuo, en lugar de como un evento anual único, con seguimiento de los resultados y repetición de las pruebas.
¿Pueden las pruebas autónomas cumplir este requisito? Sí, HITRUST no exige que la prueba de penetración la realice una persona o un evaluador acreditado, y su preferencia por un programa continuo frente a una prueba anual concuerda con las pruebas autónomas continuas. Un informe de pruebas de penetración autónomas constituye una prueba válida para el evaluador.
Conclusión: Sí, en lo que respecta al requisito de las pruebas de penetración. La validación por parte del evaluador externo constituye una fase de auditoría independiente.
Referencia: Control 06.h del Marco de Cumplimiento de HITRUST (Verificación del cumplimiento técnico).
Directrices de la FDA sobre ciberseguridad previas a la comercialización
Requisito: La guía de la FDA titulada «Ciberseguridad en los productos sanitarios: consideraciones relativas al sistema de calidad y contenido de las solicitudes previas a la comercialización» recomienda un enfoque de pruebas de seguridad por capas, pero, en la práctica, exige un informe de pruebas de penetración en las solicitudes previas a la comercialización.
¿Pueden las pruebas autónomas cumplir con estos requisitos? Sí. Las directrices se centran en los resultados: se busca evidencia de que se han realizado las pruebas, quién las ha llevado a cabo, cuál ha sido su alcance, qué se ha detectado y, lo más importante, qué medidas se han tomado al respecto. En definitiva, se trata de garantizar que los riesgos de seguridad estén bajo control. El informe de pruebas de penetración con IA de Aikido cumple con estas expectativas.
Conclusión: Sí, pero hay que detallar en la solicitud el alcance del documento, los métodos y la independencia.
Referencia: Artículo 524B de la Ley FD&C; directrices de la FDA sobre ciberseguridad previas a la comercialización (2025).
Reglamento de la UE sobre productos sanitarios (MDR)
El requisito: Los requisitos generales de seguridad y rendimiento del Reglamento sobre productos sanitarios (MDR) exigen que el software de los productos sanitarios se desarrolle según los últimos avances tecnológicos, con procesos de verificación y validación, así como medidas mínimas de seguridad informática a lo largo de todo el ciclo de vida del producto. La guía de la UE sobre ciberseguridad de los productos sanitarios (MDCG 2019-16) incluye las pruebas de penetración como parte de dicha verificación y validación, junto con las pruebas de las funciones de seguridad, el fuzzing y el análisis de vulnerabilidades.
¿Pueden las pruebas autónomas cumplir este requisito? Sí. El MDR y sus directrices son independientes del método utilizado, y una prueba de penetración autónoma constituye una prueba válida de verificación y validación. Además, las pruebas continuas se ajustan mejor al enfoque centrado en el ciclo de vida que una prueba puntual. Al igual que en las directrices de la FDA, lo fundamental es demostrar que los riesgos para la seguridad están bajo control.
Conclusión: Sí.
Referencia: Reglamento (UE) 2017/745 (MDR) de la UE, anexo I, GSPR 17.2 y 17.4; guía MDCG 2019-16.
IEC 81001-5-1
Requisito: Se trata de la norma sobre el ciclo de vida seguro del software para aplicaciones sanitarias, que se armonizará con el MDR. Sus actividades de ensayo de sistemas de software incluyen ensayos de requisitos de seguridad, ensayos de mitigación de amenazas, ensayos de vulnerabilidad y pruebas de penetración. La norma exige que las pruebas de penetración las lleve a cabo un departamento u organización independiente de los desarrolladores, y contiene una disposición específica sobre la gestión de los conflictos de intereses entre los evaluadores y los desarrolladores.
¿Puede la prueba autónoma cumplir este requisito? Sí, y el requisito de independencia juega a tu favor. Lo que exige la norma es independencia organizativa respecto a los desarrolladores, no respecto a un probador humano. Como tercero externo, Aikido cumple ese requisito de independencia, mientras que la metodología autónoma y el registro de auditoría proporcionan la actividad documentada y repetible que espera la norma.
Conclusión: Sí, la independencia de terceros cumple con el criterio.
Referencia: IEC 81001-5-1:2021, cláusulas 5.7.4 (correspondiente a SVV-4) y 5.7.5.
Automoción
ISO/SAE 21434
El requisito: La ciberseguridad en el sector de la automoción se basa en la norma ISO/SAE 21434, la norma técnica sobre ciberseguridad de los vehículos, su metodología de riesgos y el análisis de amenazas y evaluación de riesgos («TARA»). La norma señala las pruebas de penetración como una forma de validar que se han cumplido los objetivos de ciberseguridad.
¿Pueden las pruebas autónomas cumplir con este requisito? Sí, en lo que respecta a las partes a las que pueden acceder. La norma se basa en los resultados. Las pruebas de penetración son uno de los varios métodos de validación existentes (por ejemplo, fuzzing, SAST, DAST, etc.), y un informe de pruebas de penetración autónomas constituye una prueba válida, además de que las pruebas continuas también se ajustan al énfasis en el ciclo de vida. Una salvedad: los vehículos se fabrican con componentes integrados, por lo que las pruebas de seguridad física a nivel de hardware no pueden realizarse mediante métodos autónomos.
Conclusión: Sí, en lo que respecta a la superficie de ataque conectada y del backend. La norma es flexible en cuanto a los métodos y acepta las pruebas autónomas como prueba de validación.
Referencia: ISO/SAE 21434:2021, validación de la ciberseguridad (cláusula 11, RQ-11-01).
Gobierno y sector público
ENS
El requisito: el Esquema Nacional de Seguridad de España incluye las pruebas de penetración como una medida de seguridad explícita. Son obligatorias para los sistemas de categoría alta y recomendadas para los de categoría media, y los resultados recientes se incorporan a la auditoría periódica del marco.
¿Pueden las pruebas autónomas cumplir este requisito? Sí. La norma ENS especifica que lo importante es que se realicen las pruebas, no quién las introduce. Los resultados de las pruebas de penetración autónomas cumplen este requisito, y las pruebas continuas superan las frecuencias recomendadas: anual (alta) y bienal (media).
Conclusión: Sí, las pruebas de penetración autónomas cumplen el requisito.
Referencia: ENS (Real Decreto 311/2022), anexo II, medida mp.s.3; auditoría periódica con arreglo al artículo 31.
NIST SP 800-53
El requisito: la norma NIST 800-53 incluye un control específico sobre las pruebas de penetración. Establece que estas pruebas deben realizarse con la frecuencia que determine la organización, prevé la intervención de un agente o equipo independiente encargado de las pruebas de penetración e incorpora ejercicios de «equipo rojo» como medida de mejora. El control establece explícitamente que las pruebas de penetración van más allá del análisis automatizado de vulnerabilidades y deben ser llevadas a cabo por agentes y equipos con competencias demostrables.
¿Puede el testeo autónomo cumplir este requisito? En gran medida sí, más que el PCI. El control se basa en la independencia y en ir más allá del simple escaneo, dos aspectos que cumple Aikido: es un tercero independiente y, además de escanear, ejecuta y valida. El control incluso utiliza el término «agentes». La decisión final sobre si un agente autónomo demuestra las «habilidades» requeridas recae en la autoridad evaluadora, por lo que debes confirmar la aceptación con tu evaluador.
Veredicto: Sí, con el visto bueno del evaluador. Se cumplen claramente los requisitos de independencia y de «ir más allá del simple análisis».
Referencia: NIST SP 800-53 Rev. 5, control CA-8 (con CA-8(1) y CA-8(2)).
Decreto Ejecutivo de EE. UU. n.º 14028
El requisito: esta orden ejecutiva de EE. UU. impulsó el Marco de Desarrollo Seguro de Software (SSDF). El marco incluye una práctica para probar el código ejecutable con el fin de detectar vulnerabilidades, en la que se enmarcan las pruebas dinámicas, el fuzzing y las pruebas de penetración. Los proveedores de las agencias federales de EE. UU. certifican por sí mismos que cumplen el marco mediante un formulario de certificación de la CISA.
¿Puede la prueba autónoma cumplir este requisito? Sí. El marco es tecnológicamente neutro. Una prueba de penetración autónoma es una forma legítima de cumplir con la práctica de pruebas de código, y tu informe constituye la prueba que respalda la autodeclaración.
Conclusión: Sí, no es necesario realizar pruebas manuales o con personal.
Referencia: Orden Ejecutiva 14028, sección 4(e); prácticas PW.8 y PW.8.2 del SSDF del NIST (SP 800-218); formulario de certificación de desarrollo seguro de software de la CISA (OMB M-22-18).
FedRAMP
Requisito: FedRAMP exige una prueba de penetración anual conforme a sus criterios de referencia, que se lleve a cabo utilizando un conjunto obligatorio de vectores de ataque y que sea realizada por una organización de evaluación externa acreditada (3PAO) para los sistemas de nivel «Moderado» y «Alto».
¿Puede una prueba autónoma cumplir este requisito? No. La prueba de penetración que forma parte de una autorización FedRAMP, así como la prueba de penetración anual que la mantiene, deben ser realizadas por una organización de evaluación de terceros acreditada (3PAO). Una prueba autónoma realizada por una entidad que no sea una 3PAO no se aceptará en un expediente de autorización ni en una evaluación anual. Puede llevarse a cabo entre esos procesos como prueba de seguridad adicional, pero no constituye una prueba válida para la autorización.
Conclusión: No cumple el requisito. Las pruebas de penetración deben ser realizadas por una organización externa acreditada.
Referencia: Directrices de FedRAMP sobre pruebas de penetración; control CA-8 de la norma NIST SP 800-53; acreditación 3PAO por parte de A2LA.
FISMA
Requisito: La FISMA toma de la norma NIST 800-53 sus requisitos en materia de pruebas, que se aplican a través del Marco de Gestión de Riesgos del NIST. El alcance y el rigor vienen determinados por la agencia y la categorización del sistema.
¿Puede cumplir este requisito la realización de pruebas autónomas? En general, sí, siguiendo la misma lógica que el control NIST 800-53, siempre que se cumplan los requisitos de evaluación de la agencia. En el caso de los sistemas que también soliciten una autorización externa con normas de evaluadores acreditados (como FedRAMP), se aplicarán las restricciones de dicho programa.
Conclusión: Sí, pero a discreción de la agencia.
Referencia: FISMA a través de la norma NIST SP 800-53 (CA-8) y la norma NIST SP 800-37 (Marco de gestión de riesgos).
Normas internacionales
SOC 2
El requisito: SOC 2 no exige explícitamente una prueba de penetración, pero los Criterios de Servicios de Confianza de la AICPA (el organismo regulador responsable de SOC 2) sí la mencionan: el criterio de supervisión menciona las pruebas de penetración como un método de evaluación aceptable, y el criterio relativo a la detección de nuevas vulnerabilidades se respalda mediante pruebas activas. En la práctica, los auditores esperan pruebas de las pruebas de penetración, especialmente para un informe de Tipo II, dentro del periodo de auditoría, junto con pruebas de las medidas correctivas y de las nuevas pruebas.
¿Pueden las pruebas autónomas cumplir este requisito? Sí. Una prueba realizada por un tercero independiente constituye una prueba más sólida que una prueba interna, y la expresión «evaluaciones continuas o independientes» apunta hacia la realización de pruebas continuas.
Conclusión: Sí. Las pruebas continuas se corresponden directamente con las «evaluaciones continuas».
Referencia: Criterios de servicios de confianza de la AICPA CC4.1 y CC7.1
ISO/IEC 27001
El requisito: Algunos de los controles del Anexo A de la norma ISO 27001 son los puntos clave: uno sobre la gestión de vulnerabilidades técnicas, que exige «pruebas de penetración o evaluaciones de vulnerabilidad planificadas, documentadas y repetibles, realizadas por personas competentes y autorizadas»; otro sobre las pruebas de seguridad en las fases de desarrollo y aceptación; y otro sobre el ciclo de vida del desarrollo seguro.
¿Pueden las pruebas autónomas cumplir este requisito? Sí. El texto de la norma es prácticamente una descripción de las pruebas autónomas, y la reproducibilidad está integrada en el funcionamiento de los agentes. Los auditores aceptan como prueba las pruebas automatizadas y continuas realizadas por terceros, y el informe y el registro de auditoría aportan la parte «documentada».
Conclusión: Sí. Las pruebas «repetibles» encajan a la perfección.
Referencia: ISO/IEC 27001:2022, anexo A; controles 8.8, 8.25 y 8.29 de la norma ISO/IEC 27002:2022.
Normativa europea
Directiva NIS2
El requisito: La NIS2 exige a las organizaciones afectadas que gestionen las vulnerabilidades y cuenten con políticas para evaluar la eficacia de sus medidas de seguridad. El reglamento de aplicación detalla esto mediante gestión de vulnerabilidades y pruebas de seguridad automatizadas o manuales, pruebas de penetración y análisis de vulnerabilidades, que deben realizarse de forma periódica y tras cambios significativos.
¿Pueden las pruebas autónomas cumplir este requisito? Sí, de forma explícita. El reglamento de aplicación de la NIS2 es uno de los pocos instrumentos que menciona las pruebas automatizadas y las pruebas de penetración como métodos aceptables. Las pruebas autónomas continuas se ajustan a la formulación «de forma periódica y tras cambios significativos», y el informe sirve como prueba tanto para las obligaciones de gestión de vulnerabilidades como para las de evaluación de la eficacia.
Conclusión: Sí. Se contemplan expresamente las pruebas automatizadas y de penetración.
Referencia: Directiva NIS2 (UE) 2022/2555, artículo 21, apartado 2, letras e) y f); Reglamento de aplicación (UE) 2024/2690, anexo, puntos 6.10 y 7.1.
GDPR
El requisito: El RGPD exige que se establezca un proceso para comprobar, analizar y evaluar periódicamente la eficacia de las medidas de seguridad técnicas y organizativas.
¿Pueden las pruebas autónomas cumplir este requisito? Sí. El RGPD no prescribe ningún método concreto y hace hincapié en la realización de pruebas periódicas, por lo que las pruebas autónomas continuas constituyen una demostración más sólida de que el proceso está en marcha que un informe en PDF anual. El informe pone de manifiesto tanto el ciclo de pruebas como el de corrección.
Conclusión: Sí, favorece las pruebas continuas.
Referencia: RGPD (Reglamento (UE) 2016/679), artículo 32, apartado 1, letra d).
Ley de Ciberresiliencia
Requisito: La CRA exige que los productos que contengan elementos digitales se comercialicen sin vulnerabilidades explotables conocidas y que, como parte de la gestión de las vulnerabilidades a lo largo del ciclo de vida del producto, se realicen pruebas y revisiones eficaces y periódicas de la seguridad del mismo.
¿Pueden las pruebas autónomas cumplir con ello? Sí. Las pruebas «eficaces y periódicas» son lo que pentesting autónomo continuas y pentesting autónomo a lo largo de todo el ciclo de vida del producto, y el informe respalda tanto la obligación de realizar pruebas como el requisito de que no haya «vulnerabilidades explotables conocidas» en el momento del lanzamiento.
Conclusión: Sí, las pruebas «periódicas» favorecen las pruebas de penetración autónomas.
Referencia: Ley de Ciberresiliencia Reglamento (UE) 2024/2847), anexo I (parte I y parte II, punto 3); artículo 13.
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.
