Last verified 23 September 2026 (Heidelberg AI Desk lines: 12 October 2026). LM Studio is free for internal use at work. Gemma 4 is free under the Apache 2.0 licence; the size used here needs about 14.4 GB of memory, the laptop-sized E4B about 4.5 GB. Details for experts at the end of this book.

The idea in one page

An approval covers a data flow, not a project title. The ethics committee, the data protection officer and the participants agreed to specific data going to specific places for a specific purpose. Adding an AI model changes some of those facts. Your job is to find out which, write them down side by side, and ask the people who decide. It isn't your job to decide.

Name the material honestly.

Draw the flow, including the copies. A model call doesn't go straight from table to answer. There's the working copy on your disk, the app's chat history, the model provider's logs, backups, and the output file. Draw every stop from source to deletion, and write unknown where you can't show the fact yet.

Compare old and new. One short list: what was approved, what you now propose, what stays the same. Reviewers answer faster when they see only the change.

Until they answer, the status is STOP. No "small test" with real rows. You can build everything with made-up material while you wait. A local model doesn't remove the need to ask: it changes where the data goes, not what it's used for.

Test against people, not against the model's confidence. Two researchers code a set of real items by hand, once the review allows it. That's your test set with known answers. Split it: half to improve the prompt, half that you run once at the end. Write the threshold before you run it.

Where Level 3 stops. You build one step for one study, on one computer, inside one decision. Setting up AI for the whole group is T15-L04 · Set Up AI for a Whole Research Group. A shared server for the institute is IT's decision; if you want to try the apps such a server would run, do it on your own computer first, with Heidelberg AI Desk, not on a server you set up by hand.

Worked example: two studies, four quadrants

Both situations use the four-quadrant method from T01-L01 · From Idea to Working Result: The Four-Quadrant Method.

Lab: recovery comments in a clinical study

Structure it. Lena, the doctoral student: "Sort 240 free-text recovery comments into the study's eight themes, with the sentence that supports each theme, so the study team can report theme counts. A colleague must be able to rerun it when I've left. And it must be something the approvals allow."

Understand it. She reads the participant information again. It says the answers will be "analysed by the study team within the University Hospital". Her prototype called a cloud API in the United States: a model service her script reached over the internet. That's a new recipient in a new country, and the text contains health details. She then reads fifty comments. Twelve mention a date, seven name a ward or a physiotherapy practice, and three mention a relative by name. The study code sits in the first column, and the study nurse holds the list that turns it into a name.

She draws the flow and finds copies she hadn't thought about: the prototype saved every request in the API provider's dashboard, and her laptop's download folder holds an export from March. The problem isn't how to make the cloud call safe. It's that the step as designed isn't covered at all. Back to Structure it: "Keep the text inside the hospital. Send the model only the comment, with dates, places and names removed, and no study code. Ask the ethics committee and the data protection officer before a single real comment goes in."

Choose tools. LM Studio on the department's workstation, which sits in the hospital network and has 32 GB of memory, with Gemma 4 26B A4B, the second-largest size. Nothing leaves the machine, and the model file can be pinned with its checksum (a code computed from the file that shows it hasn't changed) as in T15-L02 · Record an AI Step So a Co-Author Can Rerun It. She tests E4B too, which would run on a laptop, but on her made-up comments it confuses pain and mobility more often. The minimising step is a small script with a replacement list, run on the workstation before the model sees anything. The study code is replaced by a run number, and the key between the two stays with the study nurse. She deletes the March export and the prototype's API key, the password her script used for the cloud service.

Build it. First, the review request. One page, sent by the PI to the data protection officer and the ethics committee office:

The UNKNOWN line matters. She could have guessed, but a reviewer who finds one wrong guess stops trusting the rest. The same week she checks which folders LM Studio writes to on the workstation, decides to send the comments from a script to LM Studio's local server, which lets a program on the same computer send it text, instead of pasting them into the chat window, and sends both facts as a follow-up.

