Using AI without patient data leaving the institution

Why health data needs stricter protection

The European Union's General Data Protection Regulation (GDPR) lists health data among the special categories of personal data and allows it to be processed only under specific exceptions. In Türkiye, the Personal Data Protection Law (KVKK) likewise treats health data as special category personal data; processing it is subject to narrower conditions and additional security measures.

Both laws essentially ask the same thing: for what purpose, by whom, where and for how long the data is processed. The data controller, meaning the organization that determines the purposes and means of processing, is responsible for those answers. Even when another company processes data on the institution's behalf, the controller remains responsible for security measures.

In AI projects, risk usually comes from how the system is deployed. Sending patient text to a general-purpose AI service means the data leaves the institution and sometimes the country; where it is stored and who can access it may slip out of the institution's control. When no approved tool is provided, staff may paste patient notes into chat tools of their own choosing.

What KVKK and GDPR principles mean for an AI project

The general principles and core obligations of the two laws are close to each other, and in an AI project they turn into concrete design decisions:

• Purpose limitation requires data to be processed for a specified, explicit and legitimate purpose. Data read to assess a pre-authorization request should not be used to develop another of the provider's models.
• Data minimization, which KVKK phrases as being relevant, limited and proportionate to the purpose, means the model sees only the fields its task requires. A clinical assessment often does not need the patient's name, national ID number or contact details.
• Storage limitation means keeping data only for as long as necessary. Queries, model outputs and access logs that contain personal data fall within this scope too.
• Security covers the technical and organizational measures that prevent unauthorized access and unlawful processing; encryption, role-based access and access logs are examples.
• Accountability requires these decisions to be documented. The GDPR names it as an explicit principle, and KVKK also requires the controller to carry out, or have carried out, the necessary audits.

Transferring data abroad, or outside the European Economic Area in GDPR terms, is also subject to separate conditions. The country in which an AI service runs therefore matters.

Masking is an important tool for applying these principles, but it is not the same as anonymization. Reversible masking or pseudonymization reduces risk, yet the data remains personal data. That is why masking should happen inside the institution and the masked data should stay there as well.

Steps to deploy AI without data leaving the institution

These steps apply in the same way to a hospital, a health insurer or a laboratory, whether it operates under KVKK in Türkiye or under the GDPR in the EU:

1. Define the purpose in writing. Record in a single document which process the AI will support, which users will work with it and which data fields it will see.
2. Clarify the legal basis and the roles. Identify which processing condition the institution relies on, and state in the contract whether the provider accesses the data and, if so, in what role and for what purpose. The GDPR requires a written contract with any provider that processes data on the institution's behalf.
3. Choose a deployment that keeps the data in place. Install the model on the institution's own servers or in an isolated cloud environment dedicated to it; in the cloud, fix the processing region in the contract.
4. Minimize the data and mask it in-house. Remove direct identifiers such as name, national ID number and contact details from the text the model sees.
5. Restrict access by role. Give each user only the permissions their work requires, use multi-factor authentication and run the data layer without any externally exposed network endpoint.
6. Make sure the data is not used for other purposes. State in the contract that institutional data will not be used for model training or for other customers, and how long queries, outputs and logs will be kept.
7. Make every output auditable. Set up a structure that shows the document, source and reasoning behind each recommendation and records who made the decision and when.
8. Assess the risks and start with a narrowly scoped POC. The GDPR requires a data protection impact assessment (DPIA) where health data is processed on a large scale; in Türkiye, a similar written assessment is good practice. Test the data flow together with the IT and information security teams.

How architecture choices affect data protection

How the model is deployed also shapes the data protection outcome. Models that can run on the institution's own infrastructure, open-weight foundation models for example, remove the need to send patient data to the provider.

The second distinction is between training and use. A clinical model does not have to be trained on the institution's patient records to learn medical language; published medical literature and clinical guidelines can serve that purpose. Patient data is then read only at the moment of use, inside the institution.

