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.

Figure 17.1: Defence in depth for an AI system. Each layer assumes the one before it has failed; the threat model, the security tests in CI, and the tamper-evident audit log cut across all of them.

From the threat landscape to an engineering practice

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.

Across the usage modes

The running example is a Mode 4 application approaching Mode 5, where most of this chapter applies; the table shows what each mode lets the organisation engineer.

Usage mode	What the organisation can engineer	Evidence
Mode 0 Ambient AI	Switching features off, restricting the data they reach	Feature inventory, configuration snapshots
Mode 1 Conversational assistants	Single sign-on, tenant settings, egress and data-loss controls	Exported tenant configuration, vendor audit logs
Mode 2 Embedded workplace assistants	Permission and label remediation, connector allow-lists	Access reviews, label coverage
Mode 3 Agentic work tools	A containment profile: sandbox, egress allow-list, scoped credentials	Profile in version control, tool-call logs
Mode 4 Built AI applications	Threat model as code, entitlement-aware retrieval, gateway, red teaming in CI	Control catalogue entries, CI results
Mode 5 Autonomous production agents	Mode 4 plus per-agent identity, approvals, budgets, hash-chained log, stop path	Decision logs, approval records, stop-drill results

Where there is no gateway, as in Modes 0 to 2, export the tenant configuration, version it, and review every change as a diff.

A threat-modelling method for AI systems

The method fits a half-day workshop and a pull request.

Assets and trust boundaries

AI systems have six asset classes that classical models omit: training data; model weights and adapters; prompts, which encode business rules; the retrieval corpus and its index; tools and their credentials; and outputs, which become actions and records. List each with a classification and an owner, because the owner reviews the threat entries that touch it.

The dispute assistant has five trust boundaries: the customer channel into the gateway, the document ingest path into the index, the model provider's API, the agent runtime into the dispute API, and the response path into the case record. The second and fifth surprise teams, because documents enter the index from systems with weak write control and model output acquires authority when it lands in a system of record.

STRIDE extended with ATLAS

STRIDE lacks the AI-specific technique, which MITRE ATLAS supplies (28, MITRE, n.d.). Table 17.1 combines the two with the OWASP identifiers, so that each threat is searchable by three vocabularies (27, OWASP, 2025).

STRIDE category	AI manifestation	OWASP 2025	Typical ATLAS technique
Spoofing	Tool server impersonated; model endpoint substituted	LLM03	Supply chain compromise
Tampering	Poisoned data or documents; injected instructions	LLM01, LLM04	LLM prompt injection; training data poisoning
Repudiation	Agent action not attributable to an instruction or approver	LLM06	A logging failure rather than a technique
Information disclosure	Training data extracted; other customers' records retrieved	LLM02, LLM07	Extract memorized data; discover system prompt
Denial of service	Token exhaustion, loop-induced cost, index flooding	LLM10	Cost harvesting; denial of AI service
Elevation of privilege	Hijacked agent exceeds the user's entitlement	LLM06	AI agent tool invocation

Table 17.1: STRIDE extended with the OWASP Top 10 for LLM applications and MITRE ATLAS.

Because Article 15(5) of the AI Act names the attack classes a high-risk system must resist (1, European Union, 2024), a threat model built on these identifiers shows, entry by entry, that each class was considered.

The model as code, linked to controls

The excerpt below is from the dispute assistant's threat model. The review_trigger list names the configuration paths whose change forces a review, and every control identifier resolves to a key in the artefacts shown later.

apiVersion: ai-architecture.example.org/v1
kind: ThreatModel
metadata:
  system: ai-system/dispute-assistant
  version: 2.3.0
  owner: cards-platform-team
  decision_record: AIDR-0087
  review_trigger: [retrieval_sources, tools, model_version, prompt_template]
trust_boundaries:
  - {id: TB-01, from: customer-channel, to: ai-gateway}
  - {id: TB-02, from: document-ingest, to: vector-index}
  - {id: TB-03, from: agent-runtime, to: dispute-api}
