[EAAPL-GOV003] AI Approval Workflow

Category: Governance / Deployment Control Sub-category: Change Management & Approval Gates Version: 1.3 Maturity: Proven Tags: approval-workflow, deployment-gates, separation-of-duties, change-management, APRA, EU-AI-Act Regulatory Relevance: APRA CPS230 §23–§26, EU AI Act Article 14, ISO/IEC 42001 §8.4, NIST AI RMF MANAGE 1.1

1. Executive Summary

The AI Approval Workflow establishes a multi-stage, evidence-gated approval process that every AI system must traverse before production deployment. It implements separation of duties as an architectural principle—technical, security, ethics, regulatory, and executive reviewers operate as independent gates, each with defined authority and accountability.

This pattern solves a persistent enterprise problem: AI systems deploy through standard software change management processes designed for deterministic code, which fundamentally misses AI-specific risks including fairness, explainability, adversarial vulnerability, and regulatory classification. By inserting AI-specific review stages with defined entry and exit criteria, the workflow ensures that deployment decisions are informed, documented, and defensible.

For CIOs and CTOs, this pattern delivers three strategic outcomes: regulatory defensibility (documented approval evidence for every deployed model), risk reduction (no model enters production without expert sign-off on applicable risk dimensions), and accountability (named approvers with defined authority create clear responsibility chains). Implementation integrates with existing ITSM and change management tooling, minimising adoption friction while adding material governance value.

2. Problem Statement

Business Problem

AI systems are promoted to production through standard software release processes (JIRA tickets, change advisory boards) that do not assess AI-specific risk dimensions. Approvers lack the expertise and structured information to make informed decisions. Approval becomes a rubber stamp rather than a genuine risk control.

Technical Problem

Multi-stage approval requires coordination across technical, security, compliance, ethics, and executive reviewers. Without a structured workflow, reviews happen ad-hoc, evidence is unstructured, decisions are verbal, and there is no audit trail connecting deployment to approval.

Symptoms

• AI models deployed without documented fairness or ethics review
• Security reviews of AI systems using generic application security checklists
• Legal/compliance review occurring after deployment when issues are discovered
• No traceable connection between deployed model version and approval evidence
• Different AI projects following different approval processes based on team culture
• Inability to answer regulators' question: "who approved this AI system for deployment and based on what evidence?"

Cost of Inaction

• Regulatory: APRA examination finding; EU AI Act Article 14 (human oversight) non-compliance
• Legal: Deployment of non-compliant AI creating retrospective liability without approval documentation
• Operational: Fast-moving development teams deploy without governance, creating ungoverned AI estate
• Reputational: High-profile AI failure with no documented governance process amplifies regulatory and media response

3. Context

When to Apply

• All AI systems being promoted to production (regardless of risk tier — tier determines approval depth, not whether approval applies)
• Existing deployed models undergoing material changes (new training data, new use case, architectural change)
• Third-party AI integrations being enabled for first time
• Models being promoted from staging to production after staging validation

When NOT to Apply

• Within-experiment model retraining (automated retraining of existing approved models within previously approved parameter bounds)
• Internal experimentation environments with no production data or customer impact
• Non-AI software changes (standard ITSM change process applies)

Prerequisites

• Model registered in AI Model Register (GOV001) with MRID
• Risk assessment completed (GOV002) with documented risk tier
• Technical documentation package complete per risk tier requirements
• Deployment environment provisioned with monitoring controls configured

Industry Applicability

4. Architecture Overview

The AI Approval Workflow is architected as a sequential gate process with parallel review capability within each gate. The pattern makes three foundational architectural decisions that distinguish it from generic change management workflows.

First principle: Risk-tier-driven depth, not fixed stages. A Low-risk internal analytics model does not require the same approval rigour as a Critical-tier credit decisioning model. The workflow uses risk tier (from GOV002) to determine which stages are mandatory, which are advisory, and what evidence is required at each stage. A four-tier depth model is defined: Express (Low), Standard (Medium), Comprehensive (High), and Full Board (Critical). This prevents the framework becoming a bottleneck that business units circumvent.

Second principle: Evidence gates, not opinion gates. Each approval stage has defined entry criteria (what evidence must exist before the stage opens) and exit criteria (what the approver must review and attest). Approvers cannot mark a stage complete without linking to specific assessment artefacts. This transforms approval from "did the committee meet?" to "did the committee review specific evidence and make an informed decision?" The distinction is material under regulatory examination.

Third principle: Separation of duties by role type. The five review stages—Technical, Security, Ethics, Regulatory, and Executive—must be performed by different individuals from different organisational functions. A single person cannot approve their own technical and ethics review. This separation is enforced at the workflow layer: the system will not accept approvals from the same individual for more than one stage on the same model. This satisfies APRA CPS230 §26 governance requirements for independence in risk oversight.

Stage Architecture. The five stages are:

Stage 1: Technical Review validates that the model meets technical quality standards: performance benchmarks met, model card complete, integration tests passing, fallback behaviour verified, monitoring hooks installed. Technical review can be performed by the AI/ML engineering team but not by the model's own developers (peer review at minimum).

