About six months ago, questions started popping up in our Slack channel. An engineer asked about ChatGPT usage policies. Another wondered how to scan AI-generated pull requests. Recently, a compliance manager found three teams using different LLM tools, none of which IT was aware of.
The Purple Book Community and ArmorCode surveyed over 650 senior cybersecurity leaders in North America and Europe for their State of AI Risk Management 2026 report. A key finding: organizations are adopting AI faster than security programs can adapt. This governance gap is real, and it's why you're getting these questions.
Here's what compliance teams are doing to address this gap.
Identifying Shadow AI Tools
Start with your egress logs and SaaS discovery tools. Look for API calls to known LLM providers like OpenAI, Anthropic, Google AI, and Cohere. Check browser extensions in your endpoint management console. Search Slack and email for terms like "ChatGPT," "Claude," "Gemini," and "prompt."
Detection is only part of the solution. Teams often don't disclose their tools because they fear rejection. Create an approved AI tools list with clear use cases. If developers need code completion, evaluate GitHub Copilot or Tabnine under a controlled pilot. For support teams needing response drafting, test in a sandboxed environment first.
Document this in your Acceptable Use Policy and tie it to ISO 27001 Control 5.1. You need both detective controls and a policy framework.
Reviewing AI-Generated Code
AI-generated code can fail in ways human code doesn't. It might use deprecated functions, mix authentication schemes, or create logic errors that pass unit tests but fail under edge conditions.
Your existing SAST tools will catch some issues, but you need additional checks:
- Flag any commit with over 30% code churn from a single developer in a short timeframe.
- Require architecture review for new dependencies introduced by AI suggestions.
- Test for compliance with OWASP ASVS v4.0.3 Level 2 requirements, specifically V1.14 (configuration) and V5.1 (input validation).
- Run generated code through a secondary LLM with a security-focused prompt to identify vulnerabilities.
Think of the last point as a second opinion, not a replacement for human review.
Integrating AI Risk Assessment
Integrate AI risk into your existing risk program but add specific AI risk categories. Your current risk register likely covers third-party services, data classification, and access controls. Extend these.
For shadow AI, add: "Unauthorized AI tools processing sensitive data outside approved controls." Map it to NIST CSF v2.0 functions: Identify (ID.AM for asset management), Govern (GV.RR for roles and responsibilities), and Protect (PR.DS for data security).
For AI-generated code, add: "Code vulnerabilities introduced through AI assistance tools bypassing secure development lifecycle." This ties to PCI DSS v4.0.1 Requirement 6.2.4 if you're in that scope.
Don't create a parallel AI governance structure. Use your existing change advisory board, security architecture review, and vendor management processes, adding AI-specific criteria to each gate.
Crafting an Effective AI Usage Policy
Make your policy permissive with guardrails, not restrictive with exceptions. Successful policies include:
Allowed by default:
- Public code completion tools on non-sensitive repositories.
- LLM-assisted documentation writing.
- Query optimization suggestions in development environments.
Requires approval:
- Processing customer data through external AI services.
- Using AI to generate authentication, cryptographic, or payment handling code.
- Deploying AI-generated code to production without human review.
Prohibited:
- Pasting proprietary algorithms, customer data, or security configurations into public LLMs.
- Using AI to make access control decisions without human oversight.
- Bypassing code review by claiming "AI wrote it."
Reference SOC 2 Type II Common Criteria CC6.1 and CC7.2 in your policy. Auditors will ask how you're controlling data flows to AI services.
Handling Pre-Policy AI Tools
Grandfather existing tools with conditions. Removing tools teams rely on creates resentment and drives usage underground.
Send a survey: "We're formalizing AI tool governance. What are you currently using?" Give them two weeks to respond. For each tool reported, do a quick risk assessment:
- Does it process sensitive data? (If yes, data classification review)
- Does it store our code or prompts? (If yes, vendor security assessment)
- Can we enforce usage policies through SSO or API controls? (If no, consider alternatives)
Tools that pass get added to your approved list. Tools that don't get a 90-day migration timeline to an approved alternative. This respects the work teams have done while bringing things into compliance.
Tracking AI Risk Management Metrics
Track coverage, not just usage. Metrics that matter:
- Percentage of AI tool usage visible to security (goal: >90%).
- Number of AI-generated code commits that went through security review.
- Mean time to detect unauthorized AI tool deployment.
- Percentage of developers who've completed AI secure coding training.
Avoid tracking "number of AI tools blocked" or "AI incidents prevented." Those numbers incentivize security theater. Measure whether your governance program covers the AI usage in your environment.
For compliance reporting, map these metrics to NIST 800-53 Rev 5 controls: CA-7, PM-16, and SA-15.
Balancing Speed with Security in AI Code Review
The slowdown isn't the review itself; it's likely your review process. If every AI-generated function is treated like a third-party library integration, you'll create a bottleneck.
Tier your review based on risk:
Automated scan only: UI components, test files, documentation
Peer review required: Business logic, data processing, API integrations
Security review required: Authentication, authorization, cryptography, PCI scope
This maps to OWASP Top 10 2021 risk levels. A React component rendering a dashboard? Lower risk. A function handling payment tokenization? Needs eyes from someone who knows PCI DSS v4.0.1 Requirement 6.4.3.
Set SLAs: automated scans complete in under 10 minutes, peer review in under 4 hours, security review in under 24 hours. If you're missing those targets, you need more security engineering capacity, not looser controls.
Where to Go from Here
Your AI governance gap won't close itself. The survey of 650+ cybersecurity leaders shows this is industry-wide, not just your problem. But don't wait for industry consensus.
Start with visibility. You can't govern what you can't see. Then build permissive policies that acknowledge AI tools as productivity multipliers, not security threats by default. Finally, integrate AI risk into your existing frameworks rather than creating parallel governance structures.
The teams using shadow AI aren't trying to bypass security. They're trying to ship faster. Your job is to help them do that safely.
