Why We Built an AI That Classifies Documents It Can’t Read

The Paradox

We built an AI that classifies documents it cannot read. Not "chooses not to read." Cannot. The document is encrypted with fully homomorphic encryption before the classifier ever touches it. The classifier evaluates encrypted feature vectors and produces encrypted output. At no point does any system — including ours — see the plaintext.

This sounds like a contradiction. How can a machine learning model make a decision about content it has never seen? The answer is mathematical: fully homomorphic encryption preserves the algebraic structure of the data. Addition on ciphertext corresponds to addition on plaintext. Multiplication on ciphertext corresponds to multiplication on plaintext. A neural network is nothing more than a series of additions and multiplications. If the math works on plaintext, it works identically on ciphertext.

The result, when decrypted by the data owner, is mathematically identical to running the same classifier on the raw document. The server that performed the computation never saw the document, never saw the classification scores, and cannot extract any information from the encrypted intermediaries. The ciphertext is computationally indistinguishable from random noise.

This is not a research prototype. It is a production system. Documents enter encrypted. Policy tags exit encrypted. The customer decrypts at their boundary. H33 processes millions of classification decisions without ever knowing what the documents contain, what policy classes exist, or which documents match which rules.

Why Not Use an LLM?

GPT-4, Claude, Gemini — all of them require plaintext input. You send your document to a third-party API. The API reads it. The model processes the raw text. Even if the provider promises deletion after processing, even if they contractually commit to not training on your data, the data existed in plaintext on their infrastructure. It was in memory. It was in transit. It was, for some number of milliseconds or seconds, fully readable by the systems that processed it.

For most applications, that tradeoff is acceptable. For regulated industries — healthcare, finance, legal, government — it is a non-starter. You cannot send protected health information to OpenAI and call it HIPAA compliant. You cannot send material non-public financial information to an external API and satisfy SOX controls. You cannot send classified government documents to a cloud LLM and maintain security clearance compliance.

The usual workaround is to run the model on-premises. Self-host a large language model, process documents locally, never let data leave the perimeter. This works, but it trades one problem for another. You now need GPU infrastructure to run a model with billions of parameters. You need ML engineering staff to maintain it. You need to manage model updates, version drift, and prompt injection vulnerabilities. You have replaced a data exposure problem with an operational complexity problem, and you are still processing plaintext documents on servers that insiders, attackers, or subpoenas can access.

There is a more fundamental issue: LLMs are stochastic. The same input does not always produce the same output. Temperature settings, sampling strategies, and non-deterministic GPU execution paths mean that running the same document through the same model twice can produce different classifications. For compliance purposes, this is disqualifying. If you cannot reproduce a classification decision, you cannot audit it. If you cannot audit it, it does not satisfy regulatory controls. An LLM-based classifier is neither deterministic nor attestable.

A Purpose-Built Classifier, Not a General Model

The H33 classifier is not a large language model. It is a small, compact neural network — two to three dense layers, typically 64 input neurons narrowing to 16 then to 8 output classes. The entire model is kilobytes, not gigabytes. It does not understand language. It does not generate text. It does not have an attention mechanism or a transformer architecture. It is a function that takes a fixed-length numeric vector and outputs a classification score vector.

This extreme simplicity is the point. A compact network with two matrix multiplications and a polynomial activation function is exactly the kind of computation that CKKS fully homomorphic encryption handles efficiently. The entire inference runs in 1–2 seconds on encrypted data. Not 30 seconds on a GPU. Not minutes with bootstrapping. Seconds, on a standard CPU, with no specialized hardware.

The classifier is deterministic. The same encrypted input always produces the same encrypted output. There is no sampling, no temperature, no randomness in the inference path. The FHE scheme introduces controlled noise during encryption, but the noise is managed within the scheme's parameters and does not affect the classification outcome after decryption. This determinism makes the classifier attestable: you can prove, using STARK proofs, that a specific input produced a specific output through a specific model. An LLM cannot make this guarantee.

The tradeoff is obvious: this classifier cannot do what GPT-4 does. It cannot summarize a document. It cannot answer questions about it. It cannot extract entities or rewrite the text in a different tone. It does exactly one thing — assign a document to one of a fixed set of policy classes — and it does that one thing on encrypted data, deterministically, with a post-quantum attestation attached to every result.

How It Works

The pipeline has five stages, each designed to keep the document encrypted from ingestion to output.

Feature extraction. Documents are converted to fixed-length feature vectors before encryption. The feature extractor runs on the customer's machine, inside their security boundary. It produces a numeric vector using TF-IDF term frequencies, structural markers (section counts, table presence, header patterns), and metadata signals (file type, size, creation context). The feature vector is a fixed-length array of floating-point numbers. The document text is never transmitted.

Encryption. The feature vector is encrypted under CKKS, the approximate arithmetic FHE scheme. CKKS is chosen because the classifier operates on real-valued weights and produces real-valued scores. BFV (integer FHE) would require quantization that degrades classification accuracy. CKKS preserves floating-point precision through the entire inference pipeline. The encryption happens on the customer's machine using their keys. The encrypted feature vector is then transmitted to H33.

