Como escolher uma empresa de desenvolvimento de IA no Brasil sem comprar promessa

O que você está comprando quando contrata desenvolvimento de IA

O mercado brasileiro mistura três coisas diferentes sob o mesmo nome. Plataforma pronta de chatbot é licença de software: você aluga uma interface e adapta seu processo a ela. Consultoria é diagnóstico: alguém desenha a estratégia e entrega um documento. Desenvolvimento de IA sob medida é engenharia de software: alguém constrói um sistema que roda dentro da sua operação, conversa com seu ERP, seu CRM e seu banco de dados, e passa a ser um ativo da empresa.

A confusão custa caro porque os três têm preços e prazos incompatíveis. Quem compara a mensalidade de uma plataforma com o custo de um projeto de engenharia está comparando aluguel com construção. A pergunta correta não é qual é mais barato, e sim qual dos três resolve o problema que está travando a operação hoje.

Se o seu problema é responder mensagem repetitiva, plataforma pronta resolve. Se o seu problema é que um processo crítico depende de gente copiando dado entre sistemas, interpretando documento ou tomando decisão repetitiva com base em regra de negócio própria, nenhuma plataforma genérica vai encaixar. Aí você precisa de software feito para o seu caso.

• Plataforma: Você adapta seu processo ao produto. Rápido de ligar, limitado no que pode mudar, e o dado vive na infra do fornecedor.
• Consultoria: Entrega diagnóstico e recomendação. Útil para priorizar, mas não deixa sistema rodando no fim do contrato.
• Desenvolvimento sob medida: Entrega sistema que roda na sua operação e integra com seus dados. Mais lento no início, e vira ativo próprio.

Critérios técnicos que separam fornecedor sério de vendedor de demo

Demo de IA é fácil. Qualquer fornecedor consegue mostrar um modelo respondendo bem a cinco perguntas escolhidas por ele. O que separa engenharia de teatro é o que acontece nos casos que ninguém ensaiou: entrada malformada, sistema de origem fora do ar, resposta do modelo fora do formato esperado, volume dez vezes maior numa segunda-feira.

Pergunte como o sistema trata erro. Um fornecedor que construiu software de verdade responde com detalhes concretos: validação da saída do modelo contra um schema, fila de reprocessamento, fallback quando a API do provedor falha, log de cada decisão para auditoria. Um fornecedor que só montou demo muda de assunto para a qualidade do modelo.

Pergunte também sobre acoplamento a um provedor específico. Modelos mudam de preço, de política e de disponibilidade em prazos curtos. Uma arquitetura que trata o modelo como componente trocável protege você de mudança unilateral no roadmap de terceiros. Uma arquitetura que embute o provedor no meio da lógica de negócio, não.

• Tratamento de erro: Peça para descrever o caminho de falha, não o caminho feliz. Retentativa, fila, fallback e alerta precisam existir por escrito.
• Saída validada: Resposta de modelo deve ser validada contra formato esperado antes de virar ação no seu sistema. Sem isso, o erro chega no cliente.
• Troca de modelo: Provedor e modelo devem ser configuração, não código espalhado. Isso protege o custo quando o mercado mexe no preço.
• Observabilidade: Sem log de execução e métrica de uso, não há como saber se o sistema piorou depois de uma atualização do modelo.
• Integração real: Confirme se o fornecedor já escreveu integração com os sistemas que você usa, incluindo autenticação e limites de API.

Dados, LGPD e onde a informação da sua empresa vai parar

Em projeto de IA, o dado sai do seu perímetro com mais facilidade do que em software tradicional. Cada chamada a um modelo hospedado por terceiro é um envio de informação para fora. Se esse dado inclui cadastro de cliente, contrato, histórico médico ou informação financeira, a decisão deixa de ser técnica e vira responsabilidade jurídica da sua empresa como controladora.

Isso não significa que usar modelo de terceiro seja proibido. Significa que a decisão precisa ser explícita e documentada: quais campos saem, quais são anonimizados antes de sair, quanto tempo o provedor retém, e se há acordo que impeça uso do seu dado para treinamento. Fornecedor que nunca levantou esse tema no processo comercial provavelmente também não vai levantar durante a implementação.

