Contratos de TI: as 12 cláusulas que todo CTO deveria revisar antes de assinar

Recebi outro dia o contrato de um cliente — uma empresa de logística em Curitiba — para análise antes da assinatura. R$ 2,8 milhões em 36 meses, sistema de gestão de frota com integração ERP.

O contrato tinha 47 páginas. Foi escrito pelo jurídico do fornecedor. Foi revisado pelo jurídico do cliente. Estava pronto para assinar.

Marquei 14 cláusulas em vermelho. Não eram cláusulas ilegais. Eram cláusulas que protegiam exclusivamente o fornecedor em todo cenário de problema previsível.

O diretor financeiro me ligou no dia seguinte: "mas isso é o padrão do mercado, todo fornecedor pede assim". Respondi: "é o padrão do mercado porque ninguém revisou direito até agora".

A maioria dos contratos de TI é escrita por advogados que não entendem profundamente de TI, e revisada por engenheiros que não entendem profundamente de contrato. O resultado é um documento que parece neutro mas, na hora do conflito, sempre favorece quem o redigiu.

Por que contratos de TI são diferentes de outros contratos

Contrato de fornecimento de produto físico é razoavelmente simples: você compra X unidades de Y, entrega em Z, pagamento em W.

Contrato de TI tem 4 camadas que outros contratos não têm:

1. Camada de serviço continuado

Você não compra software. Você assina direito de uso por período. Isso muda completamente as cláusulas de saída, suporte, evolução.

2. Camada de dados

Seus dados ficam, em parte, sob custódia do fornecedor. Isso introduz responsabilidades de LGPD, backup, integridade, portabilidade.

3. Camada de integração

O sistema raramente vive sozinho. Conecta com outros. Mudanças num lado afetam o outro. Quem responde por que?

4. Camada de evolução

Software que não evolui em 3 anos vira obsoleto. Mas evolução pode trazer custos não previstos, ruptura de funcionalidade, mudança de modelo de cobrança.

Quem trata contrato de TI como contrato de fornecimento padrão se prepara para problema. Os contratos que eu reviso sempre são analisados nessas 4 camadas, e em cada uma há 3-4 cláusulas críticas.

Cláusulas de uptime.com.br/" style="color:#1a365d;text-decoration:underline;font-weight:500;">SLA: o que parece bom mas não é

SLA é a cláusula mais comentada e a menos compreendida em contratos de TI.

"99,9% de uptime mensal" parece excelente. Vamos fazer a matemática.

0,1% de 30 dias = 43 minutos. Por mês. Se distribuído em incidentes menores, talvez nem notado. Se concentrado num único evento de 43 minutos durante o fechamento contábil, pode custar R$ 200 mil em produtividade perdida e R$ 80 mil em multa contratual de cliente final.

O SLA não diz nada sobre concentração.

Cláusula clássica que vejo: "o SLA é calculado mensalmente, excluindo janelas de manutenção planejada".

Janelas de manutenção planejada não entram no cálculo. Então o fornecedor pode fazer manutenção todo sábado das 22h às 6h. 8 horas por sábado x 4 sábados = 32 horas de indisponibilidade por mês que não conta no SLA. Mas conta no seu negócio se você opera 24/7 ou se seu fechamento bate sábado de manhã.

O que negociar:

• Limite de horas mensais de manutenção planejada (por exemplo: máx 4h/mês)
• Aviso prévio mínimo de manutenção (24h, 48h, 7 dias)
• Janela de manutenção definida em horário não-crítico para SEU negócio
• SLA de cada componente crítico, não só do sistema todo

SLA mal escrito é o presente de natal do fornecedor.

Propriedade intelectual: o código que você pagou mas não tem

Esse é o que mais surpreende cliente.

Você contrata desenvolvimento customizado. Paga R$ 800 mil. Acha que o código é seu. Não é.

A cláusula típica diz algo como: "a propriedade intelectual do código desenvolvido permanece com o fornecedor. O cliente recebe licença de uso perpétua e não-exclusiva".

"Licença de uso perpétua" parece bom. Não é a mesma coisa que propriedade. Você não pode:

• Modificar o código por outro fornecedor
• Sublicenciar para subsidiárias com personalidade jurídica diferente
• Usar o conhecimento em desenvolvimento posterior próprio
• Recuperar facilmente se o fornecedor falir

O que negociar:

Para customizações específicas pagas integralmente pelo cliente, exigir cessão de propriedade intelectual ao cliente, com licença de uso reversa para o fornecedor (se ele quiser reutilizar em outros clientes).

Para a plataforma base, aceitar licenciamento (não tem como ser diferente), mas exigir contrato de escrow de código fonte com terceiro independente. Se o fornecedor falir ou descontinuar o produto, você recebe o código fonte para continuidade.

Cláusulas de saída: o que acontece quando você quer trocar de fornecedor

