AI Architecture Domain Module

Making AI capability visible, governed, and enterprise-ready.

AI is no longer an experiment. It's becoming infrastructure. Organisations are deploying language models, building AI agents, automating workflows, and making decisions informed by machine learning — often faster than their architecture and governance practices can keep up.

The result is predictable: shadow AI everywhere. Teams spinning up AI tools without anyone knowing. Agents with access to production systems but no identity governance. Models making recommendations with no lineage on training data. Prompts stored in someone's desktop folder. Cost blowouts from unmanaged API consumption. And eventually, an incident that nobody saw coming because nobody had visibility.

Most organisations sit in one of two camps. Some treat AI like any other technology — fitting it into existing governance that wasn't designed for it. Others treat it as completely special — building bespoke AI governance that doesn't connect to anything else. Neither works. AI needs governance that recognises what's genuinely different about it while connecting to the same architecture fabric that governs everything else.

This module provides the practical foundation for AI architecture that spans the full stack — from the platforms that host AI capability, through the models and agents that deliver it, to the identity and security frameworks that keep it contained and accountable. It connects AI decisions to the Governance Core so they're visible, traceable, and risk-managed alongside every other architectural concern.

What This Module Provides

How It Plugs Into the Governance Core

AI Architecture connects to every component of the Governance Core — and introduces some AI-specific considerations that other domains don't have.

Guardrails Framework — AI guardrails define the boundaries for AI adoption and deployment. "All AI agents must have a registered identity in the identity provider." "Generative AI outputs that inform decisions affecting individuals require human review." "AI models accessing personal information must complete privacy impact assessment before deployment." Unlike some guardrail categories, AI guardrails need to evolve rapidly as the technology and regulatory landscape shifts — build in quarterly review cadence at minimum.

Decision Records — AI decisions carry unique weight because they're often hard to reverse once embedded in workflows. "We chose Azure OpenAI over direct OpenAI API because data residency requirements mandate Australian processing." "We accepted the risk of using an open-source model for internal summarisation because the data classification is UNOFFICIAL and the model runs on-premises." AI decision records should capture model selection rationale, data handling implications, and the risk classification that drove the governance level.

Architecture Passport — Each AI system gets a passport that includes its AI-specific attributes: what models it uses, what data it accesses, what decisions it informs, what identity it operates under, and what human oversight mechanisms exist. For AI agents, the passport is particularly important — an agent that can take actions needs a clear record of its capabilities, boundaries, and accountability chain.

Tiered Oversight — AI risk factors significantly into oversight tier. Systems using AI for autonomous decision-making, accessing sensitive data, or operating in customer-facing contexts warrant higher scrutiny. The tier assessment explicitly includes AI-specific risk factors: autonomy level, data sensitivity, decision impact, and regulatory exposure.

Technical Debt Register — AI debt is a distinct category. Prompt debt (prompts that work but aren't version-controlled or tested). Model debt (models that haven't been retrained against current data). Agent debt (agents with permissions broader than they need). Integration debt (AI capabilities wired in without proper abstraction). Energy debt (oversized models consuming disproportionate compute and energy for tasks that efficient models could handle). AI debt accumulates faster than most technical debt because the technology evolves so rapidly.

Delivery Integration — AI capabilities need to be embedded in delivery cadences. Model deployments need the same rigour as application deployments — staging, testing, rollback capability. Agent changes need the same visibility as infrastructure changes.

Architecture Registry — AI components populate the registry: models, agents, platforms, prompts, and their relationships. This makes the AI landscape visible at portfolio level — how many models are in production, which agents exist, what platforms they run on, and who's accountable.

A Note on Implementation Maturity

AI architecture is a fast-moving field. Some patterns in this module are implementable today with existing tools and platforms. Others require custom engineering or tooling that doesn't exist off-the-shelf yet. A framework that only describes aspirational architecture is useless for implementers.

This module is explicit about the difference. Where a pattern is implementable now, it says so and names the tools. Where current tooling falls short, it describes what you can build today and what requires custom work. Look for "Implementation reality" callouts throughout the module — these ground the architecture in what's actually achievable.

The governance principles are durable. The specific implementations will evolve as platforms mature. Build what you can now, govern what you build, and revisit as tooling improves.

Core Artefacts

AI Platform Reference Architecture

An AI Platform Reference Architecture provides a consistent model for how AI capability is structured and delivered across the organisation. Without one, every team builds its own AI stack, duplicates infrastructure, and creates integration nightmares.

The reference architecture should be simple enough to guide decisions but comprehensive enough to cover the key layers of enterprise AI capability.

Governance Layer sits above everything. AI policy, ethical principles, risk appetite, regulatory alignment, cost controls, and sustainability requirements are defined here. This layer doesn't build AI — it defines the boundaries and requirements for everyone who does. Sustainability belongs here rather than as a separate infrastructure concern — model selection, inference efficiency, and energy consumption are governance decisions that flow down through the architecture.

Consumption Layer is where users and systems interact with AI capability. Applications embedding AI features, portals providing AI-assisted workflows, APIs exposing AI services, and agent interfaces where AI operates with varying degrees of autonomy. This layer should abstract the complexity below — consumers shouldn't need to know which model or infrastructure powers their capability.

