From Monitor to Block: A 90-Day Rollout Playbook for AI DLP

The rollout is the product

An AI DLP tool that is switched on overnight is an AI DLP tool that gets switched off three weeks later. Every operator we have seen succeed at scale has run the same shape of rollout: a tight pilot, a long Monitor period, a slow shift to Anonymize, a final shift to Block on the categories that matter, and a quarterly review with the executive sponsor. Ninety days from extension install to a defensible enforcement posture.

This playbook is the version we walk through with CISOs at 500-person European companies. It assumes you have already bought Zeuslock or an equivalent and you are about to deploy. It is operator-direct: who does what each week, what success looks like, what to watch in the metrics, and what to say in the corridor conversations with HR, legal, the CFO and the executive sponsor. The pattern is the same every time: trust the data, move slowly, and the organization will follow you.

The 90-day milestone table

Days 0-7: Pilot deployment to the security team only

Install the Zeuslock browser extension and desktop agent on the 20 people in the security and IT team. Nobody else. All policies in Monitor mode. Push via Intune or Workspace MDM so you exercise the same deployment path you will use later, not a manual install. SSO/SCIM bound to Okta or Azure AD from day one.

The point of this week is not to test detection. The point is to catch the false positives caused by your own team's habits. A security engineer pastes legitimate hex strings into a prompt and they look like API keys. An IT admin pastes an internal asset ID that matches the SSN regex. The infrastructure team pastes UUIDs that get mistaken for tokens. You want all of that noise visible in the Operator Console before you ever touch a real end user.

Who does what. The Zeuslock operator (one named person, usually a senior security engineer) owns the console. The IT lead owns the deployment channel. The CISO is briefed twice that week, no more.

Success looks like. Twenty installs healthy in the console, 100% policy coverage, the first ten false-positive detectors identified and a tuning backlog opened. Hours-to-first-detection-tuning measured and recorded. In a healthy pilot this number is under 24.

Conversation to have. None outside the security team yet. Do not pre-announce. You want the unpolished version of your own behaviour first.

Days 8-21: 50 power users and the first baseline

Expand to 30 developers and 20 support analysts. You now have 70 people on the platform. Still Monitor mode everywhere. This is the phase where you start producing numbers that will run the rest of the rollout.

Send a short, plain note to the engineering and support teams. Not a marketing email. Something like: "We have turned on AI detection but not blocking. Your prompts go through as normal. We are measuring volume and patterns. Nothing you do today changes. We will tell you before anything changes." That is the entire script. Resist the urge to add a graphic.

Metrics to watch. Prompts-per-FTE-per-day, broken down by department. Sensitive-data hit rate as a percentage of total prompts. The top five finding types by volume. Median latency added by the extension (should be sub-50 ms). Number of distinct AI destinations being used — expect to find at least three you did not know about, including a Claude tab somebody never asked to license.

Success looks like. A clean weekly report you can show the executive sponsor on day 21, with prompt volume, hit rate, top detectors and top destinations. No employee complaints, because nothing is blocked. The CFO will quietly ask about cost — be ready with the per-seat figure and the avoided-incident framing.

Days 22-45: Org-wide Monitor and the false-positive tuning sprint

Push the extension and agent to all 500 employees via Intune, Workspace or GPO. Still Monitor mode for everyone. Three weeks of full-org visibility before any enforcement.

Run a weekly false-positive review with the operator and one engineer. Tune the ten noisiest detectors. Use custom-detector overrides for org-specific identifiers — ticket numbers, customer reference codes, warehouse SKUs — anything currently being misclassified as a credit card or a national ID. Backtest each override against the previous week's traffic before promoting it.

If you skip the tuning sprint, every false positive in week 6 becomes a helpdesk complaint and an HR meeting. Tune now, save five hours of meetings later.

Conversation with HR. A 30-minute briefing. Employees see nothing — protection is invisible at the endpoint. Data is stored only in the Operator Console, restricted to named operators. Show them the audit trail. Confirm GDPR posture: EU data residency, right to erasure honoured, DPA on file, processing register entry drafted. Get sign-off in writing before week 6.

Conversation with legal. Walk them through the legal basis (legitimate interest, with documented balancing test) and any works-council notification. In France, inform the CSE. In Germany, the Betriebsrat must be consulted before any enforcement mode. Skip this and your rollout dies in week 7.

Days 46-65: Switch financial and PII from Monitor to Anonymize

