It’s a simple question, but most organizations cannot answer it.
Not because they’ve been careless. Only because AI arrived in production faster than anyone could build the capability to secure it. A copilot here, a customer-facing assistant there, an automated workflow that quietly touches three internal systems. Each one is useful. Each one has a new attack surface. Each one requires much more than simply flipping a switch. And the people asked to secure them are, in most cases, doing it on instinct and adjacent experience.
That worked while nobody was checking. People are now checking.
The question is some version of: who is responsible, and how do you know people are qualified?
It rarely comes from a regulator first. It usually arrives in a customer security questionnaire, or from a cyber insurance underwriter at renewal, or in a procurement review where a prospect wants to know how you govern the AI in the product, they’re about to buy.
Most organizations can give you a name. Very few can give you evidence that the person behind it is qualified. Someone capable, usually from the security team, who has read a lot and is doing their best. That is a real answer, and it is not an evidenced one. The gap between the two is where the risk sits, commercially, before it’s ever a compliance problem.
Many reading this may even be recognizing themselves as that go-to AI security person. Then what does it mean for an individual when it comes to current credentials and expectations?
Because they came earlier.
This isn’t a failure of the security profession. It’s a timing problem.
CISSP, CISM and CEH remain foundational, and nothing about them has stopped being true. But they were designed before prompt injection, model exfiltration, training data poisoning and agentic AI risk were daily Monday-morning operational concerns. A team can be genuinely well-certified and still have no formal grounding in the specific ways AI systems fail.
Governance frameworks have the opposite problem. ISO/IEC, the EU AI Act, internal AI policies, and they describe what good looks like with real precision and then stop at the point where someone must implement it. They tell you an AI system needs to be robust, but they don’t teach anyone how to test whether it is.
So, organizations end up with two groups of people who can’t quite finish each other’s sentences. The security team knows how to defend systems but not what’s different about this one. The governance team knows what the obligation is but not what it looks like in code technical and governance. Both are right. Neither is sufficient alone.
The SANS and GIAC 2026 workforce research put a number on the consequence: 60% of CISOs named “not having the right staff” as their top challenge, against 40% choosing “not enough staff”. This shows that skills gaps decisively overtake headcount shortages.
You cannot hire your way out of the problem that is in front of us. The pool of experienced AI security practitioners is small and expensive, and everyone is bidding for it. The capability has to be built inside the team you already have, and then it has to be provable.
It’s worth being concrete, because “AI security” is a phrase that gets used to mean almost anything.
A person qualified to secure AI systems can recognize evasion attacks and classify them by how much the attacker knows about the model. They understand the difference between direct and indirect prompt injection (meaning the one that arrives inside a document your system was asked to summarize, with no user doing anything wrong) and can apply layered defenses rather than hoping a filter catches it.
They can identify data poisoning during development and model poisoning at runtime. They know what model exfiltration looks like, and how sensitive data leaks through outputs, augmentation pipelines, and logs rather than through the front door.
They can threat-model an agentic system, where the failure mode isn’t a single bad output, but a chain of authorized actions taken on a compromised premise. They can run AI red-teaming as a systematic process by scoping, executing, and validating that the fix worked.
And they can connect all of that back to ISO/IEC, GDPR, and to what the EU AI Act requires, without needing a lawyer in the room for every decision.
That’s the job. It is a real discipline, and it is learnable. And now, provable.
If you’re the person reading this because you’ve quietly become “the AI security person” at your organization, the value is more direct.
You are currently doing a job with no name and no proof. Certification gives you both. It converts a set of responsibilities you absorbed by circumstance into something that appears on your profile, that a hiring manager can filter for, and that gives you a defensible position in a conversation about scope or salary.
It also gives you a map. The single hardest thing about AI security right now is not that the information is unavailable. It’s that there is a great deal of it. Varying in quality, and with no obvious order to learn it in. A structured syllabus built from a canonical body of knowledge is worth a great deal when the alternative is assembling one yourself from conference talks and blog posts.
Any certification body can write a syllabus. The question is what it’s built on.
EXIN AI Security Professional is built on the OWASP AI Exchange an open, vendor-neutral body of knowledge on securing AI systems, developed by 165+ practitioners, and feeding directly into ISO/IEC 27090 and the European standard supporting the EU AI Act.
That matters for a practical reason. When your AI systems are assessed by an auditor, a customer, or a regulator, the assessor will be working from a framework. That framework has been shaped by the OWASP AI Exchange. Training your people on the Exchange means training them on the same reference point the assessment will use, rather than on someone’s interpretation of it.
Rob van der Veer
Founder, OWASP AI Exchange · Chief AI Officer, Software Improvement Group
The courseware was written by Rob van der Veer, who founded the AI Exchange and is Chief AI Officer at Software Improvement Group. As he puts it: the knowledge is open, and free to anyone. What has been missing is a way for someone to demonstrate they understand it.
That’s the specific gap this closes.
The OWASP AI Exchange remains free at owaspai.org. The certification makes the expertise testable.
Deliberately, there are no prerequisites.
Comparable credentials require an existing senior security certification, which sounds reasonable until you notice who it excludes: the data protection officer who inherited AI governance, the risk analyst writing the AI policy, the ML engineer whose model is now in a regulated workflow. These are the people already carrying responsibility. Locking them out of the certification that describes their job would be an odd way to close a skills gap.
So AISP is open to security professionals, privacy and data protection leads, governance and risk analysts, AI and ML engineers, and the technology leaders accountable for all of them.
Back to where we started.
When someone asks who in your organization is qualified to secure your AI, the goal is to be able to answer with a name, a credential, and a date, not just with the hope that you have it right.
That is a small change in wording and a large change in position. It’s the difference between asserting competence and evidencing it, and increasingly it’s the difference between passing a security review and explaining why you didn’t.
View full Press release here
EXIN AI Security Professional is available now at aisp.exin.com and through EXIN’s global network of accredited training providers.
Want to become an accredited training provider for AISP? Learn more at aisp.exin.com/for-training-partners
Are you a corporate company interested in proving the skills of your current AI-driven team? Visit aisp.exin.com/for-corporate-partners