Por trás de 90% dos projetos de IA: dívidas de prompts, dívidas de recuperação e dívidas de avaliação estão arrastando as empresas na implementação

2025 年有 42% das empresas interrompem vários projetos de IA, muito acima dos 17% do ano anterior.
O problema não está na insuficiência de poder do modelo, mas sim em uma nova forma de dívida tecnológica que está acumulando silenciosamente na infraestrutura de IA das empresas, incluindo dívida de prompts, dívida de recuperação, dívida de avaliação.
(Resumindo: O que é Engenharia Harness? Desmembrando os 7 principais módulos de implementação de um Agente de IA (Engenharia de Controle de IA))
(Complemento de contexto: GPT-5.5 Instant disponível para todos os usuários, OpenAI ensina como escrever prompts de forma mais inteligente e eficiente)

Índice deste artigo

Alternar

• Três tipos de novas dívidas, mais difíceis de detectar que bugs
• Lacunas invisíveis na monitorização
• A solução não está no modelo, mas no design do sistema

42%, essa é a proporção de empresas que interromperam múltiplos projetos de IA em 2025, mais do que o dobro do ano anterior.
Dados da S&P Global Market Intelligence indicam que falhas em IA não são eventos isolados, mas problemas sistêmicos.
Estudos do MIT no mesmo ano apontam que 95% dos pilotos de IA nunca entram realmente em produção ou geram valor comercial quantificável.

Essas falhas geralmente são atribuídas à insuficiência do modelo, má qualidade dos dados ou ROI difícil de justificar.
Mas Vikram, diretor da Cota Capital, acredita que a causa real é mais oculta: uma nova forma de dívida tecnológica está acumulando silenciosamente nas camadas de prompts, dependência de modelos e avaliação dos sistemas de IA, completamente diferente da dívida de código tradicional, mas igualmente fatal.

Três tipos de novas dívidas, mais difíceis de detectar que bugs

A dívida tecnológica tradicional reside no repositório de código, onde bugs podem ser reproduzidos, testados e corrigidos.
A dívida de IA tem características completamente diferentes: ela é distribuída, espalhada por prompts, APIs de modelos, pipelines de dados e infraestrutura.

Ela é intermitente, pois os sistemas de IA são inerentemente probabilísticos, o mesmo input não garante o mesmo output;
Ela é quase invisível, pois o sistema "parece" estar funcionando normalmente, até que um momento crítico cause uma falha total.

Dívida de prompts (Prompt Debt) é a mais evidente das três.
Ela não possui registros temporários de ajustes, sem controle de versão para alterações de prompts, e o "enche de prompts" — inserir informações irrelevantes ou excessivas para fazer o modelo entender mais —.

O resultado é que os prompts se tornam uma espécie de código informal, sem tipos, testes ou controle de versões.
Cada ajuste é feito em um sistema opaco, e, acumulando-se, a vulnerabilidade do sistema cresce exponencialmente.

Dívida de dependência de modelos (Model Dependency Debt) surge da alta dependência de APIs de modelos externos.
A lógica do aplicativo é construída com chamadas a esses modelos, mas as atualizações desses fornecedores estão fora do controle da empresa.

Quando o fornecedor atualiza silenciosamente a versão, prompts ajustados para versões antigas podem falhar ou apresentar drift de comportamento,
perdendo reprodutibilidade.

Dívida de recuperação (Retrieval Debt) aparece na maioria das implementações de IA baseadas na arquitetura RAG.
O problema é que os repositórios de dados muitas vezes estão cheios de informações desorganizadas, arquivos duplicados e dados desatualizados.
Assim, as respostas retornadas pela IA podem estar tecnicamente corretas, mas já não são mais aplicáveis.
Isso é mais difícil de detectar do que alucinações, pois parece totalmente razoável e até passa na revisão de testadores comuns.

Lacunas invisíveis na monitorização

Dívida de avaliação (Evaluation Debt) é a mais subestimada das quatro novas dívidas de IA.
A maioria dos testes de benchmark de IA foca em avaliações pontuais e de escopo restrito, que não refletem o desempenho real após implantação.
A maioria das empresas carece de padrões de teste consistentes, conjuntos de dados de referência e mecanismos de monitoramento em tempo real dos modelos em produção.

Comparado ao desenvolvimento de software tradicional, que já possui processos maduros de CI/CD (Integração Contínua / Entrega Contínua),
a área de IA ainda não possui um mecanismo equivalente de "integração contínua de prompts".

Em termos simples: um engenheiro faz um merge de código, e há testes automatizados que indicam onde há problemas;
mas, ao modificar um prompt, não há sistema que alerte imediatamente.
Como resultado, CIOs e CTOs têm pouca visibilidade do desempenho real do modelo, e não conseguem acompanhar se a performance está deteriorando.

Essas quatro novas dívidas, somadas às dívidas tradicionais de código, aceleram sua acumulação composta.
E o pior: a propriedade dos sistemas de IA é dispersa — equipes de engenharia, produto, dados e negócios possuem partes diferentes, e quando há erro, a responsabilidade muitas vezes fica indefinida.

A solução não está no modelo, mas no design do sistema

Aumentar a precisão do modelo não resolve o problema.
Vikram argumenta que: a alta taxa de falhas não está relacionada à precisão do modelo, mas sim ao design do sistema, controle de integração e cultura organizacional.

Especificamente, prompts devem ser tratados como código, com controle de versão, documentação adicional e testes rigorosos antes e depois da implantação, cobrindo todas as configurações possíveis.

Mecanismos de avaliação precisam estar integrados em toda a pilha de infraestrutura de IA, criando pipelines de avaliação contínua, incluindo métricas técnicas e de negócio, além de sistemas de observabilidade de IA para monitorar qualidade de saída, taxas de falha, drift de modelos e dados.

Além disso, todos os resultados de IA devem incluir explicações interpretáveis, com origem dos dados, modelos utilizados e passos executados, de forma clara e auditável, permitindo correções rápidas em caso de falhas sistêmicas.

Isso exige, assim como na segurança cibernética ou na modernização de nuvem, a criação de planos específicos de eliminação de dívidas de IA e orçamentos dedicados, liderados por executivos de nível CXO.

Depois de tudo isso, fica claro: 95% das falhas não acontecem por falta de inteligência do IA, mas porque a construção do sistema ainda trata a IA como uma caixa preta, uma API, e não como um sistema complexo que exige engenharia rigorosa.
Dívida tecnológica nunca desaparece por si só, ela só acumula e, em algum momento, precisa ser paga com juros mais altos.