Shadow AI Governance — The HR + IT Playbook (2026)

Governance vs detection — why both matter

This playbook covers governance. The companion piece — Shadow AI at Work — the HR + IT Playbook for Detection — covers the signal layer (network egress, output velocity, document audit logs, vocabulary markers, structured self-disclosure). The two are different operating problems and need different owners, and a strong shadow-AI programme needs both.

Detection answers the question: where is shadow AI being used in the company? Governance answers the question: what should we do about it, and what is our defensible position to the regulator, the works council, and the audit committee? Companies that ship detection without governance produce dashboards full of flags that nobody can decision. Companies that ship governance without detection produce policies that nobody can enforce because they cannot see the use happening in front of them. The two are the same model, looked at from two ends.

Governance is the harder of the two pieces because it requires committing to decision-rights — who owns each AI system, who approves new ones, who handles the edge cases. Detection is mostly technical. Governance is mostly organisational, and that is why it stalls in most companies until a regulator forces the issue.

Pillar 1 — AI inventory

The starting artefact. A live registry of every AI system the company uses, whether sanctioned through procurement or surfaced through the detection layer. The inventory is the document the regulator will ask for first if a shadow AI incident reaches a complaint, and it is the document the works council will ask for second if there is a workplace-monitoring concern. Treat it as primary artefact.

The minimum eight columns:

• System name — the AI system or service (ChatGPT Enterprise, Claude Team, Microsoft 365 Copilot, an internal model, a vertical-app AI feature).
• Owner — business owner (the team using it) and technical owner (the team running or integrating it). A single named human in each column, not a function.
• Use case description — two sentences. What is this used for and which workflows depend on it.
• Data classes processed — employee PII, client PII, regulated client data, trade secret, source code, internal financials, public information. The data-class taxonomy maps to the company's existing data classification policy.
• Lawful basis — GDPR Article 6 (and Article 9 if special category) for EU staff; DPDP Section 7 for India. Named, not implied.
• EU AI Act risk band — prohibited / high-risk / limited risk / minimal risk, with Annex III paragraph reference where applicable.
• DPIA status and date — required, complete, last updated, next-review trigger.
• Next review date — 12-month default, with material-change triggers (new data class, new use case, new vendor).

The inventory is live, not annual. Every new AI system entering the company runs through the intake workflow (Pillar 3) before reaching the inventory. Every existing system has the next-review date enforced by a calendar event with a named owner. The inventory living in a spreadsheet that nobody touches is the failure mode that triggers most regulator findings; the inventory living in a tracked system with version history is the artefact that survives a DPIA review.

Pillar 2 — classification

Every AI system in the inventory gets mapped to a risk band. The classification engine takes its bands from three overlapping regulatory frames — the EU AI Act, the GDPR, and DPDP — and the system's band is the highest single classification any of the three returns.

EU AI Act bands

• Prohibited (Article 5). Social scoring, manipulative AI, predictive workplace surveillance of a kind banned outright. Any AI system in this band is out — not deployed, not piloted, removed if found in shadow use.
• High-risk (Annex III). Includes AI systems used to monitor or evaluate workers, AI used in employment decisions, AI used in worker performance assessment. From August 2, 2026, deployer obligations apply — transparency, human oversight, conformity-assessment-on-record, registration. [needs-legal-review]
• Limited risk. Generative AI used for ordinary content drafting where there is no employment-decision link. Lighter transparency obligations.
• Minimal risk. AI features inside ordinary productivity tools (autocorrect, spell-check, summarisation) with no employment decision link.

GDPR triggers

• Special-category data (Article 9). AI systems processing health, biometric, or other special-category data trigger Article 9 conditions and usually require explicit consent or another narrow lawful basis.
• Solely automated decisions (Article 22). AI that produces a decision affecting an employee (hiring, promotion, performance evaluation, scheduling) with no meaningful human intervention triggers Article 22 — right to human review, right to explanation, restricted lawful bases.

DPDP scope

• Any AI processing keyed to an employee identifier sits inside DPDP processing scope and needs the standalone notice, the acknowledgement signature in the HRMS, and the grievance officer route under Section 4. The policy carry-over from the existing monitoring policy template is usually the cleanest path. [needs-legal-review]

The classification engine is owned by Compliance, with technical input from IT and operational input from HR. The output goes into the inventory's risk band column, and that band drives the obligations layered in Pillars 3 and 4.

Pillar 3 — the sanctioned-deployment process

