Automated Airlock in a Federated TRE: Design Patterns

Airlock review decides whether a federated Trusted Research Environment (TRE) is genuinely a TRE or merely a remote-desktop product with optimistic naming. Every other Safe in the Five Safes framework — Safe People, Safe Projects, Safe Settings, Safe Data — exists to prepare for the moment a researcher requests an output. The airlock is where governance becomes mechanical.

Why airlock review matters now

The May 2026 UK Biobank incident put output review back at the top of the regulatory agenda. Approved researchers, working inside a centralised SaaS TRE, used the TRE’s own egress workflow to walk derived data out as ordinary scientific results. No rule was broken in the technical sense — the workflow permitted it. Reviewers downstream of the architecture were the only line of defence, and they did not catch it.

The lesson, repeated in the European Health Data Space (EHDS) implementing acts and the UK Office for National Statistics (ONS) revisions to the Five Safes guidance, is that manual review cannot scale with modern analytical volume. A federation TRE supporting genomic and electronic-health-record (EHR) cohorts sees thousands of output requests per week per node. At that volume, disclosure control is a software problem, not a queue problem.

Airlock review as the fifth Safe

The Five Safes framework codified by the ONS — Safe People, Safe Projects, Safe Settings, Safe Data, Safe Outputs — places output review on equal footing with access control. Safe Outputs is the airlock. It is the gate where researcher-generated artefacts (tables, plots, model coefficients, summary statistics) are inspected against disclosure-control rules before any byte is released.

In a federated TRE the airlock acquires architectural weight it never had in a centralised model. Because data never leaves the source, the airlock is the only egress path. There is no shadow copy, no working dataset on a personal laptop, no signed-link export bucket. If an artefact does not pass the airlock, it does not exist outside the node — the property that makes the architecture defensible against the failure mode demonstrated at UK Biobank.

Disclosure-control rules the airlock must enforce

Statistical disclosure control (SDC) is a deep field, but a TRE airlock is responsible for a well-defined set of automatable checks, drawn from the ONS Safe Researcher training and the Eurostat SDC handbook:

• Small cell suppression — frequency tables must not release counts below a configurable threshold (commonly five or ten), because a cell of size one re-identifies an individual.
• Dominance (p%) analysis — for magnitude tables (drug exposures, lab values), no single contributor may account for more than p% of the cell total; dominance lets an attacker subtract their own value and infer the next-largest.
• Differencing and complementary suppression — when two related tables share margins, suppressing one cell is useless if the other reveals it by subtraction.
• Residual disclosure on regression output — coefficients are usually safe, but residual plots and influence diagnostics can fingerprint individuals.
• k-anonymity on cohort definitions — any group descriptor must satisfy a minimum equivalence-class size.
• Free-text scanning — annotations and figure captions are scanned for personal-data tokens (names, postcodes, identifiers) before release.

The challenge is enforcing these consistently across heterogeneous output types — Jupyter notebooks, R Markdown, Stata logs, model artefacts, image files — at a throughput that does not bottleneck research.

The audit trail

An airlock that does not record what it released is not an airlock. Every decision — auto-approved, auto-rejected, escalated, manually approved or rejected — must produce a tamper-evident record with the artefact hash, rule set version, reviewer identity, and timestamp. Under Article 30 of the General Data Protection Regulation (GDPR) and equivalent provisions in the Health Insurance Portability and Accountability Act (HIPAA), this log is the controller’s evidence that processing was lawful.

Automated versus manual airlock review

The historical TRE pattern, inherited from secure-room statistical agencies, was fully manual review: an analyst opened the artefact, ran SDC checks by eye, signed a release form. That pattern was tractable when a TRE served a dozen projects. It collapses when a TRE serves a national biobank with hundreds of concurrent studies and tens of thousands of output requests per month.

Automated airlock review does not eliminate the human reviewer; it changes the reviewer’s role. Routine artefacts — aggregated summary statistics, regression coefficients, k-anonymous cohort counts above threshold — clear without a human in the loop, with full logging. Artefacts that touch heuristics (free-text annotations, model weights, images) escalate with the SDC analysis pre-attached. The reviewer adjudicates exceptions rather than processing every request.

A manual-only airlock costs roughly one reviewer full-time equivalent (FTE) per fifty active researchers, by the rule of thumb used in the Health Data Research UK (HDR UK) TRE community. An AI-assisted airlock runs at one FTE per three hundred to five hundred researchers, with lower median release time and a stronger audit posture because the rule set is versioned rather than implicit in a reviewer’s head.

