Keep Your Group's AI Use Compliant and Running After You Leave

T15-L05 · AI in research · Level 5 Operator · 20-minute read, plus 150 minutes of doing

Three months' notice

You've accepted a position elsewhere and start on 1 January. You're the one who set up the group's AI use: the assistant, the paste rules, the shared log. You also built two things the group now depends on. One is a literature-screening step that sorted 2,300 abstracts for the group's systematic review in 2024. The other is a planned step that pulls structured fields out of the partner clinic's pathology reports.

In the same week three letters arrive. A journal reviewer asks you to rerun the 2024 screening with the same model. The model was retired by its provider in April, and every request to it now fails. The ethics committee asks how the pathology extraction fits the existing approval. And the PI, your group leader, asks the question you've been avoiding: "Who runs all this when you're gone?"

In a company it's a data scientist at a small contract lab, leaving in eight weeks. Her pipeline sorts incoming customer sample forms and drafts the text of QC (quality control) reports. A large customer has just sent a supplier questionnaire: "Do you use AI? Are you compliant with the EU AI Act?"

You are at Level 5 Operator. When this breaks, work stops: a paper waits on a rerun, a project waits on an approval, and QC reports wait on a pipeline nobody else understands. And whatever you built must keep working after you leave.

After this you can

• List every AI use in your group in a register that your data protection officer and ethics committee can read.
• Sort a use by the GDPR and EU AI Act questions it raises, and send each question to the office that decides it.
• Archive prompts, model identifiers and outputs with the data, so a result stays traceable after the model is retired.
• Write a retention plan that meets your funder's archiving rule without keeping personal data longer than allowed.
• Hand the setup to a named successor who has run it once without your help.

Before you start

• Books: T01-L01 for the four-quadrant method. T15-L04 for the group setup this book keeps alive: the policy, data map and shared log are your starting material. T15-L02 for recording a run, T15-L03 for the review route when participant data is involved.
• Names and email addresses of your institution's data protection officer (DPO), the ethics committee's office, and whoever handles legal questions on research contracts. In a company: the external DPO and the quality manager.
• A successor, named by the PI, with two hours in their calendar.
• About 3 hours: 20 minutes to read, about 2.5 hours of doing, over two weeks. Waiting for answers from offices takes longer. Start at least six weeks before you leave.

Last verified 23 September 2026. This summarises official texts, not legal advice; confirm with your DPO. The DFG expects research data and software archived for ten years. Anthropic gives at least 60 days' notice before retiring a model. Details for experts at the end of this book.

The idea in one page

At Level 4 you gave the group one setup. At Level 5 it has to last. Three questions decide whether it does:

Together that's one dossier. Three ideas make it work.

You collect facts; the offices decide. Whether a use is lawful under the GDPR, whether the ethics approval covers it and which AI Act duties apply are decisions for the DPO, the ethics committee and your institution's legal office. Your job is to make each question small and concrete enough that they can answer it in one email: which data, which tool, run where, by whom, for what, kept how long. A register entry that says "DPO: covered by processing agreement, email 12 Oct" is worth more than a page of your own legal reasoning.

The research exemption is narrower than it sounds. "The AI Act doesn't apply to research" is the sentence you'll hear most. Read Articles 2(6) and 2(8) yourself. They cover AI built for the sole purpose of research, and research on AI before it's placed on the market. A general assistant your group bought or was given was not built for the sole purpose of your research. So don't assume the exemption covers it. Ask, and write down the answer. In practice, most research groups using assistants are deployers, the Act's word for anyone who uses an AI system at work, with light duties today: AI-literacy measures (your onboarding hour from T15-L04 is one), no prohibited practices, and disclosure if you publish deep fakes or public-interest text without editorial control. If AI output would ever feed a decision about a patient's care, you've left this book's ground. Stop and ask.

