Central board or federated owners
Federated ownership with a small central board for high-tier approvals.
Why. Owners know the system and the board concentrates on real risk.
Trade-off. Needs training and consistent templates so owners decide alike.
AI governance and assurance · Operating model · control framework
AI governance operating model and control framework: register, risk tiers, approvals, platform guardrails and assurance
How an organisation governs every kind of AI: leadership sets direction, an AI register and risk tiers decide how much review each system needs, an approval workflow gates release, platform guardrails enforce policy and assurance closes the loop with evidence.
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.
- Guidance for AI Adoption (six practices)
- Voluntary AI Safety Standard
- ISO/IEC 42001
- NIST AI RMF
- ACSC Essential Eight
- APRA CPS 230 and CPS 234
Architecture
- Security and identity
- Monitoring, audit and analytics
- Network and edge
- People and clients
- Request or data flow
- Asynchronous or optional
- Boundary: region, account, network or trust zone
Request and data flow
Teams register each AI system, whether built, bought or embedded in software, with its purpose, type, owner, vendor, model and data.
Executives and the AI board set risk appetite and accountability. The policy turns that into principles, a RACI and acceptable-use rules.
Policy is backed by a control library: reusable controls for each risk, mapped to the Guidance for AI Adoption, ISO/IEC 42001, NIST AI RMF and the security standards that apply.
The register entry is classified. Impact on people, autonomy, data sensitivity, scale and reversibility give the system a risk tier.
The tier selects the controls from the library, so a low-risk assistant and a high-risk decisioning model receive different, proportionate requirements.
The approval workflow routes the system to the right approver: automatic for low tiers, a named executive for medium and the AI board for high.
Only approved model, prompt and guardrail versions are released to the gateway, which enforces policy at run time and blocks direct provider calls.
Production telemetry on quality, safety, drift, incidents and cost flows to monitoring.
Monitoring and test results are assembled into evidence packs and reports for leaders, auditors and buyers.
Findings return to system owners as actions, and tier or policy changes are recorded in the register.
Components and why they were chosen
| Component | What it does | Why this choice |
|---|---|---|
| AI register (SharePoint, ServiceNow, Jira or a purpose-built tool) | Single inventory with owner, tier, approvals and review dates. | You cannot govern what you cannot see. |
| Policy and control library | Principles, RACI and reusable controls mapped to standards. | One body of work answers many questionnaires. |
| Approval workflow | Tier-based routing with separation of duties. | Fast for low risk, rigorous for high risk. |
| AI gateway and guardrails | Run-time enforcement and logging. | Governance that cannot be bypassed. |
| Monitoring and incident tooling | Quality, safety, drift and cost signals with runbooks. | Detects what pre-release tests miss. |
| Evidence repository (immutable storage) | Versioned packs per system and release. | Evidence generated by the pipeline, not assembled before an audit. |
Design decisions and trade-offs
Number of tiers
Three or four tiers with explicit criteria.
Why. Simple enough to apply and defend.
Trade-off. Edge cases need an escalation rule.
Standards mapping
One control library mapped to several frameworks.
Why. Avoids parallel compliance programs.
Trade-off. The mapping needs maintenance as standards change.
Enforcement point
A gateway admits only approved versions.
Why. Makes policy real.
Trade-off. Teams need a fast sandbox path for experiments with synthetic data.
Certification
Build to ISO/IEC 42001 and decide on external certification separately.
Why. Value comes from the controls, and an accredited body assesses certification.
Trade-off. Certification adds audit cost and effort.
Well-architected pillars
Security
Separation of duties between authors, approvers and operators, least-privilege access to the register and evidence, and signed releases.
Reliability
Register and workflow are low-availability systems with backups. The gateway has its own recovery targets. A manual approval path exists if tooling is down.
Performance
Automatic low-tier approval keeps lead time short for routine use.
Cost optimisation
Proportionate controls keep review effort on the systems that need it.
Operational excellence
Regular reviews of tiers, exceptions and incidents, with named owners for each control.
Sustainability
Retire unused models, prompts and systems and avoid duplicate evaluations.
Network, identity and data
Networking
The register, workflow and evidence store are internal services behind SSO. The gateway sits in the production network with private connectivity to approved model endpoints and no direct internet path from applications.
Identity and least privilege
SSO with MFA for all users. Authors cannot approve their own releases. Pipeline identities are workload identities with scoped permissions. Approver roles are reviewed at least annually.
Data and encryption
The register holds metadata, not business data. Evidence packs may reference sensitive evaluation data, so classify and restrict them. Retain evidence in line with records obligations and the system's life.
Security and compliance mapping
| Control | How this design addresses it |
|---|---|
| Accountability and governance | Named owners, board oversight and a RACI align with the Guidance for AI Adoption and ISO/IEC 42001. |
| Risk management | Tiering and a control library align with NIST AI RMF Govern, Map, Measure and Manage. |
| Restrict administrative privileges | Separation of duties for authoring, approving and operating. Essential Eight. |
| Third-party and service provider management | Vendor and model provider assessment supports CPS 230 expectations. |
| Records and event logging | Immutable evidence and run-time logs support audit and assurance. |
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 RTOUnder one day for governance tooling. Run-time gateway targets follow the critical operation it supports.
- Target RPONear zero for the register and approvals through managed storage with backups.
- Scaling and limitsSized by the number of AI systems and release frequency.
| Failure mode | Mitigation |
|---|---|
| Register is incomplete because of shadow AI | Discover through procurement, identity and network logs, and make the approved path easy. |
| Approval becomes a rubber stamp | Specific evidence questions, sampling reviews and reviewer rotation. |
| Tiers drift out of date as systems change | Trigger re-tiering on model, data or use changes, plus an annual review. |
| Policy and enforcement diverge | Express rules as code at the gateway and test them in CI. |
| Governance slows delivery so teams bypass it | Measure time to approval by tier and publish pre-approved patterns. |
Observability and runbooks
- Systems by tier and review status.
- Time to approval by tier and exception counts.
- Control test results and open findings.
- Incidents and near misses by system.
Cost drivers and levers
Tooling licences, reviewer time, evaluation compute and evidence storage.
- Automate low-tier approval.
- Reuse pre-approved patterns.
- Generate evidence from pipelines.
- Retire unused systems.
Implementation and fit
Phased approach
- Build the register and agree risk tiers and an interim approval path.
- Publish the policy, RACI and control library mapped to chosen standards.
- Stand up the gateway, evaluation gates and monitoring for the highest tiers first.
- Add evidence automation, reporting and a continuous improvement cycle.
Anti-patterns to avoid
- A policy document with no enforcement.
- One heavyweight process for every use case.
- A register that nobody updates.
- Approval without evidence.
- Governance owned only by legal or only by IT.
When to use it
- Organisations running several AI systems across teams.
- Agencies and regulated entities needing board-level assurance.
- Suppliers who must answer AI governance questions in tenders.
When not to
- A single low-risk experiment where a short acceptable-use policy is proportionate.
- Organisations with no named executive accountable for AI.
More in ai governance and assurance
LLM guardrails · policy engine
LLM guardrails architecture: input and output guard layers, policy engine, PII redaction, grounding checks and audit
A layered guardrail pattern around an LLM application: authenticate and screen the request, redact personal data, retrieve only what the user may see, call the model, then validate grounding and policy on the way out, with every step logged for audit.
AI agents · safety controls
AI agent safety architecture: tool permissions, sandboxing, approval gates, spend limits and a kill switch
How to let an AI agent act without letting it do harm: a permission broker issues narrow, short-lived tool access, risky code runs in a sandbox, high-impact actions wait for human approval, budgets cap spend and a kill switch stops everything.
ML · model risk · MLOps
ML model risk management and MLOps lifecycle: feature store, validation, registry, drift monitoring and challenger models
A governed lifecycle for scoring and prediction models: reproducible training from a feature store, independent validation including fairness and explainability, a registry with approval status, controlled deployment, drift monitoring and champion and challenger comparison.
Related insights
Discuss this architecture
Tell us your systems, constraints and timeline. We reply within one business day, and the initial conversation is free.