Appendix D — Appendix D: Compliance

Throughout the book, chapters that touched regulated data pointed here. Although this appendix is not legal advice, it gives you enough to recognize when you have crossed into regulated territory and what the common obligations are, so you know when to involve someone qualified to provide it.

D.1 A decision flowchart

Before sending data to a model, ask, in order:

flowchart TB
    begin([your data + your use case]) --> d1{"personal data<br/>in the inputs?"}
    d1 -- yes --> dp["data-protection rules apply:<br/>redact before the call, get a DPA,<br/>stricter still for special-category data"]
    d1 -- no --> d2
    dp --> d2{"regulated sector or<br/>high-risk use?<br/>(EU AI Act Annex III)"}
    d2 -- yes --> hr["high-risk obligations:<br/>risk management, human oversight,<br/>tamper-evident records"]
    d2 -- no --> d3
    hr --> d3{"data residency<br/>constraint?"}
    d3 -- yes --> sh["self-host on hardware<br/>you govern (Chapter 4)"]
    d3 -- no --> d4{"provider terms permit?<br/>(no training on inputs,<br/>retention limits, DPA)"}
    d4 -- yes --> ok([proceed, with an audit trail])
    d4 -- no --> sh

Figure D.1: The compliance questions in the order to ask them. Personal data triggers data-protection obligations on the way through, a regulated sector or high-risk use adds the heavy obligations, a residency constraint forces the self-host branch, and even a clean path still depends on the provider’s terms; both hard stops resolve to hardware you govern.

In more detail, the same questions in the same order:

Does the data contain personal information? Names, contact details, identifiers, anything tied to a person. If yes, data-protection rules apply (the General Data Protection Regulation, or GDPR, in the EU, and various US state laws). Consider redaction (below) before the call.
Is it special-category data? Health, financial, biometric, or similar. The threshold is higher here: stricter consent, stricter handling, and in some sectors a contractual or regulatory bar on sending it to third parties.
Is the use case “high-risk” or in a regulated sector? Decisions about employment, credit, housing, essential services (the EU AI Act’s Annex III list). High-risk uses carry the heaviest obligations.
Where is the data allowed to live and travel? Residency rules may forbid sending data outside a region or to a third-party processor. This is the most common reason to self-host (Chapter 4).
Do the provider’s terms permit your use? Training on inputs, retention, and a signed DPA are the checkpoints, and the next section covers how to verify them. When the answer is no and you cannot change providers, the self-host branch applies.

If you answered yes to any of the first four, the system is in scope for regulation, and the design decisions (which model, hosted or self-hosted, what to log) are now compliance decisions.

D.2 The regulatory landscape, briefly

This changes fast, so treat the specifics as of 2026 and verify current law.

EU AI Act. A risk-tiered regime. High-risk systems carry obligations around risk management, data governance, human oversight, and record-keeping. The timeline has shifted: under amendments advanced in 2025 and 2026 (the “Digital Omnibus”), the transparency rules apply from August 2026 while the main high-risk obligations were deferred into 2027 and 2028, so check the current dates, because this sentence may already be out of date. The same deployment can be minimal-risk in one use and high-risk in another, because the tier follows the use.
US state laws. Because the United States has no federal AI statute, the states legislate individually, and the resulting patchwork is itself the compliance burden. Colorado’s AI Act, amended in 2026, narrowed earlier impact-assessment requirements toward transparency and notice on automated decision-making. Texas enacted its own AI law effective 2026, California layers AI-transparency and automated decision-making technology (ADMT) rules on top of its privacy regime (the California Consumer Privacy Act, or CCPA, as amended by the CPRA), and Illinois added employment-AI provisions governing the use of AI in hiring decisions, each drawing its lines differently. Because the law your trade press described last year may not be the law now, check the current statute for the states you operate in.
Sector rules. Health (HIPAA, the Health Insurance Portability and Accountability Act, which governs protected health information, or PHI), finance, and others impose their own requirements on top of general data-protection law.
AI disclosure. A recurring obligation across these regimes is that people who would otherwise assume a person must be told when they are interacting with an AI, which is why a customer-facing chat interface like the one Chapter 25 ships must say on screen that it is AI.
Voluntary frameworks. Beyond what the law compels, risk-management frameworks give you a structure for showing diligence. The NIST AI Risk Management Framework (AI RMF), a voluntary US standard, and ISO/IEC 42001, an AI management-system standard, are the two most cited, and adopting one is increasingly how organizations demonstrate the governance the regulations assume.

