If your employees use ChatGPT, Copilot, or Gemini on personal data — and they do — GDPR Article 35 likely requires a DPIA. Not because AI is special. Because the processing is risky in familiar ways: new technology, employee decision support, large-scale handling, and messy combinations of datasets.

That is the operational starting point.

The ICO's generative AI guidance and its 2024 consultation responses made this plain in practice: if staff use generative AI tools on personal data, you need to assess necessity, proportionality, rights impact, security, processor terms, and transfers before rollout. If the residual risk stays high after controls, GDPR Article 36 points to prior consultation with your supervisory authority.

EDPB Guidelines 4/2019 on Article 35 are the other anchor. They set out nine criteria for likely high-risk processing. Employee LLM use often hits three to five of them: use of new technological solutions, evaluation or scoring, large-scale processing, matching or combining datasets, and vulnerable data subjects where customer complaints, health details, or employee data enter prompts.

This is the working document.

Take it, edit the fields, and move.

The nine DPIA sections you actually need

Use this structure for internal employee use of ChatGPT, Microsoft Copilot, Gemini, or Claude:

  1. Processing description
  2. Lawful basis
  3. Necessity and proportionality
  4. Data subject rights
  5. Third-party recipients and processor terms under Article 28
  6. International transfers under Articles 44-49
  7. Security measures under Article 32
  8. Risk assessment
  9. Controls, owners, and review dates

Your DPIA needs evidence, not invented confidence. Tie the control set to what employees actually paste into tools, which categories appear, and where the highest-risk prompts happen.

!Prytive dashboard providing the Article 32 evidence base a DPIA needs — what categories of data actually enter which tools

Working template you can lift verbatim

1. Processing description

State the use case in one sentence. Name the tool, users, purpose, categories of personal data, and whether special category data may appear.

Use case: Employees use Microsoft Copilot for drafting customer responses.
Purpose: Drafting and summarising responses to inbound support queries.
Users: Customer support and account management teams.
Data categories: Customer name, account ID, support history, and occasionally health information if the customer includes it in a complaint or request.
Data subjects: Existing customers and customer-side contacts.
Frequency and scale: Daily use across [X] employees handling approximately [Y] tickets per month.

Also state the flow. Browser prompt, vendor processing, output returned, retention setting, logs, and admin visibility.

2. Lawful basis

Be blunt. Most internal drafting use cases land on GDPR Article 6(1)(f) legitimate interests, sometimes Article 6(1)(b) where customer servicing is tightly connected to a contract. Do not force consent into an employment setting unless you enjoy explaining imbalance.

Use case: Sales team uses ChatGPT Team to write proposals.
Likely lawful basis: Article 6(1)(f) legitimate interests.
Legitimate interest: Improving drafting efficiency for customer proposals while maintaining human review.
Balancing test summary: The processing is limited to business contact data, firmographic information, budget ranges, and internal pricing inputs. Residual risk increases where employees include unnecessary personal data or confidential deal details.

3. Necessity and proportionality

This is where weak DPIAs fall apart. Explain why the tool is needed, what limits apply, and why less intrusive options are not enough.

The tool is used only for drafting and summarisation, not for sole automated decision-making.
Employees are instructed not to include special category data unless the use case is approved and additional controls apply.
Prompt minimisation is required: names, direct identifiers, policy numbers, and free-text medical details must be removed or masked unless strictly necessary.
Outputs are reviewed by a human before sending.

Tie this section to actual workflow steps. If you cannot describe the allowed prompts, your DPIA is still theory.

4. Data subject rights

Cover access, erasure, objection, rectification, restriction, and transparency. If outputs influence customer treatment, say how that is disclosed and corrected.

Template language:

The controller remains responsible for Articles 13-15 and 16-21 GDPR rights handling. AI-generated drafts do not replace human decision-making. Where prompts or outputs contain personal data, records are retained only in approved business systems and not in unmanaged personal accounts.

