Contrato de software: o produto não cabe em uma cláusula genérica

“Contrato de software” pode reunir operações muito diferentes: desenvolvimento, licença, implantação, suporte, hospedagem, manutenção e tratamento de dados. Colocar tudo sob uma cláusula genérica de “fornecimento do sistema” esconde justamente os pontos em que surgem os conflitos. Primeiro decomponha o produto; depois escreva as obrigações.

Identifique o que é produto e o que é serviço

Software instalado, SaaS, customização e projeto sob encomenda distribuem riscos de formas diferentes. A Lei nº 9.609/1998 disciplina o programa de computador, enquanto o Código Civil e outras regras entram nas obrigações contratuais concretas.

Uma contratação pode conter licença sobre software padrão e, ao mesmo tempo, cessão ou licença específica sobre customizações. Deve também dizer quem possui ferramentas anteriores e componentes de terceiros.

Aceite precisa medir entrega real

Funcionalidade, desempenho, integração, segurança e documentação podem fazer parte do critério. Aceite por simples decurso de prazo é perigoso quando o cliente não recebeu ambiente, dados ou condições para testar. No extremo oposto, aceite sem prazo ou critério pode deixar entrega indefinidamente aberta.

Mudanças de escopo precisam de procedimento: solicitação, estimativa, aprovação, impacto e registro. Isso evita que conversas de chat se transformem, meses depois, em versões incompatíveis do que “estava incluído”.

Responsabilidade deve acompanhar as camadas do serviço

Falha de código, erro de configuração do cliente, indisponibilidade de nuvem e defeito de integração não são o mesmo evento. O contrato deve separar dependências e definir quem controla cada uma. Limitação de responsabilidade genérica que ignora essa arquitetura pode proteger pouco justamente quando surge um incidente grave.

Garantias também precisam ser específicas: correção de defeito, conformidade com documentação, segurança e propriedade intelectual podem ter mecanismos e prazos diferentes.

Subcontratação merece o mesmo cuidado. Se parte do código, suporte ou infraestrutura é entregue por terceiro, o contrato principal deve refletir dependência e garantir que confidencialidade, segurança e direitos necessários cheguem a quem executa. O cliente não precisa administrar a equipe do fornecedor, mas precisa conhecer riscos materiais de cadeia.

Se houver níveis diferentes de suporte, deixe claro o que é correção, manutenção evolutiva e atendimento consultivo. Misturar tudo em “suporte incluso” cria expectativa sem critério de entrega.

Dados e continuidade precisam entrar antes do término

Se o software trata dados pessoais, a LGPD deve aparecer na arquitetura conforme os papéis reais. Backup, exportação, eliminação, incidente e subcontratados precisam conversar com o serviço técnico.

Também defina repositório, documentação, suporte e transição quando relevantes. Compare desenvolvimento sob encomenda, licença de software e contrato SaaS para não forçar a mesma minuta em modelos diferentes.

Um contrato consistente permite responder, para cada evento relevante, qual obrigação existe, quem executa, como se mede e qual evidência fica registrada.