A Opção de Exclusão de IA Que Não Existe: O Que Encontrámos ao Verificar 17 Plataformas SaaS

Todas as plataformas SaaS a que ligou o seu negócio estão, neste preciso momento, silenciosamente a decidir se o seu conteúdo treina o modelo de IA de outra empresa. Verificámos as 17 plataformas da biblioteca de conectores da 8200.dev para perceber como cada uma delas trata efetivamente esta questão — esperando encontrar interruptores de administração. Na maioria dos casos, não encontrámos.

Eis o que descobrimos. O Slack inclui, por defeito, todos os workspaces no treino de modelos não-generativos — não existe qualquer interruptor na consola de administração; excluir-se implica que o proprietário do workspace envie um e-mail para [email protected] com uma linha de assunto específica, sem qualquer registo que possa ser verificado posteriormente. O Salesforce tem uma definição real, mas trata-se de um interruptor do Einstein GPT escondido no Setup, algo que a maioria dos administradores não sabe sequer procurar — e chegar até ele pode exigir a abertura de um caso de suporte, consoante a edição. No Zendesk, a versão é simplesmente um pedido de suporte, sem mais. O Fin AI do Intercom tem uma opção de exclusão ao nível do workspace, mas esta reside na interface, não na API — ninguém fora da sua consola de administração consegue verificar se está de facto ativada.

O Dropbox é o caso mais interessante: as contas dos EUA estão, por defeito, incluídas em funcionalidades de IA de terceiros; as contas da UE, Reino Unido e Canadá estão, por defeito, EXCLUÍDAS. Mesmo produto, mesma empresa, defeitos opostos, consoante o local de registo da conta — e a maioria das equipas nunca verificou qual se aplica ao seu caso. O WhatsApp Business também é regional: existe um formulário de objeção para a UE, Reino Unido e Brasil; em qualquer outro lugar, simplesmente não há qualquer alavanca a acionar.

Por outro lado, algumas plataformas genuinamente não utilizam o seu conteúdo para treino — trata-se de um compromisso contratual, não de uma definição: Google Workspace, Microsoft 365, Box, Notion e GCP enquadram-se todas aqui. Isto é tranquilizador, mas também não é algo que se possa verificar clicando na sua própria consola de administração — está a confiar na palavra do fornecedor quanto a um compromisso enterrado num acordo de tratamento de dados que quase ninguém lê para além da primeira página.

O padrão em todos estes casos: fora do Jira e de alguns interruptores de funcionalidades de IA adjacentes (a correspondência de código público do GitHub Copilot, as políticas organizacionais do GCP Vertex), praticamente não há para onde apontar uma API e obter uma resposta clara. E é precisamente por isso que esta verificação tem de ser feita plataforma a plataforma, manualmente, uma vez — e depois assinalada automaticamente sempre que ligar uma nova plataforma, em vez de confiar que alguém na sua equipa já leu a letra pequena.

Porque é que "alguém devia verificar isto" falha silenciosamente

A razão pela qual este problema se prolonga não é negligência. É que o controlo habitual — atribuir a tarefa a uma pessoa, dizer-lhe para verificar — não tem para onde apontar.

Observe novamente a lista acima e repare no que todas as entradas têm em comum: a postura reside num local que um painel de controlo não consegue ver. Numa cláusula contratual. Num valor regional por defeito definido no registo. Num escalão de plano que mudou na última renovação feita pelo departamento de compras. Num endereço de e-mail para o qual é preciso escrever. Não existe um único ecrã, em nenhuma destas plataformas, que responda à única pergunta que uma equipa de segurança realmente precisa de ver respondida — *a minha organização está, neste momento, a contribuir com dados de treino, e decidimos isso de propósito?*

Assim, a verificação é adiada, depois esquecida, depois herdada. O valor por defeito vence por desgaste. E esse valor por defeito foi escrito pelo fornecedor, otimizado para o roteiro de IA do fornecedor, não para as suas obrigações de tratamento de dados. Trata-se da mesma dinâmica que abordámos para uma única plataforma em o que muda no Atlassian Jira a 17 de agosto — exceto que não se trata de uma única plataforma. É cada ferramenta ligada a tomar a sua própria versão da decisão, no seu próprio calendário, no seu próprio esconderijo.

Isto é uma questão de conformidade, não de curiosidade

Se a sua organização detém um relatório SOC 2, está a trabalhar rumo à ISO 27001, ou trata dados pessoais ao abrigo do RGPD, a contribuição de dados incide diretamente sobre obrigações que já assume.

Um acordo de tratamento de dados descreve as finalidades para as quais os seus dados podem ser utilizados. Treinar um modelo de IA de terceiros é uma finalidade. Se o acordo de tratamento de dados de um cliente afirma que os dados são utilizados para prestar o serviço, e uma das plataformas ligadas à sua organização está silenciosamente a alimentar esses mesmos dados no treino de modelos, a lacuna entre o que prometeu a jusante e o que permite a montante é sua a fechar — não do fornecedor. Os auditores começaram a perguntar diretamente sobre isto, geralmente sob alguma forma de "algum dos vossos subprocessadores treina IA com os vossos dados, e como é que sabem?" Uma resposta defensável tem duas partes: a postura (que plataformas contribuem, quais estão contratualmente excluídas) e o registo da decisão (quem a analisou, quando e o que decidiu). "Nunca verificámos" é a única resposta que falha por completo. Abordámos o que os auditores esperam atualmente em o que os auditores realmente exigem em matéria de governação de IA em 2026; a contribuição de dados está a tornar-se um item de verificação padrão precisamente nessa análise.

