Clear decision rights give people room to move.
I learned this while helping a regulated business respond to the spread of generative AI. People were finding uses for it across functions. The opportunity was evident, and so were questions about customer information, confidentiality, intellectual property, and responsibility. No single function owned the enterprise risk created by all those uses together.
That left us with an organizational problem. A tool could be useful to one team while creating consequences for several others. Sending each request through a succession of separate approvals would not resolve who should make the overall decision.
I brought three options to senior leadership. The decision was to widen governance so that the affected functions became the decision makers. A cross-functional task force developed the responsible AI policy, drawing on the broader company's guidance, with no incremental headcount. The CEO approved it. That policy created the governance foundation for the enterprise Copilot deployment and subsequent AI use cases.
The reframe that carried the work was straightforward: how do we enable responsible use while protecting customer information, the company, and its strategic options?
That question gave us a purpose people could work toward together. It recognized both the value of adoption and the consequences of getting it wrong. It also made clear that responsible AI use belonged in business decision-making, with the relevant expertise present from the beginning.
No incremental headcount did not mean no investment. People contributed time, knowledge, and attention alongside their existing responsibilities. The lesson I take from that experience is about using distributed expertise deliberately. It should never become an argument that governance can run indefinitely on spare capacity.
The policy was a foundation. Turning it into a consistent operating process remained work in its own right. My later governance materials addressed intake, prioritization, ownership, production support, and lifecycle decisions. That distinction matters: leadership approval of a policy and reliable execution of that policy are separate achievements.
For leaders building their own model, I would start with the decisions the governance body needs to make. Which risks require collective judgment? Which investments require enterprise prioritization? Which matters can be handled by an accountable owner within agreed boundaries?
A council needs a clear remit and the authority to resolve those questions. Membership should follow the decisions and their consequences. Business, technology, security, privacy, legal, quality, finance, and procurement may all be relevant, depending on the use case. Attendance alone does not create shared accountability. People need to know what they are there to decide.
Operational review also needs a home. Someone must help requestors describe the problem, identify missing information, bring in the right expertise, and maintain the decision record. Senior leaders should receive the unresolved tradeoffs that require their authority, with enough context to make a decision.
This is where intake can either help or obstruct. A useful intake asks what outcome should improve, who owns it, what data is involved, what the system will be permitted to do, and who could be affected by an error. It also checks whether an existing capability already meets the need.
A familiar tool used with public information and a familiar tool used to influence a sensitive decision may require very different treatment. Approving the product name alone leaves too much unresolved. The use, the information, and the authority all matter.
The path through governance should be proportionate. Teams working within an established pattern should understand the conditions for proceeding. Unusual data, higher consequences, new external commitments, or expanded authority should trigger additional review. Clear routes reduce the need to renegotiate the same questions every time.
Decisions need to travel with the work. Record what was approved, for which purpose, under what conditions, and who owns the next step. A requestor should be able to understand whether the answer is proceed, revise, test further, use an existing solution, or stop. Ambiguity creates waiting and encourages workarounds.
Then keep governance connected to the system after launch. A change in data, model, vendor, audience, or permissions can change the basis on which the original decision was made. Ownership, monitoring, incident response, and retirement therefore belong in the operating model from the start.
The same applies to business value. An approved system that no longer serves a useful purpose still consumes money and attention. A governance process should make it possible to change or retire that system, as well as authorize it.
I would assess governance by the quality and clarity of the decisions it enables. Do teams know where to begin? Are familiar requests handled consistently? Do exceptions reach someone with authority? Can the organization explain why a system is allowed to operate and recognize when those conditions no longer hold?
Those are practical tests of whether governance is helping people act responsibly. In your organization, which decisions keep returning for approval because the underlying authority was never made clear?