Quick Answer: AI governance starts with the Govern function of the NIST AI RMF. That means establishing an AI policy, updating existing cybersecurity and privacy policies for AI gaps, and building an AI system inventory. AI risk should be integrated into your existing cyber risk program rather than managed as a separate silo. Organizations in regulated industries can layer the Financial Services AI RMF (FS AI RMF) controls on top of NIST for more concrete, audit-ready guidance, and even those outside financial services benefit from its specificity. Report AI risk to the board using quantitative dollar figures and ROI framing, not heat maps.
AI adoption is outpacing every prior technology wave. Not the internet, not cloud computing, not social media. Nothing has moved this fast. One recent study found that 78% of organizations now use AI in at least one business function, up from 55% the year before. That's not just employees casually asking ChatGPT a question. That's AI embedded in core business operations.
The governance frameworks most organizations rely on were built for a slower-moving technology landscape. Annual IT audits, for example, follow a format developed in the 1950s modeled after financial audits. Meanwhile, AI is showing up whether you've governed it or not. It's bolted onto existing tools like Microsoft 365 Copilot, embedded in standalone platforms like Gemini and Claude, and quietly woven into vendor products through contract updates that nobody flagged.
The financial consequences are already measurable. IBM's Cost of a Data Breach Report found that organizations with extensive shadow AI use faced breach costs roughly $660,000 higher than those without. For any organization handling sensitive data, whether that's customer records, patient information, intellectual property, or proprietary business processes, the stakes are real. A single hallucinated recommendation, biased automated decision, or data leak through an unsanctioned AI tool can quickly become a front-page problem.
You can't avoid AI. You have to govern it.
Built for lean security teams in highly regulated industries
The NIST AI Risk Management Framework organizes AI governance into four functions: Govern, Map, Measure, and Manage. For organizations just getting started, the question is which function to prioritize.
The Govern function is the foundation. Without governance, the other three functions (Map, Measure, Manage) don't stick. There's no structure to anchor them to. Starting with Govern means establishing an AI policy, updating your existing cybersecurity and privacy policies to address AI gaps, defining ownership, and building procedures for procurement and change management that explicitly account for AI.
But rather than working through the four functions sequentially, a more practical starting sequence looks like this: put an AI policy in place, review existing cyber and privacy policies for AI gaps, build an AI system inventory so you know what's out there, perform an AI-specific risk assessment, update your vendor questionnaire to account for AI, and bring business units into change management. These steps are concrete, achievable, and defensible.
A critical early decision is where AI risk lives in your organization. The recommendation from practitioners is that it should sit within your cybersecurity program, not enterprise risk management (ERM) and not third-party risk management in isolation. Cybersecurity already has the information system detail, the risk management sophistication, and the control structures needed to absorb AI risk. ERM officers generally don't want the technical granularity of cyber and AI risk in their ERM tools, and that level of detail is exactly what AI risk requires.
That said, cyber owning AI risk only works if the results roll up cleanly to enterprise risk for board-level reporting. The goal is one risk register, one residual risk number, and one set of recommendations. Not two committees telling different stories about the same Microsoft 365 environment.
One of the most common governance mistakes is treating AI risk as a parallel universe that needs its own separate program. It doesn't. AI is a new risk dimension on existing systems, not something that should be managed in a silo.
When Microsoft bolts Copilot onto M365, it's still M365. Running a separate AI risk assessment creates two assessments of the same system, potentially with different conclusions, different methodologies, and maybe even different risk scales. When the business unit leader or the board receives conflicting recommendations from a cyber risk committee and an AI risk committee about the same system, things get confusing fast.
Properly measuring cyber risk (and by extension, AI risk) requires eight elements: risk appetite, data classification, system inventory, key risk indicators, security controls, risk measurement, risk treatment, and reporting. If any of those elements are missing, you're not properly managing risk. Each one needs an AI-aware adjustment, not a wholesale replacement.
Updating for AI means revisiting your risk appetite (you might be accepting more risk to gain AI-enabled business value), reclassifying data flowing through AI-enabled systems (sensitivity can jump dramatically), and adding AI-specific key risk indicators alongside your existing ones. Those AI-specific indicators fall into four categories: AI data issues, AI operational issues, legal/ethical/regulatory issues, and AI model training issues.
Then layer AI-specific controls onto your existing control framework. Whether you're using ISO 27001, CIS 18, or NIST CSF, add AI controls rather than swapping frameworks. The control practice specific to AI is TEVV (Testing, Evaluation, Verification, and Validation), which most cyber programs aren't yet doing but which becomes essential when AI models can drift, hallucinate, or introduce bias over time.
Qualitative heat maps (high, medium, low) don't capture how much AI shifts the risk landscape. When you run Monte Carlo analysis on AI-enabled systems, the numbers tell a story that red-yellow-green simply can't. Those numbers then flow directly from the cyber risk assessment into the enterprise risk register, giving the board a single, coherent risk picture.
Think of the NIST AI RMF as the architect and the Financial Services AI RMF (FS AI RMF) as the blueprint. NIST provides the high-level structure (Govern, Map, Measure, Manage) at an abstraction level designed to apply to any industry. That abstraction is intentional, but it's also a challenge for any organization trying to implement AI governance tomorrow and wondering what concrete steps to actually take.
The FS AI RMF extends the NIST framework by adding concrete controls that you can assign to an owner and audit against. NIST says "consider vendor risk," and the FS AI RMF provides specific vendor questionnaire requirements. NIST recommends change management, and the FS AI RMF defines AI-specific change management checkpoints. NIST references testing, and the FS AI RMF spells out detailed TEVV expectations.
While these controls were written for banks and credit unions, they're broadly applicable. Healthcare organizations, government agencies, insurance companies, and any business handling sensitive data will find them more actionable than the base NIST framework. Only a handful of controls are truly specific to banking and lending. The rest address universal concerns like vendor oversight, change management, data governance, and model validation. Auditors and regulators across industries are increasingly asking AI-related questions, and having concrete, assignable controls gives you defensible answers.
For the Govern function, lean on NIST. For Map, Measure, and Manage, lean heavily on the FS AI RMF regardless of your industry.
You can't govern what you can't see. Most organizations don't have a clear picture of where AI already exists in their environment. The cataloging exercise is the gateway to everything else, and it's simpler to start than most people think.
Begin with the obvious: M365 Copilot is right there if you're using it. ChatGPT-style tools your employees may be accessing. Even Google search now provides Gemini-generated AI answers in a standard browser, so people are using generative AI without even realizing it. Then expand through business unit surveys, network monitoring for shadow AI tools, and procurement records to see what business units are buying.
The real goal isn't just a list of AI tools. It's connecting inventory to ownership, approvals, evidence, monitoring, and reporting. Update your vendor questionnaire to ask about AI, add AI detection checkpoints to change management, and assign an owner to keep the inventory current. Without those three steps, your inventory goes stale the day after you finish it.
Most organizations that have taken any step toward AI governance have created a policy. But many haven't gone beyond that, and others are stuck trying to write the perfect policy before publishing anything. That's a mistake. Having a base policy beats aiming for perfection, because the landscape is changing so fast that anything you write today will need updating within months. Set up the guardrails before the train leaves the station, and plan to iterate.
Shadow AI is shadow IT's more dangerous cousin. One report found that 98% of organizations deal with unsanctioned AI use. Another survey found that 75% of employees admit to putting company data into personal AI tools, signing up with a personal credit card for $20 a month, then plugging in customer details to generate reports or save time. IT has no visibility into any of it.
Shadow AI thrives when the official route is too slow. If your AI approval process takes weeks, employees will find their own tools in minutes. The practical fix is to publish an approved AI tool list and define a lightweight intake process that makes it faster to ask permission than to work around the system. Change management also needs to expand beyond IT. When a vendor pushes an update that adds AI features, your change management process should flag it. When marketing or operations signs up for a new tool, they need to be part of the conversation. If business units aren't included in change management, they're going to keep onboarding tools you don't know about.
Board members are generally finance people, not security people. They speak a different language, not a lesser one. The mistake most security leaders make is presenting the data they have rather than the data the board needs to make a decision.
An effective AI risk board report follows a simple structure: here's the risk, here's what it could cost us, and here's what we recommend. If possible, keep it to one page. Board members don't want a tutorial on AI architecture or a deep dive into cybersecurity frameworks. They want to know what you need from them.
When you go to the board and say "current risk is high, target risk is medium," that doesn't drive action. There's no inherent meaning in those terms, and different people interpret them differently. Compare that to saying: "We have a $5 million expected annual loss in this area. If we invest $500,000 in these controls, we can reduce that exposure by $2.5 million. That's a 500% ROI." Boards understand dollars and return on investment. They don't always understand color-coded heat maps, and frankly, those heat maps don't actually mean anything specific enough to act on.
Your board already has a mental model for cybersecurity reporting. AI should show up within that existing structure as updated key risk indicators, changed system risk scores, and new control investment requests. Not as a separate appendix or an entirely new reporting process.
Show the trend, not just a snapshot. Boards want to know whether things are getting better or worse based on the decisions they've made. Track residual risk over time, control implementation progress, and TEVV results. This tells a story that a single point-in-time assessment never can.
Quantifying AI risk follows the same methodology as quantifying cyber risk, with one addition. The traditional CIA triad (confidentiality, integrity, availability) now includes a fourth dimension: accuracy. AI models can drift over time, introduce bias, and hallucinate. Loss of accuracy in an AI system that informs business decisions, processes customer data, or automates workflows is a distinct and measurable risk.
For confidentiality (data breach), start with cost-per-record studies. Depending on the study, the cost ranges from $160 to $250 per record. Multiply by the number of records on a given system, and you have a starting point for breach impact.
For availability, work with business owners to estimate downtime costs. If a system's disaster recovery plan calls for a 48- or 72-hour recovery, ask the business what that downtime costs in terms of transactions not processed, customers not served, and revenue not collected. Many business owners can produce a reasonable estimate when asked directly.
These numbers don't have to be exact. Quantitative risk management uses ranges, not precise figures. Plug a low estimate and a high estimate into a Monte Carlo simulation, run thousands of scenarios, and you get a log-normal distribution that tells you far more than "high risk" or "medium risk" ever could.
AI governance doesn't require starting from scratch. For organizations with an existing cybersecurity risk program, the path forward is extension, not reinvention. Your risk appetite, your system inventory, your control frameworks, your board reporting: all of these structures already exist. AI risk is a new dimension layered onto those same systems, measured through the same methodology, and reported through the same channels.
The organizations that will navigate this well aren't the ones with the biggest teams or the most sophisticated tools. They're the ones that start now, start simply, and build governance that can evolve as fast as the technology itself. It's the Wild West out there, and the organizations laying down rails today are the ones that won't get left behind.
Built for lean security teams in highly regulated industries