1
Vulnerabilidade técnica e CDC
A assimetria técnica entre cliente e fornecedora pode justificar a aplicação do CDC e a inversão do ônus da prova.
Radar ERP · TJSP & Tecnologia
TJSP &
Tecnologia
2º Quadrimestre 2026 (Maio–Agosto)
Seleção de acórdãos do TJSP julgados entre maio e 18 de agosto de 2026 sobre implantação, licenciamento e operação de software empresarial. A síntese abaixo reúne os principais takeaways; a análise completa vem em seguida.
Advocacia Adriano Dib · São Paulo, agosto de 2026
2
44,5% executado pode não bastar
Percentual de avanço não substitui utilidade: o ponto decisivo é se o sistema entregue podia efetivamente ser utilizado.
3
Sem Go-Live não significa remuneração zero
Na rescisão antecipada, serviços comprovadamente executados podem ser remunerados, inclusive à luz do art. 603 do Código Civil.
4
Implantação precisa ser provada
Horas faturadas e documentos comerciais não demonstram, por si, instalação, configuração, treinamento e preparação para uso.
5
Sem Go-Live: prova documental pode bastar
O TJSP admitiu julgamento antecipado e afirmou que o resultado seria o mesmo mesmo sem a aplicação do CDC.
6
Pequenos defeitos não significam inadimplemento
Falhas corrigíveis que não impedem o uso do sistema não autorizam, por si, o abandono do projeto.
7
Falhas pontuais ≠ imprestabilidade
Para rescindir, não basta provar bugs: é preciso demonstrar que sua gravidade ou frequência tornou o sistema inadequado ao uso.
Fio condutor. Os julgados sugerem uma leitura funcional dos contratos de tecnologia: quem conduzia o projeto, o que foi efetivamente entregue, se houve Go-Live e, depois dele, se as falhas comprometiam a utilidade do sistema.
Análise dos acórdãos selecionados
1. Vulnerabilidade técnica e CDC
Fatos
Empresa agrícola contratou licenciamento e implantação de software de gestão. Diante do insucesso do projeto, a fornecedora ajuizou ação monitória; a cliente sustentou falhas em módulos e integrações e requereu instrução.
Decisão
O TJSP anulou a sentença de julgamento antecipado. Reconheceu vulnerabilidade técnica concreta da contratante perante a empresa especializada, aplicou a teoria finalista mitigada, inverteu o ônus da prova e determinou perícia e prova oral.
Por que importa
O precedente mostra que a complexidade técnica do projeto pode repercutir diretamente no regime probatório. Porte empresarial, isoladamente, não elimina a possibilidade de vulnerabilidade técnica.
2. 44,5% executado pode não bastar
Fatos
A prova técnica quantificou em 44,5% os serviços executados. Apesar do avanço, o sistema não atingiu estágio que permitisse utilização efetiva pela contratante.
Decisão
O TJSP manteve a responsabilização da fornecedora e afastou culpa concorrente. Destacou seu maior domínio técnico do objeto e o dever de zelar pelo adequado desenvolvimento do software.
Por que importa
O acórdão reforça uma ideia central nas disputas de implantação: esforço ou percentual de execução não equivalem, por si, a resultado útil. A especialização da fornecedora também pesa na análise de condução do projeto.
3. Sem Go-Live não significa remuneração zero
Fatos
A cliente rescindiu antecipadamente contrato de implementação. O instrumento previa remuneração pelos serviços executados e a perícia estimou que aproximadamente metade dos trabalhos havia sido realizada.
Decisão
O TJSP reconheceu o direito da fornecedora às parcelas vencidas e à remuneração correspondente a 50% dos serviços previstos até o final do contrato, apoiando-se na cláusula contratual, na prova pericial e no art. 603 do Código Civil.
Por que importa
É um precedente relevante para fornecedoras: ausência de Go-Live não elimina necessariamente o valor econômico do trabalho já prestado. Cláusula contratual adequada e prova objetiva do avanço podem ser decisivas.
4. Implantação precisa ser provada
Fatos
Fornecedoras cobravam valores e cláusula penal após a rescisão de contrato de implantação. Alegavam cerca de 80% de execução, mas desistiram da perícia e apresentaram documentos que não demonstravam concretamente instalação, configuração ou treinamento.
Decisão
O TJSP manteve a improcedência. Considerou insuficientes contrato, proposta, notas fiscais, e-mails e notificação para comprovar o avanço efetivo da implantação.
Por que importa
O caso separa esforço de entrega. Para cobrar pelo trabalho realizado, a fornecedora precisa construir evidência contemporânea e tecnicamente verificável das etapas efetivamente concluídas.
5. Sem Go-Live: prova documental pode bastar
Fatos
A cliente pagou mensalidades, mas o ERP jamais entrou em produção. A fornecedora alegou culpa concorrente e cerceamento de defesa pela ausência de perícia.
Decisão
O TJSP manteve a restituição integral e o julgamento antecipado. Aplicou o CDC, mas registrou que, mesmo sem sua incidência, a conclusão seria a mesma diante da prova documental do inadimplemento. A culpa concorrente foi afastada por falta de prova concreta.
Por que importa
O precedente reduz a importância prática da discussão abstrata sobre o CDC quando a prova documental é robusta. Também mostra que perícia não é automática e que a culpa concorrente exige demonstração específica da contribuição causal da cliente.
6. Pequenos defeitos não significam inadimplemento
Fatos
A cliente resistiu ao cumprimento contratual alegando defeitos na plataforma. A perícia concluiu que o sistema estava pronto para uso e apresentava apenas não conformidades de fácil correção, estimadas em aproximadamente uma semana.
Decisão
O TJSP afastou a exceção do contrato não cumprido. Considerou que pequenas falhas podem ocorrer e devem ser corrigidas, desde que não impeçam a utilização da solução em produção.
Por que importa
O precedente estabelece um limiar importante para sistemas implementados: defeitos corrigíveis não equivalem a inadimplemento substancial. O foco deve estar no impacto funcional da falha.
7. Falhas pontuais ≠ imprestabilidade
Fatos
Duas empresas pediram rescisão e indenização por falhas reiteradas em software de gestão. Apontaram dezesseis episódios de gravidade variável, mas continuaram utilizando o sistema por período significativo.
Decisão
O TJSP reconheceu a existência de falhas, mas distinguiu bugs e indisponibilidades pontuais de um sistema imprestável ou inadequado. Sem prova técnica de que quantidade e intensidade dos problemas ultrapassavam o aceitável, não reconheceu inadimplemento. O uso continuado também pesou contra as clientes.
Por que importa
O acórdão formula uma regra clara para a fase operacional: não se exige perfeição do software, mas funcionalidade. Para converter bugs em inadimplemento, é preciso demonstrar impacto relevante na utilidade do sistema.