WebMakers Talks: AI Act a software house'y

Zapraszamy do wysłuchania kolejnego odcinka naszego podcastu WM Talks, w którym rozmawiamy na tematy technologiczne i biznesowe związane z branżą IT.

Piotr: Cześć, nazywam się Piotr Kaźmierczak i witam w kolejnym podcaście z serii WebMakers Talks. Tym razem będziemy znowu rozmawiali o tematyce prawnej, więc będziemy mówili o tym, gdzie przebiega linia prawna w aspektach sztucznej inteligencji, AI Act'u i ukierunkowanych pod kątem software house'ów.

Dzisiaj moim gościem jest Mateusz Borkiewicz z Kancelarii Leśniewski Borkiewicz Kostka & Partnerzy oraz Damian Maślanka, który jest naszym CTO i będzie zadawał bardziej techniczne pytania.

Mateusz: Dzień dobry.

Damian: Cześć wszystkim.

Piotr: To lecimy z tym AI Act'em i tak naprawdę co jest w nim zawarte. To co nas na wstępie interesuje to AI Act, jak definiuje sztuczną inteligencję i jakie technologie obejmuje.

Mateusz: Tak, mamy w końcu definicję sztucznej inteligencji, na którą gdzieś tam czekaliśmy wiele lat i generalnie system sztucznej inteligencji to jest taki system oparty na maszynach, który został zaprojektowany w celu działania na takich różnych poziomach autonomii. On jakby po wdrożeniu może się dostosowywać do określonych sytuacji. Natomiast też takim jego głównym celem jest to, że na bazie tych danych wejściowych ma wnioskować, czyli jakby ma działać w taki sposób, żeby na podstawie tych danych wnioskować o danych wyjściowych. Czyli to brzmi tak trochę skomplikowanie i właśnie prawniczo, ale generalnie jest to taki system, który działa trochę podobnie do człowieka, czyli ma po prostu pewne narzędzia, działa na podstawie określonych informacji, uczy się na ich podstawie i wnioskuje w taki sposób, że może to wpływać na jakieś określone działania, czy to środowiska wirtualnego, czy właśnie jakby już też naszej takiej poza wirtualnej rzeczywistości.

Piotr: Ok, jak wiemy software house jest dosyć pojemnym pojęciem i doprecyzowując tak naprawdę, można powiedzieć, różną oś modeli software house'ów, tak jak pracują i jak dotyka ich AI Act, to jak byśmy mogli sformułować kluczowe założenia w tej perspektywie?

Mateusz: To jest dobre pytanie właśnie w kontekście software house'ów, bo jakby nie każdy działa w ten sam sposób i to w jakim zakresie AI Act będzie ich też obejmował, to właśnie zależy gdzie w tej naszej układance, w tej relacji z klientem będzie software house. Generalnie jakby na rynku mamy spotykane najczęściej te dwa modele, kiedy software house tworzy jakby swój produkt, swoje oprogramowanie, markuje go i udziela licencji użytkownikom na korzystanie z niego. I drugi model, kiedy przychodzi do was klient, zamawia określone oprogramowanie, wy tworzycie, przenosicie prawa autorskie, generalnie jakby nie macie już dalej z nim do czynienia, ewentualnie tam jako jakieś utrzymanie. Natomiast tym właścicielem już staje się wasz klient.

Piotr: Ale jakby jeszcze zwrócę uwagę na tak naprawdę model mieszany, ponieważ bardzo często w naszej praktyce można się spotkać z tym, że udzielamy core'owo klientowi przekazania praw autorskich na oprogramowanie, które stworzyliśmy dla niego, ale używamy różnych komponentów, do których udzielamy już licencji, bo one były wcześniej np. wytworzone przez nas, przez co możemy klientowi przekazać je taniej. Więc jak z tym modelem?

Mateusz: Jasne, no to jest ten model hybrydowy, czyli pewnie najbardziej skomplikowany pod kątem ogarnięcia też dokumentacji, która będzie po prostu z tym projektem związana, bo tak naprawdę rozchodzi się tutaj o obowiązki, które potem na software housie będą spoczywać. Generalnie jeżeli chodzi o takie definicje, które moglibyśmy do software house'u zastosować w kontekście AI Act'u to mamy tam dostawcę i ten dostawca jest właśnie rozumiany jako ten podmiot, który wprowadza oprogramowanie na rynek, który właśnie markuje to oprogramowanie gdzieś tam swoim logo, nazwą i tak dalej. Czyli można powiedzieć, że jest właśnie tym producentem i jest za niego odpowiedzialny. No i tutaj właśnie jest dużo głosów, które twierdzą, że w momencie, jeżeli to wasz klient zamawia tego typu oprogramowanie, to wy je tworzycie, ale generalnie tym dostawcą będzie stawał się już klient.

W sensie on będzie rozumiany jako ten dostawca, ten właściciel, który już potem wprowadza to oprogramowanie. I teraz w zależności od tego, gdzie my jesteśmy jako ten software house, to tych obowiązków możemy mieć więcej i mogą one wynikać bezpośrednio z AI Act'u wtedy, kiedy jesteśmy tym dostawcą, albo one mogą wynikać z obowiązań umownych, które wasz klient na was będzie nakładał, a jak zakładam, jak życie pokazuje, to raczej będzie wymagał od was, żebyście byli po prostu w pełnej zgodności z AI Act'em przy tworzeniu tego oprogramowania.

To jest takie ogólne założenie i te właśnie odcienie szarości, które się tutaj pojawiają, bo spotykam się już zarówno z argumentami za tym, żeby traktować software house'y tylko jako dostawcę, a takimi, żeby właśnie rozdzielać mocniej te ich role, więc pewnie jeszcze trochę czasu minie, zanim ta praktyka będzie też na tyle jasna, że organy też będą w wyraźny sposób gdzieś te linie nam przedstawiały. No i teraz w zależności od tego kim jesteśmy i tak AI Act będzie określone obowiązki na nas nakładał.

I taka główna core'owa zasada, która właśnie przyświecała przy tworzeniu AI Act'u polega na tym, że człowiek ma być w centrum, czyli to, że jakby jego prawa, te prawa podstawowe będą gwarantowane i będą chronione, czyli właśnie nie będziemy tutaj jakby narzucać jemu w jaki sposób ma żyć, myśleć i tak dalej, tylko właśnie będziemy tworzyć tego typu rozwiązania, żeby ułatwiały mu życie, ale żeby nie zagrażały takiej ludzkiej egzystencji, można tak górnolotnie wręcz powiedzieć, ale jakby to założenie tutaj przyświecało od samego początku, żebyśmy nie mieli tego podejścia stricte rynkowego, tylko etyczne, które będzie dbało o to, żeby ta sztuczna inteligencja potencjalnie nie zagroziła ludziom w przyszłości.

