Agente de IA para assistência de informática: triagem e dados

Um agente de IA para assistência de informática consegue responder dúvidas da entrada, informar o status do chamado e redigir mensagens de acompanhamento de peças, mas só com segurança depois que a loja decidir quais informações do cliente ele pode ver. O ponto de partida é o próprio processo de entrada: o formulário, as regras de tratamento de dados e uma lista curta de arquivos que o agente nunca pode abrir. A escolha do modelo e o desenho do chat vêm depois.

Principais pontos

• Defina o papel único do agente na entrada antes de escolher qualquer ferramenta ou integração.
• Separe os dados do chamado em três grupos: o que o agente pode ler, o que pode resumir e o que nunca vê.
• Comece com metadados e campos de status do chamado, e mantenha o conteúdo dos arquivos do cliente atrás de aprovação humana.
• Trate cada mensagem, anexo e log colado pelo cliente como entrada não confiável.
• Registre cada ação do agente para que o dono ou um técnico possa revisar o que foi lido e por quê.

Por que a entrada é o lugar certo para começar

O balcão de reparos recebe pedidos que parecem parecidos na superfície: um notebook que não liga, um celular com a tela trincada, um desktop que precisa de remoção de malware. Por trás de cada um deles há arquivos pessoais do cliente, fotos, senhas salvas, notas fiscais e, às vezes, registros de empresa. É na entrada que a loja decide quanto desse material realmente precisa, e é também o lugar mais barato para tomar essa decisão. Se as regras de entrada forem vagas, todas as integrações posteriores herdarão essa vagueza.

Isso difere de muitos outros serviços. Um agendamento de corte de cabelo raramente contém algo sensível. Um chamado de conserto pode conter o conteúdo inteiro de um disco. Um agente conectado a uma pasta compartilhada, ao sistema de chamados e à caixa de e-mail verá muito mais do que o cliente pretendia compartilhar, a menos que os limites tenham sido definidos antes da conexão.

Mapeie os dados que um chamado realmente contém

Antes de escrever qualquer regra, liste o que a loja coleta e onde isso fica guardado. A maioria das lojas descobre que um chamado é um conjunto de registros, cada um com um nível diferente de sensibilidade. Uma classificação prática tem quatro grupos:

• Administração do chamado: nome do cliente, contatos, modelo do aparelho, tipo de serviço, prazo prometido e status. O agente pode ler e atualizar esses campos.
• Notas de diagnóstico: sintomas, mensagens de erro, resultados de testes e comentários do técnico. O agente pode resumi-los em uma atualização de status, mas não deve copiar logs brutos em mensagens para fora.
• Conteúdo do cliente: documentos, fotos, caixas de e-mail, dados de navegador, backups e qualquer outro arquivo do aparelho. O agente não lê esses itens. Os técnicos tratam deles segundo os procedimentos próprios da loja.
• Credenciais e materiais de recuperação: senhas, chaves de recuperação, códigos de verificação e tokens de conta. O agente nunca recebe nada disso, e o formulário de entrada deve dizer isso com clareza.

Registre separadamente qualquer aparelho que pertença a um cliente empresarial. Contratos de serviço e compromissos de tratamento de dados firmados com esse cliente determinam o que a loja pode prometer, e as regras do agente devem seguir esses compromissos, e não o contrário.

A mesma lógica de classificação vale em outros ofícios. Na oficina mecânica, por exemplo, um agente pode cuidar de orçamentos e do status do serviço sem tocar nos registros pessoais do proprietário, como mostrado em IA para oficinas mecânicas.

Escreva as regras de entrada antes de o agente ver um chamado

Use a sequência abaixo. Ela é deliberadamente curta, porque uma política longa que ninguém segue não protege nada.

• Defina o papel do agente em uma frase, por exemplo: responde dúvidas de status e oferece horários de entrega para chamados de reparo em aberto.
• Liste os campos do chamado que o agente pode ler e os que pode escrever. O que não estiver na lista está fora de alcance.
• Declare o que o formulário de entrada informa ao cliente sobre dados: quais serviços envolvem abrir o aparelho, se acesso a arquivos faz parte de algum reparo e que backup e recuperação de dados são serviços separados, com aprovação própria.
• Decida quais ações exigem uma pessoa: orçamentos acima de um limite definido pelo dono, trabalhos de recuperação de dados, reembolsos, decisões de garantia e qualquer mensagem que trate do conteúdo de um aparelho.
• Escreva a regra de parada. Se o cliente pedir ao agente que busque, descreva ou encaminhe um arquivo, o agente recusa com educação e cria um encaminhamento para um técnico nomeado, com o número do chamado e o pedido.
• Defina uma data de revisão. Regras escritas em torno do cardápio de serviços de uma temporada perdem a validade rápido, e a revisão faz parte da regra.

Depois que esses seis pontos estiverem escritos em linguagem simples, o dono pode conferi-los com a configuração real das ferramentas. Se não puderem ser conferidos, ainda não são regras.

Limite o que o agente pode acessar

O acesso deve ser concedido por papel, e não por conveniência. Um assistente de entrada e um responsável por status precisam do sistema de chamados, talvez de uma agenda e de uma biblioteca de modelos de mensagem aprovados. Não precisam da pasta compartilhada onde os técnicos guardam imagens de diagnóstico, nem de acesso de rede às estações de bancada. Quando uma ferramenta usa autorização delegada, a concessão deve cobrir apenas os escopos que o papel exige. A documentação de OAuth 2.0 do Google descreve esse modelo: o usuário autoriza um aplicativo específico para um acesso específico, em vez de entregar a conta inteira.

