Trust by design: how you audit an AI workforce
Subatomic 101 series · Post 5 · Karl Simon, CTO
We’ve built the whole stack now — vocabulary, data foundation, cognition, architecture. This post is about the question that decides whether any of it survives contact with the real world.
Somewhere in your future there is a meeting. Maybe it’s a regulator doing an exam. Maybe it’s your biggest client, or their attorney. Somebody in that meeting is going to point at a decision your firm made — a recommendation, a flag that did or didn’t fire, a number that went out the door — and ask the oldest question in compliance: how did this happen, and who approved it?
If AI touched that decision, “the AI did it” is not an answer. It never will be. The firms that deploy AI well are the ones who can answer that question about a machine’s work exactly as crisply as they’d answer it about an employee’s work — this action, taken at this time, using this data, under this policy, and here’s the record.
Here’s the blunt version, and the expensive mistake this post exists to prevent: you cannot deploy what you cannot audit. Firms get this backwards constantly. They evaluate the AI on capability — how impressive the demo is — and treat auditability as a checkbox to sort out later. Later arrives in that meeting, with the regulator across the table, and by then the choice is already made. Trust is not a feature you add. It’s an architecture you either built or didn’t.
So let me teach the two pieces of the architecture that exist for exactly this, and then give you the questions to take into any vendor evaluation.
Deep Lens: seeing what your AI actually did
Software teams settled this argument a decade ago. Nobody runs production software today without observability — instrumentation that records what the system did, when, and why, so that when something matters you can reconstruct it instead of guessing. That discipline is why modern software is debuggable at all. It’s table stakes.
Then AI showed up, and somehow the standard got dropped. Firms are deploying systems that make judgment calls — the kind of calls that used to belong exclusively to people — with less instrumentation than their web server has.
Deep Lens is observability built for AI. Every action an AI Co-Worker takes is logged and traceable: what it did, what data it reasoned over, what it produced, and the chain from input to output. When the question comes — from a regulator, a client, or your own operations team wondering why Tuesday’s output looked odd — you don’t reconstruct from memory. You look.
The observability category itself is old and proven — Datadog, Splunk, New Relic built the previous generation of it for software infrastructure. Deep Lens is the modern successor to that old guard, built for how AI actually works: reasoning steps and decisions, not just servers and logs — and at a fraction of the cost those platforms command. It’s included when you hire the Subatomic Workforce, and it’s available standalone, pointed at whatever AI your firm already runs. Because the standard should be the same one software settled on ten years ago: if it’s in production, it’s observable. If your AI provider doesn’t include observability, that tells you something about how they expect the audit question to go.
Subatomic Shield: deciding what your AI is allowed to do
Observability tells you what happened. Shield decides what can happen.
Three things, each of which maps to a question your compliance officer already asks about humans.
Role-based access. A Co-Worker sees exactly what its role requires and nothing else — the same principle you already apply to people. The meeting-prep Co-Worker doesn’t have the run of the firm any more than a new analyst does. Access follows the job description.
Governance. The firm sets the rules — what requires human sign-off, what gets flagged, where the hard stops live — and the rules are enforced by the architecture, not by hoping everyone remembers the policy. Your compliance manual stops being a document people are supposed to have read and becomes constraints the system physically operates inside.
Your data never leaves the firm. The workforce comes to your environment; your client data doesn’t get shipped out to become someone else’s training set. For a regulated firm this isn’t a preference. It’s the difference between an AI strategy you can defend and one you can’t.
Trust by design
Notice the shape of all of this. None of it is a promise. There’s no “trust us” anywhere in it.
That’s the actual lesson of this post: in a regulated business, trust in AI can’t be a vendor’s claim or a model’s reputation. It has to be a property of the architecture — access constrained by role, behavior constrained by policy, every action leaving a record, data staying home. Built that way, the regulator meeting is a fifteen-minute records request. Built any other way, it’s an existential event.
And there’s an offensive version of this point that most firms miss: the firm that can prove what its AI does gets to deploy more of it. Auditability isn’t the tax you pay on innovation. It’s the license to keep innovating. Your most conservative stakeholder — the CCO, the examiner, the skittish client — becomes the reason you can say yes instead of the reason you always say no.
The questions to bring to any vendor
Whatever you’re evaluating — ours or anyone’s — put these on the table.
Can I see a complete record of every action the AI took, and reconstruct any decision after the fact? If the answer involves the word “roughly,” walk.
Is observability included, or an add-on? If auditability costs extra, the vendor has told you where it ranks.
What can the AI access, and who decides? You want role-based access you control — not a system with the master key.
Where does my data live, and does it train anything? “Your data never leaves your firm” is a complete sentence. Anything longer is a negotiation.
When your AI gets something wrong, how do I find out — and how fast? Every system errs. The difference between an incident and a catastrophe is whether you can see it.
Next in the series: the capstone — why the order you build all of this in is the strategy, and what it costs the firms that get the sequence wrong.