While she waits, she builds with made-up comments she writes herself, in the style of the real ones but about invented people. She turns on LM Studio's local server: in the app's Developer tab, she switches on Start server. A short script sends each comment to it. She has a coding assistant draft this script and the minimising script, as in T08-L02 · Get a Script Your Colleague Can Rerun, Without Being a Developer, with only made-up comments in the chat, and reads every line before she runs them. The prompt asks for one line per run number: theme, supporting sentence copied word for word, and UNCLEAR when no theme fits. The run record follows T15-L02 · Record an AI Step So a Co-Author Can Rerun It: model file name and checksum, LM Studio version, temperature 0 (the least random setting), a fixed seed (the number that fixes the model's random choices, so a rerun gives the same answer), prompt version.

Five weeks later the answers arrive. The ethics committee says a notification is enough, since the analysis stays with the study team in the hospital. The data protection officer agrees, with two conditions: real comments never go into the chat window, and the minimised working copies and LM Studio's log folder are deleted once the theme counts are final. Both conditions go into the README, word for word, with the date.

Now the test set. Lena and a second researcher code 80 real comments by hand, separately, and settle their disagreements together. That gives 80 comments with known themes. She splits them: 40 to improve the prompt, 40 she doesn't look at. Before running, she writes the threshold into the run record: "At least 34 of 40 themes match, and no supporting sentence that isn't in the comment."

On the first 40, the model agrees on 31. Most misses are comments about going back to work, which it files under mobility instead of daily life. She adds one line to the theme definitions, reruns the first 40 and gets 36. Then she runs the held-back 40, once: 35 of 40 match, and every supporting sentence is in its comment. It passes. If she had tuned the prompt on all 80, the result would have looked better and meant less.

Every theme in the full run is still checked by a researcher, who sees the comment, the theme and the sentence side by side. The README says who that is, where accepted themes go, and what to do when something looks wrong: "Stop. Don't rerun on real data. Tell the PI. The last accepted theme counts stay valid until the PI says otherwise."

Her colleague Paul, who joins the project in her last month, reruns the held-back 40 on the workstation from the README alone. With the same model file, seed and settings, his labels are identical to hers. He also finds that the README doesn't say where the key between run numbers and study codes lives, which he'd need for linking themes back to the study data. That's deliberate, and now the README says so: "The key stays with the study nurse. Ask her for linked analysis; never copy it here."

What it taught her: the review took five weeks and the build took two days. Building the whole thing with made-up comments while waiting meant the five weeks cost nothing.

Company: usability interviews for an insulin pen

Structure it. Deniz, usability engineer at a medical-device maker: "Sort 20 interview transcripts into our eleven use-error categories, with the quote for each, for the usability report. A second engineer must be able to repeat it for the next study. And it has to fit what participants agreed to."

Understand it. The company's approved assistant is cleared for internal documents. She checks the list: health data isn't on it. The transcripts contain diagnoses, insulin doses, and in two cases the name of a clinic. The consent form, written by clinical affairs, promises analysis "by the study team", with recordings deleted after the report. Her plan would have given the assistant's provider a copy. Back to Structure it: "Transcripts stay with the study team. The model sees excerpts about the pen, not about the person."

Choose tools. The same route as the lab: LM Studio and Gemma 4 26B A4B, on a workstation in clinical affairs that isn't used for anything else. The company's approved assistant stays in use for the report text, which contains no health data. Her review request goes to the data protection officer and the head of clinical affairs. It uses the same approved / proposed / unchanged / never / unknown / status shape.

Build it. While she waits, she builds with excerpts she writes herself. The answer comes back in two weeks: allowed on the workstation, with excerpts cut to the pen-handling passages, and all working copies deleted with the recordings. Her test set is 60 excerpts coded by her and a second engineer, split 30 and 30. The threshold, written first: 26 of 30. The held-back 30 give 27.

The takeover is the reason she wrote a README at all. The next study starts after she moves to another project. Her colleague reruns the held-back 30 on the same workstation and gets identical labels. He then runs the new study's first transcripts and finds a use error the categories don't have. The README says what to do: "New category needed: stop, add it with the second coder, rerun the full test set." He does.

What goes wrong

"Just ten rows to see." Symptom: a few real records go to a tool before anyone decided. Fix: build and test with made-up material. Ten rows are a transfer, and the review has to cover it before it happens.

Pseudonymised treated as anonymous. Symptom: "there are no names" in the request, while a key sits with the study nurse. Fix: call it pseudonymised, say who holds the key, and keep the key out of every file the step touches.

The copies nobody drew. Symptom: the flow map shows table, model, output, but the app keeps chat history and the laptop keeps old exports. Fix: check the app's settings and your disk, and draw every copy until deletion.

A local model as a free pass. Symptom: "it runs locally, so we don't need to ask." Fix: a local model answers where the data goes. It doesn't answer whether this use was agreed. Ask anyway; the answer is often quick.

Tuning on the whole test set. Symptom: the prompt is adjusted until all 80 items match, and the score says nothing about new comments. Fix: hold back half. Run it once, after the threshold is written down.

The builder decides alone. Symptom: the request ends with "low risk, we'll proceed". Fix: you prepare; the ethics committee, the data protection officer and the study lead decide. Their answer, with its conditions, goes into the README.

Conditions that live in an email. Symptom: the data protection officer's two conditions are in someone's inbox, and the next person doesn't know them. Fix: copy every condition into the README, with the date and who set it.

Do it yourself (4 hours, plus the wait)

Use one AI step from your own research that would touch data about people. If it only touches published material, pick one that would, or write the request for a planned step.

1. Structure it (15 min). Write one sentence: what the step produces, for whom, and which approval or consent covers the data today.
2. Understand it (45 min). Read the consent or participant information, the approval and the data management plan. Read 30 of the real items, if you're already allowed to, and count what identifies someone. Draw the flow from source to deletion, with every copy. Rewrite your sentence if the flow isn't covered.
3. Choose tools (20 min). Decide the minimising step, where the model runs, and who decides. Name them.
4. Build it: the request (45 min). Write the one-page review request: approved, proposed, unchanged, never, unknown, status. Have your PI or study lead send it.
5. Build it: with made-up material (60 min, while you wait). Write 20 made-up items. Set up LM Studio and the model (T11-L01 · Run an AI Model on Your Own Laptop, Offline) and switch on its local server. Have a coding assistant draft the minimising script and the script that sends each item to the server, using made-up items only, and read both. Add the prompt and the run record. Run it and fix what breaks.
6. Build it: the test and the takeover (75 min, after the answer). Copy the conditions into the README. Code the test set with a second researcher, split it, write the threshold, and run the held-back half once. Have a colleague rerun it from the README.

Exit check

What you hand in: one AI step, with:

• the review request and data-flow map, and the reviewers' written answer with its conditions;
• a README that names the maintainer, who checks the results, the conditions, and what to do when something looks wrong;
• the run record (model file and checksum, settings, prompt version) as in T15-L02 · Record an AI Step So a Co-Author Can Rerun It;
• the test set coded by two people, the threshold written before the run, and the result on the held-back half;
• the colleague's rerun from the README alone.

It passes when no real data went anywhere before the answer, the test result meets the threshold you wrote down in advance, and the colleague reruns the step from the README and gets the same labels.

Rule to remember

The approval covered the study, not the tool you added later: ask first, build while you wait, and write their answer into the README.

Details for experts

Checked on 23 September 2026. You don't need this to follow the book; it's for setting things up or answering a colleague.

Setting up LM Studio for the first time: T11-L01 · Run an AI Model on Your Own Laptop, Offline.

Further reading and tools

Next books

• T15-L02 · Record an AI Step So a Co-Author Can Rerun It: the run record and pinned model this book assumes.
• T12-L02 · Clean the Copy, Label the Result, Spot the Trap: minimising a working copy, and pseudonymised versus anonymous.
• T15-L01 · Use AI in Your Research and Say Exactly How: the methods sentence for the step.
• T11-L01 · Run an AI Model on Your Own Laptop, Offline: setting up LM Studio for the first time.
• T15-L04 · Set Up AI for a Whole Research Group: Level 4, when the group needs one setup instead of one step.

Tools

• LM Studio: Taught. Runs the model on the workstation, with fixed settings and seed.
• Gemma 4: Taught. The open model in both examples.
• Qwen3.6 (35B-A3B): Catalogued. An alternative open model of similar size.
• Heidelberg AI Desk: Catalogued. Runs the apps on your own computer only; a setup several people reach needs a server.
• Claude API: Catalogued. A cloud route, only if your organisation's contract and the review cover this data.