O que é a lei relacionada a conflitos e problemas na fase de operação do sistema?

É bem conhecido que em projetos de desenvolvimento de sistemas de TI, podem surgir vários conflitos e problemas. No entanto, não é verdade que, se todo o processo de desenvolvimento for concluído sem problemas, tudo estará resolvido. Os sistemas de TI utilizados nas empresas, por sua natureza, lidam normalmente com grandes quantidades de informações confidenciais e pessoais, e podem surgir vários problemas mesmo na fase de operação. Portanto, é importante aplicar o conhecimento jurídico na consideração de medidas de resposta e prevenção para tais situações, mesmo na fase de operação.

Como a teoria jurídica relacionada aos sistemas muda entre o desenvolvimento e a operação

Um exemplo típico de problemas legais relacionados aos sistemas de TI usados nas empresas é, sem dúvida, a questão do “incêndio” do projeto na fase de “desenvolvimento”. Projetos de desenvolvimento de sistemas geralmente envolvem um grande número de pessoas, fundos e tempo, e é comum que avancem carregando vários riscos de conflitos e problemas, grandes ou pequenos.

https://monolith.law/corporate/collapse-of-the-system-development-project[ja]

No artigo acima, organizamos os tipos de conflitos que tendem a ocorrer em projetos de desenvolvimento de sistemas de acordo com um quadro legal. Além disso, o que caracteriza os problemas legais relacionados aos sistemas de TI é a “obrigação de gestão de projetos” que é assumida de forma abrangente pelo fornecedor, que é um especialista em desenvolvimento de sistemas.

https://monolith.law/corporate/project-management-duties[ja]

No entanto, após o “desenvolvimento”, o sistema de TI passa para a fase de “operação”. Operação em sistemas de TI, em poucas palavras, significa utilizar e operar o sistema desenvolvido para realizar o trabalho real. Como muitas vezes é necessário ter um conhecimento profundo das especificações para utilizar o sistema de TI, muitas vezes é necessário o apoio de técnicos de TI. O fato de que o conhecimento técnico é necessário tanto no desenvolvimento quanto na operação do sistema de TI significa que a distinção entre os dois pode ser ambígua na prática. Um exemplo que ilustra isso é a existência de uma “obrigação de suporte”.

https://monolith.law/corporate/support-obligations-of-vendors-after-system-development[ja]

No artigo acima, apresentamos um caso judicial que reconheceu a “obrigação de suporte” como uma obrigação de fornecer suporte para a operação e implementação após o desenvolvimento, distinta da “obrigação de gestão de projetos” que o fornecedor assume durante o projeto de desenvolvimento do sistema. Em outras palavras, às vezes as obrigações legais do fornecedor que aceita o trabalho de desenvolvimento são determinadas levando em consideração as circunstâncias da fase de operação subsequente. Além disso, quando o desenvolvimento de um novo sistema avança simultaneamente com a eliminação do sistema antigo, questões como a “migração de dados” do sistema antigo podem surgir. Mesmo nesses casos, a operação do sistema antigo e o desenvolvimento do novo sistema estão intimamente relacionados.

Como devemos organizar questões legais relacionadas à operação de sistemas

Como vimos, a prática relacionada aos sistemas de TI está intimamente ligada entre “desenvolvimento” e “operação”. No entanto, na fase de operação, uma vez que o projeto de desenvolvimento está concluído, é necessário considerar os problemas do “dever de gestão do projeto” separadamente. Para discutir os problemas legais de “desenvolvimento” e “operação” de forma unificada, é necessário organizar num quadro de alto nível de abstração, um pouco mais voltado para o lado legal da prática. Por exemplo, a organização a partir da perspectiva da “responsabilidade” legal relacionada aos sistemas de TI, que será explicada no artigo abaixo, é um exemplo disso.

No artigo acima, explicamos sobre responsabilidades civis como inadimplemento de obrigações, responsabilidade por defeitos e responsabilidade por atos ilícitos, levando em consideração o contexto dos sistemas de TI. No entanto, os casos em que a responsabilidade por defeitos se torna um problema na operação, exceto quando os defeitos são descobertos após a aceitação, não são tão frequentemente assumidos. Portanto, inicialmente, devemos organizar com base na responsabilidade por inadimplemento de obrigações, que se baseia no conteúdo do contrato, e na responsabilidade por atos ilícitos, que não pressupõe uma relação contratual.

Primeiro, considere se há uma violação do dever por parte do fornecedor

