Seguro para empresa de software: o seu risco está no contrato, não no código

Empresas de tecnologia costumam pensar em risco na linguagem que dominam: uptime, backup, autenticação, cobertura de testes, plano de recuperação. É uma leitura correta e insuficiente. Porque, quando o prejuízo aparece, quem determina o tamanho dele quase nunca é a arquitetura do sistema — é um contrato que o time comercial assinou meses antes, num PDF de quarenta páginas que ninguém do time técnico leu.

A cena é sempre parecida. Chega o contrato do primeiro cliente enterprise, redigido pelo jurídico dele. Vem com cláusulas que soam padrão. A pressão é para fechar: o negócio é grande, o trimestre precisa dele, e discutir minúcia jurídica parece risco de perder a venda. Assina-se. Dois anos depois, uma atualização introduz um erro que corrompe dados do cliente, e alguém vai ler o contrato pela primeira vez — para descobrir a que a empresa se obrigou.

Este guia é a leitura que deveria acontecer antes. Ele percorre as seis cláusulas que decidem quem paga pelo bug, explica onde cada uma encontra — ou não — uma apólice, e fecha com o que muda conforme o tipo de empresa de tecnologia. Se você procura o mapa completo das coberturas do setor, ele está na página de seguros para empresas de tecnologia; aqui o caminho é o oposto, e mais útil na prática: partir do contrato para chegar ao seguro.

Por que, em tecnologia, o risco é contratual antes de ser técnico

Em quase todo setor, a responsabilidade civil nasce da lei: você causou dano a alguém, você repara. Em tecnologia B2B, existe uma camada anterior e mais pesada — a responsabilidade que você aceitou por contrato, que costuma ser bem maior do que a que a lei imporia sozinha.

Três características do setor explicam isso.

O dano é replicável. Uma falha em software não afeta um cliente: afeta todos que rodam aquela versão, ao mesmo tempo. Não existe equivalente de “um lote com defeito” — existe “todos os lotes, simultaneamente”.

O dano é financeiro puro. Não há incêndio, colisão ou lesão. O prejuízo do cliente é perda econômica — receita não faturada, operação parada, multa regulatória, retrabalho. E prejuízo puramente financeiro, sem dano físico, é exatamente o que as apólices empresariais tradicionais não cobrem. A RC Geral de uma empresa comum foi desenhada para o dano material e corporal; ela não responde pelo bug.

O cliente é maior que você. A assimetria é a regra: uma software house de trinta pessoas assina com um banco, uma operadora, uma indústria. O contrato é redigido pelo lado forte, e distribui risco de acordo. É perfeitamente comum uma empresa assumir, numa cláusula, uma exposição que supera vários anos do seu faturamento.

Some as três e chega-se ao ponto central: o seu maior risco não está no que você programa; está no que você assina.

As seis cláusulas que decidem quem paga

1. Limitação de responsabilidade — e o que o teto não cobre

É a cláusula que todo fundador cita como tranquilizante: “minha responsabilidade está limitada ao valor do contrato”. Quase sempre a leitura para por aí, e é aí que mora o problema.

O teto (cap) quase nunca é absoluto. Ele vem seguido de uma lista de exceções — hipóteses em que a limitação não se aplica e a responsabilidade volta a ser ilimitada. E a lista costuma incluir, com pequenas variações:

• violação de confidencialidade;
• incidentes com dados pessoais;
• violação de propriedade intelectual de terceiros;
• dolo ou culpa grave;
• obrigações de indenidade (a cláusula seguinte).

Repare no que sobrou dentro do teto: atraso de entrega, defeito comum, indisponibilidade rotineira — os eventos baratos. E o que ficou fora: vazamento de dados, quebra de sigilo, violação de PI — exatamente os eventos capazes de quebrar a empresa.

A conclusão prática inverte o instinto: ler o valor do cap é a parte menos importante da cláusula. O que importa é ler o que ele exclui. Um teto de doze meses de contrato com cinco exceções amplas oferece muito menos proteção do que um teto menor sem exceções.

2. Indenidade (indemnity) — a obrigação que não respeita teto

A cláusula de indenidade é o compromisso de ressarcir o cliente por perdas decorrentes de determinados eventos, normalmente violação de PI de terceiros, incidentes com dados e descumprimento legal. Ela merece atenção especial por três motivos.