5. Third-party recipients and processor terms

Name the vendor and the contract. This section should map to GDPR Article 28, not vague procurement comfort.

Use case: Employees use Microsoft Copilot for drafting customer responses.
Processor: Microsoft.
Contractual framework: Microsoft Customer Agreement and applicable Data Protection Addendum.
Role assessment: Microsoft acts as processor for covered enterprise services, subject to the configured product scope and tenant settings.
Subprocessors: Listed in vendor documentation and reviewed by privacy and security teams.

If you cannot describe the processor role cleanly, stop and sort the contract before rollout.

6. International transfers

Most LLM vendors process in the US, usually under SCCs plus supplementary measures. After Schrems II, that is not enough on its own. You need your own transfer risk assessment at the organisational level.

Use case: Employees use Microsoft Copilot for drafting customer responses.
Transfer position: Data primarily resides in the EU tenant, but Copilot grounding and connected services may involve US-hosted processing depending on configuration and support paths.
Transfer mechanism: Standard Contractual Clauses where applicable, plus vendor technical and organisational safeguards.
Controller assessment: The organisation has completed a transfer risk assessment covering data categories, access risk, encryption, logging, and prompt minimisation controls.

Cite Articles 44-49 in the DPIA and attach your transfer assessment. Vendor SCCs are paperwork. Your assessment is the actual work.

Security, risk, and controls for employee LLM use

7. Security measures under Article 32

This section needs specifics.

Controls in place:
- SSO and MFA for approved AI tools
- Role-based access and approved user groups
- Prompt-layer redaction for direct identifiers and financial data
- Browser-level blocking for high-risk prompts
- Redacted audit logs only; no storage of raw sensitive prompts in internal monitoring tools
- Retention limits and admin review of exceptions
- Staff guidance and mandatory training for approved use cases

For context on the gap between legacy controls and browser prompts, CASB coverage is usually not enough for prompt leakage.

8. Risk assessment

Score inherent risk, control effectiveness, and residual risk. Keep it readable.

Use case: Sales team uses ChatGPT Team to write proposals.
Main risks: disclosure of customer contact data, disclosure of internal pricing, onward transfer outside approved regions, inaccurate outputs copied into customer-facing documents.
Inherent risk: High.
Controls applied: approved account requirement, prompt redaction, policy restrictions, human review, transfer assessment, vendor DPA review.
Residual risk: Medium-high without prompt-layer controls; medium with enforced redaction and blocking.

If residual risk remains high, Article 36 is not optional theatre. It means prior consultation.

9. Controls, owners, and review dates

Give every control an owner and a deadline.

Control owner: Privacy Counsel for Article 28 and transfer review.
Control owner: Security for SSO, MFA, browser controls, and logging.
Control owner: Business lead for training and approved prompt patterns.
Review date: 90 days after launch, then every 12 months or on material product change.

Run the DPIA and FRIA together, but do not merge the legal tests

The EU AI Act adds a Fundamental Rights Impact Assessment in some cases under Article 27. Useful. It does not replace a GDPR DPIA under Article 35. Different legal hooks. Different questions.

A sensible team runs them as one project, with one evidence pack, then preserves separate conclusions for GDPR risk and AI Act fundamental-rights analysis.

That saves time. It also stops the usual compliance farce where one team writes a beautiful AI policy while another discovers, six weeks later, that nobody assessed transfers.

Takeaway

A workable DPIA for employee LLM use has nine sections: processing description, lawful basis, necessity and proportionality, data subject rights, Article 28 recipients, Articles 44-49 transfers, Article 32 security, risk assessment, and controls. That structure aligns with GDPR Article 35, Article 36 where residual risk stays high, EDPB Guidelines 4/2019, and the ICO's operational guidance on generative AI.

If you want the Article 32 evidence section to be based on real prompt activity rather than estimates, Prytive can produce the audit trail in 7 days.