Encrypted inference. The classifier evaluates the encrypted feature vector. This is the core computation. The first layer performs a matrix multiply: plaintext weight matrix times encrypted feature vector. The weights are plaintext — the model architecture is not secret, only the data is. The result is an encrypted intermediate vector. A polynomial activation function (a low-degree polynomial approximation of ReLU or sigmoid) is applied homomorphically. The second layer performs another plaintext-times-encrypted matrix multiply to produce the output: an encrypted classification score vector with one score per policy class.

Threshold decision. The encrypted score vector cannot be read by H33. We do not know which class scored highest. A TFHE threshold check determines the winning class without decrypting the scores. TFHE operates on individual encrypted bits and can evaluate comparison circuits — "is score[i] greater than score[j]?" — on ciphertext. The result is an encrypted tag indicating which class won. H33 learns the structure of the decision (how many classes were compared) but not the values.

Attestation. The classification result — an encrypted policy tag — is attested using H33-74, the 74-byte post-quantum attestation primitive. The attestation covers the encrypted input hash, the classifier version, the encrypted output, and a timestamp. The attestation is post-quantum secure (three independent signature families), verifiable by any third party, and tamper-evident. The customer receives the encrypted tag and the attestation. They decrypt the tag at their boundary to see the classification result.

Customer-Trained, Not H33-Trained

H33 does not train the model. We provide the SDK and the CKKS inference pipeline. The customer provides everything else.

The customer provides labeled examples from their own documents. "These 500 documents are CLIENT_PII. These 300 are FINANCIAL_STATEMENT. These 200 are INTERNAL_MEMO." The taxonomy is theirs. The labels are theirs. The decision boundaries are theirs. H33 has no opinion about what constitutes a category, how many categories exist, or what the thresholds should be.

The customer trains the classifier on their own machine. Training runs on plaintext — the model learns on unencrypted feature vectors. Training is fast because the model is small. A two-layer network with 64 input neurons typically converges in under a minute on a standard laptop. No GPUs required. No cloud training infrastructure. No data leaving the customer's premises during training.

The trained weights — plaintext numbers, the model's learned parameters — are deployed into the CKKS pipeline. The weights are not secret. The model architecture is not secret. The security property comes from the data encryption, not from model secrecy. This is a critical distinction from LLM-based approaches where the model itself is the proprietary asset. Here, the model is a commodity. The data is the asset, and it is never exposed.

From the moment inference begins, all data is encrypted. The customer's taxonomy, their training data, their documents — none of it is visible to H33. We process ciphertext. We return ciphertext. We attest the computation. That is the scope of our involvement.

The Default Output Is a Policy Tag, Not a Probability

The product output is a policy tag. "Document matched Customer Policy Class: CLIENT_PII." Not "94% CLIENT_PII, 3% FINANCIAL_STATEMENT, 2% INTERNAL_MEMO, 1% OTHER." The encrypted score vector exists inside the ciphertext — the classifier computed it — but H33 cannot read it, and we do not expose it by default.

The reason is architectural, not philosophical. Exposing probability distributions leaks information about the model's internal state, which in turn leaks information about the training data distribution. If an attacker can observe that certain documents consistently produce 94% vs 97% confidence, they can make inferences about the training set. The hard classification — a binary "matched" or "did not match" — reveals the minimum information needed to take action.

Confidence disclosure is optional and customer-controlled. Three modes are available. Hard classification (default): the tag says which class won, nothing more. Threshold proof: a TFHE proof demonstrates that the winning score exceeded a customer-defined threshold, without revealing the score itself. This satisfies auditors who need to know "the system was at least X% confident" without exposing the full distribution. Customer-decrypted: the customer decrypts the raw score vector at their boundary, giving them full visibility into the classification scores. H33 never sees these scores in any mode.

Corrections Make It Better

Enterprise buyers do not want a black box. They want to approve, correct, and override classification decisions. The H33 encrypted classifier supports this with a correction loop that is itself encrypted and attested.

When a human reviewer disagrees with a classification, they submit a correction. The correction is H33-74 attested — the original classification, the correction, the reviewer identity, and the timestamp are all bound into a tamper-evident attestation. This creates an auditable record: "Document X was classified as CLIENT_PII by the automated system. Reviewer Y changed it to FINANCIAL_STATEMENT on May 1, 2026 at 14:32 UTC. Both the original classification and the correction are attested."

Corrections marked for retraining become new labeled examples. The customer adds them to their training set, retrains the classifier on their machine, and deploys updated weights. The model improves with each correction cycle. H33 never sees the corrections, the documents, or the updated training data. We see only that a new set of weights was deployed — a new set of plaintext numbers in the inference pipeline.

