Quais acessos dar ao parceiro de implantação de IA no primeiro dia

Dê ao parceiro de implantação de IA apenas o acesso que permite entender o trabalho: um contato nomeado, documentos revisados, contas de teste e amostras anonimizadas. Adie tudo o que toque em dados reais de clientes, sistemas em produção ou mensagens enviadas para fora até que o papel, o limite de aprovação e um teste estejam combinados. Nunca entregue contas de administrador, logins pessoais, poder de pagamento ou a capacidade de alterar as próprias permissões.

Principais pontos

• O acesso do primeiro dia deve ajudar o parceiro a entender o trabalho, não a executá-lo: contatos, documentos revisados, contas de teste (sandbox) e amostras anonimizadas.
• Dados reais, permissões de escrita e canais que falam com o cliente esperam até que existam o papel, o limite de aprovação e um teste.
• Contas de administrador, logins pessoais, poder de pagamento e permissões concedidas pelo próprio parceiro a si mesmo nunca são entregues.
• Trate o acesso da equipe do parceiro e o acesso do próprio agente como duas perguntas separadas, e defina o escopo de cada uma isoladamente.
• Mantenha na sua empresa a titularidade de toda conta, ambiente (tenant) e credencial, para que só você consiga revogar o acesso rapidamente.

Que regra decide se um acesso é liberado, adiado ou negado?

O acesso deve seguir a tarefa, não o relacionamento. Um parceiro pode ser inteiramente confiável e, ainda assim, não precisar de determinada credencial esta semana. A pergunta útil não é se você confia nele, mas quanto dano um erro, uma credencial vazada ou um agente manipulado poderiam causar com aquele acesso.

Três perguntas classificam quase qualquer pedido:

• O que o parceiro precisa fazer na próxima etapa do trabalho, e ele consegue fazer isso com algo mais restrito?
• Se essa credencial fosse usada indevidamente, por uma pessoa ou pelo próprio agente, o que seria afetado e isso poderia ser desfeito?
• Sua empresa consegue revogá-la sozinha, de imediato, sem pedir nada ao parceiro?

Se a resposta à primeira for "nada ainda", adie. Se a segunda envolver dados de clientes, dinheiro ou mensagens que não podem ser recolhidas, adie ou negue. Se a terceira for "não", negue até que seja "sim". Esse é o princípio do menor privilégio, descrito em detalhe no OWASP Authorization Cheat Sheet, e vale para pessoas e para software.

Há ainda uma distinção que muitas primeiras conversas deixam passar. Um projeto de IA envolve dois conjuntos de acesso. O primeiro pertence à equipe do parceiro: as pessoas que desenham, configuram e mantêm o sistema. O segundo pertence ao agente: a identidade que ele usa para ler documentos, chamar ferramentas e enviar mensagens quando entra em operação. Os riscos são diferentes e a aprovação deve ser separada. Um engenheiro do parceiro que lê uma pasta de amostras é uma decisão distinta de um agente que grava no seu CRM.

Quais acessos você pode liberar no primeiro dia?

O primeiro dia serve para entender. O parceiro precisa aprender como o trabalho é feito hoje, quem decide o quê e quais ferramentas estão envolvidas. Nada disso exige mexer em sistemas reais.

Seguro liberar no início:

• Um contato nomeado do seu lado, mais um caminho de escalonamento, em um canal compartilhado que você controla.
• Acesso de leitura a documentos de processo que você revisou: políticas, modelos, tabelas que você aceita compartilhar, bibliotecas de respostas, guias internos.
• Uma vaga na sua ferramenta de gestão de projeto ou de chamados, limitada ao quadro do próprio projeto.
• Um ambiente de teste, workspace de teste ou conta de avaliação para cada ferramenta que o papel vai usar no futuro.
• Amostras anonimizadas ou sintéticas dos registros que o papel atende, como solicitações antigas sem nomes e identificadores.
• Horário agendado com a pessoa que hoje faz o trabalho.

O ponto em comum é que cada item ou passa pela sua revisão antes de ser compartilhado ou fica isolado da produção. Se há algo errado em um documento, você descobre antes que isso importe. Se uma conta de teste for comprometida, nada real fica exposto.

Vale o esforço de uma revisão rápida dos documentos antes de compartilhá-los. Contratos com cláusulas de confidencialidade, arquivos com dados pessoais e planilhas antigas com colunas esquecidas são as surpresas mais comuns. Quem confirma o conteúdo da pasta deve ser o responsável pelo processo, não quem a encontrou mais rápido.

Quais acessos devem esperar, e o que deve liberar cada um?

A maioria dos pedidos difíceis cai aqui. Não são recusas. São acessos que passam a fazer sentido quando uma condição específica é cumprida, e essa condição deve estar escrita para que ninguém precise negociá-la sob pressão de prazo.