Orchestration Layer is where AI workflows are composed and managed. Agent frameworks coordinate multi-step AI operations. Workflow engines manage complex AI-assisted processes. Prompt management ensures consistency and version control. Routing directs requests to appropriate models based on capability, cost, and latency requirements.

Model Layer is where the AI models live. Foundation models from vendors (GPT, Claude, Gemini, Llama), fine-tuned models adapted for specific use cases, custom models trained on organisational data, and embedding models that power semantic search and RAG. Model selection, versioning, and lifecycle management happen here. A key architectural decision is matching model class to use case: frontier models (large, general-purpose, highest capability) for complex reasoning and generation, versus efficient models (smaller, specialised, lower compute/cost) for classification, extraction, and high-volume tasks. Not every use case needs a frontier model — defaulting to the largest available model wastes compute, increases cost, and creates unnecessary energy consumption.

Knowledge Layer provides the context that makes AI useful for your organisation. RAG (Retrieval Augmented Generation) pipelines connect models to your data. Vector stores enable semantic search. Knowledge graphs capture relationships. This layer is often the differentiator between generic AI and AI that actually knows your business.

Data Layer provides the fuel. Training data for custom models. Evaluation datasets for testing. Feature stores for ML workloads. Ground truth data for measuring accuracy and drift. This connects directly to your Data Architecture — data quality here determines AI quality everywhere above.

Identity Layer is where AI meets identity governance. Agent identities, authentication mechanisms, authorisation boundaries, audit trails, and trust relationships. This is a new frontier for most organisations — treating AI agents as first-class identity principals rather than hiding them behind service accounts.

Infrastructure Layer is the foundation. Compute resources (GPU for training and inference, CPU for lighter workloads), networking, storage, monitoring, and security controls. This connects to your Technology Architecture for platform decisions and to Security Architecture for baseline protections.

Provenance and Industry Alignment

This reference architecture is a synthesis, not a reproduction of a single established standard. The AI architecture space hasn't yet converged on a single vendor-neutral reference model the way enterprise architecture has with TOGAF or security architecture has with SABSA. What exists is a collection of vendor-specific implementations, emerging analyst frameworks, and practitioner patterns that are converging on similar concepts.

The layers in this model draw from and align with several established sources:

What's genuinely novel here: The Identity Layer as a first-class architectural layer and the explicit connection of all layers to XAF's Governance Core. Most vendor architectures focus on the technical stack and treat governance as a separate concern. This model integrates governance structurally — which is the whole point of Connected Architecture.

What's synthesised from industry convergence: The remaining seven layers reflect where the industry is heading, informed by Microsoft's Azure AI architecture patterns, Google Cloud's enterprise GenAI/ML blueprints, Salesforce's Agentic Enterprise architecture, the NIST AI RMF, and Gartner's AI technology stack research. The specific composition, naming, and governance integration are XAF's contribution.

For organisations wanting to go deeper on specific layers, the "Extending to Deeper Frameworks" section at the end of this module provides pointers to the vendor and framework-specific resources that informed this model.

Platform Strategy Patterns

Not every organisation needs the same AI platform approach. The right pattern depends on scale, capability maturity, and organisational structure.

Most organisations should start with Managed Service First and evolve toward Hybrid as their capability and demand grow. Building a centralised AI platform before you have proven use cases is expensive infrastructure looking for a problem.

Edge and distributed inference is an emerging consideration across all patterns. Some use cases — low-latency field operations, disconnected environments, data sovereignty constraints — require inference to run at the edge rather than in centralised cloud. This is primarily a Technology Architecture decision (where does compute live?), but AI Architecture needs to account for it in model selection (efficient models that can run on constrained hardware), governance (how do you monitor and audit edge-deployed models?), and lifecycle management (how do you update models running on distributed infrastructure?).

AI Capability Model

Before investing in AI, you need to understand what AI capabilities your organisation has, needs, and how mature they are. The capability model provides this visibility.

AI capabilities aren't just "we use ChatGPT." They span a spectrum:

Map your current capabilities, assess maturity, identify gaps against strategic priorities, and use this to drive investment decisions. This connects directly to Business Architecture — AI capabilities should align to business capabilities and value streams.

AI Agent Architecture

AI agents are fundamentally different from traditional software. They don't just respond to requests — they reason, plan, use tools, and take actions. This creates architectural challenges that conventional application patterns weren't designed for.

Why Agents Are Architecturally Different

Traditional software is deterministic — the same input produces the same output. Agents are probabilistic — they interpret, decide, and act with inherent variability. Traditional integrations have fixed interfaces. Agents discover and use tools dynamically. Traditional workflows follow predefined paths. Agents may choose their own path to achieve a goal.

This isn't a reason to avoid agents. It's a reason to architect them deliberately.

Agent Design Patterns

Single Agent, Defined Tools — One agent with a specific set of tools it can use. The simplest pattern. Good for focused use cases like "answer questions about our policies using these documents" or "triage support tickets and route them."