Trace the decision, not just the output. Models get retired, often within two or three years. You can't promise a rerun ten years later. You can promise that anyone can see what went in, what the model was, what came out and which person accepted it. The FAIR principles, the common rules for making research data findable and reusable, help here. Principle R1.2 asks for "detailed provenance", a record of where each piece came from, and A2 asks for metadata to stay accessible "even when the data are no longer available". Apply both to the model: keep its record even when the model is gone.

Worked example: two departures, four quadrants

The method comes from T01-L01. Here it is for the postdoc from the opening, then for the contract lab.

Research situation 1: a postdoc leaves a cell biology group

Structure it. Jana leaves on 31 December. "After I leave, the group must be able to show what AI it uses and on what footing, trace every AI-assisted result back for ten years, and keep the two AI steps running with a named person. A useful result: a dossier the PI signs, and a successor who has run everything once while I'm still here to answer questions." The PI names Tom, a second-year PhD student on the clinic project, as the successor.

Understand it. She starts from what she built at Level 4: the policy, the data map and the shared log. From the log and the repositories she lists every AI use that touches data, results or people. There are seven: daily chat use in Chat AI, the chat assistant that GWDG, a university computing centre, runs for the institute (T15-L04), DeepL for supplier protocols, the image-analysis plugin, code help in the editor, the 2024 literature screening, the planned pathology extraction, and AI-drafted plain-language summaries for the institute's website.

Then she tests the one that worries her. She tries to rerun the 2024 screening for the reviewer. The request fails: the model has been retired. What she still has decides the matter. The prompt is in Git with a tag, a named marker on the exact saved version, the model identifier and date are in the run record, the input is a PubMed export with its PMIDs, and the raw output and the human decisions are saved next to it. Nobody can rerun the step. Anyone can trace it. Her reply to the reviewer says exactly that, with the method and the agreement between the model's sort and the two human screeners. She also sees one gap: the run record doesn't say who checked the excluded abstracts. That goes into the template for next time.

For the pathology extraction she writes one email to the DPO and one to the ethics committee's office, each with the same six facts: which data (pathology free text from the partner clinic, pseudonymised, with the key held by the clinic), which tool, where it runs, who sees the output, for what (structured fields for the organoid study, no effect on patient care), and how long it's kept. In this example the answers come back in ten days. The DPO: pseudonymised pathology text is health data under Art. 9, so Chat AI's external hosting isn't approved for it, even though the institute's processing agreement covers it for Group material, the data map's class for unpublished internal work; a model run on the institute's own server is acceptable, and she wants a short impact assessment. The ethics committee: the approval names analysis at the institute; a notice of amendment describing the local model is enough.

The emails change the problem. Jana had been thinking of compliance as a document to write at the end. It turns out to be three questions she has to ask now, because the answers take weeks. Back to Structure it: "The register is the list of questions and who answered them. The website summaries need a question too, for the legal office: does Art. 50(4) apply when the PI edits and signs every text?"

Choose tools. Going down the ladder:

• Register, retention plan and walkthrough record: a table on the group share, next to the data map. No new tool. The DPO and the ethics office get a PDF copy.
• Archive package: a folder per AI-assisted result, deposited with the data in the institution's research data repository when the paper is published. Prompts and code stay in Git with a tag per paper.
• The pathology extraction: an open-weight model, one whose files anyone may download and run, in Ollama, a free program that runs such models on your own machine, on the institute's GPU workstation, as the DPO asked. Because the model's files (its weights) sit on the workstation, the group can archive the exact model file the paper used, if its licence allows. That's one thing a hosted model can never give you.
• Keys and accounts: the old API account for the screening step is on Jana's institute account, billed to the group's cost centre. It moves to a group functional account, one that belongs to the group rather than a person, before she leaves.

Build it. She writes the register, one row per AI use. Three of the seven rows:

Each row links to the emails and letters it cites.

The archive package for each AI-assisted result has the same five parts:

2026_organoid-paper/ai/
  README.md          what the step did, who checked it, what a rerun needs
  prompts/           exact prompt files, Git tag paper-2026-v1
  run-records/       model identifier, provider, date, settings (T15-L02)
  inputs/            input file list with checksums (not the restricted data)
  outputs/           raw model output + the human-accepted version