Primeiro, ela costuma ser excluída do teto — é a exceção mais comum da cláusula anterior. Segundo, ela frequentemente inclui o dever de defender: você não apenas paga no fim, você assume a defesa do cliente desde a reclamação, com advogado, perícia e custas correndo antes de qualquer decisão. Terceiro, ela pode alcançar terceiros que você nunca contratou — o cliente do seu cliente, o usuário final.

É a cláusula que transforma um problema técnico contido numa obrigação financeira aberta. Quando alguém pergunta “como é que um bug pode custar mais que o contrato inteiro?”, a resposta costuma estar aqui.

3. SLA e penalidades — a distinção que muda tudo

Contratos de tecnologia definem níveis de serviço e penalidades pelo descumprimento: crédito de serviço, desconto na mensalidade, multa. É uma engrenagem conhecida, e há um ponto sobre ela que precisa ficar claro antes de qualquer conversa sobre seguro.

Penalidade contratual, em regra, não é coberta por seguro. Multa e crédito de SLA são obrigações que a empresa assumiu voluntariamente, com valor pactuado, independentemente de prejuízo comprovado — e apólices de responsabilidade civil costumam excluir penalidades contratuais puras. Elas cobrem o dano, não a multa.

A distinção prática: se o sistema fica fora do ar oito horas e o contrato prevê um crédito de 10% da mensalidade, esse crédito é custo do negócio, não sinistro. Mas se a indisponibilidade fez o cliente perder um dia de faturamento e ele cobra esse prejuízo, aí existe dano — e é aí que o E&O de tecnologia atua.

Por isso, na negociação, SLA agressivo tem custo que não se resolve com apólice. É risco retido, e precisa entrar na conta do preço do contrato.

4. Dados pessoais — “sou só operador” é um conforto falso

Muita empresa de software se tranquiliza com a divisão da LGPD: o cliente é o controlador, decide as finalidades; eu sou o operador, só processo por conta dele. Logo, a responsabilidade seria dele.

A lei não é tão generosa. Pelo art. 42 da LGPD, quem causa dano a outrem no exercício de tratamento de dados, em violação à legislação, é obrigado a repará-lo. E o §1º trata justamente do operador: ele responde solidariamente pelos danos quando descumprir as obrigações da legislação de proteção de dados ou quando não seguir as instruções lícitas do controlador — hipótese em que se equipara ao controlador.

Traduzindo para a operação: se o vazamento aconteceu porque o seu ambiente estava mal configurado, ou porque você tratou os dados além do que foi instruído, a condição de operador não é escudo. O titular pode acionar quem preferir, e a discussão entre você e o cliente sobre quem errou vem depois — normalmente com a cláusula de indenidade já mandando você pagar primeiro.

Some-se a isso o acordo de tratamento de dados (DPA) anexo à maioria dos contratos enterprise, que costuma impor obrigações de segurança, prazos curtos de notificação de incidente, direitos de auditoria e responsabilidade por subcontratados — inclusive pelo seu provedor de nuvem. Essa é a frente do seguro cyber, e a razão pela qual ele não é opcional para quem hospeda dado de cliente.

5. Propriedade intelectual — o risco que a IA tornou mais difícil de mapear

A cláusula de PI garante ao cliente que o que você entrega não viola direito de terceiro, e que você o indenizará se violar. Historicamente, a exposição vinha de biblioteca de terceiro com licença incompatível, componente copiado ou uso indevido de código sob licença restritiva.

O quadro ficou mais complexo com a geração assistida de código. Quando parte da base é produzida por assistentes, rastrear a origem e o regime de licença de cada trecho é objetivamente mais difícil — e a sua obrigação perante o cliente não muda por isso. A garantia de titularidade continua valendo integralmente, independentemente de como o código foi escrito.

Não é argumento contra usar as ferramentas; é argumento a favor de saber o que se assinou. Contratos enterprise já começam a endereçar o tema expressamente, e vale tratá-lo com transparência também na descrição do risco à seguradora — informação incompleta é a via mais comum de negativa de sinistro. A lógica geral de como novas tecnologias remodelam a responsabilidade profissional está em telemedicina, IA e dados.

6. A cláusula de seguros — o que o seu cliente realmente está pedindo

