Your GenAI Approval Needs an Expiry Trigger.

A GenAI approval records what passed on one date. It does not prove the live system still deserves approval. Give every material use case a living validation passport with explicit failure modes, change triggers, expiry and a human-controlled stop-use rule.*

The approval memo is not the control. It is evidence that a particular configuration passed particular tests for a particular purpose at a particular time. For materially changing or dynamic systems, point-in-time validation alone is too weak.

Change the provider model, prompt, retrieval corpus, transformation, tool permissions, safety settings or business use, and the evidence may no longer answer today's question. Production monitoring may also expose a failure the original test set missed.

The practical answer is a living validation passport. It links the approved use case to its known failure modes, pass criteria, evidence, accountable approval, monitoring, revalidation triggers, expiry and stop-use conditions. This is a control design proposed by TheAICommand. APRA and ASIC do not prescribe a document called a validation passport.

Why does approval decay after deployment?

GenAI is more than a model name. Behaviour can depend on provider version, instructions, retrieval content, transformations, connected tools, access settings and the user's task. A change at any surface can separate the live system from the tested configuration.

Not every deployed GenAI instance learns from your organisation's users. That distinction matters. Approval can still age because a provider changes or retires the model, a team edits the prompt, source material changes, a connector gains a new permission, or staff start using an approved assistant for a different purpose.

Treat this as validation half-life, a working governance concept, not a regulatory metric. Criticality, uncertainty and exposure to change determine how long evidence can be trusted. Calendar review is the backstop; observable changes should drive faster action.

An annual review date alone misses the point. A low-risk drafting assistant may tolerate minor wording changes. Claims, credit, prudential reporting or member-servicing workflows may need revalidation before a material change reaches production. A named owner decides.

What do the standards and regulators actually say?

As at 31 July 2026, four different layers must be kept separate.

First, Prudential Standard CPS 220 Risk Management is enforceable for banking and insurance entities within scope and has been in force since 1 July 2019. It requires a framework for material risks. Paragraph 35 requires policies and procedures for validating, approving and using models that measure components of risk. This does not automatically make every GenAI tool a regulated risk model. The broader framework still matters where a use case presents material risk.

Second, Prudential Standard SPS 220 Risk Management is the enforceable counterpart for RSE licensees, in force since 1 January 2020. It requires a framework covering material risks, documented roles, controls, monitoring and effectiveness review. CPS 220 expressly excludes RSE licensees from its definition of an APRA-regulated institution and refers readers to SPS 220, so a group template should not silently apply the banking and insurance standard to a trustee.

Third, Prudential Practice Guide CPG 235 Managing Data Risk is non-binding guidance, current from 1 September 2013. It says data-control adequacy would normally be assessed when a process is introduced, regularly afterwards, and after material change to the process, data use, controls or external environment. Its discussion of quality, ownership, lineage, metrics and ongoing effectiveness informs passport fields. It is not an AI validation template.

Fourth, APRA's 30 April 2026 letter gives supervisory observations from selected large banks, insurers and superannuation trustees. APRA labels it guidance based on current observations. It found lifecycle-control gaps across much of that sample and said point-in-time and sample-based assurance was ill suited to probabilistic models that learn, adapt and degrade. It expected lifecycle assessment and monitoring proportionate to use-case criticality.

ASIC's separate conduct-governance findings appear in Report 798, released 29 October 2024. Its targeted, non-representative review covered 624 consumer-impacting use cases reported by 23 AFS and credit licensees as at December 2023. It excluded back-office functions, investing, markets and trading activities, and models used for compliance with laws administered by other regulators. ASIC did not test consumer outcomes from individual models. Monitoring varied widely, and ASIC described periodic review of model data and output as better practice. It classified as poorer practice one case in which a licensee changed thresholds without root-cause or customer-impact analysis. REP 798 is not a prudential standard and does not mandate this passport.

Kept side by side, the layers look like this:

What belongs in a living validation passport?

Keep the passport short enough to use and structured enough to query. Link it to the test artefacts rather than stuffing every result into one record. If your organisation already keeps an AI use-case register, the passport hangs off that record rather than duplicating it.

Use this minimum-field checklist:

• Identity and purpose: [USECASEID], approved purpose, prohibited uses, business owner and risk tier.
• Configuration: provider, model identifier, system prompt version, retrieval collection, transformations, tools, permissions and safety settings.
• People and impact: intended users, affected customers or members, required human review and the decision that remains with a person.
• Failure modes: plausible ways the system can be wrong, unsafe, unfair, insecure or misleading, including low-frequency, high-severity cases.
• Pass criteria: thresholds for each critical failure mode, not only an average quality score. One critical failure can outweigh a strong aggregate result.
• Evidence: synthetic test-set version, execution date, result location, unresolved limitations and independent challenge. For material executions, the evidence pairs naturally with a run-lineage packet that lets a reviewer rebuild the inputs.
• Authority: accountable approver, approval date, conditions, control owner and second-line review where required by internal policy.
• Live limits: production indicators, thresholds, monitoring frequency, incident route and human fallback.
• Change control: events requiring triage, partial testing, full revalidation or immediate stop-use.
• Validity: next review date, expiry date, current state and the person authorised to suspend or restore use.

The useful status is not simply approved. Use states such as APPROVEDWITHINSCOPE, REVALIDATIONDUE, SUSPENDED and RETIRED. Each state should be machine-readable, but only a person with delegated authority should move the use case into or out of production.

