Does Every AI System Need the Same Controls? AIRA by Risk

Your review board wants the full governance treatment for an internal FAQ bot. Meanwhile, the AI that drafts letters to citizens went live with a single sign-off.

Both are mistakes. Australia's AI Reference Architecture (AIRA) offers a better rule: the same foundation for every AI system, with controls scaled to the risk. This is the second post in our AIRA series, and it shows how to apply that rule.

What does "applying AIRA proportionately" mean?

Applying AIRA proportionately means every AI system uses the same four-part foundation, but the depth and rigour of each control matches the risk of the use case. A drafting assistant and an AI supporting eligibility decisions share the same architecture map. They do not share the same level of oversight, traceability or evaluation.

AIRA makes this explicit. Its foundational view stays relevant regardless of the technology, deployment model or use case. What differs is the detailed architecture: which capabilities are built, and how deeply.

In practice, that means asking three questions of every control:

• Do we need it at all for this use case?
• How strong does it need to be?
• Who checks it, and how often?

AIRA itself does not define risk tiers. The three tiers in this post are a practical way to apply AIRA, lined up with the low, medium and high ratings in the DTA's AI impact assessment tool.

Same foundation for every AI system. Controls scaled to the risk.

How do you decide how risky an AI use case is?

For Australian Government agencies, the starting point is the DTA's AI impact assessment tool. It rates the inherent risk of a use case across categories such as fairness, reliability and safety, privacy, transparency and contestability. The guidance is clear that the highest rating in any category becomes the overall rating. Where people are unsure or disagree, it says to choose the higher rating.

The tool starts with a threshold assessment:

• If every risk is low, the assessing officer may recommend that a full assessment isn't needed.
• If any risk is medium or higher, the assessing officer must do one of three things: complete a full assessment, change the scope or function of the use case until the risk drops to low, or decide not to proceed.

The second option matters. Sometimes the fastest way to deploy safely is to narrow what the AI is allowed to do, not to add more controls.

Sometimes the fastest way to deploy AI safely is to let it do less.

Outside government, the same logic applies. The National AI Centre's Guidance for AI Adoption gives businesses a comparable, risk-based approach.

Four questions usually decide the tier:

1. Does the output affect a specific person's rights, money, access or obligations?
2. Does the AI act on its own, or does a person review before anything happens?
3. Can the action be undone?
4. Does it use personal or sensitive information?

The three tiers at a glance

What does a low-risk AI system need?

A low-risk AI system needs enough control for people to trust the output and catch mistakes, and not much more. Typical controls are source attribution, a person reviewing the output before it is used, clear labelling that it's AI, and basic logging.

Example: an internal policy Q&A assistant. Staff ask questions about leave, travel or procurement rules. The assistant answers from approved internal documents.

Why it's low risk: it makes no decision about a member of the public, takes no automated action, and a person reads the answer before acting on it.

What it needs:

• Answers that cite the source document, so staff can check them
• A clear label that answers come from AI
• Access limited to the right documents and the right staff
• A simple feedback button, and a sample of answers checked against a test set regularly
• An easy way to switch it off

What it doesn't need: approval workflows, full decision reconstruction, or a dedicated supervisor role. Adding them slows adoption and teaches staff that AI governance means paperwork.

What does a medium-risk AI system need?

A medium-risk AI system needs a person in the approval path before its output reaches anyone outside the organisation, plus a record of what the AI produced and who approved it. It also needs an evaluation suite before release and ongoing quality sampling.

Example: an AI agent that drafts replies to customer or citizen correspondence. It reads the incoming letter, pulls relevant records and policy, and drafts a reply for an officer to send.

Why it's medium risk: the output reaches a real person and could mislead them, but a human reviews it first and no entitlement changes.

What it needs:

• A human approves every outbound reply, and the system records the AI draft, the edits and the approver
• Escalation routing, so complex, sensitive or angry correspondence goes straight to an experienced officer
• An evaluation suite run before release, covering accuracy, tone and policy compliance
• Ongoing sampling of sent replies, with alerts if quality drops
• Clear disclosure to recipients that AI assisted, where policy requires it
• Version control, so a bad prompt or model change can be rolled back quickly

Watch out for automation bias. When officers approve hundreds of good drafts, they stop reading closely. AIRA names this risk directly: the DTA lists over-reliance on AI and reduced attention during prolonged monitoring among the risks to design for. Rotate reviewers, highlight low-confidence drafts, and track how often approvers change anything.

If approvers never change a draft, check whether they are still reading it.

What does a high-risk AI system need?

A high-risk AI system needs evidence strong enough to support review, appeal and audit. AIRA lists the qualities this evidence must support: legal defensibility, procedural fairness, contestability and evidentiary integrity. In practice, that means a complete decision record, human accountability for each outcome, and the ability to roll back.

