When Three Nonprofits Want to Train a Shared Model Without Sharing Data
Three organizations serving the same population each hold a piece of the picture, but none can legally or ethically hand over their case files. Federated learning and privacy-preserving collaboration make it possible to build a shared model from data that never leaves anyone's building. Here is how to decide whether it is worth it, and how a small coalition can actually pull it off.
Picture three nonprofits in the same city. One runs an emergency shelter, one operates a food assistance program, and one provides job placement services. They serve overlapping populations, and each has noticed the same frustrating limitation: their own dataset is too small and too narrow to build a reliable model for the question they all care about, which is predicting who is at risk of falling through the cracks. Individually, each organization has a few hundred records and a model that overfits and underperforms. Together, they would have thousands of records spanning shelter stays, food access patterns, and employment outcomes. A model trained on the combined data would be far more useful to all three.
The obvious move is to pool the data into one shared spreadsheet or database and train on everything. The obvious move is also off the table. Each organization holds information it is legally and ethically prohibited from handing over: housing status, food insecurity, criminal history, immigration details, health conditions disclosed in intake interviews. Client consent forms did not authorize sharing with other agencies. Funder agreements restrict data use. And even if the lawyers somehow blessed it, the trust that each organization has built with its community would not survive the discovery that case files were copied to a partner's server.
This is one of the most common and most underappreciated situations in nonprofit data work. The value of collaboration is obvious, the legal and ethical barriers to pooling are real, and the assumption that you must choose between them is wrong. A family of techniques broadly called privacy-preserving machine learning, with federated learning at its center, lets multiple organizations train a single shared model while their raw data stays exactly where it is. No spreadsheets change hands. No client records leave anyone's systems. What gets exchanged is mathematics, not data.
This article explains how that works in plain language, walks through the legal and governance structures that make it legitimate, surveys the open-source tooling that exists today, and, most importantly, helps you decide whether your coalition actually needs this approach or whether a simpler path would serve you better. Federated learning is genuinely powerful, but it is also genuinely complex, and a small coalition can waste a year on infrastructure that a shared anonymized dataset would have solved in a month.
What Federated Learning Actually Is
Federated learning inverts the normal logic of machine learning. Normally, you bring the data to the model: you gather everyone's records into one place and train on the pile. Federated learning brings the model to the data. A shared model is sent out to each organization, each organization trains it on its own private data inside its own systems, and only the resulting model updates, not the data, are sent back and combined. The raw records never move.
Here is the cycle in everyday terms. A coordinating server holds a starting version of the model. It sends a copy to each of the three nonprofits. Each nonprofit trains that copy on its own local data, producing a set of small numerical adjustments that describe what the model learned from their records. Those adjustments, often called gradients or weight updates, are sent back to the coordinator. The coordinator averages the updates from all three organizations into a single improved model, then sends that improved version back out for another round. After many rounds, every organization ends up with a model that has effectively learned from all three datasets, even though no organization ever saw another's data.
What Moves Between Organizations
- Model parameters and weight updates, which are numbers describing patterns
- The shared model architecture agreed on at the start
- Aggregate training metrics like accuracy and loss
What Never Moves
- Individual client records, intake notes, or case files
- Names, addresses, or any directly identifying fields
- The underlying datasets themselves, which stay on each organization's systems
Federated learning was originally developed by Google to improve phone keyboard predictions without uploading what people typed. The same principle that keeps your text messages on your phone while still improving everyone's autocomplete is what lets three nonprofits keep their case files on their own servers while still building a shared model. The technique is mature, widely deployed in healthcare and finance, and increasingly accessible to smaller organizations through open-source tools.
The Honest Caveat: Updates Can Leak, and How to Stop It
It would be dishonest to present federated learning as automatically private. The model updates that organizations send back are not raw data, but they are derived from raw data, and under certain conditions a determined adversary can partially reconstruct information about the training records from those updates. A coordinator that wanted to misbehave, or an attacker who compromised the coordinator, could in principle learn more than intended. This is the difference between data staying physically in place and data being genuinely protected. Serious federated learning deployments add two further layers to close that gap.
Secure Aggregation
So the coordinator sees only the combined result, never any single organization's update
Secure aggregation is a cryptographic protocol that lets the coordinator compute the sum or average of all the organizations' model updates without ever seeing any individual organization's contribution in the clear. Each organization masks its update with random noise that is mathematically arranged to cancel out only when all updates are added together. The coordinator receives masked values it cannot interpret on their own, and only the final aggregate emerges in readable form. This means no single organization's update is ever exposed to the coordinator or to the other participants, which dramatically reduces the risk of one party reverse-engineering another's data.
Differential Privacy
So that no individual record measurably affects the shared model
Layering differential privacy on top adds carefully calibrated statistical noise to the updates so that the presence or absence of any single individual in the training data cannot be detected from the final model. This protects against the subtle attacks where someone tries to determine whether a specific person's record was part of the training set. The trade-off is that more privacy noise can reduce model accuracy, so coalitions tune the level deliberately. For a deeper treatment of how this works and how to choose the noise level, see our guide to differential privacy for nonprofits.
The practical takeaway is that federated learning is a spectrum, not a switch. Plain federated learning keeps data in place but offers only moderate protection. Federated learning plus secure aggregation plus differential privacy approaches strong, provable privacy guarantees. Your coalition should decide early how far along this spectrum your data sensitivity requires you to go, because each additional layer adds engineering effort and a small amount of model performance cost.
Data Collaboratives and Data Trusts: The Bigger Picture
Federated learning is a technical method. It lives inside a broader set of organizational arrangements that the field calls data collaboratives and data trusts. Understanding these helps you see that the technology is only one part of the work, and arguably the smaller part. The harder questions are about governance, accountability, and who decides what.
Data Collaborative
A data collaborative is an arrangement where multiple organizations agree to combine their data, or the insights derived from it, toward a shared public-interest goal. The collaboration can take many technical forms, from a literal shared database with strict access controls to a fully federated setup where nothing is centralized. The defining feature is a joint purpose and a shared set of rules. Three nonprofits forming an agreement to build a risk model together, with documented purposes and limits, are forming a data collaborative regardless of which technology they choose underneath.
Data Trust
A data trust adds a layer of independent stewardship. A trusted third party, often with a fiduciary or legally binding duty, holds decision-making authority over how the shared data or model can be used, on behalf of the participants and sometimes on behalf of the people the data describes. Where a collaborative relies on the participants policing each other, a trust appoints a steward whose job is to enforce the agreed rules even when it is inconvenient for a participant. This structure is heavier but provides stronger accountability, which can matter when the data is highly sensitive or when the community served has reason to distrust institutions.
For a small coalition of three nonprofits, a lightweight data collaborative is usually the right starting structure. A formal data trust, with an independent steward and fiduciary duties, makes more sense once a collaboration grows beyond a handful of organizations, involves especially sensitive populations, or needs to outlive the individuals who started it. Both structures exist to answer the same underlying question: when the model trained on everyone's contributions does something good, or something harmful, who is accountable, and who gets to decide what happens next?
The Legal and Governance Scaffolding You Cannot Skip
The most common mistake coalitions make is treating this as a technology project. It is mostly a governance project that happens to involve technology. Before any code runs, the participating organizations need a set of written agreements that define what is being shared, why, under what limits, and who is responsible when something goes wrong. These documents protect the participants, the project, and most importantly the people whose lives are reflected in the data.
Memorandum of Understanding
An MOU sets the shared intent, scope, and purpose of the collaboration in plain language. It names the participating organizations, states the specific goal of the joint model, defines the boundaries of what the project will and will not do, and establishes how decisions get made. The MOU is where you write down that the model is for predicting service needs and explicitly not for any enforcement, eligibility denial, or punitive purpose. Getting this in writing early prevents mission creep, which is the slow drift from a benevolent original purpose toward uses that the founding organizations never intended and the community never agreed to.
Data-Sharing Agreement
Even in a federated setup where raw data does not move, you need a formal data-sharing or data-use agreement, because model updates are derived from protected data and applicable privacy law usually treats them carefully. This agreement specifies exactly what categories of information feed the local training, what gets exchanged between organizations, what security controls each party must maintain, how long the model and updates are retained, what happens if a participant leaves, and how the agreement aligns with each organization's existing client consent and funder obligations. It should be reviewed by counsel familiar with the relevant privacy frameworks, which for nonprofits may include HIPAA-adjacent rules, FERPA, state privacy laws, and contractual restrictions from grants.
Governance Body and Decision Rights
Name who decides. A small standing committee with one representative from each organization, meeting on a regular cadence, can handle the recurring questions that will arise: should the model be retrained, should a new partner be admitted, has a participant violated the agreement, should the project pause because of a concern. Document how the model itself is governed, including the principle that the shared model is jointly owned and that no single participant can repurpose it unilaterally. This connects directly to broader data privacy and security practices for AI that every participating organization should already have in place.
One question deserves explicit attention from the start: what do the people whose data trains the model know about this, and what would they want? Even when the law does not strictly require re-consent for federated use, the spirit of trust-based community work usually does. Coalitions that build community input into their governance, rather than treating it as a compliance afterthought, produce models that are both more legitimate and more useful, because the people closest to the problem help define what the model should actually predict.
The Open-Source Toolkits, at a High Level
You do not need to build federated learning from scratch. Several mature, free, open-source frameworks handle the hard parts of coordinating training across organizations, and a technical partner or volunteer can stand up a pilot with any of them. You do not need to evaluate all of these. The goal here is to give you enough vocabulary to have an informed conversation with whoever will implement the system.
Flower
Best general-purpose starting point
Flower is a framework-agnostic federated learning library designed to be approachable. It works with most machine learning libraries, scales from a laptop simulation to real deployments across organizations, and has strong documentation and an active community. For a small coalition running its first federated pilot, Flower is the most common recommendation because it lets you simulate the whole setup on one machine before committing to real cross-organization infrastructure.
TensorFlow Federated
Best if you already live in TensorFlow
TensorFlow Federated is Google's open-source framework for federated computation. It is powerful and well-suited to teams that already use TensorFlow and want tight integration, including built-in support for federated averaging and differential privacy. It carries a steeper learning curve than Flower and is generally a better fit when you have dedicated machine learning engineers rather than a generalist technical volunteer.
OpenMined PySyft
Best when privacy guarantees are the priority
PySyft, from the OpenMined community, focuses specifically on privacy-preserving machine learning, including federated learning, secure multi-party computation, and differential privacy. Its design philosophy centers on letting data scientists work on data they cannot see. PySyft is a strong fit when the privacy guarantees themselves are the central concern, and the community is mission-aligned with nonprofit and public-interest use.
A Word on Hosted Options
Build versus buy
Commercial and managed federated learning platforms exist and can reduce the engineering burden, but they add cost and reintroduce a vendor as a party with some level of access. For most small nonprofit coalitions, starting with an open-source framework and a trusted technical partner keeps control in your hands and budgets modest. Revisit hosted options only if the open-source path proves too operationally heavy to sustain.
Whichever toolkit you choose, the framework solves the coordination problem, not the governance problem. The software will faithfully average model updates from whoever connects to it. It has no opinion about whether those organizations agreed on purpose limits, whether the community consented, or whether the model is being used responsibly. That work remains entirely human.
When This Is Worth It, and When It Is Overkill
Federated learning is impressive, and impressiveness is a poor reason to adopt it. Many coalitions that think they need federated learning would be better served by a far simpler approach. Before committing to the complexity, honestly evaluate whether one of these lighter alternatives solves your actual problem.
Simpler Alternative: A Shared Anonymized Dataset
If each organization can strip direct identifiers and contribute a genuinely de-identified extract to a shared dataset, you can pool the data the ordinary way and train a single model with almost no special infrastructure. This is dramatically simpler than federated learning. The catch is that true anonymization is harder than it looks, because combinations of seemingly innocuous fields can re-identify individuals, especially in small populations. Done carelessly, this option offers the appearance of privacy without the substance. Done carefully, with techniques like aggregation, generalization, and added statistical noise, a shared anonymized or synthetic dataset is the right answer for a large share of coalitions, and it should be your default hypothesis until you can articulate why it fails for your case.
Simpler Alternative: A Trusted Third-Party Processor
Sometimes the cleanest path is to designate a single trusted entity, often an academic partner, a backbone nonprofit, or a vetted technical intermediary, that receives data from all participants under a strict legal agreement, trains the model in a controlled environment, and returns only the model. The data is centralized, but only briefly and only with one accountable party under enforceable terms. For coalitions where the participants trust a common intermediary, this avoids the engineering complexity of federated learning while still keeping data out of each other's hands. The trade-off is that the data does leave each organization, so this works only when consent and contracts permit it and the intermediary's security is genuinely strong.
When Federated Learning Is Genuinely the Right Choice
Reach for federated learning when several of these conditions hold at once:
- The data is too sensitive or too legally restricted to leave each organization, even de-identified, even to a trusted processor
- The data is genuinely large or high-dimensional enough that pooling would matter and anonymization would destroy too much signal
- No single party is trusted enough to be the central processor, but all parties trust a transparent shared protocol
- The collaboration is ongoing, so models will be retrained repeatedly and the infrastructure investment pays off over time
- At least one participant has, or can borrow, the technical capacity to operate it sustainably
If only one or two of these conditions apply, a simpler alternative is probably the wiser investment. Federated learning rewards coalitions with sensitive data, sustained commitment, and some technical muscle. It punishes coalitions that adopt it for novelty and then cannot keep the infrastructure running after the initial grant ends. Many of the same considerations apply to other forms of shared AI infrastructure for nonprofits, where the temptation to over-build is a recurring hazard.
The Trade-Offs to Go In With Eyes Open
No approach is free of cost. Going into a federated project understanding its real trade-offs is the difference between a coalition that succeeds and one that quietly abandons the effort after burning through its enthusiasm.
Operational and Technical Costs
- Each organization must run training locally, which requires some compute and reliable connectivity
- Datasets must be harmonized so the same fields mean the same thing across organizations
- Debugging is harder because you cannot inspect the data causing a problem
- Someone must own and maintain the coordinating infrastructure long term
Modeling and Governance Costs
- Privacy layers like added noise can reduce model accuracy, so you tune the balance deliberately
- Differences in data across organizations can make the shared model converge slowly or unevenly
- Joint ownership raises real questions about who controls and benefits from the model
- Sustaining cross-organization trust and decision-making takes ongoing relational work
A Practical Roadmap for a Small Coalition
If your coalition has decided the value is real and federated learning, or a simpler alternative, is the right fit, this phased roadmap keeps the project grounded. Notice how much of it happens before any federated code runs. That sequencing is intentional.
1Agree on the Question and the Limits
Before anything technical, get all participants in a room and define precisely what the shared model is for, who benefits, and what uses are explicitly forbidden. Write a one-page purpose statement. If you cannot agree on the question, you are not ready to share anything. This is also the moment to bring in community voice so the model predicts something the affected population actually wants predicted.
2Put the Legal Scaffolding in Place
Draft and sign the MOU and the data-sharing agreement, with counsel review, before any data touches any model. Confirm that each organization's existing client consent and funder agreements permit the intended use, and decide whether re-consent or community notification is needed. Stand up the governance committee and schedule its first meetings.
3Test the Simpler Alternatives First
Before building federated infrastructure, seriously prototype whether a shared anonymized or synthetic dataset, or a trusted third-party processor, would meet the need. If a simpler approach produces a good enough model with far less effort, take it. Reserve federated learning for the cases where you have demonstrated that the simpler options genuinely fall short.
4Simulate Before You Federate
Using a framework like Flower, build and run the entire federated setup as a simulation on a single machine, using small samples or synthetic stand-ins for each organization's data. This lets you debug the model architecture, the data harmonization, and the training process cheaply before you take on the harder problem of real cross-organization deployment. Most projects discover their hardest issues here, where they are easy to fix.
5Run a Real Pilot With Privacy Layers
Move to a real deployment where each organization trains on its own live data, with secure aggregation and, if your sensitivity warrants it, differential privacy turned on from the start rather than bolted on later. Keep the pilot scoped narrowly, monitor model performance and privacy metrics together, and document everything. Treat the first model as a learning artifact, not a production system.
6Decide Governance for the Long Term
Once the pilot proves the value, formalize how the model will be maintained, retrained, evaluated for bias and drift, and governed as participants come and go. Decide whether your collaborative should evolve toward a more formal data trust as it grows. Name owners for monitoring and for the human escalation path when the model is wrong, because a shared model that no one is accountable for is a liability, not an asset.
Conclusion: Collaboration Without Compromise
The three nonprofits at the start of this article were stuck on a false choice. They believed they had to either keep their data siloed and accept weak models, or pool their data and betray the trust and the legal commitments that make their work possible. Privacy-preserving collaboration dissolves that dilemma. Federated learning lets a model learn from everyone's data while every record stays home. Secure aggregation and differential privacy harden that promise into something defensible. Data collaboratives and trusts wrap the whole effort in accountability.
The honest message is that these techniques are powerful but not effortless, and they are not always necessary. The discipline that separates successful coalitions from stalled ones is the willingness to do the unglamorous work first: agree on the question, sign the agreements, involve the community, and seriously test whether a shared anonymized dataset or a trusted processor would solve the problem before reaching for federated infrastructure. The technology is the easy part. The governance, the trust, and the clarity of purpose are the hard parts, and they are what determine whether a shared model strengthens a community or quietly erodes its confidence.
For nonprofits, that distinction is everything. The point of building a shared model is to serve people better, and people are served best by organizations that treat their data as the trust it is. The tools now exist to collaborate without that compromise. The remaining work is choosing to use them carefully.
Exploring a Shared Model With Partner Organizations?
One Hundred Nights helps nonprofit coalitions evaluate whether federated learning is the right fit, design the governance and legal scaffolding, and stand up privacy-preserving collaborations that protect the people behind the data. Let's talk about what is possible for your partnership.