Como envolver a equipe de TI em um projeto de agente de IA

Para envolver bem a TI em um projeto de agente de IA, faça o briefing antes de escolher o fornecedor e antes de criar qualquer conta. Diga qual papel o agente terá, quais sistemas ele vai tocar, qual identidade vai usar e quem dará suporte depois. Assim a TI revisa um escopo definido, em vez de descobrir um na última hora.

Principais pontos

• Faça o briefing da TI enquanto o escopo ainda pode mudar, não quando já existe um pedido de conta de serviço ou de exceção no firewall.
• Entregue à TI uma descrição de uma página com o papel, os sistemas, os dados e as ações que o agente pode executar.
• Peça uma identidade dedicada para o agente, com permissões restritas, e nunca o login emprestado de um funcionário.
• Combine por escrito quem cuida de incidentes, mudanças de acesso e dúvidas dos usuários, e onde termina a responsabilidade de cada parte.
• Trate as perguntas da TI como contribuição ao desenho do projeto. Cada resposta que você prepara agora é um atraso que você evita depois.

Por que a TI costuma virar um bloqueio de última hora?

A TI normalmente fica sabendo de um agente de IA por meio de um pedido: criar uma conta de serviço, liberar acesso a um sistema, aprovar um novo fornecedor. Nesse ponto, a área de negócio muitas vezes já escolheu um caminho, avisou o time e criou expectativas. As perguntas da TI chegam no pior momento e parecem obstrução, quando na verdade são as perguntas que deveriam ter moldado o plano desde o início.

Há também uma razão estrutural. A TI carrega as consequências do projeto sem ter participado das decisões. Ela será acionada quando algo parar de funcionar, responde a auditores e clientes sobre acessos e mantém o diretório de identidades ao qual o agente vai se juntar. Ser consultada por último e, ao mesmo tempo, ser responsabilizada é o que transforma uma área de apoio em guardiã de portão.

Envolver a TI cedo não significa que a TI construa o agente ou seja dona do projeto. O responsável pela área de negócio é dono do papel e do resultado. A TI é dona dos padrões de identidade, acesso, dispositivos, registros (logs) e risco de fornecedores. Quando essas duas responsabilidades ficam bem separadas, cada lado sabe o que decide. As verificações que Jurídico, TI e Financeiro fazem estão descritas em Processo de compras de agentes de IA: Jurídico, TI e Financeiro, e vale saber quais delas cabem à TI antes da primeira conversa.

O que o primeiro briefing para a TI deve cobrir?

Leve um roteiro curto e escrito, mesmo que parte dele ainda seja desconhecida. Uma página dizendo que isso ainda não foi decidido é mais útil do que uma reunião que tenta improvisar tudo. O roteiro abaixo é o mínimo de que a maioria das equipes de TI precisa para formar uma opinião.

• O papel: uma frase sobre o trabalho que o agente faz, para quem, e como é um trabalho concluído.
• Os sistemas: cada caixa de e-mail, pasta compartilhada, CRM, ferramenta de chamados ou banco de dados que o agente vai ler ou alterar, marcados como somente leitura ou com permissão de modificar.
• Os dados: as categorias envolvidas (clientes, funcionários, financeiro, contratos) e qualquer item sujeito a regulação ou a cláusula contratual.
• Os canais: onde as pessoas vão falar com o agente, como chat, e-mail ou aplicativo de mensagens, e quem pode fazê-lo.
• As pessoas: o responsável pela área de negócio, os primeiros usuários previstos e quem aprova mudanças.
• O fornecedor: quem constrói e opera o agente, onde ele roda, quais provedores de modelo participam e de onde vem o suporte.
• Os limites: o que o agente nunca deve fazer e quais ações exigem aprovação humana antes.
• O critério de sucesso: como todos vão saber que funciona e o que levaria a uma pausa.

Se você já desenhou a estrutura em um diagrama, leve junto. Uma visão de uma página com as peças, como a descrita em Diagrama de arquitetura de IA para empresas: mapa em uma página, permite que a TI identifique uma conexão desconhecida em segundos, sem ler parágrafos.

Quais contas e acessos o agente vai precisar?

