Contratos de SaaS têm uma característica que engana. Eles costumam chegar prontos, em um formato que parece definitivo, com cláusulas redigidas de maneira técnica e impessoal. A leitura inicial passa a sensação de que tudo ali é praxe de mercado e não há muito o que discutir. Quem assina nesse pressuposto descobre, meses depois, que justamente as cláusulas mais silenciosas (o nível de disponibilidade prometido, quem é dono da base de dados, o que acontece quando o contrato termina) são as que organizam o risco real da relação.
Esse desconforto aparece dos dois lados do balcão. A empresa de tecnologia que fornece o software quer previsibilidade de receita e quer limitar sua exposição a falhas inerentes a qualquer sistema. A empresa que contrata quer continuidade operacional, porque passou a depender daquela ferramenta para faturar, atender clientes ou rodar a folha. Os dois interesses são legítimos e nem sempre conflitantes, mas raramente estão bem traduzidos no texto que vai à assinatura. Na atuação com revisão e negociação de contratos de SaaS, o trabalho costuma ser menos sobre redigir cláusulas novas e mais sobre tornar explícito o que o contrato deixou em aberto.
SLA e disponibilidade: o número e o que ele significa
O Service Level Agreement (SLA) é o coração operacional do contrato. Ele promete um percentual de disponibilidade do sistema, por exemplo 99,5% ou 99,9% ao mês. O ponto que merece leitura cuidadosa não é o número em si, e sim o que ele exclui e o que acontece quando não é cumprido.
- Base de cálculo: a disponibilidade é medida mensal ou anual? Janelas de manutenção programada entram ou saem da conta? Um SLA generoso no papel pode encolher bastante depois das exclusões.
- Consequência do descumprimento: falhar no SLA gera crédito em serviço, abatimento, ou apenas um pedido de desculpas? E esse remédio é a única consequência possível, ou o cliente pode escalar?
- Suporte e tempo de resposta: disponibilidade e suporte são coisas diferentes. Vale separar o tempo de resposta do tempo de solução, e definir o que é incidente crítico.
Para quem fornece, o SLA é um instrumento de gestão de expectativa. Prometer demais cria passivo. Para quem contrata, o SLA só protege se vier acompanhado de medição clara e de uma consequência que faça diferença na prática.
Propriedade dos dados e propriedade do software
Aqui mora uma confusão comum. O fornecedor é dono do software, da plataforma e do código. Isso é da natureza do modelo e não se discute. O que precisa ficar claro, em cláusula separada, é que os dados inseridos pelo cliente continuam sendo do cliente. São coisas distintas e o contrato deve dizer isso com todas as letras.
Há ainda uma zona cinzenta que costuma passar despercebida: os dados agregados ou anonimizados. Muitos contratos preveem que o fornecedor pode usar informações de uso para melhorar o produto. Pode ser razoável, mas o cliente deve saber até onde vai essa licença, e o fornecedor deve garantir que ela sustente o uso pretendido. Um detalhe muda a leitura: quando o fornecedor usa esses dados em proveito próprio, para aprimorar o produto, ele deixa de agir só em nome do cliente e pode assumir, naquele uso, o papel de controlador (quem decide a finalidade do tratamento), e não de mero operador. Reconhecer isso no texto protege os dois lados.
Está passando por isso agora? Vale conversar sobre o seu caso.
Agende uma conversa →Tratamento de dados pessoais e LGPD
Quase todo SaaS processa dados pessoais, ainda que o produto não pareça ter relação com isso. Cadastros de clientes, dados de funcionários, históricos de contato. Isso aciona a Lei Geral de Proteção de Dados (LGPD) e exige definir os papéis das partes.
Em regra, o cliente atua como controlador (define a finalidade do tratamento) e o fornecedor como operador (trata os dados em nome do cliente). Essa qualificação não é decorativa, ela distribui obrigações e responsabilidades, e, como visto, pode mudar quando o fornecedor reaproveita dados para o próprio produto. Um bom contrato de SaaS traz, ou anexa, cláusulas sobre:
- finalidade e limites do tratamento pelo fornecedor;
- medidas de segurança e comunicação de incidentes;
- uso de subcontratados (suboperadores) e a cadeia de responsabilidade;
- devolução ou eliminação dos dados ao término do contrato.
Vale ainda uma distinção que define o que segue sob a LGPD e o que saiu do seu alcance. Dado verdadeiramente anonimizado, aquele que não permite, por meios razoáveis, reidentificar a pessoa, deixa de ser dado pessoal e fica fora da lei (art. 12). Já o dado apenas agregado ou pseudonimizado, que ainda guarda chance de reidentificação, continua protegido. Tratar os dois como sinônimos no contrato cobra caro depois, então vale definir qual deles a cláusula autoriza.
O contrato de SaaS bem feito não é o que promete que nada vai dar errado. É o que define, com antecedência e por escrito, o que acontece quando algo sai do esperado: a queda de sistema, o vazamento, o fim da relação.
Limitação de responsabilidade: o teto e o que ele cobre
É praticamente universal que o fornecedor limite sua responsabilidade, em geral a um teto vinculado aos valores pagos em determinado período. Faz sentido do ponto de vista de quem fornece, porque ninguém vende software assumindo risco ilimitado. O que merece atenção é o desenho dessa limitação.
Vale verificar se a limitação convive com exceções (por exemplo, violação de dever de sigilo, infração à LGPD ou dolo), e se o teto é compatível com a criticidade do serviço para o cliente. Um sistema que sustenta a operação inteira de uma empresa pede um equilíbrio diferente de uma ferramenta acessória. Negociar esse ponto é menos sobre derrubar o teto e mais sobre calibrá-lo e definir o que fica de fora dele.
Reajuste, renovação automática e saída
São cláusulas econômicas e de continuidade, e costumam estar no fim do contrato, onde a atenção já caiu. Três pontos concentram a maior parte das surpresas:
Reajuste
Por qual índice e com qual periodicidade os valores se ajustam? Há limite? O reajuste se aplica automaticamente ou depende de notificação prévia? Para o fornecedor, previsibilidade de receita. Para o cliente, previsibilidade de custo.
Renovação automática
Muitos contratos se renovam sozinhos por novos períodos se nenhuma parte se manifestar dentro de um prazo. O detalhe é a antecedência exigida para não renovar. Perder essa janela prende o cliente por mais um ciclo inteiro.
Reversibilidade dos dados
O ponto mais negligenciado e um dos mais sensíveis. Ao término do contrato, em que formato e em quanto tempo o cliente recebe seus dados de volta? Por quanto tempo o fornecedor mantém backup antes de eliminar? Sem isso, encerrar a relação vira um problema técnico e jurídico ao mesmo tempo.
Os dois lados da mesma cláusula
O que torna o contrato de SaaS particular é que ele não tem um "lado fraco" óbvio. Cada cláusula protege um interesse legítimo das duas partes, e o objetivo de uma boa revisão é deixar o equilíbrio visível e consciente, não vencer o outro lado. Quem fornece ganha em ter cláusulas que sustentem o modelo de negócio. Quem contrata ganha em entender o que assinou e em garantir continuidade. Em muitos casos, o mesmo conjunto de pontos serve de roteiro para os dois, mudando apenas o ângulo da leitura.
Esse roteiro, vale dizer, conversa com outros instrumentos que orbitam a venda de tecnologia, como os NDAs e os contratos de prestação de serviço, que costumam acompanhar a operação e merecem a mesma leitura atenta.
Se a sua empresa fornece ou contrata software como serviço e está diante de um contrato que parece padrão mas pesa, vale ler cada um desses pontos com calma antes de assinar. E, quando o texto deixar dúvidas, conversar sobre eles com quem trabalha com a revisão e a negociação desse tipo de contrato.