Why health data on Copilot is a reminder to keep personal records offline
Microsoft Copilot Health pulls data from hospitals, wearables, and health apps into one AI-accessible layer. The pitch is convenience: one place to view records, ask questions, and get summaries. The privacy line that comes with it is polished. What it cannot offer, and what no vendor-controlled platform can offer, is real ownership of your own health data.
Health data is not ordinary personal data. GDPR Article 9 classifies it as a special category, alongside genetic data, biometric identifiers, and data revealing racial or ethnic origin. Processing it needs explicit consent or another recognised legal basis, and the bar is higher than for standard PII handling. That classification applies whether the data sits on a server in Dublin or Texas. GDPR follows the data subject, not the data centre postcode.
Vendor promises start to fray at the edges here. Microsoft has an EU Data Boundary commitment, and Copilot Chat became a Core Online Service under that boundary in September 2025. That means Microsoft commits to storing and processing EU data within EU borders for certain services. It does not change the corporate structure. Microsoft is a US-incorporated entity, and the CLOUD Act, passed in 2018, gives US law enforcement authority to compel US-headquartered companies to produce data regardless of where that data physically lives. EU residency of a server is not the same as EU jurisdictional control. GDPR Article 48 also stops simple handover to foreign authorities without an international agreement, but that tension is still there. Storing scan results in an Amsterdam data centre owned by a Seattle-headquartered company does not remove it.
There is also what happens inside the platform before any government agency gets involved. Microsoft 365 Copilot had a documented bug, confirmed in early 2026, where the model read, summarised, and surfaced emails marked confidential, including protected health information, while ignoring sensitivity labels for weeks. The liability position in that case is useful. AI health platforms routinely disclaim responsibility for output accuracy and for unintended exposure caused by misconfiguration or model behaviour. That responsibility lands with the person or entity that put the data there. When that person is you, and the data is your own medical history, the risk has already moved.
Vendor lock-in makes it worse quietly. Health records that live inside a platform you cannot export cleanly are records you do not fully control. The export path may exist in theory, but the format can be incomplete, metadata can be missing, versioning may not exist, and the audit trail for access can be poor or absent. By the time you want to leave, or the platform changes its terms, extraction is awkward enough that most people just put up with it.
The self-hosted option is not frictionless, but it is honest about what it is. Running Nextcloud on your own hardware gives you a local health records store with role-based access controls, end-to-end encryption at rest, and an audit log you can actually read. The default configuration needs explicit share grants; nothing is accessible without a deliberate decision. You set the retention period. You decide what syncs and what does not. There is no background model reading your files to produce a summary.
Getting offline backup right for health records means three things: local encryption before the backup leaves the machine, versioned snapshots so you can roll back to a known good state instead of losing a corrupted file, and at least one air-gapped copy that never touches a network. The air-gapped copy is the one that matters when everything else goes wrong. An encrypted USB drive stored somewhere physically separate from the server is not elegant, but it is yours.
Privacy by design means keeping PII out of logs from the start. Nextcloud’s logging level should be set to warning in config.php rather than debug; debug logs will capture file paths and user activity in ways that leak information. Restrict sync scope to a dedicated health records folder rather than giving a sync client access to the whole instance. Set a data retention period and stick to it: if you no longer need a document, delete it and empty the trash. The point is to keep the surface area small, not to encrypt an ever-growing pile of data and hope for the best.
The audit gap that cloud-hosted solutions leave open is structural. When health data lives on someone else’s infrastructure, your view of what has been accessed, by which service, and at what time is whatever that vendor chooses to show you. On your own hardware, the audit log is yours. You can check it, ship it to a SIEM if you want, or grep it at 2am without asking anyone’s permission. That is not a minor operational detail. For data classified as special category under GDPR, knowing what was accessed and when is part of the job.
The trade-off is time. Self-hosting Nextcloud on a small machine, a Raspberry Pi 5 or a repurposed thin client, takes an afternoon to set up properly. Maintaining it, applying updates, checking backup integrity, and rotating encryption keys takes a few hours a year. The cloud alternative takes ten minutes to sign up for and costs that time plus the ongoing uncertainty about where your data is, who can reach it, and what the platform will do with it next. That does not favour the cloud for data this sensitive.
