Quase um terço dos funcionários entrevistados compartilhou logins, chaves e acessos de trabalho com IA

Um desenvolvedor copia um log de erro para um chat de IA e pede que ele identifique a causa de uma falha. O log contém uma chave de trabalho ativa. A tarefa é rotineira e leva poucos segundos, mas o acesso ao sistema já foi entregue a um serviço externo. São justamente essas situações que vale discutir com a equipe antes da próxima correção urgente.

Segundo o RB.RU, quase um em cada três funcionários entrevistados em empresas russas compartilhou logins, chaves e acessos a pastas de trabalho com sistemas de IA nos últimos seis meses. A publicação cita um estudo da Kiberdom. Apenas 5% dos entrevistados relataram a existência de regras escritas sobre o uso de IA em sua empresa, enquanto quase um em cada cinco não sabe quais dados de trabalho pode compartilhar com esses sistemas.

O que os números dizem — e o que não comprovam

Para um fundador ou gestor de desenvolvimento, isso levanta uma pergunta concreta: os funcionários entendem exatamente o que enviam à IA junto com a tarefa? Uma pessoa pode lembrar que não deve compartilhar uma senha, mas deixar passar um token em um trecho longo de código ou um link de acesso no meio de uma conversa.

Ainda assim, uma manchete afirmando que existem regras em “apenas 5% das empresas” exige cautela. A descrição fornecida trata da proporção de funcionários entrevistados que relataram a existência dessas regras. Isso não permite calcular diretamente a proporção de empresas: vários entrevistados podem trabalhar na mesma organização, e alguns funcionários podem simplesmente desconhecer um documento de política interna já existente.

O texto disponível também não informa o tamanho e a composição da amostra, a formulação das perguntas nem os detalhes da metodologia. Portanto, os resultados não podem ser generalizados para todos os funcionários de empresas russas. Compartilhar um login, uma chave secreta ativa ou um link para uma pasta também gera riscos diferentes. A pesquisa os reúne em um mesmo panorama, mas não informa quantos casos levaram a acessos não autorizados ou vazamentos.

Como um segredo acaba em uma solicitação comum

Imagine uma equipe hipotética que está integrando um serviço de pagamentos. A integração retorna um erro, e um desenvolvedor envia ao assistente uma requisição de exemplo, os cabeçalhos e a resposta do servidor. Um token real permanece no cabeçalho de autorização. Ele não é necessário para analisar a estrutura da requisição: pode ser substituído por um valor fictício, preservando os nomes dos campos e o código de erro.

Um gerente de produto enfrenta uma situação semelhante ao pedir que a IA analise solicitações de clientes. A exportação pode conter dados de contato, links internos e informações sobre pedidos. Nesse caso, vale primeiro reunir alguns exemplos anonimizados e verificar se são suficientes para a análise necessária. Enviar a planilha inteira apenas porque é fácil anexá-la aumenta desnecessariamente o volume de dados compartilhados.

O simples envio de informações a um serviço de IA não comprova que elas foram publicadas ou usadas para treinar um modelo. As condições dependem do produto, do plano, das configurações e do contrato específicos. Essas condições precisam ser verificadas separadamente. O nome do serviço, por si só, não determina quais dados a equipe está autorizada a confiar a ele.

O que as equipes podem fazer

Vale começar com regras curtas e exemplos claros. Quais serviços são permitidos? É possível enviar código-fonte? Como lidar com documentos de clientes? Quem procurar se uma chave já foi enviada a um chat? As respostas devem estar disponíveis onde os funcionários trabalham e ser aplicáveis a tarefas reais.

O próximo passo é preparar exemplos seguros: um log sem segredos, uma requisição de teste com um valor fictício no lugar do token e uma solicitação de cliente anonimizada. Para um desenvolvedor, é mais fácil seguir um exemplo pronto do que determinar sozinho, a cada vez, os limites do que é permitido. A verificação automática de segredos pode complementar esse processo, mas seus resultados também precisam ser revisados.

Se uma chave ativa já foi compartilhada com um serviço externo, a resposta prática é revogá-la, emitir uma nova e examinar os logs de uso disponíveis. Excluir a mensagem não substitui a troca da chave.

Para um gestor, o principal valor dessa pesquisa é servir de motivo para examinar um processo de trabalho concreto. Escolha uma tarefa típica que a equipe resolve com IA e observe quais dados são enviados junto com ela. Essa análise mostrará onde é necessária uma regra clara, um modelo pronto ou uma restrição técnica.