AI and Research Data¶

The core rule¶

No identifiable or sensitive data enters a generative AI system.

While it would be great to have a clear rule for everything about AI and data, life is more complicated and every new dataset or project will require some thought.

If you realise identifiable data has gone into an AI system, tell Andrew or Elizabeth the same day. There is no penalty for reporting it. Depending on the data and the tool, there may be steps we can take and a reporting obligation to an ethics committee or data provider, but only if we know.

How to think about identifiability in our settings¶

Most published guidance on de-identification imagines an attacker with an external database running a linkage attack. That is not our main risk. In Uvira, in a camp block in Bentiu, or in a union in rural Bangladesh, the person who could put a name to a row is a neighbour, a nurse at the treatment centre, or a local official. They do not need a database. They already know who fell sick that week, who was pregnant, and whose child died.

So the working question is not "Could this be linked to a public register?" It is generally:

Could someone who was there at the time read this row and say a name?

The second thing to remember is that identifiability is shaped by the denominator, not always the specific fields. Age band, sex, and district are harmless in a national serosurvey of 8,000 people. The same three fields in a health area of 800 may pick out one person. A rule that ignores population size will be wrong in both directions, so the routes below ask you to think about how many people each row could plausibly be.

Could someone who was there point at a row and say a name?
If they could, what would it cost that person or their community?
Does the AI actually need this field to help with what I am asking?

In our experience, the AI rarely needs the fields that carry the most risk (Q3).

Terms with a dotted underline have definitions: hover over them, or tap on a touch screen.

Step 0: Set up so the AI cannot reach the raw data¶

Do this once per project for all projects, before applying any of the routes below.

Raw data reaches an AI system in three ways, and they need different controls:

You hand it over. Pasting console output, a screenshot of a data frame, or an error message.
The assistant opens it. Coding assistants and agentic tools read the working directory, not only the text you paste into a chat. If the raw dataset is in the project folder, assume the tool can and will open it.
It is buried in something else in the folder. This is the one people can easily miss, and it is covered below.

Where data live¶

Raw data do not live inside a project folder. Not in a subfolder, not in a folder you have added to .gitignore, and not behind a symlink, which looks like a local folder to the assistant even though the file sits elsewhere. A workable convention (though there are many solutions):

~/projects/uvira-ocv/         # the assistant works here
├── R/
├── data-shareable/           # minimal extracts and dummy data only
├── outputs/
└── CLAUDE.md

~/secure/uvira-ocv/           # never inside a project folder
├── raw/
└── lookups/               # the ID lookup from Step 2

