SbD-ToE 4 AI Act: Implementation Playbook

Overview

This playbook maps AI Act requirements (Regulation (EU) 2024/1689) to practical SbD-ToE actions, focusing on the technical obligations for high-risk AI systems and general-purpose AI (GPAI) models.

The Manual's response to each obligation (covered, declared gap or out of scope) is in “What this Manual covers and what stays out”.

Principle: SbD-ToE covers cybersecurity (Art. 15), record-keeping (Art. 12/19), human oversight (Art. 14), the transparency of Art. 50, post-market monitoring (Art. 72) and serious incidents (Art. 73). Accuracy and robustness are pending the AISVS/SAIF round of AppSec Core. Out of scope, with a reason: risk management (Art. 9), governance of training data (Art. 10), quality management (Art. 17), the specifics of biometric identification, legal qualification (risk classification, roles) and conformity assessment. In these, the Manual provides evidence to the data science, product, legal and compliance teams.

Structure: Each section shows:

• AI Act requirement (article)
• Applicable SbD-ToE chapter/addon
• What to do (concrete action)
• Regulatory evidence

📚 Supporting Resources: For practical templates and implementation examples, see Example Playbook, with reusable toolchains, KPIs, RACI and incident reports for the AI Act and other frameworks.

---

Step 0: Determine role and risk category (prior requirement)

Before any technical action, the legal framing must be established - compliance/legal work, not AppSec work, but it conditions the whole playbook:

1. What is the role? Provider, deployer, importer or distributor (AI Act, Article 3, points (3), (4), (6) and (7)). The bulk of the technical obligations falls on the provider of high-risk AI systems (Article 16).
2. What is the risk category?
   • Unacceptable (Art. 5) → prohibited; no technical playbook can legitimise it.
   • High-risk (Art. 6, Annexes I/III) → most of this playbook applies.
   • Certain AI systems (Art. 50 — direct interaction with people, synthetic content, emotion recognition or biometric categorisation, deep fakes) → transparency obligations, which add to those of Chapter III when the system is also high-risk (Article 50(6)).
   • Other AI systems → none of the Chapter III requirements; Art. 4 (AI literacy), addressed to providers and deployers of AI systems, nevertheless applies.
3. Is it a GPAI model? If so, Art. 53 (with the paragraph 2 exception for models released under a free and open-source licence without systemic risk) and Art. 55 (systemic risk) apply - see Phase 7.

⚠️ Outside the scope of SbD-ToE: risk classification and the qualification of roles are legal determinations. The outcome is declared per application as context CTX-AIA-RE (or with the ART50 grade only, for systems covered only by Article 50), with the legal qualification attached, and the floor entries of the context apply at any level L1–L3 (see Applicable requirements — When it applies).

---

Quick Map: AI Act Art. → SbD-ToE

✏️ Refresh 2026-09-27. Map aligned with the AI Act coverage matrix and with context CTX-AIA-RE (floor entries and requirements added by the regime), on top of the agentic layer — REQ-AGN-* (Ch. 02), ARC-015 (Ch. 04), DEP-012..014 (Ch. 05), OPS-012..014 (Ch. 12), Policy 38 (mandates), Policy 39 (AI BOM).

