Privacy and AI: Proving Control Over Time

This article focuses on operational steps (not legal advice). It explains what concrete evidence to keep so privacy controls over AI systems can be proven over time, how roles should be split, when a DPIA is required, how GDPR and the EU AI Act intersect, and practical checks you should run before the next audit.

Why privacy for AI is an evidence problem over time

Policies state intent. Audits require proof: did the control run, who executed it, when, and where is the dated evidence? The audit chain is always the same: requirement or policy → operational control → control owner → dated, verifiable evidence → immutable audit trail → exceptions or non-conformities → remediation. If any link lacks a date or a responsible person, the chain breaks.

Three distinctions that commonly cause confusion:

• Policy vs evidence. An approved policy does not prove the control was performed during a given period.
• Exception vs non-conformity. An exception is authorized, justified and time-limited. A non-conformity is an unauthorized deviation.
• Incident. Security or operational incidents are events that require their own evaluation and possibly notification; they are not recorded as exceptions or closed like an audit finding.

Rule of thumb: date, owner and version are the minimum for any evidence to be credible in an audit.

Inventory: map your AI systems and the personal data they touch

Begin with actual systems and flows, not commercial names. The same vendor may be used for customer support chats or for HR assessments — those are different legal and operational cases. If a business unit uses a tool that’s not in the inventory, an auditor will notice it by comparing access logs against the register.

Typical system categories and the minimum evidence to keep:

• Third-party generative chatbot: retain contract/DPA, supplier role (processor/controller), data residency/transfers, retention period, and a current treatment record entry.
• Models trained on web-scraped content: document sources, exclusion filters, minimization measures, and keep dated filter files; consider a DPIA for large-scale scraping.
• Scheduling or personnel evaluation systems: keep dated discrimination tests, decision logs, and appeal outcomes; ensure human verification where required.
• Document-support tools (internal search/answering): record who can query what, access logs, and rules to exclude sensitive folders.
• Experimental uses on production data: require owner approval, a deletion date, separation of environments, and a signed closure note for tests.

How to read the rows: a contract or DPA alone isn’t enough if your treatment register shows different purposes. For training datasets, auditors expect a dated list of sources and the filters applied. For HR-impacting tools, auditors expect dated discrimination testing and contestation logs. Experimental copies of production data are considered actual processing: approval, deletion date and test closure are required evidence.

Practical rule: any AI tool used by a team but missing from the inventory makes the register incomplete regardless of the model’s apparent risk.

Roles, responsibilities and segregation of duties

The controller (data controller) decides purposes and means and bears accountability under the GDPR. The DPO advises and monitors but does not replace the controller’s decision. System owners propose scope and controls. Suppliers’ roles (processor vs independent controller) must be contractually defined. Internal auditors verify independently; they do not perform the operational control they inspect.

Four-step lifecycle for introducing or changing an AI system:

1. Proposal: system owner submits a versioned system record (purpose, data types, supplier, population). Evidence: versioned entry, date, and proposer.
2. Assessment: DPO opinion and, if needed, DPIA included in the dossier. Evidence: dated opinion and DPIA version.
3. Approval: authorized signer commits the organization. Evidence: signed approval, date, and approved document version.
4. Execution and verification: implementers produce logs and tests; a different verifier confirms remediation. Evidence: test reports signed by a reviewer who did not perform the activity.

Segregation matters: one person who proposes, approves and verifies creates fragile evidence — auditors expect independent checks. Software can store versions and signatures, but it doesn’t assume responsibility or decide for people.

If you want guidance on governance between DPOs and process owners, see AuditReady’s practical post on establishing privacy governance (/en/blog/how-to-structure-privacy-governance-between-dpo-and-process-owner).

Legal bases, minimization and when a DPIA is required

Publicly available data does not automatically provide a lawful basis for reuse (for example, training a model). You still need an Article 6 GDPR basis (contract, legal obligation, public interest, legitimate interests, or consent). For special categories of data, an Article 9 condition is also required.

Legitimate interest can be used but only if a documented balancing test is retained — a checkbox won’t do. For large-scale scraping or profiling that affects individuals, a DPIA should be prepared before processing starts.

Scraping and third-party models

• Document list of sources, exclusion filters, and quality checks.
• Contractually verify model provenance, further training policy, deletion/opposition procedures, and supplier responsibilities.
• Keep experimental and production uses separated with distinct legal bases and retention schedules.

When the DPIA must precede go-live

• A DPIA is required before starting processing when risk to individuals is high: large-scale data collection, profiling, sensitive data, personnel evaluation, or novel technologies used in new contexts.
• A DPIA produced after launch cannot retroactively justify a decision unless it was written and dated beforehand. Minimum fields for each system record to survive audit:
  • ID, system name, scope, and nominated owner
  • Purpose and legal basis, categories of data subjects, supplier and contractual role
  • Retention periods, compensating controls, and narrative description of residual risk
  • Review date and evidence of closing the prior review

A DPIA documents impact on rights before processing exists — it is not a post-facto checklist.

When GDPR and the EU AI Act both apply

GDPR governs personal data; the EU AI Act adds system-level obligations depending on risk class. One does not replace the other. Mixing their assessments into a single undifferentiated document will fail both privacy and AI reviewers.

Practical alignment steps:

• Classify the usage (prohibited, high-risk, transparency-required, minimal risk) and record that classification next to the treatment record with a date.
• Maintain two linked dossiers for high-risk systems: technical compliance under the AI Act on one side, DPIA and legal basis under GDPR on the other. Link them with a common ID.
• Don’t substitute the DPIA with the AI Act conformity assessment or vice versa — they serve different purposes.
• Keep distinct owners: the controller approves processing; the deployer/provider documents AI Act-related roles and technical controls.
• Key linking fields: system ID, risk class, deployer/provider role, model version, linked DPIA, human oversight controls, logs and review dates.

