NotesSeptember 4, 202610 min read

A rule is a promise. An architecture is a fact.

The professions built on secrecy are covered in rules about their data. What they lack is the architectural reflex: run it in-house, self-host, copy nothing elsewhere. What that means, and what it costs.

Two-column diagram: on the left, a file sent to a vendor’s server and on to its subprocessors; on the right, the same file staying inside the organisation’s walls.

Few professions have written as much about protecting their data as the ones that live on secrecy. A doctor, a lawyer, an accountant, a banker, a notary, an agency holding its clients’ credentials and accounts: each has a code, a professional body or a regulator, a duty of confidentiality that criminal law enforces [1], and since 2018 a European regulation that lets them entrust data only to processors “providing sufficient guarantees” [2]. Over the past two years, artificial intelligence has in turn produced guides, charters, recommendations from authorities, model clauses.

Yet ask any of these firms one simple question: when a member of staff submits a document to an AI tool, on which machine does the model run, and who owns it? In most cases, nobody knows. The regulation is dense. The architecture is missing.

This piece is about that gap, and about why one more rule will not close it.

The framework exists, and the right people wrote it.

Start with what is going well. The guides published by professional bodies and regulators over the past two years are, for the most part, serious documents. They forbid sending an AI tool the name of a client or a patient, a confidential detail, a document from the file. They require every output to be checked. They list what makes a tool acceptable: where it is hosted, the provider’s nationality, encryption, no reuse of the data. They recommend an internal charter.

Data protection officers, specialist lawyers and compliance leads spend their weeks writing down what an organisation may do, what it must forbid, what it must document. That work is necessary, and at Helmo Solutions we try to contribute to it in our own place, with texts that turn those frameworks into concrete decisions. We are not lawyers. Our trade is elsewhere, and that is where this piece comes from.

Because all of that framework shares one nature. A charter, a privacy policy, a no-reuse clause, a certificate of European hosting: these are commitments. Texts that describe what is supposed to happen. They bind whoever signs them. They do not decide what actually happens inside the machine.

A rule is a promise. An architecture is a fact.

A rule says what will be done with the data once it is somewhere. It asks you to trust whoever holds it: their security team, their subprocessors, their jurisdiction, every future decision they will make about their business.

That trust breaks in four ways that have nothing to do with the good faith of whoever signed. A breach. An acquisition by a company from another country. A compliance shortcut taken on a busy day. An order from a foreign authority, which US law has allowed since 2018 regardless of where the server sits [3]. In all four cases the clause is still there. It simply prevented nothing.

These clauses have one thing in common: none of them can be verified by the party signing. “We do not use your data to train our models” is a sentence you read; you have no way to test it. The regulation asks you for sufficient guarantees, and all you can produce, if asked, is a statement from your provider.

An architecture decides something else: whether the data is anywhere at all. A server that never received the file cannot leak it, whatever happens to its owner. And that, you can verify yourself.

A profession whose daily work is telling an established fact from a statement should be the first to see the difference. A contract with a vendor is a statement. A machine inside your walls, with no outbound connection, is a fact.

The reflex exists elsewhere. It has not reached you yet.

In the fields the Helmo Solutions team comes from, AI infrastructure, video surveillance, permission systems, one rule is taken for granted: any server you do not control is a risk by default, and the first question asked of a tool is not “what does the vendor promise” but “can we run it in-house”. That culture has a name, self-hosting, and an ecosystem: software whose code is public, that you install on your own machines, that you audit, and that keeps working the day the vendor disappears.

That ecosystem now covers most of what an organisation asks of artificial intelligence. Transcribing a consultation or a meeting. Summarising an email thread. Searching your own archives. Pulling the dates and amounts out of a set of documents. Pseudonymising a file before sharing it. For each of these tasks there are open-code tools and models that run on a desktop machine without sending a single byte out.

The professions of secrecy, meanwhile, have stayed in the opposite culture: the tool is a service you subscribe to, the data goes wherever the vendor puts it, and the protection lives in the contract. That is not a lack of seriousness, it is a lack of exposure. Nobody has shown them that the other culture exists, that it is mature, and that it serves their duty of secrecy better than any clause. That, in our view, is the missing awareness, and it is missing precisely in the professions that would use it most.

Why these professions, more than others.

Two reasons make the gap between rule and architecture more expensive for a professional bound by secrecy than for an ordinary company.

The first is legal. Professional secrecy cannot be contracted away. A confidentiality clause signed by a vendor binds the vendor; it does not turn a disclosure into a non-disclosure. Whoever revealed information covered by secrecy revealed it, however good the contract that was supposed to prevent it [1].