I to jest też ten model, który opiera się na ważeniu różnych ryzyk, to znaczy AI Act nie mówi nam to musicie zrobić w taki i w taki sposób, generalnie tutaj jest lista obowiązków i jak to wdrożycie to będzie okej, tylko właśnie tutaj jest to podejście, które jest podobne i znane nam z RODO, czyli to, że jakby my sami musimy przeprowadzić dużo analiz ryzyka pod kątem tego, żeby ocenić jakiego rodzaju środki techniczne, organizacyjne powinniśmy wdrożyć właśnie w naszym oprogramowaniu, czy jakby w podejściu do jego tworzenia, żeby ono było bezpieczne i żeby spełniało te podstawowe zasady AI Act'u. To, co jest tutaj też istotne, to właśnie w zależności od tych ryzyk AI Act definiuje określone systemy jako dopuszczalne do wdrożenia, dopuszczenia na rynek lub takie, które w ogóle są przez AI Act zabronione.

Tutaj warto podkreślić, że ta lista zabronionych lub dozwolonych systemów też jakby jest załącznikiem do AI Act'u, ale to są też postanowienia otwarte. Czyli nie ułatwia nam to życia, bo jakby z jednej strony mamy jakieś przykłady, z drugiej i tak musimy robić analizy, więc to podejście oparte na ryzyku na pewno też będzie wymagało więcej pracy po stronie software house'ów, żeby w ogóle zbadać gdzie my jesteśmy w ramach tego tworzonego narzędzia.

Piotr: Ok, ale jak mówimy już tutaj o ryzyku i o tych narzędziach, które powiedzmy są dopuszczone lub właśnie nie są dopuszczone przez AI Act do użycia. Tak naprawdę mówimy stricte o wytworzeniu jakiegoś produktu, który wypuszczamy w mniejszym lub szerszym zakresie do jakiejś puli klientów. Ale co jeżeli my używamy tak naprawdę narzędzi, powiedzmy narzędzi, które nie są dopuszczone przez AI Act do wytworzenia takiego oprogramowania? Powiedzmy pomagając nam w taki nieformalny sposób, że nie wiem, zadajemy pytanie albo te narzędzie wypluwa nam jakiś efekt, z którego my korzystamy. Czy to w jakiś sposób jest powiedzmy objęte AI Act'em?

Mateusz: Jasne, nie mamy tutaj takiej sytuacji, że coś zostaje poza kontrolą. Są oczywiście postanowienia w AI Akcie, które wskazują, że te open source'y bezpłatne, które mają właśnie pomóc w jakiejś takiej bieżącej pracy są publicznie dostępne, gdzie ich warunki są znane użytkownikom, to jakby tutaj mogą nie podlegać pod AI Act, w taki sposób, że są tutaj jakieś szczególne jeszcze dodatkowe obowiązki na nich nakładane. Natomiast co do zasady, te wszystkie komponenty muszą być też ocenione pod kątem tego, gdzie one w tej układance się znajdują. Czyli z jednej strony, jeżeli będziemy mieli duże modele językowe w ramach naszego systemu AI, to one też mają swoje obowiązki. Ich twórcy mają obowiązki związane z tym, że muszą tworzyć np. instrukcję obsługi, też muszą zrobić określone testy i muszą udostępnić potem tym dalszym użytkownikom, bo wtedy wy powiedzmy w tej układance jesteście na tym kolejnym kroku, muszą też udostępnić wam te podstawowe informacje, te najważniejsze informacje w jaki sposób to narzędzie może być stosowane w taki sposób, żeby zapewniać bezpieczeństwo.

Piotr: W przypadku zastosowania tych modeli bezpośrednio w produkcie, czyli w sensie integrujemy się z nimi, korzystamy z tak naprawdę ich silnika i zasobów, ale podsumowując i wracając jeszcze do mojego pytania, czyli jeżeli wytwarzalibyśmy samo oprogramowanie i korzystali z narzędzi właśnie open source'owych, to jakby samo wytworzenie nie podlega pod AI Act, bo po prostu my je i tak dalej przerabiamy, dalej one podlegają kontroli naszych specjalistów, ale na przykład samo korzystanie z tych narzędzi już będzie objęte AI Act'em?

Mateusz: Nie, nie, wytworzenie też. W sensie jeżeli będziecie w ramach swojego systemu implementować te rozwiązania, to i tak jakby ten system jako całość musi spełniać obowiązki, które AI Act na niego nakłada.

Piotr: Ok, implementować, bo teraz mówimy o implementacji tych konkretnych modeli, czy tego, co te modele nam zaproponowały jako rozwiązania. Powiedzmy fragment kodu, nie wiem, jakąś powiedzmy encję, jakieś podejście, nie wiem, nawet biznesowe, czy podejście do analizy biznesowej. Ja mówię o można powiedzieć tego typu efekcie, który daje nam dany model.

Mateusz: Ok, to teraz jeżeli chodzi o te wytwory, to faktycznie wiele zależy przede wszystkim od tego, jak wygląda regulamin korzystania z tego typu narzędzi. Bo wy jesteście tutaj też użytkownikiem, który korzysta z tych rozwiązań po to, żeby ułatwić sobie pracę. No i generalnie jakby co narzędzie to podejście można powiedzieć, więc tego trzeba mocno pilnować i zawsze sprawdzać, ponieważ nie każde tego typu narzędzie daje wam prawo do np. monetyzowania się na podstawie tego typu wytworów. Wiele z nich faktycznie jakby daje takie nieograniczone możliwości korzyści. Natomiast trudno tutaj też mówić o prawach autorskich. To jest po prostu jakiś wytwór, ale taki trochę zawieszony w próżni można powiedzieć, bo tych praw autorskich tutaj nikt do tego wytworu nie ma. Natomiast, to co jest też istotne to to, że nie mamy też gwarancji, że coś podobnego nie dostał inny użytkownik tego narzędzia.

I w momencie, kiedy my będziemy to implementować w swoim rozwiązaniu, może się okazać, że to powiela również rozwiązanie, które gdzieś tam na drugim końcu świata ktoś inny w tym momencie też wdraża. Więc akurat tutaj byłbym ostrożny. Po pierwsze, musimy bazować mocno na regulaminach i tym, co z nich wynika, a dwa, jakby zawsze też nie traktować tego wytworu jako efekt końcowy, to znaczy zawsze spróbujmy go trochę zmienić, jakby dodać coś od siebie. Traktujmy to bardziej jako inspirację, a nie jakby już gotowy produkt, który implementujemy w ramach naszego rozwiązania.

Piotr: Ok, to teraz podsumowując już kwestie kategorii ryzyka, jakbyśmy mogli wymienić te główne kategorie ryzyka dla software house'ów, które wynikają powiedzmy bezpośrednio z przestrzegania AI Act'u, czy z realizacji swoich usług już po AI Akcie?