Se for uma responsabilidade por inadimplemento de obrigações, será discutida a violação do dever contratual, se for uma responsabilidade por atos ilícitos, será discutido se há uma realidade como “violação dos direitos de terceiros”. No caso de responsabilidade por inadimplemento de obrigações, os itens descritos no Acordo de Nível de Serviço (SLA) serão o problema. Além disso, tanto a responsabilidade por inadimplemento de obrigações quanto a responsabilidade por atos ilícitos requerem intenção ou negligência, então vamos prestar atenção a isso.

Em seguida, verifique a situação do dano do lado do usuário

A obrigação de indenização é assumida em relação aos danos reais sofridos pelo lado do usuário. Portanto, seja em caso de inadimplemento de obrigações ou atos ilícitos, se não houver danos do lado do usuário, não haverá obrigação de indenização.

Além disso, considere também a possibilidade de aplicação de compensação por negligência e cláusulas de responsabilidade limitada

Além disso, mesmo que o fornecedor tenha que assumir a obrigação de indenização, se houver algum tipo de negligência do lado do usuário, pode ser considerado um tratamento como compensação por negligência. Além disso, se houver uma limitação no valor da indenização no contrato assinado antecipadamente, o valor da indenização pode mudar de acordo com isso. Por exemplo, no modelo de contrato chamado contrato modelo do Ministério da Economia, Comércio e Indústria, a seguinte provisão é colocada sobre a responsabilidade limitada (a parte sublinhada foi adicionada pelo autor).

(Indemnização por danos)
Artigo 53 A e B, em relação à execução deste contrato e do contrato individual, se sofrerem danos devido a uma causa que deve ser atribuída à outra parte, podem solicitar indenização à outra parte, (limitada aos danos de ○○○). No entanto, este pedido não pode ser feito após o prazo de ○ meses a partir da data de conclusão da aceitação do produto estipulado no contrato individual que é a causa do pedido de indenização ou da data de confirmação do término do trabalho.

2. O valor total acumulado da indenização por danos do parágrafo anterior, independentemente de inadimplemento de obrigações, responsabilidade legal por defeitos, enriquecimento sem causa, atos ilícitos ou qualquer outra causa do pedido, é limitado ao valor de ○○○ estipulado no contrato individual que causou a causa da responsabilidade.

3. O parágrafo anterior não se aplica se baseado na intenção ou negligência grave do devedor da obrigação de indenização.

Exemplos comuns de problemas e disputas na operação de sistemas

Na prática, os exemplos representativos de problemas e disputas que podem ser esperados na operação de sistemas incluem o seguinte:

Acidentes como perda de dados causados por erros do operador

O trabalho envolvido na operação de sistemas muitas vezes envolve o manuseio de segredos comerciais importantes e informações pessoais, e acidentes podem ocorrer por descuido. Um exemplo disso é a “perda de dados”. Este assunto é discutido em detalhe no seguinte artigo.

É importante tomar precauções, como fazer backups com antecedência, para acidentes como perda de dados. Se essas medidas forem negligenciadas, pode ser extremamente difícil responsabilizar o fornecedor que foi encarregado da operação. Portanto, é necessário ter cuidado.

Ataques de segurança, incluindo vírus

Além disso, no caso de sistemas de TI como sites de comércio eletrónico, que são usados em grande escala na web por um número indeterminado de pessoas, podem ocorrer grandes incidentes e acidentes devido a ataques de segurança, incluindo vírus. A detecção desses ataques de segurança e a tomada de medidas contra eles também podem ser parte das operações.

Bugs e falhas que se tornam aparentes após a aceitação

Além disso, bugs e falhas podem se tornar aparentes após a aceitação. Não é sempre possível considerar e esgotar todas as possibilidades de bugs e falhas no processo de teste prévio, e eles podem se tornar aparentes posteriormente. Nesses casos, como a entrega já foi concluída, o desempenho da obrigação em si é geralmente considerado concluído, e você é normalmente isento da responsabilidade por não cumprimento. No entanto, em alguns casos, pode ser permitido reivindicar indenização com base na responsabilidade pela garantia de defeitos. Este assunto é discutido em detalhe no seguinte artigo.

https://monolith.law/corporate/system-flaw-measure-after-acceptance[ja]

Resumo

Na fase de “operação” do sistema, existem muitos problemas e conflitos que são diferentes em natureza dos projetos de desenvolvimento. No entanto, ao basear-se em teorias jurídicas como responsabilidade por inadimplemento, responsabilidade por atos ilícitos e responsabilidade por garantia de defeitos, é possível organizar um campo unificado que não é limitado por essas diferenças.