Blogs & News
When a researcher in a Trusted Research Environment is ready to take results out of the workspace, they identify the files they want to take and submit an airlock request. At that point someone, typically the project lead, principal investigator or in some platforms the data owner will review that request and either approve or reject it. For added security and accountability, this process is audited.
The airlock review is the point at which all the prior protections (data access agreements, controlled data ingest, isolated compute) either stand or fall. If the review is weak or inconsistent then potentially identifiable or otherwise sensitive data leaks out with a clear audit trail.
At Aridhia, we have been developing a suite of community applications – apps that are available for administrators to add to workspaces on demand, and even extend and enhance if required. This blog introduces one of these apps, AIRAlock. An app aimed at supporting the output review process. However, I also discuss how we should be using language-model assistance inside a TRE, where it earns its place and where it does not. As you may have guessed, the name of the app is a play on airlock; the AIRA part is the Aridhia AI service that powers the advisory layer.

Egress review is harder than it first appears. A reviewer might face a single CSV with twenty columns, or a folder of thirty files mixing tabular data, plots, model outputs, and free-text notes. For each file they need to decide whether it can leave the workspace, and that decision has to be defensible six months later, consistent across reviewers, and fast enough that egress does not become a bottleneck.
Recent incidents in the wider research-data sector have made the consequences more visible. Public reporting has covered cases where de-identified participant data, accessed legitimately by researchers, ended up outside the secure environment and on the open web. In these examples, the data left through approved channels, and the question afterwards was less about cyber-security and more about whether the egress process had been able to catch what was leaving.
The Five Safes framework, developed by Professor Felix Ritchie of UWE Bristol, decomposes data access governance into five dimensions: Safe Projects, Safe People, Safe Settings, Safe Data, and Safe Outputs. AIRAlock is a Safe Outputs tool. It does not decide who gets access, what the project is for, or how the workspace is configured. It looks at the files a researcher proposes to take out and helps a reviewer reach a defensible decision about whether they should leave. Safe Outputs is the one that most relies on human judgement and has been the hardest to really operationalise.
However, can this work be structured in a way where the reviewer is better supported and the outcome is more consistent.
Manual review is what most TREs have right now. Reviewer disagreement on similar files is well-documented and individual reviewers may drift over the course of a working day. Often, the organisational policy lives in the reviewer’s head rather than in any artefact a governance team can point to.
Pure AI review has become a recent temptation but you can’t just hand the file to a LLM and take its answer. A generative LLM’s answer is non-deterministic, so the same file can produce different verdicts on subsequent requests and there is no auditable record of why the model said what it said.
Rules-based with AI advisory is what AIRAlock implements. A deterministic rule engine ensures that rules are fixed, version-controlled, and produce the same answer for the same input every time. An AIRA supported LLM provides an interpretive second opinion the reviewer reads alongside the rule output. The reviewer still makes the decision and is accountable for the result and the AI never overrides classifications.
The rule engine is the thing you can write a policy document about and AI advisory is the thing that picks up context the rules cannot. Keeping them in distinct roles is what allows AIRAlock to take advantage of modern language-model capabilities without giving up the audit properties that make a TRE governable.
AIRAlock is a ‘community app’ that runs as a containerised app inside an Aridhia DRE Workspace.
The rule engine classifies each file as RED, AMBER, GREEN, or UNCERTAIN. Rules are inspectors that examine file contents and return structured findings. Examples are checks for NHS numbers using mod-11 check-digit validation or a suppression back-calculation. This is when a table contains a Total row and suppressed cells, the engine checks whether the suppressed values can be recovered by subtraction. Every rule that fires is accompanied by further evidence to explain why it was flagged. For example, the columns it flagged, the rows it sampled, the values it could back-calculate.

For every non-GREEN file, AIRAlock runs an automatic disclosure-risk review through AIRA. The response is a short summary of file structure, anomalies noticed, an alignment statement against the rule engine’s output, and a brief note on what the reviewer should focus on. The AI role is to surface context the heuristic rules cannot capture. GWAS summary statistics files, for example, trip the high-cardinality identifier rule on the rs_id column and AIRA reads the column names, recognises summary statistics, and gives the reviewer the structural read that helps them weigh the engine’s conservative flag.
AIRA runs inside the workspace boundary as an ‘offline’ service within the DRE and not a public API call to an external provider. The structural samples AIRA uses never leave the scope of the Aridhia DRE.
A common Safe Outputs control is dual independent review where a second reviewer signs off before a file is released. This is often referred to as ‘four-eyes’ review.
AIRAlock supports four-eyes review by making the first reviewer’s decisions and feedback visible in a structured form.
On completion of the initial review, AIRAlock creates an airlock ‘package’ that includes the files themselves and a comprehensive report PDF that provides detail on the files and the rules that fired, the evidence each rule produced, the AI advisory’s structural read, and the first reviewer’s decision and accompanying notes.
The Aridhia DRE workspace provides a ‘one-click’ route to the airlock for this package, where the second reviewer is notified by email that a review is required. This reviewer can then enter the workspace and use the activity tab to view the report PDF and all files and make a final decision. This decision is audited. The following shows how this takes place inside the Aridhia DRE Workspace Airlock process.
The European Health Data Space regulation entered into force in March 2025, with secondary-use provisions due to apply from 2029. Part of this includes the expectations of a Secure Processing Environment (SPE – the EHDS equivalent of a TRE Workspace). The TEHDAS2 joint action has been consulting on draft guidelines for data users operating inside an SPE, with further consultations running through 2026 on permits, pseudonymisation, and related questions. The implementing acts that give the regulation operational shape are expected through 2027.
Output review is part of the SPE discussion. Whatever specific form the implementing acts take, the underlying requirement is the same. This is that data leaves a controlled environment only through a checked and recorded route and that the decision is auditable. We are watching the consultations as they progress, and confident the approach (deterministic rule engine, version-pinned AI advisory, immutable audit artefact, human accountability for the decision) will continue to fit as the technical specifications firm up.
The role of AI in this design is deliberately bounded, where it is a second pair of eyes that helps the first reviewer interpret what the rules found, but the human is always accountable for the final decision. The accountability requirements emerging from EHDS and adjacent work will continue to encourage approaches that keep these roles distinct.
AIRAlock is a community app, a helper application that operates inside a workspace alongside the platform’s productised features.
If you operate a DRE and want to discuss how it could fit into your egress process, or if you are evaluating DRE for the first time, get in touch.
May 19, 2026
Scott joined Aridhia in March 2022 with over 25 years’ experience in software development within small start-ups and large global enterprises. Prior to Aridhia, Scott was Head of Product at Sumerian, a data analytics organisation acquired by ITRS in 2018. As CPO, he is responsible for product capabilities and roadmap, ensuring alignment with customer needs and expectations.