AI governance framework for security teams: A practical approach

AI governance framework: quick answer

An AI governance framework is the combination of policies, ownership structures, access controls, and monitoring processes that govern how employees at an organization use AI tools. For security teams, it starts not with policy but with discovery: you can't govern what you can't see. The first step is building a complete inventory of every AI tool in use—sanctioned or not—before writing a single rule.

‍

Key takeaways

• Most AI governance frameworks assume you already know what AI is deployed. The real starting problem is that you don't. Shadow AI has spread faster than any governance program anticipated.
• 20% of organizations experienced a data breach involving shadow AI, and those breaches cost an average of $700,000 more than conventional incidents (IBM 2025 Data Breach Report).
• A functional AI governance framework covers seven operational steps: discovery, risk classification, acceptable use policy, ownership, access controls, incident response, and review cadence.
• Governing AI tools employees use is a different problem than governing AI systems your organization builds. Most published frameworks conflate both. This one doesn't.
• NIST AI RMF and ISO 42001 are useful reference models, but neither was designed for governing unsanctioned employee AI adoption. Use them as context, not as your operating procedure.

The governance problem most frameworks ignore: you don't know what's running

Every major AI governance framework published in the last two years starts from the same assumption: you know what AI is deployed at your organization. They tell you to classify your AI systems by risk tier, assign owners, document data flows, and maintain an AI registry.

‍

The problem is the premise.

‍

Gartner identified AI trust, risk, and security management as the number one strategic technology trend in 2024. And yet 75% of enterprises lack formal governance of their AI programs (IBM 2024 Global AI Adoption Index). That gap isn't a policy failure. It's a visibility failure. Analysis of real enterprise AI adoption patterns shows most organizations are actively managing only a fraction of the AI tools their employees actually use.

‍

Employees don't wait for IT procurement cycles. They sign up for ChatGPT, Notion AI, Perplexity, and dozens of similar tools, connect them to work data via OAuth or file uploads, and get to work. The AI tool your sales rep started using last Tuesday—the one reading and summarizing your CRM data—isn't in any governance registry. It never went through a procurement review. You don't know it exists.

‍

This is shadow AI: AI tools adopted by employees outside IT or security visibility. And it's not a fringe problem. IBM's 2025 Data Breach Report found that 20% of organizations experienced a data breach involving shadow AI, at an average additional cost of $700,000 per incident.

‍

The governance frameworks most organizations encounter were designed for a world where AI adoption is controlled and known. That world doesn't exist anymore at most mid-market and enterprise organizations.

‍

This guide inverts that approach. Before you write a policy, you need an inventory. Before you assign ownership, you need to know what's out there. The framework below starts where the problem actually starts.

‍

Step 1: Build your AI tool inventory

You can't govern what you haven't discovered. The first step in any practical AI governance framework is a complete inventory of every AI tool in use at your organization, regardless of whether it was sanctioned.

‍

This is harder than it sounds. Traditional discovery methods don't work:

• Network monitoring misses tools accessed from personal devices, off-network, or via mobile. As distributed work made perimeter controls obsolete, so did the discovery methods built on top of them.
• Expense report analysis catches only tools purchased on company cards. Personal account signups—the most common path for consumer AI tools—never appear.
• Asking employees surfaces what people are willing to disclose, not what's actually in use. Self-reporting is not an audit.

Effective AI discovery requires analyzing the email-based account creation and OAuth authorization patterns that leave a trace whenever an employee connects a new tool to a work identity, regardless of which device they used or whether they ever made a purchase.

‍

What your inventory should capture

• Every AI tool in use, including consumer-grade tools (ChatGPT, Claude, Gemini, Perplexity, Copilot)
• Who is using each tool and in which department
• What data access the tool has, particularly OAuth grants connecting AI tools to work systems like Google Workspace, Microsoft 365, or Slack
• Whether AI features have been silently added to tools your employees already use (Salesforce Einstein, Notion AI, Slack AI, Zoom AI)—a critical blind spot in most governance programs

That last category matters most. Your employees may never have consciously adopted an AI tool, but AI capabilities have been added to tools they use every day. Governing AI adoption means governing these invisible additions, not just the tools employees explicitly chose.

‍

Checklist: AI tool inventory

• Identify all AI tools accessed by employees in the last 90 days
• Note which tools were self-provisioned vs. IT-approved
• Document OAuth grants from AI tools to work systems (Google Workspace, Microsoft 365, Slack, etc.)
• Flag AI features embedded in existing sanctioned SaaS tools
• Record whether each tool is accessed on managed or unmanaged devices

Step 2: Classify tools by risk tier

Once you have an inventory, classify it. Not every AI tool carries the same risk, and treating all of them with the same level of scrutiny will cause your governance program to collapse under its own weight.

‍

