---
title: "Cláusulas de Governança de Aprendizado Federado para Contratos SaaS Multi‑Inquilino"
---

# Cláusulas de Governança de Aprendizado Federado para Contratos SaaS Multi‑Inquilino

A rápida adoção do **aprendizado federado** (FL) em plataformas de software‑como‑serviço (SaaS) baseadas em nuvem abriu novas oportunidades para IA colaborativa, preservando a localidade dos dados. Contudo, a estrutura jurídica que tradicionalmente envolve o processamento de dados — como acordos padrão de *Data Processing Agreements* (DPAs) ou aditivos de *Machine Learning* — muitas vezes não captura o perfil de risco nuances do FL em um ambiente **multi‑inquilino**. Em um modelo SaaS multi‑inquilino, dezenas ou centenas de clientes distintos contribuem com atualizações de modelo a partir de seus conjuntos de dados privados, porém nenhum dado bruto jamais sai de suas instalações. Essa arquitetura cria um desafio híbrido de conformidade: cada inquilino deve permanecer confiante de que seus dados permanecem sob seu controle, enquanto o provedor SaaS deve garantir que os parâmetros de modelo agregados não exponham inadvertidamente informações sensíveis.

Para preencher essa lacuna, os redatores de contratos precisam de uma **Cláusula de Governança de Aprendizado Federado** (FLGC) dedicada. Diferente das cláusulas convencionais que focam em transferência, armazenamento e notificação de violação de dados, a FLGC aborda três dimensões centrais: (1) **transparência algorítmica**, (2) **salvaguardas de privacidade dos parâmetros**, e (3) **alocação de responsabilidade entre inquilinos**. A seguir, explicamos por que essas dimensões são importantes, como se relacionam com regulamentos vigentes como o *Regulamento Geral de Proteção de Dados* ([GDPR](https://gdpr.eu/)), o *National Institute of Standards and Technology* ([NIST](https://www.nist.gov/)), e a *International Organization for Standardization* ([ISO/IEC 27001](https://www.iso.org/isoiec-27001-information-security.html)), e como podem ser expressas concretamente em um modelo de contrato gerado pelo Contractize.app.

## Por que as Cláusulas Tradicionais de Processamento de Dados Falham

DPAs padrão são baseados na ideia de que um controlador de dados autoriza um processador a **mover, armazenar ou transformar** dados pessoais em seu nome. No FL, o processador (o provedor SaaS) nunca acessa diretamente os dados brutos; ele apenas orquestra uma série de **rodadas de treinamento local** e agrega pesos de modelo. Essa divergência gera duas áreas cegas jurídicas:

1. **Vazamento indireto de dados** – Ataques como **inversão de gradiente** podem reconstruir entradas brutas a partir de gradientes agregados, risco não contemplado nas cláusulas típicas de notificação de violação.
2. **Inferência entre inquilinos** – Um inquilino adversário poderia deliberadamente criar atualizações de modelo para inferir informações sobre o conjunto de dados de outro inquilino, levantando questões sobre **responsabilidade conjunta** e **uso justo**.

Consequentemente, uma FLGC robusta deve incorporar salvaguardas técnicas ao lado de garantias contratuais, criando uma **abordagem de via dupla** que satisfaça tanto auditores legais quanto engenheiros de segurança.

## Elementos Principais de uma Cláusula de Governança de Aprendizado Federado

### 1. Transparência Algorítmica e Documentação

A cláusula deve exigir que o provedor SaaS forneça um **Documento de Governança do Modelo** que detalhe o algoritmo federado, o método de agregação (ex.: FedAvg, Secure Aggregation) e as **técnicas de aprimoramento de privacidade** empregadas (ex.: privacidade diferencial, criptografia homomórfica). Essa documentação deve ser **controlada por versionamento** e disponibilizada a cada inquilino antes de cada lançamento importante. Referenciar o **gerador de cláusulas do Contractize.app** garante que atualizações se propaguem automaticamente a todos os contratos ativos.

> “O Provedor deverá manter e entregar um Documento de Governança do Modelo (o “MGD”) para cada serviço de Aprendizado Federado, descrevendo o fluxo algorítmico, a estratégia de agregação e quaisquer mecanismos de preservação de privacidade, devendo atualizar o MGD dentro de quinze (15) dias de qualquer mudança material.”

### 2. Salvaguardas de Privacidade dos Parâmetros

Controles técnicos se traduzem em garantias contratuais por meio de linguagem explícita sobre **sanitização de parâmetros**. Uma cláusula típica pode dizer:

> “O Provedor deverá implementar privacidade diferencial com um valor mínimo de ε de **0,5** (ou maior) em todas as agregações de modelo, e deverá validar que a diferença máxima entre gradientes individuais e o agregado não permite a reconstrução de dados pessoais.”

Além disso, deve ser incluído um compromisso de usar **agregação segura** (por exemplo, protocolos de criptografia multiparte) e de submeter auditorias de segurança semestrais por terceiros independentes.

### 3. Alocação de Responsabilidade entre Inquilinos

Em ambientes multi‑inquilino, a responsabilidade por infrações decorrentes de atualizações maliciosas precisa ser claramente distribuída. Uma redação sugerida:

> “Cada Inquilino será responsável por garantir que suas atualizações de modelo não contenham código ou dados que violem leis de privacidade ou que visem obter informações sobre outros Inquilinos. No caso de violação comprovada, o Inquilino infrator arcará com todas as perdas, custos e penalidades incorridas pelos demais Inquilinos e pelo Provedor.”

### 4. Conformidade Regulatória e Auditorias

Para alinhar-se ao GDPR, NIST e ISO/IEC 27001, a cláusula deve incluir:

- **Cláusulas de avaliação de impacto** (DPIA) quando houver risco elevado de re‑identificação.
- **Referência ao NIST AI RMF** para gestão de risco