Research · AI Governance

As organizations adopt AI across different teams - marketing piloting a generative tool, engineering fine-tuning a model, procurement signing a vendor contract with an AI-powered feature - accountability for AI use often ends up spread across departments without a single clear owner. A set of organizational practices has emerged to address this gap directly.

A governance program typically assigns clarity on four functions: who sets policy, who reviews and approves use cases before deployment, who monitors deployed systems over time, and who is accountable when something goes wrong. This is usually documented and assigned to named individuals rather than departments, and revisited as an organization's AI footprint grows - a charter that hasn't been updated since an initial kickoff tends to function more as an artifact than an active structure.

AI risk spans legal exposure, technical capability, employment implications, and business context simultaneously, which is why governance structures typically involve legal, security, HR, engineering, and the relevant business unit together, rather than any one function alone. A common structure is a standing working group or governance council that reviews use cases on a regular cadence, rather than convening only after an incident.

Governance policies are commonly reinforced through training delivered at three distinct levels:

• Foundational literacy for the whole organization - what AI is, where it's used internally, and what's expected of everyone.
• Role-specific training for those building, procuring, or overseeing AI systems, covering the specific workflow they follow.
• Leadership-level framing so executives can discuss AI strategy and risk with boards, customers, and regulators.

This training is typically treated as ongoing rather than a one-time onboarding module, updated as tools, regulations, and use cases change.

A fifty-person startup piloting an AI feature and a regulated financial institution deploying AI in underwriting decisions generally require very different governance structures, shaped by several factors:

• Size and resourcing - a small team can't sustain a heavyweight review board, though that doesn't mean no process at all.
• Maturity - organizations just beginning to experiment typically need different guardrails than those running many production models.
• Sector and regulatory exposure - healthcare, finance, and government-adjacent work carry obligations a consumer app doesn't.
• Risk tolerance - a customer-facing decision system generally warrants more scrutiny than an internal drafting tool.

Frameworks like the EU AI Act formalize distinct roles for organizations working with AI systems, and the same organization can hold different roles for different systems simultaneously:

An organization that fine-tunes a third-party model and offers it to customers can find itself classified as both a deployer and a provider simultaneously - each carrying its own associated obligations.

These categories carry different documentation, disclosure, and risk-assessment expectations under frameworks like the EU AI Act, which is why classification is treated as a technical and organizational exercise worth getting right, not just a compliance footnote.

A common thread across all five

Across these practices, a similar pattern shows up repeatedly: governance functions as an ongoing operating rhythm rather than a static document. Roles that aren't named tend not to get exercised. Training delivered once tends not to stick. A framework borrowed from a much larger organization tends not to fit. And role classification under emerging regulation carries real practical weight, not just administrative overhead.

Related Tool

See how your organization's AI governance measures up - take the AI Governance Readiness Assessment →