Problemi legali associati ai database dei sistemi IT

Quando si tratta di comprendere le questioni legali relative ai sistemi IT, è richiesta una conoscenza sistematica del diritto. Allo stesso tempo, è importante conoscere gli elementi costitutivi dei sistemi IT. In questo articolo, esamineremo come i sistemi IT sono costituiti da vari componenti e come questi componenti interagiscono tra loro per funzionare. Inoltre, discuteremo le questioni legali strettamente correlate ai database, che possono essere difficili da notare dal punto di vista dell’utente.

Un sistema IT è composto da “schermata” e “logica”

Cosa si intende per “schermata” in un sistema IT

Quando si cerca di capire la struttura di un sistema IT, la cosa più evidente è l’aspetto della schermata. Infatti, anche nel processo di sviluppo di un sistema generale, dopo la “definizione dei requisiti”, in cui si identificano le funzionalità, di solito si procede con la “progettazione della schermata” e l’organizzazione della “transizione tra schermate”. Questi aspetti visibili sulla schermata sono ovviamente aree che attirano l’attenzione dell’utente che commissiona lo sviluppo del sistema, e sono anche aree in cui la comunicazione tra l’utente e il fornitore è più probabile. Nel seguente articolo, spieghiamo l'”obbligo di cooperazione” che l’utente ha nei confronti del fornitore durante tutto il processo di sviluppo del sistema per raggiungere l’obiettivo del progetto.

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

In questo articolo, spieghiamo principalmente che l’utente ha l’obbligo di cooperare con il fornitore, soprattutto durante la fase di progettazione di base (cioè la schermata).

La “schermata” in un sistema IT è solitamente descritta in base alle regole dei linguaggi di programmazione come HTML e CSS. Quando si parla della “schermata” di un sistema IT, si utilizzano vari termini come “front-end”, “UI (User Interface)”, ma il punto principale della discussione è la “facilità d’uso” e la “leggibilità” dal punto di vista dell’utente.

Cosa si intende per “logica” in un sistema IT

Tuttavia, se un sistema IT fosse basato solo sulla “schermata”, sarebbe solo una “schermata” statica, senza alcuna “azione” o “cambiamento”. Anche se l’input dell’utente e la visualizzazione dell’output avvengono sulla “schermata”, ciò è possibile grazie ai “processi di calcolo”.

Questi componenti, che non sono visibili all’utente e che potrebbero essere definiti come “il retro del sistema”, eseguono calcoli e controlli complessi. Le operazioni come la ricerca di dati dalla schermata, la modifica dei dati, l’aggiunta o l’eliminazione, sono possibili grazie alla presenza di un database pre-costruito. Le varie operazioni sui dati del database sono solitamente eseguite con un linguaggio di programmazione chiamato SQL.

Creare un percorso dall’attivazione di un pulsante sulla schermata all’esecuzione del comando SQL necessario, è così che si completa l’immagine complessiva di un sistema con movimento e cambiamento.

Si noti che le discussioni relative alla costruzione di varie logiche invisibili dalla “schermata” sono spesso chiamate “back-end”.

Il rischio di discutere solo dell’aspetto “visivo” di un sistema

Le spiegazioni finora fornite costituiscono le basi della struttura di un sistema IT (presumendo che funzioni online). La comprensione di questi aspetti ha un grande significato anche in termini di discussione legale, prevenzione dei conflitti nei progetti e gestione delle crisi. In particolare, è possibile che si verifichino incomprensioni nella comunicazione tra gli utenti, che si concentrano solo sull’aspetto “visivo” sullo schermo, e i fornitori, che gestiscono molte operazioni importanti sul lato “logico” invisibile.

Il rischio è che gli utenti e i fornitori si preoccupino di punti completamente diversi

Ad esempio, gli utenti che parlano di un sistema IT concentrandosi sulla “schermata” tendono a non preoccuparsi della complessità della sua struttura interna. Proprio per questo, potrebbero non capire quanto un “piccolo aggiunta di funzionalità” o una “piccola modifica delle specifiche”, che sembrano insignificanti dal punto di vista visivo, possano influenzare molti processi. Ad esempio, l’articolo seguente spiega i problemi legali che spesso sorgono quando si smantella un sistema esistente che è attualmente in uso per un progetto di sviluppo di un nuovo sistema.

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

In questo articolo, spieghiamo come spesso si verificano problemi durante la migrazione dei dati al nuovo sistema a seguito dello smantellamento del vecchio sistema. In altre parole, la complessità dei meccanismi di calcolo e controllo interni, che non si possono immaginare solo guardando l’aspetto esterno, può diventare una fonte inaspettata di problemi per gli utenti. Inoltre, se non si capisce il “punto di vista del fornitore che crea il sistema”, potrebbe accadere che le modifiche vengano apportate a poco a poco dopo il fatto.

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

In casi come questi, in cui vengono ordinati cambiamenti nelle specifiche o l’aggiunta di funzionalità dopo il fatto, la possibilità di un aumento retroattivo della remunerazione può diventare un problema molto reale.

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

Il rischio che gli utenti siano indifferenti alla “logica” dietro

Inoltre, ci sono casi in cui le parti che non possono essere osservate dagli utenti diventano grandi incidenti quando i problemi vengono alla luce. Ecco un esempio.

Il rischio di problemi di manutenzione e sicurezza

Questo include situazioni in cui non è possibile implementare funzionalità aggiuntive, o in cui il sistema diventa progressivamente più lento durante l’uso fino a diventare inutilizzabile.

Inoltre, ci sono attacchi di sicurezza che sfruttano le carenze nel codice implementato sul lato dello schermo per estrarre informazioni personali e riservate che non dovrebbero essere visualizzate sullo schermo. Un esempio di questo è un metodo chiamato “SQL Injection”. L’articolo seguente tratta in dettaglio un caso in cui questo ha portato a un grave conflitto.

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

Il tema principale di questo articolo sono i rischi associati all’uso di framework e librerie, ma il caso giudiziario presentato riguarda un attacco a una vulnerabilità utilizzando SQL Injection.

Il rischio che la governance non si estenda al lavoro dell’operatore

Il fatto che gli utenti di un sistema IT siano indifferenti alla “logica” dietro di esso può portare al problema che la governance diventa difficile da estendere al lavoro dell’operatore del sistema IT. L’articolo seguente tratta l’importanza del lavoro con i database sul tema della “perdita di dati a causa della negligenza dell’operatore”.

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

Il rischio che la logica sia sbagliata anche se sembra funzionare correttamente in superficie

Il fatto che la discussione sul sistema non si limiti alla “schermata” significa che anche se il sistema sembra funzionare correttamente in superficie, la “logica” potrebbe essere sbagliata. Questo potrebbe diventare evidente in modo inaspettato in operazioni irregolari come “una volta ogni sei mesi” o “una volta all’anno”.

In questi casi, si tratta di un problema di responsabilità per i difetti, non di inadempimento, dal punto di vista legale, per un sistema che è stato consegnato una volta e poi ha rivelato difetti.

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

Se si scopre un difetto dopo l’accettazione, l’articolo seguente spiega in dettaglio come affrontare la situazione.

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

Riassunto

Una comprensione sistematica sia dello sviluppo di sistemi che della giurisprudenza

È importante comprendere quale componente del sistema IT è coinvolto nei problemi legali relativi allo sviluppo di sistemi, come prerequisito per identificare i punti di discussione legali. Sia come problema legale che come problema del sistema IT, nei conflitti che sorgono nei progetti di sviluppo di sistemi, è particolarmente importante non perdere di vista l’immagine complessiva e fare del proprio meglio per collaborare tra settori diversi.