Un lider de program AI primește de regulă un mandat: să asigure adoptarea AI, ca echipele să lucreze mai rapid datorită acesteia, ca programul să arate rezultate. Rareori se adaugă un al doilea mandat: să asigure că tot ce se creează în același timp este responsabil. Totuși, este tras la răspundere pentru amândouă în momentul în care ceva nu merge bine. Aceasta este esența riscului său: este responsabil pentru un program ale cărui limite nu le cunoaște.
Ce câștigă prin adopție — procese mai rapide, echipe mulțumite, o poveste vizibilă de inovare — se opune la ce pierde dacă lucrurile merg prost: un incident cu un instrument care nu se afla pe lista sa, un audit care pune întrebări la care nu are răspuns, un consiliu director care întreabă de ce programul nu a observat ce se folosea deja. Această asimetrie face poziția sa vulnerabilă, chiar și atunci când programul în sine funcționează bine.
Întrebarea sa nu este "ce instrumente AI am aprobat". Acea listă o are, și este de multe ori mai scurtă decât realitatea. Întrebarea sa este: ce folosesc echipele care nu se află pe lista mea, și cum obțin vizibilitate asupra acestui lucru fără ca oamenii să îl ascundă. Un lider de program care vrea să stimuleze adopția nu își poate permite ca utilizatorii să își ascundă instrumentele din frica unei corecții. Cel care întreabă ce se folosește și apoi face din asta o problemă, nu mai primește răspuns la următoarea întrebare. Guvernanța și adopția lucrează aici una împotriva celeilalte dacă este abordat greșit.
Un răspuns pe care nu îl acceptă este un blocaj simplu: "Utilizarea AI nu este permisă fără aprobare." Acest răspuns satisface un auditor pentru o clipă, dar deplasează utilizarea către locuri pe care nimeni nu le vede. Este opusul a ceea ce vrea să obțină un lider de program: el vrea ca utilizarea AI să fie vizibilă și îndrumată, nu să treacă în clandestinitate. O interdicție fără un mecanism de raportare și învățare este pentru el o pierdere, chiar dacă pe hârtie sună conform.
De asemenea, nu acceptă un răspuns care tratează totul la fel. Un instrument care rezumă text pentru uz intern nu reprezintă același risc ca un instrument care ia automat decizii despre clienți sau angajați. Fără o distincție pe rol și nivel de risc, un program nu poate stabili priorități, iar un lider de program care nu poate stabili priorități nu își poate îndeplini mandatul.
Ce funcționează cu adevărat este o inventariere care începe de la ce există, nu de la ce este aprobat. Aceasta înseamnă a pune întrebări echipelor despre ce folosesc efectiv, și a face acest lucru într-un mod care nu aduce cu sine o sancțiune. Doar așa devine vizibil shadow AI-ul — sistemele introduse fără un traseu formal, adesea pentru că ușurau munca și nimeni nu a văzut un motiv să aștepte aprobarea.
Apoi urmează clasificarea: care aplicație afectează clienții, care afectează doar procesul intern, care ia decizii fără om la mijloc. Această clasificare determină unde supravegherea trebuie să fie strictă și unde poate rămâne ușoară. Fără această clasificare, un program tratează totul la fel de strict sau la fel de ușor, și amândouă sunt o problemă: prima frânează adopția, a doua lasă riscurile nesupravegheate.
Structura de guvernanță care urmează trebuie să se conecteze la ce există deja în organizație — comitetele de risc existente, liniile de raportare existente — nu un circuit nou pe lângă acestea. Aici se distinge un lider de program și de alte roluri din organizație: un membru al consiliului director vrea să știe ce trebuie să știe un membru al consiliului director despre riscul AI la nivelul răspunderii finale, un CIO abordează problema din perspectiva sistemelor și accesului, așa cum este descris în ce trebuie să știe un CIO despre riscul AI, iar un General Counsel se concentrează pe răspundere și obligația de documentare prin ce trebuie să știe un General Counsel despre riscul AI. Un lider de program trebuie să poată răspunde acestor trei perspective fără să își piardă propria sarcină — adopția.
Ce obligații concrete se aplică pentru care categorie de risc, și în ce termene, nu este subiectul acestei pagini. Acel text se schimbă, este actualizat și explicat în alte locuri. Aici este vorba despre mecanism: cum obține un program vizibilitate asupra a ce se întâmplă, cum traduce asta în niveluri de risc, și cum demonstrează acest lucru consiliului director și organismelor de supraveghere, indiferent de ce prevede exact textul de reglementare la un moment dat.
În momentul în care este clar ce funcționează și cine este responsabil pentru asta, apare o altă întrebare: ce randament aduce atunci când acea muncă este organizată corect. Este o întrebare care trebuie răspunsă per sarcină, nu per organizație. Scanul de muncă al FTE TO AI calculează la acest nivel ce parte din muncă poate fi preluată de AI, astfel încât un lider de program nu doar știe ce se întâmplă, ci și unde adăugarea de capacitate face cu adevărat diferența.
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.