Blog

Shadow AI and GDPR: 7/30/90 day action plan for CIOs and DPOs

Decorative illustration for title card

To immediately reduce GDPR risks posed by Shadow AI, launch three parallel actions: map actual usage (proxy logs, anonymous survey), provide approved EU-hosted alternatives, and deploy technical controls (DLP, CASB, LLM gateway) within 90 days. This is the roadmap CIOs and DPOs can activate starting this week.

The EDPS states it unambiguously: Shadow AI generates unlisted processing operations without DPIAs or DPAs, directly exposing the data controller to serious GDPR violations. Governance, secure alternatives, technical controls, and awareness-raising constitute the four recommended response pillars. (Source)

Who does what, and when:

Day 7 (CIO + DPO)

1. Extract 30 days of proxy and DNS logs to identify unauthorized AI domains.

2. Launch an anonymous survey across teams to measure the actual scale of usage.

3. Decide on targeted temporary bans for the most exposed tools (e.g., consumer-grade ChatGPT on HR and legal workstations).

Day 30 (CIO + DPO + HR)

1. Finalize complete mapping and classify data by sensitivity.

2. Publish a one-page AI charter with a whitelist of approved tools.

3. Make at least one secure alternative available (Microsoft 365 Copilot for Enterprise, Mistral AI for Enterprise, or local LLM via Ollama).

Day 90 (CIO + DPO + business units)

1. Deploy CASB, DLP, and LLM gateway to route AI traffic in a controlled manner.

2. Complete DPAs (Article 28 GDPR) for each validated tool.

3. Launch the AI ambassador program and measure the percentage of LLM traffic routed via gateway.


Key points

Reducing GDPR risks from Shadow AI requires a simultaneous response on three fronts: usage mapping, approved EU-hosted alternatives, and technical controls deployed within 90 days.

PointDetails
Act within 7 daysExtract proxy logs and launch an anonymous survey to measure the actual scale of undeclared AI usage.
Provide alternatives before blockingDeploying Microsoft 365 Copilot for Enterprise, Mistral AI, or Ollama reduces migration to uncontrolled personal devices.
Combine 5 to 8 detection methodsProxy, CASB, DLP, DNS, endpoint, and invoice auditing enable estimated coverage of 70% to 90% of detectable Shadow AI.
Validate DPA and DPIA before any deploymentAny AI tool processing personal data requires an Article 28 contract and, for high-risk uses, a prior DPIA.
Safe-doc as a protection layerStateless pseudonymization upstream of each LLM call reduces residual risk and produces audit evidence usable by the DPO.

Table of contents

What is Shadow AI, and how does it differ from Shadow IT?

Shadow AI refers to the full range of artificial intelligence tools used by employees without validation or oversight from IT or the DPO: generative chatbots like consumer-grade ChatGPT (OpenAI), coding assistants like GitHub Copilot on personal accounts, audio transcription bots, or image generation tools. Usage is often casual and well-intentioned. The risk, however, is structural.

Three concrete examples illustrate how Shadow AI emerges in daily work:

  • A lawyer pastes a draft client contract into ChatGPT for a quick summary, without realizing the text transits to servers outside the EU.
  • An HR manager uses an online transcription tool to transcribe job interviews containing sensitive data.
  • A developer integrates an unapproved LLM API into an internal pipeline, creating an undocumented data flow.

Classic Shadow IT (an unapproved SaaS tool, a personal Dropbox share) already poses governance problems. Shadow AI goes further on three specific points. First, data injected into a prompt may be used to train the model at the provider's end-something a simple storage tool does not do. Second, nearly all consumer LLMs operate from US-based servers, constituting a transfer outside the EU subject to GDPR Chapter V requirements. Third, processing performed via an LLM is rarely recorded in the register of processing activities, making any DPIA impossible to produce during an audit.


What are the concrete GDPR risks of Shadow AI for your organization?

The risks of Shadow AI span six categories, each with a priority mitigation measure. The table below summarizes the most exposed data types and their GDPR impact level.

