AI reputation risk at financial institutions — what monitoring alone misses
A biased underwriting model or an erratic advice chatbot becomes a headline before it becomes an incident ticket. Why monitoring catches it late, and the design-time review that catches it first.
What an AI Governance Committee actually needs in an evidence pack
The six artefacts an AI Committee needs to make a defensible decision, and the gaps that appear most often in evidence packs.
AI incident response — what the playbook needs that IT playbooks miss
AI incidents have non-deterministic reproduction, model-level root cause, and degrading evidence. What the playbook must add.
What an agentic AI audit trail must capture
Auditing an agentic system post-incident requires what the model decided and why — not just what happened. Most implementations miss the reasoning trace.
The security terms an AI vendor contract needs
Standard contracts miss AI-specific terms: model-change notice, training restrictions, incident notification, re-assessment rights. The clause language.
Preparing for an ISO 42001 internal audit
What an ISO 42001 internal audit must cover, what evidence auditors want, and the gaps that appear most in first-time preparations.
What evidence an AI security review should produce
Review evidence must survive regulator questions, procurement audits, and post-incident inquiries. What it needs to include.
Finding the AI vendors no one formally approved
Shadow AI is in every organisation. Where unapproved AI tools hide, how to find them, and how to formalise without alienating adopting teams.
Roles and responsibilities under ISO 42001
ISO 42001 requires documented AI management roles. Who the standard expects, how they map to org structures, and what each must demonstrate.
Re-assessment triggers — the field most dispositions skip
A disposition without re-assessment triggers never expires. Triggers keep decisions honest as AI systems evolve. How to define them.
When to re-assess an AI vendor
AI vendor assessments expire. Model updates, new features, changed terms, incidents, and expanding use cases all trigger a fresh review.
Human-in-the-loop boundaries that actually hold
HITL is the most common agentic control and the most often specified in ways that don't hold. What a robust boundary requires — and the failure modes.
Who runs the AI security review — roles and hand-offs
AI security reviews span architects, security engineers, governance leads, and DPOs. Map the hand-offs to avoid dropped gates.
The anatomy of an AI evidence pack
The complete artefact set a governance committee needs for a defensible AI decision. What goes in, and why order and labelling matter.
Building an AI management system (AIMS) from scratch
An AI management system is governance infrastructure: policies, procedures, roles, records for defensible AI decisions at scale. How to build one.
The restricted-pilot pattern for risky AI systems
A restricted pilot is a formal disposition: defined scope, named controls, explicit re-review triggers. How to write one that holds.
Conditional approval for AI systems — making conditions stick
Conditional approval is the most common AI disposition. Most are written so the conditions can't be enforced. How to make them stick.
Model-change notification — the vendor clause procurement teams forget
Vendors swap models without notice, invalidating your security review. The contractual clause and review trigger that keeps assessments current.
AI risk acceptance — who actually signs
Risk acceptance attributed to a committee means no one is accountable. Who should sign for AI systems and what that signature requires.
Writing an AI governance committee charter
A committee without a charter is a meeting with a name. Authority, composition, quorum, decision types, and escalation paths defined.