Multi-Agent Orchestration — Multiple specialised agents coordinated by an orchestrator. Good for complex workflows where different expertise is needed at different stages. The orchestrator routes tasks, manages state, and ensures the overall workflow progresses.

Human-in-the-Loop Agent — Agent operates autonomously within defined boundaries but escalates to humans for decisions above its authority level. This is the most common production pattern for consequential workflows.

Supervisory Agent — A meta-agent that monitors other agents' outputs for quality, safety, and compliance before they reach the user or take effect. Useful for high-risk deployments where a second AI layer provides additional checking.

Agent Containment Principles

Agents need containment — deliberate boundaries that limit what they can do, even when their reasoning suggests they should do more. This isn't about distrusting AI; it's about managing risk proportionate to impact.

• Principle of Least Privilege — An agent should have access only to the tools, data, and actions it needs for its defined purpose. A support triage agent doesn't need access to the HR system. A document summarisation agent doesn't need write access to anything.
• Blast Radius Limitation — Design so that agent failure or misbehaviour has bounded impact. If an agent processes one transaction incorrectly, it shouldn't be able to process ten thousand more before anyone notices. Rate limits, transaction caps, and scope boundaries all reduce blast radius.
• Reversibility Preference — Where possible, agents should perform reversible actions. Draft rather than send. Stage rather than deploy. Recommend rather than execute. When irreversible actions are required, human approval should be in the path.
• Observable Behaviour — Every agent action should be logged, traceable, and auditable. If you can't explain what an agent did and why, you can't govern it. Observability isn't optional for agents — it's foundational.

AI Identity & Access Framework

This is new territory for most organisations. Traditional identity and access management was designed for humans and, later, for applications via service accounts. AI agents are neither — they're autonomous actors that operate on behalf of humans, make contextual decisions, and may need different permissions at different stages of a workflow.

Treating agents as "just another service account" misses the point. Service accounts have static, predictable behaviour. Agents have dynamic, context-dependent behaviour. Service accounts don't reason about what tools to use. Agents do. This requires a new identity model.

Agent Identity Principles

• Agents are first-class identity principals. Every agent has a distinct, registered identity in your identity provider. Not a shared service account. Not a user account pretending to be an agent. A distinct identity type that's recognisable as an agent in logs, audit trails, and access decisions.
• Agent identity is linked to accountability. Every agent identity traces back to a human owner — someone accountable for the agent's behaviour, configuration, and access. This isn't about blame; it's about knowing who to talk to when something needs to change.
• Agent identity carries context. An agent's identity should convey what it is, what it's authorised to do, and what oversight applies. This enables downstream systems to make informed access decisions. A system receiving a request from agt-support-triage-tier2 can apply different rules than a request from agt-data-analysis-readonly.

Agent Identity Model

Agent Authentication

Agents need to authenticate to systems they interact with. The mechanism depends on the context:

Critical rule: Agents should never authenticate using human credentials. Even if an agent is acting on behalf of a user, the authentication mechanism should make it clear that an agent — not a human — is performing the action. This is non-negotiable for audit integrity.

Agent Authorisation

Agent authorisation needs to go beyond simple role-based access control. Agents need contextual authorisation that considers what they're trying to do, why, and what the impact might be.

Layered Authorisation Model:

The goal is authorisation across five dimensions. Today, these are implemented across different systems — there is no single "agent authorisation platform" that handles all five. Knowing which system enforces each layer is critical for implementation.

The first three layers are standard infrastructure. Scope and Escalation require custom implementation per use case. Start with Identity, Action, and Volume — they give you meaningful containment using existing tooling. Add Scope and Escalation for higher-risk agents where the investment is justified.

Agent-to-Agent Trust

When agents interact with each other — particularly in multi-agent orchestration — trust relationships need to be explicit and governed.

Trust Principles:

An orchestrator agent can delegate tasks to worker agents, but cannot delegate more permissions than it holds itself. Trust chains are logged — if Agent A asks Agent B to do something, and Agent B asks Agent C, the full chain is captured. No transitive trust by default — Agent A trusting Agent B doesn't mean Agent A trusts Agent C, even if Agent B trusts Agent C.

How multi-agent frameworks actually work today:

Most current multi-agent frameworks (LangGraph, CrewAI, AutoGen) run agents as functions within the same process. There is no network boundary between agents, which means there's no inter-agent authentication in the traditional sense — agents share the same process memory and execution context. In this model, trust is enforced through:

• Orchestrator code logic — the orchestrator determines which agents can be called, in what order, with what inputs. This is code-level trust, not protocol-level trust.
• Per-agent tool scoping — each agent function is configured with its own set of permitted tools and API credentials. The research agent's function gets read-only credentials; the action agent's function gets write credentials. The framework doesn't enforce this — your code does.
• Structured output passing — agents receive only the outputs from previous agents that the orchestrator explicitly passes. No agent can access another agent's full context unless the orchestrator provides it.
• Audit logging at the orchestrator — every agent invocation, input, output, and tool call is logged by the orchestrator. This gives you the trust chain record even without protocol-level authentication.

