O sistema de gestão caiu numa quinta-feira às onze da manhã. Faturamento parado, equipe sem acesso ao estoque, cliente esperando na linha. O contrato prometia disponibilidade de 99,5%, e o fornecedor respondeu, com razão técnica, que oito horas fora do ar naquele mês ainda cabiam dentro do índice.
Ninguém mentiu. O contrato é que nunca disse o que aconteceria quando o número fosse cumprido e a empresa ficasse parada mesmo assim.
Contrato de tecnologia raramente falha na descrição do serviço. Falha em três perguntas que quase nunca são feitas: o que acontece quando o sistema cai, de quem são os dados, e como se sai daqui.
Vai assinar um contrato de software? Confira estes pontos
São os que mais custam depois, e todos se resolvem antes da assinatura.
- SLA com consequência, e não apenas percentual declarado. Qual o desconto, a partir de quando, e em que ponto a empresa pode rescindir sem multa.
- Janela de manutenção: quanto tempo programado fica fora do cálculo de disponibilidade, e com qual aviso prévio.
- Propriedade dos dados declarada de forma expressa, incluindo os dados derivados e os relatórios gerados.
- Devolução ao término: em qual formato, em quanto tempo, e por quanto tempo o fornecedor ainda guarda cópia.
- Segurança e incidentes: prazo para comunicar violação, obrigações de apoio e quem responde perante a autoridade.
- Subcontratação e local de armazenamento, porque a nuvem contratada costuma repousar sobre terceiros.
- Reajuste e renovação automática, com prazo de aviso para não renovar.
- Limitação de responsabilidade: qual o teto e o que fica fora dele.
Para revisar um contrato antes de assinar:
Telefone: (11) 2386-2386
SLA: promessa técnica com efeito jurídico
O SLA, ou acordo de nível de serviço, define parâmetros de disponibilidade, desempenho, tempo de resposta, tempo de solução, suporte, manutenção, janelas programadas, severidade de incidentes e compensações. Em contratos empresariais, SLA não deve ser visto como detalhe técnico. Ele é a medida contratual da confiabilidade prometida.
Um SLA genérico, sem métrica, sem consequência e sem procedimento de apuração, tem baixa utilidade. A empresa deve saber o que significa disponibilidade de 99,5%, como será medida, quais eventos são excluídos, como incidentes serão comunicados, qual é o prazo de resposta para falhas críticas, quais créditos ou multas serão aplicáveis e se há direito de rescisão por indisponibilidade recorrente.
Também é necessário avaliar proporcionalidade. Para um sistema secundário, um SLA simples pode bastar. Para ERP, faturamento, operação logística, saúde, financeiro ou atendimento crítico, a tolerância à falha deve ser muito menor. O contrato precisa refletir a importância do sistema na operação.
Dados: a empresa precisa saber onde sua informação vive
Contratos SaaS quase sempre envolvem dados. Dados de clientes, empregados, fornecedores, usuários, contratos, documentos fiscais, relatórios, logs, tickets, histórico comercial e informações estratégicas podem ser armazenados em ambiente de terceiro. A LGPD exige medidas de segurança e disciplina o tratamento de dados pessoais. O Marco Civil da Internet também trata de registros, privacidade e guarda de dados em determinados contextos.
Empresas devem perguntar: quais dados serão tratados? Onde serão armazenados? Haverá transferência internacional? O fornecedor usará suboperadores? Os dados serão usados para treinamento de IA? Como será feito backup? Qual é o prazo de retenção? Como ocorre exclusão? Como a empresa exporta sua base em caso de rescisão?
A ausência dessas respostas cria risco de dependência e perda de controle. Dado empresarial não é poeira digital; é ativo, prova, memória e, em muitos casos, vantagem competitiva.
Controlador, operador e responsabilidade por incidentes
Em contratos de tecnologia, é comum que o fornecedor atue como operador de dados pessoais, tratando dados em nome do cliente. Mas essa classificação deve corresponder à realidade. Se o fornecedor define finalidades próprias, usa dados para analytics, treinamento, publicidade, melhoria de modelo ou compartilhamento independente, pode haver papel de controlador em determinadas atividades.
O contrato deve prever obrigações de segurança, confidencialidade, comunicação de incidentes, cooperação com o cliente, atendimento a titulares, subcontratação, transferência internacional, descarte e auditoria. Também deve definir prazos de comunicação em caso de incidente. Avisar “assim que possível” pode ser pouco quando o cliente precisa avaliar risco, comunicar autoridade e preservar evidências.
Lock-in tecnológico: quando sair custa mais caro que entrar
O lock-in ocorre quando a empresa se torna excessivamente dependente de um fornecedor, a ponto de migrar ser caro, lento ou operacionalmente arriscado. Isso pode decorrer de formato proprietário de dados, ausência de API, falta de exportação adequada, integrações complexas, customizações sem documentação, treinamento específico ou cláusulas de rescisão mal desenhadas.
O contrato deve prever portabilidade, exportação em formato utilizável, assistência de transição, prazo de acesso após rescisão, documentação técnica, eliminação de dados e cooperação para migração. Sem isso, a empresa pode ficar presa a uma ferramenta ruim porque sair virou projeto de alto risco.
Em tecnologia, contrato bom não serve apenas para entrar. Serve para sair sem desmontar a empresa.
Limitação de responsabilidade: necessária, mas não cega
Fornecedores de tecnologia costumam limitar responsabilidade ao valor pago nos últimos meses ou ao valor anual do contrato. Cláusulas de limitação podem ser válidas em contratos empresariais, e o STJ já reconheceu validade de cláusula limitativa de responsabilidade em contrato entre multinacional e representante brasileira. Mas a análise depende do contexto, da clareza, da proporcionalidade e da natureza do dano.
Empresas devem avaliar se certos danos devem ficar fora do limite, como violação de confidencialidade, vazamento de dados, dolo, fraude, infração de propriedade intelectual, indisponibilidade crítica, descumprimento de obrigações de segurança e uso indevido de informações. Limitar tudo de forma automática pode deixar o cliente sem proteção real.
Rescisão, continuidade e plano de saída
Contratos SaaS devem prever hipóteses de rescisão, aviso prévio, transição, exportação de dados, suporte pós-rescisão, manutenção de confidencialidade, exclusão ou devolução de informações, pagamento proporcional, multas e continuidade mínima para migração. A empresa deve evitar que o fornecedor possa bloquear acesso de forma abrupta em situação discutível.
Também é recomendável prever plano de continuidade para sistemas críticos: backup, redundância, contingência, suporte emergencial, comunicação de indisponibilidade e responsabilidades. Tecnologia contratada sem plano de saída é entusiasmo com data de validade.
Dependência: o custo que só aparece na saída
A pergunta que define o poder de barganha de uma renovação é simples e quase nunca é feita na assinatura: quanto tempo e quanto dinheiro custaria sair daqui?
Três elementos determinam a resposta. O formato de exportação dos dados, porque receber um arquivo que ninguém consegue importar equivale a não receber. A documentação de integrações, porque sistema conectado a outros cria amarras que não aparecem no contrato principal. E o período de transição assistida, que precisa estar escrito, com prazo e escopo, e não depender de boa vontade no momento do rompimento.
Fornecedor que resiste a escrever a saída costuma estar dizendo algo sobre como pretende conduzir a renovação.
LGPD: quem é controlador e quem é operador
Em contrato de software, a empresa contratante costuma ser a controladora dos dados pessoais, e o fornecedor, o operador, nos termos do art. 5º, VI e VII, da Lei 13.709/2018. Essa definição não é decorativa: ela distribui obrigações e responsabilidade perante o titular e perante a autoridade.
O art. 42 estabelece que o operador responde solidariamente quando descumprir a legislação ou não seguir as instruções lícitas do controlador. Na prática, cláusula que tenta jogar toda a responsabilidade para um dos lados não afasta a responsabilidade perante o titular, embora organize o regresso entre as partes.
O que precisa estar no contrato: finalidade e limites do tratamento, proibição de uso dos dados para finalidade própria do fornecedor, incluindo treinamento de modelos, obrigação de comunicar incidente em prazo definido, regras de subcontratação e o destino dos dados ao término.
Continuidade: o plano para o dia em que o fornecedor sair do ar
Nem todo risco é de indisponibilidade temporária. Há o risco de o fornecedor encerrar atividade, ser adquirido ou descontinuar o produto.
As defesas contratuais usuais são três: aviso prévio longo para descontinuação, direito de exportar os dados a qualquer tempo e sem custo adicional, e, para sistemas críticos, depósito do código em custódia com hipóteses claras de liberação. A terceira raramente se justifica em contrato pequeno, mas quando o sistema sustenta o faturamento, o cálculo muda.
Leia também
- LGPD para empresas B2B: contratos com fornecedores e resposta a incidentes.
- Inteligência artificial nas empresas: riscos em contratos, dados e decisões automatizadas.
- Cláusulas que reduzem risco: limitação de responsabilidade e rescisão.
- Direito digital e LGPD: como o escritório atua nessa frente.
Vai contratar ou renovar um sistema crítico?
Este texto cobre as cláusulas que mais custam. O que ele não substitui é a leitura do seu contrato, porque criticidade, volume de dados e integrações mudam onde está a exposição.
A Assis Lira Advocacia atua em contratos de tecnologia e SaaS, negociação de SLA, adequação à LGPD e disputas com fornecedores de software. A primeira conversa é com um sócio.
Conteúdo informativo e autoral, sem promessa de resultado e sem oferta a caso concreto, nos termos do Provimento CFOAB 205/2021. Não constitui parecer jurídico nem cria relação advogado-cliente.
Fontes
Lei 13.709/2018 (LGPD), arts. 5º, VI e VII (controlador e operador), 6º (princípios, entre eles finalidade e necessidade), 37 (registro das operações de tratamento), 42 (responsabilidade e solidariedade entre controlador e operador) e 48 (comunicação de incidente de segurança). Código Civil, arts. 421 e 422 (função social do contrato e boa-fé objetiva), 473 (denúncia unilateral e prazo compatível com os investimentos) e 475 (resolução por inadimplemento). Lei 9.609/1998 (proteção da propriedade intelectual de programa de computador).
