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ácese hasta el final del artículo para obtener más información detallada sobre cómo funciona el pentesting de IA con diferentes frameworks.
Lo que buscan los auditores
En resumen, los auditores o las normas buscan lo siguiente en una prueba de penetración:
- Una metodología documentada y repetible, no una exploración ad hoc
- Independencia, y que el probador no sea el mismo equipo que construye o ejecuta el sistema
- Pruebas reales de eficacia, yendo más allá del escaneo automatizado de vulnerabilidades
- Evidencia, como hallazgos, gravedad y prueba
- Remediación y nuevas pruebas de los hallazgos
Si su pentest cumple estos criterios, ya sea realizado por IA o por humanos, es muy probable que su auditor lo 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 decirle a un auditor "realizamos un pentest contra los activos de producción en marzo", puede mostrarle un historial de pruebas de seguridad que se encuentra junto a 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: Especificidades de la industria
Industria financiera
PCI DSS
El requisito: PCI DSS es el marco más prescriptivo en este ámbito. Requiere una metodología documentada de pruebas de penetración, pruebas de penetración internas y externas al menos una vez al año y después de cambios significativos, volver a probar cualquier corrección realizada, y pruebas separadas de los controles que segmentan el entorno de datos del titular de la tarjeta (con mayor frecuencia para los proveedores de servicios). La prueba debe ser realizada por un probador cualificado que sea organizacionalmente independiente de los sistemas bajo prueba.
¿Puede el testing autónomo satisfacerlo? No. La propia Guía de Pruebas de Penetración de PCI establece una distinción entre una prueba de penetración y un escaneo de vulnerabilidades: un escaneo es automatizado, mientras que una prueba de penetración es un proceso manual de explotación que se basa en la habilidad de un probador cualificado e independiente. Las herramientas automatizadas pueden ayudar, pero la guía considera el trabajo manual como la prueba en sí. Una prueba de penetración autónoma no será aceptada como la pentest de PCI.
Los agentes de Aikido explotan la lógica de negocio, BOLA y fallos encadenados, por lo que vale la pena ejecutarlos como pruebas de seguridad continuas junto con el compromiso requerido, incluso después de cambios significativos. Esto es un beneficio de seguridad y una fuente de evidencia de remediación, no una aprobación de PCI. Planifique la pentest humana cualificada por separado.
Veredicto: No cumple el requisito. La prueba de penetración debe ser realizada por un probador humano cualificado. El testing autónomo no será aceptado como la pentest de PCI.
Referencia: Requisito 11.4 de PCI DSS v4.0.1 (11.4.1 a 11.4.6); Guía de Pruebas de Penetración de PCI SSC.
DORA
El requisito: DORA tiene dos niveles de testing. El nivel general es 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 requiere Pruebas de Penetración Dirigidas por Amenazas (TLPT) al menos una vez cada tres años para entidades financieras significativas, con reglas estrictas sobre quién puede realizarlas.
¿Puede el testing autónomo satisfacerlo? Sí para el programa general, no para TLPT. El programa general es flexible en cuanto a métodos y sus métodos listados incluyen las pruebas de penetración, por lo que el testing autónomo continuo se ajusta a él y va más allá del mínimo periódico. TLPT es diferente. Se basa en el marco TIBER-EU del BCE y requiere red-teamers externos cualificados y un proveedor externo de inteligencia de amenazas, con las instituciones de crédito significativas obligadas a utilizar exclusivamente probadores externos. Es decir, por diseño, un compromiso de red-team humano.
Veredicto: Sí para el programa general de testing. No cumplirá el requisito de TLPT, que exige red-teamers humanos externos. Utilice Aikido para ejecutar y evidenciar el programa general. El TLPT es un compromiso separado que debe ser realizado por humanos.
Referencia: DORA (Reglamento (UE) 2022/2554) Artículos 24 y 25 (programa de testing), Artículos 26 y 27 (TLPT).
Regla de Salvaguardias de la FTC
El requisito: La Regla de Salvaguardias de la FTC rige cómo las instituciones financieras protegen la información del cliente. Requiere pruebas regulares de la eficacia de sus salvaguardias, y le ofrece dos formas de hacerlo: monitorización continua, o, en su ausencia, una prueba de penetración anual más evaluaciones de vulnerabilidad al menos cada seis meses. También se requiere testing después de cambios importantes en las operaciones.
¿Puede el testing autónomo satisfacerlo? Sí. La monitorización continua se establece como una alternativa directa a la prueba de penetración anual, que es lo que proporciona el testing autónomo continuo. Para una institución que prefiera la ruta periódica, un programa autónomo proporciona tanto la prueba anual como las evaluaciones semestrales. La regla no establece ningún requisito humano o de acreditación para el probador.
Veredicto: Sí. La monitorización continua es un sustituto explícito de la pentest anual.
Referencia: Regla de Salvaguardias de la FTC, 16 CFR 314.4(d) y 314.4(d)(2).
Regulación de Ciberseguridad de NYDFS
El requisito: La regulación de ciberseguridad para servicios financieros de Nueva York se aplica a bancos, aseguradoras y otras entidades con licencia en Nueva York, y se referencia más allá del estado como una línea base del sector financiero. Su sección de pruebas de penetración requiere testing basado en su evaluación de riesgos, estructurado como monitorización continua o una prueba de penetración anual junto con evaluaciones de vulnerabilidad semestrales.
¿Puede el testing autónomo satisfacerlo? Sí. Al igual que con la regla de la FTC, la regulación trata la monitorización continua y la prueba de penetración anual como alternativas. El testing autónomo continuo se alinea con la ruta de monitorización continua, y para las entidades que eligen la ruta periódica, también produce la prueba anual y las evaluaciones semestrales. La regulación no establece ningún requisito de acreditación para el probador.
Veredicto: Sí. La monitorización continua satisface el requisito por sí misma.
Referencia: Regulación de Ciberseguridad de NYDFS, 23 NYCRR 500.5 (Segunda Enmienda, 2023).
Sector Sanitario
HIPAA
El requisito: La Regla de Seguridad de HIPAA no nombra explícitamente las pruebas de penetración. Su estándar de evaluación requiere una evaluación técnica y no técnica periódica de sus salvaguardias, que es el punto en el que suelen encajar las pentests. Una actualización propuesta de diciembre de 2024 lo haría explícito, exigiendo escaneo de vulnerabilidades al menos cada seis meses y pruebas de penetración al menos una vez al año. A mediados de 2026, esa actualización no es definitiva, pero la dirección es clara.
¿Puede el testing autónomo satisfacerlo? Sí. Ni el estándar de evaluación actual ni la actualización propuesta exigen un probador humano. Un informe autónomo es evidencia de una evaluación técnica periódica hoy, y satisfaría la obligación propuesta de pentest anual mañana, con el testing continuo superando una cadencia de una vez al año.
Veredicto: Sí, y preparado para la regla propuesta.
Referencia: Regla de Seguridad de HIPAA, 45 CFR 164.308(a)(8); NPRM de 2024 (RIN 0945-AA22).
HITRUST CSF
El requisito: HITRUST CSF es un marco certificable que las organizaciones sanitarias de EE. UU. y sus proveedores utilizan para demostrar la protección de la Información Sanitaria Protegida (PHI). Las pruebas de penetración se incluyen en sus requisitos de cumplimiento técnico y evaluación de seguridad. Para la certificación superior (r2), la prueba debe realizarse en un plazo de 12 meses y ejecutarse como un programa continuo en lugar de un único evento anual, con los hallazgos registrados y vueltos a probar.
¿Pueden satisfacerlo las pruebas autónomas? Sí. HITRUST no exige un probador humano o acreditado para la prueba de penetración, y su preferencia por un programa continuo en lugar de un evento anual se alinea con las pruebas autónomas continuas. Un informe de prueba de penetración autónoma es una evidencia válida para el evaluador.
Veredicto: Sí para el requisito de pruebas de penetración. La validación del Evaluador Externo es un paso de auditoría independiente.
Referencia: Control 06.h de HITRUST CSF (Verificación de Cumplimiento Técnico).
Guía de ciberseguridad precomercialización de la FDA
El requisito: La guía de la FDA Ciberseguridad en Dispositivos Médicos: Consideraciones del Sistema de Calidad y Contenido de las Presentaciones Precomercialización recomienda un enfoque de pruebas de seguridad por capas, pero en la práctica exige un informe de prueba de penetración durante las presentaciones precomercialización.
¿Pueden satisfacerlo las pruebas autónomas? Sí. La guía está orientada a resultados: busca evidencia de que se realizaron pruebas, por quién, con qué alcance, qué se encontró y, lo más importante, qué se hizo al respecto. En última instancia, se trata de asegurar que los riesgos de seguridad estén bajo control. El informe de pentest de IA de Aikido cumple con esas expectativas.
Veredicto: Sí, pero documente el alcance, los métodos y la independencia en la presentación.
Referencia: Sección 524B de la Ley FD&C; guía de ciberseguridad precomercialización de la FDA (2025).
Reglamento de Dispositivos Médicos de la UE (MDR)
El requisito: Los requisitos generales de seguridad y rendimiento del MDR esperan que el software de dispositivos médicos se desarrolle según el estado del arte, con verificación y validación y medidas mínimas de seguridad de TI a lo largo de la vida útil del producto. La guía de ciberseguridad para dispositivos médicos de la UE (MDCG 2019-16) nombra las pruebas de penetración como parte de esa verificación y validación, junto con las pruebas de características de seguridad, fuzzing y escaneo de vulnerabilidades.
¿Pueden satisfacerlo las pruebas autónomas? Sí. El MDR y su guía son neutrales en cuanto al método, y una prueba de penetración autónoma es una evidencia válida de verificación y validación. Las pruebas continuas también se ajustan mejor al énfasis del ciclo de vida que una prueba única. Similar a la guía de la FDA, se trata de demostrar que los riesgos de seguridad están bajo control.
Veredicto: Sí.
Referencia: MDR de la UE (Reglamento (UE) 2017/745) Anexo I, GSPR 17.2 y 17.4; guía MDCG 2019-16.
IEC 81001-5-1
El requisito: Este es el estándar de ciclo de vida de software seguro para software de salud, y se armonizará para el MDR. Sus actividades de prueba de sistemas de software incluyen pruebas de requisitos de seguridad, pruebas de mitigación de amenazas, pruebas de vulnerabilidad y pruebas de penetración. El estándar exige que las pruebas de penetración sean realizadas por un departamento u organización independiente de los desarrolladores, y tiene una disposición separada sobre la gestión de conflictos de interés entre probadores y desarrolladores.
¿Pueden satisfacerlo las pruebas autónomas? Sí, y el requisito de independencia es un punto a su favor. Lo que el estándar exige es independencia organizacional de los desarrolladores, no un probador humano. Como tercero externo, Aikido satisface ese requisito de independencia, mientras que la metodología autónoma y la pista de auditoría proporcionan la actividad documentada y repetible que el estándar espera.
Veredicto: Sí, la independencia de terceros satisface el estándar.
Referencia: Cláusula 5.7.4 (mapeada a SVV-4) y 5.7.5 de IEC 81001-5-1:2021.
Automoción
ISO/SAE 21434
El requisito: La ciberseguridad automotriz se basa en ISO/SAE 21434, el estándar de ingeniería para la ciberseguridad de vehículos, su metodología de riesgo y el Análisis y Evaluación de Riesgos de Amenazas («TARA»). El estándar nombra las pruebas de penetración como una forma de validar que se cumplieron los objetivos de ciberseguridad.
¿Pueden satisfacerlo las pruebas autónomas? Sí, para las partes a las que puede llegar. El estándar se basa en resultados. Las pruebas de penetración son un método de validación entre varios (p. ej., fuzzing, SAST, DAST, ...), y un informe de pentest autónomo es una evidencia válida, con pruebas continuas que también se ajustan al énfasis del ciclo de vida. Una advertencia: los vehículos se construyen sobre componentes embebidos, las pruebas de seguridad física a nivel de hardware no se pueden realizar mediante métodos autónomos.
Veredicto: Sí para la superficie de ataque conectada y de backend. El estándar es flexible en cuanto al método y acepta las pruebas autónomas como evidencia de validación.
Referencia: Validación de ciberseguridad ISO/SAE 21434:2021 (Cláusula 11, RQ-11-01).
Sector público y gubernamental
ENS
El requisito: El Esquema Nacional de Seguridad de España enumera las pruebas de penetración como una medida de seguridad explícita. Es obligatorio para sistemas de categoría alta y recomendado para sistemas de categoría media, y los resultados recientes alimentan la auditoría periódica del marco.
¿Pueden satisfacerlo las pruebas autónomas? Sí. El ENS especifica que se realicen pruebas, no quién las introduce. Los resultados de pentest autónomos satisfacen la medida, y las pruebas continuas superan las frecuencias anuales (alta) y bienales (media) recomendadas.
Veredicto: Sí, los pentests autónomos cumplen el requisito.
Referencia: ENS (Real Decreto 311/2022) Anexo II medida mp.s.3; auditoría periódica según el Artículo 31.
NIST SP 800-53
El requisito: NIST 800-53 cuenta con un control específico de pruebas de penetración. Exige pruebas de penetración con la frecuencia que la organización establezca, prevé un agente o equipo de penetración independiente y añade ejercicios de red team como mejora. El control establece explícitamente que las pruebas de penetración van más allá del escaneo automatizado de vulnerabilidades y son realizadas por agentes y equipos con habilidades demostrables.
¿Puede el testing autónomo satisfacerlo? En gran medida sí, más que PCI. El control se basa en la independencia y en ir más allá del escaneo, ambos aspectos que Aikido cumple: es un tercero independiente, y explota y valida en lugar de solo escanear. El control incluso utiliza la palabra «agentes». El juicio residual, sobre si un agente autónomo demuestra las «habilidades» requeridas, recae en la autoridad evaluadora, por lo que debe confirmar la aceptación con su evaluador.
Veredicto: Sí, con el acuerdo del evaluador. La independencia y el «más allá del escaneo» se cumplen claramente.
Referencia: NIST SP 800-53 Rev. 5, control CA-8 (con CA-8(1) y CA-8(2)).
US EO 14028
El requisito: Esta orden ejecutiva de EE. UU. impulsó el Marco de Desarrollo de Software Seguro (SSDF). El marco incluye una práctica para probar código ejecutable con el fin de encontrar vulnerabilidades, que es donde se sitúan las pruebas dinámicas, el fuzzing y las pruebas de penetración. Los proveedores de las agencias federales de EE. UU. auto-certifican el cumplimiento del marco en un formulario de certificación de CISA.
¿Puede el testing autónomo satisfacerlo? 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 prueba de código, y su informe es la evidencia que respalda la auto-certificación.
Veredicto: Sí, no se requiere testing humano o manual.
Referencia: EO 14028 Sección 4(e); NIST SSDF (SP 800-218) práctica PW.8 y PW.8.2; Formulario de Certificación de Desarrollo de Software Seguro de CISA (OMB M-22-18).
FedRAMP
El requisito: FedRAMP exige una prueba de penetración anual en todas sus líneas base, realizada según un conjunto obligatorio de vectores de ataque y llevada a cabo por una organización de evaluación de terceros acreditada (una 3PAO) para sistemas Moderados y Altos.
¿Puede el testing autónomo satisfacerlo? No. La prueba de penetración que respalda una autorización FedRAMP, y el pentest anual que la mantiene, deben ser realizados por una 3PAO acreditada. Una prueba autónoma realizada por una organización no 3PAO no será aceptada en un paquete de autorización o en una evaluación anual. Puede ejecutarse entre esos compromisos como testing de seguridad adicional, pero eso no es evidencia de autorización.
Veredicto: No cumple el requisito. Los pentests deben ser realizados por una organización de terceros acreditada.
Referencia: Guía de Pruebas de Penetración de FedRAMP; control CA-8 de NIST SP 800-53; acreditación 3PAO por A2LA.
FISMA
El requisito: FISMA hereda sus expectativas de testing de NIST 800-53, aplicadas a través del Marco de Gestión de Riesgos de NIST. El alcance y el rigor son establecidos por la agencia y la categorización del sistema.
¿Puede el testing autónomo satisfacerlo? Generalmente sí, la misma lógica que el control NIST 800-53, sujeto a los requisitos de evaluación de la agencia. Para sistemas que también buscan una autorización externa con reglas de evaluador acreditado (como FedRAMP), se deben aplicar las restricciones de ese programa.
Veredicto: Sí, pero a discreción de la agencia.
Referencia: FISMA a través de NIST SP 800-53 (CA-8) y NIST SP 800-37 (Marco de Gestión de Riesgos).
Estándares internacionales
SOC 2
El requisito: SOC 2 no exige explícitamente un pentest, pero los Criterios de Servicios de Confianza del AICPA (el organismo rector detrás de SOC 2) lo sugieren: el criterio de monitorización menciona las pruebas de penetración como un método de evaluación aceptable, y el criterio sobre la detección de nuevas vulnerabilidades se apoya en pruebas activas. En la práctica, los auditores esperan evidencia de pentest, especialmente para un informe Tipo II, dentro del período de auditoría, con evidencia de remediación y re-prueba.
¿Puede el testing autónomo satisfacerlo? Sí. Una prueba independiente de terceros es una evidencia más sólida que una prueba interna, y el lenguaje de «evaluaciones continuas o separadas» apunta hacia el testing continuo.
Veredicto: Sí. El testing continuo se corresponde directamente con las «evaluaciones continuas».
Referencia: Criterios de Servicios de Confianza del AICPA CC4.1 y CC7.1
ISO/IEC 27001
El requisito: Algunos de los controles del Anexo A de la ISO 27001 son clave: uno sobre la gestión de vulnerabilidades técnicas, que exige «pruebas de penetración o evaluaciones de vulnerabilidades planificadas, documentadas y repetibles realizadas por personas competentes y autorizadas»; otro sobre las pruebas de seguridad en el desarrollo y la aceptación; y otro sobre el ciclo de vida de desarrollo seguro.
¿Puede el testing autónomo satisfacerlo? Sí. El lenguaje de la norma es casi una descripción del testing autónomo, y la reproducibilidad está integrada en el funcionamiento de los agentes. Los auditores aceptan el testing automatizado y continuo de terceros como evidencia en este caso, y el informe y la pista de auditoría proporcionan la parte «documentada».
Veredicto: Sí. El testing «repetible» encaja de forma natural.
Referencia: ISO/IEC 27001:2022 Anexo A; ISO/IEC 27002:2022 controles 8.8, 8.25 y 8.29.
Regulaciones Europeas
Directiva NIS2
El requisito: NIS2 exige a las organizaciones incluidas en su ámbito que gestionen las vulnerabilidades y que dispongan de políticas para evaluar la eficacia de sus medidas de seguridad. El reglamento de ejecución lo detalla con requisitos de gestión de vulnerabilidades y pruebas de seguridad automatizadas o manuales, pruebas de penetración y escaneos de vulnerabilidades, realizados de forma regular y tras cambios significativos.
¿Puede el testing autónomo satisfacerlo? Sí, explícitamente. El reglamento de ejecución de NIS2 es uno de los pocos instrumentos que nombra el testing automatizado y las pruebas de penetración como métodos aceptables. El testing autónomo continuo coincide con el lenguaje de «forma regular y tras cambios significativos», y el informe es evidencia tanto para las obligaciones de gestión de vulnerabilidades como para las de evaluación de la eficacia.
Veredicto: Sí. El testing automatizado y las pruebas de penetración están expresamente contemplados.
Referencia: Directiva NIS2 (UE) 2022/2555 Artículo 21(2)(e) y (f); Reglamento de Ejecución (UE) 2024/2690 Anexo puntos 6.10 y 7.1.
GDPR
El requisito: El GDPR exige un proceso para probar, evaluar y valorar regularmente la eficacia de sus medidas de seguridad técnicas y organizativas.
¿Puede el testing autónomo satisfacerlo? Sí. El GDPR no prescribe un método y enfatiza el testing regular, por lo que el testing autónomo continuo es una demostración más sólida de un proceso continuo que un PDF anual. El informe evidencia tanto el testing como el ciclo de remediación.
Veredicto: Sí, favorece el testing continuo.
Referencia: GDPR (Reglamento (UE) 2016/679) Artículo 32(1)(d).
Ley de Ciberresiliencia
El requisito: La Ley de Ciberresiliencia exige que los productos con elementos digitales se comercialicen sin vulnerabilidades explotables conocidas y, como parte de la gestión de vulnerabilidades a lo largo de la vida útil del producto, se apliquen pruebas y revisiones efectivas y regulares de la seguridad del producto.
¿Puede el testing autónomo satisfacerlo? Sí. El testing «efectivo y regular» es lo que el pentesting autónomo continuo ofrece a lo largo del ciclo de vida del producto, y el informe respalda tanto la obligación de testing como el umbral de «no vulnerabilidades explotables conocidas» en el lanzamiento.
Veredicto: Sí, el testing «regular» favorece el pentesting autónomo.
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.
