In “Governance Isn’t a Policy. It’s an Architecture Decision,” TLCx Chief Technology Officer DeJon Gaines pushes back on how most companies think about AI governance. Most conversations about it happen way too late — after the AI is already live, usually kicked off by a regulator’s question, an audit finding, or a customer complaint that exposes a gap nobody thought to check for beforehand. DeJon Gaines says that order is backwards, and it’s quickly becoming the real thing that separates vendors who are actually ready for regulated buyers from vendors who’ve just said they are.
He draws a clear line between two approaches. Governance by design means the architecture itself enforces the rules — what data a model can see, what decisions it can make on its own versus hand off to a person, and what audit trail exists for everything it does. Governance by policy means relying on documents, training sessions, and catching problems after they’ve already happened to a real customer, patient, or citizen. DeJon Gaines is blunt about why this matters: a system built for governance from the ground up can prove compliance to an auditor on demand, with evidence. A system governed only by policy layered on top can only promise compliance and hope people are actually following it. One’s an engineering guarantee. The other’s a hope.
For anyone buying AI in a regulated space — banking, healthcare, government — DeJon Gaines lays out three questions that need to be part of vendor evaluation, not something left for legal review after the technical decision’s already made:
- Data access boundaries — what can the model actually see, and what’s it structurally blocked from seeing? Not by policy. By design.
- Audit trail on demand — can the vendor produce a complete, verifiable trail for a specific decision from six months ago, right now, for a regulator?
- Uncertainty escalation — when the system genuinely doesn’t know the right answer, does it hand off to a human, or does it just proceed and log what happened?
DeJon Gaines is clear these aren’t questions a sales team can answer off a slide deck. He backs this up with a real example: a regional bank running an AI-driven loan decisioning system got a request from regulators for a full audit trail on a transaction from the prior quarter — model inputs, confidence scores, every escalation step. The vendor delivered it in under four hours. That wasn’t something built for the audit. It was there from day one.
There’s also a cost argument most buyers underweight. Retrofitting governance into a system that wasn’t built for it often means re-architecting core parts of it, not just adding a policy layer. Companies that pick a vendor purely on capability and push the governance conversation to later often find out how expensive that retrofit is only after they’ve already signed. And the good news, according to DeJon Gaines, is that none of this requires sacrificing capability — the best-designed systems just treat governance as a constraint from the first sketch, the same way a well-designed building treats structural safety.
He closes with a longer-term view: as AI becomes standard infrastructure everywhere, competitive advantage won’t come from just deploying AI — it’ll come from deploying AI that enterprises can actually trust. And that trust gets measured not by what a system can do, but by what it’s architecturally prevented from doing wrong. The executives who ask architecture questions during vendor evaluation, not just compliance questions, are the ones who won’t be blindsided later by what their AI actually does in production.
Download the Insight – Governance Isn’t a Policy. It’s an Architecture Decision