D.3 Where your prompt actually goes

The book’s calls run through OpenRouter, and that routing has a compliance dimension worth seeing clearly: OpenRouter forwards each request to a downstream provider, and each provider has its own data-use terms. The questions to ask of any gateway and any provider are the same: does the provider train on inputs by default, is there a zero-data-retention option, and will they sign a data processing agreement (DPA) covering your obligations to your own customers?

OpenRouter exposes provider data policies and lets you restrict routing to providers meeting them, but the responsibility for checking is yours. When the answers are not good enough, or the data cannot leave your control at all, self-hosting (Chapter 4) is the strict answer: the prompt never leaves your machine.

D.4 Two technical practices that recur

PII (personally identifiable information) redaction before the call. Redaction of this kind is imperfect, but it removes the obvious exposure by stripping or masking personal data from text before it reaches a third-party model. For many use cases, the model does not need these personal details to perform the task. A practical pipeline is a regex pass for structured identifiers (emails, card numbers, phone numbers) and a named-entity pass for names and places, replacing each with a placeholder and keeping the mapping on your side.

A tamper-evident audit trail. For regulated uses, log every decision the system made in a form that cannot be quietly altered: the input (redacted), the retrieved context, the model and version, the output, and any human override, with timestamps and retention that meets your obligations (the EU AI Act, for instance, requires record-keeping for high-risk systems). This is the same tracing from Chapter 24, held here to a compliance standard, whereas a debugging standard sufficed there.

D.5 What this means for the book’s systems

Every system we built that touches customer or document data, the ticket triage, the document RAG, the speech transcription, is potentially in scope, and the chapter callouts marked the specific points where. The practical posture is to redact before sending where you can, to prefer self-hosting when residency or special-category rules apply, to keep an audit trail for anything that drives a real decision, and to bring in legal counsel the moment the decision flowchart says you are in scope. Recognizing that moment is the skill this appendix is for.

