Do protótipo à mudança implantada: integrar IA com permissões limitadas

1. Defina a fronteira de confiança

Imagine uma função interna que prepara uma atualização para um registro. O modelo pode ler apenas as informações estritamente necessárias e propor novos campos, mas não recebe credenciais do banco de dados nem executa a alteração. A aplicação convencional mantém o controle: autentica a pessoa, verifica suas permissões, valida o estado atual e decide se aplica a mudança. Essa separação reduz o impacto de uma resposta errada ou manipulada.

Desenhe o percurso dos dados antes de escrever código. Identifique o que a pessoa envia, qual contexto é acrescentado, que resposta se espera e quais sistemas podem ser afetados. Trate textos recuperados de documentos, chamados e registros como dados não confiáveis: eles podem conter instruções enganosas e não devem ampliar a autoridade do modelo. Evite incluir segredos ou dados pessoais que não sejam indispensáveis para formular a proposta.

Defina uma saída de escopo restrito. Por exemplo, em vez de pedir ao modelo que atualize um registro, solicite um objeto com o identificador do registro, os campos cuja alteração é proposta e uma breve justificativa. A justificativa pode ajudar quem revisa, mas não substitui as verificações do servidor. O modelo não deve decidir quem está autorizado nem quais regras de negócio se aplicam.

Uma chamada a ferramentas ou funções permite que um modelo solicite operações disponíveis em uma aplicação; isso não transforma a solicitação em autorização. A aplicação deve interpretar o pedido como uma proposta e aplicar sua própria política. Se a função escolhida envolver uma gravação, é preferível que a interface exposta ao modelo permita apenas preparar a operação, não confirmá-la.

2. Coloque um adaptador entre o modelo e os serviços internos

O adaptador é o código da aplicação que faz a tradução entre a solicitação do usuário, a interface do provedor do modelo e os serviços internos. Ele mantém as credenciais, limita o contexto enviado, valida a resposta e chama as operações determinísticas de negócio somente depois que as verificações forem aprovadas. Assim, o modelo não se conecta diretamente ao banco de dados nem decide como uma pessoa é autenticada.

Separe as responsabilidades em módulos compreensíveis: autenticação e autorização; construção do contexto; chamada ao modelo; validação da saída; apresentação para revisão; e execução da operação confirmada. Essa separação permite trocar de provedor sem reescrever as regras de negócio e facilita desativar a geração sem deixar a função convencional inoperante.

Estabeleça um contrato de entrada e saída com versão. Uma resposta estruturada pode exigir campos obrigatórios, tipos específicos e listas fechadas de valores. A saída estruturada ajuda a reduzir ambiguidades de formato, mas não prova que os valores estejam corretos ou sejam seguros. Valide o objeto no servidor, rejeite campos desconhecidos se o contrato assim exigir e verifique também as regras próprias do domínio.

Mantenha fora do modelo as decisões que devem ser determinísticas: identidade do usuário, permissões, limites de recursos, transições de estado, cálculos exatos e gravação persistente. A documentação de plataformas de integração apresenta padrões para conectar modelos e fluxos de trabalho, mas a configuração específica, os conectores disponíveis e suas permissões dependem do produto e precisam ser conferidos na documentação vigente.

3. Transforme a proposta em uma operação autorizável

A resposta do modelo não é uma ordem confiável. Antes de aplicar uma mudança, verifique se ela cumpre o esquema esperado, se o recurso está dentro do escopo autorizado e se o usuário atual pode realizar exatamente aquela operação. Não deduza autorização a partir de uma explicação do modelo, de uma categoria sugerida ou de conteúdo encontrado em documentos.

Verifique o estado do registro imediatamente antes de gravar. Se ele tiver mudado desde a geração da proposta, não aplique silenciosamente valores calculados com base em uma versão anterior. Você pode encaminhar o caso para revisão, gerar uma nova proposta com o estado atualizado ou apresentar um conflito para que a pessoa decida. A gravação deve usar uma verificação de concorrência adequada ao armazenamento empregado.

Defina regras de negócio independentes do modelo. Por exemplo, uma proposta pode ser sintaticamente válida, mas não permitida porque o chamado já está fechado. Limite a quantidade de campos que podem ser alterados, rejeite valores fora da faixa e evite que o modelo introduza identificadores de recursos que não tenham sido autorizados previamente.

A revisão humana é especialmente útil quando a mudança é sensível, difícil de reverter ou afeta outras pessoas. A decisão precisa ser informada: apresente os valores atuais e os propostos, indique quais campos serão alterados e permita cancelar. Em contextos regulados, as obrigações concretas dependem da função e da classificação aplicáveis; os guias práticos da AESIA se destinam à implementação do Regulamento de IA e são descritos como recomendações não vinculantes, não como substitutos da legislação.

4. Limite credenciais, ferramentas e contexto

Aplique o princípio do menor privilégio a cada componente: uma credencial deve permitir somente as operações necessárias sobre os recursos necessários. Se o fluxo precisar consultar dados e propor uma atualização, separe a identidade de leitura daquela que executa gravações. Mantenha a segunda fora do processo do modelo e use-a somente no caminho da aplicação controlado pelo servidor.

Não exponha ao modelo ferramentas genéricas, como executar consultas arbitrárias, acessar todos os registros ou chamar qualquer API interna. Exponha operações restritas, como obter um resumo de um registro autorizado ou preparar uma alteração de categoria. Se a plataforma permitir selecionar ferramentas ou funções, essa lista define uma fronteira de capacidade, mas não substitui a autorização implementada pela aplicação.

