Uma ferramenta de IA não é segura ou insegura em abstrato. O risco depende do caso de uso, tipo de conta, plano, dados inseridos, rota do modelo, integrações, permissões, localização, retenção, contrato e decisões tomadas a partir do output. O mesmo produto pode ser razoável para drafts de marketing públicos e inaceitável para prontuários de pacientes, resultados financeiros não divulgados, credenciais de produção ou decisões de emprego.
Este guia apresenta um processo prático de análise de fornecedores para equipes adotando assistentes, geradores, tools de programação, gravadores de reuniões, Agents, produtos de pesquisa e plataformas de análise de dados. Não é aconselhamento jurídico nem substitui análise qualificada de privacidade, segurança, compra, emprego, medicina, finanças ou regulamentação. Obrigações aplicáveis variam conforme jurisdição, setor, dados e uso.
O objetivo não é colecionar o maior número de selos de segurança. É produzir uma decisão sustentada por evidências: o que pode ser usado, por quem, com quais dados, sob quais controles, por quanto tempo e o que deve acontecer quando a tool muda ou ocorre um incidente.
Comece pelo caso de uso, não pelo questionário do fornecedor
Escreva um registro de uma página sobre o caso de uso antes de ler afirmações de marketing. Identifique responsável do negócio, usuários, pessoas afetadas, tarefa pretendida, dados de input, sistemas conectados, output gerado, revisor humano, decisão downstream, volume esperado e consequência da falha.
Classifique os dados de maior risco que poderiam entrar no workflow, não apenas a amostra mostrada na demo. Considere dados pessoais, informações de saúde e biométricas, dados de crianças, registros financeiros, material jurídico, informações confidenciais de clientes, comunicações de funcionários, source code, secrets, estratégia não divulgada, conteúdo licenciado, dados de pesquisa e dados sujeitos a restrições de residência ou contrato.
Então defina o limite de aprovação. Um produto pode ser aprovado para pesquisa em fontes públicas, mas proibido para trabalho não publicado de clientes. Um assistente de programação pode ser permitido em repositório isolado, mas não em ambiente de pagamentos. Um assistente de reuniões pode ser permitido para chamadas internas de projeto após aviso, mas bloqueado para reuniões clínicas, de RH, jurídicas ou do conselho.
O AI Risk Management Framework do NIST organiza o trabalho contínuo em Governar, Mapear, Medir e Gerenciar. Essa estrutura é mais útil que um checklist único de aprovado/reprovado, porque o risco muda durante implantação e uso.
Mapeie o fluxo real de dados
Desenhe todo sistema que pode receber ou derivar informação:
- navegador, desktop, mobile, extension, add-in, bot, API, CLI, servidor MCP ou cliente Slack;
- perfil da conta, prompts, arquivos enviados, repositórios de origem, áudio de reuniões, imagens, schemas de bancos de dados e credenciais;
- índice de recuperação, embeddings, processamento temporário, armazenamento do produto, caches, logs, analytics, feedback, monitoramento de abuso e sistemas de suporte;
- modelos próprios, fornecedores de modelos de terceiros, provedores de OCR ou transcrição, serviços de busca, infraestrutura de nuvem e outros subprocessadores;
- outputs gerados, exportações, links compartilhados, páginas públicas, webhooks, apps conectados, relatórios agendados, backups e armazenamento de itens excluídos.
Não pare em “o fornecedor usa criptografia”. Pergunte qual serviço recebe cada classe de dados, para qual finalidade, sob qual conta e acordo e por quanto tempo cada cópia permanece. Uma promessa de não treinamento responde a uma questão de finalidade; não responde sobre armazenamento, logs, review humano, divulgação legal, analytics, backup ou exclusão.
Teste todas as interfaces separadamente. Uma conta web de consumidor, workspace enterprise, API, GPT personalizado, extension de navegador, app mobile e integração conectada de terceiros podem ter fornecedores, configurações, retenção e termos diferentes, mesmo quando carregam a mesma marca.
Verifique conta, plano e acordo controladores
Identifique quem possui a conta e qual entidade jurídica fornece o serviço. Registre nome do plano, rota de cobrança, região, tenant, administradores, termos aceitos, formulário de pedido, aditivo de processamento de dados, anexo de segurança, acordo de nível de serviço, acordo de associado comercial quando relevante e toda alteração negociada.
Afirmações específicas do plano importam. “Dados enterprise não são usados para treinamento por padrão” não comprova o mesmo tratamento para uma conta gratuita. Uma página geral de segurança pode entrar em conflito com artigo de ajuda do produto ou política de privacidade antiga. Peça ao fornecedor que resolva inconsistências materiais por escrito e anexe a resposta ao registro da decisão.
Não dependa de uma mensagem do vendedor se o contrato disser algo diferente. Estabeleça uma hierarquia de evidência: acordo assinado e formulário de pedido, termos atuais específicos do plano, documentação oficial atual de segurança e privacidade, material oficial de ajuda e, por fim, páginas de marketing. Análises de terceiros e snippets de busca são pistas, não evidência controladora.
Verifique comportamento de renovação e downgrade. Controles enterprise de privacidade, retenção, SSO, auditoria ou região podem desaparecer quando um trial termina ou o workspace muda de plano.
Faça perguntas de privacidade por finalidade dos dados
Use uma tabela que separe questões que fornecedores frequentemente juntam:
| Pergunta | Evidência a solicitar | Erro comum | | --- | --- | --- | | Quais dados são coletados? | Inventário de campos e eventos cobrindo prompts, arquivos, output, metadados, analytics, feedback e integrações | Analisar apenas conteúdo enviado | | Por que cada tipo de dado é processado? | Tabela de finalidades para entrega do serviço, segurança, analytics, melhoria, treinamento, suporte e conformidade jurídica | Tratar “melhorar serviços” como finalidade precisa | | Dados são usados para treinar modelos? | Termos específicos do plano para treinamento próprio e por terceiros, padrões, opt-out e data de vigência | Presumir que não treinamento significa não armazenamento | | Quais fornecedores recebem conteúdo? | Lista atual de subprocessadores e provedores de modelos com serviço, local e processo de aviso | Analisar apenas o fornecedor contratado | | Por quanto tempo cada cópia é retida? | Cronograma para prompts, arquivos, output, logs, feedback, suporte, embeddings, backups e dados do fornecedor | Aceitar um prazo de retenção para todo armazenamento | | Como dados são excluídos? | Processo de exclusão pelo usuário, admin, API, conta, backup, fornecedor e término do contrato | Presumir que excluir um chat remove todos os dados derivados | | Onde dados são processados? | Regiões de armazenamento e processamento, mecanismo de transferência, suporte remoto e locais dos fornecedores | Confundir região de armazenamento com todo o processamento | | Quais direitos os usuários podem exercer? | Acesso, correção, exclusão, objeção, restrição, portabilidade e processo de contato quando aplicável | Presumir que o fornecedor trata automaticamente os avisos do cliente |
O Privacy Framework do NIST distingue risco de privacidade de risco de cibersegurança e usa resultados de Identificar, Governar, Controlar, Comunicar e Proteger. Um sistema pode estar bem protegido contra invasão e ainda criar dano à privacidade por coleta excessiva, uso inesperado, inferência incorreta ou decisão opaca.
Separe treinamento, inferência, logs e feedback
“Não treinamos com seus dados” pode significar várias coisas. Determine se cobre modelos fundamentais do fornecedor, modelos específicos do produto, provedores de terceiros, fine-tuning, avaliação, review humano, monitoramento de abuso, índices de recuperação e analytics. Confira se a proteção é padrão, configuração, opt-out ou apenas termo contratual enterprise.
A inferência ainda exige que conteúdo chegue a um modelo ou serviço de processamento. Um provedor pode operar com retenção zero, reter dados temporariamente para monitorar abuso ou mantê-los sob outro acordo de API. Um modelo premium habilitado pelo administrador pode usar uma rota diferente do modelo padrão.
Feedback frequentemente muda a regra. Enviar thumbs-down, ticket de suporte, conversa compartilhada ou log de diagnóstico pode autorizar coleta do prompt, arquivo, output e contexto ao redor para review. Documente isso para usuários e desative compartilhamento opcional de feedback quando o risco exigir.
Nunca reescreva “não usado para treinar” como “não armazenado”, “privado”, “não visualizado” ou “não enviado a terceiros”. Cada afirmação exige evidência separada.
Analise controles de acesso, identidade e tenant
Para uso em equipe, teste identidade em vez de aceitar uma lista de recursos. Confirme protocolo SSO, autenticação multifator, captura de domínio, provisionamento just-in-time, SCIM, design de roles, restrições de convidados, duração da sessão, políticas de dispositivo ou rede, contas de serviço, chaves de API, escopos OAuth e acesso administrativo de emergência.
Use privilégio mínimo. Um Agent de pesquisa não precisa de acesso de escrita a banco de dados de produção. Um assistente de programação não deve receber secrets de nuvem porque consegue ler um repositório. Um bot de reunião não precisa de todo evento do calendário. Uma tarefa de enriquecimento de planilha não deve herdar acesso a todos os registros de clientes conectados.
Analise limites do tenant e padrões de compartilhamento. Teste criação de links públicos, indexação em busca, descoberta em todo o workspace, exportações, duplicação, convidados externos, transferência de propriedade, revogação, cópias em cache e offboarding de funcionários. Confirme se um administrador pode inspecionar, exportar, reter e excluir conversas de usuários.
Logs de auditoria devem conter eventos úteis: login, mudança administrativa, autorização de integração, exportação de dados, compartilhamento público, ação com chave de API, mudança de role, exclusão, execução de Agent e atividade sensível de connector. Verifique retenção, formato de exportação, alertas e quem pode adulterar o log.
Trate Agents e tools conectadas como software privilegiado
Um assistente que apenas cria drafts de texto tem uma superfície de ação menor que um Agent que lê email, consulta warehouse, edita código, cria contas, publica site, envia mensagens ou movimenta dinheiro. Inventarie toda tool, credencial, schema, ação, etapa de aprovação, destino de rede e canal de output.
O Top 10 para apps de LLM e IA generativa da OWASP destaca prompt injection, divulgação de informação sensível, risco de supply chain, tratamento inadequado de output, agência excessiva e outras falhas no nível do app. Uma instrução maliciosa pode chegar por página web, email, PDF, comentário de código, linha de banco de dados, evento de calendário ou documento recuperado, não apenas pelo prompt do usuário.
Use ações em allowlist, credenciais read-only, schemas restritos, código em sandbox, validação de URLs e arquivos, encoding de output, limites de taxa e custo e aprovação humana para ações irreversíveis ou externas. Mantenha secrets fora de prompts e código gerado. Não permita que output do modelo se torne instrução SQL, comando shell, fragmento HTML, mudança de permissão ou mensagem externa sem validação adequada à consequência.
Teste prompt injection indireto com arquivo ou página controlados que instruam o Agent a ignorar sua tarefa, revelar um valor canário, acessar outra fonte ou enviar dados a outro lugar. O resultado esperado é contenção, não apenas uma recusa educada na janela do chat.
Entenda o que certificações comprovam e o que não comprovam
Relatórios SOC 2, certificados ISO, penetration tests, trust centers, declarações de criptografia, bug bounties e atestados de conformidade podem oferecer evidência útil. Não comprovam que toda interface de produto, plano, subprocessor, modelo de IA, integração ou configuração do cliente está coberta.
Peça escopo, período, entidade jurídica, limites do serviço, exceções, controles complementares da entidade usuária, auditor e status de correção. Um relatório SOC 2 Type II descreve controles em um período dentro do escopo; o logo sozinho não mostra o conteúdo do relatório. Um penetration test é uma amostra datada, não ausência permanente de vulnerabilidades.
Criptografia em repouso e em trânsito é evidência básica, não análise completa de arquitetura. Pergunte sobre propriedade e rotação de chaves, criptografia de backups, isolamento de tenants, gerenciamento de secrets, separação de ambientes, desenvolvimento seguro, varredura de dependências, resposta a vulnerabilidades, recuperação de desastre e acesso administrativo.
Confirme se chaves gerenciadas pelo cliente ou BYOK cobrem dados armazenados do produto, inferência do modelo ou apenas uma camada. BYOK pode transferir custo do modelo e visibilidade do fornecedor sem remover logs, dados recuperados ou armazenamento do app do fornecedor.
Teste retenção e exclusão de ponta a ponta
Crie uma tabela de ciclo de vida para cada armazenamento: criado, ativo, arquivado, exportado, compartilhado, excluído, conta encerrada, contrato terminado, backup expirado e legal hold. Identifique quem pode acionar cada etapa e a evidência retornada.
Execute um teste de exclusão com dados canário sintéticos. Envie um arquivo com nome único, crie uma conversa e artifact derivado, compartilhe-o, exporte-o, exclua a fonte, remova o usuário e então feche o workspace se o piloto permitir. Confira interface do usuário, API, link compartilhado, busca, integrações, visão do administrador, rota de suporte e confirmação contratual de exclusão.
Perda imediata de acesso pelo usuário não é o mesmo que exclusão física. Um serviço pode reter cópias de recuperação, logs de segurança, registros de cobrança ou dados do fornecedor por períodos definidos. Isso pode ser legítimo, mas cronograma, finalidade, acesso e eliminação final precisam ser documentados.
Teste também portabilidade. Antes de aprovar uma dependência operacional, exporte prompts, identifiers das fontes, arquivos, código, workflows, decisões, logs e configurações em formatos utilizáveis. Uma análise de privacidade não deve criar um problema evitável de lock-in.
Trate transparência, uso lícito e pessoas afetadas
Se houver dados pessoais, identifique o papel da organização, finalidade, base legal quando exigida, categorias de dados, pessoas afetadas, avisos, processo de direitos, retenção, destinatários, transferências e se é necessária uma avaliação de impacto sobre proteção de dados. As obrigações de proteção de dados da Comissão Europeia e a orientação de transparência em IA do ICO oferecem pontos de partida oficiais, mas consultoria jurídica local deve determinar a aplicabilidade.
Consentimento para gravar uma reunião não é consentimento para todo uso posterior da transcrição. Permissão para acessar um documento não é permissão para treinar um modelo, publicar um resumo gerado ou compartilhá-lo com outro fornecedor. Uma página web pública não está automaticamente livre de restrições de direitos autorais, contrato ou dados pessoais.
Uso de alto impacto exige análise adicional. Decisões de emprego, crédito, moradia, educação, saúde, direito, seguros, biometria, segurança e acesso podem acionar requisitos especializados e danos materiais. Não use output de uma IA de uso geral como única base da decisão. Defina autoridade humana, recurso, correção, testes, documentação e condições de parada.
O EU AI Act usa uma estrutura baseada em risco com requisitos que dependem do sistema e papel. Não rotule um workflow como “em conformidade com o AI Act” com base em um selo do fornecedor; classifique o uso, identifique se a organização é provider, deployer, importer ou distributor quando aplicável e verifique cronograma e obrigações atuais.
Avalie afirmações do fornecedor e risco do output
A FTC orienta empresas a cumprir promessas de privacidade e manter segurança adequada aos dados que possuem. Sua orientação Start with Security enfatiza saber quais dados são mantidos, conservar apenas o necessário, controlar acesso, proteger fornecedores, manter proteções e planejar incidentes.
Exija evidência para afirmações como “anônimo”, “retenção zero”, “HIPAA compliant”, “GDPR compliant”, “seguro para empresas”, “nunca treina” ou “precisão em nível humano”. Pergunte que conta, recurso, dado, período e contrato a afirmação cobre. Evite transformar uma declaração do produto em uma declaração editorial mais ampla.
A análise de segurança deve incluir o output. Código gerado pode introduzir vulnerabilidades; uma resposta de pesquisa pode inventar citação; uma imagem pode revelar material privado de origem; um resumo pode expor fato confidencial; uma automação pode enviar o registro errado. Defina validação, moderação, proveniência, aprovação, monitoramento e rollback para o destino real do output.
Execute um piloto controlado com dados canário
Use dados públicos, sintéticos ou construídos deliberadamente até a análise passar. Crie valores canário que nunca devem aparecer fora do documento, tenant, role ou tarefa designados. Não use secrets reais nem dados pessoais como marcadores de teste.
Teste pelo menos estes cenários:
- Uma tarefa normal com output correto conhecido e revisor documentado.
- Um usuário sem permissão tenta encontrar, exportar ou compartilhar conteúdo restrito.
- Um arquivo recuperado contém prompt injection indireto e pedido para expor um canário.
- Uma ação gerada tenta exceder escopo read-only, domínios permitidos, custo ou limites de destinatários.
- O usuário exclui dados de origem, conteúdo derivado, links compartilhados e a conta.
- Um administrador remove um usuário, gira uma credencial, revoga uma integração e analisa logs.
- Um fornecedor, modelo, termo de privacidade, subprocessor ou configuração de plano muda.
Registre evidência, não apenas “passou”. Salve screenshots ou exportações quando permitido, timestamps de eventos, entradas de log, request IDs, confirmações de exclusão, versões de políticas, revisor, lacunas não resolvidas, controles compensatórios e data de expiração da aprovação.
Produza uma decisão de aprovação delimitada
Uma decisão útil tem um de quatro resultados:
- aprovado para usuários, planos, classes de dados, integrações e finalidades nomeados;
- aprovado com controles, como proibição de dados sensíveis, acesso read-only, review humano obrigatório ou compartilhamento desativado;
- apenas piloto até chegar evidência ou termos contratuais especificados;
- rejeitado para o uso proposto, com motivo e gatilho de reavaliação.
Liste usos proibidos explicitamente. Atribua responsável do negócio, responsável técnico, contato de privacidade ou jurídico, contato de segurança, data de review, canal de incidentes e processo de offboarding. Usuários precisam de uma política operacional curta, não de todo arquivo do fornecedor.
A aprovação expira quando um fato material muda: propriedade, termos, política de privacidade, fornecedor do modelo, padrão de treinamento, subprocessor, região, incidente de segurança, escopo da integração, arquitetura do produto, caso de uso ou sensibilidade dos dados. Analise tools de alto risco com mais frequência que utilitários de conteúdo público.
Checklist compacto de compra
Antes da produção, confirme que a equipe consegue responder a tudo a seguir com evidência atual:
- Qual uso e quais dados exatos são aprovados, e o que é proibido?
- Quais conta, plano, tenant, entidade jurídica, região e acordos controlam?
- Para onde vão prompts, arquivos, metadados, output, logs, feedback e backups?
- Quais fornecedores e provedores de modelos os recebem, para quais finalidades e por quanto tempo?
- Quais são as configurações padrão e opcionais de treinamento, retenção, review humano e feedback?
- Administradores podem impor identidade, privilégio mínimo, compartilhamento, connectors, Agents, gastos e controles de auditoria?
- A equipe pode exportar, revogar, excluir e comprovar o ciclo de vida de fontes e dados derivados?
- Como prompt injection, output inseguro, agência excessiva, secrets e conteúdo de terceiros são testados?
- Quais pessoas são afetadas, quais avisos e direitos se aplicam e quem possui a decisão final?
- Quais evidências, monitoramento, plano de incidentes, gatilho de reavaliação e expiração da aprovação estão registrados?
Se várias respostas forem “o fornecedor provavelmente cuida disso”, a análise não está completa.
Aplique a estrutura entre categorias de tools de IA
Para assistentes como ChatGPT, examine termos de consumidor versus business, connectors, memória, links compartilhados e rotas de modelos. Para tools de escrita e marketing como Jasper, analise conhecimento da marca, conteúdo de clientes, integrações de publicação e aprovação factual. Para produtos de imagem e vídeo, analise assets enviados, direitos de rosto e voz, fornecedores de geração, galerias públicas, uso para treinamento e termos comerciais nos guias de imagem e design com IA e vídeo com IA.
Para tools de programação como Cursor, trate acesso ao repositório, comandos de terminal, Agents em background, execução remota, secrets e dependências geradas como privilegiados. Para tools de reuniões como Otter AI, analise aviso aos participantes, consentimento, acesso ao calendário, bots de gravação, compartilhamento de transcrição, treinamento, retenção e exclusão. Para plataformas de automação como n8n, foque credenciais, aprovação humana, limites determinísticos, logs de execução, deveres de auto-hospedagem e licenciamento.
Para tools de apresentação como Gamma, analise pacotes de fontes confidenciais, visibilidade de links, analytics de visitantes, exportações e offboarding da conta. Para tools de pesquisa como Elicit, separe literatura pública de pesquisa não publicada e verifique fornecedor, treinamento, retenção e termos de exportação específicos do plano. Explore todas as categorias de tools de IA para aplicar as mesmas perguntas de caso de uso e fluxo de dados ao workflow real.
Nossa política de privacidade explica as práticas de dados deste site, enquanto a metodologia de análise e a política editorial explicam como evidências, testes, incerteza, patrocínio e atualizações devem ser representados nas análises.
Guias relacionados
Continue com as melhores ferramentas de IA para pequenas empresas e as melhores tools de automação com IA para conectar esta decisão a workflows adjacentes e a um processo consistente de avaliação.
