The framing I hear most often about AI governance is that it's the thing standing between a firm and actually using AI. Legal must approve it. Compliance needs to review it. Security has to sign off. By the time those conversations happen, the momentum is gone and the tools have changed.
I understand why firms have internalized this. In some cases, it's been true. But it's the wrong way to think about what governance actually does when it's built correctly.
I think, after spending the better part of two years building Orion's AI governance program, that governance isn't a constraint on adoption. It's the mechanism that makes adoption sustainable.
The Questions Haven't Changed
Advisory firms have always cared about data security, client privacy, and supervision. Those aren't problems AI created. AI has amplified them — the stakes are higher, the surfaces for risk are larger, the tools are more powerful. But the underlying questions are ones this industry has been answering for decades.
When I think about what AI governance means at Orion, I come back to this framing: we're answering old questions in new ways. Data security, proprietary information, client privacy — these have been the hallmarks of what it means to be a responsible financial services firm. AI doesn't change what we're protecting. It changes how we think about protecting it, and what it takes to do that well at scale.
And I think when a firm approaches governance from that standpoint, it changes what they're actually building. Instead of a list of restrictions, they build a framework that tells employees what they can do — and why they can trust it. When people understand that a tool has been vetted, that someone has defined what data goes in and what doesn't, that the firm stands behind the environment — they use it more, not less. That's where the efficiency comes from. Not from removing governance, but from getting it right.
Who Owns This?
One of the most common mistakes I see is treating AI governance as a single function's problem. Legal owns it, or IT owns it, or compliance owns it. What happens is that the policy ends up reflecting one function's concerns while ignoring the rest. Legal builds a framework that addresses liability but doesn't reflect what advisors actually do. IT builds a security policy that doesn't account for what compliance needs from a supervision standpoint.
And so, I think what really works is getting diverse stakeholders to the table before you finalize anything. Legal, compliance, security, product, operations — each of them brings something the others don't have, and the governance framework that emerges from that conversation is more durable than anything built in isolation. The point isn't design-by-committee. It's that if you understand everyone's needs before you write the rules, the rules are more likely to enable the work rather than obstruct it.
I'd also say this requires real leadership buy-in, and that's what I've seen make the difference. A governance program that lives only at the operational level is fragile. If leadership isn't leaning in — setting the expectation that the firm will adopt AI thoughtfully, investing in the process, removing blockers when they emerge — the program stalls. Governance becomes an enabler only when leadership treats it as a priority, not a compliance exercise.
