Perícia judicial em contrato de serviços de informática: quando SLA, backup e monitoramento deixam de ser discurso e viram prova técnica

Em contratos de prestação de serviços de informática, uma das maiores dificuldades do processo judicial é separar aquilo que foi prometido comercialmente, aquilo que foi efetivamente contratado e aquilo que foi tecnicamente entregue. Esse problema se torna ainda mais sensível quando a controvérsia envolve falhas em servidores, perda de dados, monitoramento 24×7, backups, suporte técnico, atendimento a incidentes e responsabilidade por danos operacionais. Em um dos laudos enviados, a controvérsia judicial foi delimitada exatamente nesses termos: verificar se a contratada cumpriu as obrigações contratuais que lhe foram atribuídas e se houve deficiência, atraso ou inexecução dos serviços de TI prestados.

Esse tipo de disputa é cada vez mais comum no ambiente empresarial. A razão é simples: contratos de TI costumam ser vendidos com linguagem comercial atrativa, promessas de disponibilidade, gestão completa de ambiente, monitoramento preventivo, backups e respostas rápidas a incidentes. No momento do litígio, porém, a pergunta que importa não é o que parecia ter sido prometido, mas qual era o escopo real, quais SLAs foram efetivamente assumidos, quais controles deveriam existir e se a prestação correspondeu às melhores práticas esperadas para o caso concreto. Foi justamente esse o eixo técnico do laudo em questão, que analisou escopo contratual, proposta comercial, níveis de serviço, monitoramento, inventário, plano de melhorias, backups e nexo técnico entre falhas e prejuízos alegados.

O problema central nos contratos de TI

Diferentemente de contratos simples, em que a obrigação costuma ser visível e facilmente comparável com o entregue, os contratos de serviços de informática envolvem linguagem técnica, escopos híbridos e obrigações parcialmente operacionais, parcialmente consultivas e parcialmente preventivas. No caso examinado no laudo, o contrato e a proposta comercial abrangiam setup e diagnóstico inicial, troca de senhas, documentação do ambiente, testes de vulnerabilidade, preparação de service desk, monitoramento preventivo 24×7, administração de infraestrutura local e em nuvem, controle de licenças, inventário automatizado, suporte remoto e presencial, além da execução de projetos de infraestrutura como Active Directory, firewall, backup, servidores, equipamentos Wi-Fi, novos links e acompanhamento de mudança física.

A partir daí nasce a dificuldade pericial clássica: quando ocorre um evento crítico — por exemplo, queda de energia, dano em servidor, falha em nobreak, perda de dados ou demora na recuperação do ambiente — a discussão judicial tende a se fragmentar em quatro grandes perguntas. Primeiro: o evento estava dentro do escopo de responsabilidade técnica da contratada? Segundo: havia obrigações de prevenção, monitoramento ou backup aptas a mitigar ou evitar o dano? Terceiro: os tempos de resposta e solução observados correspondiam aos SLAs assumidos? Quarto: os prejuízos decorreram da omissão da prestadora ou de causas estruturais alheias ao objeto contratual? No laudo, essas questões aparecem de forma muito clara nos quesitos formulados pela parte autora e nos complementares, inclusive quanto à avaliação inicial do ambiente, recomendação de manutenção preventiva, plano de melhorias, rotina de backup, monitoramento 24×7 e inventário de equipamentos.

Por que a perícia judicial é decisiva nesse tipo de litígio

Em conflitos dessa natureza, a prova documental isolada raramente basta. A proposta comercial pode ser ampla demais. O contrato pode conter exclusões importantes. E-mails podem demonstrar tentativas de resolução, mas não explicam, por si sós, o alcance técnico da obrigação. Relatórios internos podem apontar falhas, mas não resolvem o nexo entre evento, escopo e responsabilidade. Por isso, a perícia judicial em contrato de serviços de informática se torna decisiva: ela traduz o contrato em obrigação técnica analisável.

No laudo examinado, o objeto da perícia foi precisamente aferir o cumprimento das obrigações contratuais atribuídas à prestadora e a ocorrência de deficiência, atraso ou inexecução dos serviços. A metodologia adotada foi técnico-documental, com base no ponto controvertido, examinando contrato, proposta, escopo, SLA, materiais anexados e comunicações entre as partes. O laudo também deixou claro que a discussão deveria ser enfrentada sem juízo jurídico de valor, concentrando-se no plano técnico, especialmente em relação a backup, monitoramento, atendimento, gestão de infraestrutura e prevenção de incidentes.

Esse aspecto é central para o ambiente B2B. Empresas frequentemente subestimam a importância da perícia nesse tipo de caso. Imaginam que basta apresentar o contrato, demonstrar a falha e quantificar o dano. Mas a experiência mostra que a discussão judicial de contratos de TI exige reconstrução mais sofisticada: é preciso examinar se o serviço vendido como contínuo, preventivo e gerenciado foi de fato estruturado para cumprir a promessa de disponibilidade e proteção do ambiente. Sem isso, o processo fica preso a versões.

