Self-hosted AI in healthcare: why patient data shouldn't go to someone else's API

Private AI for healthcare means the AI models that read patient data run inside infrastructure your software vendor controls, instead of sending that data to a third-party AI provider's API. For GCC clinics, this keeps data residency, access control and audit in one place. Helix runs its AI this way, as described on our security and privacy page.

What happens when software “adds AI”

Many healthcare applications add AI features by calling a general-purpose model through an API. The pattern is quick to build, and the models are powerful. But each call sends data somewhere:

1. Your clinic's software collects the text or audio: a transcript, a chart, a patient message.
2. It sends that content to the AI provider's servers, which may be in another country.
3. The provider processes it, and may log or retain it for a period under its own terms.
4. The answer comes back and is shown to your staff.

None of this is automatically unlawful. Many providers offer enterprise terms, regional hosting and no-training commitments. But every step adds a party that handles your patients' data, under a contract you did not sign directly. So the question for a clinic is simple: do you know who processes your patients' data, where, and under what terms?

Why it matters more in the GCC

Health data in the region carries specific expectations. In the UAE, the federal ICT in Health Fields law (Federal Law No. 2 of 2019) sets rules on storing and processing health data, including limits on moving it outside the country except where permitted. Saudi Arabia has its own personal data protection law and sector rules. Health authorities such as DHA and DoH also publish their own data and AI guidance. The details change and have exceptions, so take legal advice. The direction is clear, though: regulators expect you to know where health data goes.

AI makes this harder to see. A scribe recording, a chatbot conversation or a copilot question about “patients with overdue balances” can all carry identifiable data. If each feature calls a different outside provider, your data map quickly grows beyond what anyone in the clinic can track. Our article on UAE health data law for clinics covers the legal background in more depth.

There is also a trust question that no law fully covers. Patients tell doctors things they tell nobody else. When a clinic records a consultation, it asks for trust. Being able to say “this recording is processed by our own software provider, in the region, and never used to train anyone's AI” is a clear and honest answer to a patient who asks.

Questions to ask any vendor about its AI

Ask for the answers in writing, and check that they match the contract. We cover these questions in our AI scribe evaluation checklist too.

Where AI data hides

When you map where patient data goes, remember that AI features create new copies of it. Each of these needs an answer on location, retention and access:

• Audio recordings from scribe sessions, and how long they are kept.
• Transcripts and the facts extracted from them.
• Prompts and answers from copilot questions, which often name patients or balances.
• Search indexes built so the AI can find records, which contain copies of the text.
• Chatbot conversations with website visitors, which may include names, phone numbers and symptoms.
• Translations of patient instructions.
• System logs, which should never contain message text or patient details.

A good vendor can answer for every item on this list. In Helix, for example, website chat conversations follow a retention period the clinic chooses, and expired conversations are permanently deleted by a scheduled sweep.

The honest trade-offs of self-hosting

Private AI is not free of compromises. A clinic buying it should understand them:

• The vendor carries the work. Running models means managing capacity, updates, monitoring and security. You depend on the vendor doing that well.
• Model choice is narrower. A self-hosted system uses models the vendor can run and evaluate itself. It may not always use the newest model on the market.
• Evaluation matters more. Because the vendor chooses and runs the model, it should test it on clinical tasks and show you how it guards against errors.

In return, you get a shorter and clearer data path, one set of access controls and one audit trail. For clinical data, we think that trade is worth making. We also think design matters more than model size. A smaller model that must cite its source is safer than a larger one that can write anything.

How Helix runs its AI

• Models hosted in Helix's own cloud. Verto's AI runs inside Helix's own cloud environment. We do not send patient data to third-party AI APIs.
• No training on your data, ever. Customer data is not used to train models.
• Full GCC data residency. Patient data is kept in the region.
• Compliance. Helix is HIPAA, SOC 2 and GDPR compliant, with encryption in transit and at rest, role-based access and full audit logs.
• Governed actions. Every AI decision is written to an immutable audit log, and a platform-wide pause switch can stop the AI at once.
• Local translation. Arabic patient instructions are translated on Helix's own AI host, not by an outside translation service.

The same approach covers the scribe, the copilot and the AI workforce inside Verto. For regional rules on health information exchange and claims, see our UAE compliance overview and Saudi Arabia page.