AI and Swiss Law Firms: What Attorney-Client Privilege Changes in the Technical Architecture

Since the Swiss Bar Association (FSA) adopted guidelines on lawyers’ use of artificial intelligence in June 2024, the question for Swiss firms is no longer whether to use AI, but how. Translation, analysis of large document volumes, due diligence, internal investigations, summarizing and improving text: the use cases are already identified by the profession itself.

But most consumer-grade generative AI tools weren’t built for a field where disclosing confidential information is a criminal offense, not just poor practice. For a Swiss law firm, plugging an AI agent into client files isn’t a technical decision like any other — it’s a decision that may carry the responsible lawyer’s criminal and disciplinary liability.

This article breaks down what attorney-client privilege actually changes in an AI system’s architecture, and which configurations make it possible to build an architecture compatible with those requirements.

1. Professional secrecy isn’t a precaution, it’s a criminal offense

Article 321 of the Swiss Criminal Code isn’t a matter of professional ethics or best practice — it’s a criminal statute. It covers lawyers registered with the bar and their auxiliaries who reveal a secret entrusted to them in the course of their profession. The penalty, prosecuted on complaint from the injured party, goes up to three years’ imprisonment or a monetary penalty.

That last point deserves emphasis: the article explicitly covers auxiliaries. The fact that article 321 also targets auxiliaries makes it particularly important to analyze the role of technical providers: when a vendor takes part in processing information covered by professional secrecy, the firm needs to determine precisely what data it can access, under what conditions, and on what contractual basis.

On top of that, Switzerland’s revised data protection act (nFADP) provides for criminal sanctions that can reach CHF 250,000, targeting the individual personally responsible in the cases the law defines. Both regimes stack and point the same direction: a law firm’s technical architecture isn’t an implementation detail, it’s a matter of criminal compliance.

2. Why an external AI tool should never be treated as routine

Using an external AI tool to process information covered by professional secrecy can’t be treated as routine: it requires checking the subcontracting framework, the vendor’s data access, where the data is stored, the contractual guarantees, and, depending on the case, the client’s informed consent. That’s not an automatic ban — it’s an analysis to run before deployment, not after.

The usual instinct is to look for a provider hosting its servers in Europe or Switzerland for peace of mind. That’s not enough on its own. The US Cloud Act, passed in 2018, provides that a company subject to US jurisdiction can be compelled to produce data under its control, regardless of where that data is physically stored — the US Department of Justice itself describes this principle explicitly. Datacenter location alone isn’t enough to determine an infrastructure’s legal exposure. What also matters is the operator’s identity, the companies that control the service, the jurisdictions they’re subject to, and the contractual terms governing data access.

That distinction changes how a Swiss firm should evaluate an AI tool: the datacenter’s geography is one factor among several, not a guarantee on its own.

3. What the FSA guidelines provide for

The guidelines adopted by the Swiss Bar Association in June 2024 don’t close the door on AI — they set out three paths for framing AI use in light of professional secrecy.

The first is software installed in situ, on the firm’s own network, with no data leaving the premises. It’s the legally safest option, but it requires infrastructure and technical expertise that few firms have in-house.

The second allows using an external provider, provided strict subcontracting rules are respected: determining who can access the data, where it’s stored and what happens to it, with contractual guarantees equivalent to professional secrecy itself. The guidelines additionally recommend anonymizing confidential information before it’s processed by an AI system wherever feasible, and encourage each firm to establish its own internal guidelines.

This anonymization doesn’t have to be manual. Open-source tools like Microsoft Presidio automate detection and anonymization or pseudonymization: they identify names, addresses, IBANs, case numbers, or other identifiers in a piece of text and replace them with tokens before it’s sent to an AI model. An application layer built around the tool can then map those tokens back to the original data when that’s needed — Presidio itself doesn’t provide that restoration capability on its own; it depends on how the surrounding system is built. In practice, this detection step sits between the firm and the AI provider: the prompt reaching the provider then carries less directly identifying information. It’s a technical layer that complements — without replacing — contractual control over the data flow.

The third, used more rarely, allows for a waiver of secrecy with the client’s informed consent for a specific use — an option that needs to be documented as rigorously as the first two, not treated as a shortcut.

In this context, unmanaged use of a consumer AI tool can’t be treated as a sufficient solution, whatever its benefits in speed or drafting quality.

4. The architectures available, concretely

For a firm that wants to go beyond classic in-situ software, two approaches stand out today.

