The patient in the probability cloud.

This idea came up in our lab. Think of an electron. Physics cannot give its exact location, only the cloud of places where it probably is, and collisions sharpen that cloud. Now imagine two electrons, a sender and a receiver, in a space that holds a file. You can read the file only if you can find where the sender sits in relation to the receiver. Everyone else sees only the cloud. If you make the space bigger or more complex, the cloud becomes harder to see through.

This idea is closer to a specification than to a metaphor. The US government published an encryption standard in 2024 to withstand quantum computers, ML-KEM (FIPS 203). It works on almost exactly this principle. This article explains it with two small tools that you can run yourself. It then shows why it matters most for patient records.

An intuition worth taking seriously

The real name for the electron cloud is Learning With Errors. The cryptographer Oded Regev introduced this problem in 2005. The table shows how the parts of the intuition map onto it.

The intuition	The real concept
The space holding the electrons	A lattice, which is a grid of points in many dimensions
The electron’s position	A secret point in that grid, the receiver’s private key
Position known only as a probability	Every published clue is the secret plus random noise
The probability both sides agree on	Two values that come out close but unequal, rounded to the same bit
A bigger, stranger space is harder	The security level, because ML-KEM-512, 768 and 1024 differ in exactly these dials

One part of the intuition needs a correction. A single probability between one and a hundred is only about seven bits of secret. Anyone could guess it in a hundred tries. The strength comes from the size of the space, which must contain on the order of 2¹²⁸ possibilities, a number with thirty-nine digits. The cloud makes shortcut searches of that space impossible.

Run the electron cloud yourself

The lab below runs a real, toy-sized version of this math in your browser. A sender hides 64 secret bits. The receiver holds the key, cancels the noise and reads the bits back. An attacker without the key tries two ways to break in. The first solves the equations directly. The second tries every possible key, when the space is small enough.

The lab shows two rings. Each dot is one secret bit. Dots near the top read as 0 and dots near the bottom read as 1. The receiver’s ring shows two tight clouds. The attacker’s ring scatters dots everywhere.

Try the presets in this order. Each preset teaches one thing.

1. Balanced. The sender and receiver agree on every bit. The attacker gets about half right, which is what a coin flip gets.
2. No cloud. Set the noise to zero. The published clues become exact equations, and ordinary high-school algebra solves them. The attacker gets every bit. Most people find this result surprising. The randomness is the lock, not decoration.
3. Cloud too wide. Turn the noise up until the receiver’s dots cross the halfway line. The attacker still guesses, but the receiver now makes mistakes too. The receiver’s ability to read the message sets the ceiling on security.
4. Tiny space. Shrink the space to three dimensions. There are under a million possible keys, so the attacker tries them all. A secure system needs a large space.

Interactive lab loading.

Real systems choose these dials so that the receiver almost never misreads a bit. They also make the attacker’s search run longer than the age of the universe. The lab lets you adjust that balance yourself.

Why patient data needs this now

Most data loses value fast. Patient data does not. A diagnosis, a genome or a mental-health history is as sensitive in thirty years as it is today. This creates a specific threat called harvest now, decrypt later. An attacker records encrypted health data today and stores it. The attacker then waits for a quantum computer that can break the older encryption that protected the exchange.

Nothing here is broken today. The public and private keys that protect your connections still hold today, and no quantum computer exists that can open them. The risk is that an attacker opens a recording made today at a later date. Patient data is still worth opening in thirty years.

The older methods for agreeing on a key use the mathematics of RSA and elliptic curves. A large quantum computer would break these methods. The electron-cloud style of key agreement resists that attack. NIST standardized it in 2024, so adopt it now for anything with a long shelf life, not after someone announces the first quantum computer.

Encryption that protects a stored file, such as AES with 256-bit keys, is already considered strong against quantum attack. The weak points are the moment two parties agree on a key and the signatures that prove nobody altered a document. Post-quantum methods replace those parts.

First line of defense: don’t be seen

Harvest now, decrypt later has a precondition that is easy to miss. The attacker must capture the traffic first. The attacker cannot store data that never crosses the attacker’s path, so nobody can decrypt that data in 2040. Before you choose an encryption method, the cheapest protection is to give an attacker less to see.

• Keep the pipeline private. Move files over SFTP or private connections inside a VPN or private network. Do not use open internet endpoints. Encryption still applies inside the tunnel. The tunnel decides who can record the traffic at all.
• Hide the origin and the destination. A public endpoint with an obvious name tells an attacker where the valuable data flows. Keep endpoints off the public internet where you can. Keep the metadata thin. Who sends what, to whom and how often is also information.
• Move less. The safest transfer is the one that never happens. Processing data where it already lives leaves less in transit to capture. We build our tools to work that way.

