Taking on AI leadership is usually framed as a technology problem: pick the model, choose the vendor, launch the pilot. The NIST AI Risk Management Framework suggests a different starting point. It presents AI risk management as a continuous activity infused across an organization, and it names governance as the cross-cutting function that makes the rest work. If you have ninety days, the most durable use of them is to build the governing structure, then move iteratively through the remaining functions rather than chasing a launch date.
This memo sets out one practical sequence. It draws on NIST's public framework materials, which state that the AI RMF 1.0 is being updated and that a revised version is in progress, so treat the specific wording as current guidance rather than fixed doctrine.
Why governance comes first
The framework describes govern as a function infused throughout AI risk management that enables the others, with aspects of governance integrated into each of the other functions. It also notes that once a governance structure is in place, the functions may be performed in any order across the AI lifecycle, and that most users would start with map and then continue with measure or manage. The process should remain iterative, with cross-referencing between functions.
The practical implication is straightforward: governance is the precondition for everything else. A team without documented roles, an inventory of systems, and a defined review cadence will struggle to map context, measure risk, or manage incidents consistently. Building those structures in the first weeks is not bureaucracy; it is what makes later decisions defensible.
The framework is voluntary. NIST describes it as intended for voluntary use and to improve the ability to incorporate trustworthiness considerations into the design, development, use, and evaluation of AI products, services, and systems. Nothing here implies a legal obligation. The AI RMF was developed over an 18-month period with more than 240 contributing organizations from industry, academia, civil society, and government.
Weeks 1 to 4: roles, responsibilities and communication lines
Start with accountability. The framework's Govern 2 category calls for accountability structures so that teams and individuals are empowered, responsible, and trained for mapping, measuring, and managing AI risks. Two subcategories are especially useful in the first month:
Name the decision-makers
Govern 2.1 calls for roles and responsibilities and lines of communication related to mapping, measuring, and managing AI risks to be documented and clear to individuals and teams throughout the organization. The working artifact is a simple responsibility map: who owns the AI system, who owns its risk assessment, who is consulted on changes, and who is informed when something goes wrong.
Govern 2.3 states that executive leadership takes responsibility for decisions about risks associated with AI system development and deployment. That is worth making explicit on paper. A named executive sponsor, with the authority to pause or retire a system, turns governance from a committee exercise into an accountable practice.
Set the tone from the top
The framework observes that senior leadership sets the tone for risk management and, with it, organizational culture, while management aligns technical aspects of AI risk management to policies and operations. Documentation can enhance transparency, improve human review, and bolster accountability. In the first 30 days, that means drafting the policies and processes the organization will actually follow, not a shelf document: how AI systems are requested, reviewed, approved, monitored, and retired.
Weeks 4 to 8: inventory and monitoring cadence
You cannot govern what you cannot see. Govern 1.6 calls for mechanisms to inventory AI systems, resourced according to organizational risk priorities. An inventory does not need to be sophisticated. It needs to list each system in use, its owner, its purpose, its data sources, and its current risk rating.
Then set the rhythm. Govern 1.5 calls for ongoing monitoring and periodic review of the risk management process and its outcomes to be planned, with organizational roles and responsibilities clearly defined, including the frequency of periodic review. Pick a frequency and put it on the calendar. A quarterly review with named attendees is more useful than an aspirational continuous process nobody owns.
Two adjacent subcategories are easy to defer and expensive to ignore. Govern 1.7 calls for processes for decommissioning and phasing out AI systems safely, in a way that does not increase risks or decrease trustworthiness. Decide early how a system gets switched off. Govern 6.1 addresses AI risks from third-party entities, including risks of infringement of a third party's intellectual property or other rights, while Govern 6.2 calls for contingency processes to handle failures or incidents in third-party data or AI systems deemed high-risk. Vendor dependence is a governance question, not just a procurement one.
Weeks 8 to 12: iterate across map, measure, manage
With governance in place, move to context. The map function establishes the context to frame risks related to an AI system. The framework states that an initial go/no-go decision about whether to design, develop, or deploy an AI system is informed by map, and that map outcomes are the basis for measure and manage.
Document purpose and context
Useful map subcategories include documenting intended purposes, beneficial uses, and context-specific laws, norms and expectations (Map 1.1); defining business value or context of use (Map 1.4); and documenting organizational risk tolerances (Map 1.5). Together these turn a vague pilot proposal into an assessable one.
Define human oversight
Map 2.2 asks organizations to document how system output may be used and overseen by humans, and the system's knowledge limits. Map 3.5 calls for defining, assessing, and documenting human oversight processes in line with governance policies. At this stage, the question is not whether a human reviews the output, but who, at what point, with what authority to override.
Worked example (hypothetical)
Consider an invented financial services firm appointing a new head of AI. In weeks one to four, she maps responsibilities: an operations director owns the customer-service assistant, a compliance lead owns its risk assessment, and the chief operating officer is the executive sponsor. In weeks four to eight, she inventories four AI systems and schedules quarterly reviews. By week twelve, she takes one system through the map function: its intended purpose is documented, the business value is articulated, and the knowledge limits are written down alongside the human escalation path. No deployment decision is made yet; the firm now has the context to make one. The example is illustrative only and describes no actual organization.
What the framework does not prescribe
The framework is explicit that its actions do not constitute a checklist, nor are they necessarily an ordered set of steps. Organizations may select among categories and subcategories or apply all of them, depending on resources and capabilities. There is no mandated timeline, no required team size, and no single correct sequence after governance is established. The 90-day structure here is a practical management choice, not a requirement of the AI RMF.
The measure and manage functions are described here only at the level the public framework supports; the categories are detailed in the full framework and its companion playbook, which is also voluntary. For teams already working to ISO/IEC 23894:2023, a published crosswalk maps the AI RMF functions to that standard's clauses, for example linking govern to leadership and commitment, design, and the assignment of roles, authorities, responsibilities, and accountabilities. The crosswalk notes that ISO/IEC 23894 also contains clauses that do not map to the AI RMF, such as communication and consultation.
Conclusion: the first step this week
Before the next ninety days begin, produce one page listing every AI system in use, its named owner, its executive sponsor, and the date of its next review. That single artifact exercises governance, inventory, and monitoring at once, and it gives the organization something concrete to map, measure, and manage against.
Read the companion memos on who owns the AI decision, choosing a pilot you can actually evaluate, and buy, build or redesign the workflow. For a private board-ready summary, use the board brief builder. More about the publisher is at NovCog.
