An AI governance framework for executives comes down to one decision, made before go-live: a named person with real authority signs for the system’s risk, and that person sits in your business, not the supplier’s. The published frameworks all point the same way. This article shows how to make that decision, test it and rehearse it.
Key takeaways
- Why ownership of an AI system is usually settled too late, and what the main frameworks expect of executives.
- How to apply the Signature Test, and who can and cannot pass it.
- What the signer needs in hand, and how to rehearse the handover before launch.
Why the ownership decision gets made too late
Most organisations know the question exists. Few have answered it. A Morgan Stanley Institute for Sustainable Investing survey of 200 executives involved in AI governance found that around 90% say responsibility for AI governance and risk has been defined or is being defined, but just under half say it is fully allocated across functions, senior executives and the board, according to Morgan Stanley.
The same gap shows at board level. Of 3,048 US companies across the Russell 3000 and S&P 500, only 245 (8%) disclosed board-level oversight of AI, according to ISS STOXX, using data from January 2026. Disclosure is not the same as practice, but it shows how little is written down.
The cause is timing. During the build, the engineers hold the system and the sponsor holds the budget. Nobody holds the risk. By go-live the system is in front of customers or staff, and the first person asked to answer for it is whoever happens to be nearest.
What an AI governance framework expects of executives
An AI governance framework is not a document to file. The NIST AI Risk Management Framework describes its Govern function as cross-cutting, designed to inform and be infused throughout the other three functions, according to NIST’s AI Resource Center. Its accountability category includes this subcategory, which is addressed to executives directly:
Executive leadership of the organization takes responsibility for decisions about risks associated with AI system development and deployment.
Two neighbouring subcategories matter just as much. NIST says roles, responsibilities and lines of communication should be documented and clear to individuals and teams throughout the organisation, and that once the Map function is complete, users should have enough context to inform an initial go/no-go decision on whether to deploy. The go/no-go decision is the point where ownership has to be explicit.
ISO/IEC 42001 takes a similar line. According to Konfirmity, its leadership clause puts the AI policy, role assignment, accountability and resourcing with top management. Neither standard tells you which individual to name. That choice is yours, and it needs a test.
The Signature Test: who signs before go-live
The Signature Test is a single question applied to every system before it launches. If the answer is a role rather than a person, or a team rather than a role, the system is not ready.
Apply the Signature Test:
Who signs the risk statement before go-live?
The risk statement is short. It names what the system is allowed to do, what it must never do, what failure would cost, and who can stop it. The signature turns that statement from a description into a commitment.
The signer must be able to act on it. A recent preview report from Open Future Forum, which says it synthesises operator research rather than surveying directors, defines an accountable owner as the executive or business leader who can approve, pause, redesign or retire the system. Apply that definition literally. A sponsor who can approve but cannot pause has not passed.
The same report warns that being named in a survey answer does not demonstrate that decision rights are documented. Write the rights down.
Who can sign, and who cannot
Candidates are easy to list and hard to choose between. The Open Future Forum data shows how uneven the practice is: the CEO is named in 49 percent of sign-off answers and finance in 31 percent, while 13 percent name no single owner. It also notes that respondents tend to name the role closest to their own seat, which is a reminder that every function will volunteer itself.
A workable rule is to pick the business owner whose outcomes the system changes, with the authority to stop it. The supplier cannot sign, because the supplier does not carry the consequence. The engineer who built it cannot sign, because that person rarely controls budget or policy. A committee cannot sign, because a committee cannot be asked to switch the system off at two in the morning.
Specialist functions still have a place. Open Future Forum’s committee table gives the CFO the lead on spend and value claims, the CISO or CIO the lead on identity and access, and general counsel the lead on regulatory exposure. They support the signer. They do not replace the signer.
Board attention helps too. According to Protiviti, 63% of boards in organisations with high AI returns put AI on every meeting agenda, against 13% in the low-return group. That is an association, not proof of cause, but it suggests that regular sight of named owners is what mature organisations do.
What the signer needs in hand before go-live
A signature without evidence is a formality. Before anyone signs, the owner should be able to see five things.
- An inventory entry. A risk register under the Govern function tracks each system’s owner, intended use, risk classification and open mitigation items, according to Cyberhaven.
- A stop mechanism. One governance checklist from James Kenefick advises that the kill switch and isolation capability should be built before deployment, not after an incident.
- Bounded access. Open Future Forum found that of 49 applicable access responses, 18 report shared service accounts and 24 report per-agent credentials. A signer cannot answer for actions that cannot be attributed.
- A human review path. Morgan Stanley reports that 69% of respondents tell employees that AI outputs must go for separate human review in higher-risk situations.
- A decision-rights record. Open Future Forum suggests it should state who proposes, funds, approves, operates, monitors and can stop each material system.
What happens once the system is live, including incident review and ongoing monitoring, is a separate subject. This article stops at the signature.
Who carries the decision into the build
Ownership decisions are usually made in a steering meeting and forgotten in the build. Something has to carry them from the contract into the system. That is the job of a Forward Deployed Engineer, an engineer embedded with the customer who builds the system and hands it over inside the customer’s business.
The Certified Forward Deployed Engineer (CFDE)™ exists because that role had no common standard for what good handover looks like. AIU teaches the deployment lifecycle in seven stages, and ownership questions run through all of them.
AIU teaches the deployment lifecycle in seven stages: post-sale handoff, discovery, scoping, build, deploy, iterate and hand-back.
The last stage matters most to an executive. A system handed back without a named owner who understands it has not really been handed back. The owner’s side of that exchange can be rehearsed before launch, and the rehearsal tells you more than any slide.
AIU describes one such exercise as the handover rehearsal:
Five tasks the client team performs while the deployment engineers observe.
If the client team cannot do those tasks with the engineers watching, the signature is premature. Fix the gap first, then sign.
AIU also teaches how the engineers on your project are measured, which is worth knowing before you appoint one:
AIU teaches that Forward Deployed Engineers are measured on three things: deployment velocity, customer success and product feedback quality.
Product feedback quality is the one executives overlook. It is how what the deployment taught the engineers reaches the people who own the system.
Next steps for an executive team
Take your list of systems due to launch this quarter. For each, ask the Signature Test question and write the name next to it. Any blank, any committee and any supplier is a launch risk. Then check that the named person can pause the system, holds the evidence listed above, and has watched their own team run the handover.
If you want to understand the engineering role that carries this work, AIU’s programme is a place to start.
The CFDE credential and who issues it →
Frequently asked questions
What is an AI governance framework for executives?+
It is the set of roles, policies and decision rights that tell an organisation who is accountable for each AI system. For executives, the practical core is a named owner who approves the go-live decision, signs the risk statement and can pause or retire the system. Frameworks such as the NIST AI RMF and ISO/IEC 42001 place that responsibility with senior leadership.
Who should own an AI system after go-live?+
A business leader inside the customer’s organisation who can approve, pause, redesign or retire the system. The supplier and the engineers who built it can support the owner, but they cannot carry the organisation’s risk. The owner should be named, and the decision rights written down, before launch.
What is the Signature Test?+
The Signature Test is AIU’s pre-launch question: who signs the risk statement before go-live? If the answer is a team, a supplier or a blank, the ownership decision has not been made and the system is not ready to launch.
