AI security framework: a practical operating model

Start with decisions, not documents

The first workshop should not begin with a template. Begin with the decisions the company expects AI to make or influence: approving a refund, summarising a clinical note, generating code, searching private documents or taking an action through an agent. The same model can carry very different consequences in each use case.

Create a small intake record for every use case. Name the business owner, technical owner, affected users, data classes, external providers, connected tools and the worst credible failure. This becomes the working map for security review rather than a one-time questionnaire.

• Name one accountable business owner for every AI use case
• Separate advisory controls from launch-blocking requirements
• Record whether the system generates content or can create side effects
• Reassess when models, tools, data or user populations change

Build controls across six layers

Model security is only one layer. Data may be poisoned or disclosed; retrieval may cross tenant boundaries; prompts may redirect an application; tools may be over-permissioned; and people may rely on output without appropriate review. Use layered controls so one failure does not become a business incident.

The minimum stack is identity, data protection, model and supplier assurance, application security, tool authorization and operational monitoring. Product teams should be able to show evidence for each layer in the same way they show tests and deployment records.

• Identity for people, services and agents
• Data minimisation, provenance and retention controls
• Prompt-injection and output-handling tests
• Tool allowlists, transaction limits and human approval
• Logs that connect input, model, tool call and outcome

Make assurance proportionate to impact

A low-impact writing assistant does not need the same review as an agent that can change production configuration. Define tiers using data sensitivity, autonomy, reach, reversibility and legal or safety impact. The tier should determine testing depth, approval authority and monitoring.

High-impact systems deserve adversarial testing, separation of duties, staged rollout and a tested shutdown path. Lower-risk systems still need ownership, acceptable-use boundaries and basic monitoring. Proportionality keeps the framework usable instead of turning every experiment into an exception.

• Tier 1: internal assistance with no sensitive data or side effects
• Tier 2: sensitive context or customer-facing output
• Tier 3: consequential decisions, privileged tools or material autonomy

Operate the framework after launch

AI risk changes in production. Inputs drift, providers update models, users discover new behaviour and connected tools expand. Review telemetry for misuse, denied actions, unusual retrieval, sensitive output and human overrides.

A monthly AI risk review should look at evidence, not presentation slides: inventory changes, open findings, incidents, provider notices, evaluation results and decisions awaiting an owner. The framework succeeds when it changes a release or access decision before harm occurs.

• Track model and prompt changes as production changes
• Keep a kill switch and rollback owner
• Route security events into the normal incident process
• Retire unused models, keys, indexes and agents

A practical 30-day field plan

Week one — Govern. Set risk tolerance, ownership and prohibited uses. Put one accountable owner in the room, agree which business service or decision is in scope, and record the assumptions the team is making. Resist the urge to begin with a technology purchase; the first deliverable is a shared view of the problem and the authority to change it.

Week two — Map. Document data, models, tools, users and impact. Walk through the current process with the people who operate it. Compare the written design with real access paths, data flows, exceptions and on-call practice. Mark every point where an owner is missing or where the team cannot produce evidence that a control works.

Week three — Measure. Test security, quality, privacy and misuse cases. Choose a narrow pilot that can be observed safely. Define the expected result, the rollback path and the person who may accept a trade-off. Capture operational friction as product feedback; controls that are difficult to use will eventually be bypassed.

Week four — Manage. Approve, monitor, respond and improve. Review the pilot with engineering, operations, security and the service owner. Close urgent gaps, assign longer work to a funded backlog and set the next evidence review. The month should end with a repeatable operating rhythm, not a one-time presentation.

Evidence worth keeping

Good evidence is understandable outside the team that created it. Keep a concise record that connects the decision, owner, technical implementation and observed result. Screenshots can support evidence, but configuration, logs, test output and approved records are stronger because another person can reproduce or challenge them.

• Name one accountable business owner for every AI use case — owner, current state, last validation and any open exception
• Identity for people, services and agents — owner, current state, last validation and any open exception
• Tier 1: internal assistance with no sensitive data or side effects — owner, current state, last validation and any open exception
• Track model and prompt changes as production changes — owner, current state, last validation and any open exception
• Decision log showing who approved residual risk and when it will be reviewed
• Test or exercise result with the actual outcome, not only a pass label

Questions for the leadership review

Use these questions to keep the discussion connected to operating risk rather than tool activity. A useful answer names a person, a service and evidence.

• Who is accountable for the ai governance outcome when teams disagree about delivery and risk?
• Which critical service or customer promise would be affected by a failure in this area?
• What evidence would tell us the design is working in production today?
• Which exception creates the largest concentration of access, dependency or recovery risk?
• What would the team contain first, and how would it restore a trustworthy service?
• Which improvement can be completed in the next 30 days without waiting for a large programme?