Personal data in cloud AI: how to work with GDPR and HIPAA in mind

Buying an enterprise plan does not remove legal risk when handling customers’ personal data. The plan defines what the provider promises. Your company must establish that its own process is lawful: whether there is a legal basis, who is the controller and processor, which agreements are signed, what safeguards are in place, and whether you send more data than the task requires.

GDPR and HIPAA govern different relationships. So the first step is to determine whether each law applies to your company and this specific process. Only then does it make sense to choose agreements, a service, and settings.

This article explains an approach; it is not an individual legal opinion. After reading it, you should be able to map the route personal data takes through your process, understand which documents may be needed, and prepare specific questions for your lawyer and provider. The laws and regulator positions are described based on research conducted on 11 October 2026.

When GDPR and HIPAA apply

GDPR. EU Regulation 2016/679 applies beyond the EU. Article 3 covers processing in the context of the activities of a controller’s or processor’s establishment in the EU, regardless of where the processing physically takes place. It also applies to companies without an EU establishment when processing relates to offering goods or services to people in the EU or monitoring their behavior there.

For a Ukrainian company, registration in Ukraine alone does not rule out GDPR. An online service deliberately serving customers in Poland or Romania may fall under the Regulation. Whether it applies to your process should be analyzed with a lawyer against Article 3’s criteria, rather than decided by a general rule.

Ukrainian personal-data law applies separately; GDPR does not replace it. We do not analyze it here. Conclusions about Ukrainian requirements need a separate review of primary legal materials, and combining the two regimes in one instruction would be unhelpful.

HIPAA. This is US law covering health information. US Department of Health and Human Services (HHS) cloud-computing guidance is addressed to covered entities (healthcare organizations defined by law) and their business associates (business partners) that handle electronic protected health information, or ePHI.

Therefore, do not assume HIPAA applies to every Ukrainian clinic. Using a US cloud service by itself does not determine whether the law applies. That depends on the organization’s status under US rules and should be confirmed with a lawyer. Health data remains sensitive even when HIPAA does not apply. If GDPR applies to the process, health data is a special category under Article 9.

Start the discussion with your lawyer with four questions:

1. Does the company have an establishment in the EU whose activities involve processing the data?
2. Does the company offer goods or services to people in the EU or monitor their behavior there?
3. Is the company a covered entity or business associate under US rules?
4. Which other legal regimes apply to the process, including Ukrainian law?

The answers determine which sections below are mandatory for you and which are useful as good practice.

Map the flow of data

A lawyer cannot assess a process that nobody has described. Before discussing agreements, record what physically happens to the data: where it comes from, where it goes, and where it remains. GDPR defines processing broadly: collection, storage, transfer, deletion, and other operations on data also count as processing.

This map shows more than the model provider. It can reveal your own logs, test copies of the database, attachments in tickets, and integrator services. These are also personal-data processing and require a basis and safeguards. Without a map, these areas are often missed because each team sees only its part of the process.

Map one specific use case at a time, not “AI in the company” in general. A support chatbot, call analysis, and reminder generation involve different data, recipients, and retention periods.

Documents and roles

Start by defining roles. Under GDPR Article 4, the controller determines the purposes and means of processing, while a processor handles data on the controller’s behalf. When a company uses an AI service to work with its customers, the company decides why and what data to process. In that arrangement, the provider processes data on the company’s instructions. But roles depend on who actually determines purposes and means, so record the allocation in writing for each participant, including the integrator.

Here are the key requirements for an AI process if GDPR applies:

• Legal basis, Article 6. Processing is lawful only if one of the listed bases applies, such as consent, performance of a contract, a legal obligation, or legitimate interests. A provider contract does not create that basis for you.
• Special categories, Article 9. These include health data. Processing is prohibited unless one of the exceptions defined in the article applies.
• Processor agreement, Article 28. A processor acts on the controller’s documented instructions. Engaging another processor requires prior specific or general written authorization. With general authorization, the controller must be notified of planned changes so it can object. A data processing agreement is often called a DPA (Data Processing Agreement).
• Security, Article 32. Controllers and processors implement technical and organizational measures appropriate to the risk. The article names pseudonymization and encryption as examples.
• Impact assessment, Article 35. If processing is likely to create a high risk to people’s rights, a data protection impact assessment (DPIA) must be completed before processing begins.
• International transfers, Article 44 onward. Transfers to third countries or international organizations are subject to Chapter V. In practice, consider the European Economic Area (EEA), which includes EU countries, Iceland, Liechtenstein, and Norway. Transfers outside the EEA require an appropriate safeguard mechanism.

HIPAA has a different key document. HHS guidance says that when a covered entity or business associate engages a cloud provider that creates, receives, maintains, or transmits ePHI on its behalf, it must enter into a BAA (Business Associate Agreement) with the provider. A provider is a business associate even if it stores only encrypted data and has no key to decrypt it. HHS also requires a risk analysis.

