Internal audit should be able to select any material AI use, identify its current production configuration, trace the last consequential change and reproduce the evidence used to approve that change. If the answer is spread across a vendor portal, a project ticket, a policy document and an employee’s memory, the credit union does not yet have a reliable audit trail.

The starting point is broader than a traditional model list. A member-service assistant may change because its foundation model, system prompt, knowledge base, retrieval rules, integration, permissions or escalation logic changed. A fraud tool may add a data source or alter a decision threshold without changing the model name. Inventory and change control should therefore follow the complete AI system and its business use—not only the statistical model at its center.

The NCUA’s current AI resource page says examiners evaluate internal controls, ongoing risk monitoring and third-party due diligence within the existing supervisory framework. It does not prescribe this seven-record file. The approach below is an operating method for producing evidence against those expectations.

1. Create a use-level inventory record

Record the business purpose, member or employee population, owner, vendor, current status and downstream decision for every AI use. Include AI embedded inside other software and employee tools, not only systems purchased under an AI budget. Mark whether the output informs staff, drafts content, recommends an action or executes one.

Audit evidence: each use has a stable identifier, accountable business owner, technical owner, risk tier, production date and links to its governing policy and vendor record. This extends the visibility problem described in Most Credit Unions Are Using AI Already into a system of record.

2. Define materiality and change triggers

Write down what forces review before a change reaches production. Useful triggers include a new model or major model version; a new data source; a prompt or knowledge-base change that can alter member-facing answers; expanded user permissions; a new automated action; a decision-threshold change; a new vendor or subprocessor; or movement into a regulated, consequential or high-volume workflow.

Not every wording correction needs committee approval. The control should be risk-based: pre-approve low-risk maintenance categories, but prevent teams and vendors from deciding after the fact that a consequential change was “minor.”

3. Freeze a production baseline

For each release, retain the model and service version, prompts or rules, approved knowledge sources, data interfaces, permissions, guardrails, thresholds and human escalation route. For vendor systems, record what the credit union can see and what remains vendor-controlled. A dated screenshot of a settings page can support the file, but it should not substitute for a machine-readable export or configuration record when one is available.

Audit evidence: a reviewer can distinguish the configuration that passed testing from the one operating today and can identify every approved difference.

4. Attach a risk-and-test plan to the change

State what the change is intended to improve, what could break and which tests must pass. Select tests from the actual use: source accuracy and hallucination for retrieval systems; reason accuracy and outcome analysis for lending; false positives and missed cases for fraud; privacy leakage and authorization for internal copilots; authentication, accessibility and human handoff for member service.

The voluntary NIST AI RMF Playbook organizes suggested actions around Govern, Map, Measure and Manage. Treasury’s 2026 Financial Services AI Risk Management Framework adapts that structure to financial-services operational, regulatory and consumer-protection considerations and is designed to scale by institution size and complexity. Neither resource replaces legal or supervisory requirements, but both can help teams connect a change ticket to a consistent risk vocabulary.

5. Preserve approval and effective challenge

The person requesting a material change should not be the only person deciding whether its evidence is sufficient. Define the required approvers by risk tier: the business owner, technology, information security, compliance, model risk or another qualified reviewer. Internal audit should test whether the named reviewers had the information, expertise and authority to challenge the change—not merely whether their names appear on a ticket.

Audit evidence: the file contains the change request, test results, open limitations, reviewer comments, disposition of objections, approval conditions and production authorization.

6. Connect monitoring to the approved limits

A passing release test is a starting point. Record production measures, thresholds, review frequency and the owner who can pause the system. Monitoring might include corrected answers, overrides, exception rates, complaints, disparate outcomes, fraud loss and false positives, latency, unavailable source records, unauthorized actions or vendor incidents. When a threshold is breached, link the investigation and decision back to the inventory record.

NCUA also emphasizes that credit unions remain responsible for vendor monitoring and contract oversight for outsourced technology. The AI vendor exit playbook covers the data return, continuity and retirement evidence needed when monitoring no longer supports continued use.

7. Test rollback, retirement and retention

Define the previous safe state, who can authorize rollback, how long evidence must be retained and what happens to data, access, integrations and member communications when the system is retired. Run the rollback test before a high-risk release rather than discovering during an incident that the prior model or configuration cannot be restored.

Audit evidence: a completed rollback or shutdown test, retained decision records, terminated credentials and interfaces, vendor confirmation where needed and an updated inventory status.

A practical internal-audit sample

Sample by risk, not only by volume. Select one member-facing system, one consequential decision tool, one employee copilot, one vendor-controlled feature and one system with a recent material change. For each, ask whether the inventory, baseline, test, approval, monitoring and retirement records form one traceable chain.

Do not apply bank model-risk guidance mechanically to every AI tool. The federal banking agencies’ April 2026 revised model-risk guidance is tailored to covered banking organizations, says generative and agentic AI are outside its scope and is not an NCUA rule. Its emphasis on risk-based validation, monitoring, governance and vendor products can inform thinking, but the credit union’s own system inventory must capture the AI components that traditional model definitions miss.

The board and senior management do not need every configuration detail. They need assurance that material AI uses are known, changes cannot bypass review, results are monitored against approved limits and a qualified person can stop or reverse the system. CreditUnionAI News’ board AI oversight guide provides the corresponding reporting questions.

Make the evidence chain the control. Subscribe to the CreditUnionAI Weekly Briefing for practical AI governance and implementation coverage.

Get the Weekly Briefing