Build a Secure AI Program in Your Organization

A threat model for one app, a red-team test for another and a policy that few people have read: that is not yet AI security. It becomes AI security when the pieces form a program — with an owner, a scope, a repeating cycle and evidence that the controls work. The gap is real. In IBM’s 2025 breach study, 13% of organizations reported breaches of AI models or applications, and 97% of those had no AI access controls in place. Of all breached organizations in the study, 63% had no AI governance policy or were still developing one (Source: IBM and Ponemon Institute, Cost of a Data Breach Report 2025, ibm.com).

This is part 5, the last part of Level 4 and of our AI Security learning path. It brings the earlier parts together: the frameworks from part 1, the attack classes from part 2, the privacy techniques from part 3 and the evals from part 4. You will learn the eight components of a program, who owns what, how to judge your maturity, what to do in the first 90 days and which metrics show progress. The online shop of this level, with its four AI systems, serves as the example one last time.

A program, not a project

A project ends. AI risks do not: providers release new models, teams adopt new tools, and attackers adapt. A program therefore works like a management system — the Plan-Do-Check-Act cycle that ISO/IEC 42001 uses, as described in part 1 on governance frameworks. You plan controls, run them, check whether they work and improve them.

You do not have to invent the content. Several well-known guides describe what belongs in it:

• Google’s Secure AI Framework (SAIF, 2023) names six core elements, from extending security foundations to AI to placing AI risks in the context of business processes.
• The Guidelines for secure AI system development, published in 2023 by the UK’s NCSC and the US agency CISA with partner agencies from other countries, cover four areas: secure design, development, deployment, and operation and maintenance.
• The UK Code of Practice for the Cyber Security of AI (January 2025) sets 13 principles along the AI life cycle, from design to end of life.

Together with the NIST AI RMF from part 1 and with the OWASP Top 10 for LLM applications and MITRE ATLAS from earlier levels, they give you a shared vocabulary. The program’s job is to turn that vocabulary into routines.

Eight components and their owners

An AI security program needs eight components. Each needs an owner and produces evidence:

Four components deserve a closer look. The policy should fit on one page: which tools are approved, which data may go into which tool, who approves a new AI use case and where people report problems. A short policy that people remember protects more than a long one that nobody reads. Review it at least twice a year, because the tools change quickly.

The inventory must include AI that nobody registered: tools that employees use on their own, AI features that vendors switch on in existing software, and models that teams download. Level 2 explains how to find this shadow AI without turning it into a blame game. Incident response needs its own playbooks, because AI incidents look different: a leaked system prompt, a poisoned knowledge base, an agent that acted on hidden instructions. Level 3 covers AI incident response. Legal duties set deadlines here. Under the GDPR, a personal data breach must be reported to the authority within 72 hours where feasible. Under the AI Act, providers of high-risk systems must report serious incidents.

Monitoring depends on the right logs. Level 3 listed what an agent should record and which properties logs need for an investigation. At program level, the questions are coverage and ownership. Does every system in the inventory send its logs to one central place, and can you at least export the logs of bought tools? Who reviews the alerts, and how fast? Then define alerts for the patterns from part 2: many near-identical queries from one account, sudden shifts in a model’s decisions, or tool calls at unusual times.

Tools can support several components, but none of them is the program. According to the vendors, Airia governs AI agents, models, tools and data access with policies and audit evidence. Sentaro checks emails for phishing, which AI makes more convincing. Bitdefender protects business devices against ransomware, phishing and fileless attacks. Each one is a control inside the program, with an owner and a metric. More tools are in the AI Security section.

AiriaSecurity & Governance · AI at the coreOrchestration platform for enterprises to build and manage AI solutions securely. SentaroSecurity & Governance · AI at the coreEmail security for small and mid-sized businesses that checks the context and intent of messages and warns of phishing. BitdefenderSecurity & Governance · Software with AI featuresCybersecurity for small and mid-sized businesses: protection against ransomware, phishing and fileless attacks.

Short descriptions from our tool comparison, based on the vendors' information — not tested by ABXK.

Where do you stand? A simple maturity model

A maturity model helps you decide what to do next. The five stages below are a simplified model for orientation, not a standard:

1. Ad hoc: AI is in use, but nobody has an overview. Security depends on individuals.
2. Aware: An inventory and a first policy exist, and owners are named.
3. Defined: Every new AI system gets a risk assessment and follows a secure development standard. Incident playbooks exist.
4. Measured: Evals, monitoring and red-team tests produce metrics, and management sees them regularly.
5. Improving: Incidents, tests and metrics lead to changes in a steady cycle; an external audit, such as for ISO/IEC 42001, becomes realistic.

To find your stage, rate each of the eight components with four questions: Does it exist? Is it written down? Is it followed? Is it measured? Your overall stage is set by your weakest components, not your strongest.

The shop is at stage 2: it knows its four AI systems and has a policy, but only the support assistant went through a threat model. Its goal for the next quarter is stage 3. Do not skip stages. Metrics without defined processes measure chaos, and an audit before stage 3 mainly produces a list of gaps.

The first 90 days

Ninety days are a realistic period to move up one stage if you focus on a few systems. The plan below assumes a small team: a sponsor from management, one AI security lead and the owners of the main AI systems.

Which systems come first? Rank the inventory with four questions. Does the system make or prepare decisions about people? Does it touch personal or confidential data? Can it act without a human check, for example send emails or issue refunds? Can customers or the public reach it? Each yes raises the priority. To build the inventory itself, combine the discovery sources from the Level 2 part on shadow AI, and ask about use, not about rule-breaking.

For the shop, the riskiest system is the bought tool that pre-sorts job applications. It prepares decisions about people and is high-risk under the AI Act. So it gets the first full assessment, a review of the vendor’s documentation and human oversight in the hiring team. The support assistant follows with the eval suite from part 4.

Metrics that show whether the program works

Good metrics are few, have an owner, show a trend and lead to a decision. Avoid counting activity, such as the number of policies written. Measure coverage and effect instead. Report to management every quarter in the same format: the inventory, the top risks with their owners, the metric trends, the incidents and the decisions you need. The same format makes trends visible and helps the sponsor act on them. These metrics are a good start: