FL Assessment Tool

This questionnaire supports an internal conversation before adopting a federated learning (FL) architecture, FL lets you train shared machine-learning models across institutions while raw, sensitive data stays in its original location. We recommend working through it as a cross-functional group: IT, legal, operations, and management together.

AWhy, motivation and problem

The fundamental reasons you are considering FL instead of a traditional, centralized approach.

A1. What core problem are you trying to solve with an AI system?

For example: detecting fraud across institutions without sharing transaction records; predicting crop-disease spread across farms; coordinating energy inputs across a fragmented grid.

A2. Why is centralizing your data difficult or impossible? (select all that apply)

Privacy constraints and data-protection law (e.g. GDPR, HIPAA, NDPA) Commercial sensitivity or lack of trust between collaborating partners Fragmented infrastructure, data sits in separate silos, labs, branches or edge devices It is too costly to move the data (bandwidth or storage constraints)

A3. What primary benefit do you hope FL will bring?

More representative data, better accuracy, less algorithmic bias Personalized services directly where the data is used Faster time-to-value by avoiding a central data-extraction project

BWho, stakeholders and trust

B1. Which type of FL ecosystem best describes yours?

Cross-silo, collaborating with a few large organizations (a consortium of banks, a hospital network, agencies) Cross-device, training across many end-user devices (phones, sensors, meters)

B2. If collaborating externally, what is the level of trust between participants?

High, we already share resources freely Moderate, shared goals, but strict commercial boundaries Low, we would need an independent convenor or broker

B3. Who owns regulatory obligations, such as impact assessments?

Note: FL does not remove compliance duties, data-controllership and privacy risk still need owners.

CWhat, data and model characteristics

C1. How sensitive is the data at the local nodes?

Highly sensitive, health records, financial transactions, private communications Commercially sensitive, trade secrets, pricing, operational data Low sensitivity, mostly public or anonymised

C2. What kind of system are you looking to run?

Predictive / categorizing ML, finding patterns across distributed data (fraud detection, risk scoring, predictive maintenance) Federated analytics, statistical insights from decentralized data without training a model

DHow, deployment and security

D1. Do you have infrastructure to train models locally at the data source?

Yes, our servers/devices have sufficient compute and reliable connectivity No or not sure, connectivity is weak or devices are constrained

D2. How will you manage FL's specific security risks (inference attacks, data poisoning)?

We plan complementary privacy-enhancing technologies, differential privacy, secure aggregation, trusted execution We will monitor outliers and vet participants We need a partner to establish these guardrails

EWhere, location and control

E1. Where does the training data originate, and where must it stay?

Strictly on-premise, inside hospital networks or corporate firewalls On consumer devices spread globally Across multiple cloud environments run by different organizations

E2. Who should host the aggregation server, you, a partner, or a neutral third party?

In FL the coordinator combines updates but never sees raw data. Sovereign hosting is often a requirement in regulated sectors.

FConclusion

Your readout

Overall indication

Privacy need

Data fragmentation

Deployment readiness

Your notes (for your team discussion)

Talk to Goose FL →

This readout is indicative, not a certification. The strongest signal comes from discussing these questions across your organization, and then talking to us about the specifics.