Mateusz: Jasne. Generalnie jeżeli chodzi o te kategorie ryzyka, to mamy to ryzyko, które wskazuje nam na niedopuszczalne praktyki. To znaczy jeżeli, czy wy będziecie mieć jakiś pomysł albo klient przyjdzie do was z jakimś pomysłem, no to jeżeli będzie to pomysł tego typu, to musi wam się zapalić czerwona lampka. Tutaj chodzi przede wszystkim o takie modele, które bardzo mocno ingerują w prawa podstawowe człowieka, czyli w tę jego swobodę np. decyzyjną. Tutaj chodzi o jakieś działania, które w sposób manipulujący mogą wpływać np. na decyzje, czyli gdzieś tam kierowane do dzieci, czy do osób starszych, czy gdyby to też miały być jakieś działania profilujące, reklamujące np. jakieś leki dla osób w jakimś kryzysie psychicznym, gdzie właśnie robiłyby jakąś presję, że to już ci na pewno pomoże i tak dalej, to tego typu działania są zabronione.

Też AI Act wprost mówi o kwestiach związanych z biometrią, czyli gdybyśmy tworzyli narzędzia, które mają na przykład oceniać nasze emocje w miejscu pracy, bo tutaj właśnie przede wszystkim to miejsce pracy jest podkreślane jako miejsce niedozwolonego analizowania emocji, to też tego nie możemy robić. No i też taki jakby ciekawy, to też z Black Mirror pewnie niektórzy znają, czyli scoring obywateli. Czyli nie możemy patrzeć na to, że dziecko obywateli X nie zostanie przyjęte do przedszkola, bo ci obywatele np. płacą nieregularnie podatki i są gdzieś tam profilowani jako obywatele trochę tej gorszej kategorii powiedzmy.

Piotr: Ok, ale jak spojrzymy na tak naprawdę to, że klient do nas przychodzi, chce stworzyć takie oprogramowanie, my od razu ustalamy właśnie zasadę tego, że przekazujemy na niego prawa autorskie, to ta linia ryzyka mimo wszystko przebiega przez software house? W sensie software house odpowiada za tego typu rozwiązania wraz z klientem i to software house powinien zareagować? Czy ta odpowiedzialność mimo wszystko powinna zostać przerzucona na klienta? No bo jakby wcześniej mówiliśmy właśnie o tej kwestii.

Mateusz: Tutaj jest pytanie po pierwsze, jak będzie software house w ogóle traktowany? Właśnie mamy te odcienie szarości i nie powiem wam teraz na 100%, że będziecie traktowani jako dostawca albo tylko jako ten pomocnik waszego klienta, więc uważam, że poziom ryzyka tutaj jest na tyle wysoki, że ja bym raczej odradzał pójście w tym kierunku, żeby jakby tłumaczyć się, że to klient chciał, więc my zrobiliśmy. Prędzej czy później może nas to po prostu dosięgnąć. Więc raczej tutaj sugeruję też wtedy rozmowę z klientem i wyjaśnienie, gdzie widzicie te problemy. Natomiast też to, co jest interesujące, to AI Act, jakby on co prawda już wszedł w życie, natomiast stosowanie określonych postanowień zostało rozciągnięte w czasie i np. jeżeli chodzi o tworzenie tych modeli, które są już zakazane przez AI Act, to jakby ten stricte zakaz będzie stosowany właśnie od 2 lutego 2025 roku, czyli można powiedzieć, że jak ktoś chce stworzyć coś, jest niezgodne z AI Act'em to jest ostatni dzwonek żeby to zrobić, aczkolwiek nie polecam i nie zachęcam. Także jakby to jest ta pierwsza kwestia ryzyk niedopuszczalnych systemów AI. Są te systemy wysokiego ryzyka, no i tak naprawdę wokół nich się kręci cały ten AI Act i tutaj software house'y będą też miały najwięcej roboty. Co prawda to jest system wysokiego ryzyka, ale tak naprawdę patrząc na to, z czym przychodzą klienci, albo jak my też widzimy po naszych klientach, jakie rozwiązania stosują u siebie w firmach, to wydaje się, że wiele rozwiązań będzie tutaj podlegało pod ten wymóg.

To są systemy, które też żeby nie zanudzać, z jednej strony podlegają pod konkretne przepisy Unii Europejskiej, bo są związane z jakąś konkretną branżą, typu lotnictwo, windy i tak dalej, więc jak ktoś przyjdzie z jakimś oprogramowaniem do wind, to już pali się nam lampka. Natomiast druga grupa to są właśnie te ryzyka, które też są znowu wskazane w AI Akcie gdzieś tam wypisane, na podstawie których my też musimy robić swoje analizy.

No i one też znowu dotyczą kwestii na przykład profilowania, czyli jeżeli właśnie będziemy profilować klientów, profilować użytkowników i tak dalej, to już są systemy wysokiego ryzyka, czyli też coś co już z RODO wszyscy pamiętamy, czyli właśnie profilowanie i kierowanie określonych na przykład reklam do wybranej grupy, no to tutaj jakby wiemy, że to było oparte o algorytmy, o działania sztucznej inteligencji, to teraz jest jakby nałożony ten dodatkowy obowiązek związany właśnie z jeszcze dokładniejszym analizowaniem ryzyk pod tym kątem. I takie działania, które mogą być bliskie wielu podmiotom, to są działania wykorzystywane w rekrutacji albo w zatrudnieniu, czyli wszelkiego rodzaju systemy, które analizują CV-ki, analizują wyniki prac ludzi, czy jakby dostosowują awanse, czy jakby sugerują awanse i tak dalej, no to one jakby tutaj są też właśnie w tej kategorii ryzykownych.

A wiemy, że one też jakby cieszą się pewnego rodzaju zainteresowaniem na rynku i na pewno będzie trzeba jakby dbać o to, żeby one też były zgodne wtedy z AI Act'em i ten jakby szereg dodatkowych obowiązków, żeby też spełniały. No i mamy też taką trzecią kategorię, która jest już takim nieryzykownym albo związanym z bardzo niskim ryzykiem. To są najczęściej jakieś proste narzędzia, które wspierają pracę człowieka. Czy to jest kwestia edycji tekstu, czy poprawy tego tekstu. I tutaj te obowiązki dodatkowe nie wchodzą w grę.

Natomiast to, co jest ważne dla wszystkich, to jest ta zasada przejrzystości, czyli zawsze musimy informować o tym, że mamy do czynienia ze sztuczną inteligencją, czyli właśnie, że jakiś program jest oparty o sztuczną inteligencję, no i też jeżeli software house jakby tworzyłby rozwiązanie, które jakby generuje określonego rodzaju pliki, to te pliki też powinny być oznaczane jako wytwór sztucznej inteligencji, a jeżeli chodzi o deepfake, to już w ogóle musi być wprost nazwane deepfake'iem.