• Leitura de registros reais: depois que o dono dos dados classificar os campos envolvidos e que você tiver a posição escrita do parceiro sobre como seus dados são armazenados e se são usados para treinamento. O artigo sobre quem é dono dos prompts e dos dados na IA da empresa mostra o que pedir por escrito.
• Escrita em um sistema de baixo risco: depois que o agente se comportar corretamente no ambiente de teste em casos realistas e que o limite de aprovação definir quais ações exigem confirmação humana.
• Acesso a canais que falam com o cliente: depois que os usuários do piloto estiverem treinados, o caminho de escalonamento funcionar e você tiver visto como o agente trata casos que deveria recusar.
• Direitos de implantação no ambiente de produção: depois que existir um processo de mudanças. Quem solicita, quem aprova e como se desfaz uma alteração devem ser combinados antes. O guia sobre como operar um agente de IA no dia a dia descreve esse tipo de rotina.
• Acesso a sistemas financeiros, de folha de pagamento ou de RH: só se o papel realmente exigir, com aprovação própria e, em geral, primeiro apenas para leitura.
• Escopos de integração mais amplos: depois que o primeiro escopo restrito rodar sem problemas e você tiver revisado o que ele de fato fez.

Quando uma ferramenta pede permissões via OAuth, leia os escopos na tela de consentimento com a mesma atenção que daria a uma cláusula contratual. A documentação do Google OAuth 2.0 explica como os escopos funcionam. A lição prática é pedir o escopo mais estreito que permita o próximo passo e ampliá-lo de forma deliberada. Um parceiro que pede acesso total à conta quando um escopo de leitura bastaria está dizendo algo sobre seus hábitos.

Os gatilhos também mostram se o projeto está no rumo certo. Se a condição para um acesso nunca é cumprida, o trabalho provavelmente ainda não está pronto para ele. Isso é um sinal útil e combina com a lógica de por que pilotos de IA não saem do papel e como levá-los à produção, em que cada etapa precisa provar algo antes de a seguinte ser aberta.

Quais acessos você nunca deve dar a um parceiro de IA?

Alguns pedidos não são questão de momento. São riscos estruturais, e um bom parceiro não insiste neles.

• Sua conta de administrador ou de proprietário, em qualquer sistema. Crie, em vez disso, uma conta separada e com escopo limitado para o parceiro.
• Logins pessoais ou senhas compartilhadas. Toda credencial deve pertencer a uma identidade nomeada, que possa ser desativada individualmente.
• A capacidade de alterar as próprias permissões, editar registros de auditoria ou desligar o monitoramento. Quem faz o trabalho não deve ser o único a poder ver ou alterar o registro dele.
• Poder direto de pagamento, cartões armazenados ou a capacidade de aprovar gastos. Limites de gasto pertencem a controles que você mantém.
• Guarda exclusiva dos seus dados ou backups. Se a única cópia está em uma conta do parceiro, você não tem backup.
• Titularidade do seu domínio, da conta de cobrança, do ambiente de nuvem ou das contas de mensagens. A equipe do parceiro pode entrar como convidada ou delegada, mas as contas continuam suas. É uma das defesas mais práticas contra a dependência de fornecedor, tema de como migrar agentes de IA para outro fornecedor.
• Exportação em massa, sem restrição, de dados de clientes ou de funcionários.

A mesma lógica vale para o agente. O OWASP Top 10 para aplicações com LLMs lista a agência excessiva entre os principais riscos: um agente com mais ferramentas, permissões ou autonomia do que a tarefa exige pode ser induzido a ações prejudiciais pelo conteúdo que lê, como um e-mail ou uma página web com instruções ocultas. Um agente com acesso restrito limita o que essa manipulação consegue. Um agente com acesso amplo transforma cada documento não confiável em um possível caminho até os seus sistemas.

Como conduzir a conversa sobre acessos, passo a passo?

A conversa funciona melhor quando segue uma sequência, em vez de uma lista longa de pedidos chegando por e-mail. Use este roteiro antes de emitir a primeira credencial.

• Peça ao parceiro um pedido de acesso por escrito, listando cada sistema, o nível (leitura, escrita, administração), o motivo e a duração. Pedidos vagos voltam para reescrita.
• Indique uma pessoa do seu lado que aprova os pedidos e uma que pode revogá-los. Muitas vezes é a mesma, mas os dois papéis devem ser explícitos.
• Classifique cada pedido em liberar agora, liberar depois ou nunca liberar, usando as três perguntas da primeira seção. Escreva o gatilho ao lado de cada item do segundo grupo.
• Emita contas que pertencem a você: nomeadas, com escopo limitado, com data de expiração onde a ferramenta permitir e com autenticação em dois fatores ativada.
• Registre o que foi concedido, a quem, quando e por quê, em um único lugar que as duas partes possam consultar.
• Revise em pontos combinados e remova o que não está mais em uso. O método da revisão trimestral de IA na empresa serve também para os acessos do parceiro.