Esta é a parte do briefing que mais interessa à TI. O princípio é simples: o agente deve ter identidade própria, com nome ligado à sua função, de responsabilidade de uma pessoa nomeada e limitada ao que o papel exige. Ele não deve rodar com o login de um gestor nem com a senha de uma caixa de e-mail compartilhada. Uma identidade separada gera uma trilha de auditoria clara, facilita a revogação do acesso e evita que o agente herde permissões pensadas para uma pessoa.

Quando o agente se conecta a ferramentas que aceitam autorização delegada, como o OAuth 2.0, ele pode receber escopos específicos por meio de um token que a TI revoga sem mudar a senha de ninguém. Se uma ferramenta só aceita senhas ou chaves, diga isso, porque muda a forma de guardar e renovar a credencial.

Leve uma proposta para cada uma destas decisões e deixe a TI ajustá-la:

• Identidade: uma conta dedicada ou identidade de serviço, com um responsável humano nomeado.
• Escopo: o menor conjunto de permissões que sustenta o papel, começando por leitura e acrescentando escrita só onde uma tarefa exigir.
• Credenciais: onde os segredos ficam guardados, quem pode vê-los e como são renovados.
• Método de conexão: autorização revogável e com escopo, em vez de senhas compartilhadas.
• Ambiente: se existe um ambiente de teste ou dados de exemplo, para que o agente seja experimentado com segurança antes.
• Validade: uma data de revisão para cada permissão concedida e um procedimento para remover o acesso quando o projeto termina ou um usuário sai.

Essas escolhas seguem as práticas usuais de autorização, o menor privilégio e a negação por padrão, que a orientação de autorização da OWASP descreve bem. Para a verificação recorrente depois do lançamento, veja Revisão trimestral de IA na empresa: manter, corrigir ou encerrar.

Que perguntas de segurança a TI vai fazer?

Espere estas perguntas e prepare as respostas antes da reunião. Você não precisa de respostas perfeitas. Precisa de respostas honestas e de um plano para as lacunas.

• Para onde vão os dados da empresa, e o provedor do modelo os armazena, registra ou retém?
• Algum dado da empresa é usado para treinar modelos, e isso está dito por escrito?
• O que acontece se um e-mail ou documento lido pelo agente contiver instruções ocultas?
• Quais ações do agente não podem ser desfeitas?
• Conseguimos ver tudo o que o agente fez, com horário, usuário solicitante e sistema acessado?
• Com que rapidez podemos cortar o acesso dele, e quem tem autorização para isso?
• Quais subprocessadores e localizações estão envolvidos?
• Como o agente é testado antes de uma mudança chegar às pessoas que o usam?

A pergunta sobre instruções ocultas merece uma resposta de verdade. A injeção de prompt (prompt injection) é uma fragilidade conhecida das aplicações com modelos de linguagem, e o OWASP Top 10 para aplicações com LLMs a trata como risco central. A resposta crível é de desenho, não uma promessa: limitar o que o agente pode fazer depois de ler conteúdo não confiável, exigir aprovação humana para ações de alto impacto e registrar o que ele fez. Se um fornecedor disser que esse risco não existe, trate isso como alerta.

Se a empresa quiser um vocabulário comum para essas conversas, o NIST AI Risk Management Framework oferece uma estrutura para identificar e gerenciar riscos de IA sem exigir um programa grande. Um começo leve de governança, para empresas de médio porte, pode ser apenas um responsável nomeado, uma lista de sistemas e uma revisão periódica de acessos.

Onde devem ficar os limites do suporte?

É no suporte que bons projetos falham em silêncio. Todos assumem que outra pessoa vai responder quando um funcionário disser que o agente parou de responder. Resolva isso antes do lançamento, separando três tipos de suporte:

• Suporte de uso: como pedir coisas ao agente e o que ele pode ou não fazer. Em geral cabe ao responsável pela área de negócio ou a um multiplicador treinado.
• Suporte do agente: o agente se comporta de modo estranho, uma conexão com ferramenta falha, uma resposta está errada. Cabe a quem opera o agente, seja a equipe interna ou um fornecedor.
• Suporte de infraestrutura: identidade, rede, dispositivos, login único e permissões de caixas de e-mail. Cabe à TI.

Depois, combine mais dois pontos. Primeiro, quem pode pausar o agente de imediato, sem pedir permissão antes. Segundo, quem é chamado primeiro para cada tipo de problema e como essa pessoa chega à seguinte. Uma divisão de responsabilidades entre fornecedor e empresa, registrada por escrito, evita a discussão depois. Em Agência de automação com IA ou provedor gerenciado: quem opera depois você vê como traçar essa linha.

Cenário ilustrativo: uma líder de operações configura um agente para redigir respostas a partir de uma caixa de e-mail compartilhada de atendimento. A TI só descobre depois e encontra o agente rodando com o login de um gerente, com acesso a toda a caixa de e-mail dele. O projeto para enquanto as contas são refeitas. Se o briefing tivesse vindo antes, a TI teria criado uma identidade dedicada, limitada a redigir rascunhos naquela única caixa, e a pergunta sobre quem chamar quando os rascunhos pararem de aparecer já teria resposta.

Qual é uma sequência prática para fazer o briefing da TI?

Use esta sequência como plano. Ela funciona para projetos pequenos ou grandes e mantém claro o papel da TI.

• Escreva o resumo de uma página com o papel e a lista de sistemas antes de qualquer reunião.
• Peça à TI uma conversa, não uma aprovação, para ouvir as restrições antes de se comprometer com um desenho.
• Percorra o roteiro do briefing e registre cada dúvida em aberto com um responsável e um prazo.
• Combine o desenho de identidade e acesso, incluindo um ambiente de teste ou dados de exemplo.
• Combine os limites de suporte e o procedimento para pausar o agente.
• Nomeie um contato da TI para o projeto e marque um ponto de revisão antes de o agente chegar aos usuários reais.
• Registre o que foi combinado nos documentos do projeto, para que sobreviva a trocas de pessoal.
• Agende uma revisão recorrente de acessos depois do lançamento, em vez de confiar na memória.

A mesma disciplina vale em cada etapa de um piloto. Por que pilotos de IA não saem do papel e como levá-los à produção explica por que os acessos e registros aceitos em uma prova de conceito não devem ir sem alteração para a produção.

Como um modelo gerenciado funciona com a TI?

O primeiro trabalho da Be Human 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. O material voltado à TI sai dessa definição: uma lista de sistemas, as permissões solicitadas para cada ferramenta, as ações que exigem aprovação humana e as pessoas que agem quando algo dá errado. Na operação gerenciada, o monitoramento, a manutenção das integrações, a revisão de permissões e a resposta a incidentes são feitos remotamente, em português ou inglês, enquanto a empresa mantém o controle das aprovações e dos acessos. Mudanças no que o agente pode alcançar passam pelo processo de aprovação da própria empresa, de modo que a TI as vê antes de entrarem em vigor.

Perguntas frequentes

A TI deve aprovar o projeto ou apenas ser informada? Informar não basta, porque a TI é dona de padrões que o projeto precisa cumprir. Dê à TI uma chance real de definir condições sobre identidade, acesso, registros e risco de fornecedor, enquanto o responsável pela área de negócio continua dono do papel e do resultado. A aprovação deve tratar do cumprimento desses padrões, não do mérito da ideia.

E se a empresa não tiver um departamento de TI? Alguém ainda cumpre esse papel, seja um administrador terceirizado, um gerente administrativo ou um fundador que controla as contas. Nomeie essa pessoa, entregue a ela o mesmo roteiro de briefing e garanta que ela saiba quem pode revogar acessos. Pular essa etapa porque não existe uma equipe formal é como agentes acabam rodando em logins pessoais.

A TI pode dizer não a um agente de IA? A TI pode recusar um desenho específico, como credenciais compartilhadas ou acesso sem registro, e isso é saudável. Uma recusa no início do processo costuma apontar uma mudança que deixa o projeto mais seguro, como escopos mais estreitos ou um ambiente de teste. Se a TI bloquear a ideia inteira, pergunte quais condições mudariam a resposta e trabalhe a partir dessa lista.

Quanto detalhe a TI precisa antes da primeira reunião? Uma página basta: o papel, os sistemas, os dados, as pessoas e os limites. A TI pode pedir mais quando vir o que está sendo proposto. O que importa é que a página seja honesta sobre o que ainda não foi decidido.

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