Privacy and Artificial Intelligence: Controls and

Introduction

Many organisations have already put generative AI tools into use. Policies exist, an updated privacy notice may be published, and someone presented a slide deck to a governance committee. Then an internal auditor asks a few simple but precise questions — and the tone of the room changes.

The issue is rarely whether the company has an AI policy. The question is: which model version was in use on a given date, who approved that specific use, and where is the dated evidence that the controls were actually performed? From a compliance and audit perspective, privacy and AI are the same discipline: a chain of dated decisions and verifiable artifacts.

This article is practical, not legal. It does not interpret GDPR or give legal advice. It explains how to organise controls and evidence so an internal auditor, DPO or oversight body can verify compliance without relying on assurances alone.

Why evidence matters more than policy in AI projects

Auditors don’t dispute that a policy exists. They ask: who executed the control described in paragraph X, on what date, and where is the proof? How was a non-conformity opened six months ago handled, and who validated the closure? If the registry can’t answer, the review stops.

The 2024 regulatory activity around large-scale consumer systems has shown that transparency, legal bases, fairness and data subject rights are enforceable requirements for AI systems. Authorities apply existing data protection rules (GDPR) and coordinate with sectoral frameworks (for example, AI Act obligations and supervisory expectations). That makes documentary evidence crucial.

A defensible verification chain contains: the requirement or policy, an operational control, a named control owner, dated and verifiable evidence, an audit trail, a documented finding where applicable, and a verified remediation. If any link is missing, the control exists only on paper.

Key operational distinctions that reduce debate

Policy vs execution. Declaring that prompts must be classified does not prove someone classified them. The evidence is the filled registry, not the policy paragraph.
Exception vs non-conformity vs incident. An authorised temporary exception is different from a persistent non-conformity or an incident that produced impact; conflating them renders the registry unusable.
Software vs responsibility. Tools can log, version and link records, but they don’t approve or assume legal responsibility for decisions.
Operational compliance vs legal opinion. A legal opinion interprets regulation; operational evidence proves controls were executed.

Relying on a consistent registry is the practical difference between passing an audit and receiving findings. Adoption of tools often outpaces documentation: many retail, service and back-office processes embed AI before governance catches up. A continuous, versioned register typically wins an audit.

Risks to data subjects across the AI lifecycle

Risk changes by phase. Treating ‘‘AI risk’’ as a single line item produces generic controls and useless evidence. Each phase requires a different control and specific evidence.

Data collection & training: Risk — lack of lawful basis or missing source documentation. Control — verify legal basis and provenance of training data. Evidence — a source register with legal basis and versioning.
Inputs & prompts: Risk — users disclose identifying, health or confidential data in prompts. Control — prompt classification and a list of authorised tools. Evidence — approved tools registry and access logs.
Outputs & generation: Risk — generation or publication of third-party data, deepfakes, or misleading content. Control — provenance checks and publication authorisations. Evidence — publication authorisation records and usage logs.
Automated decision-making: Risk — significant or legal effects without human oversight (Article 22 GDPR). Control — human-in-the-loop procedures and appeals. Evidence — human review logs and records of challenges.
Model or dataset changes: Risk — new or increased exposure after updates. Control — trigger the DPIA and re-assess. Evidence — model version linked to DPIA with dates.
Post-release monitoring: Risk — drift, bias, or new failure modes. Control — periodic testing against thresholds. Evidence — dated test reports, owners and corrective actions.

Three phases that cause the most exposure

Inputs and prompts: This is the most common source of real incidents. A staff member pastes a medical report or contract into a chat because the tool was provided for productivity — that’s a classic data leakage caused by unclear boundaries.
Outputs and generation: Harm can affect people who never interacted with the system (a synthetic voice, a deepfake image, or a generated narrative about a third party). These people may not even be aware of the treatment.
Model or dataset change: Organisations often lose traceability when they change providers or upgrade model versions. A model update should re‑trigger risk assessment and DPIA review, but this frequently does not happen.

Regulators expect data protection by design and continuous oversight, including documented risk classification, technical documentation, auditability of training data (where feasible), algorithmic audits, and recorded tests for accuracy and bias. For any decision that is ‘‘solely automated’’ with significant effects, supervision and meaningful contestability are required.