When agents run as separate services (microservices architecture, distributed agent mesh), standard service-to-service authentication applies — OAuth 2.0 client credentials, mTLS, or managed identities. Each agent service has its own identity and credentials. This looks like:

This is standard service-to-service security — nothing agent-specific about the authentication mechanism. What makes it agent trust rather than just service trust is the governance layer: the Architecture Registry records which agents can communicate with which, the trust chain audit log captures the full delegation path, and the orchestrator enforces delegation boundaries in code.

Audit and Observability

Every agent action must be auditable. This isn't just good practice — for government and regulated industries, it's a requirement.

What to log for every agent action:

The agent identity performing the action. The human identity the agent is acting on behalf of (if applicable). What action was requested. What data was accessed or modified. What tools were used. What the outcome was. The timestamp and duration. The reasoning chain (where available and practical).

Audit trail requirements by autonomy level:

Enterprise RAG Architecture

Retrieval Augmented Generation (RAG) is the pattern that bridges the gap between generic AI models and AI that actually knows your business. Instead of fine-tuning models on organisational data (expensive, slow, creates data handling complications), RAG retrieves relevant information at query time and provides it as context to the model. The model generates responses grounded in your data without that data ever being part of the model's training.

RAG is the primary implementation pattern for the Knowledge Layer in the reference architecture. Getting it right is the difference between an AI that gives plausible-sounding generic answers and one that gives accurate, sourced answers from your actual documents, policies, and data.

RAG Architecture Patterns

Not all RAG implementations are equal. The pattern should match the complexity and criticality of the use case.

• Naive RAG — The simplest implementation: chunk documents, embed them in a vector store, retrieve the most similar chunks for a query, pass them to the model with the question. Good for prototyping and low-stakes internal tooling. Breaks down quickly in enterprise settings — struggles with multi-hop questions, loses context from aggressive chunking, and retrieves irrelevant information when questions are ambiguous or require synthesis across documents.
• Graph-Augmented RAG — For domains with complex relationships (organisational structures, regulatory dependencies, supply chains), knowledge graphs supplement vector retrieval. The graph captures relationships that embedding similarity alone can't represent. "Which policy applies to this department for this data classification?" is a graph traversal problem, not a similarity search.
• Agentic RAG — The most advanced pattern. An AI agent decides dynamically what to retrieve, from which sources, in what order. Multiple specialised retrieval agents handle different source types (documents, databases, APIs), and an orchestrator agent synthesises results. Best suited for complex research tasks, multi-source analysis, and executive decision support. Also the most complex to govern — every retrieval step needs observability.

Enterprise RAG Design Decisions

These are the decisions that separate proof-of-concept RAG from production RAG:

• Chunking strategy matters more than model selection. How you split documents determines retrieval quality. Respect document structure — use semantic boundaries (sections, paragraphs) rather than fixed token counts. Maintain metadata (source document, section heading, date, classification) with every chunk. Overlapping chunks reduce the chance of splitting critical context across boundaries.
• Embedding model selection drives accuracy. The embedding model determines how well queries match to relevant content. Evaluate embedding models against your actual data and query patterns, not generic benchmarks. Domain-specific evaluation datasets are worth the investment. Consider multilingual requirements if applicable.
• Source attribution is non-negotiable. Every RAG response must trace back to the source documents that informed it. This isn't just good practice — for government and regulated contexts, you need to prove where the answer came from. Build citation and source reference into the prompt template from day one.
• Data freshness requires pipeline design. RAG is only as current as your indexed content. Design ingestion pipelines with clear freshness SLAs: how quickly do new or updated documents appear in the knowledge base? For policy documents this might be daily; for real-time data it might be minutes. Stale knowledge bases produce confidently wrong answers.
• Access control must carry through to retrieval. If a user doesn't have access to a document, RAG shouldn't retrieve it for them. This is the correct principle — but implementation ranges from straightforward to genuinely hard depending on your environment.
  
  The simplest approach: index content at a single access level and only allow users at that level or above to query the pipeline. This works for many internal use cases — a policy Q&A system where all indexed policies are available to all staff.
  
  The next level: document-level security filtering at query time. Azure AI Search, Weaviate, and some other vector stores support security trimming — each document chunk is tagged with access metadata, and retrieval filters results based on the requesting user's permissions before passing context to the model. This works but requires every document to carry consistent access metadata through the ingestion pipeline, and the vector store must support filtered search without significant performance degradation.
  
  The hard version: per-user security trimming across multiple document sources with different access models — SharePoint permissions, database row-level security, file share ACLs, SaaS application roles — all unified into a consistent retrieval-time filter. This is an active engineering challenge, not a solved problem. Most production RAG implementations today don't achieve true cross-source access control carry-through.
  
  Start with single-classification indexes. Add document-level filtering when you need mixed-classification content in the same knowledge base. Treat cross-source unified access control as a future architecture target, and compensate with clear scope boundaries per RAG pipeline in the interim.
