# Zrychlení provenance a souladu dat federovaného učení s Formize

Federated learning (FL) se stal de‑facto strategií pro trénování vysoce kvalitních AI modelů při zachování surových dat na zařízení. Přístup řeší mnoho problémů s ochranou soukromí, ale zároveň přináší novou sadu výzev v oblasti souladu: sledování, která data přispěla k jaké aktualizaci modelu, prokazování, že souhlas byl získán, a zajištění, že auditní stopy jsou neměnné napříč tisíci edge uzly.  

Formize, platforma s nízkým a žádným kódem pro tvorbu souladných workflow, může tuto mezeru zaplnit. Využitím dynamického formulářového enginu Formize, verzovaného schématu dat a blockchain‑podporovaných auditních stop mohou organizace **zrychlit** celý životní cyklus provenance — od sběru dat na okraji až po regulatorní reportování v cloudu — bez psaní jediného řádku kódu.

Níže prozkoumáme problémovou oblast, načrtneme praktickou architekturu a projdeme krok‑za‑krokem implementaci, kterou lze replikovat během týdnů místo měsíců.

---

## Proč je provenance dat důležitá ve federovaném učení

| Výzva | Dopad na projekty FL |
|-----------|-----------------------|
| **Regulační dohled** | [GDPR](https://gdpr.eu/), [CCPA](https://oag.ca.gov/privacy/ccpa) a sektor‑specifické předpisy ([HIPAA](https://www.hhs.gov/hipaa/index.html), FINRA) vyžadují důkaz, že osobní data byla použita zákonně. |
| **Vysvětlitelnost modelu** | Auditoři a zainteresované strany požadují sledovatelnost od výstupu modelu zpět k původnímu datovému úseku. |
| **Reakce na incident** | V případě úniku dat musíte rychle identifikovat, která edge zařízení přispěla kompromitovanými daty. |
| **Přenos dat přes hranice** | Federované učení často zasahuje více jurisdikcí; záznamy provenance usnadňují soulad s SCC a BCR. |

Bez systematického rámce provenance týmy sahají po ad‑hoc tabulkách, manuálních logech nebo vlastních databázích — každý z nich je náchylný k chybám, latenci a bezpečnostním mezerám.

---

## Formize v kostce

Formize poskytuje tři hlavní schopnosti, které přímo mapují na potřeby provenance ve FL:

1. **Dynamický tvůrce formulářů** – Vytvářejte znovupoužitelné, na schématu založené formuláře pro souhlas, označování dat a metadata aktualizací.  
2. **Neměnná auditní stopa** – Ukládejte každé odeslání formuláře do ledgeru odolného proti manipulaci (volitelně podpořeného blockchainem).  
3. **Low‑code automatizace** – Spouštějte následné akce (např. odeslání metadat do registru modelů, generování zpráv o souladu) pomocí vizuálního návrháře workflow.

Tyto schopnosti jsou dostupné přes webové UI, REST API a SDK pro Python, Java a JavaScript, což usnadňuje integraci s FL nástroji (TensorFlow Federated, PySyft, Flower).

---

## End‑to‑End architektura provenance

Níže je vysokourovňový diagram, který ukazuje, jak Formize zapadá do typického FL pipeline.

```mermaid
flowchart TD
    A["Edge zařízení – zachycení dat"] --> B["Formize souhlasový formulář"]
    B --> C["Podepsaný souhlas uložen v ledgeru"]
    C --> D["Lokální FL klient – označení dat ID souhlasu"]
    D --> E["Federovaný update (váhy modelu)"]
    E --> F["Formize metadata formulář"]
    F --> G["Neměnný log aktualizací"]
    G --> H["Centrální agregátor"]
    H --> I["Registr modelů (MLflow)"]
    I --> J["Dashboard souladu"]
```

*Všechny popisky uzlů jsou uzavřeny v uvozovkách, jak vyžaduje Mermaid.*

### Klíčové datové toky

1. **Zachycení souhlasu** – Před tím, než jakákoli senzorová data opustí zařízení, se lokálně (pomocí Formize SDK) vykreslí souhlasový formulář Formize. Uživatelský podpis a rozsah souhlasu jsou uloženy neměnně.  
2. **Označování** – FL klient připojí ID transakce souhlasu ke každému datovému balíčku, čímž vytvoří kryptografický odkaz mezi surovými daty a záznamem souhlasu.  
3. **Metadata aktualizace** – Po každém tréninkovém kole klient odešle lehký Formize formulář obsahující verzi modelu, hash dat a použité ID souhlasů.  
4. **Agregace a reportování** – Centrální server agreguje neměnné logy, napojí je na dashboard souladu a automaticky generuje regulatorně připravené zprávy (např. GDPR DSAR, FDA 21 CFR Part 11).

---

## Průvodce implementací krok za krokem

### 1. Definujte schéma souhlasu

Vytvořte Formize formulář s názvem **„FL‑Device Consent“** a následujícími poli:

| Pole | Typ | Popis |
|-------|------|-------------|
| `device_id` | Text | Jedinečný identifikátor edge zařízení |
| `user_id` | Text | Pseudonymizovaný identifikátor uživatele |
| `data_scope` | Multi‑Select | Typy dat (např. „accelerometer“, „camera“) |
| `purpose` | Text | Účel ML (např. „rozpoznávání aktivit“) |
| `expiry_date` | Date | Datum expirace souhlasu |
| `signature` | Signature | Ručně kreslený nebo digitální podpis |

Povolte **„Immutable Ledger“** a vyberte **Ethereum‑compatible** blockchain pro extra právní váhu.

### 2. Nasazení souhlasového formuláře na edge zařízení

Pomocí Formize **JavaScript SDK**:

```javascript
import { FormizeClient } from '@formize/sdk';

const client = new FormizeClient({ apiKey: 'YOUR_API_KEY' });

async function renderConsent(deviceId, userId) {
  const form = await client.getForm('FL-Device Consent');
  const prefilled = {
    device_id: deviceId,
    user_id: userId,
  };
  return client.renderForm(form.id, prefilled);
}
```

SDK kešuje formulář lokálně, což umožňuje offline vykreslení. Jakmile uživatel podepíše, SDK automaticky odešle podepsaný payload do ledgeru, až se obnoví konektivita.

### 3. Označte data ID transakce souhlasu

Když zařízení shromáždí senzorový vzorek, vypočítejte SHA‑256 hash surového payloadu a uložte spolu s ID transakce souhlasu:

```python
import hashlib
from formize_sdk import FormizeClient

def tag_data(sample, consent_tx):
    data_hash = hashlib.sha256(sample).hexdigest()
    metadata = {
        "data_hash": data_hash,
        "consent_tx": consent_tx,
        "timestamp": datetime.utcnow().isoformat()
    }
    return metadata
```

FL klient zahrnuje tato metadata do každého lokálního tréninkového balíčku.

### 4. Odeslání metadat aktualizace po každém kole

Vytvořte druhý Formize formulář **„FL‑Update Log“** s poli:

| Pole | Typ | Popis |
|-------|------|-------------|
| `model_version` | Text |
| `round_number` | Number |
| `data_hashes` | Text (JSON pole) |
| `consent_tx_ids` | Text (JSON pole) |
| `aggregator_signature` | Signature |

Po každém agregačním kole server zavolá:

```python
def submit_update_log(version, round_num, data_hashes, consent_ids):
    payload = {
        "model_version": version,
        "round_number": round_num,
        "data_hashes": json.dumps(data_hashes),
        "consent_tx_ids": json.dumps(consent_ids),
    }
    client.submit_form('FL-Update Log', payload)
```

Protože je formulář napojen na neměnný ledger, každá aktualizace se stane ověřitelným, časově razítkovaným záznamem.

### 5. Vytvořte dashboard souladu

Formize nabízí **report builder**, který může dotazovat ledger pomocí GraphQL. Vytvořte dashboard, který vizualizuje:

* Počet aktivních souhlasů podle jurisdikce  
* Heat‑mapu příspěvků dat podle typu zařízení  
* Genealogii verzí modelu (graf, který ukazuje, které souhlasy napájely kterou verzi)

Exportní možnosti zahrnují PDF, CSV a JSON, připravené pro podání regulatorům.

### 6. Automatizujte regulatorní reportování

Pomocí **workflow engine** Formize definujte trigger:

> **Když** je vytvořen nový záznam „FL‑Update Log“ **a** `round_number % 10 == 0`  
> **Pak** vygenerujte balíček GDPR DSAR a pošlete ho DPO e‑mailem.

Workflow běží na serverless runtime Formize, čímž eliminuje potřebu vlastních cron úloh.

---

## Kvantifikované přínosy

| Metrika | Tradiční přístup | FL s Formize |
|--------|----------------------|--------------------|
| **Čas nasazení workflow souhlasu** | 6–8 týdnů (vlastní UI, backend) | 2–3 dny (drag‑and‑drop) |
| **Latence auditní stopy** | Hodiny (batch upload) | Téměř v reálném čase (sekundy) |
| **Snížení nákladů na soulad** | $150 k‑$250 k ročně (právní a vývoj) | $30 k‑$50 k ročně (automatizace) |
| **Riziko nesouladu** | Vysoké (manuální chyby) | Nízké (neměnný ledger) |

---

## Nejlepší praktiky a úskalí, kterým se vyhnout

| Praxe | Proč je důležité |
|----------|----------------|
| **Verzování formulářů** | Změna schématu vytváří novou verzi smlouvy; starší záznamy zůstávají neměnné, čímž se zachovává historická integrita. |
| **Šifrování citlivých polí** | I když je ledger neměnný, šifrujte pole jako `user_id`, aby byl dodržen princip minimalizace dat. |
| **Použití edge cache** | Zařízení mohou být offline hodiny; zajistěte, aby SDK kešovalo podepsané formuláře lokálně a automaticky je opakovaně odesílalo. |
| **Periodické prořezávání ledgeru** | Pro veřejné blockchainy zvažte off‑chain ukládání velkých payloadů s on‑chain hashi, aby se kontrolovaly náklady. |
| **Integrace s registrem modelů** | Propojení logů Formize s MLflow nebo DVC poskytuje jediný zdroj pravdy pro genealogii modelu. |

---

## Budoucí rozšíření

1. **Zero‑Knowledge Proofs** – Přidat ZKP‑ověření, které dokáže zahrnutí dat bez odhalení surových hashů.  
2. **Federovaná vysvětlitelnost** – Kombinovat provenance Formize s SHAP hodnotami pro generování reportů o příspěvku jednotlivých zařízení.  
3. **AI‑driven optimalizace souhlasu** – Využít shromážděná metadata souhlasu k trénování doporučovacího systému, který navrhne optimální rozsahy souhlasu pro nová zařízení.

---

## Závěr

Federované učení slibuje AI šetřící soukromí, ale vrstvy **provenance** a **souladu** často zaostávají. Formize tuto mezeru zaplňuje tím, že promění zachycení souhlasu, logování metadat a regulatorní reportování v konfigurovatelné, low‑code zkušenosti podpořené neměnnými auditními stopami. Organizace, které tento vzor adoptují, mohou **zrychlit** nasazení FL, snížit právní rizika a dodat důvěryhodné AI modely ve velkém měřítku.

---

## Viz také

- [Google AI Blog – Federated Learning: Privacy‑Preserving Machine Learning](https://ai.googleblog.com/2020/04/federated-learning-privacy-preserving.html)  
- [European Data Protection Board – Guidelines on Consent under GDPR](https://edpb.europa.eu/our-work-tools/consultations/consent_en)  
- [MLflow – Tracking Model Lineage and Metadata](https://mlflow.org/docs/latest/tracking.html)  
- [Hyperledger Fabric – Building Immutable Audit Trails for Enterprise Applications](https://www.hyperledger.org/use/fabric)