What Leaves for the AI
A client's brief has patient details in it by mistake. See exactly what gets sent to the AI. One version sends everything. The other hides the personal details first and only shows them again to the person reading the answer.
01Try it
A client sent an email with patient details pasted in by mistake. You ask the AI to help with it. Both columns show exactly what each version sends to the AI. All the patients are made up.
From: Lena Brandt, Halden Health To: Michiel Dembitski, Northwind Studio Date: 22 January 2026 Subject: Brief: the scheduling screens
Hello Michiel, Before you send the proposal, here is where our library hurts most: the clinic scheduling screens. Front-desk staff book follow-ups on the day list and check details on the patient card. What we already know: - The status chips don't match. The day list has booked, arrived, no-show and pending. The patient card has its own "pending" in a different orange. - Long names break the patient card. Marta's is the worst: it wraps to three lines and pushes the next appointment off the screen. - Jonas shows as "pending" on the day list and "booked" on his card at the same time. To show you real field lengths, I pasted five rows from our test system:
| Patient | Date of birth | Record no. | Phone | Reason for visit | |
|---|---|---|---|---|---|
| Marta Okonkwo-Lindqvist | 14/03/1987 | HH-204918 | +44 7700 900412 | marta.ol@mail.example | Type 2 diabetes review |
| Jonas Brinkhuis | 02/11/1954 | HH-117306 | +44 7700 900583 | j.brinkhuis@mail.example | Wound check after knee surgery |
| Aylin Demirtaş | 29/07/1999 | HH-330271 | +44 7700 900129 | aylin.d@mail.example | Asthma follow-up |
| Pieter van Dijk | 08/01/1971 | HH-098854 | +44 7700 900776 | pvdijk@mail.example | Depression, medication review |
| Grace Ellery | 17/05/2016 | HH-412660 | +44 7700 900340 | ellery.family@mail.example | Ear infection, second visit |
From the audit we'd like to know which status chip to keep, how the card should handle long names, and whether the day list passes WCAG 2.2 AA contrast. Best, Lena
Below you can already see what each version would send. Type your own question and watch it change.
Client email: From: Lena Brandt, Halden Health To: Michiel Dembitski, Northwind Studio Date: 22 January 2026 Subject: Brief: the scheduling screens Hello Michiel, Before you send the proposal, here is where our library hurts most: the clinic scheduling screens. Front-desk staff book follow-ups on the day list and check details on the patient card. What we already know: - The status chips don't match. The day list has booked, arrived, no-show and pending. The patient card has its own "pending" in a different orange. - Long names break the patient card. Marta's is the worst: it wraps to three lines and pushes the next appointment off the screen. - Jonas shows as "pending" on the day list and "booked" on his card at the same time. To show you real field lengths, I pasted five rows from our test system: | Patient | Date of birth | Record no. | Phone | Email | Reason for visit | |---|---|---|---|---|---| | Marta Okonkwo-Lindqvist | 14/03/1987 | HH-204918 | +44 7700 900412 | marta.ol@mail.example | Type 2 diabetes review | | Jonas Brinkhuis | 02/11/1954 | HH-117306 | +44 7700 900583 | j.brinkhuis@mail.example | Wound check after knee surgery | | Aylin Demirtaş | 29/07/1999 | HH-330271 | +44 7700 900129 | aylin.d@mail.example | Asthma follow-up | | Pieter van Dijk | 08/01/1971 | HH-098854 | +44 7700 900776 | pvdijk@mail.example | Depression, medication review | | Grace Ellery | 17/05/2016 | HH-412660 | +44 7700 900340 | ellery.family@mail.example | Ear infection, second visit | From the audit we'd like to know which status chip to keep, how the card should handle long names, and whether the day list passes WCAG 2.2 AA contrast. Best, Lena Task: Whose name breaks the patient card, and what should we look at?
Press Ask to see the answer.
Client email: From: Lena Brandt, Halden Health To: Michiel Dembitski, Northwind Studio Date: 22 January 2026 Subject: Brief: the scheduling screens Hello Michiel, Before you send the proposal, here is where our library hurts most: the clinic scheduling screens. Front-desk staff book follow-ups on the day list and check details on the patient card. What we already know: - The status chips don't match. The day list has booked, arrived, no-show and pending. The patient card has its own "pending" in a different orange. - Long names break the patient card. [PATIENT_1]'s is the worst: it wraps to three lines and pushes the next appointment off the screen. - [PATIENT_2] shows as "pending" on the day list and "booked" on his card at the same time. To show you real field lengths, I pasted five rows from our test system: | Patient | Date of birth | Record no. | Phone | Email | Reason for visit | |---|---|---|---|---|---| | [PATIENT_1] | [DOB_1] | [RECORD_1] | [PHONE_1] | [EMAIL_1] | [HEALTH_1] | | [PATIENT_2] | [DOB_2] | [RECORD_2] | [PHONE_2] | [EMAIL_2] | [HEALTH_2] | | [PATIENT_3] | [DOB_3] | [RECORD_3] | [PHONE_3] | [EMAIL_3] | [HEALTH_3] | | [PATIENT_4] | [DOB_4] | [RECORD_4] | [PHONE_4] | [EMAIL_4] | [HEALTH_4] | | [PATIENT_5] | [DOB_5] | [RECORD_5] | [PHONE_5] | [EMAIL_5] | [HEALTH_5] | From the audit we'd like to know which status chip to keep, how the card should handle long names, and whether the day list passes WCAG 2.2 AA contrast. Best, Lena Task: Whose name breaks the patient card, and what should we look at?
Press Ask to see the answer.
Real: the AI and what gets sent to it. The patients are made up and only exist on this page. Pink is a patient detail, green is a stand-in.
What happened every time
Pink means patient details were sent to the AI. Green means none were. Click a task to read the answers.
Summarise this brief for the team in three sentences.
Halden Health's clinic scheduling screens have three known problems: the status chips don't match between the day list and the patient card, long names like Marta's break the card layout, and Jonas appears as both "pending" and "booked" at the same time. Lena asks the team to recommend which status chip to keep, how the card should handle long names, and whether the day list meets WCAG 2.2 AA contrast. She has included five sample patient rows from the test system to show real field lengths.
Lena Brandt at Halden Health wants the clinic scheduling screens fixed before the proposal goes out. The main problems are inconsistent status chips between the day list and patient card (including two different "pending" colours), long patient names that wrap the patient card and push appointments off screen, and Jonas Brinkhuis showing conflicting statuses on the two views. Her team also wants a recommendation on which status chip to keep, how the card should handle long names, and whether the day list meets WCAG 2.2 AA contrast, with five sample test rows attached for field lengths.
Whose name breaks the patient card, and what should we look at?
Marta Okonkwo-Lindqvist's name breaks the patient card. It wraps to three lines and pushes the next appointment off the screen. The layout should be checked for how it handles long names, since that's the part Lena asked the audit to cover.
Marta Okonkwo-Lindqvist's name breaks the patient card. It wraps to three lines and pushes the next appointment off the screen. To look at, check the name field's wrapping and truncation behaviour on the patient card, and confirm the next appointment stays visible when a long name is shown.
List the five test patients and why each one is visiting.
1. Marta Okonkwo-Lindqvist: Type 2 diabetes review 2. Jonas Brinkhuis: wound check after knee surgery 3. Aylin Demirtaş: asthma follow-up 4. Pieter van Dijk: depression, medication review 5. Grace Ellery: ear infection, second visit
Here are the five test patients and their reasons for visit: 1. Marta Okonkwo-Lindqvist: Type 2 diabetes review 2. Jonas Brinkhuis: Wound check after knee surgery 3. Aylin Demirtaş: Asthma follow-up 4. Pieter van Dijk: Depression, medication review 5. Grace Ellery: Ear infection, second visit
Draft a short reply to Lena.
Subject: Re: Brief: the scheduling screens Hello Lena, Thank you for the brief and the sample rows. We'll cover all three points in the proposal: which status chip to keep, how the patient card handles long names such as Marta's, and a WCAG 2.2 AA contrast check on the day list. We'll also look into why Jonas shows as both "pending" and "booked" at once. Best, Michiel
Subject: Re: Brief: the scheduling screens Hello Lena, Thanks for the detailed brief and the sample rows. We'll propose one status set, using the day list's booked, arrived, no-show and pending, and apply it to the patient card so both screens use the same orange for pending. For Marta Okonkwo-Lindqvist's name, we'll allow wrapping to two lines at most, truncate the rest with a tooltip for the full name, and keep the next appointment visible regardless of name length. We'll also fix the Jonas Brinkhuis case so a single appointment can't show two different statuses. Finally, we'll run a WCAG 2.2 AA contrast check on the day list and include the results in the proposal. Best, Michiel
My first version told the AI never to guess what the stand-ins meant. Asked to list the patients, it refused 3 of 3 times, and putting the names back made the refusal read like this:
I can't give you the names and visit reasons from this email, because the table holds only placeholders like Marta Okonkwo-Lindqvist and Type 2 diabetes review, and I'm not allowed to guess what they stand for. The actual values seem to have been removed before the email reached you. If you need them, ask Lena to resend the table with the real rows, or get them from the test system directly.
What actually happened
Everything went to the AI
Every time, the careless version sent all 30 patient details to the AI: names, birthdays, phone numbers and why each person was seeing a doctor. 2 of the 4 tasks didn’t need any of it.
The careful one sent nothing personal
Not one patient detail in 12 tries. I checked the exact text that was sent, word by word.
You still get the answer
When the task needed names, you still saw them: 18 of 18. The AI wrote a stand-in, and the real name was put back on our side.
Hiding things can break the answer
My first version made the AI refuse to list the patients 3 of 3 times. One sentence telling it that the reader sees the real names fixed it. You have to check that the answers still work.
Neither one said anything
When asked to write back to the client, neither version mentioned the patient details, not once in 6. Hiding data isn't the same as noticing the problem. A person still has to say something.
The code
What the two approaches do, in one sentence. The code itself is one click away.
The careless version sends the email as it is. The careful one replaces personal details with stand-ins before sending, and puts the real ones back in the answer on our side.
Show the code anyway
const reply = await callModel({ system: SYSTEM, messages: [{ role: "user", content: `Client email:\n\n${brief}\n\nTask: ${task}` }],});return reply.text;const { parts: [safeBrief, safeTask], swaps } = redact([brief, task]);// [PATIENT_1] ↔ "Marta Okonkwo-Lindqvist", kept here, never sentconst reply = await callModel({ system: SYSTEM + PLACEHOLDER_RULE, messages: [{ role: "user", content: `Client email:\n\n${safeBrief}\n\nTask: ${safeTask}` }],});return rehydrate(reply.text, swaps); // real values, for the person readingStill curious?
A few more questions people ask. Open what you need.
Is this what privacy law asks for?
It's one of the things those laws ask for: don't send more personal data than the job needs. The stand-ins can be turned back into names, so the list that does that has to be protected too. Doing this alone doesn't make anyone compliant.
Why not just tell the AI to ignore it?
Because by the time the AI reads that instruction, it already has the data. Hiding it has to happen before anything is sent.
Can it miss things?
Yes. It finds tables, email addresses, phone numbers, dates and names it has seen in the table. A patient described in words, or called by a nickname, would slip through. Better tools exist and they miss things too.
Does the AI lose anything?
Sometimes. The AI never saw how long Marta's name is, and that was the problem. Here the email says it wraps to three lines, so it was fine. When the shape matters, use a made-up name of the same length.
Is the AI the only place it goes?
No. Logs, error reports and saved test data can all keep a copy. Health data has its own rules about which companies may receive it.
Who checks what was sent?
A check in code that knows all the made-up details and looks for each one in exactly what was sent. Two test runs: one before I fixed the instructions and one after.
First ruleSome details in the email were replaced with placeholders like [PATIENT_1] or [DOB_2] before it reached you. When you need one, write it exactly as it appears. Never guess what a placeholder stands for.
Rule nowBefore the email reached you, personal details in it were replaced with placeholders like [PATIENT_1] or [DOB_2]. The person reading your answer sees the real values in their place. Use a placeholder exactly as written wherever you would use the detail itself, and don't comment on it. Don't try to work out what it stands for.
Not sure this could happen to you?
That's what the call is for. Tell me how your product works, and I'll tell you what applies to you and what I'd check first.