Accountability / Organization
AI Governance Roles in Data Centers: Who Owns What?
An AI model cannot accept operational accountability. Named people must own the use case, the physical limits, the data, the decision to go live and the response when something fails.
Sections in this article
If an AI tool proposes a chiller setpoint change after business hours, who can approve it, who can stop it, and who is responsible for reviewing the incident next morning? If the answer is “the vendor,” ownership is incomplete.
Different teams understand different parts of operational AI. Facility engineering knows equipment limits; IT operates data pipelines; security protects network boundaries; procurement and legal negotiate vendor obligations. Governance fails when everyone participates but nobody is accountable for a decision.
The following allocation is an organizational example, not a universal reporting structure. Smaller sites may combine roles. In every case, the named owners and substitutes should be visible in the site's AI inventory and operating procedures.
Five roles that need clear boundaries
Facility operations
Owns physical safety, approved operating envelopes, local fallback procedures and the decision to permit automated equipment control. Shift teams verify actual plant condition.
IT and model operations
Owns software deployments, version records, data delivery, monitoring and the technical evidence required to reproduce an AI decision.
Cybersecurity
Controls identities, segmentation, third-party access, incident coordination and independent security logs across IT/OT boundaries.
Business and executive sponsor
Accepts justified residual business risk, funds safeguards and decides whether expected benefit warrants operational exposure.
Vendor and subject-matter advisers
Provide product evidence, support and defined contractual commitments; they do not replace the operator's on-site command structure.
A practical RACI matrix for one operational AI system
RACI uses R for Responsible (does the work), A for Accountable (owns the decision), C for Consulted and I for Informed. The proposed allocation assumes a third-party tool used for supervised cooling optimization.
| Activity | Facilities | IT / model | Security | Sponsor |
|---|---|---|---|---|
| Approve physical operating limits | A/R | C | C | I |
| Validate data and model version | C | A/R | C | I |
| Grant OT network access | C | R | A | I |
| Authorize initial go-live | R | R | C | A |
| Execute emergency facility response | A/R | C | C | I |
Assign one accountable decision owner to each activity. In the example, the sponsor authorizes the business go-live only after facilities, IT and security provide their required sign-offs; the sponsor cannot overrule safety interlocks.
Document handoffs, not just job titles
The hardest failures occur between teams. A supplier may update a model during a maintenance window without notifying the facility engineer. A controls engineer may replace a sensor without informing the data team. Neither team necessarily made an unreasonable decision in isolation; the gap was the missing handoff.
Change: replace cooling sensor cluster on Hall B. Facilities: verifies calibration and physical position. IT: validates data mapping and missing-value handling. Security: checks access changes. Go-live owner: approves model revalidation before closed-loop operation resumes.
For each system, record a primary owner, deputy, approval threshold and escalation route. If a model operates outside normal hours, its oversight plan must do the same.
Do not confuse internal accountability with AI Act legal roles
The EU AI Act distinguishes roles such as provider and deployer. A company's internal “AI owner” is a governance assignment, not automatically a statutory role. Legal obligations depend on who develops or puts a system into service, who uses it under whose authority, the intended purpose and the applicable classification.
Some high-risk requirements can apply in specified circumstances; they are not automatically triggered merely because a data center uses AI or manages critical infrastructure. Refer to the operator-focused AI Act guide for the role analysis and confirm the current application dates before asserting a duty.
First 30 days: a lean governance setup
- W1List systems and decision authority
Identify whether each tool is read-only, advisory or permitted to act on equipment.
- W2Name owners and deputies
Document on-call coverage, vendor contacts and approval requirements.
- W3Check real evidence
Collect network permissions, test results, change history and a usable response procedure.
- W4Run a tabletop exercise
Trace one unsafe recommendation from alarm to containment and reporting; close gaps discovered.
A governance rule worth keeping: a good responsibility model makes an operational question answerable quickly. Who knows the system, who can authorize a change and who can safely suspend it should never require an improvised meeting during an incident.
Sources and further reading
Primary frameworks and reference materials. Engineering decisions require site-specific validation; legal classifications require assessment of the actual use case.
- AI RMF Govern function and cross-functional oversightNIST AI Resource Center
- Guide to OT Security, SP 800-82 Rev. 3NIST
- Regulation (EU) 2024/1689 (AI Act)European Union