threats:
  - id: T-014
    boundary: TB-02
    stride: tampering
    owasp: LLM01
    atlas: AML.T0051.001
    vector: Instructions hidden in a merchant receipt uploaded to a case
    impact: Agent requests a refund the customer never asked for
    controls: [CTRL-RAG-003, CTRL-AGT-002, CTRL-GW-007]
    residual: low
controls:
  CTRL-RAG-003: Uploaded attachments indexed as untrusted with instruction stripping
  CTRL-GW-007: Output validated against the refund request schema
  CTRL-AGT-002: Refunds above threshold require case handler approval

A pipeline stage fails when a threat has no control or a control is absent from deployed configuration. A code-ownership rule routes changes to the review_trigger paths to the security architect, so the threat model is reviewed as often as the system changes, which is the only cadence that has ever worked.

Securing the data and training path

Poisoning is the attack the AI Act names first, and the defences are those of data engineering with two additions. The first is provenance: every dataset carries a datasheet, a content hash and a pipeline attestation signed with Sigstore's keyless signing, which its transparency log makes hard to forge (33, Sigstore, n.d.). The second is statistical: compare each new batch's distribution with the previous one and quarantine outliers.

Access follows least privilege with separation of duties: the identity that writes a curated dataset does not trigger training runs, and neither is a human account. Deduplicate and filter training sets for personal data, because the extraction attacks of Carlini et al. recover sequences that appeared repeatedly in training data, and repetition is what deduplication removes (52, Carlini et al., 2021).

Securing retrieval and RAG

Retrieval-augmented generation, defined in Chapter 10, creates a second write path into the model's behaviour, and most enterprise incidents we see arrive through it. Five controls address it.

Entitlement-aware retrieval. Carry each document's access attributes onto every chunk and filter on the user's delegated identity (Chapter 12) before the similarity search, never after, because a post-filter leaks through ranking.

Access control on the write path. A collection fed from a shared drive any employee can write to is an unauthenticated input to the model. Route ingestion through a pipeline governed by a data contract (Chapter 6), recording publisher, version and ingest time.

Indirect injection through documents. Greshake et al. showed that instructions in retrieved content are followed when they enter the context (51, Greshake et al., 2023). Label each chunk's provenance class in the prompt, strip imperative patterns, hidden text and markup from untrusted sources at ingest, and make sure a retrieved document can never on its own cause a write.

Index integrity. Record the index version with every response, verify the snapshot hash at deployment, and alert on writes from any identity other than the ingestion pipeline.

Exfiltration through outputs. Because a rendered link (51, Greshake et al., 2023) or image address (27, OWASP, 2025) can carry stolen data, disallow URLs outside allow-listed domains, render output as text, and block tool calls whose arguments contain long encoded strings.

Securing inference and the AI gateway

The AI gateway is where most of the threat model's controls become live. Design it as layers that each assume the previous one failed, and keep the configuration in the repository.

gateway:
  system: ai-system/dispute-assistant
  model_access:
    allowed_models: [eu-hosted-gpai-large@2026.09, classifier-small@1.4]
    require_signed_model: true
    client_identity: spiffe://bank.example/ai/dispute-assistant
  layers:
    - name: input
      injection_classifier: {model: injection-detector@3.2, action_on_detect: block}
      secret_patterns: {action: reject}
    - name: retrieval
      entitlement_filter: before_search
      untrusted_source_handling: {strip_instructions: true, label_in_prompt: true}
    - name: output
      schema: schemas/dispute-response-v3.json
      leakage_checks: [canary_tokens, personal_data_of_other_customers, url_exfiltration]
      action_on_leak: block_and_alert
    - name: logging
      store_prompt_text: hashed
      store_retrieved_chunk_ids: true
      store_tool_calls: full_arguments
      redaction_before_write: true