Piotr: Ale te pliki powinny zostać oznaczane, w sensie kiedy one są wytwarzane już powiedzmy produkcyjnie, czy są to jakieś rodzaje powiedzmy plików, czy fragmentów, nie wiem, dzieła kodu, które zostały tworzone przez sztuczną inteligencję i to też powinno zostać dla klienta oznaczone.

Mateusz: Gdybyśmy my tworzyli rozwiązanie, które generuje te pliki, to wtedy te pliki muszą być oznaczone. Natomiast jeżeli my posiłkujemy się w tej pracy, to my nie musimy tego stricte oznaczać dla klientów, jeżeli tam jakiś element powstał przy współpracy z AI. Ale tak jak mówiłem wcześniej, do tego podchodzimy też tak, że inspirujemy się bardziej, a nie kopiujemy tego, co nam AI tutaj podsuwa.

Piotr: Jasne, mówiliśmy o ryzykach, więc płynnie możemy przejść do tego, jakie konsekwencje software house może ponieść, kiedy nie zastosuje się w jakimś aspekcie do AI Act'u.

Mateusz: No to tak, jakby przyjmujemy tutaj na te potrzeby, że faktycznie software house jest tym dostawcą, bo jakby próbujemy go złapać gdzieś w tej maszynie AI Act'u, ewentualnie może być też użytkownikiem oprogramowania, jeżeli np. też stosuje jakieś oprogramowanie, ale wprowadza do niego na tyle istotne zmiany, to też będzie wtedy się stawał dostawcą. Czyli np. nie tylko, jeżeli byście w ramach software house'u dostali zlecenie wyprodukowania czegoś, ale też jeżeli byłby to już gotowy program, który byście mieli zmienić, ale on wykorzystywałby komponenty AI dzięki jakby waszej robocie, no to ta zmiana, którą wprowadzacie do programu już kwalifikowałaby was wtedy też jako tego dostawcę.

Natomiast przechodząc do tych ryzyk, to co z jednej strony jest też nam znane z RODO, czyli skargi podmiotów, które uważają, że jakaś firma na przykład w sposób nieprawidłowy wdrożyła AI Act albo w sposób nieprawidłowy go stosuje i tak dalej. Czyli do organu nadzoru idzie skarga, my mamy kontrolę i potencjalnie kontrola może właśnie zakończyć się tym, co jakby tutaj rozpala największą wyobraźnię, czyli karami do 35 milionów euro lub 7% rocznego obrotu za poprzedni rok. Czyli jakby te 20 milionów euro z RODO i 4% z RODO już okazują się niewystarczające i stawka jest podwyższona do tej granicy, aczkolwiek czy to ma jakiś sens, to trudno mi powiedzieć, takie granie liczbami trochę.

Piotr: Wyobraźmy sobie taki przykład w takim razie. Wytworzyliśmy oprogramowanie, które zostało przekazane w pełni klientowi i klient je sprzedaje. Jest ono zintegrowane z jakimiś narzędziami AI. Powiedzmy, że jest one właśnie niezgodne z AI Act'em. Jest gdzieś tam sygnowane powiedzmy naszym logo, nie wiem, powiedzmy by WebMakers gdzieś w prawym rogu. I teraz, czy to klient tego klienta może na przykład spojrzeć, a zostało wyprodukowane przez WebMakers, no to teraz zgłośmy WebMakers jako dostawcę, który nie przestrzega AI Act'u. Kto może złożyć i w jakim przypadku tego typu skargę?

Mateusz: Generalnie skargi są bardzo pojemne, w sensie papier przyjmie wszystko i na każdy podmiot, czyli jakby ja nie muszę mieć jakiejś bezpośredniej relacji z wami, żeby zgłaszać was do organu nadzoru. Także w tym przypadku można nawet po prostu iść na oślep i wskazywać firmy, że nam się wydaje, że ktoś nie wdrożył AI Act'u. W tym przypadku jest tylko pytanie o to, czy faktycznie organ by się wami zainteresował, czy wy byście byli faktycznie tym podmiotem, który jest dostawcą, czy byście mogli powiedzieć, że właśnie tutaj ta całość praw była na klienta i że to klient powinien być jako dostawca traktowany, ale to o czym mówiliśmy to okaże się już w praktyce jakie będzie takie twarde stanowisko organów do tej kwestii.

Piotr: Czyli może być tak, że powiedzmy klient nas zgłosi i kontrola wyląduje nas, nie na kliencie.

Mateusz: Tak, ale może się okazać, że jakby na skutek waszych tłumaczeń i pokazania umowy z klientem, że jakby wszystkie prawa przenieśliście, że wy tylko jakby działaliście na podstawie umowy, a odpowiedzialność całą bierze na siebie klient, no to być może ta kontrola by wtedy tutaj była zakończona, a przesunęła się na tamten podmiot, który jest już tym głównym odpowiedzialnym.

Piotr: Ok, czyli jeżeli chodzi o konsekwencje, są jeszcze jakieś rzeczy, które mogą wystąpić w przypadku software house'ów, jeżeli chodzi o stosowanie? Na przykład powiedzmy już nie bezpośrednie konsekwencje z AI Act'u, ale tego jak on obowiązuje i tego jak my i nasza praktyka powinna obowiązywać, czyli powiedzmy nie informujemy klienta właśnie o użyciu jakichś narzędzi lub właśnie stricte tych narzędzi, może poinformowaliśmy o jednym, ale o drugim nie, więc jak tutaj przebiega ta linia konsekwencji, czy one mogą nas dotknąć w ramach współpracy po prostu i jakie są to konsekwencje?

Mateusz: Jasne. Pod tym kątem to na pewno te ustalenia między wami a klientem muszą być wprost precyzowane w umowie. Tutaj znowu się trochę odwołam do RODO, bo akurat tu mamy dużą praktykę i wiemy też jak to już funkcjonuje po paru latach, ale to też jest kwestia przykładowo w RODO, kiedy administrator zamawia jakiś system u software house'u, który właśnie ma służyć między innymi do przetwarzania danych, tam wspomagać jakieś procesy i tak dalej. No i software house robi ten system, dostarcza go temu klientowi, natomiast potem przed prezesem Urzędu Ochrony Danych odpowiada już ten klient, no bo jakby on zdecydował, że on takim narzędziem się będzie posługiwał, on zdecydował o jego wdrożeniu i on je u was zamówił i prawa autorskie otrzymał również on.

No i tutaj właśnie może być ta podobna sytuacja, że w takim przypadku jeżeli ten klient staje się tym bezpośrednio odpowiedzialnym przed organem, to was może ewentualnie ścigać, mówiąc kolokwialnie, na podstawie zapisów umowy. To znaczy jeżeli z umowy będzie wynikało, że wy podczas tworzenia tego typu narzędzia zobowiązujecie się uwzględniać wszelkie obowiązujące przepisy prawa, być z nimi w zgodzie, uwzględniać je w ramach tego narzędzia, w szczególności AI Act itd., to faktycznie jeżeli tego nie zrobiliście, on dostał na przykład karę albo poniósł jakieś inne straty, no to potencjalnie jeżeli tej odpowiedzialności nie wyłączyliście sobie w umowie, no to może mieć potem do was jakiś regres.

Piotr: Okej, jakby jest to dla mnie zrozumiałe. Kolejna rzecz tak naprawdę w AI Act to jest temat danych osobowych, przetworzenia danych. Jak ten aspekt maluje się w kontekście software house'ów? Na co powinniśmy zwrócić uwagę i jak się zabezpieczyć? Tym bardziej, że nie zawsze to my jesteśmy po prostu administratorem. Często jakby po prostu wytwarzamy oprogramowanie, oddajemy je klientowi, więc jak do tego podejść?

Mateusz: Tutaj nie ma szczególnych nowości, to znaczy AI Act podkreśla to, że organy nadzoru związane z ochroną danych muszą szczególnie patrzeć właśnie też na to, żeby dane były prawidłowo przetwarzane przez te systemy AI. Natomiast jeżeli chodzi o obowiązki software house'ów, no to one są niezmienne względem tego, co już wynikało z RODO. To znaczy uwzględnianie tych zasad privacy by default, privacy by design, czyli żeby było jak najmniej danych przetwarzanych z defaultu, plus żeby były tylko te konieczne dane, w sensie żeby system był projektowany tak, żeby maksymalnie zawężać te dane, które do niego wejdą, mówiąc kolokwialnie, a nie żeby to rozszerzać, czyli tam robienie analiz ryzyk, data protection impact assessment, czyli właśnie jak to narzędzie może wpłynąć na przetwarzanie danych i tak dalej.

Więc jakby to są znowu te obowiązki, które wynikały z RODO i których też wasz klient teoretycznie powinien od was wymagać, żeby on swoją dokumentację techniczną miał też po prostu pełną i żeby on w przypadku ewentualnej kontroli mógł też wskazać, że was jako kontrahenta sprawdził i że dawaliście tutaj rękojmie prawidłowego wykonania tej umowy. Także jakby tutaj pod tym kątem AI Act niewiele zmienia. Dokłada wam potencjalnie jeszcze więcej tych obowiązków związanych właśnie z tworzeniem raportów, analiz ryzyk i tak dalej. Jakby ta dokumentacja techniczna na pewno musi być rozwinięta, ale stricte dotycząca działań systemu AI. Na plus pewnie w praktyce, kwestie danych osobowych będą gdzieś tam jednym z podrozdziałów tego typu dokumentacji technicznej.

Piotr: Tym aspektem przeszliśmy w sumie do praktycznego zastosowania zgodności AI Act w naszej pracy, to jak software house powinien się zabezpieczyć i jak powinien wdrożyć AI Act do swojej codziennej praktyki?

Mateusz: Czasu jeszcze mamy trochę, natomiast już teraz warto patrzeć też nie tylko na AI Act, ale te praktyki, które wokół tego AI Act'u też gdzieś tam się rozszerzają i te podejścia, które są gdzieś promowane na świecie. Na pewno musimy z jednej strony zrobić mapowanie, to znaczy zobaczyć czy już na przykład w ramach naszych komponentów, które wytworzyliśmy znajdują się systemy o określonym poziomie ryzyka i czy będą wymagały one stworzenia jakiejś dodatkowej dokumentacji. Co jest istotne to to, że jakby teoretycznie to co już mamy nie będzie podlegało pod AI Act.

W sensie jeżeli macie już wytworzone jakieś oprogramowanie, którego jesteście właścicielem, to nie jest tak, że wy przy obowiązywaniu AI Act'u musicie dorobić całą tę dokumentację wymaganą, tylko w przypadku jeżeli byście faktycznie jakieś zmiany wprowadzali do tego oprogramowania istotne albo takie, które na przykład powodowałyby zwiększenie ryzyka w ramach tego systemu, czyli że na przykład był zupełnie tylko wspomagaczem pracy, a nagle stanie się systemem wysokiego ryzyka, to wtedy was będą łapały te obowiązki. Natomiast jakby to jest takie uspokajające, że nie trzeba robić nagle audytu wszystkiego i prześwietlać każdego elementu oprogramowania, który już istnieje, bo jakby AI Act będzie wymagał tego tylko dla tych nowych albo zmienionych systemów.

Czyli to jakby jest kwestia mapowania. Polecam stworzyć taką jakby procedurę podejścia do narzędzi AI, bo z jednej strony software house podchodzi do tego w ramach też tworzenia tych narzędzi, ale z drugiej strony mamy też ten motyw wewnętrzny, czyli jakby wy też korzystacie, czy potencjalnie możecie korzystać z narzędzi, które będą wspomagały pracę waszych współpracowników. To są tematy nieco różne, natomiast mocno ze sobą współgrające i jakby z jednej strony też warto mieć procedurę, z drugiej osobę, która jest za nią odpowiedzialna. To jest taki ambasador AI można powiedzieć w firmie, który też się coraz częściej pojawia, taki trochę podobny do inspektora ochrony danych, prawda? Tylko właśnie ten ambasador AI odpowiada za to, żeby w ramach tych procesów, które dzieją się w firmie, te kwestie związane z jakimiś wątpliwościami dotyczącymi AI były do niego zgłaszane i żeby on też miał po prostu tę najbardziej aktualną wiedzę co można, jak można, bo sam AI Act jest bardzo skomplikowany. W sensie to jest nieprzyjemna lektura mówiąc wprost, a czytałem dużo różnych aktów prawnych. Jest napisany wieloma powtórzeniami, odwołaniami, ma załączniki, jeden odwołuje się do drugiego, dużo pracy dla prawników, a co dopiero dla osób, które z tekstami prawnymi nie mają na co dzień do czynienia. Więc taka osoba w firmie, która by tę wiedzę skupiała jest na pewno potrzebna. Czyli mamy procedurę, mamy człowieka, który będzie za nią odpowiadać i mamy właśnie mapowanie procesów, czyli to gdzie potencjalne ryzyka mogą się znajdować.