--- title: "Appendix D: Compliance" --- Throughout the book, chapters that touched regulated data pointed here. Although this appendix is not legal advice, it gives you enough to recognize when you have crossed into regulated territory and what the common obligations are, so you know when to involve someone qualified to provide it. ## A decision flowchart Before sending data to a model, ask, in order: ```{mermaid} %%| echo: false %%| label: fig-compliance-flowchart %%| fig-cap: "The compliance questions in the order to ask them. Personal data triggers data-protection obligations on the way through, a regulated sector or high-risk use adds the heavy obligations, a residency constraint forces the self-host branch, and even a clean path still depends on the provider's terms; both hard stops resolve to hardware you govern." flowchart TB begin([your data + your use case]) --> d1{"personal data in the inputs?"} d1 -- yes --> dp["data-protection rules apply: redact before the call, get a DPA, stricter still for special-category data"] d1 -- no --> d2 dp --> d2{"regulated sector or high-risk use? (EU AI Act Annex III)"} d2 -- yes --> hr["high-risk obligations: risk management, human oversight, tamper-evident records"] d2 -- no --> d3 hr --> d3{"data residency constraint?"} d3 -- yes --> sh["self-host on hardware you govern (Chapter 4)"] d3 -- no --> d4{"provider terms permit? (no training on inputs, retention limits, DPA)"} d4 -- yes --> ok([proceed, with an audit trail]) d4 -- no --> sh ``` In more detail, the same questions in the same order: 1. **Does the data contain personal information?** Names, contact details, identifiers, anything tied to a person. If yes, data-protection rules apply (the General Data Protection Regulation, or GDPR, in the EU, and various US state laws). Consider redaction (below) before the call. 2. **Is it special-category data?** Health, financial, biometric, or similar. The threshold is higher here: stricter consent, stricter handling, and in some sectors a contractual or regulatory bar on sending it to third parties. 3. **Is the use case "high-risk" or in a regulated sector?** Decisions about employment, credit, housing, essential services (the EU AI Act's Annex III list). High-risk uses carry the heaviest obligations. 4. **Where is the data allowed to live and travel?** Residency rules may forbid sending data outside a region or to a third-party processor. This is the most common reason to self-host (Chapter 4). 5. **Do the provider's terms permit your use?** Training on inputs, retention, and a signed DPA are the checkpoints, and the next section covers how to verify them. When the answer is no and you cannot change providers, the self-host branch applies. If you answered yes to any of the first four, the system is in scope for regulation, and the design decisions (which model, hosted or self-hosted, what to log) are now compliance decisions. ## The regulatory landscape, briefly This changes fast, so treat the specifics as of 2026 and verify current law. - **EU AI Act.** A risk-tiered regime. High-risk systems carry obligations around risk management, data governance, human oversight, and record-keeping. The timeline has shifted: under amendments advanced in 2025 and 2026 (the "Digital Omnibus"), the transparency rules apply from August 2026 while the main high-risk obligations were deferred into 2027 and 2028, so check the current dates, because this sentence may already be out of date. The same deployment can be minimal-risk in one use and high-risk in another, because the tier follows the use. - **US state laws.** Because the United States has no federal AI statute, the states legislate individually, and the resulting patchwork is itself the compliance burden. Colorado's AI Act, amended in 2026, narrowed earlier impact-assessment requirements toward transparency and notice on automated decision-making. Texas enacted its own AI law effective 2026, California layers AI-transparency and automated decision-making technology (ADMT) rules on top of its privacy regime (the California Consumer Privacy Act, or CCPA, as amended by the CPRA), and Illinois added employment-AI provisions governing the use of AI in hiring decisions, each drawing its lines differently. Because the law your trade press described last year may not be the law now, check the current statute for the states you operate in. - **Sector rules.** Health (HIPAA, the Health Insurance Portability and Accountability Act, which governs protected health information, or PHI), finance, and others impose their own requirements on top of general data-protection law. - **AI disclosure.** A recurring obligation across these regimes is that people who would otherwise assume a person must be told when they are interacting with an AI, which is why a customer-facing chat interface like the one Chapter 25 ships must say on screen that it is AI. - **Voluntary frameworks.** Beyond what the law compels, risk-management frameworks give you a structure for showing diligence. The NIST AI Risk Management Framework (AI RMF), a voluntary US standard, and ISO/IEC 42001, an AI management-system standard, are the two most cited, and adopting one is increasingly how organizations demonstrate the governance the regulations assume. ## Where your prompt actually goes The book's calls run through OpenRouter, and that routing has a compliance dimension worth seeing clearly: OpenRouter forwards each request to a downstream provider, and each provider has its own data-use terms. The questions to ask of any gateway and any provider are the same: does the provider train on inputs by default, is there a zero-data-retention option, and will they sign a data processing agreement (DPA) covering your obligations to your own customers? OpenRouter exposes provider data policies and lets you restrict routing to providers meeting them, but the responsibility for checking is yours. When the answers are not good enough, or the data cannot leave your control at all, self-hosting (Chapter 4) is the strict answer: the prompt never leaves your machine. ## Two technical practices that recur **PII (personally identifiable information) redaction before the call.** Redaction of this kind is imperfect, but it removes the obvious exposure by stripping or masking personal data from text before it reaches a third-party model. For many use cases, the model does not need these personal details to perform the task. A practical pipeline is a regex pass for structured identifiers (emails, card numbers, phone numbers) and a named-entity pass for names and places, replacing each with a placeholder and keeping the mapping on your side. **A tamper-evident audit trail.** For regulated uses, log every decision the system made in a form that cannot be quietly altered: the input (redacted), the retrieved context, the model and version, the output, and any human override, with timestamps and retention that meets your obligations (the EU AI Act, for instance, requires record-keeping for high-risk systems). This is the same tracing from Chapter 24, held here to a compliance standard, whereas a debugging standard sufficed there. ## What this means for the book's systems Every system we built that touches customer or document data, the ticket triage, the document RAG, the speech transcription, is potentially in scope, and the chapter callouts marked the specific points where. The practical posture is to redact before sending where you can, to prefer self-hosting when residency or special-category rules apply, to keep an audit trail for anything that drives a real decision, and to bring in legal counsel the moment the decision flowchart says you are in scope. Recognizing that moment is the skill this appendix is for.