Hiding is one layer of defense in depth. It does not replace encryption. Protection that depends only on staying hidden fails the day the hiding fails. The working order is to make the data hard to see, then make it useless if an attacker sees it anyway.

Two ways to make a record safe

Encryption protects data only while the data stays locked. Most of the time, teams must use health data. They analyze it, share it with a research partner or give it to an AI model to summarize. Two different approaches serve this use, and choosing the wrong one is a common, expensive mistake.

• Destroy the identity for good. In the industry this is de-identification. The process removes names, numbers and addresses or replaces them with tokens. It shifts dates, truncates ZIP codes and groups ages over 89 together. It discards the key that could link a token back to a person. This follows the shape of the HIPAA Safe Harbor method. It suits research releases and analytics, where nobody needs to know who anyone is.
• Disguise it and keep the key. In the industry this is pseudonymization with a token vault. The process replaces every identifier with a realistic fake that has the same shape, such as a fake Social Security number, phone number or name. An encrypted vault that never leaves your machine locks the originals. An AI model or a vendor can work on data that looks real, and your system restores the true values locally afterward. Destroying the vault’s key, called crypto-shredding, makes the originals unrecoverable on demand.

The lab below is the product. It is Harbor in miniature, the same design as the privacy layer we are building, shrunk to run in your browser on synthetic patients. It has three modes. Classify finds the identifiers, Obfuscate destroys them, and Falsify disguises them with a vault that you can restore or shred. You can show any patient in four formats: a chart, a FHIR bundle, an HL7 v2 message and a C-CDA document. Hospitals use these three standards to exchange records. Each one holds the patient, an encounter, a diagnosis and a lab result. The HL7 and C-CDA views are excerpts, because real files of those types are much longer. In every format, the identity changes while the clinical codes and the lab value stay the same. Under each mode, a panel shows exactly what would leave the building, with a leak check that scans it for every original identifier.

Interactive lab loading.

Run Classify first and watch the leak check go red. Finding sensitive data protects nothing on its own. It is the step before protection, and many products stop there.

What GDPR asks of the same two modes

HIPAA is an American law with a checklist. Europe’s GDPR has no checklist and no expert sign-off route. It tests whether anyone can identify a person in a data set by “all the means reasonably likely to be used”. Recital 26 of the GDPR states this test, and the result decides which rules apply. The two modes give different answers to that test.

	Destroy the identity (Obfuscate)	Disguise it (Falsify)
GDPR term	Anonymisation	Pseudonymisation (Article 4(5))
Personal data for you?	No, if nobody can reasonably re-identify it	Yes, because you hold the key
Personal data for the recipient?	No, under the same test	Possibly not, after the 2025 ruling below
How GDPR treats it	Outside the regulation	A named safeguard (Articles 25 and 32)

The 2025 ruling that matters. On 4 September 2025 the EU Court of Justice decided EDPS v SRB (Case C-413/23 P). A public body had pseudonymised people’s comments. It sent them to Deloitte for analysis and kept the key to itself. The Court held that pseudonymised data is not personal data “in all cases and for every person”. Depending on the circumstances, pseudonymisation can stop anyone other than the controller from identifying the person. For those other parties the person “is not or is no longer identifiable” (Court press release No 107/25).

This is the shape of the disguise mode. The vault and its key never leave your machine. A vendor or an AI model receives realistic fakes and no way to reverse them. Under the Court’s reasoning, that data may not be personal data in the vendor’s hands at all. Shredding the vault key also gives you a practical way to erase data when a person exercises the right to erasure under Article 17.

The ruling comes with two limits, and we will not skip them.

• Your own duties don’t shrink. For the duty to inform people, the Court said that you assess identifiability “at the time of collection of the data and from the point of view of the controller”. You still need a lawful basis for health data. GDPR treats health data as a special category (Article 9). You still tell patients who will receive their data before you mask anything.
• “Possibly” depends on the facts. The ruling turns on the circumstances. Free-text notes and rare combinations of details can still point to a person, so the masking needs an assessment. Our assessment uses the same evidence and the same staff expert as the HIPAA determination above, measured against the European test. An independent reviewer can receive the same evidence if you prefer.

What it costs to get this wrong

Healthcare has the most expensive data breaches of any industry. IBM’s 2025 Cost of a Data Breach report puts the average healthcare breach at $7.42 million. Healthcare has topped the industry list for more than a decade. That number counts detection, notification, legal exposure and lost business. It does not count the patient’s lost privacy, which no settlement returns.

