Lesson 13. Compliance by Design

A retail bank in Dublin built a mortgage-enquiry assistant for its public website. The build was clean: retrieval over the product sheets, a judge validated against human labels, a cost model the CFO had initialled. Two weeks before launch the bank's counsel sent three questions. Does the visitor know they are talking to software? Does the assistant's "you would probably qualify" line influence a creditworthiness decision? Where are the transcripts stored, for how long, and under which contract? Nobody had an answer that pointed at a file. The chat widget gained a disclosure banner, the gateway gained an audit log with a retention rule, the "probably qualify" feature was cut, and the system card was rewritten twice. Launch slipped a quarter. The team learned the three questions by being asked them, which is the expensive way. Decide now: which of those three questions could have been answered by a design choice made in week one, and what single document would have held the answer?

All three, and the document is a compliance annex. This lesson's deliverable is 10-compliance-annex.md in your Dossier. A compliance annex for your case: each applicable obligation mapped to a design element and the evidence it produces, with the date it applies. It opens the Run stage of Frame / Decide / Prove / Run: the file that lets the system go live in a jurisdiction and stay live when the next date arrives.

What is actually going on

An obligation is a sentence in a law, a standard or a contract. It does nothing to a system until three translations happen. The sentence becomes a control, a property the system must have ("the user is told they are talking to an AI"). The control lives in a design element, a component, a configuration or a document ("the first-turn message and the widget banner, set by a config flag that defaults on"). The design element produces evidence, something a reviewer can inspect without asking you ("a screenshot of the banner, the config hash, the release that shipped it"). The Dublin bank had obligations and a system and nothing in between, so counsel had to do the three translations under deadline, backwards, from a finished build.

The frameworks you will be asked about all share this shape and differ in vocabulary. The EU AI Act supplies obligations by article, keyed to a risk tier and to your role as provider or deployer. NIST's AI Risk Management Framework organises controls into four functions (Govern, Map, Measure, Manage) and its generative-AI profile adds a list of risks and suggested actions. ISO/IEC 42001 is a management system: it makes the evidence repeatable, year after year, and a certifier can attest to that. GDPR supplies the data obligations. Sector rules add overlays. Every one of them can be written as rows of the same three-column table, and that table is the annex.

Two properties of obligations make the annex different from a security checklist. Obligations have dates: the same article can be a future concern in June and a live duty in August, and a regulator moved a whole set of dates in 2026. Obligations have roles: the model vendor is a provider of a general-purpose model with its own duties, and your client can be a provider of a system, a deployer of one, or both. The annex therefore carries a date and an owner on every row, and the owner is a person at the client, not you.

The picture below shows three obligations passing through the three translations. Read each row left to right and notice that the evidence column never contains a promise, only an inspectable thing.

Each middle-column element is a small component when planned and a rebuild when discovered.

The rule and its condition

Map every applicable obligation to a design element and the evidence it produces before the build. Use the full high-risk control set when the use case is listed in Annex III of the AI Act, or when the client's supervisor treats the system as a model under validation; otherwise ship the baseline set (disclosure, data governance, audit logging, versioning, human override, a system card) and record the classification decision with a revisit date. The baseline set contains the cheap parts of the high-risk set on purpose, so that a reclassification changes paperwork rather than architecture.

The dates in that last row are the second half of the rule. The EU AI Act's prohibited practices have applied since 2 Feb 2025, general-purpose model obligations since 2 Aug 2025, and Article 50 transparency duties with AI Office enforcement have applied since 2 Aug 2026 (implementation timeline, observed 2026-09-27). The Digital Omnibus on AI, adopted by the European Parliament on 16 Jun 2026 and the Council on 29 Jun 2026, deferred the substantive high-risk obligations: Annex III standalone systems moved from 2 Aug 2026 to 2 Dec 2027 and Annex I product-embedded systems from 2 Aug 2027 to 2 Aug 2028 (Gibson Dunn briefing, observed 2026-09-27). Any annex written before July 2026 has the wrong dates in it, which is exactly why the annex carries the date it was checked.

The timeline below puts those dates next to the two US state laws and the two standards clients most often name. Look for the one date that appears twice.