The self-hosted, open model. Models like Llama, Mistral, or Apertus can be deployed on infrastructure fully controlled by the firm or by a Swiss provider, with no data sent to a third-party operator. Apertus deserves particular attention: developed by EPFL, ETH Zurich, and the Swiss National Supercomputing Centre, trained on the Alps supercomputer in Lugano, it’s released in 8 and 70 billion parameter versions under an Apache 2.0 license — architecture, training data, and model weights documented and accessible. Its openness and the ability to deploy it on infrastructure the firm controls make it a particularly interesting option for designing sovereign AI architectures in Switzerland. Open and self-hostable doesn’t mean compliant on its own: it’s the architecture built around the model — access, storage, contracts — that determines compliance, not the model alone.

The Swiss provider under strict contract. Hosts like Infomaniak or Swisscom allow deploying these models on Switzerland-based infrastructure, with contractual and technical guarantees strictly limiting the operator’s access to the data. This option suits firms that don’t want to manage infrastructure themselves while keeping legal control over who has access to what.

In both cases, the goal is to keep the data within a perimeter whose access, data flows, and contractual terms the firm controls — unlike unconfigured use of a general-purpose API.

5. The real issue: isolating data before the model even enters the picture

Picking a model — Apertus, Mistral, Llama, or otherwise — is only part of the problem. The more decisive question sits upstream, in the application architecture built around that model: how documents get ingested, indexed, and above all, who can access what.

An AI system applied to a law firm typically relies on a full chain — document ingestion, OCR, anonymization or pseudonymization, classification, indexing, embeddings, a vector database, RAG (retrieval-augmented generation), then the model itself — before access control and logging even enter the conversation. The key point, often overlooked: the model should never have unfiltered access to the firm’s entire document base. A well-designed architecture isolates document spaces by case and by lawyer, so that one lawyer’s query on their own case never surfaces, even indirectly, information from a case they don’t have access to.

On top of that come concrete technical requirements: encryption of documents at rest and in transit, a contractual guarantee that client data is never used to train or retrain a third-party model, a retention and deletion policy defined in advance, and environment isolation between firms if the infrastructure is shared at a provider. It’s this application layer — not the choice of LLM — that determines whether an AI architecture genuinely respects professional secrecy.

6. What can be automated without touching professional secrecy

Not every task at a firm involves protected information. Administrative management — reception, scheduling, invoicing, follow-ups, calendar organization — can rely on standard automation tools, including consumer-grade AI agents, without exposing professional secrecy, as long as no case-related information passes through them.

This distinction breaks down into three levels, useful for prioritizing a rollout:

• Level 1 — Non-sensitive data (reception, scheduling, invoicing): standard automation, with the applicable data protection controls.
• Level 2 — Data internal to the firm (general research, drafting unrelated to a specific case): external AI possible with contractual guarantees and control over data flow.
• Level 3 — Data covered by professional secrecy (content of a client file): tightly controlled architecture — in situ, sovereign infrastructure, or documented informed consent, depending on context.

It lets a firm start by automating what carries no risk, before investing in a heavier architecture for drafting assistance or case research. It’s the same logic we apply to business software automation in other sectors: map precisely what’s sensitive before deciding what can be automated, and how.

7. Why custom architecture beats a generic tool

The market is starting to offer packaged AI solutions for law firms, promising off-the-shelf compliance. The same principle we detail in our article on Lovable and custom development applies here: using technology that’s compliant on paper isn’t enough to produce an architecture genuinely suited to a specific firm, with its case volumes, practice areas, and internal organization.

A business law firm handling large-scale due diligence doesn’t have the same needs as a family law practice. What must stay in situ, what can be outsourced under strict contract, and what can be automated without special precaution — that’s defined case by case, not through a generic subscription. It’s a matter of architecture and technical modernization as much as it is a matter of law.

This article isn’t legal advice: final compliance for a given firm remains a matter to validate with its cantonal bar association or specialized legal counsel. Our role is limited to designing and implementing the technical architecture that makes that compliance possible.

8. Comparing AI architectures for a Swiss firm

No architecture is “compliant” by nature: compliance depends on the whole system — data, access, contracts, subcontractors, storage, governance. This table positions each option by what it enables, not by a legal status assumed in advance.

9. Conclusion: architecture before the tool

Artificial intelligence has real value for a Swiss law firm — time saved on research, drafting, and administrative work. But professional secrecy isn’t a checkbox, it’s a criminal offense that can directly implicate the responsible lawyer.

The question, ultimately, isn’t choosing between ChatGPT, Mistral, Llama, or Apertus. The real challenge is designing a custom architecture in which the model only has access to the data it needs to process, inside an environment where the data flows, access rights, and responsibilities are all under control — rather than buying a generic product.

Sources

• Swiss Criminal Code, art. 321 — Fedlex, official federal law database
• FSA guidelines on the use of AI (June 2024), Swiss Bar Association
• CLOUD Act White Paper, US Department of Justice
• Apertus: a fully open, transparent, multilingual language model, ETH Zurich press release
• Microsoft Presidio, open-source repository