Organizations also pay a second cost to avoid that risk. Organizations usually rent privacy tooling as a subscription per seat or per record, forever. The software runs on someone else’s infrastructure, so you must send the data you want to protect to another party. We think that model is wrong for health data. The protection should run where the data already lives, and the organization should own it outright.

What we are building

The first lab above teaches the theory. The second is a miniature of the real thing, with simplified detection so it fits in a web page. Harbor is the privacy layer of Pharos, the data platform we are building. It runs locally, next to the data. It handles the formats that health data actually arrives in. These formats are spreadsheets, FHIR, HL7 and C-CDA documents, and free-text notes. The table shows where it stands, without rounding up.

Capability	Status
De-identification and reversible masking of patient records, run locally	Working
Tamper-evident audit evidence signed with a post-quantum hybrid signature (Ed25519 plus ML-DSA)	Working
Encrypted local vault (AES-256) for reversible masking	Working
Post-quantum key exchange (hybrid X25519 plus ML-KEM-768)	Planned
Moving format-preserving encryption to the NIST-approved FF1 method	Planned
Computing on data that is never decrypted (fully homomorphic encryption)	Research demo

The last row is the long horizon. It is the reason we put so much work into the other rows. The next section covers it.

Looking ahead · Our research track

The long game: computing on data nobody can read

Everything above protects data by changing it or hiding it before it goes anywhere. Fully homomorphic encryption (FHE) goes further. It lets a computer do math on data while the data stays encrypted. The answer comes back encrypted too, and only you hold the key that opens it.

FHE connects directly to the first lab on this page. The leading FHE schemes use the same lattice math as the electron cloud, and every encrypted number carries a little noise. Each calculation widens the cloud. When the cloud gets too wide, the scheme must stop and clean it up in a step called bootstrapping. That clean-up is most of the reason FHE is slow today.

Why we think this is the next big thing

Right now, an organization that wants a powerful AI model to work on sensitive data has two choices, and both are bad.

• Send the data to someone else’s model. Any hosted model, open or closed, must see your data to work on it. For patient records, trade secrets or unreleased research, this is often not acceptable.
• Buy your own GPUs and run a model in-house. This keeps the data home. It also adds a permanent cost for hardware, power, staff and upgrades. You pay it mainly to avoid trusting anyone else. We analyzed this rent-versus-buy decision in the real cost of AI.

FHE is the third option. You send encrypted data to any model host you choose, and the host computes without being able to read your data. The model’s owner and location do not matter, because the host never holds a key. You stop paying for GPUs as a privacy measure and choose hardware on price and performance. The model owner keeps the model, you keep your data, and neither party must trust the other.

Where it actually stands

1. FHE in a consumer product Shipping

   Apple uses homomorphic encryption for Live Caller ID Lookup in iOS 18 and for Enhanced Visual Search in Photos (Swift.org, Apple ML Research)

2. A full open model running encrypted Demonstrated

   Llama-3-8B generated text under FHE in February 2026, at under 100 seconds per output token on a GPU (Cachemir, arXiv:2602.11470)

3. The speed gap on ordinary computers Gap

   FHE takes thousands to tens of thousands of times longer than computing on unencrypted data (IEEE Spectrum, March 2026)

4. Dedicated chips Hardware

   Intel’s Heracles chip ran key FHE operations 1,074 to 5,547 times faster than a server CPU. Intel calls it “like the first microprocessor” (IEEE Spectrum, March 2026)

5. Read that timeline as a trajectory. Encrypted AI already works. It is too slow for a chat window today, and purpose-built hardware already cuts the gap by three orders of magnitude. We think the gap closes within years, not decades. The organizations that are ready for it will be the ones whose data pipelines keep data private from the start.

6. We are here · we're building

   What we have today

   Harbor carries a working FHE research demo. A client encrypts a patient’s numbers. A server runs a simple risk score on them without being able to decrypt anything, and only the client can read the score. It is one small model and it runs far slower than the unencrypted version, so it is a demonstration, not a product.

   This limit is deliberate. The masking and vault that you used above put health data to work safely now. The disguise mode lets any model work on realistic fakes today. FHE is the road to letting a model work on the real data without seeing it. We are building both in the same tool, so the switch is an upgrade and not a rebuild.

   If you are an organization that wants to put health data to work without letting it leave your walls, the pieces above serve that need, and you own what we install. See how we price. You can also read the earlier pieces on whether your data is safe and the real cost of AI.

FHE

What we will not claim (anti-fabrication)

To discuss your own data, get in touch or see how we work on AI consulting.

––