Vale exigir por escrito a arquitetura de dados antes do contrato: onde ficam os dados em repouso, quem tem acesso ao ambiente de produção, como é feita a revogação de acesso quando alguém sai do projeto, e o que acontece com tudo isso no encerramento do contrato.

• Base legal: Defina antes do desenvolvimento qual base legal da LGPD sustenta o tratamento previsto. Depois de pronto, mudar é caro.
• Minimização: Envie ao modelo só o campo necessário para a tarefa. Mascarar identificador reduz exposição sem quebrar o caso de uso.
• Retenção do provedor: Verifique política de retenção e de uso para treinamento do provedor escolhido, e registre isso no contrato.
• Saída de dados: Exija cláusula de devolução e eliminação dos dados no encerramento, com prazo definido.

Contrato: propriedade do código, dependência e saída

A diferença mais cara entre fornecedores costuma estar no contrato, não na proposta técnica. Se o código-fonte fica com o fornecedor, você não contratou desenvolvimento: contratou uma assinatura com custo de projeto. No dia em que quiser trocar de parceiro, recomeça do zero. Propriedade intelectual do que foi feito sob encomenda deve estar escrita de forma explícita.

O segundo ponto é o plano de saída. Um contrato saudável descreve o que você recebe se a relação terminar: repositório completo, documentação de arquitetura, credenciais dos serviços em nome da sua empresa, e um período de transição. Contrato que não trata disso cria dependência silenciosa que só aparece quando já é problema.

O terceiro ponto é manutenção. Sistema com IA muda de comportamento mesmo sem você mexer nele, porque o modelo por trás é atualizado. Alguém precisa ser responsável por monitorar e corrigir. Defina escopo, tempo de resposta e preço da manutenção antes de assinar, não depois do primeiro incidente.

• Propriedade: Código sob encomenda deve ser seu, com cláusula explícita. Sem isso, cada melhoria aumenta o custo de trocar de fornecedor.
• Contas em seu nome: Provedores de modelo, nuvem e serviços devem estar no CNPJ da sua empresa, com o fornecedor como usuário.
• Plano de saída: Defina entregáveis e prazo de transição em caso de encerramento, incluindo repasse de documentação.
• Manutenção: Trate atualização de modelo e correção como escopo contratado, com prazo de resposta definido.

Como estruturar o primeiro projeto sem apostar a operação inteira

O erro comum é começar pelo processo mais visível da empresa. O melhor primeiro projeto é aquele com dor clara, dono definido, volume suficiente para justificar automação e uma forma objetiva de medir resultado. Se ninguém consegue dizer quanto tempo ou quanto retrabalho o processo consome hoje, não há como provar ganho depois.

Estruture em etapas com ponto de decisão entre elas. Primeiro, um escopo curto que prova a integração mais arriscada, não a mais bonita. Depois, colocar em produção com um grupo limitado de usuários reais. Só então ampliar. Cada etapa deve ter um critério de continuidade combinado antes, para que a decisão de seguir ou parar seja técnica e não política.

Antes do desenvolvimento, exija baseline: quanto tempo o processo leva hoje, quantos erros gera, quanto custa. Sem baseline, qualquer resultado apresentado depois é opinião. Com baseline, você consegue decidir sobre expansão com número em vez de impressão.

• Escolha do caso: Prefira processo repetitivo, com regra de negócio conhecida e volume mensurável. Evite começar pelo mais político.
• Baseline: Meça tempo, custo e taxa de erro antes de construir. Sem ponto de partida não há como avaliar o depois.
• Risco primeiro: O escopo inicial deve atacar a integração mais incerta. Deixar o difícil para o fim é como projetos estouram prazo.
• Critério de parada: Combine antes o que faz o projeto avançar ou ser encerrado, para evitar decisão emocional no meio do caminho.

Perguntas frequentes

Leia mais em IA para Negócios ou volte ao hub do blog.