Change Control for AI-Enabled Work: Use a Decision-Bound Change Record

Define the controlled object precisely

Do not write “AI update” as the change. Name the model and version where available, the prompt or instruction set, connected data sources, enabled tools, access permissions, evaluation set, output destination, and required human approvals. State whether the change affects drafting, analysis, recommendation, or execution. The same technical change can carry different consequences across those uses.

NIST SP 800-128 describes configuration change control as a process for managing configuration changes and preserving security-focused configuration management (NIST SP 800-128). Its scope is broader and more formal than this article’s educational artifact, but it supports the principles of identified baselines, controlled changes, and documented review.

Sources: [1]

Write a decision-bound change record

The record has eight fields: controlled object, reason, affected decision, expected behavior, prohibited behavior, evidence plan, accountable approver, and rollback trigger. Attach the before-and-after configuration and test outputs. When a vendor-managed component changes without complete detail, record the uncertainty and constrain the release instead of pretending the baseline is fully known.

NIST’s AI RMF says risk management should be continuous across the AI lifecycle and organizes work through govern, map, measure, and manage (NIST AI RMF Core). Applied here, governance assigns authority, mapping identifies affected work, measurement tests the intended and adverse behavior, and management determines release, restriction, or rollback.

Sources: [2]

Worked artifact: retrieval-source change

Imagine a synthetic policy-answering assistant. The team replaces a manually curated source folder with a larger shared repository. The technical connection succeeds, but the decision-bound record identifies a new failure: superseded policy versions may now be retrieved alongside current ones.

The evidence plan uses twelve dated questions with known answers, including conflicting versions and missing-source cases. Reviewers record which document supported each response and whether the assistant exposed uncertainty. The rollout is limited to drafting until the current-version rule passes. The rollback trigger is any answer that cites a superseded policy as current. The artifact includes source snapshots, test results, reviewer notes, and the release decision.

Close the change with operating evidence

After release, sample actual use within the approved boundary. Check whether permissions, source versions, user instructions, and required review steps match the approved state. Reopen the change if the vendor, data, or operating context moves materially. A passed pre-release test is not permanent assurance.

Treat unknown vendor changes as changes

Some services update models or orchestration without exposing every internal detail. The absence of a complete change log does not mean nothing changed. Record the first observed date, affected outputs, evidence available from the provider, and the local tests that can detect a material behavioral shift. Reduce the permitted scope if the uncertainty exceeds the organization’s tolerance.

Avoid using one benchmark set forever. Preserve a stable regression core for comparison, but add cases from new failure reports and changed workflows. Reviewers should be able to explain why each case matters and which release decision it informs. Test volume without decision relevance can create false comfort.

This method does not establish legal compliance, security control effectiveness, or fitness for a regulated use. It provides a traceable way to make and revisit a change decision. Applicable policies, technical controls, qualified reviewers, and current operating evidence remain authoritative.

For emergency changes, record the reduced evidence available, temporary scope, approving authority, and deadline for retrospective review. Emergency status should shorten the control path only as authorized; it should not erase the baseline, test, or rollback record needed to understand what entered production.