The AI Security Operating Model: A 90-Day Roadmap

The capstone of the KIS AI Security Series: how to turn principles, controls and testing into an operating model that improves every quarter.

AI security becomes real when it has an operating rhythm

Organisations rarely fail because they lack a principle such as “use AI responsibly.” They struggle because nobody owns the inventory, the control decisions, the evidence or the response when a use case changes. An operating model connects leadership intent to everyday work: a person can explain what AI is used for, what data it touches, which controls apply, how performance is measured and what happens when something goes wrong.

This is the practical end point of the series. The goal is not a perfect policy library. It is a repeatable way to discover uses, classify risk, set boundaries, test the path, respond to incidents and improve the service as models and workflows evolve.

Start with five accountable capabilities

Days 1–30: make AI use visible

Start with discovery, not bureaucracy. Ask teams which assistants, model APIs, copilots, plugins and automated workflows they use. Record the purpose, owner, data, provider, users, connectors and actions. Look for shadow use in code repositories, browser extensions, procurement records, support queues and cloud logs.

Choose a small set of representative use cases and classify them by business impact, information sensitivity, autonomy and external exposure. Assign an accountable owner for every use case. Publish a short safe-use baseline while the fuller review continues: approved services, prohibited data, approval requirements and a route for questions.

Days 31–60: put controls into the path

Turn the risk tiers into engineering and process controls. For sensitive data, minimise inputs, enforce permissions outside the model and define retention. For connected tools, use narrow capabilities, validate parameters, separate proposals from execution and require human approval for high-impact actions. For model and vendor changes, define a review trigger and capture evidence of the decision.

Days 61–90: assure and improve

Run security tests against representative workflows. Include prompt injection, malicious documents, data leakage, denied permissions, unsafe tool calls, approval bypass, logging gaps and recovery paths. Track findings to owners and retest after fixes. Review whether monitoring can show what happened without creating a new sensitive-data store.

Set a small management dashboard: number of registered use cases, percentage with owners, high-risk uses reviewed, open critical findings, control-test pass rate, denied or escalated actions, time to detect, time to contain and overdue remediation. Metrics should trigger decisions, not become a reporting ritual.

Keep the model alive

AI security is a change-management discipline. Revisit the register when a model, provider, prompt, connector, data source, user group or action changes. Retire unused tools. Review exceptions with expiry dates. Refresh abuse cases after incidents and near misses. Give product, engineering, risk and security teams a shared language for deciding when a change needs review.

What success looks like

Leaders can see where AI is used and what matters most. Teams can ship useful capabilities with bounded permissions and clear approval paths. Security can test the workflow and investigate the evidence. Users know what data is allowed and where to ask for help. When a model changes or an incident occurs, the organisation has an owner, a stop button and a learning loop.