AI Act Article	Requirement	SbD-ToE Chapter	Main Action
4	AI literacy (measures to support its development — wording of Regulation (EU) 2026/1744)	Ch. 13 + Policy 37 §11	Training track per role; mandatory with A1+ agents (the Manual's choice)
5(1a)	Safeguards for realistic content generators	THR-008, ARC-014 (floor entries CTX-AIA-RE-P09, P10; ART50 grade)	Threat model of the generated content + red-team + input and output filters
9	Risk management	Ch. 01, Ch. 02 §A0–A4, Ch. 03 agentic playbook	Out of scope (programme decision): management system of the organisation; the L1–L3 classification, the A0–A4 level and the threat model with ATLAS serve as evidence
10	Data and data governance	Ch. 05 (DEP-011..014) + Policy 39	Out of scope (programme decision): governance of training data; AI BOM (CycloneDX 1.6 ml-bom), pinning and approved vendors provide evidence of provenance
11 / Annex IV	Technical documentation	Ch. 02, Ch. 04, Policy 38 (mandate)	Annex IV index (evidence map) + model card + mandate + AI BOM
12 / 19	Logging and retention	Ch. 12 + OPS-011..014 + Ch. 12 US-13	Inference logs + audit per tool invocation
13	Transparency and provision of information to deployers	Ch. 04 + Policy 38 (mandate)	Mandate as the source of capabilities/limitations/oversight; drafting of the instructions by the provider
14 ⚡	Human oversight	ARC-014 (floor CTX-AIA-RE-P08) + Ch. 02 §A0–A4 + ARC-015 + Policy 38	Oversight interface in any high-risk system; kill-switch, intent declaration and OOB approval for agents
15	Accuracy, robustness and cybersecurity	Ch. 03 playbook, ARC-014/015, Ch. 10 §C5 (eval suites), OPS-014 (jailbreak)	Continuous eval suites + threat library + off-policy detection; accuracy and robustness pending the AISVS/SAIF round
17	QMS	Ch. 07, Ch. 14, Policy 38 (mandate lifecycle), Policy 39 (AI BOM lifecycle)	Out of scope (programme decision); the gates and the cycles of Policies 38/39 serve as evidence
25	Responsibilities along the AI value chain	DEP-013/014 + Policy 39 + Ch. 14 US-21	Pinning + approved AI service vendors + clauses
26	Obligations of deployers	Policy 38 (mandate) + Ch. 00 (composite function) + Ch. 12 US-13	Deployer mandate + qualified oversight + logs under control
43(4)	Substantial modification	ARC-009 (floor CTX-AIA-RE-P11)	Classify and record each change
50	Transparency	CTX-AIA-RE-R01, R02 (ART50 grade)	Inform; mark synthetic content
53 / 55	GPAI	Ch. 03 playbook + Ch. 05 (DEP-011..014) + Ch. 10 §C5 + OPS-014 + Ch. 14 US-21	AI red teaming via eval suites + protection of weights + Art. 53/55 clauses
72	Post-market monitoring	CTX-AIA-RE-R04 + Ch. 12 + OPS-011..014 + Ch. 12 US-13	Plan per system + agentic telemetry + drift detection
73	Serious incidents	Ch. 12 + OPS-014 + Policy 16 §11.4 + Policy 30 §9.3 + Policy 39 §7	Runbook aligned with Policy 32 §6 + agentic incident classes + upstream IR
86	Explanation to affected persons	CTX-AIA-RE-R03 + OPS-011	Record the outcome and the elements of each decision

---

How to Implement (Logical Order)

Phase 1: AI governance (M0–M3)

The quality management system of Art. 17 is outside the Manual's scope; the steps below produce evidence that feeds it.

1. Define AI governance

   • Members: CISO, AI/ML lead, GRC, legal, product
   • Evidence: Minutes, approved AI policy
   • Reference: Ch. 14 - Governance and Contracting

2. Map SbD-ToE gates as evidence for the organisation's QMS (Art. 17)

   • Development procedures → Ch. 06, Ch. 07
   • Quality control and validation → Ch. 10, Ch. 11
   • Reuse ISO/IEC 42001 if it already exists
   • 📄 Template: RACI and Governance

3. Define the AI RACI

   • Who approves a model release, who signs off exceptions, who reports incidents (Art. 73)

---

Phase 2: Classification and threat model (M2–M5)

AI Act Art. 6 - Declaration of context CTX-AIA-RE (the risk management system of Art. 9 is out of scope; the threat model serves as evidence for it)

1. Inventory AI systems

   • Purpose, data processed, model(s), inference service, dependencies
   • Reference: Ch. 01 - Application Classification

2. Classify criticality (L1–L3) and declare the regulatory context

   • Declare context CTX-AIA-RE on the application (or the ART50 grade only); the L1–L3 level is decided by the criteria of Ch. 01, and the floor entries of the context apply at any level
   • L3 is the Manual's risk classification; it is not the same as a high-risk AI system within the meaning of the AI Act (Article 6)

3. Threat model extended to the adversarial vector

   • Base: STRIDE / MITRE ATT&CK (Ch. 03)
   • Extension: MITRE ATLAS and OWASP ML/LLM Top 10
   • Cover (Article 15(5)): data poisoning, model poisoning, adversarial examples or model evasion (adversarial examples / model evasion), confidentiality attacks, model flaws
   • Evidence: Documented threat model, residual risk and measures

---

Phase 3: Data and documentation (M3–M6)

AI Act Art. 10, 11, Annex IV

1. Provenance and integrity of data and models (AI-BOM)

   • Extend the Ch. 05 inventory to datasets, checkpoints and models
   • Integrity verification (mitigates poisoning and compromised models from public repositories)

2. AI data governance (out of scope)

   • Representativeness, bias detection, statistical quality (Art. 10)
   • Datasheets for datasets / data cards
   • Out of scope (programme decision): SbD-ToE ensures integrity and provenance; the governance of training data and bias are data science work

3. Technical documentation (Annex IV)

   • Build an "Annex IV index" pointing to SbD-ToE artefacts (architecture, requirements, threat model, pipeline/test evidence) + model card, starting from the evidence map on the generated page
   • Reference: Ch. 02, Ch. 04

---

Phase 4: Technical security and robustness (M5–M10) — CORE

AI Act Art. 15 - Accuracy, robustness and cybersecurity

4.1 Defensive architecture

• What: Trust boundaries (including the agentic boundary — ARC-014), input validation, isolation of the inference service, surface reduction. Where there are AI agents with tool-use, apply ARC-015 (agent as an isolated principal): dedicated identity via OIDC, minimal scope per tool, intent declaration, OOB approval, exercised kill-switch.
• Reference: Ch. 04 — ARC-014/ARC-015, Ch. 09 — Containers/Runtime

4.2 Threat modelling + eval suites + red teaming (CRITICAL FOR Art. 15)

• What: The test catalogue now includes continuous eval suites (Ch. 10 §C5) — prompt/skill regression, abuse corpus (LLM01-2025 prompt injection, LLM06-2025 excessive agency), drift detection, A/B testing. For systems with A2+ agents, the suite is mandatory; for A4 in GPAI with systemic risk, monthly cadence (the Manual's choice).
• Threat model: Ch. 03 agentic playbook with the MITRE ATLAS threat library already included — canonical DFD (5 participants / 4 trust boundaries) + threats per boundary (AML.T0051.001, T0086, T0101, T0109, T0110, LLM01/06/07).
• Reference: Ch. 10 §C5 — Eval suites, Policy 19 §7
• 📄 Template: Toolchain Options

4.3 Secure ML pipeline + agents as principals

• What: Security gates in the pipeline (SAST/SCA, secrets, artefact integrity) + AI agents operating the pipeline with ephemeral OIDC workload identity, per-tool scope, audit per tool invocation (Ch. 07 US-19).
• Reference: Ch. 07 — US-19, Ch. 08 — IaC, Policy 18 §9

4.4 Accuracy and robustness (declared gap)

• Pending the AISVS/SAIF round of AppSec Core. Until then, record the metrics obtained in the eval suites (Ch. 10 §C5) and in operational telemetry (Ch. 12 US-13) as evidence, without presenting them as compliance.

4.5 Human oversight (Art. 14)

• What: In any high-risk system, with or without agents, an oversight interface in accordance with ARC-014 with the floor CTX-AIA-RE-P08: understand the capabilities and limitations of the system, detect anomalies, interpret the output, decide not to use it or override it and stop the system; those who oversee are warned about automation bias. For agents, REQ-AGN-001..004 and ARC-015 (kill-switch, intent declaration, OOB approval).
• Out of scope: verification by two persons for biometric identification (Article 14(5)).
• Reference: Applicable requirements — Floor, Ch. 02 §A0–A4

4.6 Safeguards for generated content (Article 5(1a))

• What: In systems that generate or manipulate realistic images, video or audio (ART50 grade), the threat model covers the reasonably foreseeable misuse of the generated content, assessed with red-team and content-safety tests (THR-008, floor CTX-AIA-RE-P09), and there are content-safety filters and classifiers on input and output (ARC-014, floor CTX-AIA-RE-P10).
• Reference: Applicable requirements — Floor

---

Phase 5: Logging and post-market monitoring (M8–M12)

AI Act Art. 12, 19, 72

5.1 Inference logging + audit per tool invocation

• What: Log schema extended with inference metadata (model id/version, relevant features, decision and confidence, correlation id) + audit per tool invocation (OPS-012) where there are AI agents: timestamp, agent_id, session_id, mandate_ref, autonomy_level, tool, tool_version, args (PII redacted), intent_event_ref, outcome, external_effect.
• Retention: A period appropriate to the intended purpose of the system, of at least six months (AI Act, Articles 19(1) and 26(6)); in SbD-ToE, 1 year at L2 and 2 years at L3 (the Manual's choice; Policy 29 §7); retention limited by the GDPR where personal data are involved; immutability.
• Reference: Ch. 12 — OPS-011..014 + Ch. 12 US-13

5.2 Post-market monitoring plan (Art. 72)

• What: Monitoring plan per system (CTX-AIA-RE-R04), when the organisation is the provider, integrated into the technical documentation (Annex IV, point 9), with the production signals (OPS-011) and those from deployers, the performance criteria, the cadence and owner of the analysis. Technical basis: dashboards for performance, model drift, token budget (OPS-013) and detection of jailbreak / off-policy actions (OPS-014). For systems with agents at A2+, agentic telemetry (Ch. 12 US-13) is the evidential basis.
• Triggers: Degradation, drift, budget overrun or off-policy set off rollback, reclassification, review of the threat model or notification of a serious incident.
• Reference: Ch. 12 US-13, Policy 30 §9

5.3 Transparency and explanation (Art. 50, Art. 86)

• What: Inform people that they are interacting with an AI system and disclose deep fakes (CTX-AIA-RE-R01); mark synthetic content in a machine-readable format (CTX-AIA-RE-R02); both verified in testing, under the ART50 grade. When an Annex III system supports decisions about people, inform them and record, per decision, the outcome and the main elements that determined it (CTX-AIA-RE-R03, OPS-011).
• Out of scope: the disclosure of AI-generated text published on matters of public interest (Article 50(4), second subparagraph).
• Reference: Applicable requirements — Requirements added by the regime

5.4 Substantial modification (Article 43(4))

• What: Each change is classified as pre-determined or as a substantial modification, and the classification is recorded; a substantial modification is flagged for a new conformity assessment (ARC-009, floor CTX-AIA-RE-P11).
• Reference: Applicable requirements — Floor

---

Phase 6: Serious incidents (M10–M12)

AI Act Art. 73

• What: Align the runbook and the incident schema with Policy 32 (§4.1 and §6), which sets the definition and time limits of Art. 73 (immediately after establishing the causal link and, at the latest, ≤15 days as a rule; ≤10 days in the event of death; ≤2 days in the event of a widespread infringement or of a serious incident under Article 3, point (49)(b); time limits counted from awareness by the provider or the deployer; an incomplete initial report is allowed). Agentic-specific incident classes (Policy 16 §11.4): off-policy action, intent-action divergence, successful prompt injection, kill-switch failure, credential exposure. Upstream incidents (Policy 39 §7): rug pull, dataset poisoning, MCP tool poisoning, provider outage. Add to the runbook the prior informing of the authority before any change to the system that affects the analysis of causes (Article 73(6); partial gap of the Manual).
• How: SIEM/ITSM exporters → notification ready for the market surveillance authority. OPS-014 feeds the IR flow (Ch. 12 US-04).
• Reference: Ch. 12, Ch. 14, Policy 16 §11.4, Policy 30 §9.3, Policy 39 §7
• 📄 Template: Incident Report

---

Phase 7: GPAI (where applicable)

AI Act Art. 53, 55

7.1 Model protection (Art. 55 — cybersecurity)

• What: Treat weights, checkpoints, datasets, MCP tools and embedded prompts as critical supply chain assets: provenance, integrity, pinning (DEP-013), approved AI service vendors (DEP-014), AI BOM per release (DEP-012), access control.
• Reference: Ch. 05 — DEP-011..014, Ch. 04 ARC-015, Policy 39

7.2 Continuous AI red teaming (Art. 55)

• What: A continuous adversarial evaluation programme made concrete in Ch. 10 §C5 — eval suites: prompt/skill regression, abuse corpus (LLM01-2025 prompt injection, LLM06-2025 excessive agency), drift detection, A/B. For agents at level A4 (internal scale of SbD-ToE) — and, regardless of level, when the organisation is a provider of GPAI with systemic risk (Art. 51) —, a monthly cadence (the Manual's choice) of kill-switch drills and updates to the detection corpus OPS-014.
• Reference: Ch. 10 §C5, Policy 19 §7

7.3 Hardening of physical and logical infrastructure (Art. 55)

• Reference: Ch. 08 — IaC, Ch. 09 — Containers/Runtime, Ch. 04 ARC-015

7.4 Declared contractual compliance (Article 53 and, where there is systemic risk, Article 55 — AI service vendors)

• What: When the organisation consumes GPAI from an AI service vendor, the contract declares compliance with Art. 53 (technical documentation, summary of training data, copyright policy) and — where applicable — Art. 55 (model evaluation with documented adversarial testing, assessment and mitigation of systemic risks, reporting of serious incidents to the AI Office, cybersecurity of the model and of the physical infrastructure).
• Reference: Ch. 14 US-21, Policy 33 §10

7.5 GPAI documentation, copyright and data summary (delegated)

• The documentation of Annexes XI and XII is drafted by the model provider; the AI BOM and the archived eval suites provide evidence for it. The copyright policy and the summary of the training content (Article 53(1)(c) and (d)) are out of scope: they belong to the legal plane. This applies when the organisation is a provider of general-purpose AI models.

---

Technical Alignment Checklist (AI Act)

The list below makes it possible to validate the technical alignment of the SbD-ToE programme with the requirements of the AI Act — it does not issue the legal compliance judgement. Periodic review is recommended:

• Framing: Role and risk category determined (legal); context CTX-AIA-RE (or ART50 grade) declared on the application
• Literacy (Art. 4): Training track activated in accordance with Policy 37 §11 (mandatory with A1+ agents — the Manual's choice)
• AI governance: AI policy approved; gates mapped as evidence; Policy 38 (mandates) + Policy 39 (AI BOM lifecycle) operational
• Classification: AI systems inventoried and classified (L1–L3); levels A0–A4 declared in the mandates
• Threat model: Threat model with the agentic playbook carried out; MITRE ATLAS + OWASP LLM Top 10 threat library already included
• Oversight (Art. 14): oversight interface (ARC-014, floor P08) validated in all high-risk systems; REQ-AGN-001..004 operational; ARC-015 validated; kill-switch exercised with recorded cadence
• Data and model provenance: AI BOM CycloneDX 1.6 ml-bom generated per build (DEP-012); approved AI service vendors (DEP-014)
• Documentation (Art. 11/Annex IV): Annex IV index + model card + mandate + AI BOM
• Cybersecurity (Art. 15): Continuous eval suites operational (Ch. 10 §C5); off-policy / jailbreak detection (OPS-014)
• Supply chain (Art. 25): Pinning (DEP-013); list of approved AI service vendors (DEP-014); contractual clauses (Ch. 14 US-21)
• Deployer (Art. 26): Deployer mandate documented when the organisation uses the AI system under its own authority (Article 3, point (4)) without being its provider
• Logging (Art. 12/19): Inference logs + audit per tool invocation (OPS-012) with retention and immutability
• Monitoring (Art. 72): Plan per system (CTX-AIA-RE-R04) + agentic telemetry + dashboards for drift, budget, off-policy
• Transparency and explanation (Art. 50, Art. 86): R01 and R02 verified in testing; R03 applied when an Annex III system supports decisions about people
• Content safeguards (Article 5(1a)): floor entries P09 and P10 applied in generators of realistic images, video or audio
• Substantial modification (Article 43(4)): changes classified and recorded (ARC-009, floor P11)
• Incidents (Art. 73): Runbook aligned with Policy 32 §6 + agentic classes (Policy 16 §11.4) + upstream IR (Policy 39 §7)
• GPAI (Article 53; Article 55 if the model has systemic risk): AI BOM + eval suites + kill-switch exercised monthly (the Manual's cadence) + declared clauses
• Evidence: Data room with technical documentation, mandates, AI BOMs, eval reports, audit trails, telemetry

---

What Each SbD-ToE Chapter Covers (Quick Reference)

✏️ Refresh 2026-09-27. Table aligned with the coverage matrix: Arts. 9, 10 and 17 are outside the Manual's scope and appear marked “(evidence)”, because the chapters serve them only as evidence.

Chapter	AI Act Articles	What It Does
Ch. 00 — Fundamentals	Art. 4, 26	Canonical roles + composite function "AI Reliability Engineer"
Ch. 01	Art. 6 (context CTX-AIA-RE), 9 (evidence)	Criticality classification (L1–L3)
Ch. 02 §A0–A4 + REQ-AGN	Art. 9 (evidence), 14	Autonomy level model A0–A4 + mandate + intent declaration
Ch. 03 agentic playbook	Art. 5, 9 (evidence), 15	Threat modelling with MITRE ATLAS + OWASP LLM Top 10 2025
Ch. 04 — ARC-014/ARC-015	Art. 14, 15, 43 (paragraph 4)	Defensive architecture + agent as an isolated principal + kill-switch
Ch. 05 — DEP-011..014	Art. 10 (evidence), 15, 25, 55	AI BOM + pinning + approved AI service vendors
Ch. 06 — Prompts as code	Art. 15, 17 (evidence)	Versioning + review of system prompts, skill files, agent files
Ch. 07 US-19	Art. 15, 17 (evidence)	Secure pipeline + AI agents as principals with OIDC + audit
Ch. 09	Art. 15, 55	Runtime/inference hardening
Ch. 10 §C5	Art. 15, 55	Continuous eval suites (regression, abuse, drift, A/B)
Ch. 11	Art. 17 (evidence)	Release gate, pre-production validation
Ch. 12 US-13 + OPS-011..014	Art. 12, 19, 72, 73, 86	Agentic telemetry + audit per tool + jailbreak detection
Ch. 13 (training)	Art. 4	AI literacy per role
Ch. 14 US-21	Art. 17 (evidence), 25, 26, 73	Governance + contracting of AI service vendors + escalation

---

Simple Metric: Am I Aligned?

These questions are a technical self-diagnosis — answering them does not issue a judgement of legal compliance. A YES to all of them indicates that the technical core is aligned:

1. Framing: Do I know my role and the risk category?
2. Oversight (Art. 14): Do I have a human oversight interface in each high-risk system?
3. Cybersecurity (Art. 15): Do I have a threat model that covers the adversarial vector (ATLAS), and do I carry out AI red teaming?
4. Chain: Do I have provenance and integrity of datasets and models?
5. Logging: Do I record inference events with adequate retention?
6. Monitoring: Do I have a post-market monitoring plan per system (R04) with drift detection?
7. Incidents: Can I report a serious incident within the Art. 73 deadlines?
8. Transparency (Art. 50): Do I inform people and mark synthetic content?
9. Documentation: Do I have an Annex IV index + model card?
10. Evidence: Can I demonstrate all of this in an audit?

≥8/10 → Good technical maturity with respect to the AI Act (technical maturity, not legal compliance). <6 → Prioritise Art. 15 (cybersecurity), logging (Art. 12) and oversight (Art. 14).

⚠️ Note: this metric covers the technical core. Full compliance also requires what is outside the Manual's scope — risk management (Art. 9), governance of training data (Art. 10), quality management (Art. 17), conformity assessment, EU declaration of conformity, CE marking and registration (Art. 43, 47–49) — and accuracy and robustness, pending the AISVS/SAIF round of AppSec Core.

---

Critical Note: Exception Management under the AI Act

The AI Act requires high-risk AI systems to comply with the requirements of Chapter III, Section 2 (Article 8(1)). Exceptions (deviations) must be formal and audited, with a documentary trail and appropriate approval. An internal exception does not change the legal obligation under the AI Act — it merely documents an accepted technical risk for the evidence dossier; the legal obligation remains.

What characterises an exception in SbD-ToE/AI Act:

• Formal deviation from a requirement (e.g. adversarial vector mitigated by a compensating measure while retraining is prepared)
• Formal approval, justification, TTL (Time-To-Live), remediation plan

Who approves (by criticality level):

• L1 (low risk): Tech Lead / AppSec Engineer
• L2 (medium risk): CISO / AI lead
• L3 (high risk on the Manual's scale, which is not the same as high-risk under the AI Act): AI governance + management (accountable)

Regulatory implication:

• Exceptions without formal approval undermine the technical evidence presented to the authority
• Some situations can never be made exceptions - first and foremost, any use that falls under the prohibited practices of Art. 5
• An audited trail is mandatory to demonstrate control to the authority

Reference: Ch. 02 - Security Requirements (exceptions addon) and Ch. 14 - Governance (formalised exceptions).

---

Next Steps

1. Legal framing: Determine role and risk category (legal/compliance) and declare context CTX-AIA-RE on the application
2. Current technical audit: Check Ch. 01–Ch. 14 against the technical requirements of the AI Act
3. Define the roadmap: Sequence the phases according to context and risk category
4. Coordinate with the domain teams: Agree with data science, product and legal on what is outside the Manual's scope
5. Implement and validate: Iterate and demonstrate the technical evidence in an audit

Full documentation: see SbD-ToE chapters 01–14 for technical and operational detail.

---

References

• SbD-ToE Manual: Chapters 01–14 (technical detail by domain)
• Cross-Check AI Act: Full normative analysis
• AI Act: Regulation (EU) 2024/1689
• Reference Frameworks: ISO/IEC 42001, ISO/IEC 23894, NIST AI RMF 1.0, MITRE ATLAS, OWASP ML Security Top 10, OWASP Top 10 for LLM Applications

---

Version: 1.1 Date: September 2026 Note: This playbook complements the AI Act normative analysis with practical implementation.