Fecha a lista a cláusula que dá origem à maioria das consultas que recebemos: o contrato exige seguro. Ela costuma pedir mais coisas do que se percebe numa leitura rápida:

• as coberturas exigidas, normalmente E&O e cyber, às vezes RC Geral e D&O;
• o limite mínimo de indenização, que pode ser muito superior ao valor do contrato;
• a data de retroatividade, exigindo que a apólice alcance fatos anteriores;
• a manutenção da apólice por período após o término do contrato — a cauda, que trataremos adiante;
• a comprovação por certificado, e não por declaração;
• o aviso prévio em caso de cancelamento, não renovação ou redução de limite;
• por vezes, a inclusão do cliente como segurado adicional.

Cada item tem preço. E aqui está a assimetria que custa dinheiro: essas exigências são negociáveis antes da assinatura e praticamente inegociáveis depois. Uma empresa que discute o limite mínimo durante a negociação comercial consegue ajustá-lo ao risco real; a que assina e depois vai ao mercado descobre que precisa contratar o que prometeu, ao preço que houver, com o contrato parado esperando o certificado.

Onde cada cláusula encontra uma apólice

Juntando as seis, o mapa da cobertura fica assim:

A cláusula	O evento típico	Onde encontra cobertura
Limitação de responsabilidade	Define o teto — e as exceções que o furam	Não é cobertura: é o dimensionamento do limite da apólice
Indenidade	Reclamação de terceiro por PI ou dados	E&O e cyber, conforme a origem
SLA e penalidades	Indisponibilidade	Multa, em regra não; dano comprovado ao cliente, E&O
Dados pessoais / DPA	Vazamento, incidente, notificação à ANPD	Seguro cyber
Propriedade intelectual	Violação de direito de terceiro	E&O com cobertura de PI, conforme o clausulado
Exigência de seguro	Certificado, limite, retroatividade	A própria estruturação da apólice

Duas leituras importam mais que as linhas isoladas.

A primeira: cyber e E&O não são o mesmo produto e não se substituem. O cyber responde ao ataque e ao incidente de dados; o E&O responde à falha do que você entrega, mesmo sem ataque nenhum. O sinistro clássico que pega empresas desprevenidas é o do meio: um erro de configuração seu que expõe dados. É falha de entrega ou incidente de segurança? Sem as duas apólices bem articuladas, é a hipótese em que cada seguradora aponta para a outra.

A segunda: retroatividade e cauda decidem se a apólice serve. Essas coberturas costumam operar à base de reclamações — respondem pelo que é reclamado durante a vigência, desde que o fato tenha ocorrido após a data de retroatividade. Em software isso é particularmente severo, porque o bug é escrito muito antes de causar dano. Um erro introduzido há dois anos pode gerar reclamação amanhã. Sem retroatividade que alcance o código em produção, a apólice vigente cobre pouco do que de fato expõe a empresa. E a cauda importa pelo motivo espelhado: contratos exigem manutenção de cobertura após o término, porque a reclamação pode chegar depois do fim da relação. O mecanismo está detalhado em retroatividade no seguro de RC, e a continuidade entre vigências é parte da proteção — trocar de seguradora sem preservar a data é uma das formas mais silenciosas de abrir um buraco no passado.

O que muda conforme o tipo de empresa

O peso relativo das cláusulas muda bastante dentro do próprio setor.

Software house e desenvolvimento sob demanda. O risco se concentra em escopo, prazo e aderência à especificação. A cláusula que mais pesa é a limitação de responsabilidade, e o E&O é o eixo do programa. A exposição de dados costuma ser menor, salvo quando a equipe acessa ambiente de produção do cliente — hipótese que muda o quadro por completo e é frequentemente esquecida na avaliação.

SaaS multi-tenant. O eixo se inverte. Um único incidente atinge toda a base ao mesmo tempo, o SLA vira o centro da relação e a guarda de dados de muitos clientes concentra risco. Cyber e E&O caminham juntos, e o limite precisa considerar o efeito agregado — não o prejuízo de um cliente, mas o de todos simultaneamente.

Aplicativos móveis e desktop. Somam-se a distribuição por lojas, o tratamento de dados no dispositivo e as permissões concedidas pelo usuário. A base de usuários finais amplia a exposição a reclamações de titulares, e não apenas do cliente contratante.

