Como rodar pilotos de MVP de IA em saúde e governo sem expor dados sensíveis

Nem toda técnica de proteção serve para o mesmo objetivo. Dados sintéticos funcionam bem quando você precisa testar fluxo, interface, lógica de negócio e parte da inferência com realismo suficiente, sem carregar identificadores reais. Eles são úteis quando a hipótese principal está no comportamento do produto, no desenho de prompts, na integração com processos ou na experiência do usuário, e não na precisão extrema de um campo clínico raro. Privacidade diferencial entra em cena quando você quer publicar estatísticas, treinar análises ou compartilhar saídas agregadas com menor risco de reidentificação. Ela adiciona ruído matemático controlado para dificultar a inferência sobre um indivíduo específico, o que ajuda em contextos de exploração analítica e dashboards. Já o federated learning faz sentido quando os dados não podem sair da instituição de origem, mas o modelo pode aprender localmente e consolidar parâmetros sem centralizar registros brutos. Na saúde, isso costuma aparecer em redes hospitalares, laboratórios e operadoras com múltiplas unidades. No governo, é comum em bases distribuídas entre secretarias, autarquias e municípios, onde cada ente tem restrição própria de acesso. Em ambos os casos, a decisão correta depende da pergunta do piloto: você quer provar que o modelo funciona, que o dado é suficiente, que a integração é viável ou que a operação aguenta escala? Para evitar escolhas por modismo, use um critério simples. Se a hipótese pode ser validada com volume e estrutura sem dados reais, comece com dados sintéticos. Se o risco maior é exposição estatística e você precisa compartilhar resultado agregado, considere privacidade diferencial. Se o dado precisa permanecer na origem por regra, política ou risco, avalie federated learning. E se o objetivo principal é acelerar decisão com governança, um sandbox bem desenhado costuma entregar mais valor que tentar sofisticar a privacidade cedo demais.

Em piloto com dados sensíveis, o contrato não é só uma formalidade de compra. Ele define o que pode ser tocado, o que fica proibido, quem responde por incidente e como a operação termina caso o experimento não avance. Se isso fica vago, o jurídico trava, o DPO endurece a leitura e o time técnico vira refém de interpretações diferentes. As cláusulas mais úteis costumam tratar de finalidade específica do uso do dado, minimização, retenção, descarte, suboperadores, soberania de infraestrutura, auditoria, notificação de incidente e devolução ou destruição das informações ao fim do piloto. Também vale prever direito de revisão arquitetural e evidência de segregação entre ambientes. Em projetos públicos e regulados, isso ajuda a sustentar a compra e a prestação de contas. No SLA, não olhe só para disponibilidade. Em piloto, faz mais sentido medir tempo de resposta a incidente, prazo de entrega de evidências, tempo para corrigir falha crítica, frequência de reporte executivo e aderência ao escopo do piloto. SLA bom para essa fase protege o comprador sem transformar o contrato em uma peça inviável de operar. Se você está comparando parceiros, peça também cláusulas de transição. Isso evita dependência excessiva e permite que o time interno assuma a operação depois do piloto. O contrato de saída e code escrow para squads alocados é uma referência útil para estruturar esse tipo de proteção, principalmente quando o piloto envolve software customizado, integrações e regras de negócio sensíveis.

O primeiro erro é pedir acesso total à base “só para ganhar tempo”. Em projetos sensíveis, isso quase sempre cria risco desnecessário e aumenta o número de aprovações internas. O segundo erro é usar cópias informais de dados em notebooks, pastas compartilhadas ou ambientes sem trilha de auditoria. Mesmo quando a intenção é boa, a governança fica frágil e a validação perde credibilidade. Outro problema comum é confundir prova técnica com prova de valor. Um modelo pode acertar bem uma classificação e ainda assim não encaixar no processo real, na rotina da equipe ou no orçamento da operação. Também é frequente subestimar o esforço de integração com sistemas legados, prontuário, ERP ou data warehouse. Se essa integração não entra no desenho do piloto, a decisão sobre escala fica incompleta. Há ainda um erro político que derruba muitos projetos: deixar o CTO e o lado de negócio em posições opostas. O CEO quer velocidade, o CTO quer sustentabilidade. Quando isso não é negociado desde o início, o piloto vira disputa interna. Um squad sênior dedicado ajuda justamente a mediar essa tensão e transformar o debate em arquitetura, evidência e contrato, não em opinião.