AI Reference Architecture

How to use this document

• What it is for. This is a base architecture guide to design AI solutions that are secure, traceable and governable: layers and components, approved patterns, environments, model and instruction management, data, security, logging, human oversight, resilience and exit. It is vendor- and technology-neutral.
• Who should own it. Usually IT architecture, with data or machine learning engineering and security. Enter the function in [RESPONSIBLE FUNCTION] and the person in [OWNER].
• Decisions to take first. Decide which components will be shared across the organization (for example, an AI gateway and a model registry), which deployment profiles you have (P1 to P5) and, with that, which patterns in Section 4 you approve, which specific technologies you will use in each layer (aid F) and how exceptions are handled (Section 12).
• Fields to complete. Replace the bracketed fields and complete the approved technologies table. Keep [OPTIONAL] clauses only if they apply.
• Country variants. This guide has no country variants. If you manufacture or sell AI software as a product, or process data in countries with specific localization or security requirements, review Sections 7 and 8 against the laws listed in "Related regulatory references."
• Review. Have information security validate Section 8 against the "AI Security Baseline" and have the data protection officer (or the country's equivalent role) validate the data and logging rules in Sections 7 and 9.
• Approval and publication. Have it approved by the technology leadership or the architecture board, record the approval in "Version history," and publish it for the architecture and engineering teams and for vendors that build solutions for the organization.

Module selection

Profile	Patterns and sections to keep
All	Sections 1 to 3, 4.5 and 5 to 12
P2 Integrates models through APIs or RAG	4.1 and 4.2
P3 Hosts models, including open-weight models	4.6
P4 Trains or fine-tunes models	4.3
P5 Uses agents that act in systems	4.4

This guide has no content specific to profile P1: organizations that only use AI inside software they buy can skip it and apply the "AI Assistant and Copilot Rollout Guide". Delete the patterns that do not apply to your organization.

AI Reference Architecture

Field	Value
Organization	[LEGAL ENTITY NAME]
Owning function	[RESPONSIBLE FUNCTION]
Guide owner	[OWNER]
Approved by	[APPROVED BY]
Effective date	[DATE]
Review frequency	[REVIEW FREQUENCY]
Contact	[AI GOVERNANCE EMAIL]

1. Purpose and scope

1.1 This guide defines the reference architecture that [ORGANIZATION NAME] uses to design, build, integrate and operate AI solutions, so that they are secure by design, traceable, subject to human oversight, replaceable and consistent with the organization's policies.

1.2 It applies to:

• solutions that integrate vendor models through APIs (for example, language models);
• third-party models hosted on owned or rented infrastructure, including open-weight models of any origin;
• retrieval-augmented solutions over internal data;
• in-house predictive or classification models;
• AI agents that use tools or take actions;
• AI features that external vendors build for the organization.

1.3 Every new design for a Medium- or High-risk AI solution, and every internally hosted model, goes through the architecture review (aid B) before it is built and before go-live.

2. Design principles

1. Secure by design and by default. Secure default configurations, least privilege and defense in depth.
2. Traceability. It is possible to reconstruct which model version, instructions and data produced each relevant output.
3. Built-in human oversight. The architecture lets a person review, correct or stop the system when the risk calls for it.
4. Minimization and privacy. Only the necessary data is sent to models, and it is protected at every layer.
5. Neutrality and portability. Applications do not depend directly on a single vendor; access to models goes through internal interfaces that allow the vendor to be changed.
6. Fail safe. On errors, the system degrades to a defined safe state, not to unexpected behavior.
7. Observability. Performance, quality, cost and security are measured from day one.
8. Reuse. Approved shared components are used instead of building parallel solutions.