Fundamental Principles

Principles are the part of an architecture that survives the next reorganisation, vendor and model generation. Chapter 3 mapped what the law requires; this chapter sets out how to decide where the law leaves the choice open, which is most of the time. It proposes eight principles for AI Architecture, relating each to the principles of Architecture as Code (Chapter 2) from which it descends and to the AI Act (66, Nordqvist, 2025), for use as review criteria, as the backbone of an AI policy, and as the source of the checks that Chapters 8 and 9 build into governance gates.

Figure 4.1: The eight principles inherit from the principles of Architecture as Code and are shaped by the AI Act; they fall into four groups (the table below).

Group	Principles
Intent	Declared intent; data and model as first-class elements
Trust	Reproducibility and lineage; evaluation before and after deployment
Control	Bounded autonomy; human oversight by design; least privilege for models and agents
Constraints	Sustainability and cost as design constraints

Table for Figure 4.1: The eight principles by group.

What a principle has to do

A principle earns its place only if it changes decisions. Richards and Ford (2020) argue that architectural characteristics have to be explicit and measurable before trade-offs can be reasoned about (71, Richards & Ford, 2020), so each principle below is stated as an obligation on the design with at least one verification a machine can perform, in the spirit of the fitness functions of Architecture as Code (66, Nordqvist, 2025).

The principles also share a scaling rule. Regulation (EU) 2024/1689, the AI Act, applies obligations in proportion to risk, from prohibited practices in Article 5, through high-risk AI systems in Article 6 and Annex III, to transparency duties in Article 50 and minimal-risk systems with no specific obligation (1, European Union, 2024). The depth of evidence each principle demands follows the same gradient: a spam filter and a benefits eligibility system both need declared intent, yet only one needs it reviewed by a fundamental rights impact assessment.

Principle 1: Declared intent

Every AI system has a codified statement of its purpose, its scope and the uses that are prohibited, and that statement is the reference against which classification, evaluation and oversight are measured.

Intent is the hinge of the regulatory structure. The AI Act defines intended purpose in Article 3(12), classification as high-risk under Article 6 depends on it, and Article 13 and Annex IV require it in the instructions for use and the technical documentation (1, European Union, 2024). An organisation that has not written down what a system is for cannot classify or evaluate it. Following Architecture as Code's principle of declarative intent (66, Nordqvist, 2025), the declaration belongs in the repository beside the system, in a form a pipeline can read. The verification is that no system reaches production without a declaration, and that the declared risk class matches the controls the pipeline finds in place.

Declared intent also covers systems the organisation did not build. In Mode 0 and Mode 1 it takes the form of an inventory entry and an approval written as "service, tier, mode, permitted data classes". A multinational group also declares where the system is used. Hansa Mutual's claims assistant declares six markets, but the declaration carries legal weight under the AI Act only in the EU entities, since Norway follows once the Act is incorporated into the EEA Agreement (187, EFTA, n.d.) and the United Kingdom and Switzerland sit outside it; there Hansa applies it as group policy.

Principle 2: Data and model as first-class architectural elements

Datasets and models are architectural elements with owners, versions, documentation, interfaces and lifecycles, on the same footing as services and databases.

Sculley et al. (2015) showed that data dependencies in a machine learning system cost more than code dependencies and may be harder to detect (48, Sculley et al., 2015), so documentation must travel with the artefact. Mitchell et al. (2019) proposed the model card, recording intended use, training data, evaluation results and known limitations (46, Mitchell et al., 2019), and Gebru et al. (2021) the datasheet, recording a dataset's motivation, composition, collection and recommended uses (47, Gebru et al., 2021). Both should change in the same commit as the artefact they describe. The verification is that every registered model has a card and every training dataset a datasheet, re-reviewed when the artefact changes.

In the lower usage modes the organisation never sees the model, so it manages the data the model touches; for an embedded assistant (Mode 2) the equivalent of a datasheet is the access review before licence assignment. For a licensed model, Article 53(1)(b) and Annex XII oblige providers of general-purpose AI models to inform downstream providers (1, European Union, 2024), and the registry entry links that documentation and records its gaps.

Principle 3: Reproducibility and lineage

Any model in production can be traced to the data, code, configuration and environment that produced it, and the same inputs produce the same artefact.