Olha, eu trabalho há quase 20 anos com TI. Quase nunca vi contrato durar o ciclo planejado sem reavaliação séria. Mudança de fornecedor é normal. Mas o contrato típico te tranca.

Os pontos de tranca:

1. Devolução de dados

"O fornecedor disponibilizará os dados em formato padrão de mercado, mediante pagamento de taxa de extração".

Tradução: vamos cobrar para te devolver o que é seu, e em formato que dá trabalho integrar em outro sistema.

O que negociar: dados retornados em formato estruturado (preferencialmente o nativo do banco), sem custo adicional, em prazo máximo (15-30 dias), com schema documentado.

2. Período de transição

Quanto tempo o fornecedor antigo mantém o sistema operando enquanto o novo é configurado?

Sem cláusula clara, fornecedor pode te cortar imediatamente após denúncia do contrato. Já vi acontecer.

O que negociar: prazo mínimo de operação assistida pós-denúncia (90-180 dias), valores claros, escopo definido.

3. Suporte à migração

Documentação técnica, mapeamento de campos, sessões de conhecimento — quem fornece? Geralmente o fornecedor antigo, mas sem cláusula clara ele coopera o mínimo legal.

O que negociar antes de assinar (e o que o fornecedor não vai te oferecer)

Lista do que eu reviso em todo contrato. Se faltar, eu marco em vermelho e oriento o cliente a negociar.

• SLA com penalidade real (não "crédito de serviço futuro", mas devolução em dinheiro)
• Cláusula de auditoria — direito de auditar o fornecedor pelo menos 1x ao ano
• Limite de aumento de preço atrelado a índice transparente (IPCA, não "a critério do fornecedor")
• Notificação prévia de qualquer mudança de modelo de cobrança (mínimo 180 dias)
• Cláusula de mudança de controle societário — você pode rescindir se o fornecedor for vendido
• Direito de não-renovação automática (sem ônus)
• Limites de responsabilidade simétricos (se o fornecedor limita responsabilidade dele em X, você limita a sua em X também)

Nenhuma dessas é cláusula esquisita. Todas são padrão em contratos bem negociados. Mas todas, sem exceção, precisam ser explicitamente pedidas pelo cliente — porque o fornecedor não oferece de graça.

Contrato bem negociado custa 2-3 semanas a mais para assinar. Contrato mal negociado custa 6-18 meses de dor de cabeça quando o problema aparece. A matemática é clara.

Confidencialidade e propriedade de dados: as cláusulas que muitos esquecem

Cláusula clássica: "o fornecedor se compromete a manter confidencialidade sobre informações do cliente durante o prazo do contrato e por 2 anos após o término".

2 anos após o término. E depois?

Depois, em tese, o fornecedor pode usar informações estratégicas suas. Negocie sempre confidencialidade perpétua para informações estratégicas, sem prazo de extinção.

Outro ponto: dados que o fornecedor processa permanecem propriedade do cliente. Sempre. Sem exceção. Mas isso precisa estar explícito. Sem cláusula clara, fornecedor pode argumentar uso anonimizado para benchmark ou treinamento de modelos.

Subcontratação: o problema escondido

Cláusula que vejo passar despercebida: "o fornecedor poderá subcontratar parte dos serviços, mantendo-se responsável perante o contratante".

Tradução: o fornecedor pode terceirizar para quem quiser, sem te avisar, mantendo o nome dele no contrato.

O problema: você contratou empresa A baseado em reputação, certificações, capacidade técnica. Empresa A subcontrata empresa B (talvez no exterior) para o trabalho real. Os dados sensíveis passam por empresa B. Você não sabe quem é, não sabe que controles existem, não tem direito de auditar.

O que negociar:

• Direito de aprovar previamente qualquer subcontratação relevante
• Mesmas obrigações contratuais aplicáveis aos subcontratados
• Direito de auditar subcontratados
• Notificação prévia de troca de subcontratado

Direito de auditar o fornecedor: por que importa

Cláusula que poucos exigem mas todos deveriam: direito de auditar o fornecedor pelo menos 1x ao ano.

Para que serve?

Em setores regulados, você precisa demonstrar para auditores externos que seus controles funcionam — inclusive quando esses controles dependem de terceiros. Sem direito contratual de auditar, você fica refém do que o fornecedor decide compartilhar.

O que o direito de auditar deve cobrir:

• Controles de segurança aplicados (acesso, criptografia, monitoramento)
• Processo de gestão de incidentes
• Aderência a frameworks declarados (ISO 27001, SOC 2, etc)
• Treinamento de equipe que trata seus dados
• Relatórios de testes de continuidade

Fornecedor maduro topa esse tipo de cláusula sem resistência. Fornecedor que resiste está te dizendo algo — provavelmente que não está pronto para auditoria de cliente.

Em resumo: o checklist final antes de assinar

