Governance: Ethics, GDPR, HIPAA and the AI Act

Why executives get this backwards

The instinct in most organisations is to treat AI governance as a gate at the end: build the thing, then send it to legal.

That sequence guarantees the worst outcome. By the time a system exists, its data flows, its retention behaviour and its decision boundaries are already fixed in code — and the cheapest fixes are no longer available. Governance applied at the end can only say no.

There is a better framing, and it is the organising idea of this module. Compliance obligations for an AI system are not one thing. They are three separate obligations that attach at three different points, and they are frequently confused:

Almost every governance failure traces to answering one of these three and assuming the other two came with it. A team gets a lawful basis for the data and forgets that the decision needs contestability. Or it builds a beautiful human-review process and never discloses that the draft was machine-generated.

Hold the three apart. The rest of this module works through each.

6.1 GDPR: the data obligation, and one decision trap

Lawful basis is not a formality

Under the GDPR, every act of processing needs a lawful basis (Art. 6). For AI projects the realistic candidates are contract necessity, legitimate interests, and consent — and the choice has consequences you will live with.

Legitimate interests is the workhorse, but it requires a documented balancing test and it grants the individual a right to object. Consent is often the wrong instrument for workplace or operational systems: it must be freely given, and it can be withdrawn, which means building a system whose lawful basis can evaporate on a Tuesday.

Health data needs a second key

This is where diagnostics, insurers, employers and anyone touching wellbeing data get caught. Health data is a special category under Art. 9. Special-category processing is prohibited by default and requires both an Art. 6 basis and a separate Art. 9 condition — explicit consent, healthcare provision, public health, or a member-state law among them.

Two keys, not one. A great many "AI wellbeing" and "AI triage" proposals fail at this step, and they fail before any model is chosen.

Purpose limitation is the quiet killer of AI projects

Data collected to deliver a service may not be freely repurposed to train a model on. Purpose limitation (Art. 5(1)(b)) and the fairness and transparency principles mean the question is not "do we hold this data?" but "did we tell people we would use it for this?"

The practical consequence for a roadmap: the training-data conversation belongs at the start of the project, not at the end. Retrofitting a lawful basis onto a corpus that has already been assembled is one of the most expensive mistakes available.

Data minimisation as an engineering instruction

Art. 5(1)(c) requires that data be adequate, relevant and limited to what is necessary. Read as an engineering instruction it means: strip identifiers before the model sees the text, wherever the task does not need them.

Most language tasks do not need to know who the person is. Detecting that a customer is describing a sizing problem does not require their name, address or account number. Masking personal data before inference is not merely a control — it materially reduces the scope of everything else in this module.

Article 22, and why a rubber stamp will not save you

Art. 22 gives individuals the right not to be subject to a decision based solely on automated processing that produces legal effects or similarly significantly affects them. Where such decision-making is permitted, safeguards must include the ability to obtain human intervention, express a point of view and contest the decision.

Executives routinely assume the fix is to place a person in the loop. The Court of Justice narrowed that escape route considerably in SCHUFA (C-634/21, December 2023), holding that a credit-scoring agency's automated score was itself automated decision-making where the score substantially determined whether a lender would contract with the individual.

The lesson generalises well beyond credit:

If the human in the loop cannot realistically change the outcome, you do not have human oversight. You have a rubber stamp — and the automated-decision rules still apply.

This connects directly to workflow design. An approval gate is only a real control when the approver has the information, the time and the authority to decide differently. Module 5 designs gates that meet that standard; here, note the legal consequence of gates that do not.

DPIAs, transfers and erasure

• DPIA (Art. 35). A data protection impact assessment is required where processing is likely to result in high risk — which covers systematic evaluation based on automated processing, large-scale special-category processing, and systematic monitoring. Most substantive AI deployments in regulated sectors will need one. Do it early; it is a design tool, not paperwork.
• International transfers. Where the model runs matters. Sending personal data to an API endpoint in another jurisdiction is a transfer and needs a transfer mechanism. This is the single most common reason serious organisations choose to run smaller models on their own infrastructure.
• Erasure. The right to erasure is straightforward for a database row and genuinely hard for a trained model. The defensible architecture keeps personal data in systems you can delete from, and keeps it out of training corpora unless you have both a basis and a plan.

6.2 HIPAA: who you are determines what you owe