No i jakby już idąc tak normalną ścieżką, to patrzymy jakie mamy narzędzia i jakie będą cele związane z wykorzystaniem określonego pomysłu na przykład. Nie jakby realizacja pomysłu, to jakby sprawdzamy jakie on może mieć konsekwencje, bo na przykład zamówił je klient albo my sobie wymyśliliśmy, ale też jakie może mieć efekty przy okazji. Jakby tego też nigdy nie możemy pomijać. Dwa, czy mamy właśnie zespół, który jest w stanie to udźwignąć, czyli musimy też dbać o tę aktualność wiedzy i szkolenia załogi, która pracuje na takich dokumentach, na takich założeniach AI-owych. Trzy, skąd bierzemy dane, jeżeli karmimy nasz system, czyli skąd je mamy, czy to są dane, do których mamy jakieś prawa autorskie, licencje, czy to są dane osobowe, ale czy są tam podstawy prawne, na których można je przetwarzać.

Często to będą informacje dostarczone wam właśnie przez jakiś model AI takiego ogólnego przeznaczenia, ale to też mimo wszystko musicie sprawdzić jak on to po prostu u siebie uregulował, prawda? Czyli jakby co z tymi danymi wejściowymi możecie robić. No i dalej to jest kwestia monitoringu, czyli jakie wprowadziliśmy środki, które mają nas chronić, żeby właśnie był AI Act spełniony, no i monitorujemy czy one zdają ten rezultat. Czyli jakby to jest cały czas żywy organizm i potrzebujemy tu faktycznie osoby, która będzie nad tym miała jakąś kontrolę, bo może się okazać, że jak przyjdzie organ, to jakby trudno będzie osobie niezaznajomionej z tym, jak działa polityka AI w firmie, jakby wyciągać jakieś fragmenty i pokazywać, że my jesteśmy zgodni. Czyli jakby ten nadzór nad dokumentacją powinien być na takim dość wysokim poziomie w organizacji.

Piotr: Czyli tak naprawdę nie tylko kwestie związane z regulacją współpracy z samym klientem, ale też te wewnętrzne, organizacyjne, które są mega istotne przy takiej codziennej pracy.

Mateusz: Tak, bo to już nawet jak w pracy przyjdzie do was klient z jakimś zapytaniem, to już wtedy powinniście też wy mieć świadomość, czy pracujecie na czymś, co ma wysokie ryzyko, czy niskie ryzyko. Więc tu już ta ocena zaczyna się już od tych pierwszych chwil.

Piotr: Ok, to myślę, że tyle jeżeli chodzi o AI Act. Jeszcze mamy kilka pytań takich technicznych związanych z obowiązującym prawem.

Mateusz: Kazusy?

Piotr: No, można tak powiedzieć. Jakieś powiedzmy edge case'owe pytania, może nie edge case'owe, bo one dotykają można powiedzieć naszej praktyki i tego, nad czym się zastanawiamy, ale to myślę, że Damian już lepiej opowie albo lepiej zada te pytania.

Damian: Doczekałem się w końcu swojej sekcji pytań. Dobrze, jeżeli chodzi o rozwój sztucznej inteligencji, to można powiedzieć, że można to podzielić na dwie takie ery. Era, gdzie powstały LLM-y, czyli duże modele językowe, no i era przed tymi dużymi modelami. Wcześniej było tak, że firmy, czy osoby wykorzystywały rozwiązania chmurowe, czy też swoje modele, które uczyli, trenowali, bądź też wykorzystywali po prostu z rozwiązań chmurowych, gdzie było to w pewien sposób zabezpieczone regulaminami, gdzie tak naprawdę dostawca tych rozwiązań chmurowych tak jakby rozpisywał odpowiednie odpowiedzialności i tak dalej. W momencie, gdy pojawiła się teraz era LLMów, tutaj próg wejścia tak jakby w AI mocno zmalała. Wiele przedsiębiorstw tak naprawdę zaczęło od tej chwili masowo wykorzystywać AI.

I tutaj pytanie, czy AI Act w jakiś sposób reguluje, czy jest różnica pomiędzy takimi rozwiązaniami chmurowymi, jak nadal występują, czy też wcześniej były wykorzystane, a tym co się teraz pojawiło, że tak naprawdę AI jest dużo bardziej powszechniejszy, łatwiejszy w użyciu i czy jest tutaj jakaś różnica pomiędzy tym.

Piotr: I ta relacja przede wszystkim się zmieniła, że wcześniej relacja była można powiedzieć B2B, czyli wytwórcy jakiegoś oprogramowania produktów versus takie globalne specjalistyczne narzędzia, a teraz narzędzia, które są udostępnione tak naprawdę normalnemu zjadaczowi chleba.

Mateusz: Tak, AI Act też bierze to pod uwagę i to można powiedzieć też na takiej ostatniej prostej tam do AI Act'u zostały dodane właśnie przepisy, które regulują te modele AI ogólnego przeznaczenia, bo w taki sposób właśnie podchodzi się do tych modeli, które właśnie jakby bazują na ogromnej ilości danych i mogą służyć do tego, żeby na ich podstawie zadając pytania otrzymywać tam jakieś określone rezultaty i te ogólne modele, one nie muszą spełniać tak rozbudowanych obowiązków jak cały system AI, ponieważ one też najczęściej stają się elementem tego systemu. To znaczy, że jeżeli one zostają wdrożone do jakiegoś rozwiązania, to to rozwiązanie, jakby sam swój cały pomysł, kto w jaki sposób będzie je wykorzystywał i tak dalej i tak musi ocenić w kategorii tego swojego powiedzmy wysokiego ryzyka. I to będzie jeden z elementów.

Natomiast sam model językowy, on przede wszystkim musi udostępniać też na zewnątrz informacje o tym, w jaki sposób on działa, to znaczy na jakiego rodzaju danych się trenuje, jakiego rodzaju politykę praw autorskich przyjmuje, na czym polegają te wytwory z tej bazy. Tutaj jest właśnie ten podkreślony motyw tej przejrzystości informowania o tym, jak w ogóle te modele językowe funkcjonują. Oczywiście one też są kategoryzowane na takie bardziej ryzykowne i mniej. Te związane z czatem GPT chociażby, tutaj mają większe systemowe ryzyko, co Komisja Europejska też podkreśla i tego typu modele będą objęte też takim specjalnym nadzorem związanym z możliwością generowania ryzyk, no bo właśnie tak jak mówicie, czy z jednej strony zwykli zjadacze chleba, ale z drugiej też firmy, jeżeli będą korzystali z tych baz, ale jakby wyniki będą zmyślane, fantazjowane i jakby nie będą odpowiadały prawdzie, no to tutaj pojawia się ogólne ryzyko po prostu dla nas wszystkich, że ten duży model nie działa tak jak powinien, więc on też jest objęty regulacjami AI Act'u, ale w mniejszym zakresie niż cały system, bo on najczęściej i tak będzie potem częścią systemu i jeżeli ktoś będzie z niego korzystał, to powinien go po prostu w ramach swojej analizy też uwzględnić.

