AI researchers and practitioners are developing and releasing new systems and methods at an extremely fast pace, and it can be difficult for enterprises to gauge which particular AI technologies are most likely to help their businesses. This article — the first part of a two-part series — will try to help you determine if federated learning (FL), a fairly new piece of privacy-preserving AI technology, is appropriate for a use case you have in mind.

FL’s core purpose is to enable use of AI in situations where data privacy or confidentiality concerns currently block adoption. Let’s unpack this a bit. The purpose of AI systems/methods/algorithms is to take data and autonomously create pieces of software, AI models, that transform data into actionable insight. Modern AI methods typically require a lot of data, collect all the necessary data at some central location, and run a learning algorithm on the data to learn/create the model.

However, when that data is confidential, siloed, and owned by different entities, gathering the data at a central location is not possible. Federated learning very cleverly gets around this problem by moving the learning algorithm or code to the data, rather than bringing the data to the code.

As an example, consider the problem of creating an AI model to predict whether patients have COVID-19 given their lung CT-scans. The data for this problem, CT-scans, are obviously confidential, and are owned by various different entities — hospitals and medical and research facilities. They are also stored all across the world under very various different jurisdictions. You want to combine all of that data because you want your AI models to be able to detect all the forms in which the disease has manifested in CT-scans. However, combining all this data in the one location is not possible for obvious data confidentiality and jurisdictional reasons.

Here’s how federated learning bypasses the confidentiality issue: A worker node, which is a computing system capable of machine learning, is deployed at each hospital or facility. This worker node has full access to the confidential data at the location. During federated learning, each such worker node creates a local AI model using the data at the facility and sends over the model to the central FL server. Note that the confidential data never leaves the client site — only the model does. A central server combines all of the insights from the local models into a single global model. This global model is sent back to all the local worker nodes, which now have insights from all the other worker nodes without having seen their data. When you iterate on these steps many times, you end up with a model that is, in many cases, equivalent to a model that would have been built if you’d trained it on all the data in the same place. (See a schematic illustration of the process below.)

Federated learning was initially developed by Google as a way to train the Android keyboard app (GBoard) to predict what the user will type next. Here the confidential data being used is the text that the user is typing. However, it turns out that the data confidentiality issue appears in many guises across industries. Indeed, you will face this problem if you are

* a maker of autonomous vehicle and you want to combine confidential video and image data from across your vehicles to build a better vision system,

* a bank and want to build a machine learning based anti-money laundering system by combining data from various jurisdictions, possibly even other banks,

* a supply chain platform provider and you want to build a better risk assessment or route optimization system by combining confidential sales data from multiple businesses,

* a cell service provider and you want to build a machine learning model to optimize routes by combining confidential data from cell towers,

* a consortium of farmers and you want to build a model to detect crop disease using confidential disease data from the members of your consortium,

* a consortium of additive manufacturers and you want to build AI-based process controllers and quality assurance systems using confidential build data from members of your consortium.

An important point to note about the above examples is that the owner of the data can be different units of the same organization but in different jurisdictions (as in the bank and cell service provider examples) or clients of the same organization (as in the autonomous vehicle maker and supply chain service provider examples), or completely independent units (as in the consortium of farmers and additive manufacturer examples above, and the hospitals/COVID-19 example described earlier).

You can use the following checklist to see if federated learning makes sense for you:

I will end by emphasizing that, if you are able to combine your data into a central location, you should probably go for that option (barring cases where you want to, for instance, future-proof your solution). Centralizing your data may make for better final model performance than you’ll be able to achieve with federated learning, and the effort required to deploy an AI solution will be significantly lower. However, if it turns out that FL is just what you need to remove your barrier to AI adoption, part two of this series will provide you with an overview of how to do that.

M M Hassan Mahmud is a Senior AI and Machine Learning Technologist at Digital Catapult, with a background in machine learning within academia and industry.

VentureBeat is always looking for insightful guest posts related to enterprise data technology and strategy.