AI Tool Use Policy¶

Summary

We encourage the use of AI coding and agentic tools in the lab. Three rules make that possible:

No lab, Institute, or collaborator data goes to an AI tool. Synthetic or public data only.
Nothing runs until a human has read it. No unattended execution, no blanket auto-approve.
You own the output. If you did not write it, you review it. You are responsible for all output/code.

1. Purpose and scope¶

This policy sets out how members of the Systems Medicine and Bioinformatics Laboratory may use AI assistants and agentic tools in their research work, including coding, data analysis, academic writing, grant drafting, and thesis preparation.

It applies to all lab members (students, research assistants, postdocs, staff, visitors) and to all AI tools used for lab work, including but not limited to:

Conversational assistants (e.g. Claude, ChatGPT, Gemini)
In-editor coding assistants (e.g. GitHub Copilot, Posit Assistant)
Agentic tools that can read the filesystem, execute code, or take multi-step actions on your behalf (e.g. Claude Cowork, OpenAI Codex, Google Antigravity, agent modes in IDEs)

The policy governs how we use these tools, not whether we use them. Our position is that these tools can improve workflows when used with discipline, and that the correct approach is controlled enablement rather than prohibition.

This document is intended to be read alongside our ethics approvals and the data access/transfer agreements governing each dataset we hold.

2. Position statement¶

The lab actively supports experimentation with AI tooling. Members are encouraged to trial these tools on their analysis code, pipelines, documentation, literature triage, and writing, and to share what works with the lab.

The risks these tools introduce are real: unauthorised disclosure of controlled data, and unreviewed code producing wrong/bad science. Both are mitigated by the controls below.

3. Data handling¶

3.1 The rule¶

No data held by the lab or the Institute may be made available to an AI tool. Only synthetic or public data may be used.

"Made available" includes any of the following:

Pasting data or data extracts into a chat window
Opening, attaching, or uploading a data file
Pointing an agentic tool at a directory or drive containing controlled data
Allowing a tool to execute code that reads controlled data and returns results into the model's context
Screenshots of data

3.2 Why the rule is absolute¶

Nearly all of our data is human participant data held under strict human research ethics approvals, consent forms, and data transfer/access agreements with cohort custodians. Those instruments almost always prohibit disclosure to third parties and transfer outside approved environments. Sending a data extract to a commercial AI vendor is a disclosure to a third party, regardless of the vendor's retention or training policy, and regardless of how "de-identified" the extract looks.

The consequences of getting this wrong are not minor. They are the loss of a data access agreement, a reportable privacy breach, and damage to the relationships (including ACDC) that our lab depends on. This is why the rule has no exceptions available at the individual level.

3.3 What you may use¶

Category	Examples	Allowed
Synthetic data	Simulated matrices, permuted/shuffled values, `rnorm()` toy datasets, structure-preserving fakes generated by you	Yes
Public data	Openly published reference resources (1000 genomes, GTEx data, published GWAS summary statistics released without restriction)	Yes, if the licence permits
Your own code	Scripts, notebooks, functions, pipeline configs	Yes — see §3.5
Schemas and metadata	Column names, dtypes, dimensions, a `str()` or `head()` of a synthetic frame	Yes
Controlled cohort data	Any individual-level lipidomics, genotype, phenotype, clinical or linkage data	No
Restricted derived data	Summary statistics, model outputs, or aggregates derived from controlled data where the agreement restricts release	No — assume restricted unless you have confirmed otherwise
Participant-identifiable material	IDs, dates of birth, recruitment site records, free-text notes	No
Credentials	Keys, tokens, `.env` files, service account JSON, database passwords	No

3.4 The practical pattern¶

Develop against synthetic/public data; run against real data yourself in a separate environment.

Build synthetic data that matches the schema and rough distributions of your real data, and let the AI tool work against that. You then run the resulting code against the real data yourself, in a separate environment.

3.5 A note on code¶

Code is not data, and you may share your own analysis code with these tools. Two cautions:

Code can contain data. Hard-coded IDs, pasted values, embedded credentials, a notebook with cell outputs still attached. Clear outputs before exposing them, and check.
Code can contain IP. Do not share unpublished sensitive code, commercially sensitive material (including anything relating to the lipidomic risk score translation), or anything under a licence or agreement that restricts disclosure (e.g. AusCVDRisk calculations/algorithm), without asking first.

3.6 Enterprise vs Personal Subscriptions¶

The Baker Institute provides access to Microsoft Copilot, which is covered by an enterprise agreement that protects your data. However, if you are using your own personal subscriptions for other AI tools (e.g., ChatGPT, Claude, Gemini), you must manually turn off the "use my chats for training" or "data sharing" options in the account settings. Many users are unaware that this is turned on by default. If the tool does not allow you to turn this off, you must not use it for any unpublished or sensitive work.

3.7 If you think you need an exception¶

You do not have the authority to grant yourself an exception, and neither does the lab head in most cases — the constraint sits in the data agreement. If you believe a piece of work genuinely requires exposing controlled data to a tool, raise it with the team before doing anything. The answer may be that we pursue an appropriately governed environment for it, which is a conversation with the data custodian.