Example: AI that supports eligibility, compliance or enforcement decisions. It assesses applications or flags cases for action, using personal information.

Why it's high risk: the output affects a specific person's money, rights or obligations, often at scale. Australia already knows what automated decisions at scale can do when they go wrong.

What it needs:

• A named human decision-maker. The AI recommends and an authorised person decides. The record shows which is which.
• Decision reconstruction. For any case, you can show the inputs, the data and sources used, the model, prompt and rule versions, the AI's output, and the human decision. Our AI agent audit log checklist covers what each record should hold.
• Contestability. The affected person is told AI was involved, why the outcome was reached, and how to challenge it.
• Irreversibility guardrails. Nothing that can't be undone happens without heightened review.
• Circuit breakers. Processing pauses automatically when error rates, volumes or anomalies cross agreed limits.
• Evaluation against today's process. The system is compared with the current human or hybrid process before and after go-live, including measured bias testing across affected groups.
• Full rollback. You can return the model, prompts, data and decision rules to a known good state.
• Records management. AI outputs that form evidence of decisions are Commonwealth records under the Archives Act.

The regulatory bar is also rising. From 10 December 2026, organisations covered by the Privacy Act, including Australian Government agencies, must explain in their privacy policy when a computer program uses personal information to make or inform decisions that could significantly affect a person's rights or interests. The OAIC has published guidance on the new obligation under APP 1. Check the detail with your legal team.

High risk means evidence: who decided, on what, with which version, and how to challenge it.

Which controls are non-negotiable at every tier?

Five controls belong in every AI system, however low the risk: a named owner, access control, basic logging, a way to switch it off, and telling people when AI is involved. They are cheap to build in from the start and expensive to retrofit.

1. A named owner. Someone accountable for the use case, as the responsible use policy expects.
2. Access control. The AI only sees the data, and only takes the actions, its users are allowed to.
3. Basic logging. Enough to investigate when something goes wrong.
4. A switch-off. Anyone responsible can stop it quickly.
5. Disclosure. People know when they are dealing with AI. AIRA also asks for a non-AI option for people who decline or can't use it.

Two more apply the moment a system touches personal information or the public: privacy-by-design controls, such as redacting personal details before they reach the model, and security against threats such as prompt injection and data poisoning.

How do you avoid over-engineering, and under-engineering?

The common mistake is to apply one fixed level of control to every AI system. Set it too high and low-risk tools never launch. Set it too low and high-risk systems ship without the evidence they need. AIRA's guidance is to start with the foundation and add depth only as evidence supports it.

Signs you are over-engineering:

• A staff productivity tool needs the same approval process as a system that decides benefits
• Every agent action waits for human sign-off, so the AI saves no time
• Assurance takes longer than the build

Signs you are under-engineering:

• No one can say who owns the system
• You can't explain a decision made last month
• The pilot's controls went into production unchanged
• The model or prompt changed and nobody re-ran the evaluation

Re-tier when the use case changes. A system's tier is not fixed. An assistant that only drafted text and is now allowed to send emails or update records has moved up a tier. Its controls must move with it. The most common way risk creeps in is through added permissions, not new models.

Risk usually creeps in through new permissions, not new models.

How AgentOS sets oversight per use case

On Avesta AgentOS, oversight depth is set per use case rather than fixed across the platform. The same platform runs a low-risk knowledge assistant with source-cited answers, and an agent whose outbound actions wait in a Relay review queue with a full activity trail. Moving a use case up a tier is a configuration change, not a rebuild.

What to ask your AI vendor

• Can oversight, logging and approval rules be set per use case, or are they fixed across the platform?
• Can one platform run low-risk and high-risk workloads side by side with different policies?
• If we give an agent a new permission, what forces us to re-review its controls?
• Can you show a complete decision record for a single high-risk case?
• How do you pause one agent, or all of them, if something goes wrong?

If you're working out the tier for an AI use case, or need to show how your AI product scales its controls to risk, book a discovery call and we'll map it with you.

Sources

• Digital Transformation Agency, AI Reference Architecture, Version 1.0, 2026 (CC BY 4.0), section "Applying AIRA proportionately", available at digital.gov.au
• Digital Transformation Agency, AI Reference Architecture: A new blueprint to help government agencies design AI systems, 30 October 2026
• Digital Transformation Agency, Threshold assessment outcome, AI impact assessment tool guidance
• Digital Transformation Agency, Inherent risk assessment, AI impact assessment tool guidance
• National AI Centre, Guidance for AI Adoption, October 2025
• Office of the Australian Information Commissioner, New resources on transparency for use of AI and automated decision-making, 30 September 2026