AI Infrastructure Governance: Turning an Enterprise AI Governance Framework into Identity, Tenant and Runtime Compute Controls

AI infrastructure governance means the compute platform enforces an enterprise's AI governance framework, the written policy for how the company uses AI. The policy stays a document until the platform refuses an action that breaks a rule.

Three layers of a GPU platform handle policy enforcement:

1. Identity and access: ties each action to a signed-in person or service account.
2. Tenant isolation: gives each tenant its own GPUs and quotas, where a tenant is a team or customer sharing the platform.
3. Runtime logging: records each job's events automatically, such as start time and input data.

A single-tenant research cluster needs the identity layer first. A shared GPU cloud adds tenant boundaries, and a regulated workload such as camera face recognition adds runtime logging rules.

What AI Governance Frameworks Require From the Platform

The NIST AI Risk Management Framework (NIST AI RMF) is a voluntary US framework for managing AI risk. Its core groups the work into four functions:

1. Govern: builds a risk-management culture and sets the policies, roles, accountability and oversight behind the other three functions.
2. Map: sets out the context of an AI system, including its intended use and its possible impacts.
3. Measure: analyzes, tests and monitors AI risk with quantitative, qualitative or mixed methods.
4. Manage: ranks the mapped and measured risks, assigns resources to them and plans the response to an incident.

ISO/IEC 42001 sets the requirements for an AI management system, the policies and processes a company uses to run AI. The standard follows a Plan-Do-Check-Act cycle, so monitoring and audit evidence belong to its Check phase.

The EU AI Act regulates AI systems sold or used in the EU. Its Article 12 requires each high-risk AI system to technically allow automatic recording of events over the system's lifetime.

Article 12 binds the AI system and the company that supplies it, called the provider in the Act. The system usually relies on its compute platform to write those logs, so the provider's compliance depends on automatic logging from the platform.

Article 12 applies from 2 December 2027 to the high-risk uses the Act lists in Annex III. The date moved from August 2026 under the Digital Omnibus, a 2026 amendment to the Act.

Article 12(3) adds four required record types for remote biometric identification, systems that identify people at a distance from face or other body data:

1. Period of use: the start and end date and time of each use of the system.
2. Reference database: the database against which the system checked the input data.
3. Matched input data: the input data for which the search found a match.
4. Verifier identities: the identification of the people who checked the system's results under the Act's human oversight rules.

How the Three Infrastructure Layers Line Up With Each Framework

NIST and ISO describe management activities, so the table shows our own mapping of their functions and phases to platform layers. An auditor reads it from left to right: pick the layer, name the requirement, then ask for that layer's records.

Identity and Access Governance

The identity layer ties each action on the platform to a named person or service account, so an auditor can see who started a job or changed a setting. The layer runs three access controls:

1. Authentication: confirms who the actor is, through a sign-in or a service credential.
2. Authorization: sets the workloads, datasets and admin actions open to that actor, often through role-based access control (RBAC), which grants permissions by job role.
3. Access logging: writes the actor, the action and the time of each event to audit logs for later review.

Auditors ask this layer for identity-linked access records, which give transparency on who provisioned a workload, changed a quota or opened a training dataset. A log line without a real account name can't show who made the change.

A record reading "admin account a.lee raised the GPU quota for team B at 14:02" passes that test. A record reading "quota updated" fails it, because it leaves out the account.

The same layer holds the verifier identities that Article 12(3)(d) requires for human oversight of remote biometric systems.

Tenant Isolation as a Governance Control on Shared GPUs

The tenant layer keeps each tenant's workloads on its assigned GPUs, storage and quotas. A failed job then stays inside one tenant, which narrows the impacts a team has to assess under the NIST Map function.

The scheduler's priority rules decide whose jobs run first when tenants compete for the same GPUs. Written priority levels and a log of where each job ran let an auditor test policy enforcement.

The provider runs the tenant boundary on a rented GPU cloud, so the provider's own controls become part of the buyer's compliance. NIST lists this third-party risk under its Govern function.

Review the provider's isolation design and audit reports during due diligence, before moving workloads onto its GPUs. The tenant review then covers the boundary settings between tenants, the written priority rules and the scheduler logs that show those rules in use.

Runtime Logging as AI Governance Evidence

The runtime layer logs events during each job. Teams use those logs for the monitoring in the NIST Measure function.

A high-risk AI system uses the same logs to meet Article 12(1).

For remote biometric systems, the platform's runtime logging writes three of the four Article 12(3) record types: period of use, reference database and matched input data. The identity layer supplies the fourth, the verifier's identity.

Sample runtime logs from different points in the system's life, such as before and after an upgrade. Check each biometric-system record for the four fields.

The AI Infrastructure Governance Audit Checklist

These five checks test the three layers and produce compliance evidence for an EU AI Act conformity assessment, the review a high-risk system needs before it's sold in the EU.

1. Automatic logging: Start a live test job and confirm the platform wrote its start, end and access events to the audit logs. The events should appear without a manual logging command from an operator.
2. Logging across the system's lifetime: Confirm logging stays on from deployment to decommissioning. Check that upgrades, migrations and configuration changes don't stop the log stream.
3. Access logs tied to identities: Match each access record to a signed-in account. Confirm the log separates human accounts from service accounts and attaches an identity to admin actions such as quota changes.
4. Written scheduler priority: Confirm the priority levels exist as written policy and that the platform logs where each job ran. Sample a busy scheduling window and check that the recorded order follows the written rules.
5. Article 12(3) record fields: For remote biometric systems, confirm each record carries the four required fields. Check that each verifier identity matches a signed-in account in the identity layer.

The ISO/IEC 42001 Check phase can reuse the same records, so one evidence set may serve both reviews.

Zettabyte Software for Each Governance Layer

zWARE is Zettabyte's GPU cluster management software for the runtime layer. It runs a hardened Kubernetes with its own AI-aware scheduler, tracks GPU, network card (NIC), power and system health in real time and alerts operators to faults.

zPLATFORM gives operators the identity and tenant controls. Its Integrated Observability feature combines identity management, usage tracking and system monitoring, and its tenant tools set quotas and usage policies.