The text never leaves: running the compliance model in your own network

There is a point in some procurement conversations where contracts stop helping. A bank’s security lead listens to the data-residency answer, the retention answer, the processor terms, and then says a version of the same sentence every time: that is all fine, but the text still cannot leave our network. Not to the EU, not to our own cloud tenant, not anywhere. At that point the question is no longer which safeguards you apply to a transfer. It is how you run a compliance check when there is no transfer at all.

That is the problem an enclave deployment solves. Instead of sending the draft to a model, the model runs inside the customer’s network, on the customer’s hardware, with no external egress. The analysis happens where the data already is. Nothing crosses the boundary, because the thing that does the analysis has been brought inside it.

The line that makes this necessary

For most organisations a cross-border or third-party transfer is a risk to be managed with the right paperwork. Under the GDPR, Chapter V lets you move personal data outside the EU with appropriate safeguards; under Article 9 of Turkey’s KVKK, transfer abroad is a regulated act you can satisfy with the right conditions. Paperwork is enough, most of the time.

For some organisations it is not a paperwork question, it is a prohibition. A bank under local supervision, a firm holding special-category data at scale, a public body, a defence supplier: for these, “the text leaves our network” is not a transfer to document, it is a line that is not crossed. The reasons vary, regulatory, contractual, political, but the effect is identical. A tool that needs to send the draft somewhere to analyse it is disqualified before anyone evaluates how well it detects anything.

Enclave exists for exactly that side of the line. It does not make the transfer safer. It removes the transfer.

What “the model runs in your network” actually means

The shift is architectural. In a cloud or sovereign deployment the intelligence lives centrally and the data comes to it. In an enclave the intelligence is shipped to the data: the model and the engine are deployed inside the customer’s environment, and they run there without reaching out. Updates arrive as artifacts the customer brings in and applies, not as a live connection to the vendor.

Three things follow from that, and they are the things to plan for:

• The customer provides the hardware. Running a model internally means hosting it on infrastructure capable of doing so. The organisation supplies and owns that; the vendor provides sizing guidance. This is the main practical difference from a cloud edition that is live in minutes.
• There is no external call in the data path. The analysis is local. That is the entire point, and it is what the security review verifies: that the deployment has no egress it does not need.
• Operations move in-house. Monitoring, applying updates, and capacity sit with the customer’s team, with vendor support. An enclave is something you run, not something you consume.

Enclave or sovereign: a distinction worth getting right

These two get confused, and choosing the wrong one wastes a quarter. The difference is a single question: can the data sit in a cloud at all?

If your policy allows data to live in a cloud account you control, sovereign is lighter and sufficient. If the policy is that the text does not enter any cloud, sovereign does not satisfy it and enclave is the fit. The test is not how sensitive the data feels; it is whether a cloud, any cloud, is permitted in the data path. Teams that reach for enclave when sovereign would do take on infrastructure they did not need. Teams that try to stretch sovereign to cover a no-cloud policy fail the security review.

Is enclave right for us

Four conditions, and if the first is true the rest usually follow:

1. Our policy or regulator forbids the message text from leaving our network, as a hard requirement rather than a preference.
2. We can host a model internally, or are prepared to provision the hardware to do so.
3. We have a team that can operate an in-network deployment, with vendor support.
4. The value of catching the risky sentence before it sends justifies running infrastructure to do it.

If the first condition is not true, enclave is probably the wrong edition and a lighter one will serve. If it is true, no amount of cloud safeguard will substitute, and the conversation should move to sizing and operations rather than contracts.

What an enclave does not change

It is worth being plain about the limits, because an enclave is sometimes sold as if moving the model in-house solves everything. It solves one thing precisely: the text no longer leaves your network. Several other things stay exactly as they were, and a buyer should price them in.

• The operational load is yours now. A cloud edition is a service you consume; an enclave is a deployment you run. Monitoring, capacity, and applying updates sit with your team. That is the direct cost of the control you gained, and the team that will carry it should sign up before the contract.
• It is not a defence against a malicious insider. A pre-send check reads a draft and flags the risky sentence; it is a guard against the careless line, not the determined one. Running it in your network does not turn it into an enforcement boundary, and it should not be sold as one. The internal threat model is a separate control.
• Detection is the same, not better. The engine inside the enclave is the engine in the cloud edition. Organisations sometimes assume the on-premise version must be the premium one; it is the same analysis, deployed differently. You are buying control over location, not a sharper check.
• Updates still have to reach it. With no live connection, new engine versions arrive as artifacts your team brings in and verifies before applying. That is manageable, but it is a process you own, and skipping it means the check slowly ages. Decide who owns the update cadence on day one.

None of these is a reason not to choose an enclave when the egress line requires it. They are the reasons to choose it deliberately, with the operating cost named, rather than as a reflex because in-house sounds safer. The organisations that run enclaves well are the ones that went in knowing it was infrastructure, not a subscription.

Where the pre-send check fits

The check itself is unchanged across every edition. VerbaPulse is a pre-send check for accidental risk: it reads a draft before it is sent and returns the sentences that create legal exposure, with the reason and a safer version. In an enclave the same engine runs inside your network, so the draft is analysed without ever crossing your boundary. It complements archiving and supervision rather than replacing them, and it is not an adversarial defence. Enclave is one of four deployment editions; it is the one for organisations whose answer to “where does the text go” is “nowhere”.

The takeaway

If your security review ends every tool evaluation with “but it cannot leave the network”, stop evaluating cloud tools against that line and name the requirement for what it is: no transfer, not a safer transfer. That single reframing tells you the edition before the first demo. Enclave is not the most secure version of a cloud product; it is a different architecture for organisations where the text stays home, and the earlier you classify yourself as one of them, the less procurement you waste discovering it at the end.