To jest i tak bardzo uproszczona odpowiedź na to pytanie szczerze mówiąc, bo to jak wam mówię kwestia i ryzyk, i załączników, i tego kto może być uznany przez komisję za ryzykowny, ale też może być ryzykowny jeżeli po prostu spełni określone kryteria, więc tutaj jest naprawdę dużo do połapania tych wątków w momencie, jeżeli byśmy już wchodzili naprawdę w określenie, który z tych modeli akurat odpowiada czemu. Stąd też tak ważne jest właśnie posiadanie w organizacji osoby, która naprawdę mówiąc kolokwialnie ogarnia te wymogi, bo jest ich po prostu więcej niż nam się tak na tej pierwszej warstwie wydaje.

Damian: Jeszcze tak uszczegóławiając właśnie na przykładzie tutaj firmy OpenAI i ChatGPT. Mamy tak naprawdę dwie możliwości użycia tej usługi. Jedna to jest po prostu używanie czatu bezpośrednio tam w przeglądarce. Druga to za pomocą API. No i różni się to tym, że o ile polityka prywatności oraz regulamin jasno precyzuje, że w przypadku API te dane, które przekazujemy do OpenAI nie są w żaden sposób wykorzystywane do późniejszego trenowania tego modelu. Tak w przypadku wykorzystywania w formie czatu, no to tutaj jest to jasno też sprecyzowane, że te dane służą do tego, żeby karmić ten model dodatkową wiedzą. Czy tutaj AI Act też to jakoś rozróżnia właśnie takie wykorzystanie przykładowo tego Chat'a GPT w takim normalnym wykorzystaniu i inaczej podchodzi do wykorzystania poprzez API czy nie jest to w żaden sposób uregulowane?

Mateusz: Nie, generalnie to już zależy od dostawcy tego modelu. Z perspektywy AI Act'u jest ważne, żeby dostawca po prostu wprost powiedział, co z tymi danymi się dzieje. Jeżeli on daje po prostu tego typu dwie ścieżki i jakby o tym wprost informuje, no to można powiedzieć, że jakby pod tym kątem jest zgodny z AI Act'em, czy tam będzie zgodny z AI Act'em, bo spełnia te obowiązki informacyjne.

Pytanie, jakie to może potencjalnie też rodzić ryzyka dla software house'u na przykład, który posługuje się tego typu narzędziami, czy w ogóle też innych firm, no bo z jednej strony możemy mieć takie trochę złudne poczucie bezpieczeństwa, że jeżeli API to nasze dane są bezpieczne, ale mamy tutaj też kilka innych aspektów, bo z jednej strony nie wiemy czy te regulaminy się w przyszłości zmienią czy nie, bo już mieliśmy takie przypadki, że różne przedsiębiorstwa zmieniały swoje podejście i coś co teoretycznie miało być chronione potem nie było, więc i tak uważam, że tutaj jest to ryzyko. A dwa, to co też widzę w regulaminach tego typu dostawców, to to, że oni przypominają, że użytkownik odpowiada za zachowanie tajemnic np. przedsiębiorstwa, handlowych i ochrony danych osobowych i ewentualna odpowiedzialność idzie do tego użytkownika.

To też jest ta nasza pomarańczowa lampka, bo faktycznie nawet jeżeli powiedzmy API daje tę gwarancję, że nie będzie tego trenowania, to mimo wszystko jeżeli byśmy jakieś poufne informacje tam załączyli no to możemy potencjalnie naruszać umowę z naszym klientem, który jakby wprost mówi, że dane zostają tylko u was i nikomu ich nie przekazujemy. Nawet jeżeli nie będzie na nich trenowany to jednak został udostępniony na jakiś serwer gdzieś do innego podmiotu. Już nie mówiąc o tym, że zawsze jest to ryzyko jakiegoś wycieku, więc po co jeszcze tutaj sobie dokładać tego stresu i tego typu dane tam zamieszczać.

Więc jakby tutaj kategorycznie, polecałbym nie ufać w takie zapewnienia bezpieczeństwa i pamiętać o tym, że te zobowiązania do poufności i tego typu zachowania tajemnic powinniśmy jakby w tym kontekście naprawdę wąsko interpretować, bo nawet jeżeli ktoś nam daje gwarancję, one będą bezpieczne, obiecujemy, no to i tak to jest podmiot trzeci, który potencjalnie nie powinien mieć do nich dostępu. Nawet jak sobie będą tylko leżeć na tym serwerze.

Damian: Zasada ograniczonego zaufania.

Mateusz: Absolutnie.

Damian: Dobrze, ja mam jeszcze takie jedno pytanie związane z odpowiedzialnością człowiek kontra maszyna można powiedzieć. Swego czasu była głośna debata, że politycy, też prawnicy zastanawiali się, kto tak naprawdę jest odpowiedzialny za wypadek, jeżeli autonomiczny samochód typu Tesla takowy wypadek spowoduje. Czy odpowiedzialność spoczywa na kierowcy, czy na producencie tego samochodu, czy też ubezpieczyciel powinien tak naprawdę całą tą odpowiedzialność wziąć na siebie. I pytanie, jak to jest w przypadku wytwarzania oprogramowania. Załóżmy, że jako software house tworzymy jakiś system, który jakieś newralgiczne dane przetwarza klienta i na podstawie tych danych wyciąga jakieś wnioski, które później klient wykorzystuje do podejmowania strategicznych decyzji w firmie, czy też rozwoju całego przedsiębiorstwa. Co w przypadku, gdy zastosujemy tutaj jakiś algorytm AI, no i okaże się, że on tutaj błędne wnioski wyciągnął. Czy odpowiedzialność spoczywa właśnie na nas, jako producencie, czyli software housie, które to oprogramowanie wytworzyło?

Bo w przypadku, gdyby to był algorytm przez nas napisany i byłby on wadliwy, no to tutaj sprawa jest jasna. Ale co w przypadku, gdy tak naprawdę dajemy, można powiedzieć, jakąś tam autonomię algorytmowi samemu sobie, bo tutaj AI sam decyduje, to kto tak naprawdę tą odpowiedzialność bierze?

Piotr: Ja może jeszcze tylko dodam, że chyba powinniśmy rozróżnić wyciąganie wniosków, a element decyzji, bo to są chyba ogólnie dwie różne rzeczy, czyli wnioski na których możemy się sugerować, ale dalej człowiek podejmuje decyzję, a moment w którym tak naprawdę model, czy ten agent stworzony przez nas podejmuje już decyzję biznesową, czyli mówi, że idziemy w tą stronę albo idziemy w tą stronę, czy nie powinniśmy od razu właśnie sobie postawić tej granicy.

Damian: Tutaj jeszcze można dodać jakiś właśnie poziom trudności, że ten system od razu decyduje, że nie ma tego czynnika ludzkiego tylko na podstawie tego, co on tam wywnioskuje, to po prostu dzieje się już docelowa akcja.