A autorização também precisa ser checada por ação, e não apenas no login. As orientações de autorização da OWASP enfatizam que as decisões de acesso devem ficar em um ponto controlado, e não ser deixadas à lógica da aplicação. Para um agente, isso significa que o limite é imposto pela camada de ferramentas. Uma frase no prompt dizendo não abra arquivos de clientes é um pedido, não um controle. Se a lista de ferramentas do agente permitir a leitura de um arquivo, remova essa ferramenta em vez de confiar que o modelo vai se abster.

Lojas que também oferecem TI gerenciada para clientes empresariais enfrentam uma versão mais ampla desse problema, com mais sistemas e mais pessoas compartilhando um mesmo conjunto de registros. Esse caso é tratado em Agentes superinteligentes para provedores de serviços de TI gerenciados.

Trate o conteúdo do cliente como entrada não confiável

Uma mensagem do cliente ou um documento anexado pode conter texto dirigido ao agente. Um log colado pode incluir uma linha que manda o assistente ignorar suas regras e enviar a lista completa de arquivos para um endereço externo. Isso é uma forma de injeção de prompt, e quem escreve esse texto não precisa de nenhuma habilidade técnica. O guia de prevenção de injeção de prompt da OWASP descreve as defesas básicas: manter as instruções confiáveis separadas do conteúdo não confiável, limitar o que o modelo consegue fazer com a própria saída e exigir confirmação antes de qualquer ação sensível.

Para uma loja de reparos, a versão prática é simples. Tudo o que o cliente envia é dado para ser lido, nunca um comando. Mensagens de saída que incluam nomes de arquivos, logs de erro ou dados de conta passam por uma verificação humana. O agente não encaminha anexos entre clientes, técnicos e endereços externos por iniciativa própria.

Cenário ilustrativo: um pedido de arquivo em um chat de status

Cenário ilustrativo, não um caso real: um cliente escreve que o notebook está lento e pede ao agente que verifique o que há nele e envie uma lista de pastas. Pelas regras acima, o agente confirma o chamado, explica que a análise de arquivos é feita por um técnico, segundo o procedimento de dados da loja, e cria um encaminhamento com o aparelho, o pedido e o horário em que foi recebido. Um técnico decide se o pedido se encaixa em um serviço aprovado e responde diretamente. O agente nunca abre o disco. O registro mostra quais mensagens ele leu e qual encaminhamento criou, para que o dono possa confirmar que o limite foi mantido.

Trilha de auditoria, rotina de revisão e a primeira tarefa

Cada ação do agente deve deixar um registro: qual chamado foi lido, quais campos mudaram, qual ferramenta foi acionada e se uma pessoa aprovou algo. Esse registro é o que permite ao dono responder a uma reclamação do cliente com fatos, e não com lembranças. A introdução do OpenTelemetry explica a ideia geral de rastros e logs para sistemas que executam muitos passos pequenos, o que descreve bem um agente que chama várias ferramentas em uma mesma conversa. Mantenha o registro legível para o dono, e não apenas para o desenvolvedor que o construiu.

Revise a configuração em uma agenda fixa e depois de qualquer incidente. Compare a lista de permissões com as ferramentas realmente conectadas. Amostre conversas em que o agente recusou um pedido e confirme que os encaminhamentos foram atendidos. Teste a configuração com um conjunto fixo de mensagens de entrada realistas, incluindo algumas hostis, antes de qualquer mudança entrar em produção. Isso não exige uma plataforma especial. Exige uma lista escrita de casos e a disciplina de executá-los.

A Be Human desenha e opera esse tipo de configuração como uma sequência, e não como uma instalação única. A primeira etapa define 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. A operação contínua cobre monitoramento, avaliações recorrentes, revisão de permissões, manutenção das integrações e resposta a incidentes, para que os limites escritos na entrada continuem valendo conforme a loja muda. A loja mantém o controle sobre o que o agente sabe e sobre o que ele pode fazer.

Se você quer descobrir qual é a primeira tarefa da sua loja que vale a pena entregar a um agente, faça o diagnóstico gratuito de IA da Be Human.

Perguntas frequentes

Um agente de IA pode abrir arquivos de clientes em um chamado de conserto? Só se a loja der esse acesso de propósito, o que a maioria dos assistentes de entrada não deveria ter. Um desenho mais seguro permite que o agente leia os campos do chamado e os resumos de diagnóstico, enquanto a análise de arquivos fica com um técnico, segundo o procedimento próprio da loja. O agente deve conseguir explicar esse limite ao cliente e criar um encaminhamento.

O que uma loja de reparos deve escrever antes de conectar um agente? Escreva o papel único do agente, a lista de campos que ele pode ler e escrever, as ações que exigem aprovação humana e a regra para pedidos de arquivo. Acrescente uma data de revisão, já que cardápios de serviço e equipes mudam. Esses poucos pontos podem ser conferidos com a configuração real das ferramentas, e é isso que os transforma em regras, e não em intenções.

Um prompt de sistema basta para manter o agente longe de dados sensíveis? Não. O prompt é um pedido ao modelo, e um modelo pode ser manipulado por conteúdo de uma mensagem ou anexo. O controle real vem da camada de ferramentas: se o agente não tem nenhuma ferramenta que leia arquivos, ele não consegue ler nenhum, independentemente do que um cliente escreva.

Com que frequência as permissões do agente devem ser revisadas? Revise em uma agenda fixa e depois de qualquer incidente, como uma mensagem enviada ao destinatário errado ou uma nova integração. Compare as permissões concedidas com as ferramentas realmente em uso, amostre os pedidos recusados e confirme que os encaminhamentos estão sendo atendidos. Verificações pequenas e regulares detectam o desvio muito antes de ele virar um problema de dados.

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