A practical guide · November 2026

AI at work: understanding the risk and reducing it

Most AI guidance tells you what is allowed. This tells you how to think about the risk, so that you can make a sensible decision when the guidance runs out or does not cover your case.

It is written for people who use AI tools in research, teaching or professional work, and for anyone who has been asked to set something up for a team. It has no product names in it, because the risks are not really about the product.

1Four questions sort almost every case

Before you decide how careful to be, answer four questions. They take about a minute, and they give you the shape of the risk before you have read any policy.

Question one

What does it hold?

Your own notes, published papers, other people's messages, patient or participant data, student work, a colleague's draft. Write down the worst thing in the pile.

Question two

Who else can reach it?

The vendor's staff, a third party processor, anyone with the account, anyone who finds the machine. Reachability is a property of the setup, not of the model's politeness.

Question three

What can it do without you?

Answer a question, or read a folder, or send a message, or run a command, or hold a password. The more it can do, the more it can do wrongly.

Question four

What happens if it is wrong?

A draft nobody sends costs nothing. A citation in a grant application, a number in a report, a message to a funder, or an action on a system does not.

The useful consequence. Three of these four questions are about the arrangement around the tool, and you control the arrangement. You rarely control the model. That is why the first move in risk reduction is never a better prompt. It is a smaller blast radius.

2The model is the smallest part of the arrangement

Two people use the same model on the same day, with very different risk.

The first pastes a colleague's email into a chat window. The text leaves the building, sits in a provider's account, may be reviewed, and cannot be confidently deleted by the person who pasted it. There is no record of what was sent.

The second runs a tool on their own laptop, pointed at one folder of their own drafts. Nothing leaves the machine except the part of the text the tool sends to the model. There is a copy on disk that nobody backs up, and a habit that will become a problem when the folder grows.

Same model. Different arrangement. The difference is who can reach the data, what it is joined to, and what happens to the copy afterwards.

Four parts of the arrangement matter more than the model:

Where it runs. Your device, an institution's server, or someone else's cloud.
What it can reach. One folder, a mailbox, a shared drive, a database, a whole network.
What it remembers. Nothing, a conversation, or a store of files that accumulates and is hard to audit.
Who administers it. You, a named colleague, or nobody in particular, which is the usual answer and the worst one.

3Six risks, and where the control lives

Each risk below has a control attached, and each control lives somewhere specific: in the design, in a process, in a contract, or in a personal habit. Knowing which is which tells you who has to act.

Risk	What it looks like	The control	Where the control lives
Other people's data	A mailbox, a participant list or a student file pasted into a chat window. The data leaves without a lawful basis and without a record.	Send the smallest possible amount. Use one route, agreed in advance, for anything that identifies a person. Delete the copy afterwards.	Process, and personal habit
Blast radius	A tool with a password, an admin account or a whole drive can be turned by a bad instruction, a malicious document or a stolen key.	Least privilege. One folder, one account, no admin rights, no shared credentials, outbound traffic limited to what it needs.	Design
Fabrication and error	A confident summary, an invented citation, a number that looks plausible and is wrong.	Check anything a reader will rely on against the primary source. Say what you checked. Keep a second reader for anything consequential.	Process
Ownership and rights	Unclear who owns the output. A licence that allows the provider to use your input. Third party material, unpublished, in a prompt.	Read the terms once and write down the answer. Avoid putting other people's unpublished work in. Keep a record of what is yours.	Contract, and personal habit
Accountability	Nobody can say who signed the work, or which parts a person checked. The tool becomes the explanation for the error.	Name the person who is responsible for the output. Keep a short log of what was checked and by whom.	Process, and management
Equity and access	The capability becomes a perk for the funded. Others work around it, or quietly fall behind. Students are affected and not consulted.	Publish who can have it and on what criteria. Provide a shared route. Treat it as infrastructure, not as a prize.	Institutional design

One more risk sits under all six: the workaround. If the sanctioned route is slower than the unsanctioned one, people will use the unsanctioned one, and the institution will not know what it is carrying. A usable permitted route is a control. A prohibition with no route is not.

4Five habits that do most of the work

Start with the smallest data. Ask what the task needs, not what you have. A summary of a paper does not need the participant table.
Keep the shortest leash. One account, one folder, no admin rights, no password that opens anything else. A tool that cannot reach it cannot leak it.
Verify what will be read by someone else. Drafts that only you read need less checking than sentences that carry your name to a funder, a journal or a family.
Write it down once. Where the tool runs, what it can reach, who owns it, what you checked. Two paragraphs now saves a meeting later, and it is the difference between an activity and a system.
Decide the owner before you start. A named person, not a team. Work without an owner is work that nobody can stop.

5A ten point check before you start

I know the most sensitive thing this will touch, and it is the minimum the task needs.
Nothing that identifies a person leaves my control without an agreed route and a lawful basis.
The tool reaches one folder or one system, not everything I can reach.
There is no shared password, and no credential that opens anything else.
I know where it runs, who administers it, and who to ring when it breaks.
I know what it is allowed to do without asking me: read, draft, send, act.
Anything consequential will be checked against a primary source by a person.
I can delete the data, and I know when I will.
There is a named owner, and a date to look again.
If I could not answer one of these, I have said so out loud rather than assumed it.

6If you are setting this up for other people

The controls that hold up are boring and structural. A pattern that works for a small group looks like this.

One machine, in a segment of its own, with inbound access limited to the institution's network.
One instance per person, under separate accounts, so that one person's files are not readable by another.
No connection to a shared mailbox or calendar while the pattern is being proved.
A written description of what data is in scope, what is out, and how long it stays.
One information assessment for the pattern, not one per person.
Nightly backup to a place the institution controls, and a tested restore.
A named technical contact, a named owner for the risk, and a date when the pattern is reviewed.
An exit route: the runbook and the configuration belong to the institution, not to the person who built it.

None of that is about the model. All of it decides whether the thing can be trusted with anything that matters.

7What this guide does not settle

Three questions depend on local rules, and only your institution can answer them.

The lawful basis. Whether you may process a particular kind of personal data, and what assessment is needed first.
Permission to use a given tool. Which products are approved, which are excluded, and for how long.
Records. What has to be logged, kept, or disclosed, including in publications and applications.

Ask early, ask in writing, and ask one named person rather than a generic inbox. A reply you can quote is worth more than a policy you have interpreted.

The one sentence version. Risk with AI is not mostly about what the model knows. It is about what the tool can reach, who else can reach it, what it can do without you, and whether a person has agreed to be responsible for the result.