Roles, legal bases and accountability in AI projects

The compliance blocker in many projects is not technical: it’s the question of who is responsible for what. A vendor’s generic statement that they “comply with GDPR” is insufficient: organisations need clarity on data controller/processor roles, sub‑processors, and international data flows.

Typical responsibilities and minimum evidence:

Data controller: defines purposes and approves the use case — evidence: dated approval resolution.
AI service provider: declares sub‑processors, transfers and home jurisdiction — evidence: supplier profile and transfer clauses.
DPO: issues an opinion on DPIA and residual risk — evidence: dated written opinion referencing the case.
Control owner: owns the control, its deadlines and verification — evidence: named owner and recorded verification.
Internal user: uses the tool within authorised limits — evidence: recorded acknowledgement of policy and training completion.

Controllers and processors under Article 28 GDPR need precise contractual instructions. If instructions are generic or missing, the chain of responsibility breaks where it is most needed.

Coordination between GDPR and AI Act: obligations, not just principles

The AI Act and GDPR overlap operationally: regulators expect classification of risk, technical documentation, human oversight and post‑deployment monitoring. For governance teams this means four operational obligations — each with its own traceable evidence: risk classification, technical documentation, human-in-the-loop controls, and monitoring results.

Choose the legal basis based on purpose

Article 6 GDPR applies to ordinary personal data; Article 9 governs special categories. In employment contexts, consent is often a weak basis due to power imbalance and should be considered carefully. Document the legal basis selection for each purpose before signing approvals — not retroactively.

Segregation of duties

The proposer of an AI use should not be the only approver and verifier. A defensible sequence is: documented business proposal, controller approval with DPO opinion, execution by the control owner, and independent verification by internal audit or an oversight board. Tools can record decisions but cannot replace human sign-off.

When a DPIA is required and how to document it

A DPIA is required when processing is likely to result in a high risk to individuals’ rights and freedoms (Article 35 GDPR). The tricky part is timing: teams often delay assessment until after deployment. A DPIA must be performed at design and before large or risky treatments go live.

How to build a DPIA in eight steps

Describe the use case: purpose, system, provider and exact model version. A DPIA without model version is not traceable to what actually ran.
Map categories of data subjects: employees, candidates, customers, and third parties.
List data types and sources, including uploaded documents and external datasets.
Assess necessity and proportionality: document minimisation, retention limits and alternatives.
Identify risks to rights and freedoms and link each mitigation measure to the risk it reduces.
Record tests: accuracy, bias, resilience, content filters and escalation mechanisms, with dates and authors.
Collect controller approval and DPO opinion in writing and attach them to the DPIA.
Reassess whenever the model, dataset, provider or purpose changes. New versions do not inherit previous assessments automatically.

For sensitive categories (health, finance, identity) apply exclusion rules for prompts, use pseudonymisation where feasible and set retention constraints. Each exception or incident must be traced to system, provider, model version, users involved and remediation timeline.

Data subjects without accounts and access requests

One often-missed DPIA element is people whose data enters a system even though they never created an account. Publicly accessible conversational products and some integrated services may process data about third parties. DPIAs should describe how such individuals are informed, how they can exercise rights (access, deletion, objection) and how requests enter the treatment register.

Employee data in corporate AI chatbots

A common leakage mode is: an employee pastes a contract or personnel file into a chatbot to get a summary. This does not require malicious intent — it is ordinary behaviour when boundaries are not clear.

A generic “do not enter personal data” rule is not an effective control: it has no owner, is not verifiable and produces no evidence. Effective controls are: an approved tools registry, pre‑use authorisation, and an explicit list of prohibited content for each tool.

Practical data categories and controls (examples):

Public data: press releases already public — allowed on authorised tools; evidence: tools registry entry.
Ordinary personal data: customer contact details — allowed only with approved tool and legal basis; evidence: access logs and treatment registry reference.
Special category data (Article 9): health records — prohibited unless exceptional and authorised; evidence: technical block, training records and DPIA.
Trade secrets: draft contracts or pricing — prohibited on non‑contracted tools; evidence: contracted tools list and periodic verification.
Minor’s data: banned without a specific assessment; evidence: DPO approval and DPIA revision.

From prompt classification to periodic checks

