16. Governance, privacy and security

Governance answers who may do what with which data, for what purpose, and for how long. It weighs more in AI than in reporting, because models can memorize and reproduce their training data, and because data cannot cheaply be removed from a model once trained. This section is an engineering orientation, not legal advice; involve a data protection officer or lawyer for real decisions.

Classify data first

Every control depends on knowing what a dataset contains. A common scheme is public, internal, confidential and restricted. Tag columns and documents that hold personal data, and especially GDPR special categories (such as health, religion, ethnicity or political opinions), which carry stricter rules.

GDPR principles as engineering requirements

The GDPR’s core principles (Article 5) translate directly into pipeline design:

Principle	Engineering consequence
Lawfulness, fairness, transparency	Record the legal basis for each dataset; tell people how their data is used
Purpose limitation	Data collected for billing is not automatically usable for model training
Data minimisation	Drop unneeded columns at ingestion; do not log full prompts “just in case”
Accuracy	Support corrections that propagate downstream
Storage limitation	Retention periods enforced by automatic deletion, not by good intentions
Integrity and confidentiality	Encryption, access control, audit logs
Accountability	Be able to show what you did: lineage, documentation, records of processing

Also know the rights people hold: access, rectification, erasure (Article 17), objection and portability, plus limits on purely automated decisions with significant effects (Article 22). High-risk processing calls for a data protection impact assessment. Sending personal data to an external model API, especially outside the EU, requires a processing agreement and a valid transfer mechanism.

Privacy techniques

• Pseudonymization replaces identifiers with tokens or keyed hashes. It reduces risk, but the GDPR still treats pseudonymized data as personal data.
• Anonymization must be irreversible, which is much harder than it sounds: combinations of ordinary fields like postcode, birth date and gender can re-identify people. Techniques include aggregation, k-anonymity and differential privacy.
• PII detection and redaction: pattern rules plus named-entity models, for example Microsoft Presidio. Apply them to RAG corpora, fine-tuning data and especially LLM application logs.
• Retention: time-to-live settings and scheduled deletion jobs on every table that holds personal data.

The right to erasure, in practice

Deleting one person’s data means finding every copy. That requires lineage (section 11) and touches every layer:

1. Bronze, silver and gold tables: delete rows, then expire old snapshots so the files actually disappear.
2. Backups: follow their retention cycle, documented.
3. Vector indexes and search indexes: delete the person’s chunks.
4. Logs and traces: delete or redact.
5. Fine-tuning and evaluation sets: remove the records.
6. Already-trained models: removing specific data from a model (machine unlearning) is still immature. The practical approach is to exclude the data from all future training, document it, and retrain on a schedule.

Access control

• Least privilege: every person and service gets the minimum access needed.
• Role-based (RBAC) or attribute-based (ABAC) policies, applied centrally in a catalog such as Unity Catalog or AWS Lake Formation.
• Row-level and column-level security, and dynamic masking, so analysts see aggregates without raw identifiers.
• Audit logs of who read what, kept long enough to investigate incidents.

Security for data and AI systems

• Encrypt in transit (TLS) and at rest, with keys in a key management service.
• Keep secrets in a secrets manager; never in notebooks, code or environment files in Git.
• Isolate networks with private endpoints for databases and storage.
• Data poisoning: anyone who can influence your training data, for example by publishing web pages you crawl, can influence your model. Provenance and filtering are security controls.
• Indirect prompt injection: documents ingested into a RAG index can contain instructions aimed at the model. Treat retrieved content as untrusted input, and limit what tools an LLM may call based on it.

Licensing and copyright of training data

• Record the license of every source and document: permissive, attribution-required, non-commercial, or proprietary.
• Respect opt-outs. Under the EU copyright rules on text and data mining, rights holders can reserve their works from commercial mining in machine-readable form, for example through robots.txt or metadata.
• Check the terms of use of models that generate synthetic data, since some restrict using outputs to train competing models.

The EU AI Act, from the data angle

The AI Act is risk-based. For high-risk systems, its data governance article (Article 10) requires training, validation and test data to be relevant, sufficiently representative, as free of errors and as complete as possible, and examined for possible biases. Providers of general-purpose AI models must, among other duties, keep technical documentation, put a copyright policy in place, and publish a summary of the content used for training.

Obligations apply in phases, and some timelines have been revisited since adoption, so check the current status before relying on a date. Either way, the engineering answer is the same: provenance, documentation and quality checks are now compliance evidence, not nice-to-haves.

Documentation that pays off

Datasheets or data cards for datasets, model cards for models, and a record of processing activities. Written while building, they cost little; reconstructed during an audit, they cost a great deal.

Questions to ask

• What is the legal basis and purpose for using this data to train or ground a model?
• If one person asks for deletion, can we find and remove every copy, including indexes and logs?
• Who can read the raw data, and is that access logged?
• Do our LLM logs contain personal data, and how long do we keep them?
• What is the license and opt-out status of each training source?