Residency and contractual questions

What you will be able to do

Collect the facts that your architecture can prove about a customer’s data. Then hand the legal questions to a qualified reviewer, instead of answering them yourself.

Before you startWhat to know and to have readyAbout 45 minutes

What you need to know

• The data inventory, its processors and the copies that a delete cannot reach, from Data inventory and Minimize and retain deliberately.

What you need on your computer

• The project at the end of this module, with its virtual environment active. python -m pytest prints 48 passed.
• This lesson adds no code. You run one short script to collect evidence.

Tested with Python 3.12.13 on macOS. The PowerShell commands for Windows were not tested.

This lesson gives no legal advice

Laws about personal data differ between countries, and sometimes between provinces or states. This lesson teaches you to collect evidence and to ask the right questions. The lesson marks every legal question for qualified review. A qualified reviewer is a lawyer or a privacy professional who knows the laws and contracts that apply to your shop.

The house inspector and the lawyer

Before you buy a house, an inspector visits it. She writes: “The roof leaks above the kitchen. The wiring in the cellar is 50 years old. The boiler was serviced last year; here is the receipt.” Each sentence is a fact that she can show.

She does not write “you can cancel the sale” or “the seller broke the law”. Those are legal conclusions, and a lawyer gives them. The lawyer needs the inspector’s report to do it. Without the report, the lawyer guesses. Without the lawyer, the buyer guesses.

A software team is the inspector of its own system. It can show where the data goes, how long it stays, and what a delete reaches. Whether that is allowed is the lawyer’s question.

The problem: “we followed the checklist”

Ines owns Bramble Books, the second shop on the platform. She asks Omar a simple question: “Is the assistant compliant with the privacy rules?” Omar asks the team. Tomás answers at once:

“Yes. We followed the checklist: we have a data inventory, we minimize the stored runs, we purge after 30 days, and forget deletes a customer. So we’re compliant.”

Every item on his checklist is true. Look at what the previous two lessons showed, though:

• After forget, three of Priti’s prompts are still at the model provider. Nobody on the team has read what the provider’s terms say about them.
• Thirty days is the team’s choice. Nobody has checked how long the shop must keep orders and refunds. Nobody has checked whether 30 days is too long for the stored runs.
• forget “anonymizes” the customer record: the name becomes [deleted]. But her ID, C-50533, still links the record to her order. “Anonymized” is the code’s word. What it means in law is not a question that code can answer.
• Larkfield’s customers live in many places: the practice data has Mississauga, Montréal, Québec City, Vancouver and more. Which rules apply to which customer is a legal question.

The checklist describes the architecture. “Compliant” is a conclusion about the law. Tomás jumped from the first to the second, and Omar was about to repeat it to a customer.

The idea: evidence first, conclusions from a reviewer

Architecture evidence is a fact about your system that you can show to someone else, and that they can check again. Code, configuration, a command’s output, a test and a contract that you received are all evidence. “RETENTION_DAYS = 30, and the test test_purge_deletes_only_what_is_past_its_end_date passes” is evidence.

A legal conclusion says whether the facts meet a law or a contract. “Thirty days is allowed” is a legal conclusion. A qualified reviewer gives it, for your shop, for the laws that apply to it. That is usually a lawyer or a privacy professional.

Two kinds of question often need that reviewer:

• Data residency is where personal data is stored and processed: in which country or region. Every hop of a request can cross a border.
• Contractual questions are about what each processor may do with the data. The part of a contract that says this is often called a data processing agreement. It covers use, sub-processors (the processor’s own suppliers), retention, deletion and what happens after a breach.

The team’s job is to make the evidence complete and easy to check. The reviewer’s job is the conclusion. Mark every place where one stops and the other starts.

A small example: one message, four places

Follow Priti’s message from her keyboard to the last copy. The picture shows each place where it travels, the evidence that says where that place is, and the question for the reviewer.

Where one customer's message travels, the evidence for each location, and the question that needs qualified review.

Text description of the diagram

Four places, in order:

1. The customer: Mississauga, Ontario, in the practice data. Evidence: the customer record. Question for review: which privacy laws apply to these customers?
2. The app server: wherever you deploy it. The practice app runs on your computer. Evidence: the hosting settings. Question: may the data be stored in that region?
3. The model provider: the region of the model deployment. Evidence: ASSISTANT_BASE_URL and the provider’s console. Question: may the prompts go there, and does the provider keep them?
4. The backups: wherever the backup storage is. Evidence: the backup settings. Question: may the backups be in another region?

Each arrow can cross a border. The architecture shows where; whether it is allowed is a question for qualified review.

Some of this evidence is in the code, and some is not. First run Priti’s three tickets with secure on a fresh practice database, as in step 10 of the previous lesson. Then save this script as evidence.py in the project folder, and run python evidence.py:

evidence.py

from support_assistant.config import Settings
from support_assistant.inventory import summary
from support_assistant.storage import RETENTION_DAYS
from support_assistant.systems import World

