The AI Strategy Guide logo The AI Strategy Guide at the cusp of AI Subscribe →
Responsible AI Governance Frameworks: An Honest Read on the 2026 Principles Landscape — Governance illustration

Responsible AI Governance Frameworks: An Honest Read on the 2026 Principles Landscape

Tom Prommer · CIO/CTOUpdated 2026-05-2912 min read

The principles document I have been most quoted from to least operational effect is the OECD AI Principles. A bank I worked with in early 2024 had adopted the OECD set as the foundation of its responsible-AI policy. Five principles, signed by the board, framed in every external communication, referenced in the annual report. I asked, during the governance review that brought me in, which deployment decision in the previous twelve months had been made differently because of the OECD adoption. The CISO’s answer was refreshingly honest: none. The principles had not been wrong about anything; they had simply not been the kind of artefact that produced deployment decisions. The deployment decisions had been made against the CISO’s existing security framework, the data team’s existing data-quality controls, and the legal team’s existing GDPR analysis. The OECD principles had been the board-facing language. The board-facing language is useful. It is not the operational control set, and pretending it is produces a programme where the board thinks AI is being governed and the operators know the governance is happening elsewhere.

That experience is the shape of this whole piece. The responsible-AI cluster — OECD AI Principles, Asilomar, the various corporate statements, the consulting-firm derivative documents — has become large and well-funded enough that the question of what it actually does has gone under-asked. I have been arguing in the governance hub that the cleaner frame is “governed AI,” by which I mean: every model in the inventory has a named owner, a documented evaluation history, a deployment gate it passed, a monitoring regime it lives under, and an incident runbook for when monitoring fires. That is operational governance. Responsible AI as currently practised is not that. It is the language layer above it, and treating the language layer as the control layer is the most common structural mistake in the cluster.

This piece is the operator’s honest read on the principles landscape — which documents are worth reading, which are pure marketing, and what has changed in the year between the original 2025 frame and the 2026 update. Two of the keywords this page targets are explicit about the year (2025 and 2026), which is what the procurement community and the governance practitioners are searching when they want to know whether the principles landscape has shifted enough to revisit. The honest answer is: it has shifted, but not in the direction the principles community claims.

Why “governed AI” is the operational frame

The vocabulary fight matters because the wrong vocabulary produces the wrong artefacts. “Responsible AI” pushes the team toward policy documents and principles statements. “Governed AI” pushes the team toward inventories, deployment gates, evaluation logs, and incident runbooks. The first set is necessary for stakeholder communication and is sufficient for it. The second set is necessary for the system to actually be governed and is the harder work.

The reason the substitution happens — responsible-AI vocabulary used where governed-AI vocabulary is needed — is structural rather than cynical. Responsible-AI material is easier to produce, easier to communicate to a board, easier to sign off on, and easier to publish externally. Governed-AI material is harder to produce, requires technical expertise the strategy team often does not have, takes longer to sign off on because the controls have to actually work, and is rarely externally visible. The incentive gradient runs against governed AI. The strategy team that produces both sees the responsible-AI document earn external recognition and the governed-AI controls earn nothing observable. The next strategy refresh allocates more time to responsible AI and less to governed.

The result, observed across the dozen-plus governance programmes I have audited since 2024, is the same. The responsible-AI policy is rich, current, and well-cited. The deployment-gate procedure is thin, outdated, or absent. The inventory is incomplete. The incident runbook does not exist. The auditor arrives and the gap surfaces. The governance programme is judged on the substantive controls, not on the policy. The policy work has been the wrong work to over-invest in.

The fix is not to abandon the principles work. It is to put it in proportion. The principles are the language layer for board communication and external positioning; they are about 15% of a working governance programme by effort. The controls are about 70%. The remaining 15% is the cross-walk — a traceability matrix that connects the two — the work that lets the CISO explain to the board that the technical controls implement the principles the board signed off on. Most enterprise governance programmes I have read invert these proportions, spending 70% on principles and 15% on controls. The inversion is what the consulting market sells; it is not what works.

