Set Up AI for a Whole Research Group

T15-L04 · AI in research · Level 4 Integrator · 19-minute read, plus 120 minutes of doing

Nine people, nine private setups

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.

Before you start

• Books: T01-L01 for the four-quadrant method. T15-L01 (the personal use log and disclosure), T15-L02 (recording model and version) and T15-L03 (participant data and ethics review). This book scales all three from one person to a group.
• The PI's time: 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.
• About 2.5 hours: 19 minutes to read, about 2 hours of doing, spread over a week.

Last verified 23 September 2026. Through Academic Cloud, GWDG's Chat AI offers its own open models free, with no chats stored; 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, 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:

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, 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

The method comes from T01-L01. Here it is in a wet lab with an ELN, then in a computational group.

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: 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 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:

The AI-use log: a shared spreadsheet on the group share with the T15-L01 columns plus Paper or project:

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. 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, 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 leave every repository and go into environment variables on the cluster, whatever the class.

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).

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.

1. 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.
2. 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.
3. 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.
4. 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.

Further reading and tools

Next books

• T15-L05 · Keep Your Group's AI Use Compliant and Running After You Leave: data protection, the AI Act, archiving and a setup that survives you leaving.
• T15-L03 · Get an AI Step on Participant Data Reviewed, Then Build It Inside the Approval: the approval route for a Restricted use.
• T04-L04 · Connect an Assistant to Real Documents Without Widening Anyone's Access: connecting an assistant to shared documents without widening access.
• T13-L03 · Write a One-Page AI Rule Your Team Can Use Without Asking You: the same policy for a whole company or institute.
• T02-L03 · Build a Shared Assistant Your Team Can Test and Take Over: shared projects and instructions inside one assistant.

Tools

• 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.