AI governance

In practice it covers use case intake and risk triage, data rules, vendor review, human oversight requirements, and incident response for AI failures. Frameworks such as the NIST AI RMF and ISO/IEC 42001 give it structure, though neither tells you where your own risk actually sits.

The distinguishing feature of AI governance, compared with the governance you already run, is that the decisions are mostly about use cases rather than systems. The same model is unremarkable for drafting marketing copy and unacceptable for screening job applicants. That means the unit of review is the application of AI to a task, not the procurement of a tool, and a process organized around vendor onboarding will keep missing the risks that matter.

Most programs fail in one of two directions. Too heavy, and every use case goes to a committee that meets monthly, so teams route around it and you have manufactured shadow AI by design. Too light, and the intake form becomes a formality nobody reads. The workable middle is tiering: an impact assessment that most use cases clear in a day, with real scrutiny reserved for those touching personal data, safety, employment, credit, or anything a regulator has already named high risk.

Governance also has to survive contact with things going wrong, which is the part most programs skip. That means naming a model owner accountable for each deployed system, defining what counts as a serious AI incident before you have one, and holding a fallback plan for switching a model off without halting the business process that has quietly come to depend on it.