Five years ago, the hard part of AI-driven discovery was the model. Today, a dozen vendors, open-source groups, and your own team can supply strong structure predictors, protein language models, and small-molecule property models. Which one you pick matters a little less every quarter. The data a model was tuned on now separates one program from the next, and the most valuable data was never yours.
That data belongs to a partner that will not ship it, to competitors who each hold one slice of the same problem, and to hospitals whose multi-omics and EHR data cannot leave the building. Discovery teams now spend more time negotiating access to data than training on it.
Federated learning fixes that at the infrastructure level: the model travels to the data, and only approved outputs come back. Discovery teams already run it in production, from fine-tuning vendor models on proprietary chemistry to training shared models across competing pharma companies. The Rhino Federated Computing team will be at the AI Drug Discovery & Development Summit in Boston later this month to talk shop with anyone stuck on the same problem.
One Infrastructure, Three Patterns
The data you need sits with someone else in three recurring situations: a single partner company, a group of competitors, or a network of hospitals. The infrastructure that makes each one work is the same. Code and models travel to the data, the data stays under its owner's control, and only outputs both sides approved leave the environment. Each pattern has a different convener and a different payer.
The rest of this post takes each pattern in turn.
Pattern 1: Fine-Tune A Model on Private Data
The most common version of the problem has three parties, and none of them will move. The data owner will not send its molecules and assay results to the model vendor. The vendor will not ship its weights into the customer’s environment without a guarantee they stay sealed. Cloud model marketplaces offer that guarantee inside a single cloud account, but discovery data rarely sits in one: it lives in on-prem clusters, across several clouds, and with partners who each hold a piece. And, before training can start, the data has to go through several preprocessing steps and data pipelines. Some models also need large reference databases. That process repeats every time new data comes in, which makes building and maintaining fine-tuning and serving a heavy burden for many teams, especially smaller biotechs.
One infrastructure resolves all four at once. The vendor’s model runs as a sealed service next to the data, so the data owner never sees the weights. Privacy controls govern what leaves: evaluation metrics and adapters, nothing else. GPU pools supply the compute that neither side wants to procure for a single project. Once the first run is set up, every step repeats the same way, so the second model and the second partner take days instead of a fresh security review and integration project.
A global pharma company already runs this pattern at production scale. More than 125 biotechs and research groups fine-tune and run its models on their own data, on infrastructure Rhino operates.
Anyone in discovery can run this pattern, and it has three distinct buyers:
- Pharma AI/ML and computational chemistry teams want one standard environment to evaluate, fine-tune, and run outside models on their own data. Every new vendor then reuses the same security review and infrastructure to protect their proprietary models.
- Model developers seeking data want access to proprietary datasets without a separate integration project for each data owner. Some pay for that access by letting data owners fine-tune and run their models in return.
- Model developers seeking distribution want their models in front of customers who won’t move sensitive data and who run on a wide mix of environments. A model that runs inside each customer’s environment can reach all of them.
Pattern 2: Pool the Signal, Not the Data
Some problems are bigger than any one company's data. ADMET, toxicity, and developability models all improve with every additional molecule, and every competitor holds a slice no one else can see. The pre-competitive consortium trains a shared model across every member's data while each member's data stays home. Members get a model none of them could have built alone; nobody gets anyone else's molecules.
Five global pharma companies already work this way, jointly training biologics developability models on Rhino’s federated infrastructure. None of them holds enough data alone to produce highly accurate models.
The hard part of a consortium is the governance: a neutral broker, a membership agreement, a definition of what each member can and cannot see, and infrastructure that enforces that definition instead of relying on good behavior. The last piece decides whether the other three hold up in practice. If you’re convening a consortium as an industry group, a vendor assembling a network around your own models, or a pharma inviting peers onto a shared problem, that infrastructure and the onboarding path already exist.
Pattern 3: Validate Targets on Patient Data That Will Never Leave the Hospital
The third pattern is where supply is scarcest. Target identification and validation increasingly run on human multi-omics and EHR data held by hospitals and academic medical centers. That data is governed by consent, IRBs, and institutional policy, and it is not leaving the institution at any price. A pharma team that wants to characterize a cohort, prioritize targets, or test a biomarker hypothesis across several institutions has to bring the analysis to each one.
Infrastructure alone does not solve this pattern. The hospitals also have to say yes. In chemistry and assay data, partners bring their own networks: a model owner recruits its users, and a consortium recruits its members. Hospitals answer to IRBs, privacy offices, and their patients, so each one has to approve the approach before any analysis runs. Rhino’s years of work with academic medical centers have established federated computing as an approach hospitals accept, because no patient record ever leaves the institution.
What to Ask For in the Infrastructure
Whichever pattern you are in, the shortlist is the same. Three requirements separate infrastructure that runs in production from a pilot that never leaves the slide deck.
- IP protection on both sides. The data owner's records never leave its environment, and the model owner's weights are never exposed to the data owner. A platform that protects only one side leaves the other side unwilling to sign, and the network never forms.
- Governed outputs. Every artifact that leaves, whether a metric, an adapter, an aggregate statistic, or a trained model, passes through a privacy filter specified by the data owner, with an audit trail of who ran what, on which data, and what came back. Per-use licensing, consortium accounting, and institutional reporting all depend on that trail.
- Onboarding in days. A new partner, model, or site should go live in days, not a quarter. Each new participant reuses the same security review, the same containers, and the same workflows, so the hundredth is easier than the first. Networks with more than 100 members grow exponentially because each new member reuses what the one before it built.
If a vendor cannot show you all three working today, with named networks in production, you are evaluating a roadmap.
Meet Us at AIDDD
The Rhino Federated Computing Platform lets AI models run where the data lives, with every party’s IP intact. The platform already powers the largest federated network in drug discovery, with over 125 members, as well as a pre-competitive consortium of five global pharma companies.
Our team will be at AIDDD in Boston, October 27-29, with ten facilitated 1:1 sessions on the calendar. Bring your specific case: a vendor model you want to test on your own data, a consortium you’re trying to convene, or a hospital network your target program needs. We’ll walk through how that pattern works today and what it would take to stand it up for you.
Book a 1:1 with Rhino at AIDDD →