Data typeShadow AI usage examplesGDPR impactAdditional risk
Customer dataContract summaries, CRM pasted into promptsHigh (arts. 28, 32)Transfer outside EU, loss of trade secrets
HR dataCVs, interviews, performance reviewsHigh (special category data, art. 9)DPIA mandatory if automated scoring or sorting
Intellectual propertySource code, patents, strategyMedium to highLoss of confidentiality, competitive risk
Financial dataFinancial statements, forecastsHigh (trade secrets)Violation of sector-specific regulatory obligations

On the legal side, three texts directly govern the situation. Article 28 of the GDPR requires a data processing agreement (DPA) with any supplier processing personal data on behalf of the controller. Article 32 mandates appropriate technical and organizational measures. Chapter V conditions any transfer outside the EU on adequate safeguards (adequacy decision, standard contractual clauses). The AI Act adds a layer: high-risk uses (CV sorting, customer scoring, surveillance) require specific compliance assessments before deployment.

Unlisted Shadow AI processing is, by definition, processing without a documented legal basis, without verifiable security measures, and without the ability to exercise data subject rights (access, rectification, erasure). In the event of a CNIL inspection, the absence of a DPA and DPIA constitutes a serious violation, regardless of any actual data breach.

The practical consequences extend beyond administrative fines. A company unable to respond to an access or erasure request because data has passed through an undocumented LLM is legally unable to honor data subject rights. Loss of trade secrets is often irreversible.


How to build a prioritized 5-step action plan for CIOs and DPOs?

A five-step plan structured over 90 days enables a shift from prohibition to governance without blocking productivity.

Step 1 - Flash audit (Day 7, CIO)

1. Extract proxy/DNS logs and identify the 10 to 15 most-queried AI domains.

2. Cross-reference with cloud invoices and browser extensions installed on workstations.

3. Launch an anonymous 5-question survey to measure frequency and use cases.

Step 2 - Mapping and classification (Day 30, CIO + DPO)

1. Build a versioned Shadow AI register: tool, usage frequency, data type injected, department.

2. Apply the sensitivity × volume matrix: "confidential/critical" uses trigger immediate action.

3. Classify data according to GDPR categories (ordinary data, special categories under art. 9).

Step 3 - Charter and whitelist (Day 30, DPO + HR)

1. Draft a one-page AI charter: scope, authorized tools, prohibited data, request procedure.

2. Publish the whitelist with at least three validated alternatives (see next section).

3. Obtain executive sponsor (CEO or CIO) signature to give the policy weight.

Step 4 - Secure alternatives (Day 30-60, CIO)

1. Deploy Microsoft 365 Copilot for Enterprise, which offers contractual guarantees against data reuse for training absent in consumer versions.

2. Evaluate Mistral AI (European provider) for sensitive text uses, with hosting on Scaleway or OVHcloud in France.

3. Test Ollama for local (on-prem) deployment on internal workstations or servers, eliminating any network transfer.

Step 5 - Technical controls and ambassadors (Day 90, CIO + business units)

1. Deploy CASB, DLP, and LLM gateway (see next section).

2. Appoint an AI ambassador per department to relay the policy and surface needs.

3. Measure the percentage of LLM traffic routed via gateway as the main KPI.

Pro tip: Don't start with prohibition. [Providing attractive alternatives before blocking](https://www.automatisation-intelligence-artificielle.fr/blog/shadow-ai-risques-entreprise/) reduces the risk of migration to personal devices or VPNs, which are far harder to monitor.


How to build a prioritized 5-step action plan for CIOs and DPOs? - overview diagram

Which technical controls enable detection and blocking of unauthorized AI usage?

No single method suffices. Combining at least five to eight complementary methods achieves estimated detection coverage of 70% to 90% of detectable Shadow AI.

