Which decisions can be automated
Automate favourable or low-impact decisions, route adverse or high-impact decisions to a person.
Why. Matches oversight to consequence.
Trade-off. Review capacity must be planned.
AI governance and assurance · Automated decisioning · human review
Automated decisioning platform: rules and models with explainability, human review and appeals
A decisioning pattern for decisions that affect people: rules and model scores combine in a versioned decision service, every outcome carries reasons, uncertain or adverse cases go to a trained reviewer and affected people have a clear route to challenge.
A reference architecture from EITSAA, not a named client system. Service limits, prices and product features change, so confirm current details before you commit to a design.
- Voluntary AI Safety Standard (human control, challenge)
- AI Ethics Principles
- Privacy Act APP 1.7 to 1.9 from 10 December 2026
- ISO/IEC 42001
- NIST AI RMF
- ACSC Essential Eight
Architecture
- People and clients
- Compute and containers
- Security and identity
- AI and ML
- Monitoring, audit and analytics
- Request or data flow
- Asynchronous or optional
- Boundary: region, account, network or trust zone
Request and data flow
A person or case enters through intake, which validates the request and collects only the data the decision needs.
The rules engine applies versioned policy and eligibility rules, and records which rules fired.
The scoring model receives features and returns a score with confidence. It has been validated and is monitored.
The decision service combines rule outcomes and score into a recommendation, with reasons and a confidence level, applying thresholds set by policy.
The explanation service turns rule hits and the main factors into plain-language reasons suitable for the person affected and the reviewer.
Favourable, high-confidence outcomes may proceed automatically if policy allows. Adverse, borderline or low-confidence cases go to a trained human reviewer who can change the outcome.
People can challenge an outcome. Appeals go to a reviewer independent of the original decision with authority to overturn it.
Every decision is logged with inputs, model and rule versions, reasons, reviewer actions and timestamps.
Monitoring analyses outcomes, overrides and appeals by group over time to detect drift, bias and process problems, and feeds model and rule changes.
Components and why they were chosen
| Component | What it does | Why this choice |
|---|---|---|
| Rules engine (DMN-based engines, Drools, cloud rules services) | Transparent, versioned policy logic. | Business-owned rules with audit. |
| Scoring model | Predictive input to the decision. | Handles patterns rules cannot. |
| Decision service | Orchestrates rules, scores and thresholds. | One place to version and test decisions. |
| Explanation service | Reasons and factors. | People deserve understandable explanations. |
| Case management for review and appeals | Queues, SLAs and outcomes. | Meaningful human control. |
| Decision log (immutable) | Full reproducibility. | Evidence for audit, complaints and FOI. |
Design decisions and trade-offs
Model or rules
Rules for policy, model for patterns, both visible in the reasons.
Why. Keeps policy explicit and auditable.
Trade-off. More components to test.
Explanation depth
Plain-language reasons for people, detailed factors for reviewers.
Why. Different audiences, different needs.
Trade-off. Explanation methods must be validated as faithful.
Reviewer design
Give reviewers context, time and authority and measure overrides.
Why. Avoids rubber-stamping and automation bias.
Trade-off. Higher operating cost.
Appeals
Independent reviewer and published process.
Why. Procedural fairness.
Trade-off. Requires clear service levels.
Well-architected pillars
Security
Least-privilege access to personal data, encryption, tamper-evident logs and protection against gaming of rules.
Reliability
Versioned rollbacks, a manual fallback process and idempotent processing.
Performance
Low-latency scoring for interactive decisions, batch for the rest.
Cost optimisation
Automation of routine favourable cases funds review of complex ones.
Operational excellence
Regular rule and model reviews, reviewer calibration and appeal analytics.
Sustainability
Reuse features and retire obsolete rules.
Network, identity and data
Networking
The platform runs in a private network. Data sources are accessed through private endpoints. Case management is available to authorised staff through SSO. Public intake is separated from decision services.
Identity and least privilege
Reviewers and administrators use SSO with MFA and role-based access. Rule authors cannot approve their own changes. Appeal reviewers are independent of first-instance staff.
Data and encryption
Minimise personal information and document the lawful basis. Exclude protected attributes from decisions unless justified, and use them only for fairness testing under controls. Retain logs for the period required by law and policy.
Security and compliance mapping
| Control | How this design addresses it |
|---|---|
| Human control and challenge | Review queues and appeals support Voluntary AI Safety Standard guardrails 5 and 7. |
| Transparency | Reasons and disclosure support guardrail 6 and the Privacy Act automated decision-making transparency from 10 December 2026. |
| Testing and monitoring | Validation and outcome monitoring support guardrail 4. |
| Records | Decision logs support guardrail 9 and FOI and records obligations. |
| Restrict administrative privileges | Separation of duties for rule and model changes. Essential Eight. |
Mappings show how the design supports each control. They are not certifications, and EITSAA does not claim IRAP assessment or compliance for any reference architecture.
Failure modes, targets and scaling
- Target RTOPer process criticality, with a manual decision process ready within the tolerance level.
- Target RPONear zero for decision logs and case state.
- Scaling and limitsSized by case volume and review queue throughput.
| Failure mode | Mitigation |
|---|---|
| Reviewers approve whatever the system suggests | Measure override rates, sample reviews and rotate reviewers. |
| A rule error affects many people | Test rules, stage releases and be able to reverse decisions in bulk. |
| Explanations do not reflect the real drivers | Validate explanation methods and prefer inherently interpretable models where possible. |
| Outcomes differ unfairly by group | Fairness monitoring, thresholds and a review and remediation path. |
| Appeals queue backs up | Service levels, capacity planning and root-cause feedback into rules. |
Observability and runbooks
- Auto-decision, referral and override rates.
- Time to review and appeal outcomes.
- Outcomes and error rates by group.
- Model and rule version in force per decision.
Cost drivers and levers
Review staff time, model and rule maintenance and log storage.
- Automate low-risk favourable cases.
- Improve rules from appeal findings.
- Batch non-urgent scoring.
- Train reviewers to reduce rework.
Implementation and fit
Phased approach
- Inventory decisions, classify impact and design the review and appeal routes.
- Build the decision service with versioned rules and logging.
- Add the validated model, explanations and fairness monitoring.
- Introduce selective automation and publish disclosure.
Anti-patterns to avoid
- Fully automating adverse decisions.
- Explanations that are generic text.
- No way to contest an outcome.
- Rules in code that only developers can read.
- Never examining outcomes by group.
When to use it
- Eligibility, triage, risk and prioritisation decisions affecting people.
- Agencies and regulated entities meeting transparency duties.
When not to
- Decisions where a person should always decide and automation adds risk.
- Processes with too little data to validate a model.
More in ai governance and assurance
Evaluation · red-teaming · CI
AI evaluation and red-team pipeline: golden sets, adversarial tests, release gates and CI
A pipeline that turns testing into a release gate: golden sets and adversarial suites run in CI against every change, scores are compared with thresholds by risk tier, failures block promotion and results become evidence.
Observability · incident response
AI observability and incident response: tracing, quality metrics, drift detection, alerts and runbooks
How to see what AI systems are actually doing and respond when they misbehave: end-to-end tracing, quality and safety scoring on sampled traffic, drift and cost detection, alerting tied to runbooks and post-incident learning that feeds testing.
Data governance · privacy · lineage
Responsible AI data governance: classification, consent, lineage and retention for training, retrieval and prompts
How data is governed across the AI lifecycle: sources are classified and assessed for lawful use, consent and purpose are enforced, lineage tracks data into training sets, indexes and prompts, and retention and deletion apply to every derived copy.
Related insights
Discuss this architecture
Tell us your systems, constraints and timeline. We reply within one business day, and the initial conversation is free.