Como limitar um assistente de IA com ferramentas, permissões e contexto

O limite real de um assistente de IA é o contrato executável do serviço, não uma proibição escrita na instrução do modelo. Dizer-lhe «não envies mensagens» pouco vale se a ferramenta ligada e a credencial disponível permitem enviar. O desenho tem, por isso, de dividir a experiência conversacional em capacidades pequenas e verificáveis, cada uma com informação elegível, identidade atuante, operação autorizada, teto de ação, evidência, testes e responsável próprios. Assim, uma pergunta rotineira não herda acesso ou poder pertencente a outra tarefa.

O que deve o assistente poder fazer?

A equipa deve começar por escrever uma carta de serviço numa única frase: «Para [utilizadores elegíveis], o assistente pode [família de tarefas autorizada], recorrendo a [informação aprovada], para produzir [resultado permitido], mas não pode [objetivos ou decisões excluídos].» Antes de ligar ferramentas, a carta identifica o ambiente de utilização, as tarefas suportadas, os limites de conhecimento, a supervisão humana e quem assume o risco. Esta é uma síntese editorial prática, informada pelo AI RMF do NIST e pela orientação da OWASP, e não uma exigência formal desses organismos.

• Troque «ajudar no apoio ao cliente» por operações observáveis: procurar um processo, resumir o histórico, recomendar um passo, criar um rascunho ou enviar uma resposta.
• Declare expressamente o que fica fora do serviço, incluindo decisões profissionais especializadas, compromissos materiais, alterações destrutivas e concessões de acesso.
• Associe cada operação ao utilizador elegível, ao resultado permitido, à supervisão necessária e ao responsável que pode alterar ou retirar essa capacidade.

Que informação pode cada capacidade utilizar?

Cada capacidade deve ter um perímetro de informação, e não apenas um limite técnico de tokens. Esse perímetro especifica sistemas aprovados, tipos e classificações de registos, filtros por objeto ou conta, datas, atualidade esperada, direitos do utilizador e dados proibidos. Mensagens externas, documentos, anexos, respostas de API e conteúdo recuperado são dados não fiáveis: podem informar a resposta, mas não devem transformar-se silenciosamente em instruções do serviço. Se a evidência necessária estiver inacessível, ausente ou desatualizada, a resposta deve ser recusada ou claramente qualificada.

• Separe o histórico temporário da sessão da memória persistente e defina o que pode entrar em cada um.
• Isole utilizadores e sessões, valide antes de persistir e aplique regras próprias de validade, dimensão, eliminação e integridade.
• Exclua segredos, credenciais e qualquer categoria que a finalidade declarada não justifique conservar.
• Escolha limites concretos segundo o risco, a privacidade e os requisitos de arquivo do serviço, sem adotar valores universais.

Como devem a identidade, as ferramentas e as permissões impor o limite?

Autenticação, autorização e aprovação são três decisões separadas: quem ou o que foi autenticado; que operação pode executar sobre qual recurso protegido; e se uma ação concreta foi aprovada. A porta de ferramentas e o sistema de destino devem aplicar os limites sobre a identidade atuante, porque o modelo e o prompt não são controlos de autorização. A equipa escolhe explicitamente entre autoridade delegada pelo utilizador e uma identidade de carga de trabalho controlada, sem herdar silenciosamente a conta privilegiada de um operador.

• Exponha operações estreitas e parâmetros validados, em vez de acesso geral à caixa de correio, base de dados, navegador ou linha de comandos.
• Limite verbos, recursos, objetos, campos, destinos, duração da credencial e destinatário do token no percurso de execução.
• Defina taxas, tentativas, profundidade de cadeias, lotes, custo, tempo, idempotência, reversão e disjuntores de acordo com o serviço.
• Nas integrações MCP protegidas, use âmbitos mínimos e tokens associados ao recurso; não apresente estes mecanismos como universais.

A conversa pode parecer contínua, mas a sua autoridade deve ser dividida em capacidades pequenas e aplicadas de forma independente.

Até onde pode ir a ação de cada capacidade?

Cada capacidade precisa de um teto de ação explícito e de controlos independentes progressivamente mais fortes quando passa de informar para alterar o estado externo. Uma escala editorial útil distingue responder ou resumir, recomendar ou propor, criar um rascunho, efetuar uma escrita limitada e reversível, provocar uma ação externa consequencial e encontrar uma decisão proibida. Criar um rascunho não equivale a enviá-lo; propor não equivale a decidir; e atualizar um campo reversível não deve abrir caminho para apagar um registo.