Dois hábitos mantêm o processo honesto. Primeiro, trate a expiração como padrão: o acesso temporário que vira permanente sem ninguém perceber é a forma mais comum de uma configuração organizada se desorganizar. Segundo, peça ao parceiro que descreva o que fará com cada acesso, e não apenas do que precisa. Se a descrição é clara e restrita, a liberação é fácil. Se é difícil de explicar, essa é a verdadeira conclusão.

Como isso fica na prática? Um cenário ilustrativo

Este é um cenário ilustrativo, não a descrição de um projeto real.

Uma pequena distribuidora quer um agente que redija respostas a consultas rotineiras sobre pedidos. O parceiro envia um primeiro pedido com direitos de administrador no sistema de e-mail da empresa, exportação completa da base de clientes, dados de login do software de contabilidade e permissão para enviar e-mails diretamente aos clientes.

O dono classifica a lista em vez de aceitá-la ou recusá-la inteira:

• Direitos de administrador no e-mail: nunca. Em vez disso, uma caixa de entrada com escopo limitado para o agente e uma caixa de teste compartilhada.
• Exportação da base de clientes: depois. O parceiro começa com uma amostra anonimizada de consultas passadas. A leitura real vem quando o dono dos dados marcar quais campos o agente pode ver e os termos sobre dados estiverem assinados.
• Login do software de contabilidade: desnecessário para este papel. Negado, com a anotação de reavaliar só se a consulta de status de faturas passar a fazer parte do trabalho, e então apenas para leitura.
• Envio de e-mails diretamente aos clientes: depois. O agente primeiro grava rascunhos em uma fila de revisão, e um funcionário aprova cada um. O envio sem revisão só é considerado depois que os rascunhos se mostrarem confiáveis segundo critérios combinados.

Nada foi recusado por desconfiança. Cada pedido encontrou um gatilho ou uma justificativa, e o parceiro pôde começar a trabalhar na mesma semana com os documentos, a amostra e o ambiente de teste. O dono também manteve todas as contas em nome da empresa, de modo que revogar o acesso depois exigiria uma única ação do seu lado.

Como a Be Human trata o acesso em um projeto gerenciado?

A Be Human começa um projeto definindo um papel útil, a memória e as ferramentas de que ele precisa, os limites de aprovação e um critério de sucesso observável. O acesso deriva dessa definição: cada ferramenta recebe a menor permissão que o papel exige, as contas ficam sob controle do cliente e tudo o que grava, envia ou gasta fica atrás de um limite de aprovação definido pelo cliente. O acesso da equipe do prestador e o acesso do próprio agente são registrados separadamente e revisados como parte da operação gerenciada, junto com monitoramento, manutenção de integrações e resposta a incidentes. Mudanças no que o agente pode fazer passam por uma etapa controlada de solicitação e aprovação, e não por uma edição silenciosa.

Perguntas frequentes

Devemos dar ao parceiro acesso aos dados de produção para acelerar? Em geral não, no início. Amostras anonimizadas e um ambiente de teste permitem que o parceiro desenhe e teste o papel enquanto o dono dos dados termina de classificar os campos e os termos sobre dados são combinados. Passar para os dados reais depois dessas etapas custa um pouco de tempo no começo e elimina um risco grande.

O parceiro pode usar contas próprias nas ferramentas, em vez das nossas? É melhor que as contas sejam suas, porque a titularidade decide quem pode revogar acessos, recuperar dados e dar continuidade ao trabalho se a relação terminar. Contas do parceiro podem servir para as ferramentas internas dele, mas tudo o que guarda seus dados, sua configuração ou as mensagens dos seus clientes deve ficar no seu ambiente.

O que acontece com os acessos quando o projeto termina ou é pausado? Toda credencial emitida ao parceiro deve ser desativada por você, e o registro de acessos deve mostrar que isso foi feito. Fica muito mais simples quando as contas são nomeadas, têm escopo limitado e pertencem à sua empresa desde o início. Combine os passos de encerramento no contrato, e não no momento da saída.

Quem dentro da empresa deve aprovar os pedidos de acesso? Uma pessoa responsável, de preferência o dono do processo que o agente vai atender, trabalhando com quem cuida dos seus sistemas ou da segurança. A aprovação não deve ficar com quem tem mais pressa em lançar. Quem aprova também deve poder revogar, para que conceder e retirar acesso nunca fiquem em mãos diferentes.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.