Sweden opens supervision against Region Gävleborg over AI transcription in care

What happened

The Swedish Data Protection Authority (Integritetsskyddsmyndigheten, IMY) announced on 7 January 2025 that it has opened a supervision case against Region Gävleborg regarding AI-based transcription in primary care ^[1]. The region had notified IMY itself, following established practice when a care provider identifies a potential data protection issue.

IMY's statement says the investigation will examine whether the processing of personal data in connection with the AI transcription complies with the requirements of the General Data Protection Regulation (GDPR). The authority has not yet published its findings.

Why it matters beyond data protection

This case sits at the crossing of two sets of rules. The first is data protection: patient records contain sensitive personal data, and any processing of them must have a legal basis, be necessary and be protected against unauthorised alteration ^[5].

The second is the AI Act. Healthcare AI that interprets diagnostic images, patient data or physiological data, or that helps triage patients, counts as high-risk under Annex I of the regulation ^[2]. Think of it like this: if a care home were to start using a machine to dispense medicines, everyone would expect it to meet stricter safety rules than a machine that prints appointment reminders. The AI Act applies the same logic to software.

For high-risk AI in healthcare, the obligations apply from 2 August 2028 ^[2]. That gives providers, regions and software suppliers two and a half years to get their systems in order.

What high-risk AI in healthcare has to do

A system that falls under Annex I must meet several requirements before it is placed on the market ^[3]:

• Risk management: Identify and mitigate reasonably foreseeable risks, including risks to health, safety and fundamental rights.
• Data governance: Use data sets that are relevant, representative and free of errors to the extent required by the intended purpose.
• Technical documentation: Keep records of how the system works, how it was developed and tested, and how it is monitored after release.
• Automatic logging: Article 12 requires the system to technically allow for the automatic recording of events over its lifetime, for traceability and so the user can monitor its operation ^[6].
• Human oversight: The design must allow a person to understand the system's output, intervene, override a decision or switch the system off.
• Accuracy, robustness and cybersecurity: The system must perform to its specified level and be protected against tampering and unauthorised access.
• Conformity assessment: The provider must have the system assessed by a notified body before it can be placed on the market.

The user of a high-risk system, in this case the region, also has obligations ^[4]. Under Article 26, the user must follow the instructions, ensure human oversight, monitor the system's operation and inform staff and patients before a high-risk AI is used. For healthcare systems that help make decisions about people, Article 27 adds a requirement for a fundamental rights impact assessment before the system is taken into use.

The logging question

Article 12 asks for automatic logging of events ^[6]. It does not say the logs must be tamper-proof, but it does say they are there so the provider can monitor the system after it has been released and so the user can keep an eye on its operation.

Here is where the practical question arises. Say a patient questions a decision, or an incident occurs, and someone asks to see the log. A log that can be quietly edited by the people who run the system is easier to challenge than one that can be shown to be unchanged. The law asks for the logs. Whether they hold up as evidence when they are needed is a separate question, and one worth thinking about early.

What a digital witness does here

The thing to seal in a care setting is not the patient record itself, which stays in the region's journal system, but a fingerprint of log entries as they are written. A fingerprint is a short string of characters calculated from the content. Change a single character and the fingerprint changes completely. You cannot rebuild the log from the fingerprint, any more than you can rebuild a person from a thumbprint, but you can tell whether two things are identical.

When each log entry is written, the system calculates its fingerprint and sends it to WitniumChain, which seals it on a chain where any later change would show, even one made by us. The log itself never leaves the region's systems. To check, an auditor, a supervisor or the patient's representative calculates the fingerprint again and compares it with the sealed one. If they match, nothing has changed since the entry was written. If they don't, something has.

That is what a digital witness does: it makes a log checkable without anyone having to trust whoever keeps it. It doesn't replace access control, monitoring or the journal system itself, and it doesn't show that a decision was right, fair or lawful, or that the log is complete. It shows that the entries written at the time are the ones being looked at now.

You can seal fingerprints of log records through the REST API, the SDK or the MCP server, at the moment each entry is written or in batches every few minutes. The content stays with you. Implementation typically takes a few hours for an integration that runs in the background. The first 2,000 seals a month are free. Read the documentation here.

How it would work

1. The journal system writes a log entry.
2. It calculates a fingerprint of the entry and sends it to WitniumChain.
3. To check, anyone you share the log with calculates the fingerprint again and compares it with the sealed one.

What this means for you

If you are a care provider using AI that helps interpret data or triage patients, or if you supply such systems, here are four questions to ask now:

• Does the system fall under Annex I of the AI Act, and do we know when the obligations apply?
• Are we logging what Article 12 asks for, and could we show an auditor or a supervisor that the logs have not been changed?
• Have we informed staff and patients that a high-risk AI is being used, and have we done a fundamental rights impact assessment where required?
• If something were questioned a year from now, what would our evidence be?

The AI Act's healthcare requirements come into force in August 2028. That sounds distant, but conformity assessment and implementation take time, and regions and suppliers will want to start early.

What to watch

• 2 August 2026: Transparency obligations under Article 50 apply, meaning people must as a rule be told when they are interacting with an AI system ^[7].
• 2 August 2027: Obligations for general-purpose AI models apply ^[7].
• 2 August 2028: High-risk requirements for healthcare AI under Annex I come into force ^[2].
• 2 December 2027: High-risk requirements for AI under Annex III (biometrics, employment, creditworthiness of natural persons and others) apply ^[8].

IMY has not said when it expects to conclude the Gävleborg case. The outcome will be worth following, because it will be one of the first times a Swedish authority examines how AI in care fits within both data protection and the AI Act's framework.