Political Tech
A coalition including Red Hat, NVIDIA, and IBM wants to automate compliance with AI governance rules, but who decides what the code actually says?
NewsOnScale Staff
August 21, 2026
There is a long history of powerful institutions solving the problem of accountability by controlling the definition of accountability. A new initiative backed by Red Hat, NVIDIA, and IBM — aimed at converting AI policy documents into executable code — fits uncomfortably well into that tradition.
The project, reported this week, seeks to bridge the gap between what regulators write and what AI systems actually do. The pitch is straightforward: policy language is vague, implementation is slow, and the space between the two is where harm tends to live. If you can encode governance rules directly into software pipelines, the argument goes, compliance becomes automatic, auditable, and consistent.
On its face, this is not a bad idea. It is, in fact, a genuinely hard problem that deserves serious engineering attention. The gap between a regulatory document and a deployed model is enormous, and filling it with human judgment alone has obvious failure modes.
But the details of who is filling that gap — and how — deserve more scrutiny than the initiative has so far received.
## Who Writes the Code Writes the Rules
Translating policy into code is not a neutral act. Every law, regulation, or governance framework contains ambiguities, contested definitions, and value-laden tradeoffs that legislators and regulators left deliberately open — either because consensus was impossible, or because they expected future interpretation by courts and agencies.
When a private consortium encodes those ambiguities into software, someone makes a choice about how to resolve them. That choice is technical in form but political in substance. A definition of "high-risk AI system" baked into a compliance library is not just an engineering decision — it is a policy decision, made by engineers, at the direction of companies with direct financial stakes in how broadly or narrowly that definition applies.
This is not hypothetical. The financial industry learned this lesson painfully when credit-scoring algorithms operationalized discriminatory lending patterns under the cover of neutral mathematics. The math was accurate. The policy choices embedded in it were not examined until the damage was documented.
## The Audit Problem
Proponents of policy-as-code point to auditability as a key benefit. If the rules are in the code, you can inspect the code. This is true, but it assumes that the people doing the inspecting have the access, expertise, and independence to do so meaningfully.
Right now, that assumption does not hold. Regulatory agencies in the United States are not resourced to audit proprietary software stacks maintained by some of the largest technology companies in the world. Civil society organizations that might otherwise play a watchdog role are dependent on voluntary disclosure. Academic researchers are constrained by terms of service and API limitations.
A governance framework that lives inside a Red Hat or NVIDIA product ecosystem is, in practice, governed by those companies — unless specific, enforceable access rights are built into the system from the start. There is no indication yet that this initiative includes such provisions.
## What Legitimate Infrastructure Could Look Like
None of this means the project is malicious or that its architects are acting in bad faith. The underlying ambition — reducing the distance between stated policy and actual system behavior — is worth pursuing. But the governance of that infrastructure matters as much as the infrastructure itself.
At minimum, any initiative of this kind should be subject to public comment periods similar to those required for federal rulemaking. The code should be open source and maintained under a governance structure that includes independent regulators, civil society representatives, and affected communities — not just vendors.
Compliance tooling built exclusively by industry, for industry, and interpretable primarily by industry is not governance. It is the appearance of governance, which is a different and more dangerous thing.
The companies backing this project have legitimate expertise and real incentives to make AI systems work reliably. Those are necessary conditions for good infrastructure. They are not sufficient conditions for accountable infrastructure.
The distinction matters. And right now, almost nobody outside the consortium is in a position to enforce it.