Como escolher parceiro de implementação de IA para sua empresa

Para escolher um parceiro de implementação de IA, teste se ele vai assumir a responsabilidade por um resultado em funcionamento, e não se consegue demonstrar uma ferramenta. Um parceiro de verdade define um papel, a memória e as ferramentas de que esse papel precisa, os limites de aprovação e um critério de sucesso que você consegue observar. Depois do lançamento, ele continua mantendo o sistema no ar. Quem revende ferramentas genéricas costuma entregar o acesso e deixar o resto por sua conta.

Principais pontos

• Pergunte quem responde pelo resultado depois da demonstração. O parceiro é responsável por um papel funcionando na sua operação, enquanto o revendedor fornece licenças e treinamento.
• Avalie o primeiro escopo. Um papel útil com resultado observável é sinal mais forte do que um tour amplo pelos recursos da plataforma.
• Exija respostas claras sobre memória, fonte da verdade, permissões e pontos de parada antes de qualquer construção.
• Procure evidências que você mesmo consiga ler: casos de teste do seu trabalho real, uma execução em observação, registros e um checklist de aceitação.
• Trate a operação como parte da compra. Monitoramento, avaliação recorrente, manutenção das integrações e resposta a incidentes decidem se o sistema ainda funcionará depois.

O que realmente separa um parceiro de um revendedor de ferramentas genéricas?

A maioria das conversas de compra segue o mesmo roteiro. O fornecedor mostra um modelo capaz em uma interface bem acabada, conecta a uma caixa de e-mail ou a um repositório de documentos e chama isso de implementação. Na demonstração funciona, porque a demonstração foi preparada. O trabalho mais difícil começa depois: quando um documento está desatualizado, um login expira, um cliente escreve algo inesperado ou o agente é chamado para fazer algo que ninguém decidiu que ele deveria fazer.

O parceiro de implementação é responsável por esse trabalho mais difícil. O modelo de IA é só um componente. Ao redor dele existem instruções, memória, ferramentas, permissões, gatilhos, verificações e uma forma de ver o que aconteceu. As diferenças aparecem no comportamento de cada lado:

• O revendedor vende acesso a um modelo ou a uma plataforma. O parceiro responde por um papel funcionando dentro da sua operação.
• O revendedor mostra capacidades. O parceiro pergunta qual tarefa deve mudar e como você vai saber que mudou.
• O revendedor trata permissões como uma tela de configuração. O parceiro as trata como uma decisão de projeto, com um responsável.
• O trabalho do revendedor termina na entrega. O do parceiro inclui o que acontece quando algo quebra.
• O revendedor reporta uso. O parceiro reporta tarefas concluídas e exceções.

Nada disso significa que o revendedor seja desonesto. Muitas ferramentas são boas, e algumas empresas têm competência interna para operá-las bem. O risco é pagar por uma implementação e receber uma licença.

Ele começa por um papel e um critério de sucesso observável?

A primeira reunião revela muito. O revendedor tende a abrir com capacidades: o que o modelo resume, redige ou pesquisa. O parceiro abre com perguntas sobre o seu trabalho. Qual tarefa se repete, quem a faz hoje, como é um bom resultado e o que acontece quando dá errado?

Procure um primeiro escopo estreito e testável. Uma boa proposta indica o gatilho (uma nova consulta, uma reunião encerrada, um chamado de suporte), as informações que o agente pode usar, a saída que ele deve produzir, a pessoa que revisa e a evidência de que a tarefa foi concluída. Se a proposta cobre todos os departamentos de uma vez, ou promete um assistente para tudo, ninguém conseguirá dizer depois se funcionou.

Peça ao parceiro que escreva o papel em uma página que sua equipe possa testar. Se ele não consegue descrever o trabalho sem se apoiar no nome de um produto, ainda não projetou nada. Um bom parceiro também dirá quando um fluxo fixo, baseado em regras, é a melhor resposta para parte do trabalho. Um consultor que recomenda agente para todo problema está vendendo o agente.

Você pode se preparar para essa conversa. Percorrer um checklist de prontidão para implementar IA antes da primeira reunião permite responder às perguntas iniciais de um parceiro sério e perceber quando o fornecedor não as faz.

Como ele trata memória, contexto e a sua fonte da verdade?

A maior parte das falhas de agentes de negócio não é falha de inteligência. Elas acontecem quando o agente age com base em informação errada, antiga ou que nunca deveria ter chegado a ele. Por isso, pergunte ao parceiro como os fatos chegam ao agente e como são mantidos corretos.

Perguntas úteis:

• De onde o agente lê os fatos e qual sistema prevalece quando duas fontes divergem?
• O que ele lembra entre conversas e o que fica guardado como registro que uma pessoa pode consultar e corrigir?
• Como uma informação desatualizada é retirada e quem é responsável por perceber?
• Como os documentos são preparados e como a busca é testada com o seu material, e não com arquivos de exemplo?
• Como o sistema trata um texto dentro de um documento ou e-mail que tenta dar ordens a ele?

A última pergunta importa mais do que parece. Documentos de negócio vêm de clientes, fornecedores e do público, e qualquer um deles pode conter texto escrito para direcionar uma IA. O parceiro deve descrever uma defesa concreta: manter as instruções separadas do conteúdo, limitar o que uma ação disparada por documento pode fazer e exigir aprovação para etapas de consequência. Uma resposta como usamos um modelo seguro não é resposta.

O mesmo vale para a memória. Um agente que lembra de tudo é tão arriscado quanto um que não lembra de nada. Você quer um parceiro capaz de explicar o que é guardado, por quê, onde fica e como é corrigido.

Quem decide o que o agente pode acessar e quando ele deve parar?

É nas permissões que uma ferramenta genérica e um sistema projetado mais se diferenciam. Uma ferramenta costuma ser conectada com o acesso que facilita a configuração. Um sistema projetado parte do menor acesso que permite ao papel fazer seu trabalho, princípio explicado em menor privilégio para agentes de IA.

Peça para ver a lista de permissões de cada ferramenta, escrita em linguagem simples. Para cada item, você deve saber se o agente pode ler, preparar um rascunho ou enviar, quem aprovou esse nível e como o acesso será revisado ou revogado depois. Ler uma agenda, redigir uma resposta e enviá-la a um cliente são três decisões diferentes, e não devem ficar juntas em um único interruptor.

Depois pergunte sobre os pontos de parada. Quais ações sempre esperam por uma pessoa? O que o revisor vê: uma proposta de decisão limpa, com a evidência anexada, ou uma transcrição para decifrar? O que acontece se uma etapa for repetida, para que o cliente não receba o e-mail duas vezes nem um registro seja criado em duplicidade? O que acontece quando uma conexão expira no meio de uma tarefa? Bons parceiros têm respostas específicas, porque já projetaram para esses casos.

Se você atende clientes próprios, acrescente mais uma pergunta: como os dados de cada cliente são mantidos separados dos demais? Uma resposta vaga aqui é motivo para pausar.

Que evidências você verá antes e depois do lançamento?

A confiança deve vir de artefatos, não de garantias. Pergunte quais destes você vai receber:

• Um conjunto de casos de teste montado com as suas tarefas reais, incluindo as estranhas e incompletas, com o resultado esperado escrito de antemão.
• Um período em que o agente produz propostas enquanto as pessoas continuam fazendo o trabalho, para que os dois resultados possam ser comparados, como descrito em testar um agente de IA em modo de observação antes de dar autoridade a ele.
• Registros que mostram o que o agente recebeu, quais ferramentas chamou, o que decidiu e o que alterou, legíveis por quem não é engenheiro.
• Uma definição escrita de pronto para cada tarefa, de modo que concluir signifique ter evidência, e não uma mensagem animada.
• Um checklist de aceitação para cada integração, assinado antes de o papel entrar em operação.
• Relatórios de custo por tarefa concluída e de exceções, e não apenas de volume de mensagens.

O método para julgar esses testes está em como avaliar agentes de IA em tarefas de negócio. Para a escolha do parceiro, o ponto é mais simples: quem não consegue mostrar como saberia que o sistema está errado não merece confiança quando diz que ele está certo. Referências como o NIST AI Risk Management Framework tratam medição e monitoramento contínuo como parte da gestão de IA, o que ajuda a formular essa exigência em uma negociação de compra.

O que acontece depois do lançamento e quem é responsável?

Um agente não está terminado quando entra no ar. Documentos mudam, uma API altera seu comportamento, um login expira, a equipe adota uma nova ferramenta, um modelo é atualizado. Cada um desses é um evento pequeno que pode degradar os resultados sem alarde. Peça ao parceiro que descreva uma semana normal após o lançamento e, depois, um dia ruim.

Procure estes elementos:

• Monitoramento que percebe as falhas antes da sua equipe.
• Avaliações recorrentes sobre os mesmos casos de teste, para que a degradação apareça como mudança nos resultados.
• Uma rotina definida de manutenção das integrações e uma revisão periódica das permissões.
• Um processo de incidentes: quem é avisado, o que é pausado e como a causa é registrada.
• Um modo controlado de melhorar o sistema, em que as mudanças são testadas antes de substituir o que funciona.

A Be Human trabalha assim. 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. A operação gerenciada pode então incluir monitoramento, avaliações recorrentes, manutenção de integrações, revisão de permissões, resposta a incidentes e melhorias controladas. O agente mantém identidade, memória, canais, ferramentas e permissões sob controle humano, e o serviço é prestado remotamente, em português e inglês.

Um passo a passo para comparar dois ou três parceiros

Use o mesmo processo com todos os candidatos, para que as respostas possam ser comparadas de forma justa.

• Passo 1: Escreva o papel candidato em meia página: gatilho, informações de entrada, saída, revisor e o que significa pronto. Entregue a mesma página a todos os parceiros.
• Passo 2: Peça que cada um responda com escopo, memória e fonte da verdade, permissões, aprovações e um critério de sucesso, e não com uma lista de recursos.
• Passo 3: Solicite a lista de permissões em linguagem simples e os pontos de parada para ações de consequência.
• Passo 4: Pergunte como eles testariam o papel com os seus exemplos reais e qual período de observação propõem antes de o agente agir.
• Passo 5: Peça que descrevam o primeiro mês após o lançamento: monitoramento, avaliações, manutenção e tratamento de incidentes.
• Passo 6: Compare as respostas lado a lado. Marque o que for vago, o que depender do nome de um produto e o que adiar uma pergunta difícil para depois.
• Passo 7: Escolha o parceiro com o menor escopo, a evidência mais legível e a rotina de operação mais específica.

Cenário ilustrativo: uma empresa de serviços quer ajuda com as consultas que chegam de clientes. O parceiro A propõe um assistente para toda a empresa, conectado a e-mail, agenda e base de clientes, com treinamentos para a equipe. O parceiro B propõe um único papel: preparar um rascunho de resposta para cada nova consulta usando os documentos de serviço da empresa, nunca enviá-lo e registrar quais fontes usou. O parceiro B lista poucas permissões, indica quem revisa os rascunhos, propõe um período de observação sobre consultas passadas e descreve verificações semanais. Nenhum dos dois promete resultados. O parceiro B é o que a empresa consegue de fato avaliar, e por isso é o que deve preferir.

Perguntas frequentes

Devemos escolher uma grande consultoria, um especialista ou um fornecedor de software? O rótulo importa menos do que as respostas aos critérios acima. Uma grande consultoria pode ser a escolha certa quando a mudança atravessa muitas equipes, um fornecedor quando o produto já atende a uma tarefa estreita, e um especialista quando o trabalho é sobretudo integração, permissões e manutenção. Seja qual for a opção, pergunte quem fará o trabalho e quem estará acessível depois do lançamento.

Quanto tempo leva um primeiro projeto até vermos algo real? Depende dos seus sistemas, documentos e processo de aprovação, então desconfie de quem se compromete com um prazo antes de conhecê-los. Um primeiro marco razoável é um papel estreito rodando em modo de observação com exemplos reais, com registros que você consegue ler. Isso mostra mais do que uma longa fase de preparação sem nada visível.

Precisamos de uma pessoa técnica do nosso lado? Você precisa de um responsável, mas não necessariamente de um engenheiro. Essa pessoa deve conhecer a tarefa, aprovar os níveis de permissão, revisar as primeiras saídas e decidir quando o papel está pronto. O parceiro deve cuidar do trabalho técnico e explicá-lo em linguagem simples.

Podemos começar com um protótipo que nós mesmos construímos? Sim, e muitas vezes é um bom ponto de partida, porque já mostra a tarefa e os dados envolvidos. Um bom parceiro vai revisar o que você montou, manter o que funciona e ser explícito sobre o que falta, como permissões, testes, registros e operação. Desconfie se ele insistir em descartar tudo sem explicar por quê.

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