A chatbot used for customer service and a scheduling algorithm used in HR will usually fall into different classes and require different proof packages.

For operational guidance on implementing the EU AI Act within your governance, see AuditReady’s AI Act features page (/en/features/ai-act).

Transparency and continuous monitoring after approval

Approval captures the system at a single point in time. The next day, suppliers might release a model update, data sources may change, or a team could start passing excluded content into prompts. The approved policy does nothing until someone re-examines the system.

Transparency requirements under Articles 13 and 14 of the GDPR still apply: provide appropriate notices and, where decisions significantly affect people, explain the logic and the possibility of human intervention. Operationally, record model versions, datasets/sources, key parameters, authorized users, contested outputs and remediation actions. Individual rights requests (access, rectification, objection) connect to your ticketing and response evidence, not a generic “handled” folder.

Monitoring events you should record (examples):

• Model version change: trigger review and update DPIA; evidence = signed changelog and DPIA re-evaluation.
• Supplier update notice: owner evaluates impact; evidence = evaluation note and contract update if needed.
• Source or input changes: periodic dataset extracts with date/version.
• Accuracy and bias testing: scheduled tests with thresholds, signed reports.
• Data subject requests: ticket with receipt date, response date, and attachments.
• AI incident: immediate incident log and decision on notification; evidence = incident log and notification rationale.

Monitoring frequencies are internal policy choices, not legal deadlines. Incident handling must be immediate and not delayed until a scheduled review.

Continuous control monitoring tools help automate evidence collection — see AuditReady’s post on continuous controls monitoring (/en/blog/continuous-controls-monitoring).

Common mistakes that weaken audits

Most audit failures trace to either missing evidence or evidence without dates and verifiers. Typical problems and fixes:

• Retroactive approvals: signing after go-live makes the control absent for the audited period. Fix: require approval before launch.
• Rolling exceptions without end: a 30‑day derogation renewed indefinitely becomes de facto non-conformity. Fix: limit renewals and convert repeated exceptions into findings after defined thresholds.
• Scattered evidence: emails, chats and personal folders do not reconstruct a verified sequence. Fix: centralize timestamped artifacts in one archive.
• Unverified closures: an owner marks a finding “done” but no independent verifier confirms it. Fix: require closure evidence signed by someone who didn’t implement the fix.
• Unregistered usage: tools used but missing from the inventory. Fix: periodic access scans versus register reconciliation.
• Late DPIAs: drafting a DPIA after launch or omitting vulnerable populations weakens the dossier. Fix: date the DPIA before go-live and re-evaluate on model or population changes.

Consequences can be material: regulators have fined organizations where transparency, accuracy, or contestability of automated HR systems were deficient. For HR systems, the register should include system name, purpose, affected population, data categories, provider role, potential consequences, discrimination testing, human oversight and contestation procedures.

Practical FAQs for operational edge cases

Q: A prompt contains special-category data. What is recorded? A: Block any outgoing submission. Create a ticket capturing the data category, whether an Article 9 condition exists, the decision to delete or pseudonymize, the owner and the date. Without that entry the prompt is untracked processing.

Q: A supplier processes data in a third country. What evidence suffices? A: Don’t rely on marketing copy. Capture transfer tools (SCCs or equivalent), who accesses the data, where data are stored, and retention. This should be contractually and operationally demonstrable.

Q: An output assigns a shift or excludes a person. Is that automated decision-making? A: Distinguish a documented recommendation with human verification (and recorded verification) from an automated decision that directly produces effects. In either case preserve the logic, contestation pathway, and outcome logs.

Q: The system can be used by minors. What must happen before launch? A: Prepare a DPIA that covers the population and pre-training data, and implement exclusion measures. An information notice alone is insufficient.

Q: An incident occurs between two quarterly reviews. Do you wait for the scheduled monitoring? A: No. Incident evaluation and any required notifications must start immediately. The periodic review documents the subsequent follow-up but does not replace incident response.

In every case keep system ID, owner, deadlines and closure evidence.

Pre-audit checklist: verify these things before the auditor arrives

Run these six checks in order; skipping one makes the next less useful:

1. Inventory: every AI system touching personal data has an owner and scope. Active access without a record is a hole, not an exception.
2. Approvals: signatures, dates and approved versions predate use. No backdating.
3. DPIA: where required, it predates processing and is updated for model or population changes.
4. Distinct registers: exceptions, non-conformities and incidents have separate logs with motivation and expiry.
5. Single evidence archive: artifacts have timestamps and versions; they’re not scattered across email.
6. Verified closures: every closed finding has verification by someone who did not implement the fix.

Assemble inventory, legal bases, DPIAs, monitoring logs and closure evidence into one audit pack and have an internal reviewer validate it before an external audit.

AuditReady can centralize these evidences with traceability for critical operations, supplier requests via expiring links, findings with severity and owners, remediation tracking, and an exportable Audit Day Pack. AuditReady does not provide legal opinions, certify compliance, or assume governance responsibilities — it organizes and preserves evidence so your people can demonstrate control.

If the only proof for the chatbot is an undated policy, the practical next step is to put owner, date and matching operational evidence into the same dossier. AuditReady can help bring registers, AI system records, findings and remediation into a single environment so reviewers don’t rebuild the story from scattered emails. Learn more about the platform on AuditReady (https://audit-ready.eu/?lang=en).