Five core controls sustain the whole framework: contractual prohibition of data reuse for training, retained access logs, a documented erasure/rectification procedure, training with recorded acknowledgement, and periodic tool reviews. If a registry exists these are verifiable within an hour; if not, they are effectively untestable.

Training evidence should be more than a signed paper: it must be a recorded acknowledgement with date and content. AuditReady captures such confirmations via secure links and produces automatic evidence when required.

Published outputs and personal data of third parties

Can you use an AI‑generated voice or face? There is no universal yes/no. Synthetic content can be used for fraud, defamation or identity substitution, and publishing the likeness or voice of real people may violate GDPR principles (lawfulness and fairness) without proper legal basis.

Four checks before publishing any generated output

Provenance: Which data sources or inputs produced this output? If the answer is “unknown,” the check fails.
Rights and consent: Is there a legal basis to use this person’s voice/image? Are consents recorded where necessary?
Purpose and reasonable expectations: Would the person expect to be represented in this way? Internal use differs from public publication.
Traceability: Does the output have a date, an author and an approval record? Without these three elements it is indefensible months later.

If a vendor claims a different jurisdictional interpretation, this does not relieve the controller of the duty to show what data produced the output and who authorised its release.

When a takedown or deletion request arrives, the steps are: identify the content, stop dissemination, respond substantively and record all actions in the register. A removed video without documented removal decisions offers no protection in a later review.

AI use registry and minimum evidence to maintain

An AI use registry is not an app inventory. It should have one row per use case, linked to a verifiable dossier. Free‑text fields that do not point to auditable files are worthless. For guidance on which artifacts to attach to assessments see this list of evidence to include in a privacy assessment: https://audit-ready.eu/en/blog/quali-evidenze-includere-in-un-assessment-privacy

Minimum fields for the AI use registry

Use case ID (stable and referenced across artifacts).
System and active model version, with start date.
Owner (a named person).
Business process or asset connected to the use.
Clear statement of purpose.
Categories of data and categories of data subjects.
Legal basis, with article reference.
DPIA reference and date.
Provider and sub‑processors, including any extra‑EU transfers.
Inherent risk and residual risk rating.
Compensatory controls with verifiable measures.
Review/re‑assessment date.
Retention period and any legal holds.
Event type: authorised exception, non‑conformity, or privacy/security incident.
Date and reference for closure or renewal of exceptions, with supporting approval.

A registry’s value is revealed when things change: an auditor must reconstruct which model version was active on a particular date and which DPIA covered that version. If the registry does not keep version history, reconstruction relies on memory, which is not evidence.

Linkages with whistleblowing and governance channels should be explicit: issues affecting corporate compliance or Model 231-like programmes should reach oversight bodies through reserved channels and documentation pathways.

Common mistakes and a pre-audit checklist

Mistakes that lead to findings

Retroactive approvals. If the approval date post‑dates actual use, the auditor flags it immediately.
DPIA never updated. The model changed but the DPIA remains for the old version.
Perpetual exceptions. Repeatedly extended exceptions lose their temporary character and indicate missing controls.
Scattered evidence. Controls executed but evidence stored across emails and chats is effectively lost for audit purposes.
Screenshots without metadata. Images of UIs do not prove when or where they were captured.
Unverified closures. A finding marked closed without independent verification remains open.

Six questions to apply to a real use case

Does every use case have a named owner, legal basis and dated DPIA?
Did the last model change re‑trigger the DPIA?
Can an auditor reliably reconstruct who used the tool and with what category of data?
Do approvals precede use or follow it?
Does every exception have a recorded expiry and approval?
Does every finding have a verified closure with evidence?

Apply these to one real use case before the next audit instead of as a generic questionnaire. AuditReady separates what is ready, what is missing and what requires human action so teams can prioritise effectively.

Conclusion

An AI audit evaluates the continuity of the evidence chain more than the elegance of policies. Owners, legal bases, approvals, dated evidence and verified closures must compose a continuous trail. AuditReady links AI use cases, privacy registries, controls, findings and remediations and can produce an Audit Day Pack for reviewers. See how the package is built on AuditReady: https://audit-ready.eu/?lang=en

Privacy and Artificial Intelligence: Controls and Audit Evidence