Armazene chaves e tokens no mecanismo de segredos aprovado para o ambiente; não os inclua em instruções, registros de depuração nem respostas ao usuário. Defina procedimentos de rotação e revogação, separe as credenciais por ambiente e evite reutilizar chaves de desenvolvimento em produção. Os mecanismos de segurança de uma API, como tokens, chaves ou certificados, têm escopos e requisitos diferentes: verifique o que está realmente configurado na plataforma e não presuma que o nome de um mecanismo implique permissões mínimas.

Reduza também as informações fornecidas ao modelo. Remova campos irrelevantes, oculte identificadores quando não forem necessários e estabeleça limites de tamanho. Verifique quais dados são enviados ao provedor, as condições vigentes de tratamento e retenção e as opções disponíveis para a região e o tipo de serviço contratado. Esses detalhes variam conforme o provedor, o produto, a configuração e a data; não podem ser deduzidos de um padrão arquitetural geral.

5. Gerencie tempos limite, novas tentativas e duplicatas

Uma chamada ao modelo pode demorar, retornar uma resposta incompleta ou falhar devido a uma interrupção temporária. Defina um tempo máximo e trate uma resposta que ultrapasse esse limite como uma proposta indisponível; não execute uma ação com base em um resultado parcial. Informe claramente o estado e permita uma nova tentativa sem perder a possibilidade de revisar o que foi solicitado.

Diferencie uma nova tentativa de geração de uma nova tentativa de gravação. Pedir outra proposta pode produzir uma saída diferente; por isso, mantenha o identificador da solicitação e mostre qual proposta está em revisão. Em contrapartida, repetir uma gravação após um tempo limite pode duplicar o efeito se a primeira solicitação tiver chegado ao sistema. Use uma chave de idempotência ou um mecanismo equivalente quando o serviço oferecer suporte e verifique o resultado antes de reenviar.

Uma operação idempotente produz o mesmo estado efetivo quando repetida sob as mesmas condições; isso não deve ser confundido com repetir qualquer solicitação sem consequências. Para uma gravação não idempotente, projete uma forma de detectar se ela já foi aplicada, por exemplo, registrando o identificador da operação junto com o resultado. Se não for possível determinar o resultado após uma falha, interrompa as novas tentativas automáticas e encaminhe o caso para reconciliação.

Proteja as gravações contra alterações concorrentes. Inclua uma versão ou condição do estado que a aplicação leu e rejeite a gravação se ela já não corresponder. Defina o que pode ser revertido: às vezes basta restaurar campos; em outros casos, há efeitos externos ou notificações que não podem ser desfeitos. Nesses casos, especifique uma compensação e quem decide aplicá-la.

6. Faça a implantação por etapas e mantenha uma saída de emergência

Prepare um ambiente de testes com dados não produtivos ou devidamente protegidos e credenciais separadas. Verifique o fluxo completo: geração de uma proposta, rejeição de uma saída inválida, negação por falta de permissões, conflito de estado, tempo limite e falha de gravação. O objetivo aqui é verificar o comportamento da integração escolhida, não presumir que um provedor ofereça determinada função de segurança.

Comece no modo de proposta sem execução: a aplicação pode gerar e exibir resultados, mas não pode aplicar alterações. Depois, habilite a confirmação para um grupo reduzido ou uma classe limitada de operações, com responsáveis identificados. Defina antecipadamente qual condição interrompe a função, quem pode ativá-la ou desativá-la e como a mudança será comunicada às pessoas usuárias.

A reversão deve ser uma capacidade operacional real. Inclua um interruptor para desativar a geração ou a execução de ações sem alterar os dados existentes, um caminho convencional para concluir a tarefa e um procedimento para revisar propostas pendentes. Se a implantação for feita por meio de uma API ou de um pipeline, separe a implantação técnica da publicação para usuários e verifique qual etapa permite receber tráfego. Os detalhes dependem da plataforma específica.

Antes de ampliar o acesso, documente os limites conhecidos, as permissões efetivas, o tratamento de dados e as instruções do provedor aplicáveis à configuração escolhida. Os guias da AESIA indicam expressamente que seus documentos são recomendações não vinculantes e estão sujeitos a revisão; use-os como orientação contextual, não como parecer jurídico automaticamente aplicável a qualquer integração.

7. Modelo para revisão arquitetural

Antes de implementar, responda por escrito a perguntas que possam ser verificadas no código, na configuração ou na documentação vigente. Não marque uma opção como resolvida apenas porque o provedor anuncia uma capacidade geral: confirme se ela existe no produto, na versão, na região e no nível de serviço que você pretende usar.

Inclua na revisão a interface exata do adaptador, o esquema da resposta, as regras determinísticas, a identidade de cada componente, os recursos acessíveis e o caminho entre a confirmação e a gravação. Registre também os cenários de erro, o comportamento das novas tentativas, o método de detecção de duplicatas, as condições de concorrência e o mecanismo para desativar a função.

Mantenha separados os fatos documentados, as decisões de projeto e as hipóteses pendentes. Por exemplo, o fato de uma plataforma permitir chamadas a funções não prova que uma função específica possa ser autorizada de forma independente. O fato de um guia descrever mecanismos de autenticação não prova quais deles estão ativos na sua implantação. Confirme cada detalhe na documentação primária correspondente e na configuração efetiva.

Para aprofundar os conceitos, consulte o guia de aprendizagem sobre IA, o guia de modelos locais e as páginas do glossário sobre chamada de ferramentas, princípio do menor privilégio, saída estruturada e injeção de prompt. Esses links internos devem apontar para páginas da Inferama e complementar este guia; não substituem a documentação do provedor escolhido.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.