Privacy, Legal and Compliance

Executive summary

Privacy, legal and compliance for AI systems applies privacy by design and accountability to data flows that are easy to get wrong at LLM scale: full prompts logged, customer PII in embeddings, training on inboxes without basis, retention beyond policy, cross-border inference without transfer mechanism. An AI Solution Engineer produces processing maps, DPIA inputs, lawful basis analysis, retention schedules, residency documentation and compliance control matrices aligned to UK GDPR / EU GDPR themes—lawfulness, fairness, transparency, purpose limitation, minimisation, accuracy, storage limitation, integrity, confidentiality—and sector rules (FCA, HIPAA themes, etc.). Legal sign-off is not a rubber stamp; it requires accurate AI-specific flows you can explain to a regulator in plain language.

When to use this page

• Before collecting, logging or retaining prompts, feedback, traces or fine-tuning data.
• When processing personal data in RAG corpora, agent tool responses or human review queues.
• When data or inference may leave UK/EEA residency boundary—cloud region, model API, support logs.
• When launching customer-facing or employee monitoring AI features.
• When legal, DPO or privacy office requests DPIA, RoPA update or subprocessor review.
• When retention, DSAR or breach scenarios expose full conversation logs without redaction.
• Pair with Security Engineering for technical controls and Responsible AI Governance for risk classification overlap with EU AI Act themes.

Executive view

Ask: **What personal data flows through the AI, on what lawful basis, for how long, and where does it sit geographically?** Challenge launch when DPIA is "in progress" without dated actions or when subprocessors include model providers not in the register.

Decision required: Is residual privacy risk documented—and does logging design support **DSAR and deletion** without shutting down the entire platform?

Technical view

Build processing maps from actual architecture; implement **minimisation** (redacted logs, trace IDs, pseudonymisation); enforce **retention TTLs** in log and vector stores; document **inference vs training** boundaries; never fine-tune on production PII without legal workflow.

Align with security redaction (topic 17) and observability schema (topic 20)—privacy is not "legal will fix it later."

Why this matters

Large language models amplify privacy mistakes. A classical app might log user IDs; an LLM app logs entire conversations—names, account numbers, health details, employee grievances—in plain text. One misconfigured log bucket or overly long retention creates GDPR Article 5 violations (storage limitation, minimisation) and breach notification obligations under Articles 33–34.

Regulators and plaintiffs ask concrete questions: What was the lawful basis for processing customer chat to improve the model? Why were prompts retained seven years when privacy notice says ninety days? Did UK customer data get inferred in a US region? Teams that cannot answer from documented processing maps face enforcement, contract termination and programme shutdown—not abstract "compliance risk."

The AI Solution Engineer does not replace legal counsel but translates architecture into privacy artefacts: data categories, purposes, recipients, transfers, retention, rights mechanisms. You flag when engineering choices conflict with policy (full prompt logging vs minimisation) before go-live, not during DSAR panic.

Weak programmes copy a generic DPIA template with "AI" in the title. Strong programmes maintain processing maps per feature, retention aligned to logs and indexes, subprocessor registers including foundation model vendors, Lawful Basis Assessments where legitimate interest is claimed, and deletion runbooks that work at trace-ID granularity. When DPO asks "can we delete User X's data?" you answer with systems, fields and SLA—not "we'll ask the vendor."

Connect to Security & privacy playbook, Governance for high-risk AI classification, and Evaluation & observability for logging design.

Learn

GDPR principles applied to AI

Principle	AI application
Lawfulness, fairness, transparency	Document basis; explain AI use in notice; no dark patterns
Purpose limitation	Training, eval, quality improvement need explicit purpose
Data minimisation	Redact logs; don't index PII unnecessarily; trim retrieval
Accuracy	Wrong AI outputs about people may breach accuracy duty
Storage limitation	TTL on prompts, traces, embeddings, review queues
Integrity and confidentiality	Encryption, access control—overlap with topic 17
Accountability	RoPA, DPIA, policies, evidence of compliance