• Evaluation is continuous, not one-off. RAG quality degrades as content changes, queries evolve, and edge cases emerge. Build evaluation pipelines that measure retrieval precision (are we getting the right chunks?), answer accuracy (is the response correct?), and faithfulness (does the response actually reflect what was retrieved, or did the model confabulate?). Automated evaluation using LLM-as-judge approaches can supplement manual review.

RAG Governance Integration

RAG pipelines need governance attention because they're the point where organisational data meets AI generation:

MCP Integration Architecture

The Model Context Protocol (MCP) is emerging as the standard for how AI agents connect to external tools, data sources, and systems. Launched by Anthropic in November 2024 and donated to the Linux Foundation's Agentic AI Foundation in December 2025, MCP provides a vendor-neutral protocol for agent-to-tool connectivity — effectively "USB-C for AI."

Before MCP, every agent integration required custom code: bespoke API wrappers, one-off database connectors, and fragile glue logic. Each new tool connection meant more engineering work, more maintenance, and more security surface area. MCP standardises this with a client-server architecture using JSON-RPC 2.0, where tools expose their capabilities through a consistent protocol that any MCP-compatible agent can discover and use.

This matters for enterprise architecture because it shifts tool integration from an application-level concern to an infrastructure-level pattern — the same way APIs standardised application integration a decade ago.

MCP Architecture Components

Host: The AI application that orchestrates LLM interactions. Manages security policy, user consent, and overall coordination. The host is the trust boundary.

Client: Maintains a connection to a specific MCP server. Each client-server pair is an independent session. Clients communicate on behalf of the host.

Server: Exposes tools (actions the agent can take), resources (data the agent can read), and prompts (templated interactions) through a standardised interface. Servers can be local processes or remote services.

Enterprise MCP Patterns

Direct Connection (Development / Simple Deployments)

Agents connect directly to MCP servers. Simple to implement but difficult to govern at scale — no central visibility, no consistent policy enforcement, no audit aggregation. Appropriate for development environments and single-purpose internal tools only.

MCP Gateway (Enterprise Pattern)

The critical enterprise pattern. An MCP Gateway sits between agents and MCP servers, providing a single enforcement point for security, policy, and observability:

Governed Catalogue (Mature Enterprise)

Beyond the gateway, a governed MCP server catalogue provides registration, discovery, and lifecycle management for all MCP servers in the enterprise:

This catalogue connects to the Architecture Registry — MCP servers are architectural components that need visibility, accountability, and lifecycle management like any other.

MCP Security Considerations

MCP introduces attack surfaces that traditional API security doesn't fully cover. The IBM security blueprint for MCP and recent academic analysis identify three primary adversary types:

Prompt injection via tool responses. A compromised or malicious MCP server can return tool results containing instructions that manipulate the agent's behaviour. Defence: treat all tool responses as untrusted data. Implement output filtering at the gateway. Sandbox agent execution environments.

Supply chain risk from third-party servers. The MCP ecosystem is growing rapidly — not all servers are equally trustworthy. Defence: governed catalogue with approval process for new MCP servers. Server provenance verification. SBOM (Software Bill of Materials) for MCP server dependencies.

Privilege escalation through tool composition. An agent with access to multiple tools may be able to chain actions in ways that exceed intended permissions. Defence: the gateway pattern enables monitoring of tool-call sequences and policy enforcement across multi-step operations. Composite permissions analysis — review what agents can achieve by combining tools, not just individual tool permissions.

MCP Gateway security controls:

MCP Governance Integration

MCP needs governance treatment as an integration pattern, not just a technology choice:

Treat MCP servers as integration points in the Architecture Registry. Every MCP server is a dependency — when it changes, breaks, or gets compromised, agents that rely on it are affected. Register them, monitor them, include them in impact analysis.

MCP server lifecycle needs the same rigour as API lifecycle. Versioning, deprecation notices, breaking change management. The MCP specification is still evolving (the November 2025 update added async operations, improved authorisation, and enterprise features) — track spec changes and assess impact on deployed servers.

Tool sprawl is the new API sprawl. As MCP adoption grows, organisations risk the same proliferation problems they've seen with APIs. A governed catalogue with clear ownership, approval processes, and decommission procedures prevents uncontrolled growth. Gartner's research flags that tool overload degrades agent accuracy even before technical limits are reached — too many tools in an agent's context window reduces selection quality.

Human consent for tool use. The MCP specification explicitly requires that hosts obtain user consent before invoking tools. For enterprise deployments, this translates to: which tools can agents use autonomously, which require human approval per invocation, and which are prohibited? This maps directly to the autonomy levels defined in the Agent Identity Model.

The MCP specification is evolving rapidly. MCP was donated to the Linux Foundation's Agentic AI Foundation (AAIF) in December 2025, establishing vendor-neutral governance. The spec is on a regular release cadence — the November 2025 update added async operations, improved authorisation (OAuth 2.0), structured tool outputs, and enterprise-oriented features. Further changes are in development, including server discovery, stateless scaling, and standardised extensions for industry-specific domains. Treat MCP architectural decisions as living guidance — review against the current specification at each quarterly guardrail review, and track AAIF announcements for breaking changes that may affect deployed MCP servers.