A practical risk classification for AI tools uses two factors: data sensitivity and organizational reach.

Tier 1: high risk

AI tools with access to sensitive business data—customer PII, financial records, source code, proprietary strategy documents, or regulated data (HIPAA, PCI, SOC 2 scope). Also includes any AI tool a significant number of employees use for core workflow tasks. These tools require formal procurement review, data processing agreements, and active monitoring.

‍

Examples: AI tools integrated into core CRM, HRIS, or code environments; any tool with admin-level OAuth access to Google Workspace or Microsoft 365.

‍

Tier 2: moderate risk

AI tools with limited work data exposure—writing assistance, research summarization, or scheduling—but no programmatic access to sensitive systems. Lower urgency for formal review, but AI productivity tools still require acceptable use policy coverage and employee communication.

Examples: Standalone writing assistants, AI meeting recorders with no calendar integration, browser-based AI search tools.

‍

Tier 3: low or informational risk

AI tools accessed for general research or curiosity with no connection to work accounts or sensitive data. Monitoring is appropriate; formal review is not. Most consumer AI tools used on personal accounts with no OAuth grants to work systems fall here.

‍

The hidden tier: embedded AI

AI capabilities added to tools your organization has already approved, without a separate procurement decision. These deserve special attention because the approval workflow that might have flagged them didn't exist when the original tool was evaluated. Treat newly embedded AI features in sanctioned tools as a Tier 1 or Tier 2 discovery event depending on the feature's data access.

‍

Step 3: Write an AI acceptable use policy

The AI acceptable use policy (AUP) is the governance artifact most often referenced and least often actually written. Most published frameworks mention it as a step; few provide usable structure.

‍

The goal of an AI AUP is not to enumerate every prohibited behavior. It's to give employees a clear, practicable framework for making decisions about AI tool use before they make a mistake—and to give your security and IT team a defensible baseline when something goes wrong.

‍

Core sections of an AI acceptable use policy

1. Scope

What this policy covers: which AI tools, which employees, which data types. Be explicit. "AI tools" is not self-defining. Include the categories that matter (generative AI, AI-powered SaaS features, AI agents).

‍

2. What's permitted without prior approval

Be specific. Generic "approved tool" language tells employees nothing. List the approved tools, or the categories of tool that are approved. Specify what data can and can't be used with each.

‍

3. What requires prior approval

Any AI tool that: (a) requests access to work accounts or data via OAuth or API, (b) involves uploading or pasting customer, employee, or proprietary data, or (c) will be used for customer-facing work outputs. The approval process should be fast. A 30-day queue defeats the purpose.

‍

4. What is prohibited

Examples: uploading customer PII to any AI tool not covered by a data processing agreement; using AI to generate or distribute content falsely attributed to a human; connecting unapproved AI tools to company systems.

‍

5. Employee responsibilities and expectations

Employees are responsible for knowing which tier their tool falls into and for not circumventing controls. This section also establishes the expectation that employees will report unauthorized AI tool use—including their own past mistakes—without punitive consequence if reported promptly.

‍

6. How incidents are reported

A clear, low-friction reporting path. If employees don't know how to report a potential AI governance incident, they won't.

‍

7. Consequences and enforcement

Must be present, but proportionate. Treat unauthorized AI use as a behavioral risk to manage, not a disciplinary problem to punish—unless patterns repeat or intent was clearly malicious.

‍

Checklist: AI acceptable use policy

• Scope defined explicitly, including AI-powered SaaS features
• Approved tool list or categories stated
• Approval process for new tools documented and accessible
• Data handling prohibitions specific (PII, regulated data, source code)
• Incident reporting path included
• Policy reviewed by legal/HR and signed off by leadership

Step 4: Establish ownership and accountability

40% of technology executives say their AI governance program is insufficient (2024 Economist Impact survey of 1,100 executives). The most common reason programs stall isn't lack of policy—it's lack of ownership.

‍

AI governance spans security, IT, HR, legal, and individual business units. Without explicit role assignment, it belongs to everyone and no one.

‍

In most mid-market and enterprise organizations, security or IT is the right lead—specifically the function that already owns SaaS governance. The CISO or VP of IT is the appropriate executive sponsor. Compliance-led programs tend to produce policy documents without operational teeth; security-led programs with compliance input produce governance that actually runs.

‍

The key coordination mechanism is a lightweight AI governance working group. Not a committee in the formal sense, but a defined roster of who gets looped in when new tools are discovered, when incidents occur, and when the policy needs revision. This doesn't require dedicated headcount or a new org structure. It requires explicit assignment of responsibilities to roles that already exist.

‍

A platform that handles identity governance across your SaaS estate gives you the operational layer for tracking which employees have access to which AI tools, particularly for sanctioned tools that integrate with your identity provider.

