11.4 Governance Roles, Risk Taxonomies, and Compliance Operations

Key Takeaways

  • An AI Center of Excellence coordinates reusable standards and expertise, while accountable business, security, privacy, legal, data, and model owners retain their duties.
  • An AI governance engineer turns policy into inventories, control requirements, technical guardrails, evidence, metrics, and exception workflows.
  • Risk assessment must cover accidental data leakage, accuracy and performance, security, safety, bias, intellectual property, reputation, and downstream dependence.
  • Public, private, open, closed, and third-party models create different transparency, sovereignty, supply-chain, contractual, and operational risks.
  • Third-party evaluation and compliance evidence must be independent enough for the risk, scoped to the deployed system, reproducible, and maintained through change.
Last updated: September 2026

11.4 Governance Roles, Risk Taxonomies, and Compliance Operations

Governance assigns decisions, evidence, and consequences. A policy without an owner or a control without evidence will not manage AI risk.

Organizational roles

An AI Center of Excellence (AI CoE) is a cross-functional capability that develops reusable patterns, training, evaluation methods, architecture guidance, and an AI inventory. It can coordinate standards but should not absorb accountability from the business owner. Central guidance and local ownership work together.

An AI governance engineer translates policy and risk requirements into technical practice. Typical work includes inventory schemas, model and data cards, control mappings, evaluation gates, logging requirements, policy-as-code, exception workflows, dashboards, and evidence collection. The role collaborates with security, privacy, legal, compliance, data science, platform engineering, procurement, and internal audit.

Other responsibilities remain distinct:

  • The business or system owner accepts objectives and residual risk.
  • Data owners authorize collection, quality, classification, use, and retention.
  • Model and engineering owners maintain artifacts, evaluation, deployment, and rollback.
  • Security performs threat modeling, testing, monitoring, and response.
  • Privacy and legal interpret obligations and individual rights.
  • Procurement manages supplier terms, provenance, notification, and exit.
  • Independent assurance or audit tests whether claimed controls operate.

Separation of duties matters. The developer should not be the only evaluator, the model should not approve itself, and a supplier's marketing claim is not independent assurance.

Risk categories and outcomes

An AI risk register should connect cause, event, affected asset or person, outcome, control, evidence, owner, and residual risk. Relevant outcomes include:

  • Accidental data leakage: prompts, outputs, logs, embeddings, feedback, or training records reveal secrets or personal data.
  • Accuracy and performance failure: confabulation, false positives, false negatives, drift, instability, or latency prevents the system from meeting its defined purpose.
  • Security and safety harm: adversarial manipulation or excessive agency causes an unsafe decision or action.
  • Bias and human-impact risk: performance differs across relevant populations or users cannot contest an outcome.
  • Intellectual-property risk: training, generated content, or model artifacts violate rights or expose protected work.
  • Reputational and legal loss: misleading, offensive, noncompliant, or poorly governed output erodes trust and produces liability.
  • Value-chain risk: a dataset, model, cloud service, plug-in, or evaluator fails or changes outside the deployer's direct control.

Risk categories overlap. A leaked support transcript can create privacy, security, regulatory, and reputational consequences simultaneously. Use scenarios and impact analysis rather than forcing each event into one box.

Deployment and sourcing models

A public model service is externally accessible or multi-tenant and may offer rapid capability with less infrastructure control. A private model runs in a dedicated or organization-controlled environment and can improve isolation, but still needs secure operations. Open models expose weights or implementation details under a license, increasing inspectability and self-hosting options while shifting patching and provenance duties to the adopter. Closed models offer less artifact visibility and require stronger contractual and behavioral assurance. These terms describe different dimensions; an open-weight model can be privately hosted.

A third-party model introduces supplier and concentration risk. Review training and data-use terms, data locations, subprocessors, retention, security controls, model-update practices, incident notification, evaluation access, service continuity, export capability, and deletion. Contract language does not replace technical tests.

Data sovereignty concerns which jurisdiction controls data and what laws apply, not merely the physical server address. Prompts, telemetry, fine-tuning records, backups, support access, embeddings, and logs may cross borders through subprocessors. Map every flow and applicable obligation before deployment.

Frameworks and compliance evidence

The OECD AI Principles support innovative and trustworthy AI, including human-centered values, transparency, robustness and safety, and accountability. NIST AI RMF, ISO/IEC 42001, laws, sector rules, and internal policies provide different kinds of guidance or obligations. Map them to one control system without falsely claiming that compliance with one framework guarantees compliance with another.

Third-party evaluation can reduce conflicts of interest and add specialist testing. Its quality depends on scope, access, method, benchmark relevance, independence, reproducibility, and disclosure of limitations. A test of a base model does not automatically cover a deployed RAG corpus, agent permissions, or a later model version.

Evidence may include inventory records, approvals, data and model documentation, threat models, evaluation reports, red-team results, access reviews, logs, incident exercises, supplier assessments, impact assessments, monitoring, and exceptions. Evidence must identify versions and dates. Reassess when the model, data, prompt, tool access, supplier, purpose, population, or law changes.

Worked governance decision

A company proposes a public third-party assistant for customer-support summaries. The AI CoE supplies the pattern and evaluation rubric. The business owner documents objectives and error tolerance; privacy maps cross-border prompt, log, and support flows; security tests indirect prompt injection and connector permissions; procurement negotiates training-use restrictions, incident notice, deletion, and exit; and an independent evaluator tests the configured system. The governance engineer links artifacts to the inventory and blocks release until redaction, tenant isolation, human review, and monitoring evidence pass. The business owner—not the vendor or model—accepts documented residual risk.

Loading diagram...
AI Governance Accountability and Evidence
Test Your Knowledge

Which statement best describes an AI Center of Excellence?

A
B
C
D
Test Your Knowledge

A supplier provides a favorable test of its base model, but the deployed system adds private retrieval and powerful tools. What is the best response?

A
B
C
D
Test Your Knowledge

Which issue is most directly a data-sovereignty concern?

A
B
C
D
Congratulations!

You've completed this section

Continue exploring other exams