Contratos de tecnologia e SaaS deixaram de ser documentos acessórios assinados depois que a área técnica já escolheu a ferramenta. Em muitas empresas, o software contratado sustenta faturamento, CRM, ERP, folha de pagamento, atendimento, logística, contabilidade, e-commerce, gestão de documentos, assinatura eletrônica, dados de clientes, automação fiscal e inteligência de negócio. Se o sistema para, a empresa não sofre apenas um incômodo tecnológico. Pode sofrer uma interrupção operacional.
O problema é que muitos contratos de SaaS ainda são tratados como simples aceite de termos de uso. A empresa contrata rápido, paga mensalidade, integra dados, treina equipe e só lê o contrato quando há indisponibilidade, perda de dados, reajuste abusivo, rescisão difícil, bloqueio de acesso ou negativa de exportação da base. Nesse momento, a pergunta deixa de ser “qual é a ferramenta?” e passa a ser “quem ficou com o risco?”.
Contratos de tecnologia exigem leitura jurídica, técnica e operacional. Não basta discutir preço. É preciso discutir SLA, suporte, segurança, proteção de dados, propriedade intelectual, continuidade, auditoria, subcontratados, local de armazenamento, rescisão, migração, limitação de responsabilidade e dependência tecnológica.
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.
Contratos de tecnologia e SaaS
Quando o software sustenta a operação, o contrato precisa proteger dados, continuidade, saída e responsabilidade.
O Assis Lira Advocacia assessora empresas na revisão e negociação de contratos de tecnologia, SaaS, proteção de dados, SLA, segurança da informação, rescisão e responsabilidade de fornecedores.
Conclusão
Contratos de tecnologia e SaaS precisam ser lidos como contratos de infraestrutura empresarial. Quando envolvem dados, operação crítica, clientes e continuidade, exigem cláusulas claras sobre SLA, segurança, responsabilidade, rescisão, portabilidade e governança.
A ferramenta pode ser digital. O risco, quando mal contratado, é bastante concreto.
Fontes consultadas
- Brasil. Lei nº 13.709/2018, Lei Geral de Proteção de Dados Pessoais. Fonte: Planalto. Acessar fonte.
- Brasil. Lei nº 12.965/2014, Marco Civil da Internet. Fonte: Planalto. Acessar fonte.
- Brasil. Código Civil, Lei nº 10.406/2002, regras gerais de contratos, boa-fé e responsabilidade civil. Fonte: Planalto. Acessar fonte.
- Superior Tribunal de Justiça. Validade de cláusula limitativa de responsabilidade em contrato empresarial. Fonte: STJ. Acessar fonte.