The repeated date is 2 Aug 2026: EU chatbot disclosure and California's SB 942 disclosure duties (operative that day for providers above a monthly-user threshold, after AB 853 was signed on 13 Oct 2025) land together. Colorado's original AI Act never reached its delayed 30 Jun 2026 date: Governor Polis signed SB 189 on 14 May 2026, repealing and replacing it with a narrower disclosure-and-transparency law that drops the original's duty-of-care and impact-assessment obligations, operative 1 Jan 2027 (Seyfarth Shaw briefing, observed 2026-09-27). ISO/IEC 42001 was published in Dec 2023 (ISO, observed 2026-09-27) and NIST AI 600-1 in Jul 2024 (NIST, observed 2026-09-27).

The frameworks, one paragraph each

EU AI Act. Four tiers (unacceptable, high, limited, minimal) plus separate duties for providers of general-purpose models, which your vendor carries and passes through as documentation you can cite. Article 50 covers the limited tier: tell people when they interact with an AI, label synthetic media. Fines reach €35M or 7% of global turnover for prohibited practices, €15M or 3% for high-risk and transparency breaches, and €7.5M or 1% for misleading authorities, with SMEs paying the lower figure (penalties summary, observed 2026-09-27). The design consequence of the tier table is that classification is a written memo in the annex, never a sentence in a meeting.

NIST AI RMF and AI 600-1. The framework (Jan 2023) is voluntary in the US and is the de facto template clients ask you to map to; its four functions are Govern, Map, Measure, Manage (NIST AI RMF core, observed 2026-09-27). The generative-AI profile (Jul 2024) names twelve risk categories, among them confabulation, data privacy, information integrity, information security and value-chain integration, with over two hundred suggested actions (NIST AI 600-1, observed 2026-09-27). Use it as a checklist generator: each risk category you cannot map to a control in the Dossier is a gap.

ISO/IEC 42001 and 23894. 42001 is the certifiable AI management-system standard, structured in clauses that mirror ISO 27001, so a client with an information-security programme can extend it rather than start one; AWS and Microsoft publish 42001 attestations that procurement teams will ask you to collect (AWS 42001 FAQ, observed 2026-09-27). 23894 is risk-management guidance built on ISO 31000. Neither tells you what to build; they tell you how to prove you keep doing it.

GDPR, lawful basis and residency. Personal data in prompts or grounding data needs a lawful basis, minimisation and a retention rule aligned with the vendor's. The EDPB's Opinion 28/2024 (17 Dec 2024) accepts legitimate interest as a possible basis for developing and deploying AI models under the usual three-part test, and warns that unlawfully processed training data can taint a deployment unless the model is genuinely anonymised (EDPB opinion, observed 2026-09-27). A DPIA is due when the processing is novel or the data is sensitive, which describes most claim, patient and applicant workloads. Residency is a topology decision (L09) the annex cites rather than repeats.

Vendor data terms. These are design inputs with a date on them. The table below is the comparison as observed on 2026-09-27 from the providers' published terms and the reporting cited beneath it; every cell moves, so the annex records the observation date and the contract clause, not the table.

Sources for the table: Anthropic pricing (fetched 2026-09-27, for the 1.1x geo multiplier and the 10% regional premium), Anthropic Covered Models list (now four models: Fable 5, Fable 5.1, Mythos 5, Mythos 5.1, all excluded from ZDR), OpenAI enterprise privacy and OpenAI data residency, Vertex AI data governance, and the report that ZDR must be verified per organisation because it can be silently absent and Covered Models are excluded from it (The Register, 2 Sep 2026), all observed 2026-09-27.

Audit logging. The log the Act's record-keeping article describes and the log a supervisor asks for are the same log: for every output, the input (or its hash where the content is sensitive), the retrieved document IDs and versions, the model and prompt versions, the user's identity, the decision a human took (sent, edited, rejected) and the timestamp. It lives at the gateway (L08) because every call passes there. Do not copy full prompts containing personal data into a shared observability service without a data-processing agreement and redaction; that is a second processor, and it goes in the annex.

Model and system cards. Two cards: the vendor's, which you cite (Anthropic publishes per-model system cards with safety evaluations, transparency hub, observed 2026-09-09), and your own for the system, which you write. Yours states intended use, out-of-scope uses, the eval results from 07-eval-plan.md, known failure modes, the oversight design and the date. It is the technical documentation in miniature.

