Processo de compras de agentes de IA: Jurídico, TI e Financeiro

O processo de compras de agentes de IA funciona quando Jurídico, TI e Financeiro analisam a mesma descrição curta do papel, dos dados, das ferramentas e dos limites do agente, e cada área responde a um conjunto fixo de perguntas sobre ela. O processo trava quando cada área recebe uma apresentação diferente do fornecedor e levanta dúvidas abertas, uma depois da outra. Combine primeiro a descrição compartilhada e depois faça as três revisões em paralelo.

Principais pontos

• Escreva um briefing único antes de qualquer revisão, para que Jurídico, TI e Financeiro julguem os mesmos fatos.
• O Jurídico verifica o que o fornecedor pode fazer com os seus dados, quem é dono de quê, quem responde por falhas e como você sai do contrato.
• A TI verifica identidade, permissões, registros, tratamento de falhas e quem pode pausar o agente.
• O Financeiro verifica os fatores de custo, tetos, esforço interno escondido e como o valor será observado.
• Registre cada conflito e sua solução no contrato ou no escopo de trabalho, não em cadeias de e-mail.

Por que o processo de compras de um agente de IA trava?

A maioria das compras de software responde a uma só pergunta: esta ferramenta faz o trabalho por um custo aceitável? Um agente de IA acrescenta várias outras. Ele age em nome da empresa, guarda credenciais, pode lembrar do que viu e seu comportamento pode mudar quando muda o modelo que roda por baixo. Cada área aprovadora enxerga uma parte disso, e nenhuma enxerga tudo.

O padrão de falha mais comum é a revisão em sequência. O patrocinador da área de negócio envia a proposta do fornecedor ao Jurídico. O Jurídico devolve comentários semanas depois. Só então a TI descobre que o agente precisa de um acesso que o Jurídico supunha que não existiria. O Financeiro vê uma cobrança por uso quando o escopo já mudou. Cada passagem de bastão reabre a conversa, e o patrocinador perde ritmo.

A falha oposta também é frequente: uma equipe pressionada pula uma área. Um piloto começa com login pessoal, com um fornecedor cujos termos de dados ninguém leu, e o custo aparece depois como surpresa. Nem a trava nem o atalho indicam descuido da empresa. Ambos nascem da falta de um documento inicial compartilhado e de uma lista clara do que cada área responde.

O que entra no briefing compartilhado?

O briefing tem uma ou duas páginas e é escrito pelo dono do papel na área de negócio, não pelo fornecedor. Não precisa ser elegante. Precisa ser específico o bastante para que três revisores diferentes cheguem ao mesmo entendimento do que está sendo comprado. Se você ainda não escreveu a descrição do papel, comece por ela e mantenha o vocabulário alinhado ao escopo de trabalho da implantação do agente de IA, para que o briefing possa alimentar o contrato depois.

Use esta ordem:

• Papel: a única função que o agente vai exercer, descrita em uma frase que um funcionário novo entenderia.
• Dados: quais sistemas e tipos de documento ele vai ler, e se algum contém material pessoal, financeiro ou confidencial.
• Ferramentas e ações: o que ele pode fazer além de ler, como redigir e-mails, atualizar registros ou enviar mensagens.
• Limites de aprovação: quais ações exigem aprovação prévia de uma pessoa nomeada.
• Memória: o que ele retém entre tarefas, onde isso fica guardado e quem pode apagar.
• Critério de sucesso: um resultado observável que mostre se o agente vale a pena.
• Responsável: a pessoa que responde pelo agente depois da entrada em produção.

Com o briefing pronto, envie às três áreas no mesmo dia, com o mesmo pedido: responder à sua lista de perguntas e apontar o que o briefing não permite responder. Lacunas no briefing são baratas de corrigir. Lacunas descobertas depois da assinatura do contrato, não.

O que o Jurídico deve verificar?

Normalmente pedem ao Jurídico que revise um contrato. No caso de um agente, a tarefa mais útil é revisar o que o contrato permite ao fornecedor, e aos fornecedores por trás dele, fazer com as suas informações e com o seu nome. Estas são as perguntas que valem a pena.

• O fornecedor, ou algum provedor de modelo de que ele dependa, treina com os nossos dados ou os retém? A resposta está no contrato, e não apenas em uma página da internet? O artigo sobre quem é dono dos prompts e dos dados na IA da empresa ajuda a colocar isso por escrito.
• Quem é controlador e quem é operador dos dados pessoais que o agente toca, e quais são os suboperadores? Na prática brasileira, vale conferir isso à luz da LGPD.
• Onde os dados são armazenados e processados, e isso é compatível com as nossas obrigações contratuais e regulatórias?
• Quem é dono da configuração do agente, das instruções, dos arquivos de conhecimento e dos resultados produzidos?
• O que acontece com os nossos dados e a nossa configuração quando o contrato termina, e em que formato eles voltam para nós?
• Se o agente enviar uma mensagem errada ou executar uma ação errada, qual responsabilidade se aplica e o limite previsto é aceitável para este caso de uso?
• O caso de uso envolve regras sobre decisões automatizadas, contratação, crédito, saúde ou comunicação com clientes, e alguém precisa ser informado de que há uma IA envolvida?
• O que o fornecedor deve nos comunicar após um incidente de segurança ou de dados, e em que prazo?

Dois hábitos ajudam o Jurídico a andar mais rápido. Primeiro, ligue cada pergunta a uma linha do briefing, para que a resposta seja uma cláusula específica ou uma alteração específica pedida. Segundo, separe os termos indispensáveis das preferências. Se tudo é impedimento, o fornecedor não consegue responder de forma útil e o patrocinador não consegue julgar o que é negociável. Como referência neutra para organizar a linguagem de risco entre as áreas, o NIST AI Risk Management Framework serve bem, e vale consultar a visão geral do AI Act europeu se o seu caso de uso envolver pessoas na União Europeia.

O que a TI deve verificar?

A TI protege os sistemas e as contas da empresa de um novo tipo de agente. A ideia central é tratar o agente como um funcionário com papel restrito: identidade própria, permissões próprias, registro do que fez e uma forma de interrompê-lo. As perguntas abaixo seguem essa ideia, e a avaliação de segurança do fornecedor de IA aprofunda o lado do fornecedor.

• O agente tem identidade e contas próprias, ou usa o login de uma pessoa?
• Qual é o conjunto mínimo de permissões que permite exercer o papel, e quem aprova qualquer ampliação?
• Quem guarda as chaves de API do modelo e as credenciais de integração, a empresa ou o fornecedor? Isso importa tanto para a saída quanto para a segurança.
• O que é registrado: entradas, chamadas de ferramentas, aprovações, resultados? Por quanto tempo, e podemos exportar esses registros?
• Como o desenho trata conteúdo não confiável, como e-mails recebidos, páginas da web ou arquivos enviados que podem carregar instruções ocultas? As orientações da OWASP para aplicações com LLMs descrevem a injeção de prompt e os controles que a reduzem.
• As etapas de aprovação são impostas pelo sistema ou apenas pedidas nas instruções do agente? Uma instrução não é um controle.
• O que acontece quando muda a versão do modelo, uma integração falha ou um serviço do fornecedor fica indisponível: plano alternativo, reversão, aviso prévio?
• Quem responde a um incidente, e com que rapidez conseguimos pausar o agente por conta própria?

A TI também deve perguntar onde o agente se encaixa no ambiente maior. Um mapa de uma página com sistemas, fluxos de dados e as conexões do agente encurta bastante essa revisão, e o guia sobre o diagrama de arquitetura de IA em uma página mostra um jeito de produzi-lo. Se a empresa não tem uma área de TI dedicada, as mesmas perguntas continuam valendo. Alguém precisa responder por elas, seja um líder de operações, seja um consultor externo.

O que o Financeiro deve verificar?

O Financeiro raramente se preocupa com o valor de vitrine. A preocupação é se o custo total pode ser previsto, limitado e comparado a um resultado. Agentes trazem custos variáveis (uso de modelo, integrações, volume de tarefas) e fixos (implantação, suporte, tempo de revisão), e os contratos dividem tudo isso de formas diferentes.

• O que move o custo: usuários, uso, um retainer recorrente, consumo de modelo, taxas de integração? Quais desses itens são repassados ao custo e quais recebem margem?
• Existe um teto, um alerta ou uma etapa de aprovação quando o uso passa da previsão?
• O que fica fora do contrato: tempo interno de revisão, limpeza de dados, treinamento, gestão da mudança e supervisão contínua? O artigo sobre o custo total de propriedade de um agente de IA lista esses itens.
• Que unidade vamos medir, como custo por solicitação resolvida ou por documento processado, e quem acompanha? O material da FinOps Foundation sobre economia unitária ajuda a pensar nisso.
• Quais são o prazo, a renovação e as condições de saída, e há compromissos mínimos?
• Quem é o responsável pelo orçamento, e que resultado nos levaria a parar ou mudar de rumo?

O Financeiro também pode ajudar o patrocinador a evitar uma armadilha silenciosa: um piloto que prova que o agente funciona, mas nunca diz quanto vale esse funcionamento. Se o critério de sucesso do briefing não é observável, o Financeiro não consegue julgar o investimento, e a pergunta volta na renovação com menos boa vontade.

Como fica um pedido quando as três revisões se cruzam?

O cenário a seguir é ilustrativo, não um caso real.

A líder de operações de uma distribuidora quer um agente que leia e-mails de atraso de fornecedores, redija respostas e atualize uma planilha interna de acompanhamento. Ela escreve o briefing e o envia ao Jurídico, à TI e ao Financeiro no mesmo dia.

O Jurídico vê que os termos propostos permitem ao fornecedor reter prompts para melhoria do serviço e pede uma exclusão por escrito. A TI percebe que o agente rodaria a partir da caixa de e-mail da própria líder e pede uma caixa dedicada, com direito de leitura e de rascunho, e com o envio condicionado a um aprovador nomeado. O Financeiro encontra cobrança por uso sem limite e pede um teto mensal e um relatório de uso que corresponda à unidade indicada no briefing.

Nenhum desses pedidos entra em conflito com outro, e nenhum exige recomeçar a avaliação, porque cada revisor respondeu sobre a mesma descrição. As três mudanças entram no escopo de trabalho como requisitos numerados. Se as revisões tivessem ocorrido em sequência, cada mudança provavelmente teria reaberto as outras.

Veja como a Be Human trata o mesmo problema. Um primeiro projeto 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. Essa definição é o briefing descrito acima, de modo que Jurídico, TI e Financeiro recebem o mesmo documento. A operação gerenciada cobre depois monitoramento, avaliações recorrentes, manutenção de integrações, revisão de permissões e resposta a incidentes, o que dá a cada área algo concreto para apontar no contrato. As mudanças após a entrada em produção passam por um processo controlado, em vez de serem feitas de modo informal.

Perguntas frequentes

Quem deve liderar o processo de compras de um agente de IA? O dono do papel na área de negócio deve liderar, porque é quem sabe responder sobre finalidade, dados e sucesso. Jurídico, TI e Financeiro respondem cada um pela sua revisão, mas não deveriam ter de reconstruir o caso de uso. Se ninguém é claramente responsável, nomeie um coordenador cuja tarefa seja manter o briefing atualizado e acompanhar as perguntas em aberto.

Precisamos das três revisões para um piloto pequeno? Sim, mas de forma proporcional. Um piloto que não toca em dados pessoais, usa uma conta dedicada e tem um teto de gastos pode ser revisado rapidamente, mas as perguntas ainda precisam de resposta. O risco de um piloto pequeno é virar um sistema permanente sem nunca ter sido revisado.

Podemos reaproveitar o modelo de avaliação de fornecedores que já temos? Em parte. As seções padrão sobre segurança, privacidade e condições financeiras continuam valendo. Acrescente perguntas específicas de agentes: treinamento com os seus dados, identidade do agente, etapas de aprovação impostas pelo sistema, mudanças de modelo, registro das ações e o direito de pausar o agente.

E se o fornecedor não souber responder a uma pergunta? Trate o silêncio como informação. Peça a resposta por escrito e, se o fornecedor ainda assim não puder fornecê-la, reduza o escopo para que o risco desapareça ou registre-o como risco aceito, com um responsável nomeado. Não deixe a questão em aberto e siga adiante.

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