Inside Data.co, a Secure Pipeline for Enterprise LLM Ingestion

What does a secure ingestion pipeline for an enterprise LLM actually look like? It is the layer between your source systems and your model that classifies every document, redacts what should never be embedded, chunks the rest, writes vectors into a store with access-control metadata attached, and keeps a lineage record good enough to revoke a single record months later. Data.co is one of the dedicated platforms that packages this work; the question for a technical buyer is whether to adopt a platform like it or build the equivalent in-house, and how either choice slots into an existing RAG or fine-tuning program.

This piece walks the pipeline stage by stage — connectors, redaction, tokenization boundaries, pgvector storage, lineage, revocation — with the figures that make each decision concrete. It assumes you already have a model and a retrieval layer. The question here is what feeds them.

Why Ingestion Is Where Governance Lives

Sensitive data leaks from an LLM at four points: the user prompt, the retrieved context, tool results, and the model's own output. Request-time redaction is the last line of defense for RAG, not the first; the ingestion pipeline is where documents and chunks get classified, where sensitivity metadata is stamped on, and where retrieval is restricted by the requesting user's authorization. Scrub a customer's SSN-bearing ticket before it is indexed, or make sure no context that should not see it can retrieve it.

The economics of getting that wrong are no longer theoretical. IBM's 2026 Cost of a Data Breach Report puts the global average breach at USD 4.99 million, a 12% jump and a new record. Among organizations that suffered an AI-related breach, 92% lacked proper AI access controls, and those incidents averaged USD 5.33 million. The pattern is not exotic model attacks. It is governance that stopped at the model boundary and never reached the data feeding it, which is the same failure mode behind most of the 2026 OWASP LLM Top 10 — Sensitive Information Disclosure sits at LLM02, Data and Model Poisoning at LLM05, and Vector and Embedding Weaknesses at LLM09, all three rooted in what the pipeline let through.

Connectors and Source Classification

The first stage is pulling documents from the systems that hold them: SharePoint, Confluence, Salesforce, Zendesk, S3, a Postgres read replica, a dozen file shares. A platform earns its keep here by treating connectors as policy objects rather than scripts. Each connector declares what it reads, the tenant it belongs to, the classification rules that apply, and the schedule on which it re-syncs. Change data capture is cheaper than full re-indexing, and worth building in from the start.

Classification runs before anything else. Documents carry labels (Public, Internal, Confidential, Restricted) that propagate into chunk metadata. That label decides whether a chunk is redacted, whether it is embedded at all, and which identities can later retrieve it. If your source systems already have sensitivity labels, the pipeline should honor them; if they do not, this is where you add them. For teams doing this work on top of data that already sits in strict network segments, the pattern pairs cleanly with an air-gapped AI server so model and index never cross the boundary.

Redaction Before Embedding, Not After

Redaction has to happen before embedding, because once sensitive text is inside a vector index it is hard to find and remove. The common shortcut — redact only the prompt — leaves identifiers memorized in embeddings that any similarity query can surface.

Pure regex is fast but misses too much. Pure LLM redaction catches more but is roughly 14x slower than transformer NER and introduces egress concerns if the detector runs in a hosted model. A 2026 benchmark across regex, spaCy NER, GLiNER, and hybrid pipelines puts the PII leak rate — identifiers that survive redaction and reach retrieval output — between 0.04% and 0.41% depending on configuration. The hybrid pipeline (regex for structured identifiers, NER for names and places, LLM pass only on flagged chunks) is where most production systems land.

Tokenization boundaries matter here. Replace a detected SSN with a stable type token ([SSN_7f21]) rather than deleting it, so chunk length, sentence structure, and downstream embeddings stay coherent. Keep the mapping in a separate, access-controlled vault — never in the vector store — so a customer-service agent can later see the real value only if their role allows it.

Chunking, Embedding, and Access-Control Metadata

Chunking is the step people underweight. Naive fixed-size chunking is a baseline; recursive chunking splits at paragraph and sentence boundaries; semantic chunking detects breakpoints via similarity drops between consecutive sentence embeddings. The right strategy depends on the corpus. Contracts and policy documents reward heading-aware recursive chunking with modest overlap. Support transcripts reward semantic chunking because speaker turns do not line up with meaning.

Embeddings are generated chunk by chunk, and each vector is written to the store alongside access control metadata on every chunk — tenant, classification label, source document ID, allowed roles, retention clock. The metadata and the vector persist together, so retrieval filters by authorization before any similarity math runs. Chunks without metadata are a bug, not a shortcut.

pgvector is the common store for teams already on Postgres, and it is more capable than the 2023 reputation suggests. On a 100,000-vector OpenAI embedding benchmark, pgvector reached 0.978 recall at 2.6 ms median latency with ef_search=100, and 0.988 recall at 4.0 ms with ef_search=200. Below roughly 10 million vectors, pgvector plus HNSW is a full production choice; above 50 million, add pgvectorscale or move to Milvus or Pinecone. The honest reason to pick pgvector first is ACID and row-level security in the same engine as your application data, which collapses a lot of the governance surface.

Lineage, Audit, and Revocation

Lineage is the stage that separates a demo from a system you can defend in an audit. For every chunk in the index, you should be able to answer three questions: which source document produced it, which version of the redaction and chunking logic processed it, and which user or role retrieved it, when, and in response to what query. If any of those answers is "we would have to reconstruct that from logs," you do not have lineage; you have hope.

Revocation is the test case. A customer invokes a deletion right, a contract terminates, a document is reclassified from Internal to Restricted. The pipeline must find every chunk derived from that source, drop them from the vector store, invalidate downstream caches, and record the action. Platforms that store source-document IDs as first-class metadata do this in minutes; pipelines that treated chunks as immutable blobs do it in days, if at all. The same discipline matters when you are running AI agents in production, where every retrieval call is an auditable event.

Build Versus Buy, Honestly

The decision is not whether an ingestion pipeline is hard — it is, but a competent team can build one. The decision is whether the differentiated work in your product is the ingestion pipeline. For most buyers it is not. Connectors, classification, redaction, chunking strategies, lineage, revocation, and the audit surface around all of it are table stakes that every serious AI feature needs and that no customer will pay you more for.

Adopt a platform when: you have fewer than two engineers who want to own this layer for a year, your source systems are standard enough that off-the-shelf connectors cover 80% of them, and your compliance posture makes a single auditable pipeline cheaper than six ad-hoc ones. Build when: your data has structure a generic connector will flatten, your redaction needs domain-specific detectors (clinical codes, trading identifiers, legal citations), or your isolation requirements rule out any shared control plane. The cost math for that second path is the same math behind year-one RAG system costs — ingestion is typically 30 to 40% of it.

Wherever you land, the pipeline should expose a small, boring API to whatever is on top: give it a query and an identity, get back ranked chunks the identity is authorized to see, with source IDs and classification labels attached. Everything interesting the model does happens after that call. Everything that keeps you out of an incident report happens before it.

Where to Go From Here

Three situations, one next step each. If you are standing up a first RAG feature on a small corpus and have Postgres in production, start with pgvector, a hybrid redaction stage, and chunk-level access metadata from day one, and the AI engineering team you bring in should refuse to ship without those three. If you already have a RAG system in production and discover you cannot answer a deletion request in under a week, your missing piece is lineage; fix the metadata schema before you add any new sources. If you are evaluating platforms like Data.co against an internal build, price a two-engineer year against the platform's annual contract, then add the audit and revocation work the platform will do for you, and compare against a reference like secure AI agents touching ERP and CRM to see what you are actually buying. The right answer is almost never the exciting one.