[EAAPL-GOV001] AI Model Register

Category: Governance / Model Lifecycle Management Sub-category: Inventory & Classification Version: 2.1 Maturity: Mature Tags: model-inventory, risk-classification, model-lifecycle, APRA, EU-AI-Act, governance, traceability Regulatory Relevance: APRA CPS230 §24–§28, EU AI Act Article 51, ISO/IEC 42001 §6.1, NIST AI RMF GOVERN 1.1

1. Executive Summary

The AI Model Register is the foundational governance artefact for any enterprise operating AI systems at scale. It provides a single, authoritative inventory of every AI model—including third-party, open-source, and internally developed models—deployed or approved for deployment across the organisation.

Without a comprehensive model register, CIOs and CTOs face material regulatory exposure: APRA CPS230 requires identification of critical operations and their supporting technology; the EU AI Act mandates transparency obligations for high-risk systems; and ISO/IEC 42001 requires documented AI system inventory as a precondition for certification.

Beyond compliance, the register delivers operational value: it enables rapid impact assessment during security incidents, supports informed model retirement decisions, provides lineage for audit purposes, and ensures ownership accountability is unambiguous. Organisations that have suffered high-profile AI failures typically share a common root cause—no one could answer "what models are running in production and who owns them?" This pattern eliminates that risk.

Implementation typically takes 6–10 weeks for initial baseline and delivers immediate regulatory defensibility. The register becomes the anchor for all downstream governance patterns in the EAAPL library.

2. Problem Statement

Business Problem

Enterprises deploy AI models across dozens of business units, often without centralised visibility. Risk teams cannot assess aggregate AI exposure. Compliance teams cannot demonstrate regulatory adherence. When incidents occur, ownership is disputed and remediation is slow.

Technical Problem

AI models are deployed through heterogeneous pipelines (MLOps platforms, vendor SaaS, custom APIs, embedded in applications). No single system captures the full population. Metadata standards are inconsistent. Version drift occurs silently.

Symptoms

• Inability to answer "how many AI models do we have in production?" within 24 hours
• Duplicate model deployments solving the same problem in different business units
• Retired models still receiving inference traffic due to untracked dependencies
• Security patches missed because no ownership record exists
• Regulatory audit findings citing inability to demonstrate AI system inventory
• Post-incident reviews revealing undocumented models contributed to failures
• Third-party AI vendor contracts renewing without performance review

Cost of Inaction

• Regulatory: APRA CPS230 enforcement action; EU AI Act fines up to €30M or 6% global turnover for high-risk system non-compliance
• Operational: Mean time to identify impacted systems during incidents measured in days, not minutes
• Financial: Duplicate model investments; ungoverned cloud AI spend growing 40–70% annually
• Reputational: Public disclosure of ungoverned AI systems materially damages institutional trust

3. Context

When to Apply

• Organisation has ≥5 AI models in production or ≥3 teams independently deploying AI
• Regulatory obligations require AI system transparency (APRA-regulated entities, EU market participants)
• Board or executive committee has requested AI risk visibility
• Prior to implementation of any downstream governance pattern (GOV002–GOV010)
• Following an AI-related incident or near-miss requiring post-incident review
• Before onboarding a new AI vendor or deploying a generative AI capability

When NOT to Apply

• Proof-of-concept or sandboxed environments with no production traffic (register entry still recommended at approval-to-test stage, but lightweight form acceptable)
• Organisations with fewer than 3 AI models and no regulatory obligation (simpler spreadsheet-based inventory may suffice until scale warrants this pattern)

Prerequisites

• Defined AI system taxonomy (what constitutes an "AI model" vs. a rules-based system)
• Nominated data steward responsible for register integrity
• Identity and access management capable of supporting RBAC on register entries
• Integration pathway to at least one deployment platform (MLOps, cloud provider)

Industry Applicability

4. Architecture Overview

The AI Model Register is architected as a federated registry with a centralised authority plane. This design reflects a fundamental tension in enterprise AI governance: business units need autonomy to move quickly, while the enterprise needs authoritative, consistent metadata. A purely centralised model creates bottlenecks; a purely federated model loses consistency. The pattern resolves this by separating the authority plane (schema, validation, access control, regulatory reporting) from the contribution plane (business unit self-registration via APIs and automated discovery).

Core Architectural Principle: Write Many, Read One. Every deployment pipeline writes metadata to the register at promotion time. Every governance, risk, and compliance (GRC) query reads from one authoritative source. This eliminates the "which spreadsheet is current?" problem that plagues manually maintained inventories.