Model access binds the gateway to signed model versions and a workload identity. The input layer pairs a classifier for novel phrasing with deterministic patterns, and neither is trusted alone; the output layer validates the schema and checks for canary tokens and other customers' data before anything downstream consumes the result. Logging that does not leak is the hardest part, because the record-keeping obligation of AI Act Article 12 and the GDPR's data minimisation principle pull in opposite directions; the resolution is to log identifiers and hashes that allow reconstruction from governed stores rather than copies of content.

Securing agents and tool use

Chapter 11 established the permission manifest and the policy decision point; this section hardens the runtime around them. The guiding rule is that a hijacked model must be able to do nothing the user could not do, and nothing irreversible without a person.

Each agent runs under its own workload identity, a SPIFFE identifier issued at start-up, and tool tokens are minted per task, scoped to the manifest's tools and the user, and expire within minutes. Pin and review Model Context Protocol servers, whose tool descriptions enter the model's context. Run tools that execute code or fetch content in a sandbox with no credentials and allow-listed egress, which makes injection through a tool result survivable. Require approval for irreversible tools, set budgets for steps, cost and time, and write every decision, tool call and approval to an append-only, hash-chained log that neither the agent nor an operator can alter.

The policy decision point evaluates the manifest with Open Policy Agent, the engine Architecture as Code uses for infrastructure guardrails, so policy tests, review and deployment are shared (35, Open Policy Agent, n.d.). The excerpt shows the approval logic against the Chapter 11 manifest loaded as data.manifest.

package ai.agents.authz

import rego.v1

default allow := false

allow if {
    base_checks
    not requires_approval
}

allow if {
    base_checks
    requires_approval
    input.approval.approver_role == data.manifest.tools[input.tool.name].approver_role
    input.approval.action_hash == input.tool.hash
}

base_checks if {
    input.workload.spiffe_id == data.manifest.identity.spiffe_id
    input.token.subject == input.user.id
    input.token.expires_at > time.now_ns() / 1000000000
    data.manifest.tools[input.tool.name].allow
}

requires_approval if {
    data.manifest.tools[input.tool.name].requires_approval
}

requires_approval if {
    input.tool.name == "disputes.refund"
    to_number(input.tool.arguments.amount_eur) > data.manifest.thresholds.refund_without_approval_eur
}

Two properties matter more than the details. An approval is bound to the hash of the specific action, so approving one refund cannot authorise the next, and the token's subject must equal the user, so a hijacked agent cannot act for a customer who never opened the session.

Supply-chain depth

Chapter 16 introduced the ML-BOM, SLSA and Sigstore; the engineering question is where each is enforced. The answer is a registry gate with six checks: an SLSA attestation verified against the expected builder and source repository (32, OpenSSF, n.d.); a Sigstore signature verified against the pipeline's identity (33, Sigstore, n.d.); a CycloneDX ML-BOM whose dataset hashes match their signed datasheets (31, OWASP, n.d.); weights in a tensor-only format, because some formats execute code on load; a vulnerability scan of the serving image; and a licence check.

This gate is required, not preferred. NIS 2 Article 21(2) and (3) make each supplier's vulnerabilities part of the mandatory risk-management measures (4, European Union, 2022); DORA Article 28 requires financial entities to manage ICT third-party risk, which captures the model and hosting providers (3, European Union, 2022); and the Cyber Resilience Act's Annex I requirements, including secure-by-default configuration and vulnerability handling, count towards Article 15 of the AI Act where the high-risk system is itself a product with digital elements within its scope (Article 12 of the Cyber Resilience Act) (7, European Union, 2024).

Red teaming and continuous security testing in CI

Red teaming is often run once before launch and never again, which is wrong for a system whose behaviour changes with every prompt edit and model update. Keep the external exercise for discovery and convert every finding into an automated test. The CI job below also runs weekly, so that drift in a third-party model is caught when the repository has not changed.