Manual versus AI-assisted airlock review — comparison

Design patterns for the airlock

Policy-as-code rule sets

Disclosure-control rules belong in version control, not in a reviewer’s training manual. Most federated TREs converge on a declarative rule set — YAML or a domain-specific language — that names each check, parameterises thresholds, and is reviewed through the same pull-request workflow as application code. When a rule changes, the artefact log records which version was in force at release.

Two-stage scanning

The first stage parses the artefact (tables, captions, model objects); the second applies the rule set. Separating parsing from policy means new output formats can be added without rewriting policy, and new rules without rewriting parsers. Production airlocks ship a parser plug-in per format (CSV, Parquet, .RData, .pkl, PNG, PDF) and a single policy engine.

Reviewer-in-the-loop UI for escalations

When automation cannot decide, the reviewer receives the artefact with SDC analysis already done: which cells failed which rules, which tokens triggered the free-text scanner, which complementary cells were flagged. The UI must support both approval-with-modification and rejection-with-reason.

Federation-aware aggregation

The same query can fan out across multiple nodes. Each node runs its own airlock locally; the federation layer must re-apply disclosure control on the aggregated result, because a cell that is large enough at every node may still be small on the meta-analysis. The pattern is airlock at the node, then airlock again at the aggregator, with the second stage aware of the first stage’s suppressions.

Reproducibility receipts

The airlock should emit a release receipt — a hash of the input dataset version, analysis code, rule set, and released artefact. Six months later, when a journal reviewer asks how a table was generated and what was suppressed, the receipt answers.

Operational checklist for evaluating an airlock

For a biobank chief technology officer (CTO) or ministry adviser assessing a federated TRE, the vendor questions are concrete:

1. Show me the rule set — is it declarative, versioned, and diffable?
2. Median time-to-release for a routine aggregated table?
3. What proportion of artefacts auto-clear without human intervention?
4. How is complementary suppression handled across related tables?
5. How is dominance analysis handled on magnitude data?
6. Demonstrate the tamper-evident audit log for a released artefact.
7. For a federated query across N nodes, where is the second-stage check?
8. What is the escalation path when automation cannot decide?

If the vendor cannot answer in concrete terms, the airlock is not yet production-grade.

Frequently asked questions

Is an automated airlock allowed under GDPR and the EHDS?

Yes. GDPR Article 22 restricts solely automated decisions with legal effect on a data subject; output review is a controller-side disclosure-control check, not a decision about an individual. The EHDS implementing acts contemplate automated SDC, provided the rule set is documented and the audit trail retained.

What is the difference between an airlock and a data clean room?

A clean room is typically a marketing-data construct where two parties match audiences without exposing raw identifiers. A TRE airlock governs egress of derived statistical outputs. The clean room enables a join; the airlock enforces disclosure control.

Can an AI-assisted airlock review free-text outputs reliably?

Named-entity recognition catches the common categories — names, postcodes, identifiers, dates of birth — at high recall. Residual risk in narrative text is real, which is why free-text artefacts typically escalate to a human reviewer even in heavily automated airlocks. The automation does the first pass; the human confirms.

How small is “small” in small cell suppression?

The most common threshold is a count of less than ten for tables of people; some agencies use five for very large populations or fifteen for sensitive sub-populations. The threshold should be a parameter of the rule set, set per study or per data type, not hard-coded.

What happens when researchers disagree with an airlock rejection?

A properly designed airlock returns the specific rule that failed, the offending cells or tokens, and a route to request review. Most rejections resolve by the researcher re-aggregating to a coarser grain; genuine edge cases — rare-disease cohorts, for example — escalate to the data access committee.

Does an airlock prevent every form of disclosure?

No. Determined adversaries with auxiliary data can sometimes re-identify individuals through linkage attacks that no per-artefact check will catch. The airlock is a necessary control, not a sufficient one; it sits alongside Safe People, Safe Projects, and Safe Settings.

How does airlock review work when compute is federated across countries?

Each node runs its airlock against local outputs under local law; the federation layer applies a second airlock on aggregated results under the law governing the cross-border collaboration. Sovereignty is preserved because no raw data crossed the border — only outputs that have cleared per-node disclosure control.