Schema Design Philosophy. The register schema is deliberately stratified into three tiers: (1) Mandatory fields required at initial registration—model ID, owner, version, purpose, data classification, risk tier; (2) Deployment fields populated at production approval—approval reference, deployment environment, endpoint, dependencies; (3) Operational fields updated continuously—last inference timestamp, performance metrics, incident history, review dates. This stratification allows early-stage registration without blocking the pipeline while ensuring operational records are complete before production traffic flows.

Risk Classification as a First-Class Attribute. Every model entry carries a risk tier (Critical / High / Medium / Low) derived from the AI Risk Assessment pattern (GOV002). The register stores both the tier assignment and the assessment artefact reference, creating a traceable chain from classification decision to governance action. Risk tier drives downstream controls: review frequency, human oversight requirements, approval authority level, and monitoring intensity.

Third-Party Model Governance. Commercial AI APIs (OpenAI, Anthropic, Google, AWS Bedrock) and open-source models (Hugging Face, Ollama) must be registered with equal rigour to internally developed models. The register schema includes vendor contract reference, data processing agreement (DPA) status, geographic data residency, and vendor security assessment date. APRA CPS230 §28 explicitly requires third-party arrangement governance—this field set satisfies that obligation.

Immutability and Versioning. Register entries are append-only with explicit version increments. Retiring a model does not delete its record; it transitions to RETIRED status with a retirement date, successor model reference, and decommission evidence link. This immutability is architecturally enforced at the storage layer and is required to satisfy audit demands for historical state reconstruction.

Automated Discovery Integration. A passive discovery agent continuously scans deployment infrastructure (Kubernetes namespaces, API gateways, cloud AI services) for AI model signatures not present in the register. Unregistered models trigger a governance alert: either the model is legitimately deployed and needs retroactive registration, or it is a shadow AI deployment requiring immediate escalation. This closes the "unknown unknowns" gap that manual self-registration leaves open.

Access Control Architecture. The register implements role-based access with four tiers: (1) Public—model name, purpose, owner contact, risk tier visible to all staff; (2) Operational—full technical metadata visible to AI/ML and security teams; (3) Compliance—full record including assessment history visible to risk and compliance; (4) Admin—schema and configuration visible only to register administrators. This tiering satisfies the principle of least privilege while enabling broad organisational transparency about AI system existence.

5. Architecture Diagram

6. Components

7. Data Flow

Primary Registration Flow

Error Flow

8. Security Considerations

Authentication & Authorisation

• All Register API calls require OAuth 2.0 / OIDC bearer token from enterprise IdP (Azure AD, Okta)
• RBAC enforced at API layer and database row level (model owner can edit own entries; risk tier changes require Compliance role)
• Service accounts for automated pipeline registration use short-lived tokens (≤1 hour TTL) with least-privilege scope
• MFA required for all human administrative actions

Secrets Management

• API keys and database credentials stored in enterprise secrets manager (HashiCorp Vault, AWS Secrets Manager)
• No credentials in register entry payloads; vendor API key references stored as Vault path references, not values
• Secrets rotation schedule: 90 days maximum for service accounts

Data Classification

• Register entries classified at the highest sensitivity of the model they describe
• Fields containing model architecture details or training data references classified as CONFIDENTIAL
• Public-facing fields (name, purpose, owner contact) classified as INTERNAL

Encryption

• Data at rest: AES-256 encryption on PostgreSQL tablespace and S3 audit bucket
• Data in transit: TLS 1.3 minimum for all API calls; mTLS for internal service-to-service communication
• Audit log WORM bucket: S3 Object Lock with Compliance mode, 7-year retention (aligned to APRA record-keeping obligations)

Auditability

• Every read of sensitive register fields logged (who accessed which model record, when)
• All mutations logged with actor identity, timestamp, IP, changed fields, before/after values
• Quarterly access review of register admin roles

OWASP LLM Top 10 Mapping

9. Governance Considerations

Responsible AI Alignment

The register operationalises accountability by making AI system ownership unambiguous and publicly discoverable within the enterprise. Every model has a named human owner (not a team or system).

Model Risk

The register is itself a control in the model risk framework. Its completeness rate (% models with all mandatory fields) is a Key Risk Indicator (KRI) reported to the AI Risk Committee quarterly.

Human Approval Requirements

• Risk tier elevation (e.g., Low → High) requires Compliance Officer sign-off
• CRITICAL tier models require Chief Risk Officer acknowledgement in register
• Retirement of a model supporting a critical business operation requires change advisory board (CAB) approval

Policy Integration

The AI Use Policy, Data Classification Policy, and Third-Party Risk Policy are all referenced by register field validations. Policy updates automatically trigger re-validation notifications to affected model owners.

Traceability

