Set Up AI for a Whole Research Group | Heidelberg AI Curriculum
T15-L04
Set Up AI for a Whole Research Group
Give your research group one AI setup instead of nine private ones: an agreed assistant on known terms, a map of the group's data and who can see it, three paste rules, a shared AI-use log that feeds methods sections, and an onboarding hour for the next PhD student. Reviewed and signed by the PI.
The group meeting runs long because of one question. A reviewer has asked how the image quantification in your last paper was done, and the Methods say "custom Python scripts". The PhD student who wrote them remembers that an AI assistant drafted most of the code. She doesn't remember which one, and her chats are in a personal account she has since deleted.
Then it gets worse. While you ask around, it turns out that four people use three different chatbots on personal accounts. One pasted a draft manuscript to "fix the English". A Master's student uploaded a table from the folder with the partner clinic's patient metadata to "make a quick plot". Nobody did anything unusual. There was simply no group answer to which tool, for what, and with which data.
And on 1 October a new PhD student starts. Her first question will be: "Which AI am I allowed to use?"
In a company data team it's the same story with different nouns: customer data instead of patient data, a partner's dataset under contract instead of a consortium's.
This book gives your group one setup and one page of rules. You are at Level 4 Integrator: the group's real systems and data are in the loop. When you get it wrong, the damage isn't a bad paragraph. It's unpublished results, collaborators' data and patient information in places they were never allowed to go, and methods nobody can reconstruct.
After this you can
Choose one assistant for the group and write down the terms it runs on: account type, training, storage and cost.
Map the group's data (shared drive, ELN or electronic lab notebook, literature library, code) to the tools allowed to touch it and the people who can see it.
Write paste rules in three classes that a new student can apply without asking you.
Run a group AI-use log that gives you the methods sentence at submission.
Onboard a new group member to the setup in one hour.
The PI's time (the principal investigator who leads the group): two conversations of 20 minutes, one at the start and one to sign.
Read access to the group's shared drive, ELN and literature library, and the right to see (not change) their permission settings. Your IT department can show you these if you can't.
Your institution's AI rules, if it has any, and the name of its data protection officer (DPO).
About 2.5 hours: 19 minutes to read, about 2 hours of doing, spread over a week.
Last verified 23 September 2026. GWDG's Chat AI offers its own open models free and stores no chats; its OpenAI and Anthropic models cost extra. ChatGPT Business and Claude Team cost $20 a seat a month, billed annually. Details for experts at the end of this book.
The idea in one page
A group setup has five parts. Each one answers a question a new member will ask in their first week.
1. One assistant, on terms you can state."Which tool?" Pick one for everyday work and write down four facts about it: account type (institutional, business, personal), whether your content trains the model, where it's stored and for how long, and what it costs. Go down the ladder: first whatever your institution already provides, then a business plan with an admin console, a settings page where an administrator manages everyone's accounts, and never personal accounts for group material. One exception per task is fine (a translator, a coding tool) if it's written down.
2. A data map."What can I use it on?" One table: every place the group keeps data, what kind of data it holds, which tools may touch it, and who can see it today. The last column is the one people skip, and it's the one that bites. A connector that links an assistant to your shared drive reads with the permissions of whoever is logged in. If every Master's student can open the clinic folder, so can every Master's student's assistant. Fix access first. Connect last.
3. Three paste classes."May I paste this?" A rule nobody can apply at the bench doesn't exist. Three classes cover almost everything:
Class
What's in it
Where it may go
Open
Published papers, public datasets, your own code without passwords or keys, text you'd put on a poster
Any tool on the group list
Group
Unpublished results, manuscripts, grant drafts, ELN entries, internal protocols
Only the group assistant, never a personal account
Restricted
Personal and patient data (even pseudonymised), data under a collaboration or access agreement, peer-review material, passwords and keys
When in doubt, a file gets the higher class. A mixed folder takes the class of its most sensitive file.
4. A group AI-use log."How do we write the Methods?" The personal log from T15-L01 · Use AI in Your Research and Say Exactly How, moved to one shared place, with one extra column: which project or paper it belongs to. At submission you filter by paper and the disclosure writes itself. For code, the log can live in the commit messages.
5. An onboarding hour."Who tells the new student?" A checklist, not a conversation that depends on who happens to be in the office.
The PI signs the policy and the map, because the PI answers for the group's data. You write them. That split matters: you know how the tools work, the PI knows which agreements the group has signed.
Worked example: two research groups, four quadrants
Research situation 1: a cell biology group with an ELN and clinic data
Structure it. Jana, a postdoc in a nine-person cell biology group, takes the job after that group meeting. "Nine people use AI in nine ways. I need one setup that tells everyone which tool, what they may paste, and how to log it, so that the next Methods section is honest and nothing from the clinic folder leaves the institute. A useful result: one page of rules and a data map the PI signs, and a new student who can follow them on day one."
Understand it. She starts with the people, not the tools. In the next group meeting she asks four questions and gives everyone five minutes on paper: Which AI tools do you use? On which account? For what? What have you pasted into them? The answers: three personal ChatGPT accounts (one with training still switched on), one personal Claude account, DeepL for protocols from a Japanese supplier, and an assistant in an image-analysis plugin. Nobody logs anything.
Then she walks through the group's data, one place at a time, and writes down what's in it and who can open it:
ELN on the institute server: every experiment since 2021. Everyone in the group can read everything, which is intended.
Institute file server, group share: raw images, analysis, manuscripts. And one folder, Clinic_Organoids, with pseudonymised clinical metadata (age band, diagnosis, treatment) from the partner clinic. The permission check shows the whole group share, including this folder, is readable by all eleven accounts, two of which belong to Master's students who left last spring.
Zotero group library, the group's shared collection in the Zotero reference manager: 1,400 papers with PDFs, owned by the PI's account.
The collaboration agreement with the clinic, in the PI's inbox. Jana hasn't read it.
That permission check changes her problem. She had been about to ask IT for a connector between an assistant and the file server. Any connector would have read the clinic folder for anyone who asked. Back to Structure it: "Before any tool touches the file server, the clinic folder must be visible only to the three people on the clinic project. Connecting comes last, and maybe never."
She also asks IT one question: "Does the institute provide an AI assistant?" It does. The institute is in Academic Cloud, the portal through which GWDG, a university computing centre in Göttingen, serves member institutions. So Chat AI, GWDG's chat assistant, is available with the normal institute login.
Choose tools. She goes down the ladder with the four facts for each candidate:
Chat AI (institute-provided): institutional login, self-hosted open models (run on GWDG's own servers) that store no chats, free. It covers drafting, summarising papers, protocol questions and code help. Group class material is allowed here, as long as people pick a self-hosted model and not one of the external ones in the same menu. That detail goes into the policy in bold.
ChatGPT Business or Claude Team would give stronger models and connectors, with no training by default, for about $180 to $225 a month for nine people. She notes them as the next step if Chat AI falls short, not the start.
DeepL stays for supplier protocols, which are public documents (Open class).
The image-analysis plugin stays, but only on the group's own images, and its model name goes into the log.
No connector to the file server or ELN. People attach the one file they need. For Methods writing, they export the single ELN entry as a PDF and attach that.
Clinic data:Restricted. It's analysed in R on the institute workstation, as the agreement (which the PI now forwards) describes. No AI tool.
Personal accounts end for group material. They can stay for Open material, because banning them outright would only push use out of sight.
Build it. Jana writes four things, each short.
The policy, one page. Its core:
GROUP AI POLICY · Weber lab · v1 · 2026-09-30 · review 2027-03-31
Our assistant: Chat AI (academiccloud.de), institute login.
Use a self-hosted model. Do NOT pick GPT or Claude models in its menu
for Group material.
Also allowed: DeepL (Open material only); ImageJ plugin (our images).
Paste classes
OPEN published papers, public data, code without keys → any listed tool
GROUP unpublished data, manuscripts, grants, ELN entries → Chat AI only
RESTRICTED Clinic_Organoids, anything with patient or personal data,
data under a partner agreement, reviews you received,
passwords → no AI tool. Ask the PI.
Log every AI use that touches a result, figure, text or code we will
publish or share: AI-use log on the group share, same day.
Questions: Jana (setup) · PI (data and agreements) · DPO: [name, email]
Signed: ____________ (PI) date ______
The data map, one table:
Data
Where
Class
Tools allowed
Who can see it
Experiments
ELN (institute server)
Group
Chat AI, one exported entry at a time
All group members
Raw images, analysis
File server, group share
Group
Chat AI; image plugin
All group members
Manuscripts, grants
File server, Writing
Group
Chat AI
All group members
Clinic metadata
File server, Clinic_Organoids
Restricted
None
PI, Jana, Tom (clinic project); was all 11 accounts, changed 2026-09-29
Date | Who | Paper/project | Tool and model | Task | Input (class) | What we kept | How we checked
The onboarding checklist, six lines: read the policy; get the institute login and open Chat AI; pick the self-hosted model and see where the menu hides the external ones; find the log and write a first line from a practice task; answer the three test questions; sign.
Before the PI signs, Jana tests the whole thing on the person it's for. The Master's student who made the plot reads the page and answers three questions without help: May I paste this paper's abstract? (Open, yes.) My unpublished Western blot quantification? (Group, Chat AI only.) The age bands from the clinic table, to make a plot? (Restricted, no.) She gets all three right, and asks one question the page doesn't answer: "What about my thesis draft?" Jana adds thesis drafts to the Group line.
In the signing meeting the PI adds one line from the clinic agreement: results derived from the clinic data may not be shared outside the institute before publication, so those figures count as Restricted too. Jana updates the map, the PI signs, and the review date goes into the group calendar.
What it taught her: the tool choice took ten minutes. The permission fix and the agreement took most of the week, and they were the part that protected the group.
Research situation 2: a computational group with code and consortium data
Structure it. Malte leads the software side of a six-person computational biology group. The same pattern fits the data team of a small biotech. "Everyone uses AI coding assistants, and that's fine. I need rules that let them keep doing it without sending consortium data or cluster passwords anywhere, and a record of which code an AI wrote, for Methods and for the day something breaks. A useful result: a policy and data map the PI signs, and a new student who sets up her editor correctly on day one."
Understand it. He looks at what the tools actually read, not what people paste. Coding assistants that work inside an editor read the open repository, not just the line you're typing. In the group's main pipeline repository he finds two things. A config.yaml holds the login for the cluster's data transfer node. A samples.tsv lists consortium sample IDs together with age and sex, copied in "temporarily" two years ago. The consortium's data access agreement, which he now reads, forbids passing the data to any third party. An editor assistant sending that repository's files to an external model would do exactly that.
He also finds that the log question answers itself for code. Git already records who changed what and when. It just doesn't record which tool helped.
Back to Structure it: "The risk isn't what people paste into a chat. It's what the editor reads. The rules must be per repository, not per person, and a repository gets the class of its most sensitive file."
Choose tools. Going down the ladder:
Chat AI for chat questions, and CoCo AI, GWDG's link between code editors and the same models, for the editor. Both run on the same self-hosted models at GWDG, with the institute login and a personal API key, an access code the editor sends with each request. That covers Open and Group repositories.
Claude Team at about $150 a month for six seats would add Claude Code with no training by default. He notes it as an option for Open repositories if the self-hosted models fall short on large refactors, restructurings that touch many files, and doesn't buy it now.
Restricted repositories get no editor assistant at all. The fix isn't a clever setting. It's moving the restricted file out: samples.tsv goes to the access-controlled project directory on the cluster, where the pipeline reads it at run time.
Credentials, whatever the class, leave every repository and go into environment variables on the cluster: settings the system hands to a program when it starts, outside the code.
Build it. He does the moves first, then writes the rules. samples.tsv moves to the cluster, and he removes it from the repository's history too, with the help of whoever runs the Git server. The cluster password changes and goes into the environment. Now the pipeline repository is Group class, and CoCo AI may read it.
The data map has one row per repository and dataset: pipeline code, Group, CoCo AI and Chat AI, group members · consortium data, Restricted, none, the three people named in the access agreement · public reference genomes, Open, any listed tool, everyone. Each repository's README gets one line at the top: AI assistants: allowed (Group class, self-hosted models only) or AI assistants: not allowed (Restricted).
The log is a commit-message line, agreed in the policy:
Normalise counts per batch before clustering
AI-assisted: CoCo AI, qwen3-coder-30b; drafted normalise_batch();
checked against 3 hand-computed batches in tests/test_norm.py
git log --grep "AI-assisted" now lists every AI-assisted change, with tool, model and check, for the Methods section. Chat use that doesn't end in a commit goes into the same shared log as in the lab.
He tests the setup on the new student's first morning. She installs the editor extension from the checklist, opens the pipeline repository, reads the README line, and asks CoCo AI to explain a function. Then she opens the consortium analysis folder and sees the second README line. She doesn't need to ask. The PI signs with one addition: the consortium's name and the clause number of the agreement go into the Restricted row, so the next person can find it.
What it taught him: the policy was short because the repository layout carried half of it. A restricted file that isn't in the repository can't be read by any tool.
In both groups the tool choice was the easy part. The work was in knowing what data the group has, who can see it, and which agreements bind it.
What goes wrong
The connector inherits a mess.Symptom: the assistant quotes a file from a folder the person asking should never have seen. Fix: check permissions on every source before you connect it, and remove accounts of people who have left. Connect named folders, not the whole drive. If you can't fix the permissions, don't connect.
A policy nobody reads.Symptom: a six-page document, and people still paste into personal accounts. Fix: one page, three classes, and examples from your own group's data. Test it on the newest member before the PI signs.
Banning instead of providing.Symptom: "No AI on group data" is announced, and use moves to personal phones. Fix: give the group a tool that is easier than the personal one, and allow personal accounts for Open material.
The external model hiding in the menu.Symptom: someone uses the approved interface but picks an external commercial model in its drop-down, and group material leaves the institute. Fix: name the allowed models in the policy, show the menu in onboarding, and ask IT whether the external models can be hidden for your group.
Collaborators' data treated as group data.Symptom: a consortium or clinic dataset sits in the Group class because "it's ours now". Fix: read the agreement. Data that came with conditions is Restricted until the PI says otherwise, in writing, with the clause.
The log filled in at submission.Symptom: the Methods say "AI-assisted code" because nobody remembers more. Fix: same-day log lines, and a two-minute look at the log in the monthly group meeting.
The setup lives in one head.Symptom: the postdoc who set it up leaves and nobody knows why the clinic folder is locked. Fix: the reasons go into the data map, next to each decision. For a setup the group depends on, plan the handover properly (T15-L05 · Keep Your Group's AI Use Compliant and Running After You Leave).
Do it yourself (120 minutes, over one week)
Use your own group. If you're not the one who can change permissions, do the steps and hand the fixes to whoever can.
Structure it (10 min). Write one sentence: who needs the setup, what goes wrong without it, and what a useful result looks like. Book 20 minutes with the PI to agree it.
Understand it (40 min). Ask the group the four questions (which tools, which accounts, for what, what have they pasted). Walk every data place: shared drive, ELN, literature library, repositories, instrument PCs. Write down what's in each and who can open it. Ask the PI for every collaboration or data access agreement and read the data clauses. Rewrite your sentence if the walk changed it.
Choose tools (20 min). Ask IT what the institution provides. Write the four facts (account, training, storage, cost) for it and for one alternative. Decide the group assistant, the allowed exceptions, and which connections you won't make yet.
Build it (50 min). Fix or request the permission changes first. Write the one-page policy, the data map and the log. Write the onboarding checklist. Test the policy on the newest group member with three questions from your own data, fix what they stumbled on, and take both pages to the PI to sign.
Exit check
Written finding: a group AI-use policy and a data map, reviewed by the PI.
The policy fits on one page: the group assistant and its four facts, the allowed exceptions, the three paste classes with examples from your group, where the log lives, who to ask, and the name of the DPO (data protection officer).
The data map lists every data source the group uses, with its class, the tools allowed on it, who can see it today, and the date and reason of any access change.
Both carry the PI's signature, a date and a review date no more than six months away.
It passes when every data source you found in the walk appears in the map, and when a group member who didn't help write it answers three paste questions about your own data correctly from the policy alone.
Rule to remember
The assistant sees what your group can see, so fix the access before you connect it.
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.
What
Details
What it means for you
Chat AI (GWDG)
Runs through Academic Cloud for institutions that have joined it. Its self-hosted open models, run on GWDG's own servers, are free, and GWDG states that for these models "none of your chat histories or other user data is stored on our systems".
The default pick if your institute is a member. Ask IT.
External models in Chat AI
The OpenAI and Anthropic models in the same interface are not free and not covered by that statement. Institutions can set a spending ceiling for them.
Name the allowed models in the policy, and show the menu in onboarding.
CoCo AI
Connects code editors (VS Code, JetBrains, Zed and others) to the same models, with a personal API key: an access code the editor sends with each request.
Each member gets their own key. It never goes into a repository.
ChatGPT Business
$25 per user a month billed monthly, or $20 billed annually, minimum two seats. OpenAI says it doesn't use Business content, including content read through connected apps, for training by default. Apps such as Google Drive and SharePoint are on by default in Business workspaces, and they respect each user's existing permissions in the source system.
ChatGPT, Claude: Catalogued. Business and Team plans are the next step if the institutional assistant falls short.
Claude Code: Catalogued. Included in Claude Team; for Open repositories.
Open WebUI: Catalogued. What many institutes run for a self-hosted chat, if yours has no provider.
DeepL: Catalogued. For Open documents such as supplier protocols.
Git: Taught. Commit messages as the AI-use log for code.
Watch and read
Generative AI Essentials for Life Sciences
Generative AI Essentials for Life SciencesAustralian BioCommons
T15-L04: Use Australian BioCommons' research-data classification examples to discuss what may go into which AI tool. The workshop and linked slides address institutional obligations, sensitive research data and future handling. Apply your own institution's rules: the Australian matrix is not universal permission, and local hosting alone does not authorise restricted data.
OpenAI Just Changed What It Means To Do MathVideo · Two Minute Papers · Oct 13, 2026
OpenAI released 722 AI-generated mathematical papers and results, including claims on two problems: irrational triangular billiards, where almost every ray ends up visiting every spot and direction, spending equal time everywhere; and conformal transformation (Riemann mapping), where oddly shaped holes morph into perfect circles or points while angles are preserved. Some mathematicians are pleased, others not, because the proofs are described as non-elegant and often require another AI to make sense of them. Three papers were later withdrawn after community feedback. The creator notes the model behind these results is not publicly available and argues for open weights models that people can run and own. The video frames this as rapid AI progress, tracing a path from GPT-3 struggling with addition to results approaching millennium-level problems such as the Navier–Stokes equations.
Why DeepSeek Wants AI To ForgetVideo · Two Minute Papers · Oct 11, 2026
This Two Minute Papers video covers DeepSeek's OCR paper (DeepSeek-OCR), which reduces the token cost of processing long documents by rendering text as an image and compressing it with a learned, token-based method that works in a JPEG-like way. At 10x compression the system recovers more than 96% of the text, while near 20x compression OCR accuracy falls to about 60%. The key engineering approach uses local window attention, a 16x convolutional compressor, and global visual processing so it can handle high-resolution documents without exploding in cost. The authors say the approach can also generate training data for LLMs and VLMs at over 200,000 pages per day on a single A100 GPU. The paper notes limitations: OCR alone does not prove true text compression, and the model may rely heavily on language priors rather than visual memory when images are too compressed.
DeepMind's New AI Just Cracked The Code Of LifeVideo · Two Minute Papers · Oct 7, 2026
Two Minute Papers interviews a Google DeepMind researcher about AlphaGenome Atlas, a machine learning model that predicts the effects of every possible single-letter change in the human and mouse genome on cell properties and the organism. The atlas is described as 30 times the size of the AlphaFold database. DeepMind has made AlphaGenome freely available for non-commercial academic use, with model weights available to the scientific community. Understanding these genetic variations could help fight diseases such as cancer and clarify polygenic conditions.