The third is auditability. Retrieval methods that tie answers to source documents (RAG) make it possible to show which information comes from a document and which from the model's inference. Evaluating rules in a rule engine, with the AI only explaining the result, also makes each decision easier to trace.

What Opinion AI does in this process

MINA, Opinion AI's clinical AI, runs on the institution's own servers or in an isolated cloud environment dedicated to it; if the cloud is chosen, data is processed only in Türkiye or in the EU region. The data layer is reachable only from the institution's local network. Opinion AI does not collect personal data; the data stays inside the institution, the institution is the data controller, and personal data is masked in-house in line with KVKK.

MINA was built by adapting an open-weight foundation model to Turkish and to the clinical language of 14 specialties through continued pre-training (CPT). Specialty, institution and task expertise is added through LoRA adapters, and knowledge retrieval runs through agentic orchestration on a clinical knowledge graph (GraphRAG). Institutions' patient data is not used to train the model.

In hospitals, TIS works as an intelligent layer on top of the existing HBYS, the hospital information system, without replacing it; at insurers, SIT-I supports the assessment of pre-authorization, claims and reimbursement files. Each institution has its own deployment, and hospital data and insurer data are not merged.

Every answer shows separately what comes from the institution's documents and what is MINA's inference; rules are evaluated in the rule engine, and the AI only explains the result. People always make the decision, and every output can be audited later. The Physician Ethics and Advisory Board, with physicians from 15 specialties, regularly reviews the model's clinical accuracy and ethical limits. More detail is available on the Ethics & Compliance and FAQ pages.

Frequently asked questions

Does entering patient information into general-purpose AI chat tools comply with KVKK and the GDPR?

Entering identifiable patient information into an AI tool that the institution has not approved or contracted carries serious risk. The data leaves the institution, sometimes the country, and where it is stored and how it is used may fall outside the institution's control. Giving staff an approved tool that runs in the institution's own environment is the safer path.

Does masked or pseudonymized health data fall outside KVKK and the GDPR?

No. Masking and pseudonymization alone do not stop data from being personal data. Data counts as anonymous only if it cannot be linked to a person even when combined with other data, and the GDPR treats pseudonymized data that can be attributed to a person with additional information as personal data. Masked data should therefore also stay inside the institution.

Should healthcare AI run in the cloud or on premises?

Both are possible; what matters is where the data is processed, who can access it and how this is secured by contract. An on-premises deployment keeps control with the institution. If the cloud is chosen, the environment should be dedicated and isolated, the processing region should be fixed, and the conditions for cross-border transfers should be assessed.

Is the AI provider a data controller or a data processor?

The data controller is the party that determines the purposes and means of processing; in these projects that is usually the hospital or the insurer. The provider's role depends on whether it accesses the data and, if so, on whose behalf, and should be set out clearly in the contract. In Opinion AI deployments, the institution is the data controller and Opinion AI does not collect personal data.

Is a healthcare AI model trained on the hospital's patient data?

A clinical model does not need to be trained on the institution's patient data to be useful; it can be built with published literature and guidelines and read patient data only at the moment of use, inside the institution. If training on patient data is planned, that is a separate processing purpose and needs its own assessment. Institutions' patient data is not used to train MINA.

Can AI make a pre-authorization or treatment decision on its own?

In responsible use of AI in healthcare, a person makes the decision; the AI offers a recommendation, its reasoning and its source. KVKK gives individuals the right to object to an outcome against them that results solely from automated analysis, and the GDPR sets limits and safeguards for significant decisions based solely on automated processing. MINA does not make decisions; approvals, requests for missing documents, rejections and prescriptions are always decided by a specialist or physician.

To assess together which process your institution could start with, without patient data leaving it, use the POC Request form. For selection criteria, see the guide on choosing a clinical decision support system; to see how data comes together in a single patient profile, see the guide on the patient digital twin.