AI governance is the operating system around how an organization decides where AI can be used, who is accountable for it, what evidence must exist before deployment, how risk is measured, how exceptions are approved, and when a system should be changed or retired. It is broader than a policy document and narrower than \u201cethics\u201d as an abstract principle. Governance becomes real when responsibilities, inventories, assessments, evidence, approval gates, and monitoring all connect to day-to-day engineering and business decisions.<\/p>\n
NIST\u2019s AI Risk Management Framework organizes AI risk work across four functions\u2014Govern, Map, Measure, and Manage\u2014and treats governance as cross-cutting across the lifecycle. Current NIST material also emphasizes accountability structures, periodic review, AI-system inventories, impact assessments, risk tolerance, and explicit decisions about whether development or deployment should proceed. This hub turns those ideas into an operational content cluster rather than a checklist of slogans.<\/p>\n
The supporting articles cover AI Accountability Matrices, AI Audit Evidence, AI Bias Testing Governance, AI Data Protection Impact Assessments, AI Impact Assessments, AI Model Inventory Reconciliation, AI Policy Exception Handling, AI Red Team Governance, AI Risk Acceptance Decisions, and Building AI Risk Taxonomies.<\/p>\n
An organization can produce dozens of AI policy documents and still have weak governance if nobody knows who owns the final deployment decision, who can stop a release, who approves an exception, or who is responsible after the system changes. NIST AI RMF Govern 2 emphasizes accountability structures, documented roles, responsibilities, and lines of communication across AI risk activities.<\/p>\n
AI Accountability Matrices<\/a> translates that into an operating model. The point is not to create an elaborate RACI for every small prompt edit. The point is to identify the decisions whose ownership actually changes risk: purpose approval, data use, model selection, evaluation, deployment, incident response, human oversight, exception approval, and retirement.<\/p>\n The existing security strategy and governance<\/a> article is relevant because the same principle applies: control maturity depends on evidence and accountable decisions, not just written policy.<\/p>\n NIST Govern 1.6 calls for mechanisms to inventory AI systems and resource them according to risk priority. An inventory is more than a list of model names. Useful records connect the system to purpose, owner, deployment status, user population, data sources, models, vendors, evaluations, applicable obligations, known risks, controls, and lifecycle state.<\/p>\n AI Model Inventory Reconciliation<\/a> focuses on the gap between what governance believes exists and what engineering or procurement has actually deployed. Shadow AI, embedded vendor features, test endpoints, local models, agent tools, and retired systems can all create drift.<\/p>\n Inventory accuracy should therefore be reconciled against technical and business sources rather than treated as a self-reported spreadsheet that is updated only before an audit.<\/p>\n NIST\u2019s playbook recommends impact assessments at key lifecycle stages, connected to system context and updates. A useful assessment describes who may be affected, how the system influences decisions, what failures could cause, which benefits justify the design, and what alternatives exist.<\/p>\n AI Impact Assessments<\/a> covers the general governance pattern. AI Data Protection Impact Assessments<\/a> narrows the focus to personal-data processing and privacy risk.<\/p>\n In the EU AI Act, certain deployers of specified high-risk systems have a separate fundamental-rights impact-assessment obligation under Article 27. That is a jurisdiction-specific legal requirement, not a universal label for every AI project. Governance frameworks should therefore distinguish voluntary internal assessment from statutory assessments that may apply in a specific context.<\/p>\n Teams often use the word \u201cAI risk\u201d to mean different things: safety, privacy, security, discrimination, hallucination, compliance, model failure, business loss, reputational harm, operational dependency, or third-party risk. Without a common taxonomy, two teams can assign different severity simply because they are classifying different kinds of harm under the same label.<\/p>\n Building AI Risk Taxonomies<\/a> shows how to separate risk sources, affected parties, impacts, likelihood drivers, controls, and ownership. The taxonomy should be stable enough for portfolio reporting but flexible enough to add new AI-specific failure modes over time.<\/p>\n NIST\u2019s AI RMF and Generative AI Profile are useful anchors because they separate governance, mapping, measurement, and management and provide a cross-sector vocabulary without pretending one risk score fits every application.<\/p>\n NIST SP 1270 identifies systemic, computational\/statistical, and human forms of bias and explicitly warns against reducing bias management to dataset representativeness or model mathematics alone. Bias can enter through institutional processes, data collection, labeling, task framing, deployment context, human interpretation, and feedback loops.<\/p>\n AI Bias Testing Governance<\/a> therefore treats metric selection as a governance decision. Teams should document which population, outcome, reference group, slice, threshold, and intervention they are testing and why that measurement is appropriate for the use case.<\/p>\n A test that produces one fairness number without context can create false confidence. Governance should preserve the assumptions behind the metric and require review when deployment context changes.<\/p>\n AI Audit Evidence<\/a> focuses on what future reviewers will actually need: versioned requirements, inventory records, data lineage, approvals, evaluation results, model\/prompt versions, deployment records, access-control evidence, exceptions, incident records, and monitoring outcomes.<\/p>\n Evidence should be generated as a byproduct of engineering processes rather than reconstructed from email threads six months later. Source control, CI\/CD, model registries, prompt registries, ticketing systems, evaluation platforms, identity logs, and system inventories can all contribute.<\/p>\n The existing compliance strategy<\/a> article provides the wider principle: policy becomes credible when it is connected to operational evidence.<\/p>\n No governance framework survives contact with real delivery if it assumes every control will always be satisfied exactly on schedule. The dangerous pattern is not the existence of exceptions; it is informal exceptions that are invisible, permanent, and owned by nobody.<\/p>\n AI Policy Exception Handling<\/a> defines a controlled path: state which requirement is not met, why the exception is necessary, what risk it creates, which compensating controls exist, who approves it, when it expires, and what event forces review.<\/p>\n Exception metrics are also valuable. If one control produces dozens of recurring exceptions, either the control is unrealistic or the platform lacks a capability teams genuinely need.<\/p>\n NIST\u2019s 2026 ARIA Evaluation Planning Manual frames holistic evaluation around model testing, red teaming, and user testing. Red teaming is therefore one evidence source within a wider evaluation program, not an isolated adversarial event that exists only for security specialists.<\/p>\nAn inventory makes the AI estate governable<\/h3>\n
Impact assessment should happen before the decision hardens<\/h3>\n
Risk taxonomies should make disagreements visible<\/h3>\n
Bias governance requires more than one fairness metric<\/h3>\n
Audit evidence should be designed while the system is built<\/h3>\n
Exceptions need expiry, compensating controls, and ownership<\/h3>\n
Red teaming should connect findings to decision rights<\/h3>\n