Compliance as an architecture constraint: AI for a Swiss fiduciary
In a regulated business, compliance isn't a layer you add after the AI works. It's the constraint that decides what the architecture is allowed to be. Here's how Swiss data and professional-secrecy law shaped every layer of an AI system we built for a fiduciary.
tsukumo
Short version: most teams treat compliance as paperwork you handle once the AI works. In a regulated business that order is backwards. The rules are not a checklist you apply at the end; they are the constraint that decides what the architecture is allowed to be in the first place. We build AI for a Swiss fiduciary, where the relevant law is not optional, and every serious legal rule turned into a concrete engineering rule. Designed in from the start, they cost a little. Bolted on after a security review, they force a rebuild.
What does "compliance as a constraint" actually mean?#
It means the law is an input to the design, the same way latency and cost are.
A CTO would never add performance "later." It shapes the architecture from the first decision. Regulatory constraints work the same way for a regulated client. Professional secrecy decides what data may flow to a model at all. Data-protection law decides where it can be processed and how long it lives. The mandate contract decides who is accountable for an action the system takes. If you design with those as fixed constraints, the AI fits inside the law. If you design for capability first and add compliance later, you discover the rules forbid the architecture you already built.
For this client, three bodies of Swiss law did most of the shaping: the data-protection act, the rules governing the client mandate, and professional secrecy. Here is how each one became code.
The default answer is no. The system acts only when a rule explicitly allows it.
In a normal app, an ambiguous case might get a best-effort guess. In a fiduciary context, a confident wrong action is worse than a refusal, because the wrong action touches someone's confidential affairs or their books. So the system is built to fail closed. If an agent is unsure whether a document is in scope, whether a tool is permitted for this user, or whether an operation is allowed, it stops and escalates rather than proceeding.
This inverts the usual default and it is deliberate. A model optimizes for being helpful, which means it leans toward doing something. The deterministic layer around it leans the other way, toward doing nothing unless permission is explicit. That tension is the safety.
If the AI did it, there is a record of it. No exceptions.
Accountability under a mandate means someone has to be able to answer "why did the system do that," after the fact, precisely. So every action the AI takes through a tool is logged: who triggered it, what it touched, what the inputs were, what came back. This is not an afterthought bolted onto a finished system; it is built into the tool layer, so an unaudited action is not possible to take rather than merely discouraged.
The payoff shows up the first time a client asks a hard question, or a reviewer does. You answer from the log, not from memory.
The system pauses, by design, exactly at the steps you cannot take back.
Reversible work runs on its own. But anything irreversible or externally visible, a payment, a filing, a communication to a third party, stops for a human. The deterministic layer knows which transitions those are, so the pauses land in the right places instead of asking a person to supervise everything. This is what makes human-in-the-loop sustainable in a regulated setting: oversight concentrated where the law and the risk actually are.
Sensitive data is controlled where it enters and leaves the model, not by trusting the model to be careful.
Personal and confidential data is detected and handled at the boundary of the AI system. What may be sent to a model, what must be redacted or kept out, and what may be stored is decided by deterministic guards around the model, not by the model's own judgment. The principle is the same one that runs through the whole design: never rely on the model to enforce a rule that the law requires you to guarantee.
One client's data cannot reach another client's request, because the boundary lives below the model.
A fiduciary serves many clients, and professional secrecy means their data must never cross. So every retrieval, query, and tool call is scoped to a single tenant by code in the data-access layer. A request about client A physically cannot read client B's records. The model never sees cross-tenant data, which means it cannot leak what it never had. Isolation enforced beneath the model is the only kind you can actually promise.
Pulled together, these constraints look like friction. In practice they are what makes the system shippable at all.
| Designed in from day one | Bolted on after a review | |--------------------------|--------------------------| | Fail-closed is the default behavior | Every ambiguous path is a potential incident | | Audit is a property of the tool layer | Audit is reconstructed, incompletely, after the fact | | Tenant isolation is structural | Isolation depends on the model behaving | | Passes a client security review | Triggers a rebuild before it can launch |
For a regulated buyer, fail-closed behavior, complete audit, and hard isolation are not nice-to-haves. They are the entry ticket. A system without them does not get deployed, no matter how capable the model is. Building them in first is not the slow path. It is the only path that reaches production.
If you are putting AI into a regulated business, healthcare, finance, legal, accounting, start from the constraints, not the demo. Write down what the law forbids, turn each rule into a deterministic guard, and design the architecture around those guards. The model is the easy part. The shell that keeps it lawful is the work, and it is exactly the kind of work that decides whether a regulated client can use AI at all.
That is the work we do, and we learned it where the stakes are real. If your team is trying to bring AI into a regulated environment without betting the licence on it, talk to us.
What does 'compliance as an architecture constraint' mean?
It means you treat legal and regulatory rules as inputs to the system design, not as a checklist applied after it's built. The same way latency or cost shapes architecture, professional secrecy and data-protection law shape which data can flow where, what the AI may do unsupervised, and what must stop for a human. Designed in, they're cheap. Bolted on, they force a rebuild.
What does 'fail-closed' mean for an AI agent?
Fail-closed means the default answer is no. If the agent is unsure whether it's allowed to do something, whether a document is in scope, or whether a tool is permitted for this user, it stops rather than guesses. In a regulated context a confident wrong action is worse than a refusal, so the system is built to refuse by default and act only when a rule explicitly allows it.
How do you keep client data isolated in a multi-tenant AI system?
Every query, retrieval, and tool call is scoped to one client (tenant) by deterministic code, not by asking the model to stay in its lane. A request for client A can never read client B's data because the data access layer enforces the boundary below the model. The model never sees cross-tenant data, so it cannot leak what it never had.
Does compliance slow an AI project down?
Upfront, a little; overall, it speeds you up. Designing for fail-closed, audit, and tenant isolation from day one is far cheaper than retrofitting them after a review, an incident, or a client security questionnaire. For regulated buyers, these properties are also what makes the system shippable at all, so they're not overhead, they're the entry ticket.