settings = Settings.from_env()
print("model provider:", settings.provider, "| model:", settings.model,
      "| endpoint:", settings.base_url or "none (recorded decisions, nothing leaves this computer)")
print("stored runs kept for:", RETENTION_DAYS, "days (minimized storage)")
s = summary(World(), "C-50533")
for r in s["rows"]:
    print(f"  {r['where']}: {r['count']} -> {r['reach']}")

model provider: mock | model: chat-small | endpoint: none (recorded decisions, nothing leaves this computer)
stored runs kept for: 30 days (minimized storage)
  database: customers: 1 -> anonymized
  database: orders: 1 -> kept for the accounts
  database: tickets: 3 -> deleted
  database: conversations: 3 -> deleted
  audit log: 3 -> kept: append-only
  model provider: 3 -> not reached
  files: attachments: 2 -> deleted
  backups: 1 -> not reached

With the mock, the honest evidence is “nothing leaves this computer”. Now set a live provider in the environment. The endpoint below is made up, and the script makes no call. On macOS or Linux:

ASSISTANT_PROVIDER=openai_compatible ASSISTANT_BASE_URL=https://larkfield-ai.example/v1 python evidence.py

On Windows, in PowerShell, set the two variables, run the script, then remove them:

$env:ASSISTANT_PROVIDER = "openai_compatible"; $env:ASSISTANT_BASE_URL = "https://larkfield-ai.example/v1"
python evidence.py
Remove-Item Env:ASSISTANT_PROVIDER, Env:ASSISTANT_BASE_URL

The first two lines of the output are:

model provider: openai_compatible | model: chat-small | endpoint: https://larkfield-ai.example/v1
stored runs kept for: 30 days (minimized storage)

The code knows the endpoint’s address. It does not know the region of the deployment behind it, or what the provider keeps. That evidence is in the provider’s console and in its terms. The team must collect it there and attach it, with the date it was read. Some providers keep prompts for a time, for example to check for abuse, and some offer to keep none. The terms say which, and they can change.

Larkfield: the review request

Kwame turns the evidence into a review request for the shop’s privacy adviser. Each row has a question, the evidence, and the open question for the reviewer. The picture shows the four main rows.

Kwame's review request: what the architecture can prove, and what only a qualified reviewer can decide.

Text description of the diagram

Four questions, each with the evidence and the open question for review.

1. Where does a customer’s message go? Evidence: the inventory (8 places after three runs), the endpoint in ASSISTANT_BASE_URL, the region of the deployment. Needs review: may it go to this provider, in this region? Must the shop tell its customers?
2. How long is it kept? Evidence: RETENTION_DAYS = 30 and the purge test, the backups’ expiry setting, the provider’s published retention. Needs review: how long must orders and refunds be kept? Is 30 days right for stored runs?
3. Can one customer’s data be deleted? Evidence: the forget output; after it, 8 copies in 4 places; the deletion test that searches every table. Needs review: is “anonymized” anonymous in law? May the audit log keep her ID? What about the provider’s copy?
4. Who processes it for the shop? Evidence: the model provider, the host and the backup storage, from the data-flow map. Needs review: does each contract cover use, sub-processors, retention and breach notice?

The evidence goes to the reviewer. The conclusion comes back from the reviewer, not from the code.

Kwame writes the request in plain sentences. Notice the marks: every sentence is either evidence that someone can check, or a question for the reviewer.

Evidence. After three runs and forget C-50533, 8 copies remain in 4 places. They are the order (1), the audit log with IDs only (3), the model provider (3) and the backups (1). Attached: the output of inventory C-50533, on the project at the end of Module 4.

Evidence. Stored runs keep no message text and end after 30 days. Code: RETENTION_DAYS = 30 in storage.py. Test: test_purge_deletes_only_what_is_past_its_end_date, passing.

Needs qualified review. May the shop keep the order and the audit events with the customer’s ID after a delete request, and for how long?

Needs qualified review. The provider’s terms, read on the date attached, describe its retention of prompts. Do they meet the shop’s duties to its customers?

Kwame does not write “this is compliant” or “this is not compliant”. The adviser’s answer goes back into the inventory table as a decision, with the adviser’s name and the date. Then it becomes evidence too.

When to ask for qualified review, and what it costs

Ask before the first real customer. Ask again when the evidence changes. Examples are a new processor, a new region, a new kind of personal data, a new place for copies, or new provider terms. Also ask when you cannot meet a customer’s request in full, such as a delete that cannot reach the provider. Module 6 adds one more moment: an incident.

You do not need a reviewer for engineering choices that stay inside the evidence. “Store less” and “delete sooner” are safe defaults that any reviewer can tighten or relax.

The costs:

• Time. A review takes days or weeks. Good evidence makes it shorter: the reviewer reads facts instead of asking for them.
• Money. Qualified review is paid work. A clear request asks only the questions that matter.
• Evidence goes stale. A provider’s terms, a region or a retention setting can change. Date every piece of evidence, and check it again on a schedule.

