Sinais de alerta ao contratar consultoria de IA: o que checar

Os sinais de alerta mais claros em uma consultoria de IA são: escopo vago, demonstrações que não se repetem com o seu material, ausência de plano para operar o sistema depois do lançamento e contratos que deixam propriedade, acesso e saída indefinidos. Um parceiro capaz de entregar define um papel, nomeia os limites de aprovação, mostra como o sucesso será medido e explica quem opera o agente meses depois do go-live. Se a proposta evita esses pontos, trate o acabamento dela como alerta, não como conforto.

Principais pontos

• Um parceiro confiável restringe o trabalho a um papel, com limites de aprovação e uma medida de sucesso observável, antes de falar de modelos ou ferramentas.
• Uma demonstração só vale se rodar com o seu material, mostrar uma falha com honestidade e puder ser repetida pelas suas próprias pessoas.
• O contrato deve dizer quem é dono dos prompts, da configuração, da memória e dos logs, e como você sai sem perder nada disso.
• Pergunte quem monitora, avalia e corrige o agente depois do lançamento, e com qual rotina. Uma resposta vaga costuma significar que ninguém.
• Certeza sem limites é o padrão por trás da maioria dos projetos ruins: promessa de resultado, nenhuma exclusão declarada e nenhuma conversa sobre o que o agente nunca deve fazer.

O que em uma proposta indica que o parceiro não consegue entregar?

A proposta é o primeiro lugar em que um parceiro fraco se revela, porque escrever uma proposta precisa exige já ter feito o trabalho antes. Propostas fracas descrevem uma ambição. As fortes descrevem uma tarefa.

Observe estes sinais:

• O escopo é uma transformação da empresa inteira, em vez de um papel definido, com início e fim.
• Ninguém do seu lado é nomeado como responsável pelo processo que o agente vai tocar.
• O sucesso é descrito como adoção, eficiência ou inovação, sem nenhuma medida que você consiga observar numa semana comum.
• Modelos, plataformas e nomes de ferramentas abrem o documento, enquanto processo, dados e pessoas mal aparecem.
• Permissões não são discutidas. A proposta nunca diz o que o agente pode ler, o que pode alterar e o que exige aprovação humana.
• O cronograma não tem pontos de revisão, apenas uma data de lançamento.
• As referências são histórias bem polidas, sem detalhe sobre o que o parceiro construiu, o que o cliente fez e se o sistema continua funcionando.

Esse último ponto merece cuidado. Um estudo de caso é peça de marketing, a menos que você consiga ver o método, os limites e a situação atual. O artigo sobre como avaliar estudos de caso de IA sem se deixar enganar mostra o que perguntar quando o parceiro usa trabalhos anteriores como prova.

Repare também no que a proposta não diz. Se ela nunca menciona o que o agente vai errar, como os erros são detectados ou quem é avisado quando algo falha, é provável que o autor não tenha operado um sistema assim por muito tempo.

Quais comportamentos em uma demonstração pedem cautela?

Uma demonstração é persuasiva por construção. Seu trabalho é descobrir se ela é representativa. O problema mais comum não é fraude, e sim um ambiente controlado que esconde como o sistema se comporta com entradas reais.

Tenha cautela quando:

• Toda entrada é digitada por quem apresenta e você nunca pode fornecer a sua.
• Os dados são exemplos genéricos, e não algo parecido com os seus documentos, os seus hábitos de nomenclatura e a sua bagunça.
• Nenhuma resposta cita de onde veio, então você não distingue consulta de invenção.
• A demonstração nunca falha. Sistemas reais falham diante de pedidos ambíguos, registros ausentes e documentos contraditórios, e um parceiro que já operou um deles mostra como a falha é tratada.
• O agente age com credenciais amplas, como acesso total a uma caixa de e-mail ou a um drive compartilhado, porque foi mais fácil de configurar.
• Não existe log. Se você pergunta o que o agente fez há um instante e a resposta é um resumo de memória, não há trilha de auditoria em que confiar.
• Quem apresenta não sabe dizer o que acontece quando um documento contém instruções dirigidas ao agente. Essa é uma classe conhecida de ataque, descrita nas orientações da OWASP sobre prompt injection, e um parceiro competente tem posição sobre ela.

Uma boa jogada é pedir uma sessão curta com uma pequena amostra do seu material, incluindo alguns casos incômodos que você escolhe com antecedência. O guia como avaliar uma demonstração de agente de IA mostra como montar esse teste sem um projeto longo.

Observe como o parceiro reage. Um bom parceiro se interessa pelos casos incômodos, porque eles são o trabalho de verdade. Um fraco volta ao fluxo preparado.

O que deve preocupar você no contrato?

Contratos revelam quem espera ser responsável. Algumas cláusulas, ou a ausência delas, antecipam como a relação vai se comportar quando algo quebrar.

• Nenhuma entrega definida. O acordo descreve horas ou um retainer, mas não o que existe no fim, como um papel documentado, uma configuração testada ou um pacote de transição.
• Propriedade indefinida. Prompts, fluxos, memória, conjuntos de avaliação e logs não são atribuídos a você, ou são licenciados de um jeito que deixa de funcionar quando o contrato acaba.
• Nenhum caminho de saída. Não há descrição de formatos de exportação, apoio na transição nem de como credenciais e integrações são devolvidas.
• Silêncio sobre o uso dos dados. O acordo não diz se o material da sua empresa pode ser usado para treinar algo, nem onde ele é armazenado e processado.
• Credenciais só com o parceiro. Se contas, acesso a APIs e hospedagem estão todos no nome dele, você não consegue sair rápido.
• Direito de alteração sem limites. O parceiro pode mudar o agente em produção sem solicitação, revisão ou registro.
• Linguagem de responsabilidade unilateral. Tudo o que dá errado é responsabilidade do cliente, ou nada é responsabilidade de ninguém.

O escopo de trabalho é onde a maioria desses pontos se resolve. O artigo sobre o que incluir no escopo de trabalho para implantação de agente de IA lista as seções que você deve exigir, e o guia sobre como migrar agentes de IA para outro fornecedor ajuda a entender quais dependências merecem preocupação e quais são normais.

Um sinal a mais está fora do texto. Se o parceiro resiste a respostas por escrito e prefere resolver tudo em reuniões, a falta de registro vai pesar mais tarde.

Quem opera o agente depois do lançamento, e como descobrir?

Esta é a pergunta que a maioria dos compradores faz tarde demais. Construir um agente é um projeto. Operar um agente é um serviço, e as habilidades são outras. Modelos mudam, integrações quebram, documentos ficam desatualizados, pessoas saem e permissões se desviam. Um sistema que estava correto no lançamento não continua correto sem atenção.

Sinais de alerta sobre operação:

• A entrega final é um documento e uma ligação rápida, e depois o parceiro some ou só atende mediante cobrança avulsa.
• O parceiro diz que o modelo é capaz o bastante e que quase não precisa de manutenção.
• Não há plano de monitoramento. Ninguém é descrito como responsável por observar erros, custo, latência ou ações incomuns.
• Não há avaliação recorrente. A qualidade é julgada pelo fato de alguém reclamar ou não.
• Mudanças são feitas por quem tem acesso, sem solicitação, aprovação ou reversão. Um processo mais sensato passa por pedidos de mudança formais, com aprovação e possibilidade de voltar atrás.
• Uma única pessoa no parceiro concentra todo o conhecimento da configuração, e a ausência dela paralisa tudo.
• A resposta a incidentes não está definida. Você não sabe quem acionar, em quanto tempo o agente pode ser pausado nem quem decide.

Observabilidade é um bom teste. Pergunte o que o parceiro registraria para saber se o agente está saudável e como rastrearia uma resposta errada até as entradas que a originaram. Conceitos gerais de observabilidade, como os do material introdutório do OpenTelemetry, dão o vocabulário para julgar se a resposta é concreta.

Como a Be Human trata isso: o 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. Depois do lançamento, a operação gerenciada pode incluir monitoramento, avaliações recorrentes, manutenção de integrações, revisão de permissões, resposta a incidentes e melhorias controladas, com identidade, memória, canais e permissões do agente sob controle humano do lado do cliente. A ideia é que quem construiu o agente e quem o mantém saudável respondam ao mesmo plano.

Se o motivo da contratação é não ter de operar o sistema por conta própria, compare as opções em agência de automação com IA ou provedor gerenciado antes de assinar qualquer coisa que termine no lançamento.

Checklist para a sua próxima conversa com o fornecedor

Use estas perguntas em uma reunião ou por escrito. Elas foram feitas para que um parceiro preparado responda com poucas palavras e um parceiro fraco se perca.

• Qual será o primeiro papel do agente, e o que ele não vai fazer?
• Quem do nosso lado aprova ações, e quais ações exigem aprovação?
• O que o agente lê, escreve e envia, e com que nível de acesso?
• Como vamos saber que está funcionando, usando algo que podemos observar sem perguntar a vocês?
• O que acontece quando o agente erra, e como isso é detectado?
• Mostrem uma falha de um projeto anterior e o que mudou depois, sem citar o cliente.
• Quem monitora o sistema depois do lançamento, e o que verifica a cada ciclo?
• Como as mudanças são solicitadas, aprovadas, testadas e revertidas?
• Quem é dono dos prompts, da configuração, da memória, dos conjuntos de avaliação e dos logs?
• Se encerrarmos o contrato, o que recebemos, em que formato e com que ajuda?
• Onde os nossos dados são armazenados e processados, e são usados para treinar algum modelo?
• Quem é a segunda pessoa que entende a nossa configuração?

Avalie as respostas pelo padrão, não pelo acabamento. Uma resposta ausente não é falha se o parceiro se compromete a responder por escrito. Evasão repetida, respostas que apenas reformulam a pergunta ou que se apoiam em garantias vazias são o sinal para desacelerar. Vários itens sem resposta em sequência indicam que você deve pausar o processo, não negociar com mais força.

Cenário ilustrativo: duas respostas ao mesmo pedido

Este é um exemplo ilustrativo, não um caso real. Uma distribuidora quer um agente para tratar e-mails rotineiros de fornecedores sobre o status de pedidos. Ela pede proposta a dois parceiros.

O primeiro propõe uma camada inteligente de operações para compras, financeiro e atendimento. A demonstração é fluida, usa e-mails de exemplo da biblioteca do próprio parceiro, e o agente tem acesso total à caixa de e-mail. O contrato é um retainer mensal sem entregas listadas, e os prompts são descritos como ferramenta proprietária. Quando perguntam quem acompanha o agente depois do lançamento, a resposta é que o sistema aprende com o tempo.

O segundo propõe um único papel: ler as solicitações de status que chegam, consultar o pedido no sistema da empresa, redigir uma resposta e enviar apenas as que seguem um padrão definido, deixando o restante para uma pessoa. A proposta nomeia o líder de operações do comprador como aprovador, lista o que o agente pode ler e escrever e define uma medida de sucesso que a equipe verifica toda semana, como rascunhos aceitos sem edição. A demonstração usa cinco e-mails reais escolhidos pelo comprador, incluindo um com número de pedido errado, e o agente o sinaliza em vez de adivinhar. O escopo de trabalho atribui à empresa a propriedade da configuração e dos logs e descreve a rotina de monitoramento.

Nenhum dos dois parceiros tem garantia de sucesso. Mas só o segundo deu ao comprador meios de descobrir, cedo e a baixo custo, se o trabalho é sólido. Essa é a diferença que você deve procurar.

E se os sinais de alerta já estiverem presentes?

Se você já está em um projeto e reconhece vários desses sinais, há opções antes de encerrar. Peça por escrito o que falta: escopo, permissões, medida de sucesso, propriedade e rotina de operação. Solicite um ponto de verificação com escopo reduzido, como um papel em uso controlado, para ver evidências em vez de promessas. O artigo sobre critérios de sucesso para piloto de agente de IA ajuda a decidir que evidência é justo esperar em cada etapa.

Se o parceiro responde com clareza, a relação pode se recuperar. Se a resposta for defensiva ou mais demonstrações, você aprendeu o que precisava saber enquanto o custo de sair ainda é baixo.

Perguntas frequentes

Uma demonstração muito polida é mau sinal? Não por si só. Ela vira problema quando você não pode mudar as entradas, ver uma falha ou inspecionar o que o agente fez. Peça para levar a sua própria amostra e julgue o parceiro pela forma como ele lida com os casos incômodos.

Devo evitar parceiros que não dão referências de clientes? Não automaticamente, já que muitos projetos são confidenciais. Mas um parceiro que não consegue descrever trabalhos anteriores em termos concretos e anonimizados, incluindo o que deu errado, deixou pouco para você avaliar. Peça o método e as lições aprendidas, e dê a eles mais peso do que a uma lista de logotipos.

Qual é a cláusula contratual mais importante? Propriedade e saída. Se você é dono da configuração, da memória, do material de avaliação e dos logs, e o contrato descreve como tudo isso é devolvido, você mantém a capacidade de trocar de parceiro. A maioria dos outros problemas fica mais fácil de corrigir quando essa cláusula está sólida.

Quanto tempo devo gastar avaliando um parceiro? Ajuste o esforço ao acesso que ele terá. Um primeiro papel restrito e com poucas permissões exige uma revisão mais curta do que um agente que envia mensagens ou altera registros. Seja qual for o tamanho, um teste prático curto com o seu próprio material vale mais do que mais uma apresentação.

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