The question at hand
When new technology enters your environment, you must decide whether to treat it as a unique category needing dedicated frameworks or integrate it into your existing risk management process. With AI, this decision feels urgent. The share of employees using AI on corporate devices tripled to 45% last year, up from 15%. Google's Threat Intelligence Group reported the first zero-day believed to be developed with AI. In April 2026, an AI coding agent at PocketOS deleted a production database during a routine task.
The question dividing security leaders: Should AI have its own risk program, or should you apply the same risk-first methodology you use for any other technology?
The case for AI-specific programs
Some argue that AI's dual nature demands specialized treatment. AI enhances both offensive and defensive capabilities, creating a rapidly evolving threat landscape. Autonomous agents can execute attacks without human direction, as seen in the OpenAI/Hugging Face incident. This isn't just automation; it's delegation.
The internal risk profile is different too. Employees often use AI tools through personal accounts outside enterprise controls. According to Verizon's latest DBIR, about two-thirds of AI users on corporate devices accessed these tools via personal accounts. You can't inventory what you don't control, and you can't govern what you haven't inventoried.
Practitioners highlight specific AI risks that don't fit existing categories. Usage-based billing creates a new attack surface where stolen API tokens lead to financial losses through resource abuse. Shared agentic systems need broad access, making the platform a high-value target. These are fundamentally different exposures.
AI development speed also outpaces traditional security review cycles. An autonomous agent can write, test, and deploy code in minutes, making existing secure development lifecycle controls insufficient. You need new checkpoints for machine-generated output.
The case for standard risk management
Other security leaders argue that AI is technology, and you already know how to manage technology risk. Creating a separate AI risk program fragments your control environment and dilutes accountability. Worse, it suggests AI is exempt from the requirements you apply to everything else.
This camp believes the fundamentals haven't changed. An AI agent with excessive permissions is just another overprivileged account. An employee pasting sensitive data into ChatGPT is no different from emailing it to their personal Gmail. The delivery mechanism changed, but the control failure is the same. ISO/IEC 27001 Clause 9.3.1 requires you to review your ISMS at planned intervals to ensure continuing suitability; that review should catch AI risks without needing a parallel structure.
Your existing risk assessment methodology already handles emerging threats. ISO/IEC 27001 Clause 6.1.2 requires you to assess information security risks, considering likelihood and consequence. That process doesn't break down when the risk involves AI. You identify the asset, assess the threat, evaluate existing controls, and determine treatment. The fact that an AI agent caused the PocketOS database deletion doesn't change your response: scope credentials properly, implement least privilege access, maintain offline backups.
Practitioners favoring this approach point out that specialized programs often become silos. Your AI governance team implements controls that don't integrate with your broader access management. Your AI risk register exists separately from your main risk treatment plan. When the external auditor asks about your risk assessment process during ISO/IEC 27001 surveillance, you now have to explain two different methodologies.
Where practitioners actually land
Most organizations are taking a hybrid approach. They're using their standard risk framework but adding AI-specific detection and inventory capabilities.
The practical middle ground looks like this: You classify AI usage as a risk scenario within your existing ISO/IEC 27001 Clause 6.1.2 risk assessment. You don't create an "AI risk program," but you do add AI tool discovery to your asset inventory. You apply your standard role-based access control requirements (ISO/IEC 27001 Annex A.5.15, SOC 2 CC6.3), but you specifically scope what AI agents can reach. You run the same tabletop exercises you always have, but you include scenarios involving compromised AI agents.
The key insight: treating AI as a standard risk doesn't mean ignoring its unique characteristics. It means applying proven control frameworks to new threat vectors. When researchers from CodeWall deployed an autonomous agent against McKinsey's AI ecosystem and gained full read-write privileges within two hours through SQL injection, the vulnerability wasn't AI-specific. The exploitation speed was faster, but the control failure was conventional.
Our take
Treat AI like every other technology risk, but don't pretend the timeline is the same.
The risk-first approach works because it forces prioritization. You can't secure everything, everywhere, all at once. You identify the risks with the highest potential business impact and address those first. That methodology doesn't change when AI enters your environment. What changes is the compression of time between vulnerability disclosure and exploitation, and the expansion of your attack surface through employee adoption of external tools.
Your ISO/IEC 27001 ISMS or SOC 2 control environment already requires you to manage access (Annex A.5.15, CC6.1), classify data (Annex A.5.12), maintain asset inventories (Annex A.5.9), and test controls (Annex A.5.7, CC4.1). Apply those requirements to AI tools and AI-accessible systems. Don't create parallel governance structures that will diverge from your main compliance program the moment someone changes roles.
But do accelerate your continuous testing. The window for exploitation is shrinking. Automated code review and dependency management become more critical when AI increases development speed. Your vulnerability identification process needs to keep pace with agents that can autonomously probe for weaknesses.
The CISOs who will manage AI risk effectively aren't the ones building specialized programs. They're the ones who understand that risk management is risk management, regardless of whether the threat actor is human or autonomous. They prioritize based on business impact, implement controls that reduce the greatest exposure, and continuously test whether those controls still work as the landscape shifts.
AI doesn't need its own framework. It needs your existing framework applied with urgency.