HIPAA confuses non-US executives because it is narrower than they expect and stricter than they expect at the same time.

It is narrower because it does not regulate health information generally. It regulates protected health information (PHI) held by covered entities — health plans, healthcare clearinghouses, and healthcare providers who transmit health information electronically in connection with certain transactions — and by their business associates.

It is stricter because once you are in scope, the obligations flow down contractually to everyone you hand data to.

The three questions that decide your position

1. Are you a covered entity, a business associate, or neither? A software vendor processing PHI on behalf of a hospital is a business associate and is directly liable for much of the rule set. A wellness app selling to consumers may be neither — and then finds itself governed by other consumer-protection law instead.
2. Do you have a Business Associate Agreement with every vendor touching PHI? This includes model providers. If a language model API will see PHI, that provider is a business associate and a BAA is required. "We use the enterprise tier" is not the same statement as "we have a BAA."
3. Is the data actually PHI, or can it be de-identified first? This is the highest-leverage question in the module.

De-identification is the strategic move

HIPAA offers two routes to de-identified data, which is then outside the rule:

• Safe Harbor — removal of eighteen specified identifier types (names, geographic subdivisions smaller than a state, all date elements more specific than year, contact details, record and device numbers, biometric identifiers, full-face images, and any other unique identifying number or code), with no actual knowledge that the remainder could identify the individual.
• Expert Determination — a qualified statistician documents that the re-identification risk is very small.

For most AI work on clinical free text, Safe Harbor style redaction before inference converts a hard problem into a manageable one. This is the same instruction the GDPR gives through minimisation, arrived at from a completely different legal tradition — which is exactly why it belongs in your control set rather than in a jurisdiction-specific checklist.

Minimum necessary, and the Security Rule's current state

The minimum necessary standard requires limiting PHI use and disclosure to what is needed for the purpose. Applied to AI, that is an argument against sending whole records to a model when a field would do.

On the Security Rule: the administrative, physical and technical safeguards in force today remain those of the 2013 rule. A significant modernisation was proposed — the notice of proposed rulemaking published on 6 January 2025, with comments closing 7 March 2025, would remove the "addressable" category, mandate multi-factor authentication, require asset inventories and network maps, and strengthen business-associate oversight. As of August 2026 no final rule has been issued, and the projected date for final action has moved to 2027.

The planning consequence is worth stating plainly to a board: the direction of travel is known even though the deadline is not. Organisations building the proposed controls now are buying optionality cheaply; organisations waiting for certainty will implement under time pressure.

6.3 The EU AI Act: find your tier, then find your date

The AI Act regulates by risk tier, and by your role — provider, deployer, importer or distributor. Most enterprises are deployers of someone else's system, which carries a lighter but real set of obligations.

The tiers

The timeline actually in force

This is where most 2026 course material is wrong, because it moved recently.

The original schedule put standalone high-risk obligations at 2 August 2026. A political agreement on the digital omnibus in May 2026, which entered into force in late July 2026, deferred them:

Two management conclusions follow:

1. The transparency obligation is live today. If customers talk to something machine-generated, or you publish synthetic content, that is a present obligation, not a future one — and it is cheap to comply with if designed in, awkward if retrofitted.
2. The high-risk deferral is time to build, not time to wait. Conformity assessment, technical documentation and logging are not things you assemble in a quarter. An organisation treating December 2027 as distant is making the same mistake organisations made with GDPR in 2016.

6.4 Frameworks that make this operational

Two voluntary frameworks turn the obligations above into something you can run and audit.

• NIST AI Risk Management Framework — a voluntary US framework organised around four functions: Govern, Map, Measure, Manage. Its value to an executive is structural: Govern is the standing organisational capability, while Map/Measure/Manage repeat per system. If you need a way to explain why you need both an AI policy and a per-system process, this is it.
• ISO/IEC 42001 — a certifiable management-system standard for AI, structured like ISO 27001. Its value is commercial as much as ethical: it produces an artefact an enterprise customer's procurement team recognises, which shortens sales cycles.

Neither is law. Both are increasingly what enterprise buyers and insurers ask for, which makes them a competitive question as well as a compliance one.

6.5 The control set that satisfies most of it at once

The efficient move is to notice how much overlap exists between regimes and implement against the overlap. Eight controls carry most of the load:

