Evolving the GRC Role in the AI Era: NIST AI RMF
Two years ago, the GRC role in most small defense contractors was a documentation role. Someone owned the policy set, someone tracked the POA&M, and the hard part was getting engineers to write down what they were already doing.
That role has changed, and not because anyone announced it. It changed because AI showed up inside the boundary and nobody filed a change request.
The framework people reach for is the NIST AI Risk Management Framework. It is worth reading. It is also worth being clear about what it is, because I see it cited the way people cite NIST SP 800-171, and the two documents do very different things.
A framework without an assessor
800-171 gives you 110 requirements, 320 objectives, a scoring methodology and eventually someone from a C3PAO sitting across the table asking you to prove it.
The AI RMF gives you four functions — GOVERN, MAP, MEASURE, MANAGE — and a set of outcomes underneath them. No score. No assessment body. No contract clause forcing the conversation.
That is not a criticism. It is a design choice, and it is the right one for a technology moving this fast. But it puts the discipline back on you. With 800-171, the deadline supplies the motivation. With the AI RMF, if you do not build the rigor yourself, nothing external will build it for you.
Which is why the GRC role is the one that changed. You are now being asked to attest to the behavior of systems that do not behave the same way twice.
Control testing assumes a system that repeats
Almost every control-testing habit we have assumes determinism. You check the configuration, you capture the screenshot, you file the artifact. The setting will be the same next quarter unless someone changes it, and if someone changes it, the change is logged.
A model does not work that way. Same prompt, different output. Same system, different behavior after a vendor updates something on their side without telling you. The artifact you captured in March describes an interaction that happened in March.
So the evidence question changes shape. You are no longer evidencing a state. You are evidencing a process — that you defined acceptable behavior, that you tested against it, that you monitored for drift, and that a named human reviewed the result.
That is a governance artifact, not a screenshot. It is also squarely GRC work, which is why the function is absorbing this rather than the engineering team.
MAP is where most organizations are already failing
Before you can govern anything you have to know it exists. In practice, this is where the work stalls.
Ask a fifteen-person contractor to list the AI in their environment and you will get one answer. Ask their staff individually and you will get a different one. A transcription tool on someone’s laptop. A browser extension that summarizes documents. A helpdesk product where the vendor enabled an assistant by default in the last release. Nobody made a decision. It simply arrived.
If any of that touches CUI, the inventory gap is not an AI governance problem. It is a scoping problem, and scoping problems are where assessments go wrong. Every one of those tools is a place data can leave your boundary, and you cannot write an accurate system security plan around components you have not enumerated.
Start there. Not with a policy — with a list.
The obligations that already apply
Here is the part I want defense contractors to sit with. The AI RMF is voluntary. Your existing requirements are not, and they do not pause because the actor is a model.
If an AI tool processes CUI, it is in scope. It is a system component. It inherits the boundary, the access control requirements, the audit requirements, the flow-down obligations under DFARS 252.204-7012, and the incident reporting expectations that come with them.
Three questions I would ask in an assessment:
- Does the tool store, process or transmit CUI, and did you verify that with the vendor rather than assume it from the marketing page?
- Where does the data physically go, and does the arrangement satisfy your FedRAMP-equivalency and cloud requirements?
- Can you produce audit records tracing what the tool did back to an individual user?
A no on any of those is not an AI issue. It is a 110-requirement issue that happens to involve AI.
Where this is heading
The voluntary posture will not hold indefinitely. The signals are already in the publication pipeline.
NIST is revising AI RMF 1.0 under the White House AI Action Plan. A draft Cyber AI Profile bridges AI risk management to the Cybersecurity Framework. Control overlays for securing AI systems are in development against SP 800-53 — and 800-53 is the document 800-171 derives from. In April 2026 NIST issued a concept note for a Critical Infrastructure profile.
Read that sequence as a practitioner. Voluntary framework, then profiles, then overlays against the federal control baseline. That is the same path other requirements have taken before they arrived in a contract.
Nobody needs to predict a date. The organizations that inventory their AI now, write down who approved what, and keep records of how they tested it will be doing paperwork later. The ones that wait will be doing archaeology.
What the GRC role looks like now
Less policy drafting. More asking what a system actually does, and whether the answer can be shown to somebody who is not inclined to take your word for it.
That is the same instinct the job always required. The systems just stopped holding still.
If AI has entered your CUI environment, the inventory is the place to start. AI governance advisory · Take the SPRS self-check