Catalog of controls to combine:

  • TLS/SNI inspection and outbound proxy: identify connections to OpenAI, Anthropic, Mistral, and other known LLM provider APIs, without full content decryption.
  • CASB (Cloud Access Security Broker): apply access policies to cloud AI applications, with identity control and session logging.
  • DLP (Data Loss Prevention): detect sensitive data patterns (company registration numbers, personal data, standard contractual clauses) in outbound flows before they reach an LLM.
  • DNS monitoring: spot resolutions to AI domains not listed in the whitelist.
  • Endpoint monitoring: track browser extensions and local processes that may call LLM APIs directly.
  • Cloud invoice audit: identify AI subscriptions paid by personal card or via shadow accounts.
  • SIEM with AI rules: correlate events (unusual connections, abnormal outbound data volumes) to detect undeclared usage.
  • IAM/SSO integration: enforce single sign-on for approved AI tools, making usage traceable and access revocable.

For SMEs, priority goes to proxy logs and DNS monitoring, which can be deployed quickly without heavy infrastructure. Mid-size and large enterprises add CASB and DLP for finer coverage. Blind spots to watch for: APIs called directly from scripts (bypassing the proxy), desktop extensions installed outside MDM, and usage from unmanaged personal devices.

Pro tip: Aligning CASB, DLP, and identity control at the flow level-not just the network level-is security teams' recommended approach for a truly effective control architecture. Network blocking alone drives users to their phones.


Document pseudonymization: how to neutralize GDPR risk at the source?

When an employee absolutely must use a public LLM for a sensitive document, upstream pseudonymization is the most direct technical measure to reduce residual risk. It does not replace network controls, but it neutralizes the main threat: exposure of identifying data to a non-contracted third party.

When to pseudonymize?

Priority use cases are HR documents (CVs, performance reviews, employment contracts), customer contracts containing personal data or confidential clauses, and any financial document injected into an analysis prompt.

Typical operational flow:

StepActionResponsible
1. PreparationAutomatic detection of 90+ types of PII and confidential data in the documentSafe-doc (API or web interface)
2. PseudonymizationReplacement of sensitive entities with neutral tokens, without storage of the original documentSafe-doc (stateless mode)
3. LLM callSending the pseudonymized document to ChatGPT, Claude, or other LLMUser or automated pipeline
4. ResultRetrieval of the LLM response on pseudonymized dataUser
5. RestorationControlled de-pseudonymization via mapping export, if necessaryCIO / authorized user

This flow integrates both on the browser side (extension or web interface) and on the server side via REST API or Safe-doc's MCP connector. The PDF audit report generated for each processing operation constitutes audit evidence directly usable during a CNIL inspection.

Integration checklist for CIOs and DPOs:

  • Verify that the Safe-doc DPA covers Article 28 GDPR and mentions EU hosting.
  • Confirm stateless mode: no document should be stored provider-side.
  • Test mapping export to ensure restoration is possible when operationally needed.
  • Integrate audit reports into the register of processing activities as proof of technical measures.
  • Verify coverage of data types relevant to your sector (health data, financial data, legal data).

Pro tip: Pseudonymization compliant with Article 4(5) of the GDPR reduces the residual risk level of a processing operation, which may lighten DPIA requirements or modify its conclusions. Systematically document this measure in your register.


Before any DPO validation of an AI tool, seven checks are required. The CNIL and EDPS converge on these minimum requirements.

Documentary obligations:

  • DPA compliant with Article 28 GDPR: the data processing agreement must specify purposes, retention periods, security measures, and commitments not to reuse data for training purposes.
  • Register of processing activities: each validated AI use must appear in the register with its legal basis, data categories, and recipients.
  • DPIA for high-risk uses: automated CV sorting, customer scoring, employee surveillance, profiling. The AI Act strengthens this obligation for systems classified as high-risk.

Contractual verifications:

  • Explicit commitment not to reuse data for model training (to be distinguished from consumer terms of service, which often authorize such reuse).
  • Proof of EU hosting or equivalent safeguards (standard contractual clauses, adequacy decision) for non-EU providers.
  • Logging SLA: the provider must be able to produce access logs in case of an incident.