Mateusz: Jasne, ja mogę nawet podkręcić temat i powiedzmy, że waszym klientem jest szpital i robicie oprogramowanie, które dawkuje lekarstwa w zależności od stanu pacjenta i jakby ten system skanując stan decyduje, że temu pacjentowi należy podać zwiększoną dawkę i jakby z tej perspektywy ten pacjent gdzieś tam dodatkowo ponosi jakąś szkodę z tego tytułu. No i właśnie, co ten pacjent ma zrobić? Czy idzie do waszego klienta do szpitala? Czy szpital idzie do was? Czy może ten pacjent powinien przyjść od razu do was z roszczeniem?

Piotr: Albo może do modelu, który został zastosowany?

Mateusz: Albo do modelu. Tak, więc jakby mamy tutaj jeszcze tego kolejnego aktora. No i teraz faktycznie AI nie ma osobowości prawnej, więc ona sama w sobie nie odpowiada, póki co. Natomiast jeżeli chodzi o te aktualne przepisy, które obowiązują, to najczęściej ta odpowiedzialność jest związana z odpowiedzialnością za produkt niebezpieczny, w zależności od tego co zostało wyprodukowane i w tym zakresie np. wy moglibyście ponosić bezpośrednią odpowiedzialność w stosunku do waszego klienta, czyli w tym momencie szpitala. Teoretycznie pacjent też mógłby mieć do was jakieś roszczenie. Natomiast jakby ta sytuacja nie jest wcale taka jednoznaczna. Tutaj więcej miałby argumentów wasz klient - szpital, żeby mieć do was roszczenie na podstawie umowy, czyli że po prostu dostarczyliście mu jakieś wadliwe oprogramowanie i tutaj moglibyście się jakby sądzić na ile faktycznie to był wasz błąd, a na ile może jakieś nieprawidłowe wykorzystanie tego oprogramowania przez klienta. Natomiast są to trudne sprawy na ten moment.

AI Act nie przychodzi tutaj z żadnym rozwiązaniem. Natomiast to co jest teraz też na tapecie w Unii Europejskiej to właśnie dyrektywa, która ma uregulować taką odpowiedzialność podmiotów, które tworzą rozwiązania oparte o AI. Ona jest jeszcze w powijakach i ona właśnie też nie dotyczy tych regulacji umownych, bo jeżeli macie umowę ze szpitalem, to wiadomo szpital może do was przyjść i wam zarzucić niewłaściwe wykonanie umowy. Natomiast właśnie ona będzie regulowała takie sytuacje, że to ten pacjent jest tym pokrzywdzonym i on chce dochodzić od kogoś odszkodowania za to, że to oprogramowanie nieprawidłowo zadziałało i dostał nie tyle jak co trzeba. Czyli to są takie pozaumowne relacje i ta dyrektywa daje bardzo duże ułatwienie właśnie dla tego typu spraw. Właśnie dla tych pokrzywdzonych.

Czyli w tym momencie ten pacjent de facto może pozwać zarówno was, szpital, jakby każdego w tym łańcuszku, który dostarczał dane, czy miał wkład w tworzenie tego oprogramowania, po to właśnie, żeby ułatwić mu dochodzenie roszczeń, że nie musi gdzieś tam zastanawiać się, czy to była firma w Kalifornii, czy to byliście wy, czy to właśnie był szpital. Tylko niezależnie kogo pozwie, sąd powinien tę sprawę rozpatrzeć i też są duże ułatwienia dowodowe, jakby jest takie ogólne domniemanie, że to wasza wina, w sensie tego pozwanego, chyba, że on wykaże, że jakby działał tutaj prawidłowo, więc to jest taka trochę pieśń przyszłości, bo nie sądzę, żeby wcześniej niż za dwa lata ta dyrektywa zaczęła obowiązywać, natomiast faktycznie jakby ten model odpowiedzialności za AI idzie w tym kierunku, żeby pokrzywdzony mógł pozwać generalnie kogokolwiek z tego łańcuszka dostawców czy użytkowników, a sądy w taki ułatwiony sposób będą z góry zakładać, że ten podmiot jest winny, chyba że wykaże, że jest niewinny. Winny, niewinny to prawo karne, ale jakby że ponosi winę za stworzenie tutaj wadliwego tego oprogramowania. Także lepsze czasy na pewno dla użytkowników, gorsze dla tych wszystkich osób w układance naszego tworzenia tego oprogramowania.

Damian: Dobrze, dla podsumowania i potwierdzenia, czy jako właśnie software house, który wyprodukuje pewien produkt, wytworzy oprogramowanie, to musimy tak naprawdę uważać na każdy aspekt i jeżeli to my jesteśmy twórcami danego modelu AI-owego, to po prostu bierzemy odpowiedzialność za jego działanie. W przypadku, gdy wykorzystujemy model firmy trzeciej, to ta odpowiedzialność spoczywa na tej firmie trzeciej, tak?

Mateusz: Może się okazać w takim układzie, w zależności od tego na jakiej podstawie została ta decyzja podjęta, czyli jakby czy ten model, z którego korzystaliście dostarczał wam tylko dane wejściowe, a wy jakby projektowaliście tę decyzje, no to wydaje się, że w tym zakresie niestety więcej przemawia za tym, że to będzie wasza odpowiedzialność. Jeżeli w ramach tego modelu były też już pewnego rodzaju modele decyzyjne zaprojektowane przez tego dostawcę, tego pierwszego w tym łańcuszku, no to mielibyście prawo do takiego regresu. Jeżeli by was ten pacjent powiedzmy pozwał, to moglibyście dochodzić potem regres od tamtej firmy. Natomiast wydaje mi się, że w praktyce pewnie i tak będzie to utrudnione, bo zwykle będziemy mieli w przypadku tych dużych modeli językowych do czynienia z firmami o takiej skali działania, że pewnie w wielu przypadkach będzie to wyglądało jak walka Dawida z Goliatem, ale to pewnie też czas pokaże, być może podejście tych organów, które mają nadzorować właśnie rynek AI będzie tutaj też sprzyjało jakby takiemu dochodzeniu odpowiedzialności od tych też podmiotów końcowych.

Piotr: Tym pięknym akcentem kończymy dzisiejszy podcast właśnie na granicy prawa, czyli gdzie AI Act tak naprawdę się kończy i gdzie ma odcienie szarości i co nie jest pewne. Ja dziękuję moim gościom. Był z nami Mateusz Borkiewicz z kancelarii Leśniewski Borkiewicz Kostka i Partnerzy oraz Damian Maślanka w roli eksperta i naszego CTO WebMakers.

Damian: Również dzięki.

Mateusz: Dzięki.

Dziękujemy za wysłuchanie odcinka. Po więcej interesujących treści zapraszamy na naszego bloga, który znajdziecie na stronie www.webmakers.expert.

Posłuchaj w Spotify

Zobacz w YouTube