Contrato SaaS: disponibilidade sem método de cálculo é promessa vaga

Contrato SaaS precisa transformar uma prestação tecnológica contínua em obrigações que possam ser medidas. “Disponibilidade de 99,9%” parece precisa, mas continua vaga se o documento não disser qual período é medido, quais eventos são excluídos, qual fonte calcula indisponibilidade e o que acontece quando a meta não é cumprida.

Escopo deve refletir a arquitetura real do serviço

Funcionalidades essenciais, integrações críticas, regiões de hospedagem, suporte, segurança, subcontratados e tratamento de dados podem estar distribuídos entre proposta, ordem comercial, termos gerais e anexos. O contrato deve indicar hierarquia entre esses documentos e procedimento de mudança para evitar versões contraditórias.

A LGPD entra quando o serviço trata dados pessoais, e o Marco Civil da Internet pode ser relevante conforme a aplicação oferecida.

SLA precisa dizer como o número é produzido

Defina janela de medição, indisponibilidade total e parcial, manutenção programada, dependências externas, comunicação de incidente e canal de contestação. Créditos de serviço podem ser um remédio contratual, mas é preciso explicar sua relação com outras consequências e limitações de responsabilidade.

O mesmo vale para suporte. “Atendimento 24/7” pode significar apenas abertura de chamado. Severidade, tempo de resposta, atualização e restauração precisam ser diferenciados.

Segurança e incidente precisam ter responsáveis dos dois lados

Fornecedor e cliente controlam partes diferentes do risco. O primeiro costuma responder pela infraestrutura e pela aplicação; o segundo pode controlar usuários, permissões, dispositivos e configurações. O contrato deve evitar tanto jogar toda segurança para o fornecedor quanto atribuir genericamente qualquer incidente ao cliente.

Procedimento de incidente deve prever canal, informação mínima, atualização e cooperação. Se houver dados pessoais, as obrigações contratuais precisam conversar com a LGPD e com o papel concreto de cada agente.

Mudança de preço merece governança semelhante à mudança de produto. Métrica por usuário, consumo, armazenamento ou chamada de API pode alterar custo rapidamente. O contrato deve explicar como consumo é medido, quando excedente começa e com que antecedência mudanças materiais serão aplicadas.

Também vale definir o que acontece com funcionalidades beta ou experimentais, que podem ter disponibilidade e suporte diferentes do núcleo contratado.

Dados e saída pertencem ao desenho do contrato desde o início

Formato de exportação, prazo para retirada, suporte à migração, eliminação ou retenção residual e destino de backups não devem aparecer apenas na cláusula final. Se o cliente só consegue descobrir na rescisão que exporta PDFs em vez de dados estruturados, o lock-in já está consumado.

Compare a operação geral de software como serviço e a dependência de integrações por API. Depois simule três eventos — indisponibilidade, incidente de dados e término — e localize em todos os documentos quem age, em quanto tempo, com qual evidência e qual consequência.