What an agentic AI audit trail must capture
Auditing an agentic AI system after an incident requires a different evidence set than auditing a deterministic system. The audit trail must capture not just what happened, but what the model decided and why — and most implementations miss the latter.
Presenting AI risk to leadership without the 40-slide deck
Most AI risk presentations to leadership are too long, too technical, and too focused on the threats rather than the decision. This piece defines the structure that gets a governance decision out of a leadership meeting.
The security terms an AI vendor contract needs
Standard vendor contracts cover SLAs, data processing, and confidentiality. AI vendor contracts need additional terms: model-change notification, training data restrictions, incident notification, and re-assessment rights. This piece defines the clause language.
Preparing for an ISO 42001 internal audit
ISO 42001 requires periodic internal audits of the AI management system. This piece defines what an internal audit must cover, what evidence auditors look for, and the gaps that appear most often in organisations preparing for their first audit.
What evidence an AI security review should produce
A review that produces only a slide deck is not a review. The evidence an AI security review produces must survive a regulator question, a procurement audit, or a post-incident inquiry. Here is what that evidence needs to include.
AI governance that does not become bureaucracy
The failure mode of AI governance is not too little process — it is too much. When the review process becomes the obstacle, teams route around it. This piece defines the governance structures that provide accountability without creating friction.
Finding the AI vendors no one formally approved
Shadow AI — AI tools adopted without formal security review — is in every organisation. This piece defines a practical discovery process: where shadow AI hides, how to find it, and how to bring it into a formal review without alienating the teams using it.
Roles and responsibilities under ISO 42001
ISO 42001 requires documented roles and responsibilities for AI management. This piece defines the roles the standard expects, how they map to typical organisational structures, and what each role must be able to demonstrate.
Re-assessment triggers — the field most dispositions skip
A disposition without re-assessment triggers is a decision without an expiry. It stays valid regardless of what the AI system becomes. Re-assessment triggers are the mechanism that keeps a disposition honest over time.
When to re-assess an AI vendor
An AI vendor assessment is not a one-time exercise. Model updates, new features, changed data-handling terms, incidents at the vendor, and expanding use cases in your organisation are all triggers that require a fresh assessment.
Human-in-the-loop boundaries that actually hold
Human-in-the-loop is the most common control in agentic AI risk plans. It is also the control most often specified in a way that does not hold. This piece defines what a robust HITL boundary requires — and the failure modes that hollow it out.
Who runs the AI security review — roles and hand-offs
AI security reviews involve more people than a single security team: architects who describe the system, security engineers who threat-model it, governance leads who accept the risk, and DPOs who validate data handling. This piece maps the hand-offs.
Preserving evidence after an AI incident
AI incident evidence degrades in ways that traditional IT incident evidence does not. Model context windows are ephemeral, log retention is often incomplete, and model weights change. This piece defines the evidence-preservation steps to take immediately after an AI incident.
The anatomy of an AI evidence pack
An AI evidence pack is the complete set of artefacts a governance committee needs to make a defensible decision. This piece defines what goes into one — and why the order and labelling of the artefacts matters as much as the content.
Building an AI management system (AIMS) from scratch
An AI management system is the governance infrastructure for AI: the policies, procedures, roles, and records that allow an organisation to make defensible AI decisions at scale. This piece defines what it takes to build one.
Classifying AI incidents — a framework for security teams
AI incidents do not fit cleanly into standard incident classification schemes. A model behaving unexpectedly is not the same as a data breach, but it may become one. This piece defines an AI-specific incident classification framework.
The restricted-pilot pattern for risky AI systems
A restricted pilot is a formal disposition state: the AI system may operate within a defined scope, on the condition that named controls are in place and named triggers will initiate a re-review. This piece defines how to write a restricted-pilot disposition.
Conditional approval for AI systems — making conditions stick
Conditional approval is the most common disposition for AI systems that are not ready for unrestricted production. The conditions are the whole point — and most conditional approvals are written in a way that makes the conditions unenforceable.
Model-change notification — the vendor clause procurement teams forget
Vendors change the underlying model in their AI products without notifying customers. The security review that justified the original deployment may no longer be valid. This piece defines the contractual clause and the review trigger that keeps the assessment current.
AI risk acceptance — who actually signs
Risk acceptance for AI systems is often attributed to a committee rather than a named individual. When something goes wrong, no one is accountable. This piece defines who should sign risk acceptance for AI systems and what that signature requires.
Writing an AI governance committee charter
An AI governance committee without a charter is a meeting with a name. The charter defines the committee's authority, composition, quorum, decision types, and escalation paths. This piece defines what a working charter requires.