‍

Step 5: Implement access and data controls for sanctioned tools

Governance without controls is a document. For AI tools that have been formally approved, implement the technical controls that reduce the risk of data exposure.

‍

For AI tools with OAuth access to work systems

Review and right-size OAuth permissions. Most consumer and prosumer AI tools request broad scopes—read/write access to email, calendar, and files—when they may only need read access to a specific data type. Audit the scopes requested and revoke access for any tool where granted permissions exceed what the tool legitimately requires.

‍

Managing OAuth risk at scale is the operational layer where this work happens. Every OAuth grant is a trust decision—one your employees made unilaterally, and one your security team now needs to audit.

‍

For AI tools handling sensitive data

Ensure a data processing agreement (DPA) is in place before any sensitive data flows into an AI tool. A DPA defines how the vendor stores, processes, and retains your data. For tools used in customer-facing contexts, verify whether the vendor's AI training policy allows them to use your data to train their model.

‍

SSO enrollment

AI tools used by a significant portion of employees should be enrolled in your SSO identity provider. SSO enrollment makes account lifecycle management tractable: you can deprovision access when an employee leaves instead of discovering lingering AI accounts months later. Simplifying SSO enrollment for applications outside your current identity provider is where that work begins.

‍

For AI agents and automations

A growing category of AI risk involves non-human identities: AI agents that operate autonomously and hold persistent access to work systems via API keys or OAuth tokens. These aren't governed by employee behavior—they're governed by access controls on the credential itself. Audit which AI agents or automations have standing access to your systems, and ensure those credentials are rotated, scoped, and revocable. The security risks MCP servers introduce as agents connect to enterprise systems through standardized protocols add new surface area that standard OAuth audits don't cover.

‍

Checklist: access and data controls

• OAuth scopes audited for all AI tools with work system access
• DPAs confirmed for AI tools handling sensitive data
• AI training data opt-outs confirmed for applicable tools
• High-adoption AI tools enrolled in SSO
• AI agent credentials inventoried and subject to access management controls

Step 6: Set up monitoring and incident response for AI misuse

An AI governance framework without a response procedure is incomplete. Monitoring and incident response are what convert your policy from a document into an operational program.

‍

What to monitor

• New AI tool adoptions in near-real-time. When an employee connects a new AI tool to a work account, that's a governance event. It should trigger a classification check, not a month-end audit.
• OAuth grants from AI tools to sensitive systems. A new AI tool requesting admin-level access to Microsoft 365 is a different risk profile than one requesting read-only calendar access.
• Anomalous data access patterns. AI tools that begin accessing significantly more data than their baseline—or accessing data outside the scope of their stated function—warrant investigation.
• Former employee access. AI tools provisioned under a personal email address may retain access to work data after an employee leaves. Offboarding procedures need to include AI tool access. Automating employee offboarding to remove SaaS and AI access closes this gap before access lingers past the departure date.

When an employee pastes customer data into ChatGPT

This is the most common shadow AI incident scenario, and almost no published governance framework explains what to do procedurally.

1. Determine the scope of the data exposure: what data was shared, in what form, with which tool, at what time.
2. Check the tool's data retention and training policies: was the data likely retained? Is it used for model training? Has the vendor received a deletion request?
3. Assess regulatory notification requirements: if the data included customer PII, determine whether the incident triggers GDPR, CCPA, or other applicable notification obligations.
4. Document the incident and communicate to the employee. If this was a policy violation, address it through HR procedures. If the policy was unclear or the employee didn't know it applied, treat it as a training moment.
5. Update the AUP if the incident revealed a gap. If the tool involved wasn't addressed by your current policy, add it.

What an AI incident is not

Not every unauthorized AI tool use is a reportable data breach. Severity triage matters. An employee who used Perplexity to summarize a public competitor article is a different risk profile than one who uploaded a customer list to an unchecked AI tool. Your incident response procedure should include a severity tier map to prevent both under-response and over-response.

‍

Step 7: Create a review cadence as tools and regulations evolve

An AI governance framework built in Q1 2026 will be materially incomplete by Q4 2026. The rate at which AI tools evolve exceeds what any static policy can keep up with.

‍

What a review cadence looks like in practice

Monthly: Review new AI tool discoveries from the prior 30 days. Classify any newly discovered tools. Check whether any vendor has added AI features to an existing sanctioned tool that weren't present at last review.

‍

‍Quarterly: Run access reviews for AI tools in compliance scope, review the AUP for completeness given new tool categories or use cases that have emerged, and confirm ownership assignments are still accurate. Review the incident log from the prior quarter and identify pattern findings that warrant policy updates.

‍

Annually: Full framework review against the current regulatory environment. Confirm that your data processing agreements reflect current vendor practices. Review NIST AI RMF and ISO 42001 updates for guidance you may want to incorporate. Conduct a tabletop exercise for an AI-related incident scenario.

