This is the order to build an AI governance program in, and the reasoning for the order. What the program has to contain is a different question, answered by the AI governance framework. This page assumes you have read that or already know the domains.
The sequence below is not a maturity model and there is no score at the end. It is the order in which each step becomes possible, which is a more useful constraint than a target state.
Why the order matters more than the list
Most governance programs that stall do so because they were built in the wrong order, and the same two inversions account for most of it.
The first is writing policy before taking inventory. A policy written before anyone knows what is in use governs an imagined organization, and its first contact with reality is an exception request it has no way to handle. Both the NIST and GAO frameworks put context and mapping before control selection, and that is not an accident of drafting.
The second is publishing prohibitions before publishing a route to approval. Governance that can only say no produces the undeclared use it was meant to prevent, because people who need a tool to do their work will use one. The approved list has to arrive at the same time as the restriction, or preferably before it.
Step 1: get a sponsor who can decide
Before anything else, establish who is accountable at executive level and confirm they are willing to decline things.
This step is often skipped because it feels like process. It is not: everything downstream requires someone to arbitrate between a department that wants a tool and a risk that the organization is not willing to take. Without that person, the program produces recommendations that nobody is obliged to follow.
What you need from them is narrow. A decision that governance exists, a named owner, an escalation route, and agreement that the first inventory will be run without consequence attached.
Step 2: run the inventory, and ask rather than audit
Find out what is already in use. Ask staff directly, in writing, with an explicit statement that nobody is in trouble.
The tone of this request determines the quality of the answer, and an audit framing produces an undercount that will mislead every subsequent step. Ask what tools people use for work, what they use them for, and whether the organization pays for them.
Then add the part people cannot tell you: the AI features already switched on inside products you license. Check your major vendors' release notes and admin consoles rather than relying on recollection. This is usually where the surprises are.
What to record per system, and how to keep the record current afterwards, is covered in AI inventory and use-case management.
Step 3: name an owner for each system
Every system on the inventory gets a named person who is answerable for how it is used.
This is not the vendor manager and not necessarily anyone in technology. It is whoever owns the business process the system is part of, because they are the only person positioned to notice that the use has drifted from what was approved.
Systems with no plausible owner are the first useful output of the exercise. In most organizations two or three things surface that nobody is willing to own, and that answer is itself a decision.
Step 4: classify by consequence, not by technology
Sort the inventory by what happens if the system is wrong, not by how the system works.
A workable first cut has three tiers. Systems that affect no one outside the person using them. Systems whose output reaches a customer, a resident or the public. Systems bearing on a decision about a person, including eligibility, employment, discipline, grading, safety, credit or a benefit. The third tier gets real scrutiny; the first gets almost none.
Classifying by model type or by vendor rather than by consequence is the common error, and it produces a scheme that has to be re-argued for every new tool.
Step 5: write the smallest policy set that decides things
Now, and not before, write it down. Four documents cover most organizations, and all four can be short.
An acceptable use position, stating what staff may do, what is prohibited, and where to ask. This is the one staff will actually read, and what belongs in an AI acceptable use policy covers it in detail.
A data rule, stating what categories of information may be put into an AI system and which are prohibited. This is the single highest-value sentence in most governance programs and it must be specific enough to apply without asking.
A procurement position, stating what happens before an AI product is bought or an AI feature is enabled, including who must be consulted.
A human review position, stating where a person must review an output before it takes effect, keyed to the tiers from step 4.
Organizations frequently ask for a longer list. Longer lists are not better here: the constraint is whether a member of staff can find the answer to a specific question in under a minute, and every additional document makes that less likely.
Step 6: publish the approved list and the request route
Say which tools are approved, for what, and how to ask about one that is not on the list.
This is the step that converts a governance program from an obstacle into an asset, and it is the one most often deferred until the framework is complete. Deferring it is how organizations end up with nothing: staff cannot wait, so they proceed without you, and the eventual policy lands on a population that has already routed around it.
Commit to a response time on requests, and keep it. A route that takes three weeks is not a route.
Step 7: apply the technical controls the classification calls for
Now the security and access work has a target. Identity, access review, logging, data-loss controls and secure integration, applied in proportion to tier rather than uniformly.
The AI-specific part is worth separating from general security hygiene, and is covered in the AI cybersecurity risks to assess before deployment. The most commonly missed item is access inheritance: a retrieval system will answer using everything the requesting account can reach.
Step 8: assess vendors, starting with the ones you already have
Supplier review is usually built for new purchases, which means it never reaches the AI features added to products bought years ago. Start with the existing estate.
The questions to ask and the terms to look for are in AI vendor risk assessment. GAO's April 2026 review of federal AI acquisitions found that agencies were not consistently collecting and applying lessons learned from earlier procurements, which is a failure mode worth designing against rather than discovering.
Step 9: decide what you will watch, and set review dates
Approval without an expiry is a decision about a system that no longer exists. Give every tier-two and tier-three system a review date and a trigger list.
The triggers that matter most are a vendor changing its model or its terms, a new capability being enabled by default, and the use case drifting from the one approved. None of those arrives with a notification addressed to you.
Step 10: tell people, in the place they already look
Training that consists of circulating a policy changes nothing. What changes behavior is a short current statement of what is approved and where to ask, published where people already go for other answers.
Pick the channel deliberately. An intranet page nobody visits is not publication, and a policy attachment in an email is findable for about a week. Whatever your organization treats as the place to look things up, that is where this belongs, and it needs an owner who updates it when the approved list changes.
One further point on tone. The statement should say what people may do before it says what they may not, because the first question anyone actually has is whether the thing they are already doing is allowed.
What the first ninety days realistically produce
An inventory with owners, a three-tier classification, four short policies, an approved list with a request route, and review dates on the systems that matter. That is a complete first cycle and it is achievable in a quarter for most organizations.
What it will not produce is completeness. Several domains in the framework will still be empty, and that is the correct state after one cycle. A governance program that is genuinely running and covers eight domains is worth considerably more than a complete one that exists on paper.
LABUSA runs this sequence with organizations as an AI governance consulting, and can also review a program already underway against what an assessment finds. If you are not sure which of the ten steps you are on, that is a normal place to start and a conversation will establish it.