Common mistake

We followed the checklist, so we're compliant

Symptom: a team member tells a customer, or a sales page says, that the assistant “is compliant” or “meets the privacy rules”. The statement rests on a checklist: inventory, minimization, retention and delete, all ticked.

Cause: a checklist lists engineering controls. It is architecture evidence. “Compliant” is a legal conclusion about specific laws and contracts, for specific customers. Nobody qualified made it. Tomás’s checklist did not cover the provider’s three prompts, the legal retention of orders, or the meaning of “anonymized”.

Diagnose: for each sentence in the claim, ask “Can I show this with code, configuration, output or a document that I have?” If yes, it is evidence. If the sentence says “allowed”, “required”, “compliant” or “legal”, it is a conclusion. Then ask who made it.

Fix: replace the claim with evidence and open questions, as in Kwame’s review request. Send the questions to a qualified reviewer. Until the answer comes back, describe what the system does, not what the law says about it. For example: “Stored runs keep no message text and are deleted after 30 days.”

Bring the module together: every copy and how it is retired

This is the module’s completion check. For each place where Priti’s data lives, you can now say where the copy is, and how it is retired:

Place	Copies after three runs (minimized)	How it is retired	Question for qualified review
Customer record	1	forget anonymizes it	Is this anonymous in law?
Tickets and attached files	3 and 2	forget deletes them	none from the architecture
Stored runs	3, outcome only	the purge after 30 days, or forget	Is 30 days right?
Orders	1	kept, notes cleared	How long must they be kept?
Audit log	3, IDs only	kept, append-only	May it keep the ID, and for how long?
Model provider	3	not reached by the app	What do the provider’s terms allow?
Backups	1	expires; run forget again after a restore	Where are they, and for how long?

Your turn: a new provider

Omar asks the team to try a second model provider for French tickets, through ASSISTANT_BASE_URL. Its servers are in another country. Write two rows for Kwame’s review request. Write one row of evidence that the team must collect, and one row of questions for qualified review. Do not write a conclusion.

Show an example answer

Evidence to collect. The new endpoint’s address from the environment, and the deployment’s region from the provider’s console. The provider’s terms on retention, sub-processors and use of prompts, with the date that we read them. Which tickets go to it: the French ones, 3 of the 26 tasks in the evaluation set. A new row in the inventory: “model provider 2”. Proof that forget still reports it as not reached.

Questions for qualified review. May customers’ messages be sent to a processor in that country? Does the shop need to tell its customers, or ask them first? Do the provider’s terms on retention and sub-processors meet the shop’s duties? What must the shop do if a customer asks to delete data that this provider holds?

The answer names no law and says nothing is “allowed” or “compliant”. It gives the reviewer facts and questions.

See it end to endFind and remove personal data before it reaches a modelCase study

The personal-data case study turns a measurement into architecture evidence for a decision that needs qualified review: may a model provider read unmasked documents?

Knowledge check

Check your understanding

Sort these four statements into architecture evidence and legal conclusions: (a) 'Stored runs are deleted 30 days after the run.' (b) 'Keeping the audit log after a delete request is allowed.' (c) 'forget leaves 8 copies in 4 places.' (d) 'The shop must keep orders for its accounts.'

Show the answer

Evidence: (a), shown by RETENTION_DAYS and the purge test; and (c), shown by the inventory output. Conclusions: (b) and (d). They say what is allowed or required, so a qualified reviewer must make them. The code can only record “kept for the accounts” as the shop’s decision.

Check your understanding

Why can the code say where the model endpoint is, but not where the data is processed?

Show the answer

The code knows only the address in ASSISTANT_BASE_URL. The region of the deployment behind that address is in the provider’s console. What the provider does next, such as keeping prompts or using sub-processors, is in its terms. The team must collect that evidence outside the code, and date it.

Check your understanding

Ines asks Omar: 'Can you delete everything about one of my customers?' Using this module's evidence, write a short, honest answer.

Show the answer

For example: “The app deletes or anonymizes the customer’s record, tickets, files, stored runs, approvals and emails. It keeps the order, and audit events with IDs only. Copies at our model provider and in backups are outside the app’s reach. The backups expire, and our privacy adviser is checking the provider’s terms.”

Recap

• Architecture evidence is a fact that you can show and someone can check again: code, configuration, output, tests, contracts that you received.
• A legal conclusion says whether the facts meet a law or a contract. A qualified reviewer makes it, not the code and not a checklist.
• Data residency: every place that the data travels to can be in another country. The code knows the endpoint; the region and the provider’s retention come from the console and the terms.
• Contractual questions: use, sub-processors, retention, deletion and breach notice, for each processor.
• “We followed the checklist, so we’re compliant” turns evidence into a conclusion. Replace it with evidence and open questions.
• You can now say where each copy of a customer’s data exists and how it is retired.

Next: Impact and error costs