The intake-to-approval workflow for new AI tools. The process exists to make the sanctioned path faster than the shadow path — the procurement and compliance friction is the thing pushing employees to consumer AI accounts, so this pillar is where the carrot-versus-stick balance gets re-set.

The seven-step intake

1. Intake request. Single form. Use case, data classes, business owner, target user count, vendor link. Standing-up the form inside the existing ITSM tool removes the friction of a separate portal.
2. Initial classification. Compliance runs the EU AI Act + GDPR + DPDP screen using the vendor scorecard. Verdict: in scope for fast-track approval, in scope for DPIA, in scope for full conformity review, or out of scope (prohibited band).
3. DPIA where required. For high-risk and any system processing special-category data. The DPIA template anchors to the existing monitoring policy DPIA section.
4. Vendor due diligence. Security review, sub-processor list, data residency, breach notification SLA. The DPDP cross-border data transfer angle gets specific attention for India-staff scope.
5. Works-council notification. For EU staff. Required for any workplace AI evaluation system under Annex III. Build in two-week lead time as default. [needs-legal-review]
6. Pilot. Time-bound (30-90 days), scoped to a single team or use case, with success criteria defined upfront. Pilot data feeds the production decision.
7. Production approval and inventory entry. Single approval gate. Adds to the live inventory with all eight columns populated. Calendars the next review date.

The seven steps look heavy on the page, and for high-risk systems they are. For limited-risk and minimal-risk systems the same workflow runs in under five working days because steps 3, 4, 5, and 6 collapse or are bypassed. The point is the workflow is the same shape for every system; only the depth of each step varies.

Speed targets that beat the shadow path

The single most important number in this whole framework: the time-to-first-approval for a low-risk AI tool needs to be under ten working days, ideally under five. Any longer and the rational employee chooses the consumer-account shadow path because their work is waiting. Procurement teams that hit a 5-day approval window for low-risk AI tools see shadow AI declines of 40-60% within a quarter; teams that need 30+ days see no change.

Pillar 4 — exception handling

The intake process catches 80-90% of cases cleanly. The remaining 10-20% need an exception path — and the exception path is the pillar that is missing most often, which is why governance frameworks stall.

The four exception types

• Pilot exception. An employee or team is asked to use a not-yet-sanctioned AI tool for a defined business reason inside a defined window. Capped at 90 days, named owner, scoped data classes, exit plan if the pilot fails.
• Regulated-data exception. A use case touches client regulated data and needs an extra contractual clause or supplemental DPIA before approval. Owner: Compliance with the named business owner.
• Time-bound emergency exception. Production incident or commercial deadline requires a 24-72 hour use of an otherwise unsanctioned tool. Capped at 7 days, post-hoc DPIA required, named approver in the incident channel.
• Permanent edge exception. A long-tail use case that does not fit the sanctioned stack and cannot wait for full intake. Lower data-class scope, additional monitoring, quarterly review by the governance committee.

The audit trail

Every exception gets an entry in the inventory with the exception type, the named approver, the data classes scoped in, and the expiry date. The audit trail is the single artefact that proves the company is governing rather than tolerating — and it is the artefact a regulator or works council will ask for first if a shadow-AI complaint surfaces.

Operating model — who owns what

The governance framework only works with named ownership. The split that works in 50-500 employee shops:

• CISO or IT Director — owns the inventory, the classification engine, and the technical due diligence at intake. The data-class boundary at the network and data-loss-prevention layer sits here too.
• Head of HR — owns the policy comms cadence, the manager training, the amnesty mechanics, and the coaching path. The works-council notification for EU staff sits here in most companies.
• Head of Compliance — owns the DPIA, the EU AI Act conformity assessment, the DPDP Section 4 notice work, the GDPR Article 22 review, and the legal-basis register.
• Accountable executive — a CISO, a Chief Privacy Officer, or a dedicated AI Governance Officer. Owns the quarterly governance committee, the executive escalation path, and the regulator interface.

Where governance and detection connect

The detection layer (covered in the shadow AI detection playbook) surfaces unsanctioned use from network egress, output velocity, document audit logs, vocabulary markers, and self-disclosure. Each surfaced system flows into the governance loop as a new inventory candidate — classification, intake, decision.

The reverse arrow matters too. Governance defines which data classes can flow through which systems, and that decision drives the data-loss-prevention rules at the detection layer. The two-way handshake is what makes the model operational rather than aspirational. A company can stand up either layer first, but the value compounds when both are running.

FAQ