Where a study has an approved server, the raw data stays there and never comes down to a laptop at all (note that at the time of writing this, we don't have any studies like this.).

Check what is already in your project folder¶

A project folder that has been worked in for a year usually contains identifiable data even when the raw file is elsewhere, because our tools cache things. Before you point an assistant at a project, look for:

.RData, .Rhistory, and saved workspaces, which hold whatever objects were in memory;
.ipynb notebooks, which store cell outputs, so a head(dat) from three months ago sits in the file as plain text (to those python people on the team if there are any right now);
knitted .html and .pdf from .Rmd or .qmd files, which print tables and often name places;
intermediate .rds and .csv files from a merge that still carry names or IDs;
figures in outputs/ labelled by village or facility;
git history, since a file that was committed and later deleted is still in the repository, and an assistant can read history.

Clearing these once at the start of a project is much easier than noticing them later.

Ignore files help, but they do not enforce¶

.gitignore stops data reaching GitHub, which matters on its own, but it governs Git rather than the assistant. Where a tool offers its own ignore settings, use them as a second layer. Neither is the control you rely on. The control is that the file is not there.

Use a CLAUDE.md, and know what it does¶

A CLAUDE.md file records project conventions and is worth writing, but it is probably not a perfect guard rail. It states intent, but the tool may not honour it. Consider adding something like the following in your project's CLAUDE.md file:

## Data

Raw participant data for this study lives outside this repository, at
~/secure/<study>/, and must not be read, copied, or summarised.

Only files in `data-shareable/` may be opened. These are de-identified
extracts or dummy data prepared under the group's AI and data guidance.

If an analysis seems to need a field that is not in `data-shareable/`,
stop and say so rather than going to look for the raw file.

Permissions, and what you paste¶

Read the permission prompts rather than approving broad file access by reflex, and be careful with modes that auto-accept actions when identifiable data is anywhere on the machine. It is hard to do this when you are asked to click every minute but please please pay attention.

Then remember route 1 above. The most common way this goes wrong is not an agent going looking, it is someone pasting the first six rows of a data frame to debug a merge, or a screenshot of a console. That is sharing data, and the routes below apply to it.

Three ways to work¶

With Step 0 done, every analysis takes one of three routes. Pick the highest one in this table that answers your question, because each row below costs you more effort than the one above it.

Route	Use when	What the AI sees
1. Aggregated data	The question can be answered from counts, rates, or summaries	Data we would be willing to publish today
2. A minimal data extract	You need record-level data, and the risky fields can be generalised	A generalised extract that has passed a small-cell check
3. Dummy data	The analysis needs fields that cannot be generalised without breaking it	Nothing real. The analysis with the real data runs offline

If none of the three works for what you are doing, that is a conversation with Andrew or Elizabeth rather than a judgement call to make alone.

Route 1: Aggregated data¶

Aggregated data, for example weekly counts by age group and sex, may be shared with AI systems if it is data we would be willing to share publicly today.

Two conditions apply:

Suppress any cell with fewer than [5] observations, or a higher number if you believe it is appropriate.
Suppress complementary cells so the hidden values cannot be recovered from row or column totals (e.g., if there are 20 individuals stratified into 4 females and 16 males, you should suppress both female and male cell counts if the total count is provided).

Aggregation is not automatically safe. Weekly counts by age group and sex within a single health area may still produce cell counts of one or two.

Route 2: A minimal data extract¶

Four steps are required to prepare a minimal extract. A single project may require different minimal extracts for each contributing analysis.

Step 1: Build the extract¶

Create a separate data extract limited to the fields and records the analysis needs. Do not point AI tools at the full study dataset. Write it to data-shareable/.

This step is done without AI. You can write the extraction code with AI assistance, but give it the schema (a description of the different fields in the data table) rather than the actual data, and create the extraction yourself.

Step 2: Apply the default generalisations¶

The below table is the working set of generalisation rules for all GDD analyses and they should be applied to the extract before anything is shared. If an analysis needs something the table forbids, that is a conversation with Andrew or Elizabeth.

Field	What to do before sharing
Names, phone numbers (including recontact numbers), national ID or voter card, medical record number (MRN), lab accession, email, biometrics, exact residential address or household GPS (see below), device or SIM identifiers, and full-face photographs	Remove. These are never generalised, only removed.
Study or participant IDs, household IDs, and linkage keys	Replace with a fresh random sequence uniquely generated for this extract. All crosswalks with linkage keys remain outside of project folders and outside of the reach of AI. Do not reuse the same random sequences across extracts.
Exact dates: onset, admission, sample collection, vaccination, visit, or death	Convert to epidemiological week or calendar month. If the analysis needs intervals, share the interval in days and remove the reference date.
Submission and upload timestamps, and other automatically-generated date fields in the export	Remove. These are easy to miss because they survive after you have generalised the dates you were thinking about.
Date of birth	Convert to an age band. Never share a date of birth, whole or partial.
Age	Five-year bands, with an upper band at 75 and above. For children under five, use `0` and `1–4` rather than age in months.
Geography	Health zone or district at the finest. Never share health area, village, camp block, or named facility.
GPS coordinates	Remove. Two decimal places is roughly a kilometre, which may still identify a small village in rural settings. If the analysis itself is spatial, prepare the aggregated or jittered version outside the reach of AI and pass only the generalised / jittered data to the AI.
Occupation	A small fixed set of broad categories. Never share free-text occupation fields or a locally rare one, such as the only health worker, a teacher, or the fishers at one landing site.
Travel and exposure history	Categories only, for example travel outside the district in the past seven days as yes or no. Never a named place or a specific date.
Any free-text field	Review all free text entries you plan to include to ensure no identifiable data are included.
Enumerator, interviewer, or clinician ID	Drop or re-key. An enumerator ID with dates reconstructs a route and therefore a set of households.
Filenames and image metadata	Strip EXIF and rename files using the re-keyed ID (see Study or participant IDs above). Our naming conventions, and those of ODK and Kobo, often encode the site and date.

Step 3: Run the small-cell check¶

The table above handles fields one at a time. This step handles them in combination.

Cross-tabulate the quasi-identifiers still in the extract. Quasi-identifiers are fields that do not identify anyone on their own but can identify individuals when used in combination with each other. Treat any cell with fewer than [5] records as identifying, and generalise further, using wider age bands, month rather than week, or a coarser geography, until no cell falls below the threshold.

The combinations that catch us most often:

Exact date and geography below health zone. Onset date plus health area during a cholera outbreak may name a person to anyone at the treatment centre. This is the most common way our data leaks.
Exact date and a named facility, when the facility admits only a handful of patients per day.
Age in years (or worse, months) and sex and village.
Occupation and small-area geography, especially when the occupation is locally rare.

Two caveats on the small-cell check. (1) The real denominator is the population the records came from, so we may need to apply stricter rules in small or closed populations. (2) This check does not evaluate the sensitivity of the field in question, only the rarity of the feature. For example, a cell of 50 people with a stigmatising condition has higher sensitivity than a cell of 50 individuals aged 5-14 years old.

Step 4: Stop and consult¶

Some data are identifying by construction, and no amount of field stripping fixes it. Talk to Andrew or Elizabeth before sharing if the extract involves:

a small outbreak, where being a case is itself rare and locally known. The index case, the first several cases, and the deaths may effectively be named people;
a camp, prison, school, workplace, or single facility, where the institution is the denominator;
images of people, human sequence data, or contact-tracing data (see below);
any dataset governed by a data-transfer agreement, memorandum of understanding, or protocol that restricts onward transfer or third-party processing. Sending data to an AI system is an act of "onward transfer" and represents a violation of that agreement;
anyone who has been in the media, or a case local authorities have discussed publicly.

Route 3: Dummy data¶

If an analysis cannot be prepared on a non-identifiable extract, generate a dummy dataset with fake but realistic values, develop the code with AI using only the dummy data, and then run the analysis on the real data offline.

Dummy data works only if it carries the real structure, including the parts that break code: missingness patterns, duplicated and malformed IDs, mixed date formats, and encoding quirks from ODK and Kobo. Generate it from the real schema and marginal distributions rather than by hand. If the dummy data is too clean, the code will fail on the real data, and the tempting fix will be to paste in a few real rows. ★

When code fails offline, bring back the error, not the data. Tracebacks and error messages often print the offending values, so read what you are pasting.

Over the next months we hope to develop more guidance on preparing dummy data within the group, and hopefully some shared code.

★ ECL: I think we should still advise jittering of real dates even if only the marginal distribution is used for constructing the dummy dataset.

Data types that need extra care¶

The Step 2 table assumes a rectangular dataset with one row per person. These four do not fit that shape, and each carries risk the table cannot see.

Images of people. The content identifies as surely as the metadata does. A hand, jewellery, a bed number, a ward whiteboard in the background, or a participant ID written on an RDT cassette will all do it. Patient images cannot be shared with AI without consultation with Andrew or Elizabeth and the appropriate ethics approvals.

Genomic sequence data. Never share raw or unenriched sequencing reads, which carry human reads (not often the case in our work) and are direct identifiers rather than quasi-identifiers. Treat consensus genomes from a small outbreak as quasi-identifiers, because once an accession is public, the sequence plus a collection date and district becomes the linkage key.