AI changes the bottleneck in compliance authoring, but not in the way the first demo suggests. The easy win is faster prose. The harder problem is proving what the prose claims.
A control draft can sound complete before it names anything operational. "AI systems must be reviewed before deployment" reads like a control. It has the right nouns. It points at a real concern. It gives a reviewer something to nod at.
It is not yet a control in the sense that matters.
It does not say which AI systems are in scope, which risk it treats, who owns the review, what evidence gets produced, where that evidence lives, what test would fail the control, how exceptions work, or how often the claim has to be rechecked. It is a policy-shaped sentence waiting for an evidence model.
That distinction matters because control assessment is not copy editing. NIST SP 800-53A frames assessment as procedures for determining whether controls are implemented and for producing assessment results. NIST SP 800-53 gives a catalog of control language, but the operational question is still: what would make this pass or fail?
AI is useful here when it is treated as a hypothesis generator. It can draft the control intent, propose assumptions, and expose missing fields. It is dangerous when fluency lets the team skip the uncomfortable part.
The draft is a claim about evidence
The useful reviewer question is not, "does this sound like a control?" It is, "what claim would make this control pass or fail?"
Take a constructed example:
Every production model release requires a recorded risk review linked to model version, reviewer, test results, exceptions, and approval decision.
That is still not perfect, but it is closer because it names observable edges. There is a model version. There is a reviewer. There are test results. There are exceptions. There is a decision. A workflow can now ask whether those things exist and whether they agree with the policy.
This is where controls start to look like graphs. A policy clause implements a requirement. A control treats a risk. A test checks the control. Evidence supports the test result. An exception changes the meaning of a pass. A system boundary decides what is in scope.
I made the same point from the knowledge-systems side in RDF vs property graphs: compliance controls, policy clauses, suppliers, evidence, and regulations are exactly the kind of concepts that need stable identity across systems. The compliance version of that argument is simpler. If the evidence, control, and risk cannot be named consistently, the audit trail becomes a document search problem.
Machine-readable beats polished
OSCAL is useful as a reference point because it treats control catalogs, baselines, implementation information, assessment, and monitoring as machine-readable artifacts in XML, JSON, and YAML. You do not need to adopt OSCAL on day one to learn from the shape of it.
The lesson is that a control is not only a paragraph. It is a structured object with relationships to other objects.
That structure changes how AI should be used in the drafting loop. The model should not only return polished prose. It should return the control text plus the assumptions it made: scoped systems, evidence sources, test method, review cadence, owner, exception path, and unresolved gaps.
Without that pressure, AI makes the weak version of compliance cheaper. It produces a better-looking document while leaving the evidence chain unbuilt. With that pressure, it can speed up the useful work: turning vague intent into testable claims.
AI-specific compliance makes this more obvious. The NIST AI RMF Core treats risk management as continuous across the AI system lifecycle. ISO/IEC 42001 describes an AI management system as policies, processes, and controls for how AI systems are designed, developed, deployed, and used. The EU AI Act's Article 12 summary points to logging over the lifetime of high-risk AI systems to support traceability and monitoring.
Those are not one-time approval ideas. They imply recurring evidence.
Where the cheap prose helps
There is real value in a good first draft. A blank page hides disagreement. A draft makes reviewers react. It can reveal that legal, engineering, security, and product are using the same word for different things.
AI can make that part faster. It can generate candidate control language, map a policy clause to likely evidence, summarize gaps, and propose a first test method. That is useful work when the workflow treats every generated sentence as pending verification.
The failure mode is approval without a recorded basis. Human review still matters, but a signature over vague prose does not fix the accountability problem. It only adds a person to an untestable claim.
Small teams do not need full formal machinery before they can write better controls. They do need a trace. A spreadsheet with stable identifiers, evidence links, owners, dates, and test outcomes is more serious than a polished policy document with none of those things.
The next bottleneck in compliance authoring is not writing. It is making every sentence answerable to evidence.