Stay connected: follow us on LinkedIn and explore more at
www.CherryHillAdvisory.com.
.svg)
Subscribe now to join the Risk Register community:
Most organizations now have an AI governance committee. Fewer have one that has ever said no to anything.
That is the quiet problem with the committee as a structure. It is easy to stand up and easy to mistake for governance. Having the document is not the same as having the governance, and a committee that meets is not the same as a committee that decides.
For internal audit, the committee raises two questions at once. Who should actually sit on it? And when the chief audit executive gets the invitation, what does internal audit own in that room, and what does it have to leave to management?
An AI governance committee exists to make and record decisions about AI risk: which use cases go ahead, under what conditions, who owns them once they are live, and when they get retired. If it is not doing those four things, it is a discussion group with a calendar invite.
We see the same pattern across organizations of every size. There is a policy, there is a charter, and there is a steering committee that meets. What is missing is real ownership by that committee. Deployments reach it after the business has already committed, nobody asks a hard question, no change log is kept, and the committee validates whatever the deployment team already decided. We call that rubber stamp approval, and it is the weakest form of AI governance there is, precisely because it looks like the strongest.
The test is simple and slightly uncomfortable. Pull the committee's minutes for the last two quarters and count the use cases it sent back, conditioned, or declined. If the number is zero, the committee is not governing. It is witnessing.
When did your committee last change the outcome of a deployment decision? The answer usually comes down to who is sitting at the table.
The right AI governance committee members are the people who own the risk, not the people most excited about the technology. The NIST AI Risk Management Framework is direct about this. Under its GOVERN function, subcategory 2.1 calls for roles, responsibilities, and lines of communication for AI risk to be "documented and are clear to individuals and teams throughout the organization," and subcategory 2.3 says executive leadership "takes responsibility for decisions about risks associated with AI system development and deployment." Subcategory 3.1 adds that AI risk decisions should be "informed by a diverse team," with diversity of disciplines, experience, and expertise named explicitly.
In practice, that points to a committee chaired by an accountable senior executive with authority to stop a deployment. Around that chair, the business owners who define use cases and own the data. Technology and security, who own infrastructure and configuration risk. Legal and privacy, who own compliance exposure. The second line (risk and compliance), who own the AI risk taxonomy and the monitoring. Procurement or third-party risk, because a large share of your AI arrives inside tools you already bought.
Every seat maps to a risk someone can be held accountable for. If a seat exists because a person asked to be included, the committee gets bigger without getting any better.
Internal audit's seat works differently, but one structural failure is worth naming first.
Shared ownership in AI governance very quickly becomes no ownership. The business assumes IT owns the model, IT assumes the business owns the use case, and when something goes wrong the committee discovers it built a finger-pointing exercise in waiting.
The fix is less glamorous than a new charter. It is a RACI, written down, for every AI use case above a risk threshold the committee sets, with one named owner per use case and one named owner for the inventory itself. The board has already been told this matters. Our post on the AI governance questions every board should ask management starts in the same place: a named leader who owns AI risk, and a way for bad news to reach the board in time.
Ownership also has to survive go-live. In a live poll during our AI governance webinar on building and reviewing AI governance, roughly three quarters of the internal auditors attending reported no formal post-deployment monitoring process for AI, either relying on informal user feedback or having nothing in place at all. Approval without monitoring is a one-time opinion about a system that keeps changing.
Who on your committee would notice if an approved model started drifting next month? Internal audit's seat starts there.
Internal audit should have a seat at the AI governance committee, and it should not be the one making the decisions. Those two statements are not in tension, and holding both is what makes the seat valuable.
Being in the room early is where internal audit adds the most. Pre-implementation reviews, questions about the vendors being selected, and a view on control design all shape the outcome while it is still cheap to change.
The IIA's Three Lines Model gives the committee a clean way to describe the seat. Management and the second line own the risk and the controls. Internal audit provides independent assurance and advice, and under Principle 5 its "independence from the responsibilities of management is critical to its objectivity, authority, and credibility." So internal audit can advise, challenge, and ask the question nobody else in the room wants to ask. It does not vote a use case through, own the inventory, or sign off on a model's controls.
The same document puts it plainly: "independence does not imply isolation," a point we made when the IIA refreshed its Three Lines position. We lean toward objectivity as the guiding principle, contributing in the room and managing independence transparently, which brings us to where the Standards draw the line.
The 2024 Global Internal Audit Standards are specific about where that line sits. Standard 2.2, Safeguarding Objectivity, says internal auditors "must refrain from assessing specific activities for which they were previously responsible," and that objectivity is presumed impaired when an auditor provides assurance over an activity they had responsibility for "within the previous 12 months."
Apply that to AI. If the chief audit executive chairs the committee, or internal audit ends up owning the approval workflow, the function has taken on a management responsibility it will later be asked to audit. Standard 7.1, Organizational Independence, addresses exactly this situation. When the chief audit executive has ongoing roles beyond internal auditing, the responsibilities and safeguards "must be documented in the internal audit charter," and if those areas are subject to internal auditing, alternative assurance must be established, such as "contracting with an objective, competent external assurance provider that reports independently to the board."
The Standards also give internal audit a legitimate way to help without crossing over. They define advisory services as advice "without providing assurance or taking on management responsibilities," and list advising on the design of new policies, processes, and systems as an example. That is the committee seat, described in the Standards' own words.
Full stop: if internal audit holds the pen on AI approvals, someone else has to audit AI governance.
Internal audit owns one thing outright in AI governance: independent assurance, reported to the board, on whether the governance actually operates. That includes the committee itself.
A useful audit of the committee covers four areas. Whether the AI inventory is complete, including AI embedded in vendor tools. Whether the committee's decisions are evidenced, with challenge, conditions, and a change log. Whether post-deployment monitoring exists for approved use cases and someone acts on it. And whether ownership is documented at the use-case level rather than assumed. The NIST AI RMF supports the independence of that work: MEASURE 1.3 calls for assessments involving internal experts "who did not serve as front-line developers for the system and/or independent assessors."
The frameworks are complementary here. We use the IIA's approach to structure the audit work and the NIST AI RMF to define what good governance should look like, so the function is evaluating against a recognized standard rather than inventing one. Our AI auditing guide is built on that pairing.
Verifiability is the test. A control that exists on paper but cannot be independently evidenced is a finding, and that includes the committee.
The audit committee needs internal audit's independent read on AI governance, not a summary from the AI committee about itself. Boards are asking about AI inventory and oversight, and management's own reporting cannot answer whether management's own committee is working.
The Standards already require the chief audit executive to confirm organizational independence to the board at least annually and to disclose impairments. Adding the AI committee seat to that conversation, and to the internal audit charter, turns a potential independence question into a documented, board-approved role.
If the honest answer to "what is closing the AI governance gap here" is nothing on a current cadence, that belongs in front of the audit committee now, not at the next planning cycle. For a wider view of the gaps we see most often as adoption scales, our piece on the ten things to get right in AI governance goes further on inventory, vendor AI, and rubber-stamp review.
If you are defining internal audit's seat on an AI governance committee, or planning the first audit of one, our AI governance advisory team works alongside internal audit functions on exactly this.
Reach out to Cherry Hill Advisory and we will work through it with you.
The next disruption in AI will not wait for your committee's quarterly meeting. The organizations that handle it well will be the ones whose committee decides, whose owners are named, and whose internal audit function can tell the board, with evidence, that both are true.
Subscribe now to join the Risk Register community:
