Ce înseamnă legea în legătură cu conflictele și problemele în etapa de operare a sistemului?

Este bine cunoscut faptul că în proiectele de dezvoltare a sistemelor IT pot apărea diverse conflicte și probleme. Cu toate acestea, nu este deloc adevărat că, dacă toate etapele unui proiect de dezvoltare se finalizează fără probleme, totul este în ordine. Sistemele IT utilizate în companii, prin natura lor, sunt de obicei cele care gestionează o cantitate mare de informații confidențiale și personale, iar în etapa de operare pot apărea diverse probleme. Prin urmare, este important să folosim cunoștințele juridice pentru a lua în considerare și a preveni astfel de situații chiar și în etapa de operare.

Cum se schimbă discuțiile juridice în jurul sistemelor în dezvoltare și operare?

Un exemplu tipic de probleme juridice legate de sistemele IT utilizate în companii este, fără îndoială, problema “incendiului” în etapa de “dezvoltare” a proiectului. Proiectele de dezvoltare a sistemelor implică adesea un număr mare de oameni, fonduri și timp, devenind astfel o afacere pe scară largă, și avansează în mod normal cu riscuri de diferite conflicte și probleme, mari sau mici.

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

În articolul de mai sus, am clasificat tipurile de conflicte care apar adesea în cadrul proiectelor de dezvoltare a sistemelor, în conformitate cu cadrul juridic. De asemenea, ceea ce caracterizează problemele juridice legate de sistemele IT este “obligația de management al proiectului”, care este considerată a fi asumată în mod cuprinzător de către furnizorii specializați în dezvoltarea sistemelor.

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

Desigur, după “dezvoltarea” sistemelor IT, acestea trec în faza de “operare”. Operarea în sistemele IT, într-un singur cuvânt, înseamnă să utilizezi și să operezi sistemul dezvoltat pentru a efectua activități reale. Deoarece este adesea necesar să cunoști în detaliu specificațiile pentru a utiliza sistemul IT, este adesea necesară și expertiza tehnicienilor IT. Faptul că sistemele IT necesită cunoștințe tehnice atât în dezvoltare, cât și în operare înseamnă că distincția dintre cele două poate deveni vagă în practică. Un exemplu care ilustrează acest lucru este existența “obligației de suport”.

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

În articolul de mai sus, am prezentat un caz în care s-a recunoscut “obligația de suport” ca o obligație de a oferi asistență pentru operarea și implementarea după dezvoltare, distinctă de “obligația de management al proiectului” pe care o are furnizorul în timpul proiectului de dezvoltare a sistemului. Adică, există cazuri în care obligațiile legale ale furnizorului care preia dezvoltarea sunt determinate luând în considerare și circumstanțele fazei de operare ulterioare. De asemenea, atunci când dezvoltarea unui nou sistem avansează în același timp cu eliminarea sistemului vechi, pot apărea probleme precum “migrarea datelor” din sistemul vechi. În astfel de cazuri, operarea sistemului vechi și dezvoltarea noului sistem sunt strâns legate una de cealaltă.

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

Cum ar trebui să organizăm problemele legale legate de operarea sistemelor?

Așa cum am văzut, practica legată de sistemele IT este strâns legată de “dezvoltare” și “operare”. Cu toate acestea, în faza de operare, având în vedere că proiectul de dezvoltare s-a încheiat, este necesar să considerăm problemele legate de “obligațiile de management al proiectului” separat. Pentru a discuta în mod unitar problemele legale ale “dezvoltării” și “operațiunii”, este necesar să le organizăm într-un cadru cu un grad ridicat de abstractizare, ușor mai orientat spre lege. De exemplu, organizarea din perspectiva “responsabilității” legale asociate cu sistemele IT, explicată în articolul de mai jos, este un exemplu în acest sens.

https://monolith.law/corporate/responsibility-system-development[ja]

În articolul de mai sus, explicăm responsabilitatea pentru neexecutarea obligațiilor civile, responsabilitatea pentru garanția defectelor și responsabilitatea pentru acte ilicite, luând în considerare contextul sistemelor IT. Cu toate acestea, cazurile în care responsabilitatea pentru garanția defectelor devine o problemă în operare nu sunt atât de multe, cu excepția cazurilor în care defectele sunt descoperite după acceptare. Prin urmare, ar trebui să începem prin organizarea responsabilității pentru neexecutarea obligațiilor, bazată pe conținutul contractului, și responsabilității pentru acte ilicite, care nu presupune o relație contractuală.

În primul rând, examinați dacă există încălcări ale obligațiilor din partea furnizorului