UK GDPR mirrors EU GDPR post-Brexit with UK-specific adequacy and ICO guidance; treat dual compliance when operating across UK and EEA.

Lawful basis for AI processing — choose deliberately

Common bases for enterprise AI (legal must confirm per case):

Basis	Typical AI use	Notes
Contract	Feature user asked for—servicing bot under T&Cs	Scope limited to contract delivery
Legitimate interest (LIA)	Fraud detection, limited internal productivity	Document LIA; balance test; opt-out where required
Consent	Optional model improvement using customer chats	Granular, withdrawable; not blanket T&Cs
Legal obligation	Regulated record-keeping with AI assist	Statute defines retention
Public task / official authority	Public sector decision support	Sector-specific
Vital interests	Rare; emergency health scenarios	Narrow

Unlawful patterns:

• "Improve AI" as vague purpose on all logs without basis
• Fine-tuning on customer emails under legitimate interest without LIA
• Employee monitoring via copilot logs without transparency and basis
• Consent bundled with unrelated services

Produce Lawful Basis Assessment one-pager per feature for legal review.

DPIA — when and what for AI

Data Protection Impact Assessment required when processing likely high risk to individuals—often triggered for AI:

• Systematic evaluation of individuals (profiling)
• Large-scale special category data
• Monitoring of publicly accessible areas (rare for text AI)
• Innovative technology (ICO/EDPB guidance includes AI)
• Automated decision with legal/significant effect (even if human review exists—document role)

DPIA sections (AI-enriched):

1. Description — feature, users, automation level, HITL
2. Necessity and proportionality — why AI vs rules/search
3. Data flows — sources, prompts, logs, embeddings, tool APIs, vendors
4. Risks to individuals — wrong advice, discrimination, leak, re-identification from embeddings
5. Measures — minimisation, retention, authZ, eval fairness, human oversight
6. Consultation — DPO, security, sometimes data subjects or works council
7. Sign-off and review triggers — model change, new data source, new region

DPIA is living—reopen on material change.

Processing map / RoPA entry — the core artefact

Record of Processing Activities entry (or processing map) per AI feature:

Field	Example content
Name	Customer Policy Q&A Assistant
Controller / processor roles	Bank = controller; Azure OpenAI = processor (subprocessor)
Categories of data subjects	Customers, prospects
Personal data categories	Name, policy number, query text, chat history
Special category	Usually none; flag if health/financial inference
Purpose	Answer policy questions during servicing
Lawful basis	Contract + legitimate interest for fraud logs (separate purpose)
Recipients	Internal servicing; subprocessors: {vendor list}
Transfers	UK South inference; no US transfer if prohibited
Retention	Redacted logs 90 days; traces 30 days; no training on prod chats
Security measures	Reference control matrix topic 17
Rights mechanism	DSAR via privacy portal; deletion by user_id in log store

Diagram: user → app → retriever → model API → logs → reviewers.

Retention — align policy, logs, indexes and backups

Retention mismatch is the most common AI privacy failure: privacy notice says 90 days; Splunk retains 13 months; vector DB never deletes orphaned chunks.

Data artefact	Typical enterprise range	Design note
Full prompts (if stored)	Avoid; if needed, days not years	Redact PII fields
Redacted traces + trace ID	30–90 days	Supports debug without content hoard
Aggregated metrics	13–24 months	No content if possible
Human review queue	Until review + 30 days	Access restricted
Embeddings of user uploads	Delete with user deletion request	Hard problem—prefer not to embed PII
Fine-tune datasets	Project-specific; legal approval	Versioned with expiry
Backups	Match primary TTL + restore test	Deletion must propagate

Implement TTL jobs; prove with audit sample quarterly.

Data residency and international transfers

Questions for every deployment:

