AIRA is the Aridhia DRE's large language model inference capability, reachable from inside a workspace. It gives researchers a way to use AI that the organisation can govern, instead of leaving them to find their own.
How AIRA works
AIRAInference is held inside the trust boundary. Data never crosses it.
A Trusted Research Environment exists so sensitive data can be worked on without leaving. But to use most language models you have to send them your text, and the easiest models to reach sit outside the environment. That outbound call is itself a way for data to leave.
An organisation that offers no sanctioned way to use AI cannot govern the AI its researchers turn to regardless. It has no control over which models they reach, no say in whether data leaves, and no record of either. Banning AI usually moves the activity out of sight rather than ending it.
The researcher pastes sensitive data into a public chatbot. It leaves the trust boundary, with no audit trail and no way to bring it back.
Sensitive data has been exposed.
AIRA
The model runs inside the trust boundary. Every call is logged, every prompt is versioned, and nothing leaves.
Sensitive data remains secure.
Any tool that speaks the protocol can call it: a Python client, a command-line tool, an IDE extension, or an R client like ellmer. Because the model runs inside the trust boundary, a prompt can contain the sensitive data a researcher is working with. Aridhia calls this the data-aware pattern.
Researchers get inline completions and a chat assistant inside the editor they already use. Every request runs through AIRA instead of an outside provider, so the code they are working on stays in the workspace.
A coding agent that plans and edits across files from the terminal. It works only against the in-workspace endpoint, so repository contents never leave the boundary.
Pairs with you from the command line and proposes diffs you review before they land. The prompts and the code it reads both stay inside the workspace.
An agent for biomedical tasks that can reason over study data in place. Sensitive cohorts stay within the trust boundary while it works.
Reviews files queued for egress and flags possible disclosure risk, helping the airlock approver decide what is safe to release.
Turns a plain-English description into an OMOP cohort definition and supports phenotype review, all against governed data inside the workspace.
Pulls structured fields out of free-text documents such as reports and letters, turning them into analysis-ready tables without anything leaving the boundary.
With more applications and integrations to be added in future development.
Researchers reach AIRA from inside their workspace, never the open internet. An administrator entitles each workspace to specific models, and every request flows through a single endpoint to whichever inference backend the organisation has chosen. The path below is the same regardless of where the model actually runs.
AIRA endpointThey hold regardless of which application is calling.
1
The model runs inside the workspace. The data you show it never leaves to be processed, so real data can go into a prompt safely.
2
The organisation decides which workspaces can reach which models, set per workspace and revocable at any time. The researcher does not choose.
3
The workspace has no other way out, so AIRA is the only route to a model. A capable option inside the workspace removes the reason to go around it.
4
The organisation picks the topology based on cost, infrastructure, data locality and models. When inference runs outside, the organisation owns that relationship.
A TRE depends on being able to account for what happens to the data inside it. A language model is useful enough that people will route around controls to reach one. With AIRA the model runs where the data already sits, or behind a boundary the organisation controls; access is decided by the organisation rather than the individual; and there is a single sanctioned path.
Understand the risks of AI in research settings and how Aridhia enables safe, compliant, and fully audited use of LLMs inside Trusted Research Environments.
AIRA is a transparent API layer in front of OpenAI-compatible and other models, so each one behaves exactly as it normally would while every request stays governed and audited. The same layer keeps the cost of running many models down by loading each only when it is in use.
Add as many models as you like. Each one is only spun up while it is actively being used, so a large catalogue does not mean a large bill.
Each model scales out across nodes to meet demand and scales back to zero when it is idle. You set the node configuration and limits, and pay only for the compute a model is actually using.
Set the priority of each model. Requests that cannot run straight away wait in a queue until their model is free, so batch jobs fill spare compute without interrupting real-time use.
Run more than one deployment of the same model. Keep a dedicated high-priority instance for code completion and a separate lower-priority one for batch work.
Bring your own model as a Docker container. Proprietary models trained on sensitive data run inside the DRE without leaving it, built the same way as the models Aridhia ships.
Every request is recorded. When a prompt references workspace files or blobs, those file accesses are captured in the audit trail too.
Same workspace-facing endpoint, same controls. Only where the compute sits, and who runs it, changes.
AIRADRE Azure Subscription
The GPU and inference instance run inside the DRE's own Azure subscription, in the same environment as the workspaces. That subscription can be managed by Aridhia, or be the customer's own tenancy. There is nothing extra to provision or connect, and it is the default option.
Run inference on your own GPU cluster or another cloud. AIRA extends the trust boundary to include that external GPU over a secure private connection, so the same protections apply and the workspace endpoint stays the same.
Secure link between Azure and cluster.
AIRA
For models you don't host, AIRA provides a governed pass-through to a managed service, with AWS Bedrock as the example. Data does leave the Azure boundary, so the organisation owns the provider account and configures residency, retention, connectivity and audit.
Inference reached from inside the workspace, access entitled per workspace by an administrator, a single sanctioned path. Only the backend changes, a deployment decision made behind the endpoint. An organisation can choose the topology that fits its cost, sovereignty and capability needs without changing how researchers consume AIRA.
If you want to know more about how AIRA works within the Aridhia DRE, or want to explore which topology fits your organisation, get in touch.