Bias testing. Group-fairness toolkits built for tabular models do not transfer to a text generator, and regulators currently state goals rather than test protocols (bias evaluation survey, observed 2026-09-09). Use counterfactual prompting: the same case with names, addresses, gender markers and language varied, with a rule that tone, offered options and any amounts must be invariant. Record what you tested and what you could not, in the card.

HIPAA. Protected health information needs a business-associate agreement with every processor in the chain, at the enterprise tier, and coverage is feature-specific: a moderation endpoint or a file-upload feature may sit outside the BAA even when the chat endpoint is inside it. Redact before any tool that is not covered, and retain the audit log for the documentation period.

SR 11-7. US bank model-risk guidance treats an LLM that informs a decision as a model needing validation, effective challenge and ongoing monitoring; treat the prompt, the retrieval configuration, the model version and the agent steps as one model in the inventory. Reports of a 2026 successor are unverified; ask the client's model-risk team what they are examined against and cite that.

PCI DSS. Version 4.0.1 has applied fully since 31 Mar 2025 and an LLM that stores, processes or transmits cardholder data, or could affect its security, is in scope (PCI SSC on AI, observed 2026-09-27). The design move is to keep the LLM path out of the cardholder-data environment: tokenise at the payment boundary, return last-four only, and document the scoping decision for the assessor.

Worked case

Harbor Mutual's assistant drafts claim correspondence for motor and property policies, grounded in the policy wording, and can book adjuster visits through a calendar tool. Adjusters review and send every letter in phase one. A later phase may let customers confirm bookings in a chat window. The insurer operates in the EU and the UK, keeps its document archive on-premise, and runs a cloud tenancy. Claim files include bodily-injury reports, which are health data. Procurement (L03: regulated enterprise) already asked for vendor certifications, and legal has asked one question: is this a high-risk AI system?

Three options were on the table. Option A: treat the assistant as high-risk now and build the full Annex III set, including a formal risk-management system and conformity-assessment preparation. Option B: classify it as not listed, ship the baseline set, record a revisit date. Option C: build first and let counsel review before launch. Decide now: which option, and on what fact?

Option B, on the text of Annex III. The Annex lists, under access to essential private services, risk assessment and pricing in relation to natural persons for life and health insurance (Annex III text, observed 2026-09-27). Motor and property claims correspondence is not listed, and the assistant neither prices a policy nor assesses a person's risk; the adjuster decides the claim and the letter reports the decision. Harbor Mutual's classification memo says so, cites the Annex, and names two triggers that would reverse it: a product extension to health or life cover, or a feature that recommends settlement amounts to the adjuster. The revisit date is Jun 2027, six months before the 2 Dec 2027 Annex III date, so that a reversal leaves time to act.

Then the reasoning that makes Option B cheap either way. Harbor Mutual's model-risk function treats the assistant as a model in its inventory regardless of the Act, so three high-risk-shaped controls ship in the baseline: the gateway audit log described above, an adjuster override that is a button rather than a policy, and technical documentation that is the Dossier itself. If the classification ever flips, those three rows change status, not design.

Article 50 is dated and conditional. In phase one, a human sends each letter, so the direct-interaction disclosure is not triggered; the annex records that reasoning rather than leaving the row blank. The day customers confirm bookings in chat, the duty applies (from 2 Aug 2026, per the timeline sourced above), and the design element is already built: a first-turn disclosure string behind a config flag that defaults on, with the screenshot and config hash as evidence.

GDPR supplies the heaviest rows. The lawful basis for processing claim data is the one counsel already relies on for claims handling; the annex cites it rather than inventing a new one. Injury reports are special-category data, so the grounding-data design (L06) redacts medical detail from chunks that the letter drafter can retrieve, and the DPIA records both the residual risk and who accepted it. Residency comes from the topology ADR (L09): EU traffic to an EU region of a cloud marketplace, UK traffic pinned to a UK or EU region, and a rule that no fallback path may leave the region (L14 inherits that rule). Retention follows the vendor terms table: the model chosen under a zero-data-retention approval, verified by a probe call, or 30-day retention documented in the DPIA if the chosen model is excluded from ZDR.