Reproducibility is the AI form of Architecture as Code's insistence on version control and immutable artefacts (66, Nordqvist, 2025). It requires capturing the data snapshot or its hash, the code commit, hyperparameters, base model version, container image and seeds, and at inference time the model version, prompt version and retrieved documents behind each output. Article 12 of the AI Act requires high-risk systems to log events automatically so that their functioning can be traced, and Article 11 with Annex IV requires documentation of the development process, data and validation (1, European Union, 2024), which an unreproducible system cannot meet. The verification is a periodic rebuild that yields the same evaluation results, and a trace for every production output that resolves to registry entries.

For a group processing data in several countries, lineage also records place. Hansa Mutual's claims assistant is used in six markets and processed in Germany and at the Polish service centre, so every trace carries the market of the claim and the place of processing. In Modes 1 and 2, by contrast, the only reproducibility available is the vendor's audit log retained under the organisation's control.

Principle 4: Bounded autonomy

Every AI system, and every agent in particular, operates within explicit limits on the actions it may take, the resources it may consume and the decisions it may make without a person, and those limits are enforced outside the model.

A model cannot be trusted to respect limits it is merely told about, because adversarial input can alter its behaviour, so the limits are enforced by components it does not control: a tool allow-list, per-tool permissions, a budget, a step limit, and approval gates above an impact threshold. This is the blast-radius thinking of Architecture as Code applied to behaviour rather than infrastructure (66, Nordqvist, 2025), and the Manage function of the NIST AI Risk Management Framework expresses the same idea as risk management (36, NIST, 2023). The verification, using the manifest of Chapter 9, is that no agent can invoke a tool absent from its manifest, and that the enforcing policy is tested like any other code.

For a coding agent in Mode 3, which runs with the developer's credentials, the bounds are the managed permission policy, sandbox and egress allow-list. Nordvik Region limits Mode 3 tools to its platform team and runs no Mode 5 agents at all; Hansa Mutual cannot, so it bounds its claims-triage and IT-operations agents with manifests, value limits and approval thresholds, and binds every tool call of the claims-triage agent to the market of the claim.

Principle 5: Evaluation before and after deployment

The quality, safety and fairness of an AI system are measured against declared acceptance criteria before deployment, and the same measurements continue in production for as long as the system runs.

In AI the code may be unchanged while the data, the world or an upstream foundation model has changed, so evaluation is a continuous property rather than a phase. Article 9 of the AI Act describes risk management for high-risk AI as a continuous iterative process, Article 15 requires appropriate accuracy and robustness, and Article 72 requires post-market monitoring that actively collects and analyses performance data (1, European Union, 2024); the NIST framework's Measure function states the same requirement in the vocabulary of risk (36, NIST, 2023). Architecturally this means versioned golden datasets, pipeline thresholds and production sampling with human review. The verification is that a model cannot be promoted below its thresholds and that an alert fires when production quality drops below them.

For a bought service, evaluation becomes acceptance testing, repeated whenever the vendor changes the model. Hansa Mutual's claims assistant answers in five languages whose quality differs, so its release gate applies thresholds per language rather than to a flattering average.

Principle 6: Human oversight by design

Where an AI system affects people, the ability of competent people to understand, override and stop it is built into the architecture, assigned to named roles and exercised in practice.

Article 14 of the AI Act requires that high-risk systems be designed so that natural persons can oversee them effectively, including understanding the system's capacities and limitations, remaining aware of automation bias, deciding to disregard its output, and intervening or interrupting operation; Article 26 requires deployers to assign that oversight to people with the competence, training and authority to exercise it (1, European Union, 2024). Each is a design requirement: understanding needs explanations in the interface, overriding a workflow path that records the override without penalising the person, and interrupting a control reachable without a change request. The verification is that the interruption path has been exercised, overrides are logged and reviewed, and the oversight roles are populated. Chapter 10 develops the patterns.

Oversight means reviewing a draft in Mode 2, a designed workflow step in Mode 4, and bounds and a stop path in Mode 5. Nordvik Region's benefits-triage system only ranks, because under national administrative law an accountable official decides every case. Hansa Mutual applies the same oversight design in all seven markets as group policy, including in Switzerland, where FINMA's guidance on AI sets supervisory expectations for governance and risk management without an AI Act (192, FINMA, 2024).

