RegLeg™ processes the most sensitive material a regulated organization owns: its policies, its dispositions, its regulatory posture, the record of how it decided what a rule required. A platform that handles that material cannot wave at security. It has to be specific. Tenant scoped is the word we use, and we mean something precise by it at every layer where your data moves.
The concern driving all of this is well documented. A 2026 Cisco privacy benchmark found that seventy percent of organizations acknowledge real exposure from proprietary or customer data being used in AI training, while only fifty five percent require contractual terms that actually define data ownership and liability. The gap between the worry and the paperwork is where bad outcomes live. So let us close it, layer by layer.
The data layer: isolation that is enforced, not promised
Tenant scoping starts at the data layer, and the question is simple: can one customer ever see, or influence the output served to, another customer? In a multi tenant platform, isolation is enforced through real mechanisms, tenant scoped access controls, per tenant separation in the data model, and application level filtering that binds every operation to a tenant identity. The right answer is not that cross tenant access is unlikely. It is that the architecture makes it structurally impossible, and that the vendor can show you how.
Your taxonomy, your policies, and your reviewer feedback are learned for you and kept inside your tenant. They are an asset that improves your experience of the platform, and they never become a shared resource that lifts a competitor.
The model layer: where the real distinction lives
This is the layer that separates honest vendors from convenient ones, and it requires a distinction most marketing copy refuses to make.
There are two very different things a vendor can do with your data and a model. The first is use your data to train or fine tune a base model whose weights are shared across customers. That is the practice buyers are right to fear, because it can absorb your content into something other customers touch. The second is tenant scoped learning, where your data shapes your experience inside your boundary and goes nowhere else. The first is a leak waiting for a clever prompt. The second is the product working as it should.
RegLeg does not say we never train, because that phrase is usually a dodge. Tenant scoped training on your own corpus, for your own benefit, inside your own boundary, is a good thing, and we do it openly. What we guardrail is the interaction with foundation models, the large base models that sit underneath. When the platform routes a request to one of those models, the request is bounded by tenant policy: which models are eligible, which content classes may transit, which jurisdictions are out of bounds, which prompts require human review.
The integration layer: zero retention as architecture, not a setting
Foundation model providers have moved on this, and a serious vendor builds on top of the strongest available terms rather than the defaults. The major providers generally do not train their base models on enterprise API traffic, but many retain inputs for a window, often around thirty days, for abuse monitoring unless a zero retention arrangement is in place. Enterprise zero data retention configurations exist precisely to close that window, so that prompts and completions are processed and discarded rather than stored.
Zero retention as we mean it is an architectural property, not a checkbox. Customer data is processed in memory for the operation and then it is gone. The inference pipeline is stateless. Identifiers are stripped before traffic leaves the boundary. Nothing is cached, nothing is logged as content, and only minimal operational metadata, latency, errors, the disposition of a request, is kept so the audit trail can exist at all. Data is processed, not retained. That is the whole sentence, and it has to be true at the integration layer or it is not true anywhere.
The contract layer: the commitment in writing
Architecture without a contract is a demo. The commitments above have to land in the agreement, with the right to verify. That means an explicit prohibition on using your data for base model training, fine tuning, or service improvement; documented zero retention behavior with any underlying model providers; named data residency and isolation mechanisms; audit rights or third party audit reports; and a defined fate for your data on deletion request or termination. The audit trail, the prompt, the response, the model, the latency, and the disposition, is yours to inspect.
The questions to ask any AI vendor, including us
Bring these into procurement and ask them of every vendor that uses the words tenant scoped or zero retention. Does the contract explicitly prohibit using our data to train or improve any model whose benefit reaches another customer? Where and for how long is our data, prompts, outputs, and embeddings, retained, and can you give us zero retention in writing, including with your underlying model providers? What are the exact isolation mechanisms, and how is cross tenant access prevented by construction? Can we audit your data handling, or receive a third party report on it? And what happens to our data the day we leave?
A vendor that has built tenant scoping properly will answer all five without flinching, because the answers are the same ones their architecture already enforces. We hold RegLeg to exactly this standard, and we expect you to make us prove it. Tenant scoped training is positive, foundation model interactions are guardrailed, and the audit trail is yours. That is the commitment, in plain language.