Illustrative composite. Harbor Mutual's numbers are a teaching device, not a measurement from a real insurer. The regional endpoint premium on its cloud marketplace came to about 10% of model spend, or roughly $180 a month on the pilot volume, against a legal-exposure estimate the general counsel put in seven figures. Option A was costed at four extra months of a compliance lead and an external assessor's preparation fees for a system the Annex does not list. Option C is the Dublin bank's story: a quarter lost.

The annex Harbor Mutual signed is below. Every row has an obligation, a source, a date, a design element in the Dossier, evidence a reviewer can open, an owner at the insurer, and a status.

# 10-compliance-annex.md: Harbor Mutual claims-correspondence assistant
Classification: NOT Annex III high-risk as scoped (memo: annex/classification-2026-09.md)
Reversal triggers: health/life cover in scope; settlement-amount recommendation feature
Observed dates checked: 2026-09-09 · Revisit: 2027-06-01 · Owner: Head of Claims Operations

| # | Obligation (source) | Applies from | Design element (Dossier file) | Evidence | Owner | Status |
|---|---|---|---|---|---|---|
| 1 | Classification decision (AI Act Annex III) | now | Classification memo; reversal triggers | Signed memo, revisit date | Legal | done |
| 2 | Direct-interaction disclosure (AI Act Art. 50) | 2026-08-02, when chat ships | First-turn disclosure string, flag default on (05-agent-spec) | Screenshot, config hash, release id | Product | ready, not live |
| 3 | Record keeping, traceability (Act record-keeping; insurer MRM policy) | now | Gateway audit log, append-only, 7-year retention (06-integration-spec) | Log sample, retention config, access list | Platform | done |
| 4 | Human oversight and override (Act oversight; MRM) | now | Adjuster approves every letter; override button; oversight latency budget (12-rollout-plan) | Approval log, latency report | Claims Ops | done |
| 5 | Lawful basis and minimisation (GDPR Art. 6, Art. 9) | now | Basis cited from claims-handling record; medical detail redacted at ingest (04-grounding-data) | Counsel memo, redaction test results | DPO | done |
| 6 | DPIA (GDPR Art. 35) | before pilot | DPIA in annex/dpia.md; residual-risk sign-off | Signed DPIA, review date | DPO | done |
| 7 | Residency (constraint register; GDPR transfers) | now | EU region endpoint; UK pinned; no cross-region fallback (adr/0003-topology) | Gateway routing config, failover test log | Platform | done |
| 8 | Vendor retention and training terms (contract, DPA) | now | ZDR approval or documented 30-day retention; probe call | Approval letter, probe result, DPA clause | Procurement | done |
| 9 | Second-processor logging (GDPR Art. 28) | now | Observability export redacted; DPA with the vendor | DPA, redaction rule, sample | DPO | done |
| 10 | System card (Act documentation; MRM validation) | before production | annex/system-card.md, versioned with prompt and model | Card, eval results link, date | Architect | draft |
| 11 | Bias testing (Act data governance; insurer conduct rules) | before production | Counterfactual suite in 07-eval-plan; invariance rule | Suite results, documented limits | Eval lead | in progress |
| 12 | Vendor certifications (procurement) | contract | Trust-portal reports collected | SOC 2, ISO 42001 attestations, dates | Procurement | done |
| 13 | Model-risk inventory entry (insurer MRM policy) | before pilot | Inventory record, tier, validation schedule | Inventory id, validation date | Model Risk | done |

Faded case

Skip to the open case if this is familiar. Lumen sells a support agent to SaaS companies: US-hosted, multi-tenant, one engineer, twelve people. Compliance was next year's problem until this quarter, when two things happened. A tenant based in Berlin asked whether Lumen's widget tells its end users they are talking to an AI, and Lumen's first enterprise prospect sent a questionnaire asking for a retention policy and a list of sub-processors. Lumen has no annex, no DPA template of its own and no budget for a certification programme.

