Applied AI
Who should own enterprise AI governance?
Security, legal, data, technology and business leaders each own part of AI risk. Governance works when accountability and decision rights are explicit.
January 29, 2026
Security sees data exposure. Legal sees liability and intellectual property. Data leaders see lineage and quality. Technology teams see an operating platform. Business leaders see an opportunity—and a queue of approvals slowing it down.
Asking one function to “own AI” sounds decisive. It usually gives that function responsibility for risks it cannot control and decisions it is not equipped to make.
The better answer is federated governance with one accountable executive, named owners for each system and explicit decision rights across the lifecycle.
Accountability cannot be outsourced to a committee
NIST's AI Risk Management Framework organises work around Govern, Map, Measure and Manage. Governance is the cross-cutting function because risk decisions depend on context, measurement and ongoing operation—not a one-off legal review.
An executive sponsor should be accountable for the enterprise programme: risk appetite, investment, escalation and whether controls actually operate. A cross-functional council can set common policy and resolve exceptions. But every AI system still needs a business owner accountable for its purpose and consequences, plus a technical service owner accountable for operation.
If everybody owns AI, nobody owns the incident at 2 a.m.
Give each function real decisions
Business owner
Defines the problem, affected people, acceptable outcome, human oversight and value. Accepts residual business risk and funds operation—not merely the pilot.
Product and technology
Design, build or configure the service; manage integration, reliability, cost, change and support. They provide evidence that the system behaves as approved.
Data
Own source suitability, quality, lineage, retention, access and permitted use. Data governance is not replaced by AI governance.
Security
Sets requirements for identity, isolation, secrets, supply chain, logging, tool permissions, testing and incident response. It needs veto authority for material security risk, not ownership of business value.
Privacy and legal
Interpret obligations, contracts, intellectual property, transparency, data-subject rights and prohibited or high-risk uses. They should shape design early rather than approve a finished system under deadline.
Risk, compliance and internal audit
Challenge classification and controls, test whether evidence is real and report independently. They should not become the delivery team they later assess.
Procurement and vendor management
Govern provider diligence, data terms, subcontractors, service changes, exit, portability and concentration risk.
People and HR
Address workforce impacts, employee monitoring, skills, acceptable use and change. Adoption is a governance concern when work and accountability change.
Risk-tier use cases, not technologies
The same model can draft an internal summary or influence a credit decision. Governing the model name alone misses the impact.
Classify each use case using factors such as:
- consequence and reversibility;
- affected people and rights;
- autonomy and tool access;
- data sensitivity and jurisdiction;
- external communication;
- regulatory or contractual exposure;
- scale and frequency; and
- detectability of error.
Low-risk uses can follow a paved path with standard controls. Higher-risk uses need deeper assessment, evaluation, human oversight and approval. Some should be prohibited. Document the reason so similar cases receive consistent treatment.
Build stage gates into delivery
Governance should produce evidence at natural engineering points:
- Intake: purpose, owner, users, data, provider and risk tier.
- Design: threat model, human role, evaluation plan, architecture and fallback.
- Pre-release: test evidence, red-team findings, privacy/security review and operating readiness.
- Launch: approved scope, monitoring, user disclosure, support and incident route.
- Operation: drift, incidents, provider/model changes, complaints, cost and realised value.
- Retirement: access removal, data and index deletion, records, contracts and replacement.
Automate evidence collection where possible. Do not turn every low-risk experiment into a six-month approval process; that simply creates shadow AI.
Maintain an inventory that reflects reality
The inventory should include purchased assistants, embedded vendor features, APIs, internally trained models, RAG indexes, agents, automated decisions and meaningful employee use. Record owner, purpose, risk, data, users, providers, versions, tools, controls and status.
Discovery matters because policy alone does not reveal unsanctioned use. Offer safe approved tools, simple disclosure and proportionate review so teams have a credible alternative to hiding experiments.
An inventory is not success if its entries are stale. Tie it to procurement, architecture, identity, API gateway and production-release processes.
Govern change, not only launch
Models, prompts, providers, retrieval corpora and tool permissions change. A provider can alter a feature underneath a product. A system approved for advice can acquire write access.
Define which changes require regression testing or renewed approval. Keep versioned evaluations and traces. Monitor outcomes and incidents by risk tier. Establish emergency disablement and rollback. Review whether the system still produces value; a compliant system with no useful adoption should also be retired.
What to measure
- known AI systems with named business and technical owners;
- inventory coverage compared with discovery signals;
- time to approve low-, medium- and high-risk uses;
- exceptions by age and accountable approver;
- material changes released without evaluation;
- control failures and incidents by risk tier;
- time to disable or contain unsafe behaviour;
- user adoption of approved routes versus shadow alternatives; and
- realised value and retirement of underperforming systems.
Counting policies and committee meetings measures activity, not governance.
The counterarguments
“The CIO should own all of it.” Technology is well placed to operate shared controls, but cannot accept every business, legal and human consequence.
“Legal or security should own it.” They need authority over their risk domains. Making them sole owners can reduce governance to prohibition and leave operating quality unowned.
“A committee should own it.” A council coordinates policy; it cannot replace accountable system owners or an executive who resolves conflict.
“Business units should move independently.” Domain ownership is valuable, but shared minimum controls, inventory and escalation prevent inconsistent risk and duplicated infrastructure.
Adovo’s view
Enterprise AI governance is not a new department that takes responsibility away from everyone else. It is a decision system: who may decide, what evidence they need, who can stop the release and who answers when the service causes harm.
Centralise the minimum guardrails and platform. Federate use-case ownership. Make accountability singular even when expertise is shared.