The key point: a processor agreement does not replace a legal basis, data minimization, your own safeguards, or an assessment of data transfers. It is one of several necessary elements.

Minimize before sending a prompt

GDPR Article 5 establishes data minimization: data must be adequate, relevant, and limited to what is necessary for the purpose. The practical rule for an AI process is simple: the best-protected data is data you never sent.

Before connecting AI, ask: what is the minimum data the model needs for this particular task? Common techniques include:

• remove fields that do not affect the result;
• replace names and contact details with an internal identifier;
• send only the relevant excerpt, not the entire document;
• aggregate data when an individual-level view is unnecessary;
• keep the “identifier → person” mapping in your own system and do not send it to the AI service.

Do not overstate the effect. Pseudonymization and anonymization are different. GDPR defines pseudonymization as processing that prevents attribution to a specific person without additional information stored separately. But Recital 26 explicitly says pseudonymized data remains information about an identifiable person. The Regulation applies only where information is truly anonymous. Replacing a name with an identifier reduces risk; it does not take processing outside GDPR.

The same logic applies to models. In Opinion 28/2024, the European Data Protection Board (EDPB) does not suggest automatically treating a model trained on personal data as anonymous. The assessment depends on how likely it is that personal data can be extracted from the model or obtained through queries. If a company plans to fine-tune a model on customer data, that is a separate decision requiring a separate assessment.

Training example: a patient appointment reminder

This example is fictional. It illustrates minimization and is not a conclusion about the lawfulness of a particular processing activity.

A clinic wants AI to write friendly appointment reminders. Consider two ways to construct the prompt.

Option A. Send the patient’s full medical record, including contact details, to the AI service so the “model has all the context.”

Option B. Send an internal patient identifier, appointment date and time, and the permitted contact-channel type. AI generates a text template. The clinic’s system inserts the name, phone number, or email and sends the message itself.

Option B substantially reduces the amount of data sent. But it does not automatically make processing lawful or anonymous. An identifier combined with the appointment time remains pseudonymized personal data. Even the fact that someone has an appointment at a medical facility may reveal health information, which a lawyer should assess.

If one template works for all patients, there is no need to send any patient-specific data to the model. AI can help prepare general wording, while the clinic system inserts the name, date, and time locally. Use a pseudonymized prompt only where individual details are truly needed.

The second table shows why one decision is not enough. It separates three levels often collapsed into the phrase “we have everything covered.”

Security and provider review

Once the data route and roles are clear, review the provider. This is not a single question—“is the service secure?”—but a set of specific questions whose answers should appear in the documentation or contract.

Access. Who at the provider and integrator can access data and in what circumstances? Who in your company can access API keys, settings, and logs? Keep keys in one controlled location, not in messages.

Regions. Where is data processed and stored? Is it transferred outside the EEA or to an international organization, and which Chapter V GDPR mechanism applies? Check geography for the whole data route, including subcontracted providers.

Retention and deletion. What periods apply to prompts, files, and technical logs? How is data deleted when the contract ends? Our article on enterprise AI plans discusses the difference between no training and no retention in detail.

Incidents. How and when does the provider notify you of an incident, who receives the notice in your company, and what happens next? Put these terms in the contract, not only in marketing material.

Subprocessors. Get the list of companies engaged by the provider, the type of written authorization, and the process for notice of changes. Article 28(2) allows specific or general prior written authorization. With general authorization, you must have a way to object to adding or replacing a processor.

Service-specific limits. Different features and models from one provider may have different terms. Connectors to third-party systems have their own terms too. Check the exact set of features used by your process.

A separate note on encryption: it is necessary, but it does not replace agreements. HHS says a cloud provider remains a business associate even without a key to encrypted data. Encryption reduces the impact of an incident; it does not change the legal status of the participants.

What to include in a launch decision

After the checks, record the decision in writing. It should not be a general authorization to “use AI,” but a record for a specific process. We recommend including these fields:

Record residual risks honestly. An employee may paste unnecessary data into a prompt. A provider may change terms or add a feature. An integrator may enable more detailed logging for debugging. No plan, agreement, or checklist eliminates these risks completely. The record makes them visible and assigns someone to monitor them.

What to do next:

1. Choose one process where personal data already enters AI or will enter it.
2. Map its data route from collection through deletion.
3. Discuss the four questions about GDPR, HIPAA, and other regimes with a lawyer.
4. Reduce the prompt fields to the minimum needed for the task.
5. Gather agreements (DPA and, where needed, BAA) and the provider’s answers about access, regions, retention, and incidents.
6. Record the launch decision, owner, residual risks, and review date.

It is normal to have open questions for the provider after this. It is better to know exactly what you do not know than to rely on a general claim about security.

Frequently asked questions