The roles are the first thing to sort. Lumen is the provider of the system; each tenant is a deployer. Article 50 disclosure lands on the interaction with the end user, so the widget needs a disclosure string that tenants can word but not remove, defaulting on, live before 2 Aug 2026 for any tenant with EU end users. The retention question is answered by the vendor table above: Lumen's model provider retains for 30 days by default, so Lumen's own retention cannot honestly be shorter unless it applies for ZDR, and its sub-processor list must name the model provider and the observability service.

The decision left to you: Lumen can ship exactly one compliance item this quarter with the engineer it has. The candidates are the widget disclosure with per-tenant wording, an ISO 42001 gap assessment, and a bias-testing suite. Which one, and what goes in the annex for the other two?

Open case

A national benefits agency wants a helpdesk assistant on its public portal. Version one answers questions about eligibility rules from the published guidance, tells callers which form to use, and books appointments at local offices. Version two, which the agency prefers, would ask callers for their circumstances and tell them whether they are likely to qualify, then pre-fill the application. Callers include people with limited language skills. Transcripts contain income, household and health information. The agency's counsel has asked you for the classification, the dated obligations for each version, and the first three annex rows. The quiz's first item grades your answer.

Where this breaks

Dates move. The Omnibus shifted the high-risk dates once; delegated acts and guidance can shift what "listed" means again. An annex without an observed date on its sources cannot be trusted a year later, and one without a revisit date will not be reopened. Treat it like a price sheet: dated, re-checked at each stage gate.

Vendor terms are per endpoint and per model. A BAA that covers chat may not cover file uploads or batch; ZDR may exclude a model family; a residency setting may apply to one product line. The annex records the term per endpoint you actually call, with the probe that proves it. "Our vendor is compliant" is not a row.

Bias testing for generators has no agreed protocol. Counterfactual invariance catches obvious asymmetries and misses subtle ones, and no regulator has published a pass mark. Write down what you tested, the limits and the review cadence, and resist a client who wants the word "unbiased" in the card.

The annex is not legal advice. You translate obligations into design elements; counsel decides which obligations apply and signs the classification memo. An architect who classifies alone has taken a decision that is not theirs.

Key Takeaways

• Translate every obligation into a control, a design element and inspectable evidence before you build.
• Classify in writing against Annex III as scoped; record the reversal triggers and a revisit date.
• Ship the cheap high-risk-shaped controls in the baseline: audit log, override, versioned documentation.
• Carry a date and a client-side owner on every row; obligations switch on and evidence needs a producer.
• Verify vendor terms per endpoint and per model with a probe, not a contract clause.

What You Have Now

A compliance annex for your case: each applicable obligation mapped to a design element and the evidence it produces, with the date it applies. It lives at dossier/10-compliance-annex.md, with the classification memo, the DPIA and your system card beside it in dossier/annex/. It cites, rather than repeats, the topology ADR for residency, the grounding-data design for minimisation, the integration spec for the audit log and the eval plan for bias testing, so a reviewer can follow each row to the design element that satisfies it. It serves the Run stage: it is what a regulator, a procurement team or a supervisor reads, and the next lesson's runbook inherits its residency and retention rules as constraints on every fallback path.

Further Reading

• EU AI Act implementation timeline: the dated obligations, updated as delegated acts land; check it at every stage gate.
• NIST AI 600-1, Generative AI Profile: the twelve risk categories and suggested actions; use it as a gap-finder against your Dossier.
• EDPB Opinion 28/2024 on AI models: lawful basis and the anonymity question, from the regulators themselves.
• ISO/IEC 42001: what a certifiable AI management system contains, and what your vendor's attestation actually attests.
• The Register on verifying zero data retention: the case for evidence by probe rather than by contract.

Exercises

1. Classify your case in writing. Write the classification memo for your Dossier's system: the Annex III paragraph you checked, the reasoning in three sentences, two reversal triggers, and a revisit date. Have someone who is not you read it and say which sentence they would challenge.
2. Fill the annex. Using the template in the worked case, write at least ten rows for your case. For each row, open the evidence column and ask: could a reviewer inspect this without asking me a question? Rewrite every row where the answer is no.
3. Probe a vendor term. Pick one term from the vendor table for the provider your case uses. Find the primary page, record the observed date, and design the cheapest test that shows the term is in effect for your organisation. Add the test to the evidence column.

Check your understanding