‍

On-trigger:

• Any material AI incident, regardless of scheduled cycle, triggers an immediate AUP and control review
• Any significant employee headcount change triggers an access review for AI tools in the high-risk tier
• Any AI tool that changes its data processing terms or training policies triggers a review of your DPA and opt-out status for that tool

The governing principle: your review cadence should match the rate at which your threat surface changes. For most organizations, AI tool adoption is adding new surface area faster than annual reviews can address it. A broader SaaS security best practices checklist can supplement your AI governance review cycle with controls for the wider SaaS estate AI tools live inside.

AI governance checklist

A practical AI governance framework for security teams requires seven operational capabilities. Use this as a gap assessment:

Discovery

• Continuous visibility into AI tools in use across the organization
• Discovery covers personal accounts, unmanaged devices, and embedded AI features in existing SaaS

Classification

• Risk tier assignment for each discovered AI tool
• Embedded AI features in existing tools are classified separately

Policy

• AI acceptable use policy exists, is current, and has been communicated to employees
• AUP includes specific data handling rules, not just general principles

Ownership

• Named owner for AI governance program (security or IT lead)
• Working group with representation from legal, HR, and business units

Access controls

• OAuth scopes audited for all AI tools with work system access
• DPAs in place for AI tools handling sensitive or regulated data
• High-adoption tools enrolled in SSO

Incident response

• Monitoring in place for new AI tool adoptions
• Documented incident response procedure for AI data exposure events
• Offboarding procedure includes AI tool access revocation

Review cadence

• Monthly, quarterly, and annual review cycles defined and assigned
• On-trigger review criteria established

How Nudge Security approaches AI governance

Building an AI governance framework starts with visibility—and visibility is what most organizations are missing. Nudge Security discovers every AI tool in use at an organization on Day One, including tools accessed on personal accounts, tools running on unmanaged devices, and AI capabilities embedded in existing SaaS applications. No network configuration required.

‍

From that inventory, security and IT teams can classify tools by risk, review and right-size OAuth access, enroll AI tools in SSO, and get notified when employees adopt new AI tools in near-real-time.

‍

If you want to see what AI tools are actually running at your organization before you build your governance framework, start with a free trial.

‍

FAQ

What is an AI governance framework?

An AI governance framework is the combination of policies, accountability structures, access controls, and monitoring processes that govern how employees use AI tools within an organization. For security teams, the framework starts with discovery—building a complete inventory of AI tools in use—before establishing rules about how those tools can and can't be used. A governance framework for AI employee usage is distinct from governance frameworks for AI systems an organization builds or deploys itself.

‍

What are the key components of an effective AI governance framework?

The key components are: (1) a complete AI tool inventory covering sanctioned and unsanctioned tools, (2) a risk classification system that tiers tools by data sensitivity and organizational reach, (3) an AI acceptable use policy that employees can actually follow, (4) explicit ownership and accountability assignments, (5) access and data controls for approved tools, (6) monitoring and incident response procedures, and (7) a regular review cadence. Most published frameworks include some of these; the most commonly skipped is discovery—the inventory that makes everything else possible.

‍

Who should own AI governance in an enterprise?

AI governance should be owned by the security or IT function that already manages SaaS governance—typically the CISO or VP of IT. Compliance-led programs tend to produce policy without operational execution. Security-led programs, with compliance input on regulatory obligations and HR input on enforcement, produce governance that actually runs. The key structural element is not a new committee but clear role assignments: who owns discovery, who owns policy, who handles incidents, and who enforces with employees.

‍

How do you write a formal AI policy?

A formal AI acceptable use policy needs seven elements: an explicit scope statement naming what AI tools and data types the policy covers; a list of approved tools or categories and what data can be used with them; a clear approval process for new tools; specific data handling prohibitions (PII, regulated data, source code); employee responsibility statements; an incident reporting path; and documented enforcement procedures. The most common failure mode is a policy so general it can't be applied to a specific situation. Write it so a department manager can make a yes/no decision about a specific tool request without escalating to IT.

‍

What financial risks accompany unmanaged AI sprawl?

The IBM 2025 Data Breach Report found that 20% of organizations experienced a data breach involving shadow AI, at an average additional cost of $700,000 per incident. Beyond direct breach costs, the financial risks include: regulatory fines if unsanctioned AI tools process regulated data without proper agreements in place; vendor liability if AI-generated outputs used in customer-facing work contain errors or IP violations; and hidden SaaS spend as employees accumulate paid AI subscriptions that never go through procurement review. The governance gap is also an audit gap—organizations pursuing SOC 2 or ISO 27001 certification increasingly face questions about AI tool controls that their current programs can't answer.