name: ai-security-tests
on:
  pull_request:
    paths: [prompts/**, guardrails/**, manifests/**, retrieval/**, threat-model.yaml]
  schedule:
    - cron: "0 3 * * 1"
jobs:
  security:
    runs-on: ubuntu-latest
    permissions: {contents: read, id-token: write}
    steps:
      - uses: actions/checkout@v4
      - name: Policy unit tests
        run: opa test policies/ -v
      - name: Prompt injection regression suite
        run: python3 tools/redteam.py run --suite redteam/injection-v9.yaml --target staging --max-success-rate 0.01
      - name: Data leakage probes
        run: python3 tools/redteam.py run --suite redteam/leakage-v4.yaml --target staging --max-success-rate 0.0
      - name: Agent boundary fuzzing
        run: python3 tools/agent_fuzz.py --manifest manifests/dispute-agent.yaml --assert-no-unapproved-writes
      - name: Publish evidence
        run: python3 tools/evidence.py publish --run-id ${{ github.run_id }} --controls CTRL-GW-007,CTRL-RAG-003,CTRL-AGT-002

The suites are version-controlled attack cases, including the goal-hijacking and prompt-leaking patterns Perez and Ribeiro catalogued (50, Perez & Ribeiro, 2022) and the organisation's own red-team findings. Thresholds are explicit: one per cent success is tolerated for injection, because the agent policy bounds the consequence, while any leakage of another customer's data fails the build. The results are published as evidence against the control identifiers for AI Governance, Chapter 11.

Two obligations shape the programme. Article 55 of the AI Act requires providers of general-purpose AI models with systemic risk to perform model evaluation including documented adversarial testing (1, European Union, 2024); the bank, as deployer, asks for that documentation in procurement and tests the compound system itself. For financial entities, DORA Articles 24 to 27 require a resilience testing programme and, for the entities that the competent authority identifies, threat-led penetration testing of critical or important functions (3, European Union, 2022), for which the CI suites are the continuous complement, not a substitute.

Detection, monitoring, and incident response for AI

Security monitoring uses the telemetry the gateway and agent runtime already produce: blocked inputs rising for one identity, canary tokens in output, refused tool calls, agents hitting their step budget, and cost departing from baseline. Each is a reason to open the trace, not proof of an attack. Build the rules on the OpenTelemetry attributes Chapter 21 uses for quality monitoring, so that security analysts and product teams see the same trace.

Figure 17.2: The incident flow. Detection feeds a triage step that selects a playbook, containment runs in parallel with legal classification, and the evidence pack from the audit log serves both the regulatory reports and the update of the threat model and tests. The table gives the reporting duties.

Regime	Report	Time limit
NIS 2	Early warning	Within 24 hours
AI Act	Serious incident	Within 15 days
DORA	Major incident	Staged reports

Playbooks

Three version-controlled playbooks cover the recurring incidents.

Playbook	First indicators	Containment	Evidence to preserve
Prompt injection	Canary token in output; refused tool call with unusual arguments	Quarantine retrieved documents; roll back prompt or guardrail version; revoke session tokens	Trace with chunk identifiers, tool-call arguments, policy decisions
Model theft or extraction	Systematic query patterns; registry access from an unexpected workload	Block identities; rotate registry credentials; verify artefacts	Gateway and registry logs; verification results
Data leakage	Another customer's data in a response; leakage probe failing	Block the collection; disable the response path; re-run the entitlement audit	Response log; entitlement attributes at retrieval; index version

Table 17.2: Incident playbooks for AI-specific incidents.

Every containment action depends on an earlier design decision, such as versioned prompts, chunk-level source identifiers and short-lived tokens, so the incident flow is a test of the architecture.

Worked example: prompt injection playbook as code

Illustrative example. The dispute assistant's runbook for a suspected indirect injection (PB-AI-001, threat T-014) is kept beside the threat model. Within 30 minutes of a canary or flag alert the on-call analyst scopes the incident from the trace. Within 60 minutes the platform engineer quarantines the affected chunks, revokes sessions and sets a feature flag requiring approval for every agent write, which narrows the service rather than switching it off. In parallel, because the classification clock starts at awareness, the incident manager assesses DORA Article 19, NIS 2 Article 23, GDPR Article 33 and, for a high-risk system, AI Act Article 73, recording the outcome within four hours even when no threshold is met. Finally the team rebuilds the index from signed sources, and the security architect adds a regression case and updates the threat model.

Reporting duties as architectural requirements

European law prescribes who reports what to whom and by when, and the deadlines are short enough that the process must be designed in advance.

Instrument	Who reports	Trigger	Timeline
NIS 2 Article 23	Essential and important entities	Significant incident	Early warning within 24 hours; notification within 72 hours; final report within one month
AI Act Article 73	Providers of high-risk AI systems; deployers inform the provider (Article 26(5))	Serious incident	15 days; 10 days where a person has died; 2 days for widespread infringement or serious and irreversible disruption of critical infrastructure
DORA Article 19	Financial entities	Major ICT-related incident	Initial, intermediate and final reports on the timelines in the regulatory technical standards
Cyber Resilience Act Article 14	Manufacturers of products with digital elements	Actively exploited vulnerability or severe incident	Early warning within 24 hours through the single reporting platform, then notification and a final report

Table 17.3: Reporting duties that an AI incident may trigger.

The deadlines come from NIS 2 Article 23 (4, European Union, 2022), Article 73 of the AI Act (1, European Union, 2024), DORA Article 19 (3, European Union, 2022) and the Cyber Resilience Act (7, European Union, 2024). One incident can fall under several regimes, so the evidence pack is written once and attached to each report; for a public authority, NIS 2 and, where it builds its own high-risk tool, Article 73 apply likewise. In both sectors the 24-hour early warning is the design constraint: if the logs do not link each action to its input, the early warning will state that the cause is unknown.

Security evidence and assurance

Everything in this chapter produces evidence as a by-product; the assurance task is to generate, not hand-maintain, its mapping to the frameworks auditors recognise. ISO/IEC 42001 defines an AI management system whose Annex A controls cover, among other things, the AI system life cycle, data for AI systems and third-party relationships (24, ISO/IEC, 2023). An organisation certified to ISO/IEC 27001 already operates much of what ENISA's foundational layer asks for, since that layer points to ISO/IEC 27002 for the implementation of technical controls, and this chapter's AI-specific controls are the additions a combined audit will test (19, ENISA, 2023).

Worked example: control catalogue entry

Illustrative example. The entry below comes from the bank's control catalogue. It carries the framework mappings, the configuration key that implements the control, and the evidence query that proves it is operating, so the auditor's mapping table is generated from the file the pipeline reads.

apiVersion: ai-architecture.example.org/v1
kind: ControlCatalogue
metadata:
  scope: ai-system/dispute-assistant
  version: 2026.10
controls:
  - id: CTRL-AGT-002
    title: Refunds above threshold require case handler approval
    implemented_by: policies/ai/agents/authz.rego#requires_approval
    threats: [T-014]
    frameworks:
      iso_iec_42001: [A.6 AI system life cycle, A.9 Use of AI systems]
      iso_iec_27001: [A.8.2 Privileged access rights]
    regulation:
      - {instrument: AI_Act, article: "14"}
      - {instrument: DORA, article: "9"}
    evidence:
      query: evidence://audit-log?event=tool_call&tool=disputes.refund&approval=missing
      frequency: daily
      fail_condition: result_count_greater_than_zero

The pipeline resolves the implemented_by path, so a control whose configuration was renamed fails the build, and the fail_condition makes the control falsifiable. The clause references are illustrative and must be checked against the editions the organisation is certified to.

The same catalogue answers procurement. When the bank buys the model, the hosting or an MCP server, its requirements are these controls expressed as contractual obligations: a signed model with SLSA provenance and an ML-BOM, documented adversarial testing, vulnerability handling that meets the Cyber Resilience Act, logging that supports its Article 12 and DORA duties, and the right to audit. AI Governance, Chapter 7 treats the clauses; the point here is that the organisation asks its suppliers for exactly what it demands of itself.

Nordvik Region and Hansa Mutual

The engineering transfers directly from the bank. Nordvik Region would apply the threat model to its citizen-service and staff assistants, whose boundaries are the public website, the guidance index and the supplier's model API. Because it runs no agents with write access, its gateway and playbooks are simpler, and its catalogue maps controls to NIS 2, the GDPR and the AI Act alone.

Hansa Mutual's claims correspondence assistant resembles the bank's closely, and its IT-operations agent adds the agent-runtime boundary. The difference is jurisdiction: the injection playbook must decide within hours which duties an incident triggers in which entity, namely DORA Article 19 for the EU entities (3, European Union, 2022), AI Act Article 73 where Hansa provides a high-risk system and the incident occurred in an EU member state (1, European Union, 2024), and national regimes for the United Kingdom and Swiss entities. Hansa therefore records the affected entity in every gateway log line and a jurisdiction field in the catalogue. Nordvik's challenge is skills and supplier dependence; Hansa's is routing one technical incident into several legal processes.

Summary

Security engineering for AI systems is a discipline of layers, each assuming the one before it has failed, and of linkage, so that every threat names a control, every control a configuration, and every configuration produces evidence. The threat-modelling method extends STRIDE with ATLAS and OWASP, enumerates the AI-specific assets and boundaries, and lives in the repository with review triggers.

The controls follow the data from signed datasets through entitlement-aware retrieval and layered guardrails to least-privilege agents and a registry gate. Red teaming becomes a pipeline stage, the European reporting deadlines constrain the logs, and the control catalogue maps it all to ISO/IEC 42001, ISO/IEC 27001 and the regulations.

Chapters 18 and 19 treat AI as the source of threat, in adversaries' hands and in the organisation's own agents. AI Governance, Chapter 11 binds this chapter's evidence into the manifest from which the Annex IV technical documentation is generated.

Sources

1. Nordqvist, G. (2025). Architecture as Code. The Transformed Architecture, Book 1, published at aac.geon.se. (72, Nordqvist, 2025)
2. European Union Agency for Cybersecurity (ENISA). Multilayer Framework for Good Cybersecurity Practices for AI. June 2023. (19, ENISA, 2023)
3. MITRE Corporation. MITRE ATLAS: Adversarial Threat Landscape for AI Systems. (28, MITRE, n.d.)
4. OWASP Foundation. OWASP Top 10 for LLM Applications 2025. OWASP GenAI Security Project. (27, OWASP, 2025)
5. 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)
6. Sigstore Project. Sigstore: Signing, verification and provenance for software artefacts.. (33, Sigstore, n.d.)
7. Carlini, N., Tramèr, F., Wallace, E., Jagielski, M., Herbert-Voss, A., Lee, K., Roberts, A., Brown, T., Song, D., Erlingsson, Ú., Oprea, A. & Raffel, C. (2021). Extracting Training Data from Large Language Models. Proceedings of the 30th USENIX Security Symposium. (52, Carlini et al., 2021)
8. Greshake, K., Abdelnabi, S., Mishra, S., Endres, C., Holz, T. & Fritz, M. (2023). Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security (AISec '23). (51, Greshake et al., 2023)
9. Open Policy Agent Contributors. Open Policy Agent Documentation. Cloud Native Computing Foundation. (35, Open Policy Agent, n.d.)
10. Open Source Security Foundation. Supply-chain Levels for Software Artifacts (SLSA).. (32, OpenSSF, n.d.)
11. OWASP Foundation. CycloneDX Machine Learning Bill of Materials (ML-BOM).. (31, OWASP, n.d.)
12. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union, 27 December 2022. (4, European Union, 2022)
13. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (3, European Union, 2022)
14. European Parliament and Council of the European Union. Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). Official Journal of the European Union, 20 November 2024. (7, European Union, 2024)
15. Perez, F. & Ribeiro, I. (2022). Ignore Previous Prompt: Attack Techniques For Language Models. NeurIPS 2022 ML Safety Workshop. (50, Perez & Ribeiro, 2022)
16. International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system. Geneva: ISO, December 2023. (24, ISO/IEC, 2023)