1. Data residency and processing location — know and pin where inference happens. Satisfies GDPR transfers, supports HIPAA, simplifies sector rules.
2. Identifier masking before inference — strip personal and health identifiers on the way in. Satisfies GDPR minimisation and the spirit of HIPAA minimum necessary; often converts PHI into de-identified data entirely.
3. Purpose binding — each system records what it may use data for, and training use is a separate, explicit decision. Satisfies purpose limitation.
4. Approval gates with real authority — a named human who can see the input, change the output, and whose decision is recorded. Satisfies Art. 22 safeguards and AI Act human-oversight expectations.
5. Traces — an immutable record of what was sent, what came back, which version of the system produced it, who approved it. Satisfies AI Act logging, evidences DPIA claims, and is the only way to answer "why did it do that?" months later.
6. Retention and deletion — defined lifetimes for inputs, outputs and traces, and a deletion path that actually works. Satisfies erasure and minimisation.
7. Disclosure at the interface — tell people when they are interacting with, or reading output from, an AI system. Satisfies AI Act Art. 50, live now.
8. A system inventory — one list of every AI system, its tier, its owner, its data, its jurisdiction. Everything above is unenforceable without it, and no regulator conversation survives its absence.

6.6 Shadow AI: the exposure you have not inventoried

Every organisation in this course already has AI in production. Not all of it is sanctioned.

Staff paste customer emails, contracts, patient narratives and source code into consumer chat tools because those tools are useful and the sanctioned path is slower. Each paste is potentially a transfer, a purpose-limitation breach, a PHI disclosure without a BAA, or a trade-secret disclosure.

Prohibition alone does not work; it converts visible usage into invisible usage. The pattern that does work has three parts:

1. Measure it before you legislate. Network and expense data will tell you what is actually in use.
2. Provide a sanctioned path that is genuinely faster than the unsanctioned one. Convenience is the control.
3. Make the rule specific to data class, not to tools. "Never paste customer identifiers or patient data into any external tool" survives the arrival of the next product; a list of banned domains does not.

Exercise — Build a control map for one workflow

Time: 60–75 minutes. Produces the artefact for this module.

Choose one real workflow from the labelled portfolio you built in Module 3 — ideally one that touches personal data.

Step 1 — Separate the three obligations. For this workflow, write one paragraph each on the data obligation, the decision obligation and the disclosure obligation. If any is "none," say why.

Step 2 — Complete the control map. For each of the eight controls, record the current state, the target state, and a named owner. Not a team — a person.

Step 3 — The override test. Find the human in your workflow who is supposed to provide oversight. Ask three questions: Do they see the inputs the system used? Do they have time to review at the real volume? Has anyone ever overridden it? If any answer is no, you have a rubber stamp, and both your legal exposure and your quality assurance are weaker than your documentation claims.

Step 4 — Name the tier. State which AI Act tier this system occupies, which role you play, and the date that applies. Write the sentence you would say to a regulator.

Self-check

1. A colleague says, "We have consent, so we can train on this data." Which two principles might still block it?
2. Your vendor says its enterprise plan is "HIPAA compliant." What single document do you ask for, and what do you check inside it?
3. Under what circumstances does putting a human in the loop fail to remove a system from Art. 22 scope?
4. Your recruitment team wants to use the internal document-summarisation tool to rank job applicants. Which tier did the system just move into, and what changed?
5. Which of the eight controls would you implement first in your organisation, and what is your argument for the sequence?

Further reading

• Regulation (EU) 2016/679 (GDPR), Arts. 5, 6, 9, 22, 35 — and the EDPB guidance on automated decision-making.
• CJEU, SCHUFA Holding, C-634/21, 7 December 2023 — on when a score is itself an automated decision.
• Regulation (EU) 2024/1689 (AI Act), Annexes I and III, Arts. 6, 26, 50 — read alongside the 2026 omnibus amendments to the application dates.
• 45 CFR Parts 160 and 164 (HIPAA Privacy and Security Rules); HHS guidance on de-identification methods.
• HHS Office for Civil Rights, HIPAA Security Rule NPRM, 6 January 2025 — the proposed modernisation, still pending as of August 2026.
• NIST, AI Risk Management Framework 1.0, 2023.
• ISO/IEC 42001:2023, AI management systems.