What fully homomorphic encryption changes for a server
Ordinary encryption forces a choice. Data protected in transit and at rest still has to be decrypted before anything can be computed on it, so the service provider sees it — and any feature that depends on the content requires giving up the protection.
The trade-off it removes
Fully homomorphic encryption lets computation run directly on encrypted data, so the server never holds the plaintext. The result comes back encrypted and only the key holder can read it.
That closes a specific gap rather than replacing existing protections. End-to-end encryption already keeps a provider out of user data; what it cannot do is let the provider run a model over that data. FHE is what makes a feature possible without the decryption step in the middle.
"Standard protections like end-to-end encryption present a trade-off: user-data can be protected from data breaches, but then the service provider cannot provide features that depend on the data."
Why it needed a compiler at all
The technique has existed for years; what has been missing is a way to use it without cryptographers. Converting an existing program into an efficient encrypted version has meant hand-optimization by specialists, which puts it out of reach of ordinary product work.
A compiler moves that expertise into tooling. The developer states which values are secret, and the transformation, scheme selection and parameter choices become the compiler's problem rather than a research project per application.
"Write a program in Python, annotate the types to mark which are secret, and HEIR will compile the rest."
What HEIR compiles to
A compiler is defined by its targets. HEIR's target list is the reason it is positioned as infrastructure rather than as one more FHE library.
Standard libraries as the backend
HEIR generates code for established FHE libraries, naming OpenFHE and Lattigo. It does not attempt to replace them.
This is the pragmatic choice. Those libraries carry the audited scheme implementations, and a compiler that emitted its own primitives would inherit the burden of proving them correct. Sitting above them means HEIR competes on the optimization and usability layer, where the actual barrier is.
"Support code generation for standard FHE libraries, such as OpenFHE and Lattigo."
Accelerators, including hardware that is not shipping yet
The target list also covers GPU, TPU, FPGA and custom ASICs. Encrypted computation is expensive enough that specialized hardware is the expected route to production speed.
Google names partnerships with Belfort, Niobium, Cornami and Optalysys, all building accelerators for this workload. Compiling to an intermediate representation is what makes that bet cheap: when a new accelerator arrives, the applications above do not get rewritten.
"Support code generation for FHE hardware accelerators, including GPU, TPU, FPGA, and custom ASICs."
Research and benchmarking as first-class goals
Two of the project's stated goals are providing a platform for research into novel FHE optimizations and for benchmarking. That is unusual to state alongside production ambitions, and it explains the shape of the project.
The effect is compounding. A cryptographer with a new optimization can implement it inside HEIR and inherit the test, benchmark and comparison infrastructure instead of rebuilding it, which is how improvements reach applications rather than staying in papers.
"By building on HEIR, cryptographers can focus on their specific optimization and use the existing infrastructure for testing, benchmarking, and comparisons."
What the demonstrations do and do not prove
Google shipped four worked applications with source code. Read carefully, they mark the boundary of what is currently practical.
Four applications, all classification-shaped
The demonstrations cover private content recommendation, credit card fraud detection, network intrusion detection and hotword detection. Each was built with a partner and each is a model producing a small answer from private input.
That shape is not incidental. Encrypted inference costs grow with the computation, so the workloads that land first are the ones with a bounded model and a short output: a score, a flag, a yes or no. Generative workloads are a different order of expense.
"We have partnered with companies developing hardware accelerators for homomorphic encryption, including Belfort, Niobium, Cornami, and Optalysys."
The latencies are single-threaded CPU figures
Every latency in the writeup was measured on a single-threaded CPU, and the source code is published. Both details matter when judging the numbers.
Single-threaded is the conservative baseline: it understates what a tuned deployment would achieve and it makes the comparison across the four applications honest. Publishing the source is the stronger signal, because it means the figures can be reproduced rather than taken on trust.
"Each application was compiled with HEIR, and latency numbers are presented for a single-threaded CPU. The source code for all examples is available in our GitHub repository."
The documentation for this toolchain is spread across a blog post, a docs site and a GitHub repository, and the parameter tables are where the real constraints live. Converting those pages to markdown before feeding them to a model keeps the tables intact, which matters when the answer you need is in a cell rather than a paragraph.
HEIR is best read as an infrastructure bet rather than a product announcement. The cryptography works; the cost is the problem; and the way costs come down is a compiler that lets optimizations and accelerators arrive without rewriting the applications above them. For a team evaluating it today, the honest question is not whether encrypted inference is possible but whether your workload looks like one of those four — small model, bounded output, private input — because that is the shape currently within reach.