Activate Anonymize for credit_card, IBAN, email, phone, SSN, NIR (FR), DNI/NIE (ES) and Steuer-ID (DE). Format-preserving anonymization means the LLM still receives a structurally valid value — a fake IBAN that passes the checksum, a fake email at example.com — so downstream reasoning still works. The user sees their answer. The data leaves the building cleansed.

This is the first week the end user can theoretically notice something has changed. Most do not, because LLM responses are still useful. Watch user-experience metrics: are answers still useful, are users complaining, are users bypassing by retyping prompts to evade detection? The bypass rate is the early warning indicator. Above two percent and your anonymization is too aggressive.

Conversation with all staff. A one-page note. Concrete examples, no jargon. "From Monday, when you paste a customer email into ChatGPT, it will be replaced with user@example.com before it leaves your machine. The model's answer will still make sense. The alternative is a CNIL notification we would rather not write." Sign it with the CISO and the head of HR. People read joint notes.

Metrics to watch. Anonymization rate by detector, helpdesk ticket volume tagged ai-dlp, bypass attempts, pulse-survey satisfaction. Sensitive-data hit rate should fall on the categories you switched.

Days 66-80: Switch credentials and source code from Monitor to Block

Activate Block mode for api_key (all variants: AWS AKIA, Stripe sk_, OpenAI sk-, Azure, Google/Gemini, GitHub ghp_, Slack xoxb-, GitLab glpat-, npm npm_, Bearer tokens), password, private_key, jwt, aws_access_key and github_token. These categories are non-negotiable. There is no legitimate business reason to paste an AWS access key into ChatGPT, ever. The block message should be polite, name what was blocked, and link to the exception-request form.

Add Block for source code, but scope it to engineering groups only. The non-engineering side of the company has no business pasting source code, and engineering needs a workflow for the cases where they do. The Zeuslock CLI gives developers a local pre-flight check they can run before they ask the operator for an exception.

What to expect. A measurable spike in helpdesk tickets in week 11. Most are not actually complaints, they are surprise plus a confused first-time block. Train the helpdesk on the exception-request workflow before the spike, not after. The right script is: "Yes, we blocked that. Here is the form. The operator will respond within four business hours. If it is urgent, here is the on-call number." Tickets fall back to baseline by the end of week 12 in every rollout we have run.

Conversation to have with the CFO. A short note when the first credential block lands. "At 14:03 today the platform blocked an AWS production access key from being pasted into ChatGPT by a contractor. That is the kind of incident the audit committee will ask about. We now have evidence we are preventing it." That is how budget for year two gets approved.

Days 81-90: Review, report, renew

Build the quarterly metrics deck. Six slides, not sixteen. Incidents prevented by category. Top finding types. Top departments by hit rate. False-positive rate by week, showing the curve flattening after the tuning sprint. Mean time-to-resolution for incidents. A single slide on the next 90 days.

Brief the executive sponsor in the language they care about. Not detection counts. Avoided-incident framing. "In the first 90 days, the platform prevented an estimated twelve incidents that would have required a CNIL notification under GDPR Article 33, and three incidents involving production credentials that would have required key rotation and a customer communication." Pick the two or three numbers the audit committee will repeat back to you next quarter and lead with those.

Then decide what is next. Stricter policies on the categories you held back. More custom detectors for the org-specific identifiers you discovered in week 5. Expand to the subsidiaries you parked at the start. Integrate the incident stream with your SIEM via the Splunk HEC or Microsoft Sentinel connector, route high-severity findings to PagerDuty, post weekly summaries to a private Slack channel for the operator team.

The checklist

1. Days 0-7: 20 security/IT users, Monitor, tune the noise your own team creates.
2. Days 8-21: add 50 power users, baseline prompts-per-FTE and hit rate, write the first weekly report.
3. Days 22-45: roll out to all 500 in Monitor, run the false-positive tuning sprint, brief HR and legal in writing.
4. Days 46-65: switch PII and financial to Anonymize, send the plain one-page note co-signed by CISO and HR.
5. Days 66-80: switch credentials and code to Block, prepare the helpdesk before the spike, brief the CFO on the first real prevention.
6. Days 81-90: ship the six-slide deck to the executive sponsor, frame avoided incidents in regulator language, lock in the next quarter.

For the operator-side detail on each phase, see the detection policies guide and the deployment checklist.