Ponha uma cerca ao seu agente de IA antes que ele possa enviar e-mails ou gastar dinheiro

Acredito que um agente de IA deve ganhar acesso ao seu negócio, não recebê-lo como um presente de boas-vindas. Se dirige uma pequena ou média empresa, a atração é compreensível: ajuda com e-mails, registos, código rotineiro e compras. Mas a minha posição é simples. Antes de um agente poder atuar nos seus sistemas, dê-lhe um quintal cercado. Só então considere entregar-lhe as chaves.

Não trataria isto como um argumento contra a IA. Vejo-o como a diferença entre experimentar uma ferramenta útil e dar a um processo não testado autoridade sobre clientes, dinheiro e operações. Uma demonstração persuasiva não me diria o suficiente sobre como um agente lida com um pedido ambíguo ou uma situação inesperada. Eu gostaria de limites que se mantenham mesmo quando o seu julgamento falha.

O meu primeiro passo seria um ambiente isolado (sandbox) ou uma cópia de teste: um local onde o agente possa praticar sem contactar clientes reais, alterar registos reais ou fazer compras. Verificaria essa separação em vez de a assumir. A conta de teste ainda consegue aceder a uma caixa de entrada real? As credenciais de pagamento reais estão disponíveis? Se a cerca tiver um portão para os sistemas reais, gostaria de saber exatamente quem o controla.

Em seguida, daria ao agente a sua própria conta, apenas com as permissões que a sua tarefa atual exige. Nunca o meu login de administrador. Um agente que redige lembretes de marcações não tem uma razão óbvia para alterar as configurações de processamento salarial. Também manteria palavras-passe e outras credenciais fora do seu alcance, a menos que sejam essenciais para a tarefa autorizada. O acesso separado dá-me algo específico para restringir ou revogar.

Depois, escreveria duas categorias: o que pode fazer sozinho e o que precisa da aprovação de uma pessoa. Redigir um e-mail pode ser permitido; enviá-lo pode exigir aprovação. Preparar uma atualização de registo pode ser aceitável; apagar registos pode não ser. Tornaria essas regras aplicáveis através de permissões de sistema e etapas de aprovação sempre que possível, em vez de depender apenas de instruções para se comportar com cuidado.

Estabeleceria limites de gasto, volume e tempo antes de iniciar o trabalho real. Isso significa um teto de compras, um limite para mensagens ou alterações de registos e uma janela de operação definida. Os limites corretos dependem do negócio e da tarefa. O meu teste seria prático: se o agente repetisse a ação errada até atingir o limite, conseguiríamos absorver e reverter o resultado confortavelmente?

Manteria um registo das suas ações e lê-lo-ia atentamente durante as primeiras semanas. Gostaria de ver o que alterou, o que enviou, quais as aprovações que solicitou e onde parou. Para mim, o registo não é uma caixa para assinalar. É a forma como compararia o trabalho que pensava ter delegado com o trabalho que está realmente a ser feito.

Deve também existir um botão de paragem, e alguém deve saber que é responsável por o premir. Testaria que parar o agente impede efetivamente ações futuras, incluindo trabalho em fila. Também planearia como revogar o seu acesso e desfazer alterações quando possível. Um procedimento de emergência não é grande consolo se ninguém souber onde ele está.

Só após rever trabalho real, mas de baixo risco, alargaria as permissões, uma responsabilidade de cada vez. Procuraria um comportamento consistente dentro das regras, não apenas um resultado impressionante. Na minha opinião, a possibilidade de um agente ultrapassar um limite é razão suficiente para estabelecer limites antes da confiança, sem esperar por um exemplo assustador. O meu conselho é começar pequeno, observar atentamente e manter o controlo. A DevMojos ajuda as empresas a adotar agentes de IA com segurança, com as cercas no lugar primeiro.