AI Governance Framework

AI governance isn't about saying no to AI. It's about creating the conditions under which AI can be deployed with confidence — confidence that it's ethical, that it's compliant, that it's accountable, and that it's actually doing what it's supposed to do.

AI Governance Principles

• Human oversight: Humans remain accountable for AI decisions. The system can recommend; humans decide — especially for consequential outcomes. The level of human oversight should be proportionate to the impact of the decision.
• Explainability: Stakeholders affected by AI decisions deserve an explanation of how decisions were made, at a level appropriate to context. A customer denied a service needs a different explanation than an engineer debugging model behaviour.
• Fairness: AI systems should not discriminate based on protected characteristics and should be tested for bias before and during deployment. This requires deliberate testing, not just assumption.
• Privacy: AI systems must handle personal information in accordance with privacy requirements, including purpose limitation and data minimisation. Particular attention for AI: training data may contain personal information that the model can surface in unexpected contexts.
• Security: AI systems are attack surfaces. They need protection from adversarial manipulation (prompt injection, jailbreaking), data poisoning, model theft, and misuse. This connects to Security Architecture for baseline controls.
• Transparency: Organisations should be open about where and how AI is used, especially in customer-facing contexts. People should know when they're interacting with AI.
• Accountability: Every AI system has a human owner. Every AI decision traces to someone who can be held accountable. This doesn't mean humans are blamed for AI errors — it means someone is responsible for ensuring appropriate governance is in place.

AI Risk Classification

Not all AI deployments need the same governance intensity. Classification drives proportionate oversight:

Classification should happen early — at initiative assessment, not after deployment. Review classification when use cases change, data sources change, or autonomy levels change.

Explainability as a risk mitigant: Systems that can provide full reasoning traces — whether through symbolic approaches, chain-of-thought logging, or auditable retrieval pipelines — present lower governance risk than opaque models. Where an AI system can demonstrate how it reached a conclusion with traceable evidence, proportionately lighter oversight may be appropriate compared to black-box models at the same autonomy level. This isn't a free pass — explainability reduces but doesn't eliminate risk.

Regulatory Alignment

AI regulation is evolving rapidly. The governance framework should align with applicable frameworks without being dependent on any single one:

Government context: Queensland Government agencies should reference FAIRA for AI risk assessment. Australian Government agencies should align with the Australian AI Ethics Principles. These aren't optional for government — they're expected practice. Build compliance into your process, not as an afterthought.

Model Lifecycle Management

AI models aren't static. They degrade, drift, and require ongoing attention. A model that performed well at deployment can become dangerously inaccurate as the world changes around it. Lifecycle management ensures models remain fit for purpose.

Model Lifecycle Stages

• Development: Training data governance, bias testing, documentation of model decisions and limitations. What data was used? What was excluded? What performance thresholds were set? What edge cases were identified?
• Validation: Independent validation before production. Performance benchmarking. Edge case testing. Bias assessment against protected characteristics. Red teaming for adversarial robustness.
• Deployment: Staged rollout (shadow mode → canary → progressive → full). Monitoring instrumentation. Rollback capability. For fine-tuned or custom models, deployment includes model versioning and artifact management. For vendor models, deployment includes prompt versioning and configuration management.
• Operation: Performance monitoring against defined metrics. Drift detection — is the model's accuracy changing over time? Cost monitoring — is inference cost tracking to budget? Incident response procedures for model failures or harmful outputs.
• Evolution: Retraining triggers (performance degradation, data distribution shift, new requirements). Version management. A/B testing for improvements. Prompt iteration for vendor models.
• Retirement: Clear criteria for when models should be retired. Graceful degradation. Replacement planning. Data retention and disposal for training data.

Model Registry

Every model in production — whether vendor-provided, fine-tuned, or custom-built — should be registered:

Prompt Management

For organisations using vendor foundation models (increasingly the majority), prompt management is the new model management. Prompts are the interface between your business logic and the model's capability — they deserve the same governance as code.

Prompt governance principles:

Prompts are versioned and stored in source control, not in someone's clipboard. Prompt changes follow the same review process as code changes. System prompts that define agent behaviour are treated as configuration that affects security and compliance. Prompt testing includes adversarial testing (prompt injection attempts, jailbreak attempts, boundary-pushing inputs).

AI Observability Principles

Individual artefacts in this module each address their own monitoring needs — agent audit trails, model drift detection, RAG evaluation metrics, MCP gateway logging. But these need to connect into a coherent observability story across the AI stack. Without it, you have monitoring in silos — you can see that an agent failed, but not that it failed because the RAG pipeline returned stale content from a vector store that hadn't been refreshed since last week.

Unified tracing across the AI chain. A single user request may flow through a consumption interface, an orchestration layer, an agent, a RAG pipeline, an MCP tool call, and a model inference — potentially spanning multiple services. Distributed tracing should capture this full chain. OpenTelemetry is the emerging standard for AI observability, with GenAI semantic conventions in active development that extend traditional application tracing with AI-specific spans for model inference, retrieval operations, and tool calls.

What to observe at each layer:

