The CISO's Guide to Generative AI Risk: What to Govern, What to Block, and What to Allow

Generative AI tools arrived in the enterprise faster than any technology in recent memory. ChatGPT reached 100 million users in two months. By the time most security programs had a policy drafted, half the organization was already using it daily.

This guide is for CISOs who have moved past "should we allow AI tools?" and are now building a real governance program. It covers what to govern, what to block, what to allow, and how to enforce it without killing the productivity gains your business has already come to depend on.

The Governance Gap

Traditional enterprise security was designed around perimeters and file flows. Your DLP blocks email attachments containing SSNs. Your CASB monitors uploads to Dropbox. Your endpoint solution detects malware on the device.

None of these tools were designed to intercept a 200-word paragraph typed into a browser text box and submitted to a third-party AI over standard HTTPS.

ChatGPT is the highest-volume AI surface and the one most organizations encounter first. For a full breakdown of why it is uniquely difficult to protect against with traditional tools, see our ChatGPT Data Loss Prevention guide.

The governance gap is architectural, not procedural. You cannot solve it with a policy memo. You need controls that operate where the data actually moves — inside the browser, at the moment of input.

What to Govern

Not every AI use case carries the same risk. Before building a blocklist, map the landscape:

High-risk use cases (data that creates regulatory or legal exposure): - Patient records, PHI, and clinical notes sent to AI for summarization or drafting - Customer PII sent to AI for email drafting, CRM data analysis, or support work - Financial account data, card numbers, and transaction records - Source code containing credentials, API keys, or proprietary algorithms - Legal case details, client names, and privileged communications - Internal deal codenames, M&A targets, and unreleased product information

Medium-risk use cases (no direct regulatory exposure, but IP or competitive sensitivity): - Internal strategy documents and roadmap discussions - Organizational structure, headcount, and compensation discussions - Vendor pricing and contract terms

Low-risk use cases (appropriate for broad AI tool access): - Drafting external communications using publicly available information - Research on publicly known topics - Coding help using open-source libraries and public APIs - Learning, summarization of published materials, language tasks

The governance program should start with hard controls on high-risk use cases and lighter-touch awareness for medium-risk ones. Low-risk use cases should be actively encouraged — this is where the productivity value lives.

What to Block

Block means the prompt never reaches the AI provider's servers. Use block for data where exposure creates:

• Regulatory liability — HIPAA PHI, PCI-DSS card data, GDPR-covered personal data, FERPA student records
• Legal privilege risk — attorney-client communications, work product, client matter details
• Material financial risk — MNPI, unreported earnings data, M&A details before announcement
• Credential exposure — API keys, service account passwords, database connection strings, tokens

These categories are not negotiable. The regulatory consequences of exposure are concrete. Use pattern detection for known formats (SSNs, card numbers, IBANs) and entropy detection for credentials and API keys — high-entropy strings that your keyword list does not know to look for.

What to Warn (But Not Block)

Some data is sensitive but not regulated. For these categories, a warn action — showing employees what was detected and asking for justification — is more appropriate than a hard block. Warn actions:

• Build employee awareness without creating friction for legitimate workflows
• Create an audit trail of borderline decisions without stopping work
• Surface edge cases that help you refine your policy over time

Apply warn to: internal project names and codenames, vendor pricing, proprietary but non-regulated business logic, and organizational data that is sensitive but not illegal to share.

What to Allow

This is the part most security programs get wrong. Over-restriction is not a security win — it is a productivity loss that creates shadow IT. Employees who cannot use approved AI tools find unapproved ones.

Define a clear allowlist of approved AI platforms (ChatGPT, Claude, Gemini are the highest-volume enterprise tools) and communicate that using them for low-risk tasks is not just permitted but encouraged. Your AI governance program should make employees feel supported, not surveilled.

The Enforcement Stack

An effective AI governance program has three layers:

Layer 1: Technical controls. Browser-native AI DLP that intercepts prompts before submission. This is the only layer that works without network infrastructure changes. It handles the high-risk cases automatically, before human judgment is required.

Layer 2: Audit and visibility. Even with blocking in place, you need a log of what is being caught, which teams are triggering violations, and whether your policy is calibrated correctly. Audit logs also provide the evidence trail that regulators, auditors, and cyber insurance underwriters increasingly require.

Layer 3: Awareness and training. Technical controls stop the automated leakage. Training handles the edge cases: employees who find ways around controls, novel use cases your policy did not anticipate, and the cultural shift toward treating AI tools as a shared resource with shared responsibility.

Building the Program

Month 1: Deploy AI DLP in monitor-only mode. No blocking. Collect baseline data on what is actually being sent to AI tools across your organization. This data will be more useful than any threat model you build from assumptions.

Month 2: Enable blocking for the highest-risk categories: credentials, regulated PII, card data. Enable warn for the medium-risk categories. Communicate the policy to employees — explain why, not just what.

Month 3: Review the audit data. Adjust false positive rates. Identify teams with high violation rates that need targeted training. Add rule coverage for patterns you missed in month 1.

Quarter 2+: Expand coverage to additional AI platforms as your employees adopt them. Build quarterly policy reviews into your security calendar. Use the audit log to report to your board on AI risk posture.

Pretzel is built for this governance model: browser-native detection, centralized policy management, team-scoped rules, and a full audit trail. See how it works or start free with no network changes required.