AI in RMF: what should and shouldn't be automated
AI should read, rank, extract and draft. It should never make an authoritative RMF determination. The line is not about capability — it is about who is accountable for the claim.
Every tool in this market now has an AI story. Very few of them have an answer to the only question that matters for a government buyer: what is the machine allowed to change?
The line worth drawing
It is not a capability line. It is an accountability line.
An RMF determination is a claim a named, authorized person makes and can be held to. “This control is satisfied” is not a summary of evidence — it is a professional judgment with consequences. The moment a machine can write that claim into the record without a person accepting it, the record no longer says who is accountable for anything in it.
So the line is: AI may produce anything, and may change nothing.
What AI is genuinely good at here
Plenty, and it is worth being specific rather than dismissive.
Reading long documents. Finding the paragraph in a two-hundred-page SSP that discusses AC-2 is tedious, mechanical, and something a model does well. Extraction with the supporting quote attached turns a day of searching into an afternoon of reviewing.
Ranking applicability. Deciding which of several hundred DISA STIGs plausibly apply to a system running a given technology stack is a ranking problem, not a judgment. A ranked list a practitioner confirms is far better than an unranked list they work through alphabetically.
Drafting. A first implementation statement assembled from evidence, which a practitioner then corrects, is faster than a blank field — as long as everyone understands it is a draft and the record records that.
Surfacing possible impact. When a component moves, suggesting which controls that might touch is useful even when it is sometimes wrong, because the cost of checking a suggestion is low and the cost of missing an impact is high.
Resolving ambiguous headings. Deterministic rules handle most document structure. AI is a good fallback for the cases the rules could not resolve — used as a fallback, and named as one.
What it must not do
Make a determination. Satisfied, not satisfied, not applicable — these are human acts.
Write to the authorization record. Everything a model produces should be a proposal, carrying its own explanation, until a person with authority accepts it.
Invent identifiers. A control, CCI or STIG identifier that does not exist in the catalog must be discarded server-side before anyone sees it. A plausible-looking hallucinated identifier is worse than an obvious one, because somebody has to disprove it.
Assert a security property. Whether a connection crosses the boundary, whether data is encrypted, how data is classified — a model that can assert these can quietly change the authorization.
Take instructions from documents. Content extracted from an uploaded file must be fenced as data. A model that follows instructions found inside a scan report is an injection vector wearing a compliance badge.
Overwrite a newer human edit. If a proposal’s target changed between extraction and acceptance, acceptance should be refused as stale. Somebody made a more recent decision and it should win.
The provenance requirement
Once a machine has proposed and a person has accepted, the record should keep both facts: that this statement was proposed by an extraction on a date, and accepted by a named person on another date. If somebody later edits it, that should be visible too.
This is what makes the whole arrangement defensible. Not that the AI is accurate — you cannot prove that to an assessor — but that every claim in the record has an accountable author, and you can show who it is.
The question to ask a vendor
Not “do you use AI?” Everyone does.
Ask: what can your AI change without a human accepting it?
If the answer is anything at all, you have learned something important about what will end up in your authorization package.