4. Code execution and agentic tools¶

Agentic tools can run shell commands, modify files, install packages, and call APIs. This is what makes them useful and what makes them dangerous.

4.1 The rule¶

All code must be reviewed before the model is allowed to run it.

Read every command and every diff before you approve it.
Do not enable auto-approve, YOLO mode, "always allow", or equivalent for any tool operating on lab systems or repositories.
The agent's working directory must contain no controlled data. Symlink in synthetic data and ensure no real data is accessible - these tools will read files without your permission.
Destructive operations (rm, git push --force, DROP, overwriting inputs, mass file rewrites) are approved individually, if at all. Prefer to run these yourself.
Do not give an agent your credentials, tokens, or an authenticated session to a data platform.
Version control is important to not lose control. Commit before you let an agent loose, so you can see exactly what it changed and revert cleanly.

4.2 Why¶

Two failure modes, both cheap to prevent and expensive to discover late:

Operational. An agent that misreads your intent can delete work, corrupt an input file, or push broken code. Reviewing code is mandatory.
Scientific. An agent will happily produce code that runs, returns plausible numbers, but is entirely wrong. This happens frequently and can be highly damaging if not caught. It will not be caught if you do not review the code.

5. Responsibility for AI-generated output¶

5.1 The rule¶

You are responsible for everything you submit, commit, publish, or hand over, regardless of how it was produced. "The AI wrote it" is not a defence and will not be treated as one. If you didn't write it, you are required to review it.

This is not optional. It is the same standard that we apply to every other tool/workflow we use: you are responsible for all work you do. AI-generated code is held to exactly the same standard, and for exactly the same reason — because your name goes on the paper.

5.2 What review actually means¶

Reviewing means you can defend the code line by line to me, to a reviewer, and to a collaborator who wants to reuse it.

You understand what every line does and why it is there. If you cannot explain it, you have not reviewed it.
The statistical and biological logic is correct.
You have checked the code against your actual intent, not against whether it ran without error.
Silent failure modes have been checked.
Any package or method the tool introduced is one you can justify. Do not flood your work with unnecessary dependencies.
The output has been tested.

5.3 Practice¶

Prefer small, reviewable increments over large generated blocks. If the codebase is too large to read, it is too large to accept.
If AI substantially generated a component, say so in the commit message or PR description. This is not a confession, it is useful context for whoever reads it next — including you in six months.
Where AI tools materially contributed to a manuscript or its analysis, follow the target journal's and the Institute's disclosure requirements. AI tools are not authors, but their use must be declared.

6. Academic writing (Manuscripts, Grants, and Theses)¶

6.1 Authorship and Declaration¶

AI tools and LLMs cannot be listed as authors on any manuscript, grant, or thesis. You must explicitly declare the use of AI tools in the acknowledgments or methods section (detailing which tool was used and for what purpose), strictly adhering to the target journal, funding body, or university guidelines.

For Monash University students and staff, please refer to the official guidelines: Generative AI in Academic Research.

6.2 Confidentiality and Unpublished IP¶

Do not paste unpublished intellectual property, novel hypotheses, or sensitive grant text into public or commercial LLMs unless an explicit non-training enterprise agreement is in place (such as the Baker Institute Copilot enterprise agreement). If you use a personal tool for grammar or editing, ensure all specific data values, identifying details, and novel ideas are scrubbed, or that you have explicitly opted out of model training in your account settings.

6.3 Accuracy and Hallucinated References¶

You own the output. Fact-checking references and claims is entirely your responsibility. You must thoroughly check that any and all references generated by an AI tool are accurate and genuinely support your claim, not just that they exist. Including hallucinated citations or factually incorrect claims is a serious breach of academic integrity and will be treated as such.

6.4 Peer Review¶

Under no circumstances may you upload manuscripts, grants, or other materials provided to you for peer review into any LLM or AI tool. This includes documents provided to you by collaborators. The peer review process is strictly confidential.

7. Roles¶

Lab members are responsible for compliance with this policy, for reviewing everything they accept, and for raising uncertainty early rather than proceeding on assumption.

The lab head is responsible for maintaining this policy, approving lab-level tool use, liaising with Institute IT and data custodians, and for the scientific integrity of the lab's output.

8. Reporting¶

If you think you may have exposed controlled data to an AI tool, or an agent has done something destructive:

Tell me immediately. Same day. Do not attempt to quietly clean it up, and do not wait to see whether it matters.

There is no penalty for reporting a mistake promptly and honestly. There is a serious one for concealing it — a disclosure we self-report early is a manageable incident, and one discovered later by a data custodian is not. Preserve the evidence (session logs, chat transcript, terminal history) so we can establish what actually happened.

9. Status and review¶


Owner	Lab Head, Systems Medicine and Bioinformatics Laboratory
Applies to	All lab members and affiliates
Version	1.0 (draft)
Review	Every 6 months, or on any material change to tooling, vendor terms, or Institute policy

This is a living document. The tooling landscape changes on a timescale of months. If a rule here is preventing you from doing good work, that is worth knowing — raise it and we will look at whether the rule or the workflow is the problem.