Anomaly detection for agent behaviour. Unlike traditional applications, AI agent behaviour is probabilistic — some variation is expected. But sudden changes in tool selection patterns, unusual data access volumes, or unexpected escalation rates may indicate prompt injection, model degradation, or configuration drift.

Connect observability to the Governance Core. AI observability data feeds multiple governance components: the Architecture Registry (health status of AI components), Technical Debt Register (degrading models, drifting agents), and Tiered Oversight (evidence that oversight levels remain appropriate). Don't build AI observability as a standalone dashboard — connect it to the governance structures that act on the signals.

AI Guardrails

AI guardrails define the non-negotiables and risk-based boundaries for AI decisions across the organisation. They're owned by AI Architecture and should be referenced by every team building or deploying AI capability.

What AI guardrails typically cover:

AI model selection and approval requirements. Agent identity and access requirements. Data handling requirements for AI workloads. Human oversight requirements by risk classification. Ethical boundaries for AI use cases. Cost management and consumption controls. Vendor and model provider requirements. Prompt security and adversarial resilience requirements.

Example AI guardrails:

• "All AI agents operating in production must have a registered identity in the enterprise identity provider — no exceptions."
• "Generative AI used for content that will be published externally requires human review before publication."
• "AI models processing PROTECTED or above classified data must run within Australian-sovereign infrastructure."
• "AI agent permissions must follow least privilege. Agents must not hold standing write access to production systems unless continuous operation requires it, with compensating monitoring controls."
• "AI-assisted decisions affecting individuals (eligibility, risk scoring, access) require documented explainability and human override capability."
• "Foundation model API costs must be attributed to consuming business units. Shared platform costs are governed by the AI platform team."
• "Prompt injection testing is mandatory for any AI system accepting user input before production deployment."
• "AI model selection must consider inference efficiency alongside accuracy. Prefer efficient models for high-volume, non-critical tasks — not every use case needs a frontier model. Report inference compute costs quarterly as part of AI cost attribution."
• "Multi-agent systems must implement chain-of-trust logging. Every agent-to-agent delegation must be captured in the audit trail, with supervisory agents reviewing outputs for high-risk decisions before they take effect."

Integration with Other Domain Modules

AI Architecture shapes and is shaped by every other domain:

The boundary with Innovation Architecture is important: Innovation owns the experimentation and assessment of AI capability. This module owns what happens when AI moves to production. The handover point is scale readiness — when an AI experiment is ready for enterprise deployment, it needs to meet the governance, identity, and platform requirements defined here.

Operating Model Adaptations

Large Enterprise / Government

Large organisations and government agencies typically have established governance, significant compliance obligations, and complex stakeholder environments.

Adaptation points:

Full AI governance with ethics review board or committee. AI agent identity integrated with enterprise identity provider (Entra ID, Okta, etc.). Formal AI risk classification aligned with existing risk management frameworks. Integration with whole-of-government frameworks (FAIRA for Australian government). Procurement and vendor assessment integration for AI model providers. Compliance evidence requirements built into all templates. Sovereign data requirements for model hosting and data residency.

Federated Organisations

Organisations where AI capability is built across multiple business units or agencies need coordination without centralised control.

Adaptation points:

Shared AI guardrails with local implementation flexibility. Central AI model and agent registry for visibility without central approval. Community of practice for sharing AI patterns and learnings. Common AI identity framework with federated implementation. Shared AI platform services where economies of scale justify it (embeddings, vector stores, common models). Local autonomy for domain-specific AI use cases within guardrails.

Project-Based Organisations

Where funding comes in project tranches, AI capability competes for the same pool as delivery.

Adaptation points:

AI capability investment justified within project business cases. Lightweight AI governance that doesn't consume project runway. Clear handover when project-funded AI capability needs ongoing operation. AI agent identities provisioned as part of project setup, reviewed at project close. Platform costs attributed to projects, with shared infrastructure funded separately.

Small / Growing Organisations

Organisations early in their AI journey with limited dedicated AI capability.

Adaptation points:

Start with managed AI services (vendor APIs, SaaS with AI features) before building platform capability. AI guardrails focused on the highest-risk areas first — data handling and human oversight. Agent identity can start simple — distinct service accounts with clear naming convention — before full agent identity model. Single AI register (even a spreadsheet) tracking all AI usage across the organisation. Governance proportionate to scale — don't build enterprise AI governance for three AI use cases.

Common Pitfalls

Shadow AI everywhere — Teams adopt AI tools without anyone knowing. The AI register is empty while the organisation is full of AI. Fix: make registration easy and valuable (not bureaucratic), and build discovery mechanisms (API gateway monitoring, cloud cost attribution, procurement alerts).

Agent identity as afterthought — Agents deployed with shared service accounts, no audit trail, and permissions nobody can explain. Fix: agent identity from day one. No agent in production without a registered identity.

Governance theatre — Ethics assessments get completed but nobody reads them. Risk classifications happen but don't change anything. Fix: governance outputs must change behaviour — risk classification drives oversight level, ethics assessment drives design decisions.

