Which requirements still need human penetration testing even if AI testing exists?

Prescriptive regimes such as PCI DSS, some FedRAMP engagements, and TLPT-style exercises under DORA still require human or accredited involvement for the formal test. In those cases, AI testing can support continuous security, but it should not be substituted for the mandated engagement.

Why This Matters for Security Teams

Human penetration testing remains mandatory in some compliance and assurance paths because AI-based testing does not yet satisfy every legal, contractual, or assessor requirement. The practical issue is not whether AI can find weaknesses, but whether the result is accepted as an official test evidence set. In regimes that require attestation, independence, or accredited oversight, the testing method matters as much as the findings.

This distinction is especially important for payment, regulated financial services, and public sector environments where an assessment must be defensible to auditors and third parties. AI can accelerate reconnaissance, fuzzing, and control validation, but it cannot automatically replace the procedural requirements of a formal engagement. Guidance from NIST AI 600-1 Generative AI Profile also reinforces that generative systems need governance, validation, and human accountability rather than blind reliance on outputs.

The risk is that teams treat AI testing as a compliance shortcut and discover too late that the engagement was not acceptable for certification, audit, or customer assurance. In practice, many security teams encounter this only after the formal test has already been scheduled, rather than through intentional control planning.

How It Works in Practice

In operational terms, AI testing is best understood as an enhancement layer, not a universal substitute. It can continuously scan code, infrastructure, APIs, and exposed services, then propose likely attack paths or misconfigurations. Human penetration testing still enters where the requirement is to perform a formal, scoped, and accountable assessment that meets a specific standard or regulatory expectation.

Security teams usually separate the work into three parts:

• AI-driven discovery for breadth, speed, and repeatability.
• Human-led exploitation and judgment for chained attacks, business logic flaws, and safe handling of live environments.
• Formal evidence collection for the assessor, auditor, or certification body.

This matters because frameworks often care about who performed the test, how independence was preserved, and whether the output can be signed off by an approved party. For example, PCI DSS assessment expectations are tied to documented testing and validation, while DORA-style threat-led exercises and some public sector engagements can require specific human involvement or accredited providers. AI can support these activities, but it usually cannot be the sole basis for the formal conclusion. The current guidance suggests treating AI output as input to the test plan, not as the test record itself.

Teams that want to operationalise this well should define which assets are eligible for AI-assisted testing, which findings require human verification, and which reports can be reused for audit evidence. They should also validate tool output against a known baseline, because generative tools can miss chained vulnerabilities or overstate exploitability. This is especially useful when paired with NIST AI Risk Management Framework expectations for governance and measurement, alongside process controls that preserve tester accountability. These controls tend to break down when a third-party engagement requires accredited human sign-off but the internal team assumes automated results will be accepted without re-execution.

Common Variations and Edge Cases

Tighter compliance requirements often increase cost and scheduling friction, requiring organisations to balance faster continuous testing against formal assurance obligations. The hard part is that the answer changes by regime, assessor, and scope. There is no universal standard for this yet, so current guidance should be read conservatively rather than aspirationally.

One common edge case is a hybrid engagement where AI tools are used to support scoping, attack-path generation, or pre-testing, while a human tester performs the mandated final assessment. Another is a contract that names a specific testing methodology or credentialed provider, which can make purely automated testing non-compliant even if the technical coverage is strong. For cloud and software supply chain testing, AI can be highly effective at continuous validation, but formal artefacts still need human review where contractual language or regulatory text demands it.

This is also where identity and privilege controls matter. If AI testing is allowed to exercise credentials, tokens, or non-human identities during validation, the organisation should define expiry, approval, and monitoring rules so testing does not create standing access. The safest pattern is to align AI testing with human-led governance rather than letting it operate as an unsupervised substitute for regulated assurance. For broader AI governance context, the OWASP Top 10 for Large Language Model Applications and MITRE ATLAS help frame the risks of over-trusting automated security outputs.

Related resources from NHI Mgmt Group

• Why do AI-generated security summaries still need human governance?
• Why do AI SRE agents still need human review?
• Why do AI-built features still require human judgment in identity design?
• Why do AI agent sandboxes still leak secrets even when egress policies are enforced?