Principle 7: Least privilege for models and agents

A model, a pipeline or an agent holds its own identity and only the permissions its declared purpose requires, for the data it may read, the tools it may call and the systems it may change.

Architecture as Code treated least privilege as a foundation of security as code (66, Nordqvist, 2025), and AI sharpens it in two ways. A model that can read an entire document store may reveal it under adversarial prompting, so inference-time access is scoped to the user and purpose, and an agent acting with its launcher's credentials inherits every permission that person has, so agents need identities of their own. Article 15 of the AI Act requires high-risk systems to be resilient against attempts to alter their use or performance, naming data poisoning, model poisoning and adversarial examples (1, European Union, 2024). The verification is that every model and agent has a workload identity with grants declared in code, and that access to an undeclared resource is denied and logged.

Hansa Mutual meets a jurisdictional version of the problem: a claims handler in Sweden has no reason to retrieve Dutch claims, so retrieval filters by market, and the claims-triage agent's credentials are scoped to the market of each claim rather than to the Polish service centre that processes them all.

Principle 8: Sustainability and cost as design constraints

The energy, carbon and financial cost of training and inference are design inputs with budgets and owners, not consequences discovered on an invoice.

Inference cost scales with every request and token, unlike almost any other component in the estate. Architecture as Code treated cost optimisation as an architectural discipline with measurable targets (66, Nordqvist, 2025), and AI requires the same for energy; Annex XI of the AI Act requires providers of general-purpose AI models to document known or estimated energy consumption (1, European Union, 2024). For deployers it means choosing the smallest model that meets the acceptance criteria and attributing cost to use cases. The verification is a cost and energy budget in the system's declaration and a pipeline check against it; Chapter 16A treats the economics.

In Modes 1 and 2 cost is a per-seat licence, so the decision is who receives one; in Modes 3 to 5 cost follows consumption, and a looping agent can spend a month's budget in an afternoon, so the budget belongs in its manifest. Hansa Mutual attributes platform consumption to each national entity.

The principles as code

Principles in a policy document are advice; in a repository, each with an executable verification, they are architecture. The governance gates of Chapter 9 consume the manifest below.

# architecture/principles.yaml - principles with executable verifications
apiVersion: ai-architecture.example.org/v1
kind: PrincipleSet
metadata:
  name: ai-architecture-principles
  version: 1.2.0
principles:
  - {id: P1, name: Declared intent, aiActAnchor: "Articles 3, 6 and 13", verification: policy/intent_declared.rego}
  - {id: P2, name: Data and model as first class elements, aiActAnchor: "Article 10 and Annex IV", verification: policy/model_card_present.rego}
  - {id: P3, name: Reproducibility and lineage, aiActAnchor: "Articles 11 and 12", verification: pipelines/rebuild_and_compare.yaml}
  - {id: P4, name: Bounded autonomy, aiActAnchor: "Article 14", verification: policy/agent_manifest.rego}
  - {id: P5, name: Evaluation before and after deployment, aiActAnchor: "Articles 9, 15 and 72", verification: pipelines/evaluation_gate.yaml}
  - {id: P6, name: Human oversight by design, aiActAnchor: "Articles 14 and 26", verification: checks/oversight_roles_populated.py}
  - {id: P7, name: Least privilege for models and agents, aiActAnchor: "Article 15", verification: policy/workload_identity.rego}
  - {id: P8, name: Sustainability and cost as design constraints, aiActAnchor: "Annex XI", verification: checks/budget_report.py}
scaling:
  minimal-risk: [P1, P2, P7, P8]
  limited-risk: [P1, P2, P5, P7, P8]
  high-risk: [P1, P2, P3, P4, P5, P6, P7, P8]

The scaling block connects the principles to the AI Act's risk-based approach: a minimal-risk system is spared rebuilds and oversight checks that would add cost without reducing risk, whereas a high-risk system is held to all eight. The classification that selects the row is described in Chapter 8.

Worked example: a one-page principles statement with testable controls

Illustrative example. Nordvik Region publishes its principles to staff, suppliers and residents as a one-page statement. Every line names the control that enforces it and the test that proves the control works, so the page and the manifest cannot drift apart.