• Antes de uma ação consequencial, apresente uma pré-visualização verificável e associe a aprovação ao interveniente, ferramenta, recurso, parâmetros normalizados, momento e validade.
• Volte a validar autorização e aprovação na execução; uma alteração ao destinatário, conteúdo ou outro parâmetro relevante exige nova decisão.
• A aprovação nunca fornece autorização em falta, alarga permissões permanentes nem converte uma decisão proibida numa decisão permitida.
• Pagamentos, concessões de acesso, operações destrutivas, mudanças em produção, decisões profissionais de elevado impacto e compromissos materiais permanecem sob controlo humano qualificado e políticas determinísticas adequadas.

O que acontece quando o assistente encontra um limite?

Recusa, ajuda parcial segura, encaminhamento humano e escalamento de segurança devem ser resultados explícitos do serviço, com condições reais de paragem. O assistente declara o limite em linguagem simples sem revelar regras sensíveis e nunca afirma que consultou uma fonte, obteve aprovação, executou uma ferramenta ou gravou uma alteração quando isso não aconteceu. Pode ainda oferecer a parte admissível — por exemplo, um rascunho ou um pedido de informação em falta — desde que não contorne a razão da recusa.

• Use razões operacionais consistentes: tarefa fora do âmbito, informação inelegível, autorização insuficiente, aprovação necessária, evidência ausente ou antiga, juízo especializado, dependência indisponível, limite operacional ou sinal de segurança.
• Inclua no encaminhamento o objetivo original, contexto não sensível, capacidade tentada, razão, evidência disponível ou em falta, próximo passo e identificador de rastreio.
• Distinga apoio corrente ao utilizador, aprovação de negócio e incidente de segurança, pois têm responsáveis e urgências diferentes.
• Mantenha a execução suspensa enquanto o responsável atua e exija validação nova se a ação proposta tiver mudado.

Como transformar estes limites num desenho operacional?

As equipas devem preencher uma linha do quadro de desenho por cada operação visível para o utilizador e ligar essa linha a controlos aplicáveis, evidência, testes, métricas e responsabilidade. Registe o interveniente elegível, autenticação, perímetro de informação, sessão e memória, operação da ferramenta, identidade atuante, recursos, teto de ação, aprovação, limites operacionais, recusa, registo, cenários de avaliação e proprietário. O quadro e a escala de ação são síntese editorial apoiada nos princípios citados, não normas impostas pelo NIST ou pela OWASP.

Que provas permitem lançar e continuar a operar o assistente?

O lançamento exige provas de que o serviço permitido e as recusas esperadas funcionam em condições semelhantes às de utilização, seguidas de monitorização e reavaliação quando algo material muda. Aos casos positivos juntam-se acesso entre contas, ferramenta não autorizada, evidência antiga, conteúdo recuperado envenenado, dados proibidos, contorno de aprovação, parâmetros alterados, repetição de pedidos, falha de dependências, tentativa de exfiltração e cadeias descontroladas. Um conjunto aprovado é evidência datada, não garantia permanente.

• Faça os registos reconstruírem quem pediu, qual capacidade e política se aplicaram, que classes de fontes e ferramentas intervieram, que decisões de autorização e aprovação ocorreram, qual foi o resultado e que versões estavam ativas.
• Não conserve segredos nem contexto sensível ilimitado; ajuste conteúdo, acesso e retenção às regras de privacidade, segurança e arquivo.
• Monitorize utilização inesperada de ferramentas, recusas repetidas, falhas de autorização, alterações de aprovação, sequências anómalas, deriva, latência, consumo e falhas ao nível da capacidade.
• Atribua autoridade para pausar, corrigir ou retirar capacidades aos responsáveis pelo serviço, acessos, encaminhamentos de negócio e incidentes de segurança.

Alterações a modelos, prompts, recuperação, memória, ferramentas, permissões, políticas, dados, fornecedores ou contexto operacional devem reabrir os testes e a evidência das capacidades afetadas. Comece pela menor capacidade que produza valor e só aumente a autoridade através de uma mudança revista, não de uma simples edição ao prompt. Quando existam dados sensíveis, memória persistente, acesso privilegiado, compromissos externos, alterações destrutivas ou resposta a incidentes, envolva os responsáveis de segurança, identidade, privacidade, arquivo, risco e serviço; decisões legais, regulatórias ou profissionais especializadas seguem para peritos qualificados e processos governados em separado.