The principles documents, ranked by usefulness

Five categories of principles documents dominate the 2026 landscape. They are not interchangeable. They serve different purposes, and the strategy team that adopts one without understanding the purpose ends up using the wrong tool.

The OECD AI Principles (2019, updated 2024). The reference standard for intergovernmental framing. Five principles — inclusive growth, human-centred values, transparency, robustness, accountability — at a level of generality that admits almost any specific control set as compliant. The OECD principles are useful as the international-policy reference that almost every other framework cross-walks to, and they are useful as board-level language because the board has heard of the OECD. They are not useful as a control set. The honest read: cite them, do not operationalise them.

The Asilomar AI Principles (2017). A research-community statement from the Future of Life Institute, signed by a large group of AI researchers. Twenty-three principles ranging from research norms to long-term safety. The Asilomar set is historically significant as the first widely-cited statement of long-term AI safety concerns from the research community itself, and it remains the cleanest articulation of the capability-safety arguments that underpin the Anthropic Responsible Scaling Policy and similar work. It is less useful for enterprise governance because most of its principles are research-norm principles rather than deployment-control principles. The honest read: useful intellectual context, particularly for organisations whose AI work has any frontier-capability exposure; not the basis for an enterprise control set.

Microsoft Responsible AI Standard (v2, 2022, with subsequent operational guidance). The corporate document that most cleanly translates principles into operational requirements. Microsoft’s standard names six principles and then maps each one to specific impact-assessment requirements, oversight requirements, and deployment-gate requirements for products built inside Microsoft. The standard is unusual in being publicly available, fully detailed, and reflective of how Microsoft actually governs its own product portfolio. The honest read: read it, adapt it, and use it as the model for what a corporate responsible-AI document looks like when it is meant to do operational work. It is not perfect — the impact-assessment process is heavy and biased toward Microsoft’s specific product shape — but it is the corporate document closest to a working framework. Reference: Microsoft Responsible AI Standard, v2.

Google AI Principles (2018, updated periodically) and SAIF (Secure AI Framework). Google’s principles document is shorter than Microsoft’s, but the company has separately published SAIF as the technical framework that sits underneath. The honest read on Google’s work is that the principles document and the SAIF document together produce a coherent governance posture; either one alone is incomplete. The principles handle the board-facing language; SAIF handles the technical controls. The separation is honest in a way most corporate documents are not — Google does not pretend the principles document is itself a control framework. The principles are at ai.google/principles; SAIF is at saif.google.

Anthropic Responsible Scaling Policy (RSP, originally 2023, multiple revisions through 2025–2026). The corporate document that has done the most to shift the conversation since 2024. Anthropic’s RSP defines capability thresholds and commits the company to specific safety measures triggered when models cross those thresholds. The RSP is structurally different from the other corporate documents — it is not a principles document; it is a conditional commitment framework. The honest read on the RSP is that it has become the pattern the safety-conscious labs are converging on (OpenAI’s Preparedness Framework is shaped similarly; DeepMind’s Frontier Safety Framework is shaped similarly), and that pattern is more useful for enterprises with any high-capability AI exposure than the older principles-set pattern. The RSP itself is at anthropic.com/rsp-updates.

The two documents I would skip are most of the consulting-firm responsible-AI documents and most of the “ethical AI” frameworks that have proliferated since 2023. The consulting-firm documents are usually derivative of the corporate ones with less operational specificity and more brand alignment; they are sold as the basis for an engagement but rarely contain content the corporate originals do not cover better. The “ethical AI” frameworks are usually principles documents at a higher level of generality than the OECD set, which is to say at a level of generality where they cannot be operationalised at all. The honest read: pick the most useful corporate document for your context (Microsoft if you are operationally heavy, Anthropic if you have frontier-capability exposure, Google if you want the clearest separation between principles and controls), and skip the derivative material.

What changed between 2025 and 2026

