Every mature compliance function runs on cycles. Quarterly reviews. Annual audits. Triennial re-certifications. The cycle is not arbitrary — it reflects a practical truth about human-administered governance: you can only look carefully at a system so often before the cost of looking exceeds the cost of the risk.

That calculus was reasonable when the systems being governed changed on the same timescale as the review cycles.

AI systems do not change on that timescale.

How Traditional IT Audit Cycles Were Designed

The modern IT audit is descended from financial accounting practices developed in the mid-20th century. Its core logic is retrospective: gather evidence of what happened over a defined period, verify that the evidence is accurate, and report on findings.

This works well for systems whose state can be meaningfully described by a retrospective review. A financial ledger at year-end is a legitimate snapshot of the year's transactions. An HR payroll system audited in July describes a stable process that has been running consistently.

The assumptions embedded in this model are worth making explicit:

The system being audited does not materially change during the audit.
Historical state is a reliable proxy for current state.
The audit scope captures the significant risks.
A twelve-month cycle is appropriate to the rate of change.

Every one of these assumptions fails for modern AI systems.

Why AI Systems Invalidate the Classic Model

Three characteristics of AI systems make the traditional audit cycle structurally inadequate.

Model drift. A machine learning model trained on data from eighteen months ago may behave differently on current data — not because anyone changed it, but because the data distribution has shifted. Audit reports do not capture drift. They capture the model's behaviour as described at audit time.

Data distribution shift. The inputs to an AI system — user queries, documents, transactional data — evolve continuously. A credit decisioning model trained on pre-pandemic repayment data and an AI recruitment screener trained before a significant workforce shift are both operating in environments their training data did not anticipate. A point-in-time audit cannot observe this shift; it can only note that the issue has been flagged as a potential risk.

Regulatory change velocity. AI governance regulation is accelerating faster than most enterprise review cycles. APRA's CPS 230 took effect in 2025. OAIC Privacy Act reforms with automated decision-making obligations arrive in December 2026. TEQSA's focus on AI in higher education is sharpening for the same year. A governance programme that reviews AI systems annually may find itself out of compliance with frameworks that did not exist when the last review was conducted.

The Four Pillars of Continuous Assurance

Continuous assurance is not simply running audits more frequently. It requires a different structural approach, built on four pillars.

1. Automated evidence collection. Evidence that must be assembled manually by a team before a review will always lag. Continuous assurance requires that evidence is collected, hashed for integrity, and linked to the AI systems it covers as a matter of standard operational practice — not as a pre-audit sprint. SHA-256 hashing at ingestion means that when a document is needed six months later, its integrity is already verified.

2. Deterministic scoring. Assurance posture needs to be expressed as a reproducible number, not a narrative summary. A TrustScore™ — computed from control decisions across governance, risk, privacy, and transparency dimensions — provides a score that can be tracked over time, compared across systems, and reported to a board without requiring interpretation. The same inputs produce the same score, every time. No language model is involved in the calculation.

3. Immutable audit trail. Every control decision, every evidence upload, every score change must be recorded with a timestamp and linked to the actor who made it. Immutability is not a legal nicety; it is what makes the audit trail credible when it matters. A trail that can be edited after the fact is not evidence. It is a document.

4. Proactive re-evaluation triggers. The re-evaluation of an AI system should be triggered by material changes — a new training run, a change to a material data source, a change to the regulatory framework governing the system — not by the calendar. Continuous assurance infrastructure monitors the conditions that matter and surfaces re-evaluation requirements automatically.

What "Continuous" Actually Requires in Practice

Continuous assurance is a discipline before it is a technology. The technology enables the discipline; it does not replace it.

In practice, continuous assurance requires:

Role clarity. Someone within the organisation owns the assurance posture of each AI system. This owner is responsible for ensuring evidence is current, control decisions are reviewed when material changes occur, and the TrustScore reflects actual system state.
Workflow integration. Evidence upload and control review must be embedded in the AI system lifecycle — not bolted on as a compliance activity. When a system is updated, the governance workflow updates in parallel.
Infrastructure. Collecting, storing, and linking evidence at scale requires an evidence hub with integrity verification, a control evaluation pipeline, and a scoring engine that can run on demand. This infrastructure is the enabler.
Reporting hygiene. Boards and senior management need to receive assurance posture reports on a cadence that reflects the pace of change — quarterly at minimum, with alert-triggered updates when material changes affect high-risk systems.

Regulatory Signals Pointing Toward Continuous Expectations

No Australian regulator has yet mandated continuous assurance by that name. But the regulatory direction of travel is consistent.

APRA's Prudential Standard CPS 230 — Operational Risk Management, effective 1 July 2025 — requires that regulated entities maintain operational resilience, including ongoing monitoring of material service arrangements. Sections 36–40 of CPS 230 set out monitoring and reporting requirements that are ongoing obligations, not periodic events. An AI system that qualifies as a material service arrangement under CPS 230 is subject to those ongoing monitoring requirements.

The OAIC's guidance on automated decision-making under the Privacy Act reforms — which take effect in December 2026 — emphasises ongoing impact assessment rather than one-time review. The expectation is that entities understand the ongoing effects of automated systems on individuals, which requires continuous monitoring, not historical documentation.

These are signals from regulators about the direction of expectations, not definitive statements about future enforcement positions. Compliance teams should treat them as indicators of where requirements are heading, not as current mandated obligations beyond what is already published.

How Sentrify Implements the Continuous Assurance Loop

The Sentrify evaluation pipeline implements continuous assurance through a multi-stage architecture built on AWS Lambda and Step Functions.

When an AI system is registered, its governance context — risk category, applicable frameworks, relevant controls — is captured. Evidence documents are uploaded to the evidence hub, where each file is processed, hashed for SHA-256 integrity, and linked to the system.

The evaluation pipeline runs each control through a layered assessment: deterministic rule checks, evidence type validation, structural completeness verification, and freshness assessment. The results feed the TrustScore™ calculation, which computes a weighted composite across the four governance dimensions.

When material conditions change — a new evidence document is uploaded, a control decision is revised, the framework version governing the system is updated — the evaluation can be re-run on demand. The TrustScore updates. The audit trail records the change. The board receives a current number, not a historical one.

The pipeline does not use a language model in the scoring path. TrustScore is deterministic math applied to deterministic inputs. This is a deliberate architectural choice: a score that must be defensible under regulatory scrutiny cannot depend on probabilistic model outputs.

The Governance Posture Shift

Continuous assurance changes the relationship between compliance teams and the audit. Rather than treating the audit as the primary governance event, the audit becomes a verification of a posture that already exists and is already documented.

This is not a reduction in governance rigour. It is a redistribution of effort from periodic scrambling to continuous discipline. The evidence is always current. The score is always visible. The audit trail is always intact.

For AI systems operating in APRA-regulated, TEQSA-overseen, or OAIC-governed contexts, that posture is not just operationally useful. It is becoming the expectation.

For more on the mechanics of TrustScore and why it represents a structural shift in AI governance, read Why TrustScores Will Replace AI Audits. Download the AI Governance Checklist to assess your organisation's readiness across 50 checkpoints. To see the evaluation pipeline, visit Sentrify Platform.