Every downstream governance action (risk assessment, approval, incident, audit finding) references the MRID. This creates a complete, traversable lineage from model registration through retirement.

Governance Artefacts

10. Operational Considerations

Monitoring

SLOs

Logging

• Structured JSON logs for all API calls (requestId, modelId, actor, action, duration, outcome)
• Log retention: 90 days hot (Elasticsearch), 7 years cold (S3 Glacier) aligned to APRA record-keeping
• Log shipping to enterprise SIEM within 60 seconds of event

Incident Response

• Register unavailability: fallback read from last-known-good snapshot; no writes permitted during degraded mode
• Data integrity breach: invoke immutable audit log to reconstruct state; notify CISO within 1 hour
• Shadow AI discovery spike: treat as potential security incident; invoke GOV008

Disaster Recovery

Capacity Planning

• Register expected growth: 50–200 new model entries per quarter for a large enterprise
• Storage at 5-year horizon (100KB average record × 2,000 models × 50 versions): ~10GB structured data; negligible
• Search index: scale Elasticsearch to 3-node minimum; add shard at 500K+ documents
• Discovery agent: deploy one agent per 1,000 Kubernetes pods; 10-minute scan cycle

11. Cost Considerations

Cost Drivers

Scaling Risks

• Discovery agent may generate high event volumes in large Kubernetes estates (>10K pods); event queue sizing critical
• Elasticsearch index rebuild time increases with record volume; schedule during low-traffic windows

Optimisations

• Use PostgreSQL with pgvector for semantic search to eliminate separate Elasticsearch cluster at small scale
• S3 Intelligent Tiering for audit log to reduce cold storage costs after 90 days
• Automate mandatory field completion via MLOps pipeline integration to reduce human governance effort

Indicative Cost Range

Infrastructure costs assume AWS ap-southeast-2; human costs at AUD $160K all-in per governance FTE.

12. Trade-Off Analysis

Option Comparison

Architectural Tensions

13. Failure Modes

Cascading Failure Scenarios

• Scenario 1: Register API outage during a major ML model release. Consequence: deployment proceeds without registration (allowed by exception); AI model operates without governance controls until registration completed post-deployment. Mitigation: exception process must mandate 24-hour post-deployment registration SLA.
• Scenario 2: Incorrect risk tier (Low assigned to High-risk credit model) cascades through GOV002/GOV003, resulting in insufficient human oversight controls. Detected only during regulatory audit. Mitigation: mandatory cross-functional risk tier peer review for any model touching credit, fraud, or customer eligibility decisions.

14. Regulatory Considerations

APRA CPS230 (Operational Resilience)

• §24–§25: Requires identification of critical operations and the resources supporting them. The register's "supports critical operation" flag and critical operation reference field directly satisfy this obligation.
• §28: Third-party arrangement governance requires inventory of material service providers. Register's vendor section with DPA status and security assessment date satisfies this for AI vendors.
• Evidence artefact: Quarterly AI Model Register Report provided to Board Risk Committee.

APRA CPS234 (Information Security)

• §15: Requires information asset classification. Register enforces data classification on all model records.
• §36: Penetration testing evidence for AI systems linked to register entries.
• Evidence artefact: Register feeds APRA CPS234 information asset register; security assessment dates tracked.

EU AI Act

• Article 51: Requires registration of high-risk AI systems in EU database before placing on market. Register export function generates EU-format registration payload. Risk tier = High or Critical automatically queues for EU database registration.
• Article 13: Transparency obligations for high-risk AI. Register's purpose, capability, and limitation fields map to Article 13 transparency documentation requirements.
• Annex VIII: Technical documentation requirements. Register links to technical documentation artefact.

Privacy Act 1988 (Australia)

• APP 1.3: Transparency about automated decision-making. Register's public-facing fields support organisational transparency obligations.
• APP 11: Security of personal information. Register tracks which models process personal information, enabling targeted security controls.

ISO/IEC 42001:2023

• §6.1.2: AI risk identification requires documented AI system inventory. The register is the primary evidence artefact.
• §9.1: Performance evaluation requires monitoring of AI objectives; register KRIs feed this requirement.

NIST AI RMF

• GOVERN 1.1: Organisational policies for AI risk management require a complete model inventory as foundation.
• MAP 1.1: AI risk identification mapped to AI system context. Register provides the system context for MAP function activities.

15. Reference Implementations

AWS

Azure

GCP

On-Premises

16. Related Patterns

17. Maturity Assessment

Overall Maturity: Mature (Level 4)

Progression to Level 5: Implement real-time federated query across multi-cloud registers; integrate with supply chain ML bill-of-materials (ML-SBOM); automate EU AI Act registration submission.

18. Revision History