Governance, Approval, and Cost Considerations
10.1 Governance checkpoints
Section titled “10.1 Governance checkpoints”| Checkpoint | Key questions |
|---|---|
| Use-case approval | What problem is being solved, why is FL needed, and what alternatives were considered? |
| Data protection review | What data is used, what leaves each participant, what risks remain, and what controls are applied? |
| Security review | How are participants authenticated, how are systems hardened, and how are incidents handled? |
| Participant agreement | Who can join, what must they contribute, who owns the model, and what happens if a participant exits? |
| Model governance | Who can access, deploy, monitor, retrain, or retire the model? |
| Operational readiness | Who operates the system, who is on call, what is logged, and how are failures handled? |
| Production release | Have performance, privacy, security, and governance criteria been met? |
The governance process should identify the decisions that require formal sign-off, including use-case approval, participant admission, privacy-control selection, model release, production deployment, and any residual-risk acceptance.
10.2 Federation agreement topics
Section titled “10.2 Federation agreement topics”-
Purpose of the federation and permitted use of the trained model.
-
Participant admission, suspension, and exit procedures.
-
Minimum data quality, schema, and contribution expectations.
-
Infrastructure and security responsibilities for each participant.
-
Access rights to the global model, local models, metrics, logs, and outputs.
-
Treatment of intellectual property, derived models, and publication rights.
-
Incident response, breach notification, and points of contact.
-
Retraining, model retirement, and deletion of intermediate artefacts where required.
-
Balanced participation expectations, including how to handle low-quality, stale, or minimal updates.
10.3 Cost drivers
Section titled “10.3 Cost drivers”FL costs should be estimated by drivers rather than by a fixed monthly number. Actual costs depend heavily on the number of participants, model size, training frequency, GPU requirements, data volume, logging retention, security controls, and the level of production hardening required.
| Cost driver | Why it matters | How to manage it |
|---|---|---|
| Number of client nodes | Each participant may require a client environment, certificates, storage, monitoring, and support. | Start with two or three participants. Add participants only after onboarding and support are stable. |
| Coordinator infrastructure | Requires compute, networking, storage, certificates, logging, and access controls. | Keep starter deployment small and scale after measuring actual load. |
| Client compute | Local training cost varies by data volume, model size, and GPU needs. | Use CPU-friendly baselines early. Add GPUs only where justified. |
| Model size and update payloads | Larger models increase compute, network transfer, aggregation overhead, and storage. | Use the smallest suitable model and track update size. |
| Training rounds and epochs | More rounds increase compute, time, logging, and privacy-budget use. | Set round budgets, stopping criteria, and maximum runtime. |
| Secure aggregation and DP | Controls add computation, coordination, and experimentation overhead. | Test controls on synthetic data and record utility impact. |
| Logging and retention | Production logs and audit evidence can become significant. | Separate operational and debug logs; apply retention policies. |
| Security and assurance | Architecture review, VAPT, container scanning, and incident planning cost time and money. | Budget assurance early and do not leave it to final release. |
| Operational support | Production needs runbooks, on-call, retraining, incident response, and participant coordination. | Assign owners before production and include support in sponsor budget. |
An indicative itemised estimate for a five-client AWS/GCC reference deployment is provided in Appendix F. It should be treated as an order-of-magnitude planning reference and updated against the actual deployment, current pricing, procurement assumptions, exchange rates, and assurance requirements before sponsor approval.
10.4 Production readiness criteria
Section titled “10.4 Production readiness criteria”-
The use case has a documented FL suitability decision and alternative approaches were considered.
-
Each participant has approved its local data use and operating responsibilities.
-
The deployment has passed security review against the organisation’s cloud and cybersecurity standards.
-
The privacy controls and residual risks have been reviewed by the relevant governance owners.
-
The model has passed agreed performance, fairness, robustness, and privacy-test criteria.
-
Monitoring, alerting, incident response, rollback, and retraining responsibilities are assigned.
-
The model access, export, and lifecycle rules are documented and enforceable.
-
Backups, rollback, CA rollover, and DR drill procedures have been tested or scheduled before production reliance.
Production readiness should be supported by an evidence pack covering architecture, approved participants, data manifests, training configuration, privacy settings, security review, test results, model evaluation, monitoring, rollback, incident response, and cost approval. Detailed evidence templates should be maintained in the repository.