The second is human. A company that suffers a breach manages an incident. A doctor, a lawyer, an accountant who sent a file to a server they do not control answers personally, before their professional body or regulator, for what was done with it. The vendor’s promise does not appear in their place.

What “on-premise” means, and what it does not.

The word has become a brochure argument. So it needs defining.

A local deployment, as Helmo Solutions practises it, meets three conditions. The model runs on a machine the organisation owns or controls. No copy of the data passes through a third-party server: not the documents, not the requests, not the technical logs, not the “convenience” backups at the vendor. And the organisation can verify it for itself, by unplugging the network and watching everything keep working.

What it is not deserves saying too. “Hosted in Europe” is not enough: a vendor’s shared server located in Europe is still a server you do not control, and the nationality of the company operating it matters as much as the location. What matters is who owns the machine, who holds the keys, and whether it is shared. “End-to-end encrypted” is not local: the model has to read the text in the clear to work, and it does so wherever it runs. “Your data is not used for training” is not local: it is precisely the promise you cannot verify.

There is a simple way to put it. In a local deployment, your AI provider is you.

Open weights and open licence are two different questions.

Becoming your own provider means being able to download a model and run it. Several allow it today. But “open” covers two distinct things, and both questions need asking.

The first is technical: are the model’s weights published? If so, the model can run on a machine you own, with no network call. That is what is called an open-weight model.

The second is legal: under which licence? Some open-weight models are released under the Apache 2.0 licence, which allows use, modification and redistribution with no condition of size or sector [4]. Others are released under the vendor’s own licence, which restricts certain uses and can change from one version to the next. The Open Source Initiative published a definition of open source AI in October 2024 precisely to tell the two apart [5].

Why care: because the licence is the only promise left in a local deployment, and it had better be irrevocable. A model under Apache 2.0, downloaded today, will still be usable in ten years on the same terms, whatever happens to its publisher. You pin the version, you audit it, you record it in your register, and nobody can take it away from you. That is a guarantee of architecture, not of contract.

What it costs, and why it is our trade.

Be honest about the price, or this piece is one more brochure.

A local deployment has a real cost: a machine sized for the model, its backups, its updates, control of physical access to it. Open-weight models run a few months behind the best closed models [6]. On an organisation’s tasks, sorting correspondence, pulling the dates out of a set of documents, preparing a sourced summary, that lag does not show. But the risk has not gone away, it has changed nature: from a legal risk you do not control to an operational risk you do.

That is also why the self-hosting culture did not walk into these professions on its own. It needs someone who can size the machine, choose the model and its licence, install it with no outbound connection, log access, write the update procedure, and hand the organisation the documentation that lets it do without them afterwards. A firm of two to twenty people does not have that person, and should not have to.

That is exactly the work we do at Helmo Solutions: on your hardware, or on a dedicated server hosted in Europe, one per client, that we operate for you. We come from companies where AI infrastructure and permission systems were the product itself. That know-how is not written into a charter. It gets installed.

Want to know what it would look like at your firm?

One scoping conversation is enough to say whether a local deployment is justified in your case, including when the honest answer is no.

Contact

The rule says what should happen. The architecture makes it happen.

This is not about setting the two against each other. An organisation needs both, and in that order.

The charter sets the permitted uses, trains the staff, documents the decisions, provides for oversight. Without it, the most watertight architecture gets used any old way. That is the work of the people who frame the professions, and it is done well.

The architecture, for its part, means the charter no longer has to be believed. When the data never leaves your walls, the ban on sending a file to a third-party server is no longer a rule to follow: it is a state of affairs. Nobody can break it on a busy evening, nobody can renegotiate it, no foreign jurisdiction can get around it.

The professions of secrecy have finished writing their rules, or nearly. What remains for them to do cannot be written. It gets built, one machine at a time, in every firm that decides its files are protected by how it is equipped, and not by what it was promised.

Notes

  1. French Criminal Code, article 226-13: disclosure of secret information by a person entrusted with it by status or profession is punishable by one year’s imprisonment and a €15,000 fine.
  2. Regulation (EU) 2016/679, article 28(1) (use of processors providing sufficient guarantees) and article 32 (security of processing). Applicable since 25 May 2018.
  3. Clarifying Lawful Overseas Use of Data Act (CLOUD Act), 23 March 2018.
  4. Apache License, version 2.0, Apache Software Foundation, January 2004. Examples of models released under it: Mistral Small 3 (Mistral AI, January 2025); gpt-oss (OpenAI, August 2025).
  5. Open Source Initiative, “The Open Source AI Definition”, version 1.0, 28 October 2024.
  6. Epoch AI, capabilities index, tracking of the gap between open-weight and closed models, 2026 data.
contact

Describe your situation in a few lines, no commitment. One conversation is enough to know whether there's a system worth building, and which door to take first. Or send me a message.