← All posts
AI & Email Compliance

Cloud, Sovereign, Enclave, Black: four ways to deploy a compliance check, and when each fits

October 15, 2026 · 7 min read

Partway through a procurement review, a bank’s security team usually asks one question that decides everything that follows: where does the text go? Not where is it stored, not is it encrypted, but at the moment your tool reads an employee’s draft, does that draft leave our network, and if so, which network does it land in? The answer to that single question determines which way a compliance tool can be deployed, and for a regulated organisation it is often the first filter, applied before anyone looks at detection quality or price.

It is worth separating the question cleanly, because vendors tend to blur it. “Cloud” and “on-premise” are not two options on a spectrum of trust. They are answers to a legal question about data movement, and that question has more than two answers. A communication compliance check can run in four distinct places, and the right one depends entirely on what your data is allowed to do.

The constraint that actually drives the choice

For most regulated organisations the deployment decision is not a preference, it is a transfer question. Under the GDPR, moving personal data outside the EU or EEA is a restricted transfer governed by Chapter V: Article 44 sets the general principle that a transfer may only happen under the chapter’s conditions, and Article 46 is where standard contractual clauses and other safeguards live when there is no adequacy decision. In Turkey, the parallel is Article 9 of the KVKK, which treats transfer of personal data abroad as its own regulated act with its own conditions.

An employee’s email draft is personal data, often about a third party. The moment a compliance tool sends that draft to a model hosted in another country, the organisation has made a cross-border transfer and has to stand behind it: the right clauses in place, the right notice given, the transfer defensible if a regulator asks. For many firms that is manageable with contracts. For some, a bank under local supervision, a firm handling special-category data, a public body, it is a line they will not cross at all. The text simply cannot leave.

That is why “run it in the cloud” is a complete answer for one organisation and an instant disqualification for another. The four deployment editions below exist to answer that one question at four different levels of strictness.

The four editions, and what each one answers

The important thing is that the detection engine is the same in all four. What changes is where it runs, where the data goes, and who operates it.

Edition Where it runs Where the text goes Who operates it Answers the question
Cloud Our EU environment Processed in the EU, message content not stored; the event record is kept, not the text Us “We can use EU cloud, we just need it in the EU and not retained.”
Sovereign Your own cloud tenant or data centre Stays inside your cloud boundary, under your subscription You, with our support “It can be cloud, but it has to be our cloud, under our control.”
Enclave Your network, no external egress Never leaves your network; the model runs on your hardware You, with our support “The text cannot leave our network at all.”
Black Fully isolated, air-gapped No connection in or out; offline licence and updates You “The environment has no internet, and that is a hard requirement.”

Read top to bottom, each row removes one more assumption about connectivity. Cloud assumes you accept EU processing by a vendor. Sovereign removes the vendor’s environment but still assumes cloud. Enclave removes external egress entirely. Black removes the network itself.

Cloud

The default for organisations whose constraint is location and retention, not egress. Processing happens in the EU, the message content is not stored, and what remains is the event behind the reporting: the rule that fired, the outcome, the department, the time. For a firm whose requirement is “keep it in the EU and do not keep the text”, this is the whole answer, and it is live in minutes.

Sovereign

For organisations that accept cloud but not a third party’s cloud. The engine runs inside the customer’s own tenant or data centre, within their boundary and their controls. The data never enters a vendor environment. This fits firms with a strong internal cloud posture and a policy that says anything touching customer data runs under their own subscription.

Enclave

For organisations where the text cannot leave the network. The model runs on the customer’s own hardware, inside a closed deployment with no external egress. This is the edition that answers the bank security team’s question with a flat “it never leaves”. It is the right fit where cross-border transfer is not a contract to manage but a line that cannot be crossed, and where the organisation can host the model internally.

Black

For environments that have no internet by design: defence, critical infrastructure, the strictest banking enclaves. Everything is isolated, licensing is offline, and updates arrive as signed packages carried in rather than pulled down. Black is not Enclave with extra marketing; it is a different operational model, because an air-gapped environment changes how every update and licence check works. An organisation that merely wants the text to stay internal wants Enclave. Black is for the organisation whose environment is sealed.

A short decision path

Three questions place almost any organisation on the right edition:

  1. Can the text be processed in EU cloud by a vendor, if it is not retained? If yes, Cloud. Most commercial firms stop here.
  2. If it must be cloud but your own, can it run in your tenant? If yes, Sovereign.
  3. Must the text never leave your network? If yes, Enclave, or Black if the environment is air-gapped.

The reason to settle this early is that it is the cheapest decision to get right at the start and the most expensive to get wrong late. A procurement process that reaches contract on a cloud assumption, then discovers at the security review that the text cannot leave the network, restarts. Asking “where does the text go?” in the first conversation saves the quarter.

Where the pre-send check fits

Across all four editions the job is the same: read a draft before it is sent and return the sentences that create legal exposure, with the reason and a safer version. It is a pre-send check for accidental risk, the careless line a well-intentioned employee does not notice, and it complements archiving and supervision rather than replacing them. What the editions change is not what the check does, but whether the draft it reads ever crosses your network boundary. For a firm that can use cloud, that is a convenience. For a firm that cannot, it is the difference between a tool it can buy and one it cannot. The deployment model is how the same check becomes available to both.

The takeaway

Before you evaluate any communication compliance tool on detection or price, answer one question in writing: at the point of analysis, is your text allowed to leave your network, and if so, to whose. Take that answer into the first vendor conversation. It tells you in one sentence whether you are a Cloud, Sovereign, Enclave, or Black organisation, and it stops you from running a procurement process that the security review will later send back to the start. The detection engine can be identical. The deployment has to match your data’s permission to move.

See how VerbaPulse flags risk before an email is sent, right inside Gmail and Outlook.

See VerbaPulse in action →
← Deleting emails after the duty starts: obstruction, preservation, and the notice that prevents it What a cloud compliance check keeps, and what it never sees →