Que acessos dar a um agente de IA e quais não dar

Esta objecção chega antes de todas as outras, e é saudável. A pergunta «o que é que ele pode fazer de mal» é a pergunta certa a fazer a qualquer ferramenta a quem se entregam as chaves dos sistemas de trabalho.

A resposta que se segue não é «não tenha medo». É uma análise por tipo de acesso: o que se abre sem sobressaltos, o que se abre a meio, o que não se abre nunca, e como avaliar um produto antes de carregar em «permitir».

O princípio de onde partir

Formalmente chama-se princípio do menor privilégio; na prática soa mais simples: o agente deve ver exactamente aquilo de que precisa para a sua tarefa, e nem um canal a mais.

Não é paranóia, é a maneira de tornar o risco abarcável. Se o agente vê um canal e uma pasta, a pergunta «o que é que ele pode estragar» tem uma resposta curta. Se lhe deram administrador, resposta curta não há.

Verificação útil: formule a tarefa e veja qual é o acesso mínimo que a cobre. «Tratar dos documentos que vêm dos clientes» são uma pasta concreta e uma conversa concreta, não o disco inteiro e toda a correspondência.

O que abrir sem sobressaltos

Leitura de sítios concretos. Um canal, uma pasta, uma etiqueta no email, um calendário, um quadro. Não «o email», mas «as mensagens com a etiqueta Clientes». Não «o Drive», mas «a pasta Projectos 2026». Praticamente todas as integrações decentes sabem limitar o âmbito — se o produto não sabe, já isso é um sinal.

Escrita onde o erro é reversível. Um rascunho de email, um comentário, uma tarefa, um cartão, uma linha numa folha de cálculo com histórico de versões. Reversível é aqui a palavra que conta: um rascunho apaga-se, um email enviado não.

Acções internas sem destinatário. Mudar o nome a um ficheiro por uma regra, arrumar por pastas, pôr uma etiqueta, juntar números num relatório. Nada disto o cliente vê.

O que abrir só para leitura

Sistemas financeiros. Ver pagamentos, extractos, estados de subscrições — sim. Iniciar movimentos de dinheiro — não, e é melhor que isso seja uma limitação técnica e não uma definição que se pode comutar sem querer.

Sistemas onde vivem compromissos de outras pessoas. O calendário dos colegas, as tarefas da equipa. O agente pode ver que a pessoa está ocupada e propor. Mexer numa reunião alheia é decidir por outro, e isso pede-se-lhe a ele.

O repositório de código. Mostrar o que entrou na release, que pull request está há quatro dias à espera de revisão — é útil. Escrever código e fazer merge é trabalho dos engenheiros e responsabilidade deles.

O que não abrir nunca

Administração. Gestão de utilizadores, papéis, permissões. Uma ferramenta que se pode atribuir permissões a si própria deixa de ser limitada.

Segredos. Chaves de API, tokens, palavras-passe, o conteúdo dos cofres de segredos. À parte: o número de um cartão não é coisa para andar numa conversa — se aparecer lá, o comportamento certo do agente é recusar e pedir que não se volte a fazer, e não «tratar disso com cuidado».

Eliminação irreversível. Apagar ficheiros, emails, registos, esvaziar a reciclagem. Uma versão nova ao lado da antiga — sim. Apagar — não.

Canais pessoais. Mensagens privadas, conversas que não são de trabalho. Na maioria dos produtos esta limitação é da própria plataforma, e ainda bem.

Envios em massa sem confirmação. Um envio não se pode chamar para trás. Um erro no segmento, e a mensagem foi para a base toda.

Um à parte sobre dados pessoais

Aqui não chega limitar o acesso — é preciso limitar também o volume.

Se para a tarefa basta saber que o documento chegou e que está legível, o agente não precisa do conteúdo do processo clínico. Se para responder ao cliente basta o número da encomenda, não é preciso o perfil inteiro.

E uma regra que fica à parte: onde a utilização precisa de consentimento, a falta dele pára o processo. Não «fazemos com cuidado» — não fazemos.

O que tem de ficar registado

Acesso sem registo é confiança sem verificação. O mínimo que vale a pena exigir:

• o que o agente leu e quando;
• o que alterou, com possibilidade de ver a versão anterior;
• o que enviou para fora e quem o confirmou;
• onde parou e porquê.

O último ponto é subestimado, e é o mais útil: é por ele que se vê se os seus limites estão a funcionar ou se o agente os contorna porque você formulou uma coisa diferente daquela que tinha em mente.

Como revogar

Verifique isto antes de ligar, e não depois. A resposta deve ser simples: o acesso dá-se por OAuth e revoga-se do lado do serviço, na secção das aplicações ligadas, em dois cliques e sem falar com o apoio ao cliente.

Se revogar um acesso exigir um email para o apoio ao cliente, isto não é uma integração, é uma dependência.

Bandeiras vermelhas em qualquer produto

A lista é curta, e aplica-se também a nós — passe por ela toda a gente, incluindo o BossForce:

1. Pedem a palavra-passe em vez de OAuth. A palavra-passe do email entregue a um serviço é acesso a tudo, para sempre. As integrações decentes funcionam por OAuth, com permissões limitadas.
2. Não dá para limitar o âmbito. Se a única opção é «acesso à caixa de correio toda», você não tem escolha e, portanto, também não tem controlo.
3. Não há registo de acções. Não se vê o que aconteceu — também não há nada para verificar.
4. Envio sem confirmação por omissão. A definição «mostra-me primeiro» tem de ser o estado por omissão, e não uma caixa que é preciso ir procurar.
5. À pergunta sobre limites respondem «o modelo foi treinado para ser cuidadoso». Cuidado não é limitação. Limitação é quando a acção é tecnicamente impossível.

Lista de verificação antes de ligar

• qual é o acesso mínimo que cobre a tarefa;
• o que disso pode ficar só para leitura;
• que acções são irreversíveis e se estão ou não sujeitas a confirmação;
• onde estão os dados pessoais e se o agente precisa de os ver;
• como consultar o registo;
• como revogar o acesso em dois minutos.

Se houver resposta clara para as seis, a conversa sobre segurança está terminada — daqui para a frente é uma questão de configuração, e não de confiança.