The case for keeping your documents where they are

When we designed COMPLY.Reg, we made one decision that still draws a raised eyebrow in every demonstration: we do not pull a customer’s documents into our systems. It is worth explaining why we accepted the harder path, because the reasoning goes to the heart of what sovereignty means in practice rather than in marketing.

The convenient architecture, and its cost

The industry default is to pull. A platform connects to a customer’s systems, ingests the relevant documents, and analyses them in the vendor’s cloud. The approach is easy to build and it demonstrates beautifully, which is why it became the norm. For a regulated European firm it is also the wrong trade, because the moment those documents land on the vendor’s servers, the vendor has taken custody of the customer’s most sensitive material and become a link in the customer’s own regulatory exposure.

Definition

Push versus pull

In a pull model, the platform reaches into the customer’s environment and copies documents out to analyse them centrally. In a push model, the analysis is sent to the data: the platform issues a structured package of questions, the customer’s side answers them locally, against its own documents and on a model of its own choosing, and only the structured answers return. The source material never moves, and the customer, not the vendor, decides which model ever reads it.

The choice stays with the customer

We inverted the flow. Rather than processing an institution’s evidence ourselves, the platform produces a structured metadata package, in effect a precise set of questions, and the institution runs that package against its own documents, on its own side, using a model of its own choosing. Only the structured answers return. Source documents are never transmitted to or stored on our systems.

That last point carries more weight than it first appears, because it hands the institution the one decision this debate turns on: which model ever reads its confidential material. Run the package on a self-hosted model, or one operated by a European provider, and the evidence stays beyond the reach of foreign authorities. Run it on a US-operated model, and the same exposure any US-hosted model carries follows. The choice belongs to the customer, and the architecture is what makes it a genuine choice rather than a setting buried in someone else’s cloud.

This closed off a few features that pulling would have made trivial, and it cost us engineering time we could have spent elsewhere. We would make the same decision again, because a sovereign compliance layer is only meaningful if it cannot leak what it never holds.

Architecture is a statement of priorities

There is a tendency to treat data protection as a policy layer applied on top of a finished product. The more durable version is architectural, decided before the first feature, because a guarantee enforced by design does not depend on anyone remembering the policy under pressure. Choosing not to hold a customer’s documents is a constraint, and constraints of that kind are how a platform signals what it actually values.

The easy path was available to us, and its appeal is visible on plenty of competitors’ slides. We think the harder one is the only honest way to offer European institutions a compliance system they can trust with the material they can least afford to lose.