Responsible AI as an Operating Model
In one sentence: a responsible AI principle changes nothing until it has been converted into an artefact somebody produces, at a gate somebody passes, with a name against it.
The problem
Most large organisations now have a set of AI principles. Fairness. Transparency. Accountability. Human oversight. Robustness. They are almost always reasonable, and they are almost always inert.
They are inert because a principle is not a control. It does not say who produces what, at what point, to what standard, or what happens when it is missing. So it sits in a policy document, and the first team to build something real meets the requirements at the end, in a review, phrased as questions nobody warned them about.
The team experiences that as governance being slow. The control function experiences it as a team that arrived unprepared. Both readings are fair and neither is the cause. The cause is that nothing translated the principle into work, which is the gap most AI governance programmes are actually carrying.
The model
Every principle has to survive three translations before it changes anything.
Principle to question. What is this principle asking about this specific system? Fairness is not a requirement. "Which groups could this treat differently, on what data, and how would we detect it" is a requirement, and it is answerable.
Question to artefact. What document, test, dataset or record answers that question well enough for an accountable person to sign? This is the step almost everyone skips, and it is where most of the recoverable time in governance is lost, because teams produce the wrong evidence and then produce it again.
Artefact to gate and owner. At which point in the lifecycle must the artefact exist, who produces it, and who accepts it? A responsibility not attached to a point in time is a preference.
The test of a responsible AI programme is not whether the principles are good. It is whether you can name, for any system currently in flight, the artefact that satisfies each principle, the gate it is due at, and the person who owns it. If you cannot, the principles are decoration and everyone involved already suspects it.
What changes when the model is not yours
All of the above was built for models an organisation trains itself. A bought or hosted foundation model breaks four assumptions at once, and this is where most existing model governance is discovered to be specific rather than principled.
Provenance becomes attestation. You cannot inspect the training data. The question moves from what the model was trained on to what you are sending it, what you are accepting back, and what the vendor will state in writing.
Validation becomes evaluation. There is no held-out test set that settles the matter. What replaces it is a graded set of cases representing how the thing will actually be used, run repeatedly, with results a non-specialist can read and challenge.
Monitoring becomes behavioural. Statistical drift detection does not catch a system that is confidently wrong in a new way. Sampled outputs have to be read by somebody who knows what good looks like, on a schedule, as part of the service rather than as a favour.
The unit of change is not yours. The vendor can update the model underneath you. Re-evaluation becomes a scheduled obligation and a contractual question, not an event you choose to trigger.
The useful finding is that the operating model survives all four. The artefacts change completely. The structure of principle, question, artefact, gate, owner does not. If the governance you built for traditional machine learning cannot absorb a bought model, it was never a model of anything. It was a description of one case.
How to use it
Take the principles your organisation has adopted as given. Do not rewrite them and do not open the wording argument. That argument is available to anybody, it consumes months, and it changes nothing downstream.
For each principle, write the question it asks of a system, in the vocabulary your engineers already use. Then name the artefact that answers it, and set the depth of that artefact against the risk of the system. A low risk internal tool and a customer facing decision cannot carry the same evidence pack. Pretending otherwise is precisely how capable people learn to route around the process.
Attach each artefact to a gate that already exists. Responsible AI does not need its own committee. It needs to be present in the forums that already meet, holding the decisions those forums already own.
Then publish the map, and name who is accountable for keeping it current. An out of date map is worse than no map, because people follow it and are wrong.
When to use it
When a set of principles has been adopted and nothing observable has changed. When teams are consistently asked for AI evidence late. When a first generative AI use case is arriving and the existing model governance was written for something else entirely. And before anybody commits to a date for responsible AI being implemented, because the honest answer depends entirely on how many of these translations already exist.
An example
An internal assistant that drafts responses for staff from an approved knowledge base. Four principles, translated.
- Human oversight. The question: at what point does a person see the output, and can they tell it was machine generated? The artefact: the interaction design plus a record of where the review step sits. The gate: design review, before build.
- Transparency. The question: can we reconstruct what produced a given answer? The artefact: prompt, retrieval and response logging, with a retention period agreed with privacy rather than assumed. The gate: pre-production.
- Robustness. The question: how does it behave on the cases it was not designed for? The artefact: an evaluation set including adversarial and out of scope inputs, with results. The gate: pre-production, and again whenever the vendor changes the model.
- Accountability. The question: who owns this on a Tuesday when it is wrong? The artefact: a named service owner and an agreed support model. The gate: promotion.
None of that is novel and none of it is difficult. Written down before the build it is a fortnight of work. Discovered afterwards it is a quarter, and the quarter is spent under pressure with an audience.
Limitations
It assumes the principles are settled. Where they are genuinely contested, this converts a values argument into a documentation exercise, which buries the disagreement rather than resolving it. That is a real cost and it should be named rather than enjoyed.
It says nothing about whether a system should exist. Every artefact described here can be produced, in good faith, for a use case that should have been declined. That decision sits before this one and belongs to people with the authority to make it. It is also written to frameworks rather than to law. NIST and ISO give you a structure; they do not tell you what you owe a regulator. In New Zealand that starts with the Privacy Act 2020, whose principles grant access and correction and limit retention by purpose, and with the Reserve Bank of New Zealand's prudential requirements. For Australian-owned banking groups the APRA prudential standards apply at group level, including CPS 234 on information security and CPS 230 on operational risk, which took effect on 1 July 2026 and pulls service providers and critical operations into scope. Check the instrument before you borrow the framework.
Proportionality is the hardest part and this does not solve it. Deciding which systems need the full pack is judgement, and erring heavy is how an organisation teaches its best teams to work around the process quietly.
And it is weakest exactly where the technology is moving faster than anyone can specify evidence for. There the honest position is a short review cycle and a written statement of what you do not yet know how to test, which is a harder thing to put in front of a committee than a framework that claims to be complete.
References
- NIST, "Artificial Intelligence Risk Management Framework (AI RMF 1.0)". January 2023. Organises the work into Govern, Map, Measure and Manage, which is a useful cross-check against whichever control functions your organisation happens to have. Version 1.0 is the current published edition and the framework is under revision, so treat it as a structure rather than a settled specification
- NIST, "Generative Artificial Intelligence Profile" (NIST AI 600-1). July 2024. The companion profile for generative AI, and a reasonable starting list of what changes when the model is not one you trained
- ISO/IEC 42001:2023, "Information technology, Artificial intelligence, Management system". The first AI management system standard, for when the artefacts have to line up with something certifiable