Government AI teams can pass a pre-deployment evaluation and still operate a poor service. The model may stay within its accuracy threshold while people abandon the transaction, staff quietly work around it, costs climb, or harmful edge cases concentrate in a group hidden by the average.
That is why AI monitoring cannot stop at model health. The Australian Government’s AI Technical Standard and Digital Performance Standard point to a broader operating model: monitor whether the AI behaves as intended and whether the digital service continues to help people complete the task they came to do.
The practical answer is one operating scorecard with two linked views. One view covers the AI system — drift, safety, reliability, cost and control effectiveness. The other covers the service — completion, satisfaction, accessibility, assisted-channel demand and outcomes. Neither is enough on its own.
Two Standards, One Operational Obligation
The AI Technical Standard organises controls across the AI lifecycle. Its monitor stage covers operation and maintenance after deployment, when changes in inputs and the operating environment can degrade performance or create harm.
Statement 38 makes ongoing testing and monitoring required. It calls for periodic post-deployment testing, monitoring against operating procedures, predefined performance and drift metrics, infrastructure health, safety, reliability, human-machine collaboration, unintended consequences, transparency, cost, security and compliance. Statement 39 requires incident handling plus corrective and preventive action, including root-cause analysis and detailed records.
The Digital Performance Standard covers a different but overlapping question: is the public digital service effective for the people using it? It has been mandatory since 1 January 2025 for services subject to the Investment Oversight Framework and for new or replacement public-facing services. Its criteria require a monitoring framework, availability measurement, success measurement, customer-satisfaction measurement, and analysis and reporting that leads to improvement.
Put together, the standards expose a common delivery mistake. A dashboard showing latency, token use and evaluation scores may prove that an AI component is technically alive. It does not prove that a person received a correct answer, understood what to do next, completed their transaction, or had a workable path when the AI failed.
Start With the Service Outcome
Before choosing model metrics, define the outcome the service exists to achieve. The AI Technical Standard’s Statement 12 warns against relying on one metric and asks agencies to select complementary measures across value, performance, safety, reliability, adoption, human-machine teaming and qualitative experience. It also asks teams to document trade-offs and keep verifying that the metrics reflect real success and failure.
For a government service, a useful measurement tree starts with four questions:
- Did people achieve the intended outcome? Measure successful end-to-end completion, not just clicks on the AI feature.
- Was the outcome correct and safe? Sample decisions or generated content against authoritative sources, policy and known failure cases.
- Was the experience fair and usable? Segment results where lawful and appropriate, test accessibility, and look for cohorts missing from the data rather than averaging them away.
- Could the service recover? Track fallbacks, human intervention, complaints, corrections, reversals and time to restore a safe path.
These questions prevent a team from mistaking adoption for value. More prompts, longer sessions or higher AI utilisation can mean success. They can also mean confusion, rework or a service that makes users ask the same question repeatedly.
Build a Dual-Layer Scorecard
The scorecard should connect system signals to service outcomes without collapsing them into one magic number.
AI-system measures might include:
- task-specific quality against a versioned evaluation set;
- groundedness, citation validity and unsupported-claim rate;
- input, output and performance drift;
- harmful-output, sensitive-data disclosure and misuse indicators;
- human override and intervention rates;
- availability, latency, error rate, recovery time and failover success;
- cost per completed task, not merely cost per model call;
- model, prompt, retrieval index and policy version in effect for each evaluated result.
Service measures might include:
- end-to-end completion and abandonment;
- first-contact resolution and repeat-contact rate;
- customer satisfaction at meaningful points in the journey;
- accessibility defects and completion with assistive technology;
- transfer to phone, counter or staff-assisted channels;
- complaints, contest requests, corrections and reversals;
- staff effort, queue time and rework created or removed by the AI path.
Then map the layers. A fall in completion alongside stable model accuracy may point to confusing interaction design or a broken hand-off. Rising human override may indicate drift, but it may also reveal that policy changed before the evaluation set did. Lower call-centre volume looks positive until complaints or abandoned transactions rise. The value comes from investigating these relationships, not decorating a dashboard.
Give Every Signal an Owner and a Decision
A metric without an action path is observability theatre. The AI Technical Standard’s Statement 37 recommends defining reporting audiences, alert severity, thresholds, recipients and feedback loops that turn insight into system improvement.
For each important measure, record:
- the owner who can decide or escalate;
- the baseline, target and tolerated range;
- the data source and collection frequency;
- which model, prompt, knowledge base, workflow and policy version the measure applies to;
- the warning and stop thresholds;
- the immediate response, such as investigation, restricted mode, human-only fallback or rollback;
- the evidence needed before normal operation resumes.
Reserve real-time alerts for conditions requiring real-time action. A suspected data leak, unsafe autonomous action or sharp failure-rate increase may justify an immediate page. A slow change in satisfaction or a demographic participation gap usually needs scheduled analysis with enough context to avoid false alarms.
Monitor What the Average Hides
Aggregate performance is especially dangerous in public services. An overall completion rate can improve while outcomes deteriorate for people using screen readers, people with limited English, regional users on slower connections, or users whose circumstances are uncommon in the evaluation set.
The Technical Standard explicitly asks agencies to monitor unintended consequences, provide channels to report issues or contest outcomes, analyse quantitative and qualitative evidence for recurring harms, and look for missing data such as groups not using the system. The Digital Performance Standard likewise requires user feedback and a holistic view of the journey.
Practical controls include:
- predefined cohort and edge-case slices in the evaluation suite;
- regular moderated sessions with people using the live journey;
- accessible in-context feedback that does not require the AI interaction to succeed;
- review of non-use and assisted-channel demand, not only successful AI sessions;
- privacy-preserving analysis designed with legal, data and accessibility specialists.
Not every service can or should collect every demographic attribute. Where direct measurement would be inappropriate, combine lawful proxy-free telemetry with qualitative research, complaints, frontline staff evidence and targeted accessibility testing. “We do not have the data” should trigger a safer evidence plan, not a claim that no disparity exists.
Treat Change as a Revalidation Event
AI services change even when the agency does not deploy code. Vendors update models, retrieved content changes, user behaviour shifts and policy material is amended. A static launch evaluation decays.
The AI use case impact-assessment requirements reinforce this point: agencies must regularly monitor in-scope use cases and re-validate the assessment when scope, usage or operation changes materially. Vendor and regulatory changes also need attention.
Make those triggers explicit. Re-run the relevant assurance when:
- the model or provider changes;
- a prompt, tool set, retrieval source or ranking method changes materially;
- the service reaches a new user group or supports a higher-impact task;
- a human approval step is removed or authority expands;
- production monitoring reveals drift, repeated complaints or a new harm pattern;
- policy, legislation, security classification or vendor data handling changes.
This extends the release discipline in our article on making AI impact assessment a release gate. The assessment establishes the approved operating assumptions. Monitoring tests whether those assumptions remain true after launch.
A Minimum Viable Operating Pack
A team does not need a giant observability programme before it can operate responsibly. It does need a small, coherent pack that joins engineering, service design and governance evidence.
- Outcome map. State the user outcome, possible harms, fallback path and success measures.
- Versioned evaluation set. Include normal tasks, edge cases, policy-critical cases and known failure examples with clear expected behaviour.
- Dual-layer dashboard. Show AI-system health beside completion, satisfaction, accessibility and assisted-channel indicators.
- Alert and intervention matrix. Define severity, owner, response, communication and recovery evidence.
- Change and revalidation log. Tie model, prompt, retrieval, workflow and policy changes to the tests and approvals they trigger.
- Incident and learning record. Capture impact, root cause, corrective action, preventive action and the resulting update to evaluation or monitoring.
Start this pack during discovery, as the Digital Performance Standard advises, rather than inventing it after production traffic arrives. The first useful dashboard is not the one with the most charts. It is the one that tells an accountable owner when to intervene and whether the service improved after they did.
What This Means for GovCMS and Drupal Teams
An AI feature connected to GovCMS or Drupal is still part of a broader publishing and service journey. Monitoring the model alone misses the risks created by stale source content, workflow bypass, inaccessible generated markup, incorrect citations or a hand-off that strands the user.
For content drafting, retrieval and conversational navigation, include measures such as:
- citation links resolving to current authoritative pages;
- answers grounded in the approved content set and release state;
- corrections propagating through indexes and caches within a defined time;
- human editorial rejection and rewrite reasons;
- accessibility conformance of generated or transformed content;
- successful navigation to the next service step rather than chatbot engagement alone.
This is where the content controls in treating the data pipeline as part of the system meet live service measurement. Provenance and permissions protect the input path; outcome monitoring shows whether the resulting experience is still correct and useful.
A 30-Day Implementation Path
- Week 1 — define outcomes and baselines. Choose one live or near-live AI use case. Map the end-to-end journey, baseline completion and support demand, then define complementary AI and service measures.
- Week 2 — instrument and version. Add telemetry at the model, retrieval, workflow and service layers. Record the component versions needed to reproduce an evaluated result.
- Week 3 — set intervention rules. Agree warning and stop thresholds, owners, human-only fallbacks, incident routes and revalidation triggers. Rehearse one degraded-service scenario.
- Week 4 — run the operating review. Review the dual-layer scorecard with product, operations, security, service design and the accountable use case owner. Turn findings into tracked corrective actions and update the evaluation set.
At the end of the month, the team should be able to answer a better question than “Is the model up?” It should be able to show whether the service is helping people, where it is failing, who acts, and how the evidence changes the next release.
Working with NAITEC Digital
NAITEC Digital helps Australian Government teams turn AI standards into practical delivery and operations. We can define measurable service outcomes, build evaluation and monitoring frameworks, instrument AI and digital-service journeys, design incident and fallback paths, and integrate the evidence into GovCMS, Drupal and custom software delivery.
We are a Newcastle, NSW software consultancy, a BuyICT registered supplier, and GovCMS/Drupal specialists on the Drupal Services Panel. Our capabilities span AI integration, automation and custom software delivery and government digital services, GovCMS and Drupal.
If your dashboard can show model uptime but not whether people complete the service safely, talk to NAITEC Digital. We can help build the missing operational evidence.
Frequently Asked Questions
Is monitoring required after an Australian Government AI system is deployed?
For agencies adopting the AI Technical Standard, required criteria in Statement 38 cover periodic post-deployment testing and ongoing monitoring across performance, drift, safety, reliability, human-machine collaboration, unintended consequences, transparency, cost, security and compliance. The responsible-use AI policy also requires regular monitoring and evaluation for in-scope use cases.
Why are model accuracy metrics not enough?
They describe only part of the system. A model can meet its technical threshold while the full service creates abandonment, rework, inaccessible interactions, incorrect hand-offs or unequal outcomes. Service completion, satisfaction, support demand and qualitative research reveal failures that model metrics cannot.
Which services must apply the Digital Performance Standard?
The standard is mandatory for digital services subject to the Investment Oversight Framework and for new or replacement public-facing services. It came into effect for new and replacement public-facing services on 1 January 2025.
What should trigger AI revalidation?
Triggers should include material changes to scope, usage or operation, as well as model or provider changes, new data or retrieval sources, expanded authority, removed human controls, repeated incidents, and relevant vendor or regulatory changes.
Can NAITEC Digital help implement AI monitoring?
Yes. NAITEC Digital can connect AI evaluation, observability, service-performance measurement, GovCMS/Drupal workflows, incident handling and revalidation into one operating model. Contact us to discuss the use case.