AI Security Engineering in Practice

Chapter 16 mapped the threat landscape. This chapter is the engineering handbook that follows from the map, in the same relationship that Chapter 9B of Architecture as Code bears to Chapter 9 (72, Nordqvist, 2025). It covers a threat-modelling method, the controls at each layer from training data to tool execution, red teaming as a pipeline stage, incident response under the European reporting duties, and the evidence an assurance function will ask for.

The organisations I work with rarely lack awareness of AI threats; they lack a repeatable way to turn it into controls that survive the next release. The remedy is that of Architecture as Code: declare the intent, version it, test it on every change, and derive evidence from the pipeline. ENISA's multilayer framework supplies the structure, with cybersecurity foundations below, AI-specific practices in the middle and sector-specific obligations on top (19, ENISA, 2023); this chapter works through the middle layer.

The running example, a composite, is a payment-dispute assistant at a pan-European retail bank. The assistant retrieves the dispute policy and case history, drafts a resolution, and, as an agent, can open a case and propose a refund through the dispute API. The bank is a financial entity under Regulation (EU) 2022/2554 (DORA), the assistant processes personal data under the GDPR, and the model is a third-party general-purpose AI model hosted within the Union.

Primary topics explored

1. From the threat landscape to an engineering practice
2. A threat-modelling method for AI systems
3. Securing the data and training path
4. Securing retrieval and RAG
5. Securing inference and the AI gateway
6. Securing agents and tool use