Sobre questões legais associadas à base de dados de sistemas de TI

Ao abordar questões legais relacionadas com sistemas de TI, é necessário ter um conhecimento sistemático da lei, mas ao mesmo tempo, é importante entender os componentes de um sistema de TI. Este artigo irá explicar como os sistemas de TI são compostos por diferentes componentes e como estes interagem para funcionar, bem como discutir questões legais particularmente relevantes para bases de dados, que podem ser difíceis de perceber do ponto de vista do utilizador.

Os sistemas de TI são compostos por “interface” e “lógica”

O que é a “interface” num sistema de TI

Quando tentamos entender a estrutura de um sistema de TI, o que mais se destaca é a aparência da interface. De facto, mesmo nos processos típicos de desenvolvimento de sistemas, após a definição dos requisitos, como a identificação das funcionalidades, o que normalmente se segue é o “design da interface” e a organização da “navegação”. Estes aspectos visíveis da interface são facilmente notados pelos utilizadores que encomendam o desenvolvimento do sistema e também são a área onde a comunicação entre o utilizador e o fornecedor é mais provável de ocorrer. No artigo abaixo, explicamos a “obrigação de cooperação” que o utilizador tem para com o fornecedor em todas as fases do desenvolvimento do sistema, a fim de alcançar os objetivos do projeto.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Neste artigo, explicamos principalmente a necessidade de o utilizador cooperar com o fornecedor em fases como o design básico (ou seja, a interface).

A “interface” num sistema de TI é normalmente descrita de acordo com as regras de linguagens de computador como HTML e CSS. A discussão sobre a “interface” de um sistema de TI é muitas vezes referida como “front-end”, “UI (User Interface)”, entre outros termos, mas o foco principal é a “facilidade de uso” e a “legibilidade” do ponto de vista do utilizador.

O que é a “lógica” num sistema de TI

No entanto, se um sistema de TI for baseado apenas na “interface”, será apenas uma “interface” estática, sem qualquer “movimento” ou “mudança”. Mesmo que a entrada do utilizador seja recebida e a saída seja exibida na “interface”, este processo envolve “processamento de cálculo”.

Estes componentes, que estão fora da vista do utilizador, ou seja, “por trás do sistema”, realizam cálculos e controlos complexos. Operações como a pesquisa de dados a partir da interface, a modificação de dados, a adição e a eliminação de dados, só são possíveis graças a uma base de dados previamente construída. As várias operações realizadas nas informações da base de dados são normalmente feitas numa linguagem de computador chamada SQL.

Configurar um caminho desde o acionamento de um botão ou similar na interface até à execução do comando SQL necessário, é assim que se completa a imagem geral de um sistema com movimento e mudança.

Nota-se que as discussões sobre a montagem de várias lógicas que não são visíveis a partir da “interface” são por vezes referidas como “back-end”.

Correr riscos ao discutir apenas a “aparência” do sistema

A explicação até agora serve como base para a estrutura de um sistema de TI (assumindo que funcione na web). A compreensão desses assuntos tem grande significado em termos de discussões legais, prevenção de conflitos em projetos e gestão de crises. Especificamente, pode-se imaginar que ocorram mal-entendidos na comunicação entre os utilizadores que se preocupam apenas com a “aparência” na tela e os fornecedores que têm muitas tarefas importantes no lado “lógico” invisível.

O risco de os utilizadores e fornecedores terem pontos de preocupação completamente diferentes

Por exemplo, os utilizadores que falam sobre sistemas de TI com foco na “tela” tendem a ser indiferentes à complexidade da estrutura interna. Por isso, eles podem não entender o quanto uma “pequena adição de funcionalidade” ou “pequena mudança de especificação” que parece superficial pode afetar muitos processos. O seguinte artigo explica os problemas legais que tendem a ocorrer ao abolir o sistema existente que está atualmente em operação em relação ao projeto de desenvolvimento de um novo sistema.

https://monolith.law/corporate/the-transition-from-the-oldsystem[ja]

Aqui, explicamos que muitas vezes ocorrem problemas na migração de dados para o novo sistema devido à abolição do sistema antigo. Em outras palavras, o fato de que o mecanismo de cálculo e controle interno é complexo e intrincado além do que se pode imaginar a partir da aparência pode se tornar uma fonte inesperada de problemas para o lado do utilizador. Além disso, se você não entender o “sentimento do fornecedor que cria o sistema”, pode ocorrer uma situação em que as mudanças posteriores aparecem em pequenas quantidades.

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

Em tais casos em que mudanças de especificações e adições de funcionalidades são ordenadas posteriormente, a possibilidade de um aumento posterior na remuneração pode se tornar um problema sério às vezes.

https://monolith.law/corporate/increase-of-estimate[ja]

O risco de os utilizadores serem indiferentes à “lógica” por trás

Além disso, as partes que não podem ser observadas pelo utilizador podem se tornar um grande incidente quando um problema é descoberto. O seguinte é um exemplo disso.

Risco de problemas surgirem em termos de manutenção e segurança

Isso inclui situações em que não é possível implementar funcionalidades adicionais e o desempenho se torna gradualmente mais lento durante o uso até que pare de funcionar.

Além disso, há um método de ataque de segurança chamado “injeção SQL”, que explora as deficiências do código implementado no lado da tela para extrair informações pessoais e confidenciais que não devem ser exibidas na tela. O seguinte artigo trata em detalhe de um caso que se tornou um conflito sério como resultado disso.

https://monolith.law/corporate/risks-of-libraryuse-and-measures[ja]

O tema principal deste artigo são os riscos associados ao uso de frameworks e bibliotecas, mas o caso judicial apresentado é um caso em que um ataque foi feito usando uma vulnerabilidade com injeção SQL.

Risco de a governança não se estender ao trabalho do operador

A indiferença do utilizador do sistema de TI à “lógica” por trás está ligada ao problema de que a governança pode não se estender facilmente ao trabalho do operador do sistema de TI. O seguinte artigo explica a importância do trabalho de lidar com bancos de dados no tema “perda de dados devido à negligência do operador”.

https://monolith.law/corporate/dataloss-risk-and-measures[ja]

Risco de a lógica estar errada mesmo que pareça estar funcionando corretamente na superfície

O fato de que a discussão do sistema não se limita à “tela” significa que mesmo um sistema que parece estar funcionando corretamente na superfície pode ter uma “lógica” errada. Isso pode ser revelado inesperadamente em operações irregulares, como “uma vez a cada seis meses” ou “uma vez por ano”.

Em tais casos, torna-se um problema de responsabilidade pela garantia de defeitos (não inadimplemento) legalmente em relação a um sistema que foi entregue uma vez e depois descoberto para ter defeitos.

https://monolith.law/corporate/defect-warranty-liability[ja]

Como medida de resposta quando um defeito é descoberto após a aceitação, o seguinte artigo explica o processo em detalhes.

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

Resumo

Compreensão sistemática do desenvolvimento de sistemas e assuntos jurídicos

É importante entender qual componente do sistema de TI está envolvido nos problemas legais relacionados ao desenvolvimento de sistemas, antes de identificar os pontos de discussão legais. Tanto para questões legais quanto para problemas de sistemas de TI, em disputas que ocorrem em projetos de desenvolvimento de sistemas, é especialmente importante não perder de vista o quadro geral e esforçar-se para colaborar entre diferentes indústrias.