Yapay zekâ sistemlerinde hasta verisini korumak

Bu yazı şu anda yalnızca İngilizce olarak mevcuttur. İncelenmiş Türkçe çevirisi daha sonra eklenecektir.

Every health AI vendor says it takes privacy seriously. The statement tells you little. What tells you more is the architecture: where data travels, who and what can reach it, how long it is kept, and what happens when something goes wrong.

Data-protection law points the same way. The EU’s General Data Protection Regulation treats data concerning health as a special category under Article 9, with processing prohibited unless a specific condition applies. Article 25 requires data protection by design and by default. Türkiye’s Law No. 6698 (KVKK) likewise treats health data as a special category of personal data with stricter processing conditions. In other words, the law expects privacy to show up in how systems are built, not only in how they are described.

This article sets out the design choices we think matter most. It is not legal advice. The right configuration depends on jurisdiction, institution, and use, and should be settled with the institution’s data-protection officer.

1. Decide where computation happens

The simplest way to limit exposure is to not move data. For many clinical and operational workflows, the processing can run inside the institution’s own infrastructure, on premises or in a private cloud tenancy the institution controls. AId Centric designs for this kind of local or controlled deployment by default.

When an external service is genuinely needed, for example a hosted speech model, it should be a deliberate, documented exception. That means knowing what is sent, under which agreement, to which region, and whether it is kept or used for training.

2. Carry identity all the way through

Access control often stops at the application’s front door. Behind it, a service account with broad rights does the work. That breaks the link between who asked and what was retrieved.

A better pattern is to pass the user’s identity and role through every layer, so that a query run for a ward nurse can only return what that nurse is allowed to see. In our Operus product this is how permission-aware SQL works: row- and scope-level rules are enforced before a query runs, not filtered afterwards. The same principle applies to clinical data in Med-AId.

3. Minimise by default

The GDPR’s data-minimisation principle (Article 5) is easier to follow when the software makes the minimal path the easy path:

• Analyse the fields a question needs, not the whole record.
• Prefer de-identified or pseudonymised datasets for research and model development. In the US, HHS guidance describes two recognised approaches, Safe Harbor and Expert Determination; other jurisdictions have their own tests.
• For ambient documentation, treat audio retention as a setting the institution chooses, including no retention once the note is signed.

4. Keep logs that answer real questions

Audit logs are often too thin to be useful or too noisy to read. A useful log answers the questions an investigator or data-protection officer will actually ask: who accessed which records, for what workflow, when, and what was produced. In Med-AId, workflows, queries, and models are recorded so that results can be traced to their computation. The same trail supports privacy review.

5. Treat language models as a new data path

Generative models add risks that traditional systems don’t have:

• Prompt content is data. Anything placed in a prompt, including retrieved records, has been processed. It needs the same controls as any other use.
• Outputs can leak inputs. A summary can reveal more than the person reading it is allowed to see if retrieval ignores permissions. Enforce permissions at retrieval time, before content reaches the model.
• Tools and agents widen the blast radius. A model that can call tools or reach the network can do more damage if it is misused or misbehaves. Give it the least privilege the task needs and no standing credentials.

6. Tell patients plainly

Privacy is also about respect. Patients should be told in plain language when AI is involved in their care (for example, when a consultation is being captured for documentation) and what that means for their data. WHO’s guidance on AI for health puts protecting autonomy, including privacy and informed consent, first among its principles.

Questions to ask any vendor, including us

• Where does processing happen, and can it run entirely inside our environment?
• Which data leaves our boundary, if any, and under which agreement?
• How is user identity enforced at the data layer?
• What is logged, for how long, and who can read the logs?
• How are prompts, retrieved content, and model outputs protected?
• Is any of our data used to train models? Can we opt out?
• What happens to data when the contract ends?

Good answers are specific. If the answer to any of these is “we take privacy seriously”, ask again.

Kaynaklar

1. Regulation (EU) 2016/679 (General Data Protection Regulation), in particular Articles 5, 9 and 25. Official Journal of the European Union, L 119, 4 May 2016. eur-lex.europa.eu/eli/reg/2016/679/oj
2. Law No. 6698 on the Protection of Personal Data (KVKK), Republic of Türkiye. English translation published by the Personal Data Protection Authority. www.kvkk.gov.tr/Icerik/6649/Personal-Data-Protection-Law
3. U.S. Department of Health and Human Services. Guidance Regarding Methods for De-identification of Protected Health Information in Accordance with the HIPAA Privacy Rule. www.hhs.gov/hipaa/for-professionals/special-topics/de-identification/index.html
4. World Health Organization. Ethics and governance of artificial intelligence for health: WHO guidance. Geneva: WHO; 2021. www.who.int/publications/i/item/9789240029200