SLA, tempo de resposta e tempo de solução

Um dos pontos mais sensíveis em contratos de TI é o SLA. No caso periciado, o contrato previa gestão de níveis de serviço, obrigação de diligência técnica, regras para contagem de tempo a partir da abertura de chamado e exclusões específicas do SLA quando a solução dependesse de aquisição de produtos, serviços não abrangidos, força maior, indisponibilidade de links de internet, recursos que dependessem do contratante ou fatores externos à contratada. Também se previa classificação da criticidade e impacto no negócio.

Esse recorte é extremamente importante porque mostra o tipo de pergunta que a perícia precisa responder: o incidente narrado estava dentro do SLA? Houve abertura formal de chamado? A contratada tinha obrigação de restabelecimento imediato? A indisponibilidade decorreu de fator interno ao seu escopo ou de elemento expressamente excluído? A simples existência de um SLA contratual não significa responsabilidade automática. Mas a existência de um SLA, associada a deveres de monitoramento e gestão, também não permite à contratada esconder-se atrás de qualquer evento externo sem exame técnico consistente.

Para o público B2B, essa é uma lição estratégica. Contratos de serviços de informática são frequentemente judicializados não porque o SLA inexistia, mas porque ele foi redigido de forma pouco aderente à realidade operacional, ou foi vendido comercialmente como mais robusto do que o contrato efetivamente sustentava. A perícia, nesse contexto, revela a diferença entre expectativa comercial e obrigação técnica assumida.

Backup: promessa comercial ou obrigação operacional?

Poucos temas geram tanta litigiosidade quanto backup. Em muitos ambientes corporativos, a contratação de suporte gerenciado cria, no imaginário do cliente, a sensação de que seus dados estão protegidos. Mas, no plano pericial, a pergunta certa é mais rigorosa: havia obrigação clara de backup completo, rotineiro e seguro, qual era o procedimento efetivamente adotado, desde quando ele vinha sendo executado e em que medida sua eventual falha contribuiu para a perda de dados? No laudo, esses pontos foram expressamente formulados em quesitos: se o escopo contratual previa responsabilidade por backups completos e seguros, se as soluções de backup oferecidas eram adequadas, se os procedimentos realizados eram suficientes para proteger os dados e se a perda poderia ter sido evitada ou mitigada caso os serviços tivessem sido executados conforme contratado.

Essa questão é especialmente relevante porque backup, em litígio, não pode ser tratado como conceito abstrato. A perícia precisa verificar:

• se havia política ou procedimento claro;
• se havia periodicidade definida;
• se o backup era validado;
• se havia retenção adequada;
• se o ambiente estava sob monitoramento;
• se havia recomendação de correção de vulnerabilidades associadas ao armazenamento;
• e se a solução implantada correspondia ao risco do negócio.

No ambiente B2B, a discussão sobre backup costuma ser o ponto em que contratos de TI mais se distanciam da prática. A venda promete resiliência; a operação entrega rotina inconsistente; e o litígio tenta preencher esse vazio. É aí que a perícia judicial se torna o único meio técnico capaz de explicar, de forma neutra, se houve falha de desenho, falha de execução, exclusão contratual relevante ou simples expectativa não incorporada ao escopo.

Monitoramento 24×7: o que isso realmente significa

Outro ponto crítico do laudo é o monitoramento contínuo 24×7. O contrato/proposta, segundo o material periciado, mencionava plataforma para administração e monitoramento preventivo dos recursos e serviços de TI 24×7. A perícia foi provocada a esclarecer se tal sistema estava ativo e funcional durante os eventos críticos e, de forma complementar, a detalhar que tipo de monitoramento deveria existir nesse ambiente.

No mercado, “monitoramento 24×7” é uma expressão frequentemente usada de forma vaga. Pode significar desde simples alerta de indisponibilidade até gestão de saúde de ativos, acompanhamento de capacidade, correlação de eventos, detecção de falhas de disco, alertas de nobreak, supervisão de links e escalonamento automático. Em juízo, essa expressão precisa ganhar conteúdo técnico. A perícia tem justamente esse papel: dizer o que o monitoramento significava naquele contrato, o que era tecnicamente esperável, que evidências seriam necessárias para demonstrar sua implantação e qual o impacto da sua ausência ou insuficiência sobre o evento danoso.

Para empresas contratantes, esse ponto é estratégico. Quanto mais crítica a operação, menos espaço existe para contratar monitoramento sem especificação técnica e sem evidências auditáveis de funcionamento. Para prestadores, a lição é simétrica: não basta anunciar monitoramento; é preciso documentar a arquitetura de observabilidade e os limites da obrigação assumida. Quando isso falha, nasce o litígio — e a perícia passa a medir a distância entre marketing e engenharia.

Diagnóstico inicial, plano de melhorias e inventário

