Automated Compliance Workflows: Rules, Approvals and Evidence

Automated compliance workflows should make a decision explainable after it has been made. For each completed case, we would expect to find the evidence considered, the rule applied and the person authorised to approve the outcome. A completed task is a record of workflow progress. Treat it separately from a judgement that the underlying obligation has been met.

We use automated compliance workflows here to mean software that collects evidence, applies defined checks and routes work to the appropriate reviewer. That is a working definition, not a regulatory classification. The design question is which steps can run automatically and which decisions need accountable human approval.

Define the obligation before building the workflow

Start with a specific process, such as reviewing an inspection record. Ask the responsible domain specialist to identify the applicable obligation, its scope and what evidence would support a decision. Record the source document and the interpretation being implemented. Do not ask a developer or a language model to resolve an ambiguous obligation without that review.

Then separate the checks. A system can be configured to reject an empty date field or flag an expired document. Whether the evidence is adequate for the particular case should be a distinct decision. Label those outcomes differently, for example "required fields present" and "approved by reviewer", rather than using one "compliant" status for both.

The distinction is useful when discussing standards too. The NIST AI Risk Management Framework describes itself as voluntary and use-case agnostic. We use it here as risk-management guidance, not as a statement of a UK organisation's legal duties. Establish the actual obligations for the process separately.

Keep rules identifiable and versioned

Give each automated rule an identifier, an owner and an effective date. Keep the approved interpretation alongside its source and implementation tests. When someone changes the rule, require a recorded review before the new version becomes active.

This follows the traceability approach in Karl Wiegers and Candase Hokanson's Software Requirements Essentials, Chapter 5, Practice 16. They recommend linking derived requirements back to business rules and explain that a rule change can affect tests and databases as well as requirements.

Our recommendation is to extend that connection to each case outcome. Save the rule version actually used, rather than displaying whichever version happens to be current when someone opens the record later. If a changed interpretation requires previous cases to be reconsidered, create a separate reassessment with its own decision history. Do not silently replace the earlier result.

Before releasing a change, test a case that should pass, one that should fail, and missing or contradictory evidence. Include cases on either side of the effective date. Have the domain owner confirm the expected outcomes before developers implement the change.

Make exceptions and approval explicit

Design an exception route before allowing the normal route to close cases. Missing evidence should produce a visible unresolved state with an owner. Conflicting evidence should reach someone authorised to assess it. A failed integration should be recorded as a technical failure, not converted into a successful check.

Use a defined approval role for consequential decisions. Give the reviewer access to the source evidence and the reason the case was referred. Require a decision reason when they accept an exception or override an automated recommendation. Record who made that decision and under which authority.

For AI-assisted steps, NIST's GOVERN 2.1 and GOVERN 3.2 address documented responsibilities and defined human oversight. Our design recommendation is to make that oversight enforceable through permissions. The component suggesting an outcome should not gain approval authority merely because its output looks complete.

Test the approval controls directly. Attempt to close a case with an unauthorised account and confirm that it is refused. Try to approve a record after its supporting evidence changes. Require a fresh review rather than allowing the earlier approval to cover different evidence.

Store evidence that can be inspected later

A useful reference for logging design is NIST SP 800-53's audit controls, AU-3 and AU-9. AU-3 specifies event information, including timing, outcome and associated identities. AU-9 addresses protection against unauthorised access, alteration and deletion. These are security and privacy controls, not a complete specification for every compliance process.

For a case workflow, we recommend retaining the evidence reference, its version, the check result and subsequent approval history. Keep corrections as new entries linked to the original. Set access and retention rules appropriate to the information, rather than promising that every record will be kept forever.

Test retrieval as well as capture. Ask a reviewer to reconstruct a closed case from an export without help from its original handler. Can they find the evidence that was reviewed and distinguish an automated result from a human decision? If an attachment has been replaced, can they still inspect the version used at approval? Treat failures in that exercise as defects to fix before expanding the workflow.

Give AI a bounded task

A suitable pilot might ask AI to suggest document categories or draft a summary for a reviewer. Keep those suggestions separate from approved findings and provide links to the underlying material. Do not let a generated summary replace the source evidence or change a rule's meaning.

Set the pilot's acceptance criteria before running it. Compare suggested outputs with reviewed cases, record incorrect suggestions and test whether reviewers can identify unsupported statements. Define what happens when the model cannot produce a useful answer. An unresolved case should remain unresolved until the authorised process deals with it.

Start with one workflow and verify its permissions, exception route and evidence export. Measure review effort and corrections during the pilot before claiming an improvement. Expand only when the process owner accepts the observed results and the remaining limitations.

Update, October 2026

Our July engineering article, Closing the Loop to Full Autonomy, describes review gates with controls to pause or return work and a separate human approval to merge. The relevant connection is the separation of automated work from approval authority. It is an engineering example, not evidence that an automated compliance decision satisfies a legal obligation.

Sources

• NIST, "Artificial Intelligence Risk Management Framework (AI RMF 1.0)", 26 January 2023.
• Karl Wiegers and Candase Hokanson, "Software Requirements Essentials", first edition, Chapter 5, Practice 16, Addison-Wesley Professional, 9 March 2023.
• NIST, "Security and Privacy Controls for Information Systems and Organizations", SP 800-53 Revision 5, OSCAL derivative, derivative file dated 23 March 2021.
• Dendro Logic, "Closing the Loop to Full Autonomy", 17 July 2026. Referenced only in the October 2026 update.