Special cases to monitor:

  • CV sorting and customer scoring are high-risk uses under the AI Act: a prior DPIA is mandatory, and the final decision cannot be entirely automated without a right to human review.
  • Audio transcription tools processing health or union data fall under Article 9 of the GDPR: enhanced legal basis required.

The CNIL reminds that GDPR compliance of an AI tool is not limited to the provider's privacy policy. The data controller remains solely responsible for the lawfulness of the processing, the legal basis chosen, and the security measures implemented. Consulting CNIL resources on AI and data protection enables anticipation of priority control points.

For contracts and DPA clauses, the guide to contract confidentiality and artificial intelligence details the wording to require.


How to deploy AI governance that lasts?

An AI policy only lives if it is supported by identified people and measured by concrete indicators. Prohibition without structure erodes within weeks; shared governance lasts 18 months.

The four operational pillars:

1. Executive sponsor (CEO or CIO): signs the AI charter, validates the budget for approved alternatives, arbitrates conflicts between productivity and compliance.

2. AI lead (CIO or CISO): manages the Shadow AI register, coordinates technical controls, reports quarterly KPIs to the board.

3. DPO: validates DPIAs, signs DPAs, liaises with the CNIL in case of an incident.

4. AI ambassadors (one per department): relay the policy, collect business needs, surface undeclared usage without stigmatizing.

KPIs to track quarterly:

  • Percentage of LLM traffic routed via approved gateway (target: > 80% at Day 90).
  • Number of incidents linked to prompts containing sensitive data detected by DLP.
  • Adoption rate of approved tools vs. unauthorized tools (measured by proxy logs).
  • Results of the quarterly employee survey on knowledge of the AI charter.

Training plan:

  • 30-minute awareness session for all employees: what is Shadow AI, what are the risks, which tools to use.
  • 90-minute business workshops for high-risk teams (HR, legal, finance): practical cases, demonstration of approved alternatives.
  • Quarterly email reminder with a recent (anonymized) incident example to maintain vigilance.

The technical governance combining continuous discovery, prompt inspection, and identity control is essential for French SMEs, where unregulated use remains frequent and where outright prohibition has regularly shown its limits.


Why prohibition alone does not work in French SMEs and mid-size enterprises

Organizations that have tried to block access to LLMs without offering an alternative have observed the same phenomenon: usage migrates to personal devices, 4G/5G connections, and consumer VPNs, out of all visibility. The risk does not disappear; it becomes invisible.

The approach that works combines three elements in this precise order: first, attractive and performant alternatives (employees must prefer the approved tool to consumer-grade ChatGPT); second, technical controls that make unauthorized usage visible without making it impossible; and third, a culture of accountability supported by AI ambassadors. Compliance is not an objective in itself for business teams; productivity is. Aligning the two is the only sustainable strategy.

Feedback from the field in SMEs and mid-size enterprises confirms that organizations that involved business units from the mapping phase obtained significantly faster adoption of approved tools than those that imposed the policy top-down. Employees who participated in defining the rules respect them better and surface problematic usage more readily.


Safe-doc: pseudonymize your documents before each LLM call

Your teams already use LLMs. The question is no longer whether to prevent it, but to ensure sensitive data never transits in clear text. Safe-doc inserts as a protection layer between your documents and any AI tool: real-time pseudonymization, zero storage, detection of 90+ types of PII and confidential data.

Safe-doc

Concretely, Safe-doc integrates into your LLM gateway via REST API or MCP connector, or directly into your employees' browsers. Each pseudonymized document generates a PDF audit report, immediately usable during a CNIL inspection or DPA review. The restoration mapping remains under your control, on the enterprise side.

For legal departments and DPOs seeking a documentable technical response, Safe-doc provides proof that appropriate measures have been taken within the meaning of Article 32 of the GDPR. Visit the page dedicated to DPOs to see how to integrate Safe-doc into your compliance framework or request a rapid audit of your current AI usage.


Sources

The references below cover the regulatory, technical, and operational dimensions addressed in this article. They constitute a solid starting point for documenting your approach during an audit.

Recommendation