Restricted inputs stay in the clinic project's protected storage. The package names them and says where they live.

The retention plan gives every item a period, a reason and a person who deletes:

Then the walkthrough. Tom does it, Jana watches and doesn't touch the keyboard. He logs into the workstation with his own account, starts the extraction step from the README on three test reports that the clinic prepared for this purpose, finds and opens the 2024 archive package, and explains to the PI in two minutes why that step can't be rerun and why that's fine. He gets stuck once: the README says "start the model" but not which command or which model tag, Ollama's name for one exact model version. Jana adds both lines: ollama pull with the exact tag, which downloads that model once, and the command that starts the extraction script. The second time he runs it without asking.

The PI signs the dossier on 15 December, with a review date in June. Jana's last entry in the register moves every Contact field that still said Jana to Tom or the PI.

What it taught her: the compliance work was mostly waiting for answers, so it had to start early. The continuity work was mostly finding what only lived in her head.

Research situation 2: a data scientist leaves a contract lab

Structure it. Aylin, the only data scientist at a 20-person contract testing lab, leaves in eight weeks. The same pattern fits a data team in a university core facility. "The step that sorts incoming sample forms and drafts QC report text must keep running, the customer questionnaire must get a true answer, and our quality system must be able to show how any past report was made. A useful result: a dossier the managing director signs, and Kai from the QC team running the pipeline alone."

Understand it. Her register has four AI uses. The one that matters is the pipeline: a hosted model, called through the lab's business API account, reads each sample form, fills a structured record, and drafts the report's summary paragraph, which a QC analyst edits and signs. The forms contain names and email addresses of customers' staff, and for some clinical customers a pseudonymised patient code.

The customer questionnaire asks "Are you compliant with the EU AI Act?" She was about to write "Yes." Reading Art. 3(4) and Art. 4 changes that. The lab is a deployer. What it can truthfully say is what it does: which system, which tasks, that a qualified person signs every report, that staff received AI-literacy training on a named date, and that the external DPO reviewed the data flow. She sends the draft answer to the external DPO and the managing director, not to the customer.

She also finds the continuity risk: the API key lives in an environment file, a settings file the program reads its key from, on her laptop, and the model identifier in the code is an alias that the provider moves to newer models. Two QC reports from March and August were made with different models, and the records don't say so. Back to Structure it: "Pin the model version in the code, record it in every report's run record, and move every key off my laptop."

Choose tools. The register and retention plan go into the lab's existing quality management documents, because that's where auditors look. The API key moves to the company's password manager and the server's environment. The model identifier gets pinned to a dated version, with a calendar reminder 60 days before its announced retirement date. The run record for each report joins the report in the document management system.

Build it. She writes the register rows, the retention plan (report records kept as long as the quality system requires for the report itself; raw forms with personal data only as long as the customer contract allows), and a one-page "What to do when the model is retired": test the replacement model on the ten reference forms, compare the structured fields, record the result, and only then switch. Kai does the walkthrough on a copy of last week's forms and runs the retirement drill once on the reference set. The managing director signs, and the customer receives an answer made of facts.

In both places the dossier was short. What made it hold was that every open question had a named answer, every result had its record, and the successor had already done the work once.

What goes wrong

"Research is exempt." Symptom: the group skips every AI Act and data-protection question because "it's research". Fix: read Art. 2(6) and 2(8), send the question to your legal office, and record the answer in the register. Data protection applies to research in any case.

Pseudonymised treated as anonymous. Symptom: coded patient data goes into a tool approved only for non-personal material. Fix: if anyone, anywhere, holds the key, it's personal data (Recital 26). Health data needs the DPO's answer before it goes into any AI tool (T15-L03).

Archiving the answer but not the question. Symptom: a figure in a paper came from an AI step, and nobody can say which model, which prompt or who checked it. Fix: the five-part archive package, filled in on the day of the run, not at submission.