Use this prompt to challenge the failure-mode library against approved, synthetic material. The business control owner and an independent risk specialist must review the suggestions, set thresholds and approve any change.

Review this approved GenAI use-case specification and synthetic test summary. Identify missing failure modes, weak pass criteria and tests that could pass while a severe customer, member, prudential, privacy or security harm remains. Return: failure mode, cause, affected party, observable indicator, proposed synthetic test and proposed threshold. Do not approve the use case, change risk appetite or waive a failure. Mark every proposal HUMAN REVIEW REQUIRED.

[APPROVED_USE_CASE_SPECIFICATION]
[SYNTHETIC_TEST_SUMMARY]
[CURRENT_FAILURE_MODE_LIBRARY]

Do not let the same system grade its own performance without independent evidence. AI may assist with test-case drafting, result collation and anomaly surfacing. Humans must define the intended purpose, decide materiality, set acceptable limits, investigate failures and authorise use.

Which changes force revalidation or stop-use?

Build a change-event cascade rather than sending every alteration through the same committee. Triage the event against the passport, then apply one of four responses: record only, targeted test, full revalidation, or immediate stop-use pending human investigation.

At minimum, capture changes to the provider model or version, system prompt, retrieval corpus or schema, transformation logic, tool or connector permissions, safety settings, intended users, affected population and approved purpose. Add incidents, complaints, control breaches, abnormal performance, legal or policy changes and scheduled expiry. A vendor breach is a change event too, not only a privacy notification problem. A vendor's description of a change can inform triage. It cannot replace your organisation's impact assessment.

Expiry and stop-use are different. Expiry says the approval has run out and use cannot continue until a human renews it. Stop-use is an immediate control response to a defined event, such as a critical test failure, unexplained data exposure, prohibited tool action or output that could cause material customer harm. The passport should name the safe fallback and who may restore service after evidence is reviewed.

Fictional worked example: [USECASEID] assists a risk team to draft monitoring commentary from approved, aggregated control metrics. It does not determine the control rating or approve the report. After [MODELVERSION] changes, the aggregate accuracy score remains 98 per cent. Yet the assistant invents a root cause in two of 20 sparse-data tests, breaching the passport's zero-tolerance criterion for unsupported causal claims.

The status moves to SUSPENDED. Staff return to the approved manual template. The owner fixes the instruction and retrieval constraint, reruns the full critical-failure suite, records the evidence and seeks fresh human approval. The 98 per cent headline never overrides the failed critical criterion.

Use this prompt to compare an approved configuration with a proposed one. The system owner and second-line reviewer must verify the inventory, decide the test scope and authorise the resulting status.

Compare the approved and proposed configuration manifests. List every change to model, instructions, retrieval data, transformations, tools, permissions, safety settings, users and purpose. Map each change to existing failure modes and controls. Recommend record only, targeted test, full revalidation or stop-use, with reasons. Do not authorise deployment or infer that an omitted field is unchanged.

[APPROVED_CONFIGURATION_MANIFEST]
[PROPOSED_CONFIGURATION_MANIFEST]
[VALIDATION_PASSPORT]

Do this Monday

1. Choose one material use case. Start where an output informs customer, member, prudential, compliance or operational work. Confirm the human decision owner and safe fallback.
2. Reconstruct what was approved. Record the exact configuration, purpose, users, test set, results, conditions and approval. If the evidence cannot identify the tested system, mark revalidation due.
3. Name critical failures. Set separate, human-approved criteria for unsupported claims, data leakage, prohibited actions, harmful cohort effects and loss of required human review.
4. Install the change-event cascade. Connect vendor notices, configuration management, retrieval updates, access changes, incidents and complaints to one triage queue.
5. Set expiry and stop-use. Give the passport a review date, explicit suspension thresholds, a manual fallback and named restoration authority.
6. Test the control itself. Run a fictional model-change scenario and confirm the alert, evidence, decision, fallback and status update can be reconstructed.

Bottom line

A launch approval proves only that one defined system passed one defined test. CPS 220 and SPS 220 set enforceable risk-management baselines within their respective scopes, while CPG 235 offers non-binding data-risk guidance. APRA's AI letter adds supervisory observations and expectations; ASIC REP 798 reports thematic findings and better-practice examples. None prescribes a validation passport. Use the passport as your own living control, with failure-specific criteria, change triggers, expiry and a human stop-use decision that keeps approval attached to the system actually operating.

This article is general information and education only. It is not legal, compliance, financial or professional advice. Obligations vary by organisation and circumstance. Verify current requirements against the primary sources cited and seek advice specific to your situation.

References

1. APRA, Prudential Standard CPS 220 Risk Management, in force from 1 July 2019: https://www.apra.gov.au/standards/cps-220
2. APRA, Prudential Standard SPS 220 Risk Management, in force from 1 January 2020: https://www.apra.gov.au/standards/sps-220
3. APRA, Prudential Practice Guide CPG 235 Managing Data Risk, current from 1 September 2013: https://www.apra.gov.au/practice-guides/cpg-235
4. APRA, APRA Letter to Industry on Artificial Intelligence (AI), Summary of common weaknesses and expectations for regulated entities, published 30 April 2026: https://www.apra.gov.au/news-and-publications/apra-letter-industry-artificial-intelligence-ai
5. ASIC, Report 798 Beware the gap: Governance arrangements in the face of AI innovation, released 29 October 2024: https://download.asic.gov.au/media/mtllqjo0/rep-798-published-29-october-2024.pdf