This correction loop is what makes the system an enterprise product rather than a research demo. Classification accuracy improves over time, driven entirely by the customer's domain expertise. The cryptographic audit trail satisfies compliance teams. The encrypted pipeline satisfies security teams. The correction mechanism satisfies operational teams. All three operate without H33 ever seeing the data.

What This Means for Compliance

The compliance implications of encrypted classification are not incremental. They are structural.

HIPAA requires protection of protected health information during processing. Traditional classification systems — including self-hosted LLMs — process PHI in plaintext, which means the processing environment must meet the full weight of HIPAA administrative, physical, and technical safeguards. The H33 encrypted classifier never processes plaintext PHI. The feature vector is encrypted before it leaves the customer's HIPAA-compliant boundary. The classification runs on ciphertext. The result returns encrypted. The processing environment does not need to be HIPAA-compliant because it never handles PHI.

GDPR requires purpose limitation and data minimization. A classification system that reads document content processes more data than necessary for the classification task. The H33 classifier processes an encrypted feature vector — a fixed-length numeric array that does not contain the document text. Even if the ciphertext were compromised, it reveals nothing about the document. This is data minimization by construction, not by policy.

SOX requires auditable controls over financial reporting processes. Document classification that routes financial statements to compliance workflows is part of that control chain. The HATS attestation on every classification decision — input hash, model version, output, timestamp, all post-quantum signed — creates an audit trail that a SOX auditor can verify without accessing the documents themselves. The auditor verifies the attestation chain. They do not need to see the data to confirm that the classification system operated correctly.

The pattern is consistent across regulatory frameworks. If the classification system never sees the data in plaintext, the compliance posture changes fundamentally. You are not "protecting data during classification." You are classifying data that was never exposed in the first place. The distinction matters when regulators ask not "how do you protect data?" but "does data exist in a readable form during processing?"

The Architecture

The end-to-end pipeline, from document ingestion to policy tag, operates as follows:

Customer SDK — the customer defines their taxonomy (policy classes), provides labeled examples, and trains the classifier on their machine. The SDK handles feature extraction, model training, weight export, and CKKS encryption of feature vectors. The SDK runs entirely on the customer's infrastructure.

Deploy weights to H33 — the trained model weights (plaintext) are uploaded to the H33 inference pipeline. The weights describe the classifier's learned decision boundaries. They are not secret — they reveal the model architecture but not the training data.

Documents enter encrypted — each document is converted to a feature vector on the customer's machine, encrypted under CKKS using the customer's keys, and transmitted to H33. The document text never leaves the customer's boundary.

CKKS inference — the encrypted feature vector passes through the neural network layers. Plaintext weights multiply encrypted features. Polynomial activation functions evaluate homomorphically. The output is an encrypted score vector.

H33-74 attest recommendation — the encrypted classification is attested with the 74-byte post-quantum primitive. The attestation binds the input, the model version, the output, and the timestamp.

Policy engine applies rules — customer-defined rules determine what happens after classification. Route to review queue. Apply retention policy. Trigger workflow. Escalate to human. The rules operate on the tag, not on the document content.

TFHE tags created — the policy tags are created as TFHE-encrypted boolean values. Tags can be evaluated in downstream systems without decrypting the core classification scores.

UpstreamBundle committed — the complete classification record — encrypted input hash, encrypted output, attestation, tags — is committed as an UpstreamBundle. Tags are evaluable by downstream systems without decrypting core content.

Every step encrypted. Every step attested. Zero plaintext exposure. The customer decrypts at their boundary to see results. H33 sees ciphertext in, ciphertext out, attestations attached. That is the entire system.

What This Is Not

This is not a general-purpose AI. It cannot answer questions about your documents. It cannot summarize them. It cannot generate new text based on them. It is a classifier. It assigns documents to categories. That is the scope.

This is not a replacement for LLMs in use cases where plaintext processing is acceptable. If you are comfortable sending documents to a cloud API, an LLM will give you richer output — summaries, entity extraction, question answering, translation. The encrypted classifier exists specifically for organizations that cannot or will not send documents to a plaintext processing system.

This is not magic. The classification quality depends entirely on the customer's training data and taxonomy design. A poorly defined taxonomy with insufficient labeled examples will produce poor classification results — encrypted or not. The FHE pipeline guarantees privacy, not accuracy. Accuracy is the customer's responsibility, and the correction loop gives them the mechanism to improve it continuously.

What this is: a production system that proves AI does not require reading your data to be useful. The document classification use case is the first instantiation. The same encrypted inference pipeline applies to biometric matching, AI agent attestation, fraud scoring, and any domain where a compact model can be trained on customer-provided labels and deployed under FHE. The principle is the same in every case: the data stays encrypted, the model operates on ciphertext, and the result is attested.

We did not build this because encrypted AI is an interesting research topic. We built it because enterprise customers told us they need document classification that satisfies their CISO, their compliance officer, and their general counsel simultaneously. Plaintext AI cannot do that. Encrypted AI can. So we built it.