Infraestrutura, hospedagem e processamento de dados. Aqui a disponibilidade é o produto. A exposição de indisponibilidade é máxima, a responsabilidade por subcontratados (incluindo o provedor de nuvem) costuma ser expressa em contrato, e o DPA tende a ser mais exigente. Cyber é o núcleo, com atenção especial ao efeito cascata: o seu incidente é o incidente de todos os seus clientes.

Hardware e IoT. Entra uma camada que as demais não têm — a responsabilidade pelo produto físico, com risco de dano material e até corporal, além da proteção do laboratório e dos equipamentos de informática. É o subsegmento em que a RC de produtos volta a fazer sentido ao lado do E&O.

Consultoria de tecnologia. O produto é a recomendação. A exposição não está no código entregue, e sim na orientação que levou o cliente a uma decisão custosa — arquitetura, escolha de plataforma, migração. O E&O é praticamente a apólice inteira.

Para startups com investidores, há ainda um interlocutor a mais: o fundo. Term sheets e acordos de acionistas frequentemente exigem D&O para proteger fundadores e conselheiros por atos de gestão. É uma exigência de governança, não de operação — e chega em momento diferente das demais.

Erros que se repetem

1. Dimensionar o limite pelo faturamento. O limite precisa acompanhar o maior contrato, não a receita média. Uma empresa pequena com um contrato enterprise tem exposição que não guarda relação com o seu tamanho.
2. Ler o valor do cap e não as exceções. As hipóteses excluídas do teto são justamente as caras.
3. Contratar só o cyber. Metade da exposição de uma empresa de software não envolve ataque nenhum.
4. Aceitar a cláusula de seguros sem cotar antes. Prometer limite e retroatividade que não se sabe quanto custam é assinar um cheque em aberto.
5. Deixar a retroatividade para trás numa troca de seguradora. O prêmio menor esconde a perda do passado — e em software o passado está todo rodando em produção.
6. Descrever o risco por baixo na cotação. Omitir acesso a ambiente de produção, volume de dados sensíveis ou uso de subcontratados é a via mais direta para uma negativa.
7. Tratar penalidade de SLA como sinistro. Não é. É custo do negócio, e precisa estar no preço do contrato.

Pontos-chave

• Em tecnologia, a responsabilidade contratual costuma ser maior que a legal — e é ela que dimensiona o risco.
• O teto de responsabilidade protege menos do que aparenta: o que importa são as exceções, que costumam incluir dados, confidencialidade e PI.
• A indenidade é a cláusula que escapa do teto e obriga a defender o cliente antes de qualquer decisão.
• Penalidade de SLA, em regra, não é segurável; o dano comprovado ao cliente é.
• Ser operador de dados não afasta a responsabilidade — o art. 42, §1º da LGPD prevê solidariedade quando o operador descumpre a lei ou desvia das instruções do controlador.
• Cyber e E&O são complementares, e o sinistro mais traiçoeiro é o que fica na fronteira entre os dois.
• Retroatividade é decisiva em software, porque o erro é escrito muito antes de causar dano.
• A cláusula de seguros é negociável antes de assinar e praticamente inegociável depois.

Fale com a GVM

Existe uma ordem natural que quase todo mundo inverte. O caminho comum é: assina-se o contrato, descobre-se a exigência de seguro, corre-se atrás da apólice com o negócio parado. O caminho que funciona é ler a minuta antes, entender o que as cláusulas de responsabilidade, indenidade e dados realmente impõem, dimensionar a cobertura a partir daí e chegar à assinatura com a documentação pronta.

É esse o trabalho que a GVM faz junto de empresas de tecnologia: ler o contrato do seu cliente com olho de risco, apontar onde a exposição excede o que a apólice atual alcança, dimensionar limite e retroatividade ao que os seus contratos de fato exigem e cotar com seguradoras que entendem SaaS, software house, infraestrutura e hardware — comparando exclusões e resposta a incidentes, não apenas preço.

Se você tem um contrato enterprise na mesa, uma rodada em andamento ou uma cláusula de seguros que não sabe se consegue cumprir, fale com a GVM. Envie a minuta e o desenho do seu negócio: a análise é sem compromisso. O detalhe das coberturas está na página do E&O de tecnologia e no seguro cyber — e o programa completo do setor, em seguros para empresas de tecnologia.