The secure document pipeline: PGP, Vault, and where PII actually gets stopped

Most enterprise AI programmes discover their data problem the same way: legal reviews the pilot, and the pilot dies. Not because the model is wrong — because nobody can say where the customer records went.

We built a different starting point for one of Europe’s largest telecoms, on their enterprise GenAI platform. The requirement was simple to state and hard to build: sensitive documents needed to reach a model, but plaintext PII could never touch a log, a vector store, or a disk it didn’t need to.

Intake: PGP before anything else

Documents enter the pipeline PGP-encrypted at the source. This matters more than it sounds — most “secure” pipelines encrypt in transit (TLS) and call it done, which protects the wire but not the destination. Ours keeps documents encrypted until the exact processing step that needs plaintext, and no earlier.

Keys: HashiCorp Vault, and a rule with no exceptions

Decryption keys live in HashiCorp Vault. The rule we built the architecture around: private keys and plaintext PII are never persisted, and never enter the processing graph as a durable artefact. A pipeline built around that rule has a narrower failure mode than most: if a job fails, it fails — it isn’t allowed to leave a plaintext copy behind to debug from later, which is a harder constraint to design for than it sounds, but the right one to hold.

Redaction: DLP in the flow, not at the edge

PII detection and redaction (Google Cloud DLP) runs inside the flow, before the document reaches anything downstream — the model, the vector store, the logs. This is the detail most builds get backwards: they bolt redaction onto the edge of an existing pipeline as a filter, which means anything the filter misses has already reached somewhere sensitive. Redaction-in-flow means the sensitive version of the document never exists as a durable artefact anywhere downstream — only transiently, for the one processing step that needs it.

Auditability without exposure

The output is governed and auditable: a security team can verify every step of the flow without ever needing access to the plaintext itself. That’s the property that actually gets sign-off. Not “we redact PII,” which every vendor claims, but “here is the audit trail, and it doesn’t require you to trust us — you can see the boundary was never crossed.”

Why this is the first thing we build, not the last

The pattern above sounds like infrastructure, and it is — but it’s infrastructure that determines whether an AI programme survives contact with a security review. We build this pipeline before the interesting agent work starts, not after, because a governed intake layer is reusable across every use case that follows it. The alternative — building the flashy agent first and retrofitting governance once legal asks — is why most pilots that “worked” in the demo never make it to production.

If your AI programme is stuck at “legal won’t sign off,” this is usually the layer that’s missing.