The Framework Isn’t the Problem — The Translation Is
Most IT managers at mid-market companies have heard of the NIST AI Risk Management Framework by now. Fewer have read past page ten. That’s not laziness — it’s a rational response to a document written for enterprise risk offices and federal agencies, not a 100-person company where you’re also the person keeping the firewall updated.
on Unsplash
The NIST AI RMF is genuinely useful. It’s not a compliance checklist with pass/fail boxes, which is both its strength and the reason it confuses people who are used to frameworks like PCI DSS. It’s a structured way of thinking about AI risk across four functions: GOVERN, MAP, MEASURE, and MANAGE. This post translates each one into language that means something when you have no dedicated compliance team and a handful of AI tools already running in production.
GOVERN: Decide Who Owns What Before a Problem Forces the Question
GOVERN is the foundation. In the NIST framing, it covers the policies, accountabilities, and culture that make everything else possible. For a large enterprise, that means AI ethics boards and formal risk appetite statements. For a 100-person company, it means something more practical: someone has to own this, and that person needs written authority to act.
Start with a one-page AI use policy. It doesn’t need to be long — it needs to answer three questions. Which AI tools are approved for use? What categories of data can employees feed into them? And who approves exceptions? If you can answer those three questions in writing and get a signature from leadership, you have a GOVERN foundation that’s proportionate to your size.
The second piece of GOVERN that gets skipped at smaller companies is vendor accountability. When you adopt a SaaS tool with AI features baked in — a CRM that auto-summarizes calls, a support platform that drafts responses — you’ve inherited that vendor’s AI model whether you acknowledged it or not. Your policy needs to say something about that. At minimum, you should know which of your vendors are using AI in ways that touch customer data, and you should have a line in your vendor agreements (or addendum) that addresses it.
GOVERN isn’t about perfection. It’s about not being in a position where a regulator or a client asks who was responsible and the honest answer is “nobody in particular.”
MAP: Know What AI Is Running Before You Try to Assess It
MAP is the discovery and context-setting function. Before you can assess risk, you need an accurate picture of what AI tools your organization is actually using — which is harder than it sounds, because AI capabilities are now bundled into nearly every SaaS product your employees touch.
The practical output of MAP is an AI inventory. Not a formal asset register with seventeen fields — a working list that captures the tool name, the business function it supports, the data it processes, and who owns it. For most mid-market companies, the first pass at this inventory will surface tools no one in IT knew were being used. That’s normal. Shadow AI is the rule right now, not the exception.
MAP also asks you to think about context: who relies on this AI output, and what happens if the output is wrong? A tool that drafts internal Slack messages carries different risk than one that generates customer-facing contract summaries or flags credit applications. The NIST framework calls this “impact assessment” — practically, it’s just asking “what’s the worst realistic outcome if this model fails or produces biased output?”
You don’t need a risk matrix with five-digit consequence scores. You need enough context to prioritize. High-volume, customer-facing, regulated-data-touching tools go to the top of your assessment list. Internal productivity tools with no sensitive data exposure go to the bottom. Everything else fits somewhere in between.
MEASURE: Establish a Baseline You Can Actually Track
MEASURE is where the NIST AI RMF small business conversation most often breaks down. The framework talks about metrics, testing, and ongoing monitoring — which sounds like a data science team and a model ops pipeline. You probably don’t have either.
Here’s what “good enough” looks like for a company your size: you have defined criteria for what acceptable AI performance looks like in your environment, and you have a way to notice when something has drifted from that baseline.
For most mid-market IT teams, this is simpler than the framework language implies. If you’re using an AI tool for customer support ticket triage, acceptable performance might mean the model correctly categorizes tickets above some threshold you’ve set based on early observation. You don’t need to run statistical validation — you need someone to periodically spot-check outputs and flag when accuracy looks materially worse than it used to be.
The more important MEASURE practice for companies without a compliance team is incident tracking. When an AI tool produces a bad output — a customer gets wrong information, a flagged transaction was a false positive that caused a real problem, an auto-drafted document contained a factual error — that needs to be logged somewhere. Not because a regulator is watching, but because patterns in those logs are how you identify which tools need closer attention and which vendor conversations you need to have.
If your company operates in the EU or serves EU customers, this isn’t just good practice — it’s increasingly a structural expectation under the EU AI Act. Getting in the habit of logging AI-related incidents now costs almost nothing compared to reconstructing history later.
MANAGE: Close the Loop Between Risk Identification and Actual Action
MANAGE is where the other three functions pay off — or don’t. This is the function that asks: when you find a risk, what do you actually do about it?
For mid-market IT teams, the MANAGE function is mostly about having a clear escalation path and a small set of predefined responses. You don’t need a 40-page incident response plan for AI specifically. You need answers to a handful of questions. Can you disable or restrict an AI tool quickly if something goes wrong? Who makes that call? How do you communicate to affected users or customers? How do you document what happened and what you did?
The MANAGE function also covers residual risk acceptance — the acknowledgment that you’ve looked at a tool, understood its limitations, and decided the risk is acceptable given the controls you have in place. That decision should be documented and signed. This matters because “we didn’t know” and “we looked at it and decided it was acceptable” are very different positions when something goes wrong.
One practical MANAGE step that’s underused at smaller companies: build a quarterly review cadence into your calendar now, before you need it. Once a quarter, look at your AI inventory. Has anything new been added? Has any vendor significantly updated their model? Have you had incidents that suggest a tool needs closer scrutiny? Thirty minutes four times a year is enough to keep your MANAGE function alive without it becoming a burden.
Do This Week: Build Your AI Inventory in Under Two Hours
If you want to take one concrete step toward NIST AI RMF alignment before the end of the week, start with your AI inventory. Open a spreadsheet and list every SaaS tool your company uses. For each one, look at the vendor’s feature documentation or changelog and mark whether it includes AI or ML capabilities. Then add four columns: what business function does it serve, what data does it process, who in your organization owns the relationship with this vendor, and — on a simple High/Medium/Low scale — how much does the business rely on its AI output?
That’s it. You now have a MAP-function output. It won’t be perfect on the first pass, but it will be more than most companies your size have, and it gives you a starting point for every other NIST function. Review it with your leadership team, fill in the gaps, and keep it updated as tools change.
If you want a structured way to take that inventory and turn it into a formal risk assessment, InfoDefenders is built specifically for teams in this position — no enterprise GRC background required. Our AI tool register and Risk Assessment Agent turn that spreadsheet into a scored, exportable risk assessment in minutes. See plans and start a free trial.
What “Good Enough” Actually Looks Like
The NIST AI RMF is not a certification. There’s no audit at the end. What it gives you is a structured way to demonstrate that your organization thought about AI risk seriously and acted proportionately — which is exactly what regulators, enterprise clients, and cyber liability underwriters are starting to ask for.
“Good enough” for a 100-person company doesn’t mean implementing every sub-practice in the framework’s companion playbook. It means you can show a written AI use policy, an inventory of tools in use, a log of incidents or near-misses, and a documented process for reviewing and responding to risk. If you can show those four things, you’re ahead of most companies your size and you have a foundation that scales as your AI footprint grows.
The companies that will struggle aren’t the ones that started imperfect. They’re the ones that waited until a client contract or an incident forced the question.