• Where does inference run (region)?
• Where are logs and traces stored?
• Where does human review occur (offshore BPO)?
• Does vendor process in other regions for abuse monitoring or support?
• Are Standard Contractual Clauses, UK IDTA or adequacy decision in place?

Patterns:

• UK-only: Azure UK South, private endpoints, contract prohibiting transfer
• EEA-only: Similar with EU regions
• No transfer: On-prem or sovereign cloud; higher ops cost

Document in processing map; do not assume "EU company = EU data."

Minimisation in logging and observability

Design logs for debuggability without content hoarding:

trace_id: 8f3a2c...
user_id_hash: sha256(salt+id)
intent: policy_refund_query
model_version: gpt-4.1-2026-04
prompt_version: sys-v3.2
retrieval_ids: [doc-4412#chunk-7, doc-8891#chunk-2]
latency_ms: 4200
outcome: answered_with_citation
pii_detected: false

Store full prompt/response only in break-glass encrypted store with ** shorter TTL** and dual control access—or not at all.

Align with MLOps and Observability trace schema.

Training vs inference boundary

Inference-only (default for regulated enterprise): production data never used to train foundation model; optional opt-in improvement pipeline with separate basis.

Fine-tuning / RAG corpus:

• Corporate documents — often non-personal or business data; still check confidential info
• Customer chats — high risk; usually prohibited or consent-only anonymised set
• Employee data — works council, employment law

Document technical controls: production log export blocked from training buckets; network policies; DLP on export jobs.

DSAR, erasure and portability

Data Subject Access Request: must locate personal data across logs, review tools, feedback DB, possibly vector store.

Design for deletion:

• user_id or customer_id on every personal-data-bearing record
• Deletion API cascading: logs, sessions, review queue, cached embeddings from user uploads
• Vendor deletion process documented (model provider may not "unlearn"—contractual reality)
• SLA internal: e.g. 30 days aligned to GDPR

Portability: structured export if data processed by automated means on consent/contract basis—define format.

Special categories and children

Special category data (health, biometric, racial origin, etc.): explicit legal basis required (often explicit consent or substantial public interest)—most enterprise assistants exclude by policy and detect/block in DLP.

Children: ICO and GDPR enhanced protection; age gates; no profiling for marketing.

Flag in DPIA when domain touches these—even if "accidental" via user paste.

EU AI Act awareness (compliance interface)

EU AI Act (Regulation 2024/1689) layers product regulation on top of GDPR—not replacing it.

Themes relevant to privacy/compliance interface:

AI Act theme	Privacy/compliance touchpoint
Risk classification	High-risk systems need QMS, logging, human oversight—overlap topic 19
Transparency	Disclose AI interaction to users
Data governance	Training data quality for high-risk (if custom training)
Record-keeping	Logs retained for audit—align with minimisation tension—document balance

Full AI Act implementation is legal programme; ASE supplies technical flow accuracy for conformity assessments.

Sector overlays

Sector	Additional themes
Financial services (UK)	FCA Consumer Duty, fair treatment, record-keeping SMCR
Insurance	FCA, ICO guidance on automated decisions
Healthcare (UK)	UK GDPR + confidentiality; Caldicott; no patient in general RAG
Public sector	Equality duty, transparency, ALGO Act themes
Employment	UK GDPR employment context; monitoring policies

Reference sector legal—not generic GDPR slides.

Intellectual property and contractual use of content

Separate from GDPR but blocks launch:

• Licence to use documents in RAG index—publisher, third-party data feeds
• Customer contracts prohibiting AI training on their data
• Employee-generated content ownership
• Open-source licence on code generated by copilot

Processing map should note IP clearance for corpus sources.

Frameworks and methods

PRIV-AI — privacy design checklist

Step	Question
Personal data inventory	What PD categories enter prompts, logs, indexes?
Residency	UK/EEA only? Transfers documented?
Iawful basis	Per purpose documented and signed?
V minimisation	Can we log trace IDs instead of full text?
Access & rights	DSAR/deletion path tested?
Impact	DPIA required and current?
Retention	TTL everywhere including backups?
Evidence	RoPA updated? Subprocessors listed?
Transparency	Notice and in-product disclosure?
Accountability	DPO consult recorded?

Lawful basis decision tree (draft for legal review)

Is processing necessary to deliver contracted feature to this user?
  YES → Document Contract basis; scope to delivery only
  NO → Is there a compelling legitimate interest with minimal impact?
    YES → Complete LIA; implement opt-out if appropriate
    NO → Is explicit consent appropriate and obtainable?
      YES → Granular consent flow; no bundling
      NO → Do not process personal data for this purpose

Legal must approve—tree guides conversation, not replaces counsel.

Retention schedule template

Data type	Location	TTL	Legal driver	Deletion method	Owner
Redacted trace metadata	Log analytics	90 days	Storage limitation	Automated TTL job	SRE
Full prompt (break-glass)	Encrypted blob	7 days	Debug necessity	Secure wipe	Eng
Human review cases	Review DB	Review + 30d	Quality	Cascade delete	Ops
User feedback thumbs	App DB	1 year	Legitimate interest LIA	API delete	Product

DPIA risk register snippet

Risk	Likelihood	Severity	Mitigation	Residual
Wrong refund advice	Medium	High	RAG citations + HITL on compensation	Medium
PII in logs	High	High	Redaction pipeline	Low after fix
US transfer	Low	High	UK region pin + SCC if needed	Low
Re-ID from embeddings	Low	Medium	No user uploads indexed	Low

Subprocessor register (AI-specific entries)

Include at minimum:

• Foundation model API provider
• Embedding API if separate
• Vector DB SaaS if used
• Observability vendor (may receive traces)
• Human review BPO if offshore
• Cloud IaaS/PaaS

Review DPA and subprocessor notification clauses annually.

Transparency patterns

• Privacy notice section: AI features, purposes, retention, rights
• In-product label: "AI-generated; verify important details"
• Employee handbook addendum for internal copilots
• Cookie/consent if tracking behaviour for model improvement

ICO expects clear language—not buried in 40-page policy.

Real-world scenarios

Scenario A — UK insurer: full prompt logging remediation

Context: Customer servicing assistant in pilot; engineering logs full prompts and responses to Splunk for debugging; 847 GB accumulated over 5 months; includes customer name, policy number, health hints in free text.

Privacy review findings:

• Purpose debug not in privacy notice; basis unclear
• Retention indefinite vs notice 90 days
• No redaction; broad engineer access
• DPIA marked "not required" incorrectly

Remediation (8 weeks):

1. Processing map and DPIA completed; basis Contract for feature; Legitimate interest for security fraud signals (separate minimal log)
2. Logging redesigned: redacted metadata + trace_id default; break-glass full content 7-day TTL, dual approval
3. Splunk TTL 90 days; historical purge project £62K
4. DSAR procedure tested: locate by user_id_hash in 4 hours
5. Engineer access via just-in-time role

Measurable outcomes:

• Stored personal data volume ↓ 94%
• DPIA signed; ICO enquiry (proactive) closed with no enforcement
• Debug MTTR initially ↑ 15%; recovered with better trace schema by month 3

Lesson: Retention and minimisation must be engineered day one.

Scenario B — Retail bank: cross-border inference blocked

Context: Global bank UK entity; architecture defaults to US East Azure OpenAI for cost. Legal flags UK GDPR transfer issue for customer name + transaction questions in prompts.

Decision: Deploy UK South private endpoint; update RoPA; SCC + TRA documented for any residual vendor subprocessors (support/abuse monitoring) with data minimisation.

Numbers:

• Inference cost ↑ 8% vs US region—accepted vs conduct risk
• 0 UK customer prompts routed to US after network policy enforcement (verified by 30-day traffic audit)
• Subprocessor register updated 4 entries

Lesson: Residency is architecture decision, not legal footnote after build.

Scenario C — HR assistant: employee monitoring backlash

Context: Internal HR policy RAG; leadership wants full conversation logs for "productivity analytics" on who asks what.

Privacy/work council pushback: No transparency; no basis for monitoring; purpose creep from policy answers to surveillance.

Resolution:

• Purpose limitation: logs for quality and security only—not management analytics
• Transparency: all-staff email + intranet FAQ on logging
• Basis: Legitimate interest LIA for security incident investigation only
• Analytics dashboard shows aggregate query volumes—no individual attribution without HR/legal escalation process

Outcome: Works council sign-off; adoption 78% at 6 months vs 41% in shadow IT alternative; 0 grievances on monitoring.

Lesson: Purpose limitation and transparency prevent programme cancellation.

Scenario D — Fine-tune ambition stopped by contract review

Context: Product proposes fine-tuning on 12 months of customer support chats (2.3M conversations) to "improve tone."

Legal analysis:

• Customer T&Cs prohibit use of chat content for model training
• GDPR basis for new purpose insufficient without consent campaign
• Special category snippets appear in 0.3% of chats (health disclosures)

Decision: No fine-tune on prod chats. Instead: synthetic data generation + SME-authored examples; optional opt-in improvement programme designed for future.

Saved exposure: estimated £8M+ contract breach claims (internal model); programme continues inference-only.

Lesson: Training vs inference boundary is contractual and legal—not engineering preference.

Practice exercises

Primary exercise — Processing map (90 minutes)

Brief: Internal HR policy Q&A RAG for 5,000 employees; SSO; SharePoint corpus; logs to cloud analytics; Azure OpenAI UK region.

Tasks:

1. Complete processing map / RoPA row (all fields in Learn section).
2. Propose lawful basis per purpose (feature, security logging, quality sampling)—flag for legal review.
3. Design logging schema minimised for privacy; specify TTLs.
4. List subprocessors and transfer assessment.
5. State DPIA required? yes/no with triggers.

Acceptance criteria:

• No "indefinite retention" without legal statute citation
• Separate purposes for debug vs analytics vs security
• DSAR deletion mechanism named at field level

Stretch exercise — DPIA pack and retention programme (full day)

Brief: Customer-facing telecom mobile tariff FAQ assistant; 200k users/month; may log feedback; CRM tool integration for callback scheduling; EU and UK customers.

Tasks:

1. Full DPIA draft (7 sections) with risk register ≥8 risks.
2. Retention schedule for all data stores including backups and vendor logs.
3. Transfer mechanism documentation UK↔EEA and any US vendor subprocessors.
4. Transparency pack outline: notice changes + in-app disclosure.
5. DSAR/deletion runbook with test case: delete user U-12345.
6. LIA outline if legitimate interest used for fraud/abuse logging.
7. EU AI Act interface note: likely risk tier and logging implications (for legal).

Acceptance criteria:

• Tension between AI Act logging and minimisation explicitly addressed
• Callback CRM write documented as separate purpose/basis if needed
• No fine-tune on customer chats without consent path

Questions you should be able to answer

1. What personal data categories enter the AI system?
2. What is the lawful basis for each processing purpose?
3. Is a DPIA required, completed, and when is it reviewed?
4. Where does data physically reside for inference, logs and review?
5. What international transfers occur and under what mechanism?
6. What is retention for prompts, traces, embeddings, feedback, backups?
7. How does logging implement minimisation—what is not stored?
8. What is the inference vs training boundary technically enforced?
9. Who are subprocessors and are DPAs in place?
10. How does a DSAR get fulfilled—including vendor-held data?
11. How is erasure implemented across logs, indexes and review tools?
12. What transparency do users and employees receive about AI?
13. Are special category or children's data excluded and monitored?
14. What sector rules apply beyond GDPR?
15. What IP/licence issues affect the RAG corpus?

Negative cases — when privacy and compliance fails

Failure mode	Symptom	Prevention
Log everything	DSAR nightmare; breach magnitude	Minimisation by design
Retention theatre	Notice 90d; logs forever	TTL automation + audit
Basis shopping	"Legitimate interest" for everything	LIA per purpose
DPIA checkbox	Generic template	AI-specific flows
US region default	unlawful transfer	Residency architecture
Train on prod chats	Contract + GDPR breach	Technical boundary
Embedding PII	Cannot delete user data	Don't index uploads
Shadow subprocessors	New observability vendor unlisted	Register update process
No transparency	Employee/customer surprise	Notice + in-product
Ignore works council	Programme halted	Early consultation

Case study: the analytics creep. HR bot logs used for "who asked about redundancy" management reports. Unfair dismissal claim cites covert monitoring; programme shut; £290K settlement (reported internal figure). Fix: purpose limitation in architecture.

Case study: seven-year logs. Engineering copied enterprise log standard (7 years) to AI prompts. Regulator sample: violation storage limitation. Purge £180K; executive audit finding.

Case study: vendor training default. SaaS copilot default "help improve our models" on; customer PD entered global training. Contract breach notices from 3 clients. Emergency config change + indemnity negotiations.

Operating-model notes

Role	Responsibility
DPO / privacy office	DPIA sign-off, DSAR oversight
Legal	Basis, contracts, transfers
ASE	Processing maps, technical controls
Engineering	Retention jobs, redaction
SRE	Log stores, TTL enforcement
Product	Transparency UX

Cadence: RoPA review annual; DPIA trigger check every release with new data source or region.

Tension: audit logging vs minimisation

Regulators and AI Act may want proof of operation; GDPR wants minimal data. Resolution:

• Metadata-rich, content-poor audit logs
• Tamper-evident storage with hashed inputs where content cannot be stored
• Legal balance documented in DPIA residual risk

Document decision—not silent compromise.

RoPA maintenance workflow

1. Intake trigger: New feature, new data source, new subprocessor, new region → privacy ticket within 5 business days
2. Draft update: ASE updates processing map; legal reviews basis
3. DPO consult: Mandatory for Tier High or special category touch
4. Publish: Versioned PDF in document control; link from inventory (topic 19)
5. Annual refresh: Even if unchanged, confirm still accurate

Avoid RoPA drift where production diverged six months ago.

Pseudonymisation and anonymisation for AI logs

Technique	Use in AI	Limits
Hash user_id with salt	Correlation without name in default logs	Reversible with salt—protect salt
Tokenisation	Replace account number in traces	Token vault access controlled
Redaction	Strip regex PII from prompts before store	Imperfect on novel formats
Aggregation	Dashboards only	Loses debug granularity
Synthetic replays	Debug in lower env	Not prod data

Anonymisation (GDPR Recital 26) bar is high—assume pseudonymised data remains personal data unless expert certifies otherwise.

Processor vs controller decisions for enterprise AI

Common patterns:

• Enterprise customer is controller for employee/customer PD; cloud + model API are processors under DPA
• Vendor model provider often subprocessor—ensure flow-down terms and notification
• Internal copilot on employee data: employer typically controller; works council may require consultation

ASE documents data flow to subprocessors accurately—legal assigns roles.

Automated decision-making (Article 22) awareness

Article 22 restricts solely automated decisions with legal/significant effect. Many AI systems are assistive (human Decide)—document clearly:

• AI recommends; human approves in core system of record
• No auto-execution of adverse outcomes
• Logic explanation available to human reviewer (retrieval citations, not black-box score alone)

If fully automated decision contemplated—legal review mandatory; often prohibited or heavily constrained in credit/employment.

Privacy engineering patterns for RAG

Pattern A — Query-side minimisation: Strip PII from user query before embedding if not needed for personalisation; use session context token instead of name.

Pattern B — Retrieval ACL: User sees only chunks they may access—privacy and security overlap (topic 17).

Pattern C — Ephemeral context: Retrieved chunks held in memory only; not written to long-term logs—trade debuggability for minimisation.

Pattern D — Regional index partition: UK customer corpus and queries never co-mingled with US index—hard partition not filter-only.

Choose in DPIA with explicit trade-off note.

Scenario E — DSAR overload after logging fix

Context: After redaction migration, legacy logs still hold 9 months of full prompts; 340 DSARs in quarter vs usual 40.

Response:

• DSAR triage team scaled temporarily (4 FTE for 8 weeks)
• Legacy bucket mapped with automated search on user_id
• Parallel purge project with legal hold exceptions only
• New requests served from redacted store in SLA 28 days

Cost: £185K one-off; board approved retention cap policy preventing recurrence.

Lesson: Legacy log debt is balance-sheet item—budget purge when changing architecture.

Scenario F — Works council and copilot in Germany

Context: Multinational rolls out Microsoft Copilot to EU employees; German works council (Betriebsrat) requires DPIA, purpose limitation, no keystroke surveillance, training data opt-out verification.

Delay: 11 weeks for agreement; copilot scoped to Office apps without custom corp RAG until DPIA for internal docs completed.

Outcome: Phased rollout; DE users on reduced feature set initially; full parity 6 months later with signed agreement.

Lesson: Employment context privacy is procedural—not only technical minimisation.

Lawful basis examples table (illustrative — legal must confirm)

Feature	Purpose	Illustrative basis	Notes
Servicing chatbot answer	Deliver support	Contract	Scope to query handling
Fraud pattern detection on prompts	Security	Legitimate interest + LIA	Minimal fields logged
Model improvement from chats	Quality	Consent or legitimate interest	Often blocked by contract
Compliance audit log	Regulatory evidence	Legal obligation	Retention statute-driven
Internal analytics on query volumes	Capacity planning	Legitimate interest	Aggregated only

Use in workshops; never ship without legal sign-off column completed.

Privacy review gate in CI/CD

For Tier Medium+:

• Processing map version linked in release ticket
• Retention TTL config diff reviewed if logging changed
• New subprocessor field empty or approved
• DPIA status current or exception ID attached
• RoPA entry updated within 30 days of material change

Privacy engineer non-blocking comment on fail in mature programmes; blocking for Tier High regulated.

Children's data and education technology note

EdTech and youth-facing features: UK Age Appropriate Design Code expectations—high privacy default, DPIA mandatory, no nudge to weaken privacy. AI tutors require parental consent flows in many contexts—legal owns; ASE documents no profiling default in architecture.

Breach notification decision tree (high level — legal owns)

Suspected personal data breach?
  → Contain and assess within hours
  → Legal/DPO: reportable under GDPR Art 33 (72h to authority)?
      → If yes: notify authority; assess Art 34 user notification
  → Document timeline, data categories, approximate counts
  → Post-incident: update DPIA, logging, security controls

ASE supplies technical facts: what logged, who accessed, whether encryption applied, trace IDs affected.

Data Protection by Design workshop (half day)

Participants: ASE, privacy, eng, product

Outputs:

• Processing map v1
• Retention schedule draft
• Logging schema whiteboard
• Open legal questions list with owners
• DPIA required Y/N with triggers

Schedule before sprint 1 ends on greenfield AI features—retrofit cost 3–5×.

Comparing UK GDPR and EU GDPR for AI programmes

Topic	Practical note
Adequacy	UK adequacy decision for EEA transfers (monitor political changes)
ICO vs DPA	Similar principles; guidance wording differs slightly
Representatives	UK/EU rep may be required if offering services cross-border
Fines	Both substantial—compliance economics favour design-time privacy
AI guidance	ICO AI guidance; EU EDPS/EDPB statements—legal tracks both

Document which regime applies per user population—not per HQ location alone.

Contractual clauses checklist for model providers

• Processing purpose limited to inference (or defined training scope)
• Subprocessor notification and objection rights
• Deletion/support for DSAR within SLA
• Region pinning or transfer mechanism documented
• No use of customer prompts for model improvement without opt-in
• Security audit rights or SOC2/ISO equivalent
• Incident notification within 24–72 hours
• Exit plan: data return/deletion on contract end

Procurement and legal lead; ASE validates technical data flows match contract.

Records of processing — AI feature example (extended)

Feature: Employee leave policy assistant

Element	Detail
Data subjects	Employees (EEA + UK)
Categories	Employee ID hash, query text, role from SSO, policy docs (non-PD)
Special category	None intended; user may paste health—DLP scan + discard
Purpose 1	Answer leave policy questions
Purpose 2	Security fraud signals on prompts
Recipients	HR digital team; Azure OpenAI UK (processor); observability vendor (processor)
Retention	Query metadata 90d; break-glass 7d; no training on queries
Rights	DSAR via HR portal; deletion within 30d
DPIA ref	DPIA-2026-HR-AI-01 (approved 2026-02-14)

Use as template for practice exercise comparison.

ICO accountability expectations for AI (themes)

• Data minimisation demonstrable in architecture—not policy-only
• Transparency to staff and customers about AI use
• DPIA when high risk—including innovative tech
• Vendor due diligence on subprocessors
• Training records for staff handling AI-related DSARs
• Audit trail of changes to processing

ICO enforcement trends include logging and retention failures—operationalise TTL jobs.

Related playbook content

• Security & privacy — redaction, encryption, breach patterns
• Governance — risk tiers and EU AI Act alignment
• Evaluation & observability — privacy-preserving tracing
• Security Engineering — security controls supporting confidentiality
• Responsible AI and Governance — fairness, transparency, oversight
• MLOps, LLMOps and Observability — log schema and retention jobs
• EU AI Act (Regulation 2024/1689)
• AI Governance: NIST AI RMF and the EU AI Act
• How to use this Learning Map
• 8D Framework
• VALUE gate

Output

Expected outputs for this topic:

• Processing map / RoPA entry — purposes, categories, recipients, transfers, retention
• DPIA inputs or full DPIA — risks, mitigations, sign-off trail
• Lawful basis assessment — per purpose, flagged for legal confirmation
• Retention schedule — all stores including backups; TTL owners
• Residency and transfer documentation — regions, SCC/IDTA references
• Logging minimisation design — schema, break-glass policy, redaction
• DSAR/deletion runbook — tested procedure with SLA
• Subprocessor register updates — model and observability vendors

Practice checklist

• I documented all personal data categories entering prompts, logs and indexes
• I assigned lawful basis per purpose and flagged legal review items
• I determined DPIA requirement with explicit triggers for review
• I designed retention TTLs consistent across logs, backups and vendors
• I documented residency and transfers—not assumed from vendor marketing
• I separated inference from training with technical boundaries
• I specified transparency actions for users or employees
• I filed processing map in engagement pack with DPO consultation note

Key takeaways

• AI amplifies privacy risk through full-text logging and scale—minimisation and retention must be engineered, not policy-only.
• Lawful basis applies per purpose—debug, feature delivery, fraud, and model improvement are not interchangeable.
• DPIA and processing maps must reflect actual AI data flows, including subprocessors and tools.
• Residency and transfers are architecture decisions with UK/EU GDPR consequences.
• Training vs inference boundary protects against contract breach and unlawful repurposing.
• DSAR and deletion require user_id linkage across logs, review queues and optional indexes.

What to do next

1. Complete the processing map exercise for the HR policy assistant brief.
2. Continue with Responsible AI and AI Governance — connect privacy risks to risk tiers and approvals.
3. Open Security & privacy playbook for redaction and encryption patterns.
4. Align logging schema with MLOps and Observability.