În cazul responsabilității pentru neexecutarea obligațiilor, se va discuta dacă există o încălcare a obligațiilor contractuale, iar în cazul responsabilității pentru acte ilicite, dacă există o “încălcare a drepturilor altora”. În cazul responsabilității pentru neexecutarea obligațiilor, elementele menționate în Acordul de nivel de serviciu (SLA) vor fi o problemă. De asemenea, trebuie să reținem că atât responsabilitatea pentru neexecutarea obligațiilor, cât și responsabilitatea pentru acte ilicite necesită intenție sau neglijență.

Verificați apoi situația în care apar daunele din partea utilizatorului

Obligația de despăgubire se aplică în cazul în care utilizatorul a suferit un prejudiciu. Prin urmare, indiferent dacă este vorba de neexecutarea obligațiilor sau de acte ilicite, dacă nu au apărut daune din partea utilizatorului, nu va fi necesar să se asume o obligație de despăgubire.

Examinați de asemenea posibilitatea aplicării compensării pentru neglijență și a clauzelor de limitare a responsabilității

Chiar și în cazul în care furnizorul trebuie să își asume o obligație de despăgubire, dacă există o anumită neglijență din partea utilizatorului, se poate considera o compensare pentru neglijență. De asemenea, dacă există o limitare a sumei de despăgubire în contractul încheiat în prealabil, suma de despăgubire poate fi modificată în funcție de aceasta. De exemplu, în modelul de contract cunoscut sub numele de contractul model al Ministerului Economiei, Comerțului și Industriei, există următoarea prevedere privind limitarea responsabilității (partea subliniată a fost adăugată de autor).

(Despăgubire)
Articolul 53 Părțile A și B pot solicita despăgubiri dacă suferă daune datorită unor motive care pot fi atribuite celeilalte părți în legătură cu îndeplinirea acestui contract și a contractelor individuale. Cu toate acestea, această cerere nu poate fi făcută după ce au trecut X luni de la data finalizării acceptării produselor specificate în contractul individual respectiv sau de la data confirmării finalizării serviciilor.

2. Suma totală acumulată a despăgubirilor din paragraful anterior este limitată la suma specificată în contractul individual care a cauzat motivul de răspundere, indiferent de neexecutarea obligațiilor, responsabilitatea legală pentru garanția defectelor, îmbogățirea nejustificată, actele ilicite sau orice alt motiv de cerere.

3. Paragraful anterior nu se aplică în cazul în care obligația de despăgubire se bazează pe intenție sau neglijență gravă.

Exemple de probleme și conflicte frecvente în operarea sistemelor

De asemenea, în practică, exemplele reprezentative de probleme și conflicte care pot apărea în operarea sistemelor includ următoarele:

Accidente precum pierderea de date cauzate de erorile operatorului

Munca implicată în operarea sistemelor implică adesea prelucrarea de secrete corporative importante și informații personale, și accidente pot apărea din neglijență. Un exemplu de acest lucru este “pierderea de date”. Detalii despre aceste cazuri sunt explicate în detaliu în articolul de mai jos.

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

Pentru accidente precum pierderea de date, este important să luați măsuri de precauție, cum ar fi efectuarea de backup-uri în avans. Dacă aceste măsuri sunt neglijate, poate fi extrem de dificil să se urmărească responsabilitatea către furnizorul care a fost însărcinat cu operațiunile, așa că este necesară precauție.

Atacuri de securitate, inclusiv viruși

De asemenea, în cazul sistemelor IT precum site-urile de comerț electronic, care sunt utilizate în masă pe web de un număr mare de persoane, pot apărea incidente și accidente majore datorate atacurilor de securitate, inclusiv viruși. Detectarea acestor atacuri de securitate și luarea de măsuri împotriva lor pot fi, de asemenea, considerate parte a operațiunilor.

Bug-uri și defecțiuni care apar după acceptarea inspecției

De asemenea, pot apărea noi bug-uri și defecțiuni după acceptarea inspecției. Nu este întotdeauna posibil să se examineze în mod exhaustiv toate posibilitățile de bug-uri și defecțiuni în etapa de testare preliminară, și pot apărea după aceea. În astfel de cazuri, deoarece livrarea este deja finalizată, se consideră că îndeplinirea obligației este finalizată, și este de obicei scutită de responsabilitatea pentru neîndeplinirea obligației. Cu toate acestea, pot fi recunoscute cereri de despăgubire pentru daune bazate pe responsabilitatea pentru defecte. Detalii despre aceste cazuri sunt explicate în detaliu în articolul de mai jos.

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

Rezumat

În etapa de “operare” a sistemului, există numeroase probleme și conflicte care diferă în natură de proiectele de dezvoltare. Cu toate acestea, prin stabilirea unui fundament pe teorii legale precum responsabilitatea pentru neexecutarea datoriilor, responsabilitatea pentru acte ilegale și responsabilitatea pentru garanția defectelor, este posibilă organizarea unui domeniu unitar care nu este limitat de aceste diferențe.