Stage 2: Security Review validates AI-specific security controls: adversarial robustness testing completed (per GOV002 security module), input validation controls in place, model endpoint access controls verified, supply chain provenance confirmed, and penetration test scheduled or completed. Security review is performed by the enterprise security team, not the AI team.

Stage 3: Ethics Review assesses fairness, explainability, and responsible AI alignment. This stage is mandatory for all customer-facing models and all models making consequential decisions about individuals. Ethics reviewers must be independent of the development team and must include at least one non-technical reviewer. For Critical-tier models, the AI Ethics Review Board (GOV009) performs this stage.

Stage 4: Regulatory/Compliance Review validates that the model is compliant with all applicable regulatory obligations: data processing agreements signed (third-party models), privacy impact assessment completed, EU AI Act registration submitted (if applicable), prohibited use case confirmation, and geographic restriction compliance. This stage is performed by Legal/Compliance, not the AI or business team.

Stage 5: Executive Sign-off provides accountability at the appropriate authority level based on risk tier. Low-tier models may not require executive sign-off; Critical-tier models require CRO or Board Risk Committee acknowledgement. This stage creates the governance anchor — a named executive accountable for the deployment decision.

Parallel Review Optimisation. Stages 2, 3, and 4 (Security, Ethics, Regulatory) can execute in parallel once Stage 1 (Technical) is complete. This parallelisation reduces the calendar time from sequential 5-stage to effectively 3-stage (Technical → parallel Security+Ethics+Regulatory → Executive). For a well-prepared Medium-tier model, the full workflow completes in 5–7 business days.

Conditional Re-review. Material changes to an approved model trigger a partial re-review. The system categorises change types and maps them to required re-review stages: a model architecture change triggers Technical + Security; a new use case triggers Ethics + Regulatory; a new training dataset triggers Technical + Ethics. This prevents full re-review for minor changes while ensuring material changes receive appropriate scrutiny.

5. Architecture Diagram

6. Components

7. Data Flow

Primary Approval Flow (Comprehensive Track — High Risk)

Error Flow

8. Security Considerations

Separation of Duties (Critical Control)

• System enforces: no individual can approve more than one stage for a given model deployment
• Workflow engine maintains approver identity per stage; cross-check performed before accepting approval
• Model owners cannot approve any stage on their own model (explicit exclusion list)

Deployment Token Security

• JWT deployment tokens carry: MRID, model version hash, approved environment, issuer, expiry (24 hours)
• MLOps pipeline validates token signature before permitting deployment
• Tokens invalidated immediately if model version changes post-issuance

Audit Log Integrity

• All approval decisions written to WORM-compliant immutable log
• Approval records include: approver identity, timestamp, decision, rationale text, evidence artefact hashes
• No deletion permitted; corrections via superseding record only

OWASP LLM Top 10 Mapping

9. Governance Considerations

Responsible AI

The Ethics Review stage (Stage 3) is the primary responsible AI gate. It requires sign-off from a designated AI Ethics Officer or, for Critical-tier, the full AI Ethics Review Board (GOV009). Ethics review covers: fairness assessment outcomes, explainability adequacy, human override mechanisms, and vulnerable population impact.

Model Risk

The approval workflow is a key control in the enterprise model risk framework. Approved models receive a Model Risk Rating that references the approval record. Model risk committee reviews approval outcomes quarterly.

Traceability

Every deployed model has a traceable approval chain: MRID → Assessment ID (GOV002) → Approval Request ID → Stage approver identities → Deployment token hash → Deployed model version. This chain can be reconstructed from audit logs for any deployed model at any point in time.

Governance Artefacts

10. Operational Considerations

SLOs

Monitoring

Disaster Recovery

11. Cost Considerations

Cost Drivers

Indicative Cost Range

12. Trade-Off Analysis

Option Comparison

Architectural Tensions

13. Failure Modes

14. Regulatory Considerations

APRA CPS230

• §23: Risk management framework requires documented approval process for changes to critical operations. This workflow provides the required documentation.
• §26: Governance arrangements require independence in risk oversight. SoD enforcement directly satisfies this.

EU AI Act

• Article 14: Human oversight requirements for high-risk AI. Stage 3 (Ethics) and Stage 5 (Executive) provide the human oversight attestation required before deployment.
• Article 16(f): Providers of high-risk AI must draw up technical documentation. Stage 1 (Technical) gate enforces documentation completeness.
• Article 43: Conformity assessment for high-risk AI. Approval record serves as conformity assessment documentation for Annex III use cases.

NIST AI RMF

• MANAGE 1.1: AI risk responses are decided upon and implemented. Approval workflow is the primary implementation of MANAGE function.
• MANAGE 2.2: Mechanisms to respond to AI risk prioritised. Stage-based escalation implements this.

ISO/IEC 42001

• §8.4: Operational planning and control requires documented procedures for AI system deployment. This workflow pattern satisfies §8.4.

15. Reference Implementations

AWS

Azure

On-Premises / Enterprise ITSM

16. Related Patterns

17. Maturity Assessment

Overall Maturity: Proven (Level 3)

18. Revision History