One retention rule for everything. Symptom: chat logs with personal data kept "for ten years, like the DFG says", or raw data deleted early "for data protection". Fix: a retention plan per item, with the reason and a named person who deletes or checks.

Handover as a document. Symptom: a 20-page README, and the successor still calls you three weeks after you've left. Fix: the successor runs every step while you watch. Every question they ask becomes a line in the README.

Keys and accounts tied to the leaver. Symptom: the pipeline stops the day your account is closed, or the invoice goes to your personal card. Fix: list every account, key and subscription in the register and move them to group or company accounts before your last month.

A moving model name. Symptom: the same code produced reports with two different models, and the records can't tell them apart. Fix: pin a dated model version, record it per run, and plan the switch before the retirement date.

Do it yourself (150 minutes, over two weeks)

Start at least six weeks before anyone leaves, or now if nobody is leaving. That's the cheapest time to do it.

1. Structure it (10 min). Write one sentence: what must still work, be allowed and be traceable when you're gone, and who takes over. Ask the PI or manager to name the successor.
2. Understand it (45 min). List every AI use from your log, data map and repositories. For each, write the six facts: data, tool, where it runs, who sees the output, purpose, retention. Mark the uses that touch personal or health data, or that publish text. Send one email per open question to the DPO or ethics office, with the six facts. Try to rerun your oldest AI-assisted result, and note what's missing.
3. Choose tools (15 min). Decide where the register, retention plan and archive packages live, using systems your institution already keeps: the group share, the repository, the quality system. List every account and key that's tied to you and where each will move.
4. Build it (80 min). Write the register, filling in answers as they arrive. Build one archive package for your most important AI-assisted result. Write the retention plan. Move the keys and accounts. Book two hours with your successor and do the walkthrough: they run the main AI step and restore one archived result while you watch. Fix the README from their questions, and take the dossier to the PI to sign.

Exit check

Written finding: a compliance and continuity dossier with three parts.

• Register of AI uses: every AI use in the group that touches data, results or people, with its data class, tool and where it runs, each open question and who answered it (with a date and a link to the answer), its status, and a named contact who isn't you.
• Retention plan: for every item, how long it's kept, why, and who deletes or checks it. At least one archive package built to the five-part pattern.
• Successor walkthrough: the successor's name, the date, what they ran, where they got stuck and what you changed as a result.

It passes when the successor has run the main AI-assisted step and restored one archived result without your help, every open question in the register has a named answer or a named person waiting for one, and the PI or manager has signed with a review date.

Rule to remember

A setup that only you can explain stops the day you leave.

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. It isn't legal advice.

Further reading and tools

Next books

• T15-L04 · Set Up AI for a Whole Research Group: the policy, data map and log this book keeps alive.
• T15-L02 · Record an AI Step So a Co-Author Can Rerun It: the run record inside every archive package.
• T15-L03 · Get an AI Step on Participant Data Reviewed, Then Build It Inside the Approval: the review route for personal and health data.
• T12-L05: governance records and handover for any system a team depends on.
• T13-L05 · Keep Everyone's AI Skills Current, and Show It When Asked: recording the AI-literacy measures Article 4 now asks for.
• T10-L05 · Keep a Data Pipeline Right for Years, and Trace Any Published Number to Its Source: keeping a data pipeline running over years.

Official sources

• GDPR on EUR-Lex (opens in a new tab) and AI Act on EUR-Lex (opens in a new tab), with the 2026 amendment (opens in a new tab).
• The Commission's AI Act overview and timeline (opens in a new tab).
• DFG Code of Conduct, Guideline 17: Archiving (opens in a new tab).
• Springer Nature AI policy (opens in a new tab).

Tools

• Ollama: Taught. Runs an open-weight model on your own workstation, so health data stays in the building and the exact model file can be archived.
• Git: Taught. Tagged prompts and code for each paper.
• Claude API: Catalogued. An example of a hosted model with a published retirement schedule; any hosted model needs the same record.