Organizațiile consideră adesea că rolul lor este fix: noi suntem utilizator, furnizorul este aanbieder, gata. Această presupunere este adesea greșită, sau este corectă astăzi și nu mai este corectă mâine. Rolul pe care îl are o organizație în raport cu un sistem AI nu este o caracteristică fixă a organizației. Este un rezultat al ceea ce se întâmplă cu sistemul: cine îl creează, cine îl adaptează, cine îl introduce pe piață și sub ce nume. Dacă unul dintre acești factori se schimbă, este posibil ca și rolul să se schimbe, și odată cu el obligațiile aferente.
Acest lucru face din clasificare nu o fotografie de moment. Un rol care a fost stabilit corect la achiziție poate fi incorect un an mai târziu, fără ca intern să se fi decis conștient ceva.
Clasificarea depinde de un număr limitat de factori, dar acești factori nu se află toți la partea care utilizează sistemul. Este relevant, printre altele, dacă un sistem a fost dezvoltat intern sau achiziționat, dacă sistemul achiziționat este utilizat neschimbat sau este adaptat, și dacă adaptarea afectează profilul de risc al sistemului. De asemenea, este relevant sub ce nume este prezentat un sistem în exterior: un sistem care este revândut sau dezvoltat în continuare sub un brand propriu poate implica un alt rol decât rularea neschimbată a unui produs extern. Pentru limita exactă dintre aceste două poziții, este relevantă pagina despre ce se schimbă atunci când o organizație adaptează ea însăși un model achiziționat, iar pentru întrebarea de bază, care dintre cele două roluri principale se aplică, există pagina care explică de ce depinde exact alegerea între furnizor și utilizator.
Clasificarea nu este, deci, ceva ce o organizație stabilește o singură dată și apoi arhivează. Este o clasificare care trebuie reevaluată de fiecare dată când faptele de bază se schimbă.
Dacă rolul se schimbă, se schimbă și ceea ce se așteaptă de la o organizație. O parte care este pur utilizator are obligații diferite față de o parte care este (co)responsabilă pentru realizarea unui sistem. Aceasta nu afectează doar documentația. Afectează și unde în organizație ar trebui să se afle responsabilitatea pentru un sistem, cine raportează despre acesta și ce nivel de supraveghere este adecvat.
Această schimbare are repercusiuni asupra întrebării cât de serios trebuie evaluat intern un sistem. O schimbare de rol poate face ca un sistem considerat anterior gestionabil să trebuiască reevaluat în privința nivelului de risc — o întrebare tratată separat pe pagina despre ce înseamnă un nivel de risc ridicat pentru organizația care utilizează sau furnizează sistemul. Invers, o schimbare de rol poate face ca un sistem să cadă în afara domeniului de aplicare al anumitor obligații, sau să intre chiar în acesta. Ce tipuri de aplicații se află exact în afara domeniului de aplicare și care nu, este explicat pe pagina despre ce tipuri de aplicații AI se află în afara domeniului de aplicare al obligațiilor.
Factorii care provoacă o schimbare de rol se manifestă de obicei la un nivel la care conducerea, departamentul juridic sau managementul de risc nu au vizibilitate automată. O echipă care ajustează fin un model achiziționat pe date proprii. Un departament care transmite un produs extern de chatbot către clienți sub un nume de produs propriu. O integrare care combină un model al unui furnizor cu reguli proprii și oferă apoi această combinație extern. Niciunul dintre aceste pași nu trece automat printr-un registru central, iar lista IT de instrumente aprobate de obicei nu înregistrează acest tip de modificare, pentru că modificarea nu este recunoscută ca „achiziție nouă”, ci ca ajustare a ceva ce era deja aprobat.
Acesta este motivul pentru care schimbările de rol devin adesea vizibile abia atunci când ceva nu merge bine, sau atunci când se cere extern o justificare. Întrebarea „care este rolul nostru în privința acestui sistem” este atunci răspunsă retroactiv, într-un moment în care marja de a ajusta ceva este mai mică decât dacă întrebarea ar fi fost pusă mai devreme.
Deoarece clasificarea se poate schimba, distincția dintre ceea ce necesită atenție acum și ceea ce trebuie reevaluat pe termen mai lung este relevantă pentru planificarea lucrărilor de guvernanță. Nu toate implicațiile unei schimbări de rol necesită acțiune imediată; o parte poate fi planificată. Care parte este aceasta și care nu poate aștepta este tratat pe pagina despre ce trebuie abordat acum și ce poate fi planificat pentru mai târziu. Pentru un rezumat compact al întrebării de clasificare în sine, inclusiv principalele puncte de schimbare, există pagina care aprofundează circumstanțele exacte în care se schimbă un rol.
Întrebarea ce rol are o organizație în raport cu un sistem AI se află în strânsă legătură cu o altă întrebare care rareori primește aceeași atenție: ce parte din munca efectivă din organizație este deja realizată de AI, este planificată să fie realizată de AI, sau este deja preluată fără ca cineva să fi consemnat acest lucru. În timp ce întrebarea legată de rol se referă la responsabilitatea față de un sistem, scanul de muncă al FTE TO AI se referă la distribuția sarcinilor înseși: pentru fiecare sarcină se calculează ce parte poate fi preluată de AI, indiferent de rolul pe care organizația îl asumă formal în acest sens. Aceste două întrebări se intersectează, pentru că o schimbare în distribuția sarcinilor este adesea motivul unei schimbări de rol.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.