A auditoria pontual que vale a pena realizar agora

A boa notícia é que este é um dos raros itens de governação em que a correção é genuinamente barata. Não é preciso reestruturar nada. É preciso encontrar as definições, decidir com intenção e registar por escrito a decisão. Concretamente:

1. Faça o inventário da superfície. Liste todas as plataformas SaaS onde o conteúdo ou os metadados da sua organização realmente residem. Se armazenar dados de clientes, dados regulados ou qualquer coisa sob acordo de confidencialidade, está no âmbito — não apenas a ferramenta que lhe enviou um e-mail esta semana.
2. Encontre a postura de cada plataforma. Por vezes é uma página de definições, por vezes um pedido de suporte, por vezes uma opção de exclusão por e-mail, por vezes uma cláusula contratual sem qualquer controlo. Registe onde reside.
3. Confirme o escalão. Em várias plataformas, a postura depende do escalão — o GitHub exclui os dados dos planos Business e Enterprise do treino, enquanto os escalões inferiores ficam sujeitos a termos mais amplos, e uma migração pode alterar silenciosamente a sua postura.
4. Decida deliberadamente. Aceitar a inclusão pode ser uma escolha legítima; funcionalidades de IA melhores são um benefício real. O modo de falha não é a contribuição — é a contribuição que ninguém decidiu. Exclua o que for sensível e, depois, deixe o resto seguir se essa for a sua decisão.
5. Registe por escrito e reverifique periodicamente. Uma nota datada transforma um valor por defeito silencioso em prova de governação, e os fornecedores alteram os valores por defeito com frequência suficiente para que uma postura verificada uma única vez não seja uma postura gerida.

A descrição honesta dessa lista é *recorrente, transversal a plataformas, e maçadora* — precisamente o tipo de controlo que se degrada quando depende de um ser humano se lembrar.

Como isto se apresentou quando aplicámos esta verificação a nós próprios

A 31 de julho de 2026, abrimos a consola de administração da nossa própria organização no Atlassian e percorremos os cinco passos acima. Reportar o resultado com precisão importa, porque funciona nos dois sentidos.

O controlo ao nível da organização já estava desativado. Atlassian Administration → Security → Data contribution oferece uma única opção de Ligado/Desligado para toda a organização — não uma por produto — e a nossa estava definida como Desligado, com uma lista de inclusão vazia, pelo que nada tinha sido seletivamente reincluído. Nada a corrigir. É isso que parece um bom valor por defeito, ou uma boa decisão anterior.

Depois há a frase impressa diretamente por baixo desse controlo: *"Os metadados são sempre contribuídos."* O interruptor que tínhamos definido rege o conteúdo dentro da aplicação — o que as pessoas escrevem em tickets e páginas. Os metadados estão fora desse âmbito, e no nosso plano a página não oferece qualquer controlo para eles. A nossa subscrição do Jira é Premium; a exclusão total de metadados é uma capacidade exclusiva do Cloud Enterprise. Um aviso presente em todos os ecrãs de administração indica a data em que a alteração entra em vigor: 17 de agosto de 2026.

Assim, uma organização que já tinha tomado a decisão deliberada, num escalão pago, ainda assim não conseguiu excluir-se por completo — e a única forma de o saber foi ler uma linha de texto numa página de definições que não havia razão particular para revisitar. Entretanto, o Bitbucket e o Trello são faturados separadamente e ficam totalmente fora dessa página; seja qual for a sua postura, trata-se de uma verificação diferente, num ecrã diferente.

Nada disto é uma crítica ao Atlassian, que pelo menos disponibiliza o controlo, declara o limite claramente e publica a data. É o argumento deste artigo, demonstrado sobre nós próprios: a decisão e os seus limites residem onde nenhum painel de controlo os mostra, e "desativámo-lo" não é o mesmo que "não estamos a contribuir".

Como a 8200.dev expõe isto automaticamente

A 8200.dev gera agora uma constatação sobre a postura de treino de IA para cada plataforma que ligar. Ligue o Slack, o Dropbox, o Salesforce, o GitHub, ou qualquer uma das outras plataformas suportadas, e a verificação indica-lhe — mesmo ao lado das constatações sobre partilha e permissões — se esse fornecedor utiliza os seus dados para treino de IA por defeito, onde reside a opção de exclusão ou a garantia contratual, e quando essa postura foi verificada pela última vez. As plataformas com inclusão por defeito surgem como constatações que exigem uma decisão; as plataformas contratualmente seguras surgem como atestações que pode entregar a um auditor.

Quando uma plataforma expõe de facto uma política legível por API num eixo vizinho, verificamo-la em tempo real: o conector do GitHub lê a definição de correspondência de código público do Copilot da sua organização, e o conector do GCP assinala quando o Vertex AI está a funcionar sem qualquer política organizacional a restringi-lo. Todas as constatações são acompanhadas por um manual de correção passo a passo, e o catálogo completo de verificações está disponível na página de funcionalidades.

O objetivo não é dizer que as funcionalidades de IA são perigosas — muitas valem a pena ativar. O objetivo é que a contribuição de dados seja uma decisão, não um valor por defeito, em cada plataforma que a sua organização já utiliza. Se preferir que isto seja exposto automaticamente em vez de depender de ser lembrado manualmente, consulte os planos e preços e ligue a sua primeira plataforma em poucos minutos.