Ask a regulated team whether they’ve turned on AI and you usually get one of two answers. Either it’s locked down so hard it can’t do anything useful, or it’s running loose in a corner where no one is looking. Both come from the same mistake: treating governance as a gate — a single switch that is either open or shut. The systems worth building don’t have a switch. They have a dial.
A gate forces a false choice. Open it and you inherit risk you can’t see; keep it shut and the work never gets done. Neither is a real answer for a business that has to both move and stay compliant — so most of them freeze. A pilot that never ships. An AI tool quietly banned. A policy that says “not yet” for two years. The gate didn’t make anyone safer. It just moved the decision to “never.”
Highest-grade by default, relaxed by configuration#
We build to the strictest bar we can imagine — the forensic one, where every action, every touch, every decision by a person or a machine is recorded so it can be reviewed and trusted later, the way evidence is. That is the top of the dial. Then, for any given setting, we turn it down to exactly what the work needs. The strongest control is always there; how much of it is switched on is a configuration — chosen per industry, per domain, per kind of work — not a different product, and not a rebuild.
That is the whole difference. A gate asks “in or out.” A dial asks “how much, and where,” and answers it per context without changing the machine underneath.
One platform, many postures#
A forensic lab and a marketing team do not need the same amount of control, and pretending they do is how you end up with a product too heavy for one and too loose for the other. On our platform they run the same system at different settings. The lab turns the dial to the top: full traceability, nothing unlogged, every step defensible in front of an auditor. The marketing team runs it low — the guardrails that matter, none of the friction that doesn’t. A factory floor sits somewhere in between. Same building, different rooms: the feeling stays consistent, the control is tuned.
That consistency isn’t a nicety. It is what lets a company grow into new kinds of work without relearning the tool or re-earning trust every time.
Why this is an architecture question, not a policy one#
Anyone can write a policy that says “be more careful in regulated settings.” The hard part is making the careful version and the light version the same system, so moving between them is a setting change and not a six-month project. If tightening control means forking the product, you don’t have a dial — you have two products and a maintenance bill, and in practice the strict one never gets built. So we treat “cheap to reconfigure” as a first-class requirement: minimal effort now, effectively zero over time. A control you can’t turn up without a rebuild is not a control you really have.
The failure mode is worth naming precisely, because it is common and it does not look like a failure at the time. A team ships the light version first, because that is the version customers ask for. The strict version becomes a roadmap item. The roadmap item becomes a branch. The branch drifts, because the light version keeps shipping and the strict one does not. Eighteen months later there are two codebases, one of them behind, and the answer to “can you run this in a regulated setting” is a services engagement. Nobody decided that. It is simply what happens when the difference between postures is expressed as code rather than as configuration.
Which direction the default points#
There is a second decision inside this one, and it is the one that actually matters: which end of the dial you build first.
Building the loose version first and hardening it later is the intuitive order — it ships sooner and demos better. It also almost never arrives. Every control added afterwards has to be retrofitted through paths that were designed without it, and each retrofit is a negotiation with code that already works. Building the forensic version first and relaxing it is harder at the start and cheaper for ever afterwards, because relaxing a control is a matter of not requiring it, while adding one is a matter of finding every place it should have been.
So the default points at the strict end, and every relaxation is deliberate, named, and recorded as a setting. That has a useful side effect: a customer can be shown their own configuration. “This much proof, here, for this work” is a sentence with a value in it, and a value can be reviewed. “We take security seriously” cannot.
The objection worth taking seriously#
The fair criticism is that a dial can be turned all the way down, and a vendor who ships one has handed the customer a way to configure the governance away. If it can be relaxed, someone will relax it, probably under deadline.
That is true, and it is why the dial has a floor rather than an off position. Some controls are not settings: tenant isolation, the audit record itself, and the fact that data does not leave the walls hold at every position. What varies is how much is required, reviewed and retained — not whether anything is recorded at all. A configuration that could switch off the record would not be a lower setting on the same dial. It would be a different product, which is the thing this whole argument exists to avoid.
The second objection is that “configuration” is where complexity goes to hide, and a system with enough settings is one nobody understands. Also fair. The answer is that the settings are few, named in plain words, and versioned — the same discipline we apply to vocabulary. A dial with two hundred positions is not a dial; it is a maze with a nicer name.
How to check this in someone else’s product#
The question that separates a dial from a gate is not “is it configurable.” Everything is configurable in a slide. Ask instead what it costs to change: can the vendor move a deployment from a light posture to a forensic one without a code change, and will the same test suite pass in both? Ask which controls hold at every setting, and get the list. Ask to see the configuration for an existing customer — not their data, just the shape of their settings.
A vendor with a real dial finds these easy and slightly boring. A vendor with a gate and a roadmap will answer with a timeline.
This is what finally lets a regulated team say yes. Not “AI, on or off,” but “this much proof, here, for this work — and we can show you the setting.” Governance stops being the thing that blocks AI and becomes the thing that lets you turn it on, deliberately, at exactly the level the work deserves. A dial, not a gate.