The original frame for this piece, when I started writing about the responsible-AI cluster in late 2024, was that the principles documents were doing less operational work than their adopters claimed and that the cleaner move was to focus on the operational control set. That frame holds. What has changed in the year since is the regulatory landscape and the maturity of the safety-lab pattern.

The first shift is the EU AI Act August 2026 high-risk obligations. The conversation in boardrooms has shifted from “is our AI responsible” to “is our AI Act-compliant.” The two questions have substantial overlap — most of what the Act requires for high-risk systems is recognisable as responsible-AI practice — but the framing has consequences. Boards now ask compliance questions where they used to ask principles questions. The shift is mostly healthy; compliance questions have answers that can be checked, principles questions have answers that can be performed. The risk is that responsible-AI work that is not directly required by the Act gets deprioritised, which would be a mistake for the medium-tolerance use cases the Act does not specifically regulate.

The second shift is the maturation of the safety-lab pattern. In 2024 Anthropic’s RSP was a single-lab commitment that other labs were watching but not adopting. By mid-2026 the pattern — capability thresholds, conditional safety commitments triggered at threshold, third-party evaluation regimes — has become the visible shape of how safety-conscious labs govern themselves. This matters for enterprises with high-capability AI exposure because the pattern is more concrete than the principles documents and more directly applicable to enterprise contexts. An enterprise that adopts the RSP pattern as the model for its own internal governance of high-capability work has a more operational framework than one that adopts the OECD principles.

The third shift is the cross-walking work between the principles documents and the formal compliance frameworks. NIST has published cross-walks between the AI RMF and various corporate principles documents. ISO/IEC 42001:2023, the AI management system standard, provides a certifiable structure that some corporate principles documents now map their controls against. The cross-walks lift the principles from rhetoric to compliance scaffolding for the organisations that take the work seriously. The principles are no longer standalone; they are increasingly the language layer on top of NIST or ISO control sets. That is the right direction. It is also the direction that makes responsible-AI policy work look less impressive on its own and more like ordinary compliance scaffolding, which is the honest read of what it has always been.

What a principles document is actually for

The principles document is for three things, and pretending it is for more than that is the source of most of the confusion in the cluster.

Board communication. The board cannot engage with the technical content of a NIST AI RMF cross-walk or an ISO 42001 control set. The board can engage with five principles framed in plain language. The principles document gives the board the vocabulary to ask the right questions of the CISO, the CAIO, and the DPO. Without the vocabulary, the board’s oversight defaults to either silence (it does not engage at all) or panic (it engages at the wrong altitude). The principles are the scaffolding for board engagement.

Hiring conversations. Candidates for AI engineering and governance roles increasingly ask about an organisation’s responsible-AI posture before they sign. The principles document is the artefact that answers the question at the appropriate altitude for a hiring conversation. The candidate is not going to read the deployment-gate procedure; the candidate will read the principles. A current, signed, board-endorsed principles document signals to candidates that the organisation has thought about the work. A missing one signals the opposite.

External positioning. Customers, partners, regulators, and the public ask whether an organisation has a responsible-AI posture. The principles document is the artefact that answers the question for external audiences. It is not the operational reality of the governance programme; it is the public-facing representation of the values the programme commits to.

Three uses. None of them include “operational control set.” Strategy teams that allocate principles-document effort against the three uses above produce useful documents at moderate cost. Strategy teams that allocate principles-document effort against an implicit fourth use (“the foundation of our governance programme”) produce expensive documents that do not deliver the foundation they were supposed to deliver, because the foundation lives in the control set the principles do not contain.

What I would do on Monday morning

If you have no principles document, adopt the Microsoft Responsible AI Standard as a starting point, adapt it to your context over four to six weeks, and have the board sign it. The Microsoft standard is the most operationalised of the publicly-available corporate documents, and the adaptation work is mostly removing Microsoft-product-specific language and adding your-industry-specific language. Do not write a principles document from scratch; the cost-to-value ratio is bad and the existing corporate documents are better engineered than what most enterprise teams will produce.

