Como avaliar fornecedores de IA: guia para empresas médias

Contratar o fornecedor errado de IA custa mais do que não contratar nenhum. Custa o tempo do projeto, o capital investido, e - o que é mais difícil de quantificar - a credibilidade interna do tema para os próximos 18 meses.

Este guia é para gestores e líderes técnicos que precisam avaliar propostas de implementação de IA com rigor, sem ter uma equipe de IA interna que possa fazer isso por eles.

O problema com o mercado atual

Entre 2023 e 2025, o número de empresas que se apresentam como “consultoria de IA” multiplicou por dez no Brasil. A maioria são revendedoras de ferramentas SaaS com branding novo, agências de software que adicionaram “IA” ao portfólio, ou profissionais independentes sem experiência em produção.

Isso não é julgamento. É consequência natural de qualquer mercado aquecido. O problema é que as empresas compradoras raramente têm os critérios certos para distinguir quem entrega de quem apenas promete.

Os seis critérios que importam

1. Experiência em produção, não só em demos

A diferença entre um sistema de IA que funciona em demo e um que funciona em produção é enorme. Em produção, você precisa lidar com dados reais (que são sujos), usuários reais (que se comportam de forma imprevisível), e sistemas existentes (que têm APIs mal documentadas e comportamentos legados).

Perguntas para fazer ao fornecedor:

• Você tem sistemas que funcionam em produção há mais de seis meses? Posso conversar com o cliente?
• Como você lida com alucinações em sistemas de atendimento automatizado?
• Qual foi o maior volume de requisições que um sistema seu processou em produção?

Se o portfólio é composto só de projetos internos ou pilotos que “estão em avaliação”, isso é um sinal. Pilotos existem para validar o fornecedor, não para ser o portfólio dele.

2. Clareza sobre o que é produto e o que é serviço

Há dois modelos legítimos de entrega em IA:

Modelo produto: o fornecedor tem um sistema pronto (ou semi-pronto) que você configura para seu contexto. Tempo de implementação menor, menos customização, custo menor. Adequado quando seu problema é comum.

Modelo serviço: o fornecedor constrói algo sob medida para o seu contexto específico. Mais caro, mais demorado, potencialmente mais efetivo. Adequado quando seu problema tem particularidades que produtos genéricos não atendem.

O problema ocorre quando fornecedores apresentam um produto como se fosse serviço (vendendo customização que não fazem de verdade) ou vendem serviço quando um produto resolveria (porque o ticket é maior).

Pergunte diretamente: “O que você vai construir do zero para mim, e o que já existe como base?“

3. Capacidade de integração com seus sistemas

IA não existe no vácuo. Qualquer sistema útil precisa acessar seus dados (CRM, ERP, bases históricas), responder a usuários (via WhatsApp, Salesforce, portal interno), e ser monitorado pela sua equipe.

Avalie:

• O fornecedor tem experiência com seus sistemas específicos? (SAP, Salesforce, Totvs, sistemas legados)
• Como vai ser feita a autenticação e autorização nos sistemas existentes?
• Quem mantém as integrações quando há uma atualização no sistema de origem?

Fornecedores sem experiência em integração com sistemas legados frequentemente subestimam essa parte em 300% de esforço. É o maior fator de atraso em projetos de IA em empresas médias.

4. Governança de dados e compliance

Em qualquer projeto que envolva dados de clientes, colaboradores ou processos sensíveis, você precisa saber:

• Os dados vão sair da sua infraestrutura? Para onde?
• Se você usa modelos de terceiros (OpenAI, Anthropic, Google), quais dados são enviados?
• Quem é o responsável legal pelo processamento dos dados?
• Como serão tratados logs de conversação em sistemas de atendimento?

Se o fornecedor não consegue responder essas perguntas com precisão, ou trata o assunto como formalidade, é sinal de imaturidade no modelo de entrega.

5. Modelo de suporte e manutenção pós-go-live

Sistemas de IA degradam com o tempo. Modelos de linguagem recebem atualizações que mudam comportamentos. Dados da empresa mudam. Regras de negócio evoluem.

Perguntas essenciais:

• O contrato inclui manutenção ou é entrega única?
• Quem monitora o sistema em produção?
• Como é o processo para atualizar o sistema quando muda algo no negócio?
• Qual é o SLA para bugs críticos?

Muitos contratos de IA são de entrega de código-fonte sem suporte. Isso é adequado apenas se sua equipe interna tem capacidade de manter o sistema. Se não tem, isso vai gerar dependência implícita que não está precificada no contrato.

6. Modelo de precificação e o que está incluído

Os modelos de cobrança em IA variam muito:

• Projeto fixo: escopo fechado, risco de escopo rastejante alto em projetos de IA (porque o escopo real de um problema de IA raramente é claro no início)
• Time and materials: mais flexível, exige controle de horas e governança de escopo
• Success fee: alinhamento interessante, mas requer KPIs mensuráveis definidos antes do projeto
• Licença + implementação: modelo de produto, recorrência alta, customização baixa

Pergunte o que está incluído no preço: infraestrutura de nuvem, licenças de modelos de linguagem, horas de suporte pós-go-live, treinamento da equipe. Projetos de IA têm custos variáveis de operação (chamadas de API para modelos de linguagem) que podem surpreender.

O que o RFP não vai capturar

Processos formais de RFP são ruins para avaliar fornecedores de IA porque medem a capacidade de responder documentos, não a de construir sistemas.

O que funciona melhor:

• Prova de conceito paga: peça ao fornecedor para resolver um problema pequeno e real, por um valor fixo. Você aprende mais em 30 dias de PoC do que em 3 meses de avaliação documental.
• Referências verificadas: não peça referências - peça contato direto com o cliente, e ligue. Pergunte o que deu errado, não só o que deu certo.
• Entrevista técnica: coloque seu líder técnico ou um consultor independente para conversar com a equipe de engenharia do fornecedor. Não com o comercial.

Critérios de eliminação imediata

Elimine qualquer fornecedor que:

• Não consegue explicar de forma simples como o sistema vai funcionar tecnicamente
• Projeta resultados financeiros sem análise dos seus dados e processos
• Não tem contrato-padrão com cláusulas de dados e propriedade intelectual bem definidas
• Não tem ninguém na equipe com experiência comprovada em ML ou sistemas de IA em produção
• Usa “ChatGPT” como argumento técnico central (sem explicar arquitetura, fine-tuning, RAG ou qualquer detalhe)

Estrutura para a decisão final

Antes de fechar qualquer contrato, certifique-se de ter respondido:

1. Qual problema específico está sendo resolvido? Não “melhorar o atendimento” - qual volume, qual métrica, qual processo exato.
2. Qual é a hipótese de valor? O fornecedor consegue articular por que acredita que o sistema vai funcionar no seu contexto específico?
3. Qual é o critério de sucesso do projeto? Não subjetivo - número, prazo, condição de aceite.
4. O que acontece se não atingir o critério de sucesso? Quem assume o risco?
5. Sua equipe vai conseguir operar o sistema depois? Ou vai criar dependência permanente?

Avaliação bem feita não garante projeto bem-sucedido. Mas elimina a maior classe de falhas: o fornecedor errado para o problema errado.