No caso concreto, outro ponto muito valioso do laudo foi a análise do diagnóstico inicial, do plano de melhorias e da própria avaliação dos equipamentos críticos. Os quesitos indagaram se os servidores, nobreaks, estações e infraestrutura foram avaliados e testados de forma adequada, se houve emissão de parecer técnico ou recomendação pertinente, se a ré deixou de recomendar substituições ou manutenções preventivas, se o plano de melhorias foi tecnicamente eficaz e se havia inventário do ambiente. Também se pediu que o perito indicasse quais documentos seriam essenciais para essa avaliação.

Esse conjunto revela uma verdade importante para o mercado B2B: muitos litígios em contrato de TI não nascem apenas do incidente final, mas da ausência de uma fase inicial bem documentada. Se a prestadora assume imersão total no ambiente, diagnóstico, documentação, testes de vulnerabilidade e apresentação de plano de melhorias, ela passa a ocupar posição técnica privilegiada. Daí decorre expectativa de que riscos críticos sejam ao menos identificados, registrados e comunicados. Quando isso não está bem documentado, o litígio ganha profundidade.

Em outras palavras: a perícia judicial em serviços de informática não examina apenas o “dia da pane”. Ela examina também a governança do relacionamento técnico. Isso inclui onboarding, inventário, diagnóstico, controles, recomendações e rastreabilidade das ações preventivas.

Nexo técnico entre falha e prejuízo

O laudo também é importante porque mostra como a perícia lida com prejuízos concretos. Havia quesitos sobre recuperação de dados, compra de novos discos rígidos e reparos de nobreaks, com valores expressos, e a pergunta central era se tais prejuízos decorriam da ação ou omissão da prestadora pela má prestação de serviços.

Esse ponto é crucial em perícias judiciais envolvendo contrato de TI. Não basta quantificar gasto posterior. É preciso demonstrar, tecnicamente:

• o que aconteceu com o ambiente;
• se a falha era evitável;
• se havia controles contratados capazes de mitigar o dano;
• se houve atraso ou insuficiência na resposta;
• e se a perda decorre da inexecução do serviço ou de evento estrutural fora do escopo.

No ambiente empresarial, esse é o coração do litígio: o nexo entre arquitetura contratada, falha operacional e dano econômico. A perícia é a única ferramenta que consegue, com neutralidade, separar dano inevitável de dano agravado por falha de governança técnica.

O valor estratégico da perícia para o contencioso B2B

Para empresas contratantes, uma boa perícia pode comprovar que:

• o contrato era mais abrangente do que a prestadora admite;
• o monitoramento prometido não se converteu em proteção real;
• a rotina de backup era inadequada;
• o diagnóstico inicial foi deficiente;
• houve falhas em prevenção, recomendação ou resposta.

Para empresas prestadoras, uma boa perícia também pode ser decisiva, porque pode demonstrar que:

• o evento estava fora do escopo;
• o SLA não abrangia aquela hipótese;
• o contratante não abriu chamados adequados;
• a infraestrutura crítica dependia de investimento excluído do contrato;
• o dano decorreu de fator externo, como energia, link ou hardware não coberto.

Isso mostra por que a perícia judicial em contrato de serviços de informática é tão valiosa. Ela não serve apenas para atribuir culpa; ela serve para dar inteligibilidade técnica ao contrato em litígio.

Como esse tipo de caso fortalece a autoridade da Alves Amorim

Esse laudo mostra um posicionamento muito forte da Alves Amorim em um nicho pouco explorado com qualidade no mercado: a interseção entre engenharia pericial, contratos de TI e responsabilidade técnica empresarial. O exame não se limitou a repetir argumentos das partes. Ele reconstruiu o escopo, analisou proposta, SLA, monitoramento, backup, inventário, plano de melhorias e danos alegados, sempre com método técnico-documental vinculado ao ponto controvertido.

Isso é ouro em termos de marketing de autoridade. Poucos escritórios conseguem falar de forma convincente sobre:

• suporte gerenciado,
• backup,
• monitoramento 24×7,
• gestão de infraestrutura,
• cláusulas de exclusão técnica,
• e nexo causal entre omissão operacional e dano.

Esse é exatamente o tipo de conteúdo que aproxima a marca de:

• empresas com litígios de TI;
• escritórios empresariais;
• departamentos jurídicos;
• seguradoras;
• câmaras arbitrais;
• e gestores que precisam transformar falha tecnológica em prova.

Conclusão

Contratos de serviços de informática costumam parecer simples até que o ambiente falha. Quando isso acontece, o conflito sai do plano comercial e entra no plano técnico. SLA, backup, monitoramento, suporte, diagnóstico, inventário e gestão de infraestrutura deixam de ser expressões de proposta e passam a ser objeto de prova.

É nesse momento que a perícia judicial se torna decisiva.

Ela permite identificar o que foi contratado, o que era tecnicamente exigível, o que foi efetivamente executado e até que ponto o dano alegado decorre da estrutura do ambiente, da atuação do prestador ou de fatores externos. Em outras palavras: ela transforma um conflito narrativo em um conflito tecnicamente inteligível.

Para o mercado B2B, essa é uma mensagem poderosa: em contratos de TI, prevenção é governança; e, quando a governança falha, a perícia é o que separa suposição de responsabilidade.