# Nordvik Region: principles for the use of AI (version 1.2, approved 2026-05-14)

Approved by: Regional Executive Board. Owner: Chief Architect.

| No. | We commit to | Control | Test that proves it |
|---|---|---|---|
| P1 | Say what each AI system is for and must not do | ai-system.yaml | Deployment blocked without it |
| P2 | Document every model and dataset | Model card, datasheet | Registry rejects a model without a card |
| P3 | Explain what produced any output | Trace ID on every response | Monthly sample of 50 traces |
| P4 | Keep agents inside declared limits | Permission manifest | Policy tests on every change |
| P5 | Measure quality and fairness | Evaluation gate, drift monitor | Promotion fails below thresholds |
| P6 | Let staff understand, override and stop AI | Override and suspend switch | Suspend drill twice a year |
| P7 | Give each system only the access it needs | Workload identity | Undeclared access denied and logged |
| P8 | Budget cost and energy | Budget in the declaration | Monthly report |

Residents may ask which AI systems are used in their case: ai-register@nordvik.example.

Behind each line sits a control set with an owner, a test and a frequency. For P6, one control requires that an oversight role can suspend AI output for a whole service within five minutes, proved by drill; another expects quarterly override rates between 2 and 30 per cent, or a recorded explanation. An override rate near zero is as worrying as a very high one, because it may mean staff have stopped exercising judgement, the automation bias that Article 14(4)(b) of the AI Act asks the design to address (1, European Union, 2024).

Across the usage modes

The organisation's ability to verify the principles differs by usage mode (usage-mode matrix).

Mode	Principles that carry most weight	How they are verified
Mode 0 – Ambient AI	P1 declared intent, applied to the inventory boundary	Supplier contracts and change control
Mode 1 – Conversational assistants	P1 and P7, through data rules	Approved-tool list, enterprise settings, literacy
Mode 2 – Embedded workplace assistants	P7, because the assistant inherits the user's permissions; P6	Permission audits and sensitivity labels
Mode 3 – Agentic work tools	P4 and P7	Tool permission settings, sandboxing, repository protection
Mode 4 – Built AI applications	All eight, scaled by risk class	The pipeline checks of this chapter
Mode 5 – Autonomous production agents	All eight, with P4 and P6 dominant	Policy tests, approval gates and kill-switch drills

Verification thus moves from contract and configuration in Modes 0 to 2 to the organisation's own pipeline in Modes 4 and 5, with Mode 3 in between.

Trade-offs between principles

Principles conflict, and pretending otherwise produces architectures that satisfy none of them. Table 4.1 summarises the tensions that recur.

Tension	Where it bites	Usual resolution
P4 bounded autonomy against value	Approval for every step	Gate by impact threshold; keep low-value actions free
P3 reproducibility against hosted models	Provider retires versions	Pin, record the version, re-evaluate on change, record an exception
P8 sustainability against P5 evaluation	Evaluation consumes inference	Scale evaluation depth with risk class
P3 lineage against data minimisation	Traces retain personal data	Trace by reference and hash
P6 oversight against P7 and security	Explanations expose prompts to the wrong audience	Tier explanations by role
Group consistency against national law	Seven legal regimes	One baseline; overlays may only tighten it

Table 4.1: Recurring tensions between principles and how they are usually resolved.

The lineage tension is often found late. Article 5(1)(c) and (e) of the GDPR require personal data to be limited to what is necessary and kept no longer than needed, and Article 17 gives a right to erasure (2, European Union, 2016), while Principle 3 asks for traces that resolve every output to its inputs. A trace that stores identifiers, versions and content hashes rather than documents satisfies both, because the personal data stays in the system of record.

Resolve conflicts in the same order every time: a legal obligation first; then protection of the people affected over efficiency, so Principles 6 and 7 outweigh Principle 8; then the option that is easier to reverse; and finally record the outcome as a decision or a time-limited exception with compensating controls in the AI Decision Record, where trade-offs can be revisited.

Worked example: a recorded exception to a principle

Illustrative example. Hansa Mutual's claims assistant uses an externally hosted general-purpose AI model whose provider retires versions on its own schedule, so the full rebuild that P3 demands is impossible. Rather than ignore the principle, the architecture board records a time-limited exception with compensating controls.

# exceptions/EXC-0004.yaml - Hansa Mutual (illustrative)
apiVersion: ai-architecture.example.org/v1
kind: PrincipleException
metadata:
  id: EXC-0004
  system: claims-assistant
  decisionRecord: AIDR-0021
spec:
  principle: P3
  requirement: Periodic rebuild from recorded inputs with identical evaluation results
  reason: >
    The hosted model cannot be rebuilt or retained by Hansa Mutual. The provider
    offers version pinning for at least 12 months after a version is released.
  compensatingControls:
    - Pin the model version at the AI gateway and record it on every call
    - Re-run the full evaluation suite within 5 working days of any version notice
    - Keep prompt, retrieval configuration and index snapshot reproducible
    - Retain request and response logs for the period set by the entity's ICT risk management framework
  residualRisk: medium
  acceptedBy: chief-risk-officer
  approvedOn: 2026-06-02
  expiresOn: 2027-06-01

The exception names the requirement it relaxes, lists compensating controls, and expires, because an exception without an expiry date becomes the architecture by default; the pipeline therefore treats an expired exception as a failing check.

Nordvik Region and Hansa Mutual

Nordvik Region publishes its principles so that residents and journalists can hold it to them. Its controls lean towards Principle 6, because an accountable official decides every case, and because it mostly procures, it verifies most principles through contracts and acceptance tests; its hardest tension is lineage against data minimisation in special-category case work.

Hansa Mutual, by contrast, must make a principle written once hold in seven jurisdictions, three of them outside the AI Act, so it keeps one group statement that national entities may tighten but never weaken. Building on hosted models, it cannot always meet Principle 3 in full and says so in EXC-0004, and Principles 4 and 7 weigh far more for it, because it runs autonomous production agents and Nordvik runs none.

Summary

Eight principles define AI Architecture. Declared intent and treating data and models as first-class elements establish what a system is; reproducibility with lineage and evaluation before and after deployment establish whether it can be trusted; bounded autonomy, human oversight by design and least privilege establish how it is controlled; and sustainability and cost establish what it may consume. Each is anchored in the AI Act and has a verification that a pipeline can execute.

They apply in proportion to risk and in every usage mode, and their predictable conflicts are resolved in a fixed order and recorded. Principles describe how to design, however, not whether an organisation can apply them, so Chapter 5 closes Part I with a readiness assessment codified as a scorecard.

Sources

1. Nordqvist, G. (2025). Architecture as Code. Companion volume to this book, published at aac.geon.se. (66, Nordqvist, 2025)
2. Richards, M. & Ford, N. (2020). Fundamentals of Software Architecture: An Engineering Approach. Sebastopol, CA: O'Reilly Media. ISBN 978-1-4920-4345-4. (71, Richards & Ford, 2020)
3. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, 12 July 2024. (1, European Union, 2024)
4. European Free Trade Association. EEA-Lex factsheet 32024R1689: the Artificial Intelligence Act. EFTA. (187, EFTA, n.d.)
5. Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J.-F. & Dennison, D. (2015). Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems 28 (NeurIPS 2015). (48, Sculley et al., 2015)
6. Mitchell, M., Wu, S., Zaldivar, A., Barnes, P., Vasserman, L., Hutchinson, B., Spitzer, E., Raji, I. D. & Gebru, T. (2019). Model Cards for Model Reporting. Proceedings of the Conference on Fairness, Accountability, and Transparency (FAT* '19), pp. 220–229. (46, Mitchell et al., 2019)
7. Gebru, T., Morgenstern, J., Vecchione, B., Vaughan, J. W., Wallach, H., Daumé III, H. & Crawford, K. (2021). Datasheets for Datasets. Communications of the ACM, 64(12), pp. 86–92. (47, Gebru et al., 2021)
8. National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1, January 2023. (36, NIST, 2023)
9. Swiss Financial Market Supervisory Authority (2024). FINMA Guidance 08/2024: Governance and risk management when using artificial intelligence. FINMA, 18 December 2024. (192, FINMA, 2024)
10. European Parliament and Council of the European Union. Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). Official Journal of the European Union, 4 May 2016. (2, European Union, 2016)