Auditing AI Systems: A Practical Guide

An AI system review should establish what the system does, what can go wrong and how the team detects and handles those failures. Model output is only one part of that system. Input preparation, retrieval, permissions, validation, integrations and human review can each change the result.

The checks below support engineering and operational review. They do not establish legal compliance or replace the assessments your organization requires for its intended use.

Define the purpose and the boundary

Write down the users, allowed tasks, input sources and expected output. Identify actions the system may perform and actions that need a person’s approval. A document assistant that prepares a draft has a different boundary from a system that updates business records.

Record the important dependencies: model and prompt versions, retrieval settings, source systems and validation rules. This makes a later failure easier to reproduce and helps reviewers distinguish a model change from a change elsewhere in the workflow.

Test accepted output and failure behavior

Build a test set from representative work, with missing fields, conflicting documents, unfamiliar wording and requests outside the intended scope. Define the expected result or review criteria before running the system. Evaluate unsupported claims, omissions, incorrect calculations and whether references point to the right source.

Inspect how the system handles uncertainty. Does it stop, request more information or route an exception? Check that a reviewer can understand the evidence without having to repeat the entire task. Measure preparation plus checking effort rather than generation speed alone.

Check access, processing and human approval

Confirm which users can retrieve each source and whether those restrictions remain effective across search, drafting and exports. Map where information is stored and where model processing occurs. Application hosting and inference may use different infrastructure; review both against the requirements agreed for the project.

For workflows with consequential actions, test the approval boundary and the behavior after rejection. Check that retries do not duplicate an approved action and that failures leave a state the operator can understand. Use the workflow’s actual responsibilities to decide what evidence must be retained.

Keep a review record and a change process

Maintain a record of the test cases, observed defects, accepted limitations and the decision to release or hold a change. Assign responsibility for incidents and define how users report a problematic result. Retest relevant cases after changes to prompts, models, retrieval or source data.

The NIST AI Risk Management Framework and its Playbook provide a voluntary structure for organizing AI risk work around Govern, Map, Measure and Manage. Use them to inform a review plan tailored to the system; completing a checklist is not a certification. NIST AI Risk Management Framework NIST AI Risk Management Framework Playbook

Make the findings actionable

End the review with specific defects, their owners and the evidence needed to close them. Separate immediate blockers from limitations that can be monitored within the agreed scope. Dotnitron’s engineering work can support validation, review interfaces, access boundaries and deployment choices; organizational approval remains with the appropriate owners.