Shipping AI into regulated systems
What changes when your chatbot or agent has to pass a compliance review — and how to design for it from day one.
Most AI demos die on contact with a compliance review. The model works in the demo; the deployment around it doesn’t. Audit trails are missing, prompts aren’t versioned, data residency is an afterthought, and there’s no answer to the one question every reviewer asks: what did the system decide, and why?
Shipping AI into a regulated environment — healthcare, finance, legal — isn’t a harder version of building a chatbot. It’s a different job. The model is maybe 20% of it. The other 80% is the boring, unglamorous engineering that lets a careful organisation actually put the thing in front of users.
Design the answers in from the start
You can’t bolt compliance onto a finished AI feature. The properties a reviewer cares about have to be architectural decisions made early:
- Versioned, config-driven prompts. Prompts are part of your system’s behaviour. They belong in version control and config, not hard-coded in a function, so you can review, diff, and roll them back like any other change.
- An audit trail for every decision. Each AI interaction should write a record: the input, the prompt version, the model output, and what happened next. When someone asks why the system did something six weeks ago, you need a real answer.
- Tenant isolation at the database. In multi-tenant healthcare or fintech products, isolation enforced in application code is a bug waiting to leak data across customers. Enforce it at the data layer.
- A clear line between suggest and decide. The safest pattern in regulated settings is AI that proposes and a human who approves. Make that boundary explicit in the product, not implicit in good intentions.
Evaluation is not optional
A demo proves the model can succeed once. Production requires knowing how often it fails, and how badly. Before anything ships, we build an evaluation set from real cases and measure against it — so “the AI got better” is a number, not a vibe. After launch, the same harness catches regressions when a model or prompt changes.
Guardrails are part of the product
Inputs get validated. Outputs get checked against rules before they reach a user. Sensitive actions get gated. None of this is exciting, and all of it is the difference between an AI feature that survives a security review and one that gets quietly switched off after the first incident.
The unglamorous version is the one that ships
It would be more fun to write about clever prompting. But the projects that make it into production in regulated industries aren’t won on cleverness — they’re won on the discipline around the model: review, audit, isolation, evaluation, and a human in the loop where it counts.
It’s less glamorous than the demo. It’s also the only version that ships.
Have a project like this?
Start a project →// more insights
Building software for the Swiss market
Multilingual by default, local payments, government integrations, and data residency — what it actually takes to ship for Switzerland.
Dedicated team vs. agency: when staff augmentation wins
Embedded engineers and the traditional agency model solve different problems. Here's how to tell which one you actually need.