Platform before use cases — Building a comprehensive AI platform before proving that AI delivers value. Fix: start with managed services and proven use cases. Build platform capability when you're solving real scaling problems, not imaginary ones.

One-size-fits-all governance — Applying the same governance intensity to a document summarisation tool and an automated eligibility decision system. Fix: risk-based classification that drives proportionate governance.

Prompt sprawl — Prompts stored in code, in databases, in configuration files, in someone's notebook, with no version control or testing. Fix: treat prompts as first-class artifacts with versioning, testing, and review.

Model set and forget — Models deployed and never monitored for drift, bias, or degradation. Fix: model lifecycle management with defined monitoring cadence and retraining triggers.

Agent permission creep — Agents accumulate permissions over time as new tools are added but old ones are never removed. Fix: regular agent access reviews (just like user access reviews) and just-in-time permissions where practical.

Cost blindness — AI consumption costs growing unchecked because nobody's tracking which teams, agents, or use cases are driving spend. Fix: cost attribution from day one. AI spend visible at the same granularity as cloud spend.

Extending to Deeper Frameworks

XAF AI Architecture provides the governance-connected fundamentals. For organisations wanting deeper AI architecture practice, the following established frameworks and vendor resources offer comprehensive guidance — and informed this module's reference architecture:

The goal isn't XAF or these deeper frameworks — it's XAF for governance integration, with deeper methodology available for those wanting comprehensive AI architecture practice. Start with what XAF provides. Extend when you need more depth.

Getting Started

Week 1 — Minimum Viable AI Visibility

1. Inventory your AI — What AI tools, models, and agents exist in your organisation right now? You'll be surprised. Include SaaS AI features, not just purpose-built AI.
2. Identify your highest-risk AI — Which AI use cases touch personal data, make or inform decisions about people, or operate with any autonomy?
3. Write your first AI guardrails — Even three guardrails are better than none. Start with identity, data handling, and human oversight.
4. Assign ownership — Someone needs to be accountable for AI architecture. Even if it's a part-time responsibility initially.

Month 1 — Foundation

1. Establish AI risk classification — Categorise your existing AI use cases. This immediately tells you where governance effort should focus.
2. Set up agent identity basics — Ensure every AI agent has a distinct identity. Even if the full identity model isn't implemented yet, no more shared service accounts for agents.
3. Create the AI register — Simple is fine. Model name, purpose, owner, data classification, risk level. This becomes your portfolio view.
4. Define the platform direction — Are you centralising, federating, or consuming managed services? Even a directional decision prevents fragmentation.

Quarter 1 — Governance and Platform

1. Implement AI governance for high-risk use cases — Ethics assessment, explainability requirements, monitoring. Focus on the AI that could hurt most.
2. Build agent authorisation model — Least privilege, scope boundaries, escalation triggers for your production agents.
3. Establish model lifecycle practices — Monitoring, drift detection, review cadence. Start with production models.
4. Connect to the Governance Core — AI guardrails in the framework, AI systems in passports, AI decisions in records, AI debt in the register.

Ongoing

Quarterly AI guardrail reviews (the landscape moves fast). Agent access reviews aligned with user access review cadence. Model performance and drift reviews. AI register currency checks. Cost attribution and optimisation reviews. Regulatory landscape monitoring for new AI-specific requirements.

What Success Looks Like

You know AI Architecture is working when:

Outcome Indicators:

Teams deploy AI with confidence because guardrails tell them what "good" looks like. AI agents have clear identities, bounded permissions, and audit trails. When someone asks "what AI do we have?" there's a clear answer. AI governance is proportionate — lightweight where risk is low, rigorous where it matters. Model performance is monitored and drift is caught before it causes problems. Shadow AI is reducing because the governed path is easier than going alone. AI costs are visible and attributed to the teams and use cases driving them. When an AI incident occurs, the response is informed by clear ownership and audit trails.

Metric Indicators:

Anti-metrics (things that might look good but indicate problems):

• 100% guardrail compliance — guardrails might be too loose, or teams aren't pushing boundaries
• Zero agent permission escalations — agents might not be doing anything useful
• No AI governance exceptions — the process might be so onerous that teams avoid it entirely
• All AI classified as low risk — classification might not be honest

The Bottom Line

AI Architecture bridges the gap between "we're using AI" and "we're using AI responsibly, visibly, and at scale." Without it, you get shadow AI, ungoverned agents, unmonitored models, and the inevitable incident that erodes trust in AI across the organisation.

The technology is moving fast. The governance doesn't need to move as fast, but it needs to exist and it needs to connect to everything else. AI decisions are architecture decisions. AI agents are identity principals. AI models are assets that need lifecycle management. AI platforms are infrastructure that needs technology governance.

Start with visibility — know what AI you have. Add identity — every agent gets a name. Build governance proportionate to risk — not everything needs the same scrutiny. Connect to the Governance Core — AI isn't special enough to have its own parallel governance universe.

AI that ships without governance isn't innovation — it's a liability. Governance that prevents AI from shipping isn't protection — it's a bottleneck. This module provides the middle path.

Templates Summary

This module includes the following ready-to-use templates: