Empresa especialista em inteligência artificial: como escolher

Escolher uma empresa especialista em inteligência artificial é um problema de comparação, não de pesquisa. A lista longa qualquer um monta numa tarde, e ela não decide nada. O que decide é o funil depois dela: como sair de dez nomes plausíveis para três, o que perguntar nessas três conversas, o que colocar em um diagnóstico curto e remunerado rodando em paralelo entre os finalistas, e com qual critério escolher no fim. É desse percurso que este texto trata.

O critério de entrada eu já discuti em outro lugar: fornecedor que chega ao nome do modelo antes de entender como um pedido entra, tramita e sai da sua operação está vendendo o que tem em estoque, e o raciocínio inteiro está no texto sobre consultoria de inteligência artificial. Aqui isso é premissa, não conclusão. Essa diferença aparece já na primeira conversa, e costuma antecipar o resto do projeto. O problema começa depois dela, quando sobram três candidatos que passaram nesse filtro, todos com material bom, todos dizendo mais ou menos a mesma coisa.

Quatro filtros separam esses finalistas, e nenhum deles é porte, portfólio ou selo de parceria: quem faz diagnóstico antes de proposta, quem sabe explicar de onde vem o dado e como ele chega ao sistema, quem aceita registrar no contrato de quem são o modelo, o prompt e a base de conhecimento ao fim do projeto, e quem já prevê manutenção antes de você perguntar. Fornecedor que falha em qualquer um desses quatro pontos não é necessariamente ruim — mas está vendendo software, e software é a parte barata do problema.

O primeiro corte é a ordem em que o fornecedor decide

Esse filtro de entrada tem uma razão prática, e ela aparece na sequência mais comum de fracasso. A empresa decide que precisa de IA, escolhe uma plataforma, contrata licenças, distribui acessos e depois procura onde aplicar. Meses adiante, existe uma ferramenta paga, um punhado de usuários curiosos e nenhum indicador de negócio alterado. O erro não foi a escolha da ferramenta. Foi a ordem das decisões.

Um fornecedor sério inverte essa ordem, e isso custa a ele a venda rápida. Antes de nomear qualquer tecnologia, ele precisa entender qual decisão da operação é lenta, cara ou inconsistente, quanto volume passa por ali, qual o custo do erro e quem tem autoridade para mudar o processo. Só depois disso é possível dizer se o caso pede um assistente de recuperação de informação, um classificador, um fluxo com agentes ou coisa nenhuma. A resposta honesta às vezes é que o problema é de processo e não se resolve com modelo algum — e a disposição de dizer isso, com um contrato na mesa, é um dos indicadores mais fortes de competência que existem.

Há um segundo sinal na mesma direção. Quem implanta trabalha com escopo recortado e critério de sucesso definido antes de começar. Quem revende trabalha com adoção: o objetivo implícito é que mais gente use a plataforma, porque uso justifica renovação. São incentivos diferentes, e eles produzem projetos diferentes.

A reunião comercial é o teste técnico mais barato que você tem

Você não precisa de auditoria técnica para separar os dois perfis. Precisa de meia dúzia de perguntas específicas e da disciplina de não aceitar resposta genérica. Estas costumam bastar:

• De qual sistema sai o dado que alimenta essa solução, em que formato ele está hoje e o que precisa acontecer antes de ele ser utilizável?
• Como vamos medir se funcionou, com qual medição de linha de base feita antes de começar?
• O que o sistema faz quando o modelo erra — e como eu fico sabendo que ele errou?
• De tudo o que vocês entregaram, quantos sistemas vocês operam hoje, em produção, com alguém responsável por eles?
• Quem, nominalmente, vai trabalhar nesse projeto, e essas pessoas estão nesta reunião?
• Onde o nosso dado é processado, ele fica retido em algum lugar depois e é usado para treinar qualquer modelo?

A pergunta sobre nomes desarma mais fornecedores do que as técnicas. Na maioria das empresas de tecnologia que conheço, comercial e entrega são times distintos — e essa distância é onde já vi mais projeto azedar. A pergunta sobre erro também é reveladora: quem já operou IA em produção responde falando de validação, faixa de confiança, rota de exceção e revisão humana, porque conviveu com o problema. Quem nunca operou responde que o modelo é muito bom. O comportamento do sistema diante da própria falha, incluindo o que se faz com as alucinações, é engenharia deliberada, não característica do modelo escolhido. Já a pergunta sobre o dado tem um segundo uso: a resposta dada de improviso na reunião é a que você vai cobrar por escrito no contrato, e a diferença entre as duas versões costuma ser instrutiva.

Sinais de alerta aparecem antes da proposta chegar

Promessa de resultado antes de diagnóstico é o primeiro. Nenhum fornecedor consegue estimar ganho percentual em um processo que ainda não viu, com um dado que ainda não abriu. Quando o número aparece cedo, ele veio de material de marketing, não de análise, e serve para ancorar a negociação.

Caso de sucesso sem número verificável é o segundo. Histórias contadas em adjetivos — ganho expressivo, adoção enorme, transformação profunda — não são casos, são narrativas. O que constitui caso é: qual era a medição antes, qual passou a ser depois, em quanto tempo, medida como, e existe alguém do cliente disposto a confirmar isso numa ligação. Ausência de referência acessível é informação.

O terceiro sinal é a proposta que começa pela ferramenta e trata integração como detalhe de implementação. Quando o documento dedica páginas à plataforma e um parágrafo a “integração com sistemas legados a definir”, o risco inteiro do projeto foi empurrado para depois da assinatura. É ali que o cronograma costuma estourar.

O quarto sinal é mais sutil, e é o que mais engana comprador experiente: a demonstração que roda sobre dados do próprio fornecedor. Demo é um ambiente construído para funcionar. Os documentos foram escolhidos, as perguntas foram testadas antes, o que travava saiu do roteiro. Isso não é desonestidade, é o formato — e por isso a demo não informa quase nada sobre o seu caso.

O contraponto é barato, e é o mesmo movimento em qualquer setor: peça a demonstração sobre uma amostra da sua operação, e monte a amostra você. Quem escolhe os casos precisa ser o cliente, com uma pessoa que conheça o processo por dentro, não o comercial nem o fornecedor. A amostra deve conter três faixas: os casos fáceis, que representam o volume do dia a dia; os atípicos, que a operação encontra toda semana e que ninguém documenta; e um punhado dos piores itens do acervo — o escaneado torto, o campo livre preenchido às pressas, o documento que tem duas versões conflitantes. Não precisa ser grande, precisa ser representativa e conter o pior. E o que se mede fica definido antes de o fornecedor tocar no dado: taxa de acerto por faixa, o que o sistema faz quando não sabe (se admite, se inventa, se escala para um humano), quanto tempo leva por resposta e quanto custa cada uma. Fornecedor que negocia a composição da amostra está dizendo, sem querer, onde o sistema dele quebra.

Capacidade de dado é o filtro que separa de verdade os candidatos

O que diferencia empresas capazes das demais raramente é o modelo — quase todo mundo consome os mesmos fornecedores de modelo. A diferença está na camada de dado, e é uma diferença de engenharia dura. Extrair informação de sistemas internos, tratar formatos inconsistentes, lidar com documentos digitalizados de qualidade variável, respeitar permissionamento para que um usuário não receba resposta construída sobre um dado que ele não pode ver, manter tudo isso atualizado sem intervenção manual: é aqui que projetos vivem ou morrem.

Vale perguntar como o fornecedor pretende dar à IA acesso ao conhecimento da empresa. Se a resposta for “colamos os documentos no prompt”, o desenho não sobrevive ao volume. Fora esse caso extremo, a resposta se lê por dois indícios. Domínio aparece quando o fornecedor devolve perguntas antes de responder: quantos documentos são, em que formato estão, com que frequência mudam, quem pode ver o quê, e o que o sistema deve fazer quando duas versões do mesmo documento discordam entre si. Improviso aparece quando a recuperação aumentada por geração é apresentada como recurso que a plataforma já traz pronto, sem nenhuma decisão a tomar e sem nenhum ponto de falha a discutir. As decisões existem e são muitas; quem ainda não as enfrentou vai enfrentá-las durante o seu projeto, no seu orçamento.

A mesma régua vale para integração. Perguntar quais sistemas o fornecedor já integrou, com quais protocolos, e o que ele faz quando a API do ERP não expõe o campo necessário separa quem tem cicatriz de quem tem apresentação. Projeto de IA empresarial é, em grande medida, um projeto de integração com um modelo no meio.

Quem fica dono do modelo, do prompt e do dado

Esta é a cláusula que quase ninguém lê e que define o custo de sair. Ao fim de uma implantação existem ativos que não são a licença da plataforma: os prompts de produção, ajustados ao longo de meses; os conjuntos de avaliação que definem o que é resposta certa no seu contexto; a base vetorial construída sobre o seu conhecimento; eventuais pesos de ajuste fino; a documentação das integrações. Quando o contrato é silente, a titularidade de prompts, conjuntos de avaliação e base vetorial vira disputa: nenhum desses ativos tem enquadramento óbvio — não são exatamente programa de computador, não são exatamente o seu dado bruto, não são exatamente documentação técnica —, e é por isso que precisam ser nomeados por escrito, item a item, como entregáveis do cliente. Sem isso, a discussão só acontece no pior momento possível, que é o da saída.

O ponto sensível é o dado, e é aqui que a pergunta feita na reunião precisa virar cláusula: onde ele é processado, se é retido, se é usado para treinar qualquer modelo e o que acontece com ele no encerramento. Quem trabalha com IA empresarial responde isso de imediato, porque a pergunta é rotina. Quem improvisa pede para verificar e volta com uma resposta ambígua. Um bom critério prático: peça o plano de saída antes de assinar o de entrada. Fornecedor confiante em ser mantido não tem problema em descrever como você o substituiria.

Sistema de IA sem manutenção apodrece em silêncio

Software tradicional quebra de forma visível. Sistema de IA se degrada sem avisar. Modelos são descontinuados e substituídos por versões que se comportam de outro jeito; o vocabulário e os documentos da operação mudam; um processo interno é alterado e ninguém informa quem cuida do sistema; a base de conhecimento envelhece. O resultado é uma queda gradual de qualidade que ninguém detecta, porque o sistema continua respondendo com a mesma fluência de sempre.

Por isso um contrato que termina na entrega é um contrato mal desenhado. A técnica de monitorar isso é assunto de quem constrói, e está detalhada no texto sobre software com IA embarcada. O que interessa ao contrato é outra coisa: quem faz, quando, e às custas de quem. Precisa estar nomeado com que periodicidade a qualidade das respostas é revisada e contra qual referência; o que dispara uma reavaliação fora do calendário — a descontinuação ou substituição do modelo em uso, uma mudança no processo do cliente, uma queda detectada em produção; quem executa essa revisão, nominalmente; o que dela está incluído no valor mensal e o que é cobrado à parte; e em quanto tempo o fornecedor precisa responder quando o comportamento do sistema muda sem ninguém ter mexido nele. Contrato que resolve tudo isso com uma linha genérica de “suporte” deixou a conta em aberto, e ela chega. O fornecedor que trata manutenção como upsell posterior está transferindo a você um risco que ele conhece melhor do que você.

Listas de fornecedores respondem “quem existe”, não “quem serve”

Mapas de mercado são úteis no início, para formar repertório e entender quem atua em qual camada. Para quem contrata daqui, o levantamento das empresas de inteligência artificial no Brasil serve bem como ponto de partida da lista longa: dá nomes, segmenta por atuação e evita que a busca comece e termine nos dois fornecedores que apareceram no último evento do setor.

O que nenhuma lista resolve é a lista curta. Nome grande não garante que a sua conta receberá gente sênior, e empresa pequena não garante proximidade — garante apenas que há menos pessoas entre você e quem executa. A decisão real acontece na conversa, com as perguntas acima na mão, e depois num piloto pago de escopo pequeno, com critério de sucesso escrito antes de começar. Piloto é a forma mais barata de comprar informação sobre um fornecedor.

O que eu faria no seu lugar

Eu descartaria qualquer proposta que chegue antes de alguém ter olhado o meu dado. Escolheria dois ou três candidatos pelo modo como conduziram a primeira conversa, não pelo material, e contrataria de cada um um diagnóstico curto e remunerado sobre o mesmo problema. A qualidade desses diagnósticos diz mais do que qualquer apresentação institucional: costuma acontecer de um deles reformular o problema de um jeito que você não tinha considerado — e, quando acontece, é com esse que vale seguir.

E manteria em mente que a decisão sobre uma empresa especialista em inteligência artificial não é uma compra de tecnologia, é uma escolha de parceria técnica de médio prazo. O ativo que fica não é o modelo, que será trocado; é o entendimento acumulado sobre como o seu processo funciona, codificado em prompts, avaliações, integrações e dados organizados. Quem contrata pensando em ferramenta compra a parte que envelhece mais rápido.

---

Se você está avaliando fornecedores agora e quer estruturar o critério antes da próxima reunião comercial, essa é uma das frentes que conduzo à frente do Grupo WYS, com uma metodologia própria de diagnóstico e implantação de IA empresarial. O caminho mais direto é o contato; se o momento ainda é de alinhar a liderança sobre o que a IA muda no negócio, o caminho das palestras existe para isso.