1. SLA com penalidade real em dinheiro, não crédito vazio
2. Cláusula de auditoria anual obrigatória
3. Limites de reajuste atrelados a IPCA com teto
4. Notificação prévia obrigatória para mudança de modelo de cobrança (180 dias)
5. Mudança de controle societário gera direito de rescisão
6. Cessão de contrato exige consentimento prévio
7. Confidencialidade perpétua para informações estratégicas
8. Direito de aprovação de subcontratação relevante
9. Foro neutro ou de cidade do cliente
10. Devolução de dados em formato estruturado, sem custo, em prazo definido
11. Limite de responsabilidade simétrico entre as partes
12. Exclusões claras da limitação (dolo, culpa grave, LGPD)

12 pontos. Se algum estiver fora, marca em vermelho e leva para nova rodada de negociação. Se ainda assim o fornecedor não topa, pense duas vezes se quer mesmo fechar.

Se você está com contrato chegando para assinar, ou está num momento de revisão, vale a pena baixar os templates. Não são contratos para usar diretamente — todo contrato precisa de adequação ao caso. Mas servem como checklist do que tem que estar lá.

Os 5 pontos críticos que poucos revisam no contrato

Em revisão de contrato de TI, três ou quatro itens recebem atenção da maioria das empresas: valor, prazo, escopo, SLA. Mas há cinco pontos que tipicamente passam batido — e que custam caro quando o contrato vira problema:

1. Propriedade intelectual. Quem é dono do código produzido? Da arquitetura? Da documentação? Tipicamente o fornecedor tenta manter propriedade ampla; o cliente assume custo de construção e fica sem ativo. A cláusula precisa ser explícita: tudo desenvolvido sob o contrato é de propriedade exclusiva do contratante, sem restrição de uso futuro.

2. Multas e penalidades. SLA sem multa real é declaração de intenção. Quando o SLA é descumprido, a multa precisa ser proporcional ao impacto — não simbólica. Empresa madura inclui multa baseada em percentual do faturamento mensal do fornecedor sob o contrato, com escala crescente para descumprimentos sucessivos.

3. Direito de auditoria. Cliente tem direito de auditar instalações, processos e sistemas do fornecedor? Pode contratar terceiro independente? Em quais condições? Sem essa cláusula, problemas operacionais ficam fora de alcance do cliente.

4. Reversão e portabilidade. No fim do contrato, como o cliente recupera dados, configurações, customizações? Em qual formato? Em quanto tempo? Fornecedor pode reter material como leverage de renovação. Cláusula explícita de transição protege o cliente.

5. Limitação de responsabilidade. Quando o fornecedor erra, qual é o limite financeiro de responsabilidade dele? Tipicamente fornecedores tentam limitar a 12 meses de honorários — valor frequentemente insuficiente diante de incidente real. Cláusula bem negociada protege o cliente contra prejuízo maior.

O que o jurídico tradicional pode não capturar

Outra coisa que aparece sempre: jurídico tradicional revisa contrato de TI sem entender as nuances técnicas. Resultado: cláusulas legais bem feitas, cláusulas técnicas frágeis ou inexistentes. O contrato passa pelo jurídico, mas falha na operação.

Exemplos práticos: cláusula de "disponibilidade adequada" sem definição quantitativa (qual é o uptime contratado?); "atendimento profissional" sem definição de SLA por severidade; "manutenção corretiva" sem distinção entre bug, melhoria e nova funcionalidade; "backup adequado" sem RTO/RPO definidos.

A revisão técnica precisa acontecer em paralelo. Idealmente, time técnico revisa antes do jurídico, marca pontos a serem traduzidos para cláusula contratual. Jurídico então formaliza. Versão final é revista por ambos.

Investimento extra de tempo: 8-20 horas por contrato relevante. Retorno: redução drástica de conflito operacional futuro, e proteção real em caso de descumprimento.

Quando renegociar antes do fim do prazo

Contrato de TI não é estático. Mercado evolui, tecnologia evolui, necessidades evoluem. Empresa madura renegocia ativamente — não apenas quando o contrato vai vencer.

Gatilhos típicos para renegociação fora do ciclo: mudança significativa do volume contratado (consumo cresceu ou caiu 30%+); surgimento de tecnologia disruptiva no setor; mudança regulatória que afeta o serviço (ex.: nova exigência de LGPD); aquisição ou fusão do fornecedor por outro grupo; incidente material que evidenciou fragilidade do contrato atual.

O processo: comunicação formal ao fornecedor expondo o gatilho, solicitação de revisão de termos, negociação estruturada com prazo definido. Em muitos casos, o fornecedor prefere renegociar a perder o contrato — especialmente em mercado competitivo.

O risco de não renegociar: contrato envelhece, condições ficam fora de mercado, cliente paga mais que o necessário ou recebe menos do que o competidor concorrente entregaria. Renegociação proativa economiza 15-30% do valor do contrato em casos típicos.