If you have a principles document that is not connected to any operational control set, the work is not to rewrite the principles. It is to build the control set and then write a one-page cross-walk between the existing principles and the new controls. The cross-walk is the artefact that turns the principles document from theatre into scaffold. Most enterprises that have a principles-document-without-controls problem do not need a better principles document; they need controls and a cross-walk.

If you have both a principles document and a control set, audit the cross-walk. Most cross-walks I have read are stale by twelve to eighteen months; the principles document gets refreshed on a different cadence from the control set, and the cross-walk drifts. A current cross-walk is a quarterly maintenance commitment, not a one-off artefact. Reserve the capacity.

If you are reading this because you have been asked for a “responsible-AI governance tools” recommendation, the governance tools comparison is the place to start. The honest read on tools in the responsible-AI category specifically is that they cluster into two groups: tools that help with the principles-and-policy work (OneTrust, ServiceNow extensions, the policy-management platforms) and tools that help with the control-and-evaluation work (Credo AI, Holistic AI, the model-lifecycle platforms). Buying the first when you need the second is the most common procurement mistake in the cluster. Decide which problem you are solving before you write the RFP.

If you are governance-led and reading this in 2026 because the Act deadline has surfaced gaps you did not know about, the parent governance hub and the CISO piece are the right places to start. The responsible-AI work is downstream of the operational controls; the controls are the load-bearing element. The principles are the language. The principles without the controls are theatre. The controls without the principles are functional but politically unsupported. You need both, in the right proportions, and the right proportion in 2026 is roughly 70-15-15 controls-principles-crosswalk, not the inversion the consulting market sells.

Sources & methodology

If you have run a responsible-AI programme that succeeded against a different ratio, send the description and I will publish the comparison from the next refresh. The interesting outcome of public governance work is the disagreements, not the agreements.

Frequently asked questions

Are 'responsible AI' and 'AI governance' the same thing?
No, and the distinction matters operationally. Responsible AI is a board-communication shape — a vocabulary for talking about fairness, transparency, accountability, and safety in language a non-technical board can engage with. AI governance is the operational control set — the inventory, the deployment gates, the evaluation regimes, the incident response runbooks. The first is necessary for stakeholder communication; the second is necessary for the system to actually be governed. Conflating them produces either policy documents with no deployment-gate effect or technical controls with no executive coverage.
Which corporate responsible-AI principles documents are worth reading?
Microsoft's Responsible AI Standard, Google's AI Principles (read alongside the SAIF technical framework), and Anthropic's Responsible Scaling Policy. The first is the most operationalised; the second is the cleanest at separating principles from technical controls; the third is the most useful as a model for thinking about capability thresholds. The two I would skip are most of the consulting-firm responsible-AI documents — they are derivative of the corporate ones with less operational specificity — and any document whose first commitment is to 'human-centric AI' without naming what the phrase operationalises into.
What has changed in the responsible-AI landscape between 2025 and 2026?
Three things. First, the EU AI Act's August 2026 high-risk obligations have shifted the conversation from principles to compliance — boards now ask whether the programme is Act-ready, not whether it is responsible. Second, Anthropic's Responsible Scaling Policy has matured from a single-company commitment into a pattern the safety-conscious labs are converging on, which gives boards a more concrete model than the principles documents do. Third, the corporate principles documents have started getting cross-referenced against the NIST AI RMF and ISO/IEC 42001:2023, which lifts them from rhetoric to compliance scaffold for the labs that take the work seriously.
Should we adopt a responsible-AI framework if we already have governance and ethics policies?
Probably not as a separate artefact. Most enterprises already have governance, ethics, and risk policies that cover the substantive ground; adding a responsible-AI policy on top usually produces parallel documents that drift. The cleaner move is to extend the existing governance documentation with an AI-specific annex that names the model-lifecycle controls the existing policies do not cover, and to pull the principles language from the corporate responsible-AI statements where it is useful for board communication. One document, with an AI-specific section. Not two parallel documents that have to be reconciled at every refresh.