Architecting AI-Enabled Systems

Welcome to Chapter 12, Architecting AI-Enabled Systems. It is about systems built around artificial intelligence, or AI: machine learning models, and large language models, or LLMs. They need everything the earlier chapters taught, plus new answers to new questions. Where should a model run? How do you ground it in your own data, let it use tools safely, test something probabilistic, and defend against prompt injection?

This chapter is for developers and architects who know the rest of the course, and who must design, review or govern AI-enabled systems that are reliable, secure and affordable. It builds on the whole course: every quality, style and practice, now applied to probabilistic components. It leans most on quality attributes, data architecture, security and privacy, resilience and observability, and evaluation and fitness functions. Those earlier ideas change shape here. Quality attributes now include accuracy and groundedness. Resilience must cope with rate limits and outages at a model provider. And testing becomes evaluation. This is the last chapter, so it leads on to the final assessment and the capstone case study.

Most of an AI-enabled system is ordinary software. This container diagram from Section twelve point two shows the chapter's running example: a customer support assistant for the food delivery platform. Customers chat through the mobile app, which talks to a chat service. Difficult conversations are handed off to an agent console, where human support agents pick them up. At the centre is the orchestrator, which holds the prompts, the tools and the limits. It searches a help-centre index, and makes tool calls to the existing order and refund services. Every model call passes through an AI gateway, which holds the provider keys, routes each call, and falls back from provider A to provider B. Traces of every call are kept for evaluation. Only the model is new. But its behaviour is statistical rather than specified: usually right, sometimes confidently wrong, and supplied by a provider that may throttle it, change it or retire it. That changes how everything around it must be designed.

The first four sections build the system. Section twelve point one explains what machine learning and large language models are: training and inference, tokens, context windows, sampling and embeddings, and why hallucination and non-determinism are inherent. Section twelve point two places the model in an architecture: hosted, self-hosted or on the device, behind an AI gateway, with routing, cascades, fallback ladders and humans in the loop. Section twelve point three covers retrieval-augmented generation, or RAG, the most common pattern for grounding answers in your own data, from chunking and vector indexes to hybrid search and access control. Section twelve point four moves from answering to acting: tool calling, the agent loop, workflow patterns, the Model Context Protocol, or MCP, and the reliability engineering that agents need.

The second four sections make the system trustworthy and sustainable. Section twelve point five shows how to test probabilistic behaviour, with evaluation sets, metrics, a model acting as judge, and regression evaluations that act as fitness functions. Section twelve point six covers prompt injection, excessive agency and the other risks catalogued by OWASP, and the layered defences that contain them. Section twelve point seven deals with token economics, latency, caching and batching, and the practice of versioning, tracing and monitoring model calls. And Section twelve point eight covers data governance, fairness, transparency and human oversight, and how regulation such as the EU AI Act, and frameworks such as the NIST AI Risk Management Framework, shape architecture.

A language model cannot reliably tell instructions from data, so any text in its context can try to steer it. This diagram from Section twelve point six shows the answer: deterministic layers around an untrusted model. A user's message first passes input guards, then a context builder, which marks untrusted content and pulls in data filtered by the user's own access rights. The model sits in the middle, labelled never trusted. Its output passes output guards, which check the schema and filter what reaches the user. When it asks to use a tool, a tool gateway enforces authorisation and policy. Consequential actions need human approval before they reach the business systems, while read-only calls go directly. And monitoring collects logs, traces and anomaly alerts, with a kill switch. No prompt is a security boundary. These deterministic layers decide what the model can see, what it can do, and what reaches the user.

Two examples recur. The support assistant you have just seen gains retrieval in Section twelve point three and tools in twelve point four, and is evaluated, secured and costed in the sections after that. The second is this course itself. ArchitectBot answers learners' questions by retrieving passages from the course's own chapters, and calls a ladder of models from more than one provider, so that a single outage does not silence it. Written test answers are marked by a model against a fixed rubric.

Section twelve point eight explains that the EU AI Act regulates by risk: prohibited practices, high-risk systems, transparency obligations and minimal risk, with separate obligations for general-purpose AI models. That material is general information, not legal advice. Obligations depend on the facts of each system, and on the exact legal texts and guidance in force, which continue to change. Qualified legal advisers should be involved in any real classification or compliance decision.

Treat the model as a talented, fallible and untrusted component, and let deterministic architecture decide what it sees, what it may do and what happens to its output. Ground its answers in retrieved, permitted facts. Validate everything it produces, and give it the least privilege its task needs. Require human confirmation for consequential actions. Measure its quality continuously, as you would any other quality attribute, and plan for its provider failing. Models will keep getting better, and systems built on this principle get better with them.

The sections follow the running example as it grows, so reading in order works well. But each section stands on its own, so you can go straight to the one you need. Allow about three and a half hours to read the whole chapter. Providers and models are named only as examples, because the market changes every few months while the principles do not. At the end of each section there are self-check questions. Answer them in your head before you look at the answers. When you are ready, there is an optional chapter test, which takes about forty five minutes. It has twenty multiple choice questions and two written answers. The pass mark is eighty per cent.

That is the shape of the final chapter. Start with Section twelve point one, on machine learning and large language models for architects. See you there.