The AI governance committee has 34 open decisions. The oldest has waited six weeks. Product teams have started calling their tools “experiments” so they can work around the queue, while procurement renews two AI vendors that nobody added to the inventory.
That organization does not need another principles workshop. It needs decisions to move.
AI governance consulting should turn a pile of requests, exceptions, incidents and stale approvals into an operating service. The test is visible: ordinary cases move on time, consequential cases receive deeper review, and nobody has to guess who can say yes or no.
Measure the queue before maturity
Begin with the cases already waiting. Pull requests from procurement, security, architecture, legal, privacy, model-risk, product and business teams. Include decisions made outside the formal process. Those workarounds reveal where the current route costs more than it protects.
Build a queue snapshot:
| Queue field | What to record |
|---|---|
| Case | The AI use, purchase, system change, exception or incident decision |
| Submitted | Date and route by which the case arrived |
| Requester | Person accountable for supplying missing evidence |
| Decision owner | Person with authority to approve, reject or stop |
| Current state | New, waiting for evidence, under review, decided or expired |
| Wait reason | Missing fact, unavailable reviewer, disputed authority or no route |
| Consequence | Release, purchase, user impact or risk affected by the delay |
| Next action | One named action, owner and due date |
Do not start by assigning a maturity score. A score can wait. The queue shows which decisions the governance system fails to complete today.
Set entry criteria that requesters can meet
A case should not enter review with “we want to use AI” as its entire scope. The intake needs enough information to route the decision without asking the requester to complete a full risk assessment alone.
Require a small core:
- business purpose and accountable owner
- affected users or parties
- system boundary and vendor names
- data categories and sources
- output or action the system can produce
- environments and user population
- target decision date
- known legal, contractual or policy constraints
Return an incomplete case with the missing fields named. Do not let it sit in a review state while the clock runs and nobody knows who owes the next fact.
The intake form should use the language of the requester. Internal governance staff can map it to control frameworks after the business use is understood.
Route decisions by type before risk
One risk score cannot route every case. Buying a vendor, approving a new use, changing a production system and containing an incident need different people and clocks even when their risk looks similar.
Use separate lanes:
| Lane | Typical decision | Required authority |
|---|---|---|
| New use | May this business task use AI under the proposed boundary? | Business owner plus the control owners named by scope |
| Acquisition | May the organization contract for this vendor and service? | Procurement owner with security, data and legal input where applicable |
| Build or release | May this system version enter the next environment? | Release authority backed by evaluation and operating evidence |
| Material change | Does an approved use need reassessment? | System owner and the authority that owns the changed risk |
| Exception | May a defined requirement be deferred under limits? | Named risk-acceptance authority |
| Incident | Must the system be contained, changed or stopped? | Incident authority with business and technical ownership |
| Retirement | Can use, access, data and dependencies be closed? | Business and system owners |
Risk tiering belongs inside those lanes. A low-impact vendor renewal and a low-impact internal change still need different records.
NIST’s AI RMF Core organizes AI risk work into Govern, Map, Measure, and Manage functions. NIST says its actions are not a checklist or necessarily an ordered set of steps. That makes the framework useful as a source of outcomes, while the organization remains responsible for its own routing.
Give each state a clock and an owner
Governance becomes a black hole when every submitted case is simply “in review.” Define states that expose the next action.
For example:
- Intake review checks that the case can be routed.
- Evidence pending returns specific gaps to the requester.
- Control review records specialist findings and conditions.
- Decision ready confirms that the authority has the required packet.
- Decided records approval, rejection, conditions and recheck events.
- Expired closes a decision that no longer applies.
Set service expectations by lane and tier. The clock should stop when the requester owes evidence and restart when it arrives. Record the actual reason for delay. “Governance” is not a useful reason.
The queue should also have an escalation route. If a decision owner misses the window, the case moves to a named alternate or is denied by timeout under a written rule. Silence must not become approval.
Match evidence to the decision
A consultant earns their fee by making evidence proportionate and explicit. A staff drafting tool does not need the same packet as an agent that can alter a customer’s account.
For each lane and tier, define minimum proof:
| Evidence family | Examples |
|---|---|
| Purpose and boundary | Approved use, affected parties, exclusions, system and data flow |
| Performance | Representative cases, outcome checks, known limits and failed cases |
| Authority | Permissions, approval rules, denied actions and exception path |
| Security and privacy | Threats, access controls, data handling, tests and open findings |
| Operations | Monitoring, incident route, recovery, rollback and support owner |
| Supplier | Contract scope, subprocessors, change notices, exit and data return |
| Decision | Conditions, approver, date, expiry and reassessment triggers |
The packet can reference existing evidence. It should not demand the same document in three templates.
The NIST AI RMF Playbook says its suggested actions are voluntary and organizations may select what fits their context. A consulting proposal should therefore explain which outcomes apply to each lane and how the evidence will be checked. Copying the entire Playbook into a tracker is not tailoring.
Treat exceptions as temporary inventory
Exceptions are not footnotes to approved cases. They are work items with their own owners and clocks.
An exception record needs the missing requirement, reason, affected systems and people, compensating control, approval authority, monitoring, expiry and action at expiry. The action might revoke access, stop the system or return the case to normal review.
Show expiring exceptions in the same operational queue. Review them before the deadline. If an exception renews repeatedly, ask whether the rule is wrong, the remediation has no owner or the organization is accepting a permanent condition without saying so.
Feed incidents and changes back into decisions
An incident should locate the original approval quickly. Use one system identifier across the inventory, decision record, vendor review, release evidence and incident ticket.
After containment, the incident can reopen the decision with new facts. The reopened case should state what changed: expected behavior, measured impact, control effectiveness, residual risk or recovery ability.
The same applies to ordinary change. A new model, data source, external action, user population or business policy may cross the boundary of an old approval. Define those triggers when the case is decided. Otherwise every change becomes either a full review or no review, both of which fail at scale.
Report flow and exposure together
Executives need more than the number of approved systems. Show how the governance service is operating.
Useful measures include:
- cases received and decided by lane and tier
- time spent waiting for evidence, specialist review and final authority
- cases without a named decision owner
- overdue high-impact decisions
- exceptions approaching expiry
- incidents that reopened an approval
- systems with no current review or retirement trigger
- decisions rejected or narrowed because evidence changed the outcome
Do not celebrate faster approval by itself. A healthy queue can move quickly because the intake is clear, or because review has become ceremonial. Pair flow measures with evidence completeness and the consequences represented by open cases.
Scope consulting to an operating backlog
Put the current queue in the statement of work. A bounded first engagement might cover the top 20 cases, the intake and routing design, evidence standards for two risk tiers, exception handling, decision reporting and handoff to internal owners.
Write acceptance around operation:
| Deliverable | Acceptance evidence |
|---|---|
| Queue baseline | Every sampled case has a state, next action and owner |
| Intake and routes | New cases enter the correct lane without consultant interpretation |
| Evidence rules | Reviewers can name what is required and why |
| Authority map | Each decision and escalation has a named role |
| Exceptions and incidents | Expiry, containment and reopening paths work on current records |
| Reporting | Leaders see delay, exposure and ownership without a manual slide rebuild |
| Handoff | Internal staff operate the next review cycle and update the records |
Keep legal interpretation with qualified counsel. Keep independent assurance independent. Keep technical tests with people who can execute and challenge them. Governance consulting connects those results to decisions; it does not replace every specialist.
Our AI compliance consulting guide covers requirement-to-evidence mapping. The AI risk assessment guide covers one bounded system and its credible harms. Use governance consulting when the recurring problem is the organization’s ability to route and own those decisions across a portfolio.
The engagement is finished when the decision queue no longer depends on the consultant to interpret each case. Policies matter. A working queue shows that people can use them.