WM Talks - Wdrażanie produktów SaaS i AI SaaS w kontekście AI Act

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: Witam w kolejnym odcinku WebMakers Talks. Nazywam się Piotr Kaźmierczak i poprowadzę dzisiejszą rozmowę z Paulą Skrzypecką z Creativa Legal. Porozmawiamy trochę o legalnym tworzeniu i wdrażaniu produktów AI i AI SaaS oraz na co warto zwrócić uwagę w kontekście prawa .

Paula, weszły nowe przepisy dotyczące regulacji AI. Od czego warto zacząć, na co warto zwrócić uwagę jeżeli chodzi o kwestie prawne przy wdrażaniu nowych produktów tego typu?

Paula: Przede wszystkim było już dotychczas, jeszcze przed AI Act'em sporo przepisów, które już pośrednio te kwestie regulowały. W związku z czym to nie jest tak, że teraz wydarzyło się coś zupełnie nowego czego nie dało się wcześniej przewidzieć. Natomiast jak już mówimy o AI Akcie który wszedł w życie 2. sierpnia, to tutaj myślę, że na start powinniśmy podejść od samego początku. Czyli po pierwsze - zastanowić się, czy w ogóle ta regulacja nas dotyczy. To nie jest takie oczywiste, bo AI Act chociażby dotyczy wyłącznie komercyjnego wdrażania, utrzymywania, rozwijania systemów sztucznej inteligencji i jest tam sporo wyjątków przewidzianych na przykład na rzecz twórców open source'owych, LLM-ów albo wdrażania systemów sztucznej inteligencji na potrzeby badań naukowych, działań stricte rozwojowych bez dalszego planu na ich komercjalizację. Więc pierwsza sprawa - w ogóle zobaczmy czy łapiemy się w zakres tej regulacji.

Druga kwestia - czy to co robimy będzie systemem sztucznej inteligencji w rozumieniu AI Act'u? Dlatego, że AI Act posługuje się pojęciem System Sztucznej Inteligencji i wszystkie przepisy odmieniają to słowo przez wszystkie przypadki.

Generalnie ta definicja jest dosyć pojemna. Praktycznie każde narzędzie, każdy model o którym dzisiaj pomyślimy, kiedy rozmawiamy z klientami, albo mówimy o tworzeniu jakiegoś rozwiązania AI-owego, będzie tym systemem sztucznej inteligencji w rozumieniu tych przepisów. Natomiast zawsze zostają jakieś odcienie szarości. Może się okazać, że w określonym przypadku coś, jakiś moduł na przykład uzupełniający, dzisiaj istniejący na rynku produkt, już tym systemem sztucznej inteligencji wcale nie będzie.

Więc punkt drugi: patrzymy czy to co robimy mieści się w ramach systemu sztucznej inteligencji. Spoiler alert jest taki że najprawdopodobniej - tak. Kolejna kwestia patrzymy na to kim jesteśmy w świetle AI Act'u. Bo to, że mamy do czynienia z jakimś produktem, z jakimś rozwiązaniem AI-owym, to jedno, ale druga kwestia, to ustalenie kim my jesteśmy w ogóle w łańcuchu dostawy tego rozwiązania na rynek? Czy jesteśmy właśnie dostawcą? Czy jesteśmy dystrybutorem? Czy jesteśmy tylko użytkownikiem, albo w ogóle pełnimy jeszcze jakąś inną funkcję? I to wbrew pozorom nie jest wcale taki odległy, albo abstrakcyjny dylemat, bo już dzisiaj spotykam się z pytaniami, czy to z agencji marketingowych czy software'owych, które mówią: klient zamawia u nas tworzenie określonego rodzaju treści. Nazwijmy je szeroko. I my wykupujemy sobie konto i licencje w jakimś narzędziu i teraz dostarczamy klientowi jakiś produkt czy jakąś usługę w oparciu o to co wygenerowaliśmy na tym koncie i teraz kim my jesteśmy. Czy my jesteśmy dostawcą w tym momencie jakiegoś rozwiązania AI-owego, czy też nie? Więc to są takie dylematy, które się pojawiają w praktyce. Najwięcej obowiązków, żeby nie powiedzieć - wszystkie - będą ciążyć na dostawcach. Tymi dostawcami jak najbardziej mogą być chociażby software house'y, które tworzą, rozwijają, utrzymują określone rozwiązania, ale nie muszą. Dostawcą może być też klient. W zależności od tego, co de facto jest stworzone i gdzie ten system sztucznej inteligencji będzie nam się plasował.

To jak już wiemy kim jesteśmy, jeżeli jesteśmy dostawcą, to teraz otwiera nam się cała, szeroka lista różnego typu obowiązków związanych z tym co robimy. Wiemy, że mamy system sztucznej inteligencji. No to patrzymy na skalę ryzyka przewidzianą, czy klasyfikację poziomów ryzyka przewidzianą w AI Akcie, bo w zależności od tego czy to co robimy łapie się na wysokie ryzyko, ograniczone ryzyko, minimalne ryzyko - to takie będziemy mieć też obowiązki. Zarówno te powiedzmy materialne dotyczące tego w jaki sposób mamy tworzyć to rozwiązanie, jak i dotyczące transparentności, dotyczące tworzenia dokumentacji, zakresu tej dokumentacji, oznaczania produktów i czysto biurokratycznych obowiązków, takich jak rejestracja chociażby w unijnej bazie.

Więc patrzymy, gdzie jesteśmy na tej skali ryzyka. Warto nie być w gronie systemów z artykułu 5. AI Act'u, czyli systemów zakazanych. Jeżeli jesteśmy to to jest dobry moment na to żeby coś zmodyfikować w założeniach, bo jeżeli produkt na dzisiaj wygląda na taki co mógłby być zakazany, bo na przykład umożliwia w jakiejś formie scoring społeczny. Nawet na małej, zamkniętej grupie scoring studentów pod kątem tego czy ściągają czy nie ściągają, to warto prześledzić sobie te założenia, bo mamy jeszcze 6 miesięcy na wyeliminowanie z rynku systemów, które ten poziom ryzyka mają nieakceptowalny w świetle regulacji. Jeżeli wychodzi nam, że mamy wysoki poziom ryzyka, bo na przykład dostarczamy albo mamy zamiar dostarczać jakiś software, który będzie usprawniał rekrutację, będzie wybierał, selekcjonował CV, to wchodzimy w tę grupę systemów wysokiego ryzyka i tych obowiązków będzie najwięcej. Jeżeli natomiast robimy Chatbot'a do sklepu internetowego, nie wiem z nasionami, albo z artykułami ogrodniczymi, gdzie jest ryzyko, że nasz użytkownik spotka się z jakimś naruszeniem, z jakimś działaniem mogącym ingerować w jakiekolwiek jego prawa jest niskie, to odpowiednio tego rodzaju system plasuje się gdzieś tam niziutko i tych obowiązków będzie zaledwie kilka. Przynajmniej wynikających z tego dzisiejszego brzmienia AI Act'u.

Czyli podsumowując: patrzymy gdzie jesteśmy w klasyfikacji ryzyka i płynnie przechodzimy do kolejnego punktu, czyli co się z tym wiąże, jakie mamy w związku z tym obowiązki. I o tym w zasadzie jest cały AI Act - o obowiązkach, obowiązkach, obowiązkach, przepis po przepisie, po prostu możemy całą matrycę w oparciu o te regulacje sobie stworzyć. I ostatnia kwestia, czyli rozplanowanie sobie dostosowania się do tej regulacji w czasie, bo to też nie jest tak, że wszystko trzeba zrobić od razu. Oczywiście takie jest formalne i biurokratyczne założenie, ale życie biegnie trochę inaczej. W związku z czym warto po prostu mieć świadomość, co jest dla nas krytyczne w tym momencie, które ryzyko jest, gdzie to ryzyko krytyczne się mieści i w pierwszej kolejności pozbyć się tego ryzyka, czy jakoś inaczej je zmitygować i później według planu dostosowywać kolejne warstwy tego co robimy do tych regulacji i to wszystko.

Piotr: Okej, to może przejdźmy do kwestii danych osobowych dostosowania do RODO, kluczowych kwestii i wymagań prawnych, jeżeli chodzi o przetwarzanie i zbieranie danych. I jakiś najlepszych praktyk w tym zakresie. Co twoim zdaniem jest najważniejszymi rzeczami, na które tutaj warto zwrócić uwagę?

Paula: Wbrew pozorom najlepszą praktyką nie jest wcale nieprzetwarzanie na siłę danych osobowych, to jest częsta obawa. W ogóle bardzo często rozmowa ze mną zaczyna się od takiego stwierdzenia, że tu robimy apkę, to to i tam, no i tam będą dane osobowe, tak jakby to było złe, że nie wolno, więc wolno. I w ogóle cała regulacja jest po to, żeby powiedzieć, jak wolno, a nie żeby powiedzieć czego nie wolno. I pierwsza podstawowa sprawa o której warto pamiętać - RODO nie zabrania w żaden sposób przetwarzania danych osobowych przez sztuczną inteligencję, przez narzędzia sztucznej inteligencji, modele. Jak je nazwiemy tak je nazwiemy, ale generalnie w ogóle nie ma tego rodzaju zakazu. Więc teraz skoro już wiemy, że nie ma zakazu, to poruszamy się w sferze co musimy zrobić żeby to było bezpieczne dla wszystkich. Pierwszą kwestią jest oczywiście informacja. Niezależnie od tego w jakim celu. Chociaż zakładamy, że on jest prawnie uzasadniony, a nie jakiś tam zupełnie z kosmosu. Zastanawiamy się, bierzemy pod lupę ten produkt, ten proces, który ma ten nasz produkt AI'owy wspierać. Jakich danych potrzebujemy i po co, czy też jakich danych potrzebuje klient i po co i co będzie z nimi robił? No i odpowiednio do tego osoby, których dane tam trafią niezależnie od tego czy mówimy o osobach w oparciu o których dane model ma zostać wytrenowany czy później mają po prostu na bieżąco być analizowane przez ten model, bo na przykład jest to model wewnętrzny w firmie, gdzie po prostu on stanowi taką super bazę wiedzy, która dodatkowo wspiera załóżmy pracowników w infolinii w jakichś działaniach, więc mniej więcej ma o nich jakieś też takie "personalne pojęcie". W związku z czym informujemy o tym, że w ogóle twoje dane się tam mogą znaleźć albo się znalazły.

Kolejną kwestią jest kwestia zgód. Bardzo często wydaje nam się, że na przetwarzanie danych osobowych trzeba mieć zgodę. Nie zawsze. Zgoda jest tylko jedną z kilku podstaw przetwarzania danych osobowych i chociaż te zgody są takie najbardziej nośne, żeby nie powiedzieć medialne to najrzadziej będą miały zastosowanie i to jest przestrzeń w której na dzisiaj pojawiają się różnice, jeżeli chodzi o dobre praktyki, o podejście różnych organów, bo są organy takie jak Europejski Inspektor Ochrony Danych, który powiedział w jednym ze swoich stanowisk, że trenowanie sztucznej inteligencji na rzeczywistych danych osobowych, nie wymaga zgody tych osób, ale wymaga informacji. Natomiast już pojawiają się decyzje innych organów na poziomie lokalnym, na poziomie krajowym, które mówią "Nie! Ma być zgoda i koniec". My tak wykładamy. Po pierwsze przepisy RODO, po drugie przepisy krajowe, że ta zgoda musi być i to będzie ten punkt, ten taki punkt wrażliwy w tego rodzaju projektach, gdzie będą się ścierały nam kwestie na przykład różnic w prawie poszczególnych państw z wykładnią po prostu RODO na poziomie unijnym i wreszcie też na poziomie międzynarodowym bo z czasem te praktyki będą adaptowane przez inne regulacje, które powstały na wzór RODO - jak chociażby kalifornijska ustawa o ochronie danych. W związku z czym ona też będzie absorbować z czasem te praktyki, które się pojawiają na gruncie RODO.

Czyli mamy informacje. Mamy zgodę. Trzecia kwestia to po prostu formalne zabezpieczenie tego procesu. Odpowiednie umowy, czy to pomiędzy software housem, a klientem, czy jeszcze pomiędzy innymi podmiotami. Tymi, które rzeczywiście biorą udział w całym tym procesie przetwarzania danych. I ostatnia rzecz to to, że szczególną uwagę należy zwracać na te procesy, na te działania, które opierają się na podejmowaniu jakichś decyzji szeroko rozumianych wobec konkretnych osób, bo one najczęściej będą jeszcze czymś obwarowane. Czasami są obwarowane jakimś dodatkowym obowiązkiem - na przykład uzyskania zgody. Czasami te dodatkowe regulacje przejawiają się tym, że można się z tą decyzją nie zgodzić i to ma jakieś swoje konsekwencje. W związku z czym, tam gdzie jest decyzja wobec jakiegoś indywidualnego człowieka, bo na przykład to jest system do wystawiania ocen uczniom w szkole, to tam te wymogi dotyczące procesu przetwarzania danych osobowych będą zawsze wyższe i ten standard oczekiwany od dostawcy, będzie wyższy.

Piotr: Okej, do kwestii decyzji i konsekwencji w tym zakresie jeszcze wrócimy. A powiedz mi, czy istnieją specyficzne regulacje dotyczące wykorzystania AI w branżach tego typu wrażliwych, jak medycyna, finanse, czy na przykład sektor publiczny?

Paula: Tak, istnieją i co ciekawe albo co może być ciekawe dla osób nie zajmujących się prawem na co dzień, to one istniały już długo. Długo przed AI Act'em i to są właśnie wszystkie te regulacje, które odwołują się w swojej treści do takiego enigmatycznego pojęcia, jak zautomatyzowane decyzje, albo zautomatyzowane podejmowanie decyzji. Na dzisiaj mamy takie przepisy w prawie bankowym, które określają, jakiego rodzaju zautomatyzowane decyzje i w oparciu o jaki katalog danych mogą być podejmowane, na przykład w procesie wnioskowania o kredyt. Mamy tego rodzaju przepisy w ustawie o działalności ubezpieczeniowej, gdzie jest mowa chociażby o rozpatrywaniu zgłoszeń szkód, przyznawaniu odszkodowania. Wiemy od lat, że czy proces scoringu czy proces szacowania ryzyka ubezpieczeniowego odbywa się ze wsparciem różnego rodzaju algorytmów, w tym tych, które mogą bazować na sztucznej inteligencji. Mamy na przykład przepisy, które nie dotyczą wprost wykorzystania sztucznej inteligencji, jako takiej, ale mają znaczenie dla branży. Na przykład jakiś czas temu rozważałam z klientami możliwość wykorzystania voicebot'a w aptece i jak wiele czynności dzisiaj farmaceuty pracującego w aptece mógłby wykonywać bot i wyszło nam, że jest ich niewiele. Praktycznie nie ma ich wcale. Dlatego, że przepisy prawa farmaceutycznego - nie jestem ekspertką, ale tam jest napisane w miarę prosto. Przepisy prawa farmaceutycznego wymagają, żeby np. leki były wydawane przez farmaceutę, który spełnia określone kryteria, więc ten proces automatyzacji jest mocno ograniczony. Tak samo nie mógłby wypisywać na przykład recept farmaceutycznych. W związku z czym, to są branże, gdzie rzeczywiście tego rodzaju regulacje są i najczęściej należy ich po pierwsze szukać pod hasłem zautomatyzowane decyzje. Po drugie, tam gdzie nie ma mowy o zautomatyzowanych decyzjach, a wiemy, że w tym procesie dzisiaj kluczowy jest człowiek - patrzymy na kryteria, czy ten człowiek, który wykonuje te czynności zgodnie z prawem musi mieć jakieś konkretne cechy, których nie możemy nadać chociażby voice botowi.

Piotr: A co w przypadku, jeżeli człowiek wspiera się, przypuśćmy lekarz wspiera się w diagnozie jakimiś narzędziami AI'owymi, podejmuje na podstawie czy analizy, czy wyrzuconych wyników jakąś decyzję i dochodzi do jakiegoś błędu przy diagnozie. Czy w jakikolwiek sposób narzędzia z których korzystał mogą być, powiedzmy pociągnięte, czy dostawcy narzędzi mogą być pociągnięci do odpowiedzialności, czy dana decyzja wtedy spoczywa na człowieku który ją podejmuje?

Paula: Odpowiedzialność za decyzję zawsze będzie podążała za tym lekarzem. Natomiast dostawca tego narzędzia może wobec lekarza, wobec przychodni, wobec NFZ'tu czy kogokolwiek sobie wyobrazimy w tym miejscu jako strona zawieranej z dostawcą umowy - może się zobowiązać do tego, że będzie ponosić odpowiedzialność za określone błędy, czy inne nieprawidłowości, które się pojawią. Natomiast w stosunku do pacjenta zawsze odpowiedzialny będzie lekarz, odpowiedzialna będzie placówka na takich zasadach, na jakich dzisiaj to funkcjonuje. Plus, jeżeli chodzi o możliwość tego rodzaju wsparcia dla lekarzy, znowu wymagałoby to dosyć indywidualnego podejścia. Chociażby z uwagi na zasady dotyczące przetwarzania danych dotyczących stanu zdrowia, tego takiego rygorystycznego planowania i świadomego układania tego kto do tych danych będzie miał dostęp, w jakim zakresie, jak zarządzać prawami pacjentów, czy na przykład... Bo na przykład intuicyjnie, moglibyśmy. Myślę, że w świetle przepisów jest w zupełności to uprawnione. Moglibyśmy stwierdzić, że ja się na przykład nie zgadzam, żeby podczas mojej wizyty lekarz, nie wiem dermatolog - wspierał się jakąś apką opartą o sztuczną inteligencję, bo ja nie chcę, żeby dostawca tej apki wiedział, że mam trądzik i po prostu mi to nie pasuje. I co wtedy? Czy jesteśmy w stanie tę lukę jakoś organizacyjnie wypełnić? Czy też nie? Bo na przykład lekarz musi z tego skorzystać, bo dzisiaj system wystawiania recept jest z tym powiązany. Więc nie da się wyłączyć tego elementu. Także te obszary będą się przenikać. Natomiast - żeby więcej nie drążyć wokół - natomiast odpowiedzialność na dzisiaj wobec pacjenta będzie ponosić lekarz, bąd placówka. Ewentualnie placówka mogłaby potem wtórnie dochodzić jakiejś odpowiedzialności od dostawcy, ale tylko wtedy, kiedy on się po prostu do tej odpowiedzialności będzie poczuwał i ona będzie jakoś usankcjonowana w umowie.

Piotr: A co w kwestii samej edukacji i używania narzędzi na przykład przez uczniów? No nie wiem, wykonując jakieś zadania domowe, czy wspierając się przy rozwiązywaniu, jakby jakiś klasówek, czegokolwiek, co podlega ocenianiu. Jakby wiemy, że do użytku takiego ogólnego trafiły narzędzia z których można korzystać, można się wspierać nimi. A czy są jakieś regulacje w tym zakresie, które powiedzmy jakoś by limitowały kwestie użycia tego typu narzędzi?

Paula: Nie. Może się to pewnie zadziać na poziomie szkoły, ale tutaj też byłabym ostrożna, bo szkoły w swoich statusach mają czasami takie bardzo zaborcze praktyki, jeżeli chodzi o wpływanie na to co robią uczniowie i w jaki sposób. Więc byłabym na poziomie tych szkolnych regulatorów dosyć ostrożna. Natomiast na poziomie takim ogólnym tego rodzaju regulacji nie ma.

Piotr: okej czyli jest high life.

Paula: If you say so.

Piotr: Płynnie przeszedłbym do kwestii umów, które zawieramy w kontekście właśnie tych wszystkich regulacji. Czyli na co powinniśmy zwrócić uwagę przy tym jak podpisujemy umowy z klientem, czy z jakimś partnerem. W jakich umowach powinniśmy zwrócić uwagę na kwestie dotykające rozwiązań AI, czy jakie kwestie powinniśmy zabezpieczyć?

Paula: To zaczynając od początku. Jak zaczynamy z kimś rozmawiać, to najczęściej ta rozmowa jest poprzedzona podpisaniem chociażby jakiejś NDA'ki, czy jakiegoś oświadczenia o zachowaniu poufności, czegoś co dotyczy tej kwestii. I tutaj są dwa aspekty. Po pierwsze jeżeli na przykład używamy do nagrywania spotkań, do robienia notatek, transkrypcji, jakiegoś narzędzia AI'owego, powinniśmy o tym napisać wprost. W tego rodzaju NDA'ce, albo to zakomunikować przed spotkaniem tak, żeby uczestnicy tego spotkania mogli świadomie się zgodzić bądź się nie zgodzić na udział w tego rodzaju wsparcia. Po drugie, jeżeli na przykład wykorzystujemy ChatGPT do pisania maili, albo przygotowywania ofert, to znowu to również powinno być zabezpieczone w NDA'ce i już nie chodzi nawet o to, że formalnie rzecz biorąc dopuszczenie jakiegoś podmiotu trzeciego do dostępu do jakiś informacji poufnych jest naruszeniem umowy i to jest złe. Tak jest, ale to jest w pewnym sensie taka dosyć abstrakcyjna i mocno sformalizowana perspektywa. W praktyce najczęściej dzieje się tak, że takie rzeczy wychodzą przy okazji. To znaczy klient nie był na żadnym odcinku rozmowy informowany o tym, że tego rodzaju akcje będą prowadzone, po czym pracownicy w rozmowie mówią, że ofertę sobie zrobiliśmy w ChatGPT coś tam i wtedy się okazuje, że nikt się na to nie umawiał, a NDA'ka była podpisana według starego wzoru i nagle jest kłopot. Więc pierwsza rzecz - umowa o zachowaniu poufności, przewidzenie przypadków w których te informacje poufne, które nam klient udostępnia mogą trafić do jakiegoś narzędzia.

Jeżeli chodzi już o współpracę przy tworzeniu produktu usługi czegoś, świadczenia, jakiejś usługi, no to tutaj tych aspektów jest kilka. Po pierwsze, umowa powinna odzwierciedlać to o czym mówiliśmy na samym początku, czyli kim kto jest w ogóle z punktu widzenia regulacji. Czy software house będzie dostawcą oprogramowania? Jaka jest odpowiedzialność deweloperów, bo AI Act w niektórych miejscach do deweloperów wprost się odwołuje. W związku z czym warto byłoby funkcjonalnie jakoś do tego podejść. Jakie obowiązki w związku z tym i na kim spoczywają w związku z charakterem tej współpracy? Kwestia istotna dla umów zawartych dzisiaj, to spotkałam się już kilka razy z takimi pytaniami ze strony software house'u: my zrobiliśmy dla klienta model. Ten model stanie się za chwilę produktem, albo już się stał produktem. No i my go zaczęliśmy tworzyć 2 lata temu, kiedy nikt o AI Akcie nie myślał poważnie. I teraz co zrobić, żeby klient nie mógł powiedzieć w razie jak się coś wysypie, że my jesteśmy zobowiązani do tego, żeby zapewnić mu produkt zgodny z AI Act'em, podczas gdy nikt tych kryteriów nie brał pod uwagę. Więc warto jakoś adresować te kwestie w umowach, czy zobowiązujemy się, że ten model, ten produkt będzie spełniać takie i takie wymogi czy też nie, albo dajemy klientowi możliwość wspólnego dostosowania się do tych wymogów - na przykład w ramach zlecenia przygotujemy jeszcze dokumentację techniczną, która będzie spełniała wymogi z AI Act'u. Czyli podsumowując jasno - mówimy kto kim jest w świetle tej nowej regulacji, jakie obowiązki w jaki sposób dzielimy, odpowiednio też adresujemy kwestie przetwarzania danych osobowych, co już powinno się dziać, ale tutaj z tym szczególnym uwzględnieniem jakiegoś ewentualnego zautomatyzowanego podejmowania decyzji. Dodałabym do tego jeszcze jeden ekstras, mianowicie wróciła na wokandę. Można powiedzieć w Unii Europejskiej dyrektywa dotycząca odpowiedzialności za sztuczną inteligencję i to jest dyrektywa, która dotyczy odpowiedzialności w sytuacjach pozaumownych. Czyli jeżeli nasz klient, na przykład dla którego zrobiliśmy AI'owy produkt, będzie sobie robił scoring swoich klientów, bo tak. Bo tak ułożył sobie teraz swój proces, ale jest operatorem telekomunikacyjnym i ma w tym całkiem uzasadniony prawnie cel, no to dobrze by było od razu w naszej umowie zaadresować te kwestie. Czyli do jakiego momentu my jako dostawca ponosimy odpowiedzialność i za co. A za co już nie myślę, że dobrze napisane umowy z klientami już dzisiaj mają solidne fundamenty, tam gdzie na przykład mówimy o odpowiedzialności za ataki, za jakieś działania osób trzecich, jak jest rozłożony ten ciężar, co gwarantujemy, jakiego rodzaju dostępność i wyjaśnialność, a jakiego poziomu nie. Nie ma np. obowiązku wynikającego z jakichś ogólnych przepisów prawa udostępniania klientowi promptów. Jeżeli korzystamy ze sztucznej inteligencji i tego rodzaju rzeczy, taki obowiązek może wynikać po prostu z ustaleń pomiędzy nami.

Piotr: Okej, ale wracając można powiedzieć do samej praktyki. Jeżeli mamy tak naprawdę otwarte już umowy z klientami, tworzymy dla nich powiedzmy software i to się dzieje już od nie wiem, kilku lat. W naszych procesach wprowadzamy użycie różnego typu narzędzi AI'owych i teraz rozumiem, że powinniśmy zaktualizować wszystkie umowy pod kątem poufności, pod kątem użycia tych narzędzi. To jest jedna rzecz, a jeszcze inną kwestią będzie to, że wskazując klientowi, że powiedzmy są dostawcy którym udostępniamy w jakikolwiek sposób dane, które są objęte poufnoścą, czy dane, które przetwarzamy w ramach tej współpracy, czy to nie otwiera takiej Puszki Pandory z klientem i czy to nie sięga głębiej? Na zasadzie przetworzenia tego w naszych procesach wewnętrznych, bo może nie powinniśmy właśnie tego typu danych udostępniać i tak naprawdę mieć to zaadresowane z naszą kancelarią na poziomie procesów i tego jak możemy do tego podejść? Ewentualnie, jeżeli wskazujemy to klientowi w umowie i klient do nas wraca i mówi, że on tego nie chce, jak powinniśmy się zachować w takiej sytuacji?

Paula: To jest dylemat z którym rzeczywiście mierzyłam się z wieloma firmami na początku ubiegłego roku, kiedy był ten pierwszy boom i hype na Gen AI i co trzeba pisać w umowie, czego nie trzeba, klient nam się przestraszy, już nie będzie chciał korzystać i jak do tego podejść? Więc myślę, że warto by było zacząć od przeglądu tych umów pod kątem ich elastyczności, jeżeli chodzi o tego rodzaju kwestie, bo bardzo często okazuje się, że umowy były na tyle ogólne - na przykład umowy ramowe, że to nie będzie Big Deal żeby teraz coś tutaj zmienić, albo żeby to uszczegółowić na poziomie maila. Na przykład, że: "Słuchajcie mamy teraz takie i takie procesy, które usprawniliśmy w ten i w ten sposób. Jeżeli jesteście ciekawi to coś tam i damy wam informacje na ten temat - co, jak, dlaczego i po co - i czasami są umowy w których na przykład wprost wyłączone są możliwości stosowania tego rodzaju narzędzi i wtedy wymaga to już przerobienia umowy. Jak do tego podejść tak zdroworozsądkowo, myślę, że trzeba takie krytyczne dla nas kwestie z punktu widzenia naszej odpowiedzialności na przykład, kwestie prawno-autorskie. Czyli po pierwsze ustalenie tego co jest utworem w naszym wspólnym rozumieniu. Czy na przykład jak wygeneruje kod i później go trochę zmodyfikuje, bo go dostosuje do potrzeby klienta, ale generalnie to będzie bazował na wygenerowanym kodzie... Czyli my już między sobą uznajemy, że to jest utwór czy też nie, więc takim punktem zapalnym na pewno będą prawa autorskie.

Z drugiej strony dane osobowe. Zwłaszcza tam, gdzie będą trafiały do jakiegoś narzędzia dane osobowe użytkowników, klientów naszego klienta, osób fizycznych jakichś, to to jest drugi obszar krytyczny. Trzeci, to właśnie ta odpowiedzialność za błędy, za za brak dostępności. Poziom szczegółowości na jaki godzimy się zejść w naszej komunikacji, to znaczy na jak bardzo szczegółowe informacje chcemy się zgodzić przekazywać klientowi. W praktyce jak działam z software house'ami, które chcą jakoś usankcjonować korzystanie z narzędzi sztucznej inteligencji, to robimy zazwyczaj dwie rzeczy. Pierwsza jest taka, że tworzymy wewnętrzne polityki dotyczące korzystania z tego rodzaju narzędzi. Dlaczego? Dlatego że to umożliwia zapanowanie nad chaosem. Po pierwsze wszyscy wiemy z czego można nam korzystać, a z czego nie. Narzędzi jest mnóstwo. Różnego rodzaju GPTsy powstają w masowej liczbie każdego dnia i część z nich w ogóle nie zasługuje na jakiekolwiek zaufanie. Nie tylko dlatego, że dają słabe rezultaty, ale po prostu służą do wyciągania danych. Na przykład w związku z czym robimy jakiś odsiew. Korzystamy z tego, co jest nam naprawdę potrzebne. Tworzymy sobie jakąś listę i tworzymy sobie wewnętrzne zasady, że na przykład korzystamy tylko z konta firmowego, to powoduje, że mamy licencje na wykorzystanie tych treści komercyjnie.

Nie każdy dostawca narzędzia daje nam takie uprawnienia na zwykłym koncie konsumenckim. Po trzecie zarządzamy zakresem danych, czy informacji poufnych naszych i naszych klientów, które mogą tam trafiać i teraz mając już taką nawet ramową politykę wewnętrzną, jesteśmy w stanie bardzo łatwo sprostać praktycznie każdemu pytaniu klienta dotyczącego tego, co się dzieje. I ta polityka może mieć odbicie. Po pierwsze w umowie z klientem, gdzie klientowi na przykład wskazujemy wprost, że w procesach takich i takich korzystamy z narzędzi Gen AI. Nie musimy ich wskazywać nawet z nazwy, ale wskażemy chociaż proces na jakim odcinku w ogóle pojawia się tego rodzaju narzędzie w układance. Po drugie odbiciem tej polityki powinny być też umowy z naszymi podwykonawcami, czy pracownikami, gdzie na przykład wprost nasz podwykonawca zobowiązuje się do stosowania się do tych zasad, a nie do robienia sobie częściowo czegoś na swoim własnym koncie, a częściowo na naszym. Już nie tylko ze względu na ochronę informacji poufnych, ale chociażby na to, że większość dostawców najpopularniejszych narzędzi Gen AI pisze wprost, że w dowolnym momencie mogą ci wszystkie rzeczy z konta zniknąć. Więc chociażby pod kątem backupu. Po co mamy później odrabiać coś, co już było na jakimś jego prywatnym koncie? To są problemy, które istnieją od wielu lat tylko po prostu w innych narzędziach i nie warto o nich zapominać, także w tym kontekście.

Piotr: Okej, a powiedz, miałaś taką sytuację, gdzie klient jest negatywnie nastawiony do AI i przy tego typu zmianach, czy propozycjach zmian stwierdza, że on się nie chce na to godzić i chce rozwiązać w takim wypadku umowę?

Paula: Sytuacje w których się nie zgadzał tak, do rozwiązania umowy ostatecznie nie doszło. Natomiast dużo częściej spotykam opór ze strony tego kto stosuje przed informowaniem niż w drugą stronę. Klienci zazwyczaj się na to godzą. Czasami właśnie próbują sobie zabezpieczyć prawa do informacji na bardzo głębokim poziomie szczegółowości i to może być kłopot, bo po pierwsze to może być po prostu uciążliwe odpowiadanie na tego rodzaju pytania - zwłaszcza zadawane przez osobę, która nie porusza się zbyt płynnie w tego rodzaju kwestiach, po drugie może generować realną jakąś pracę do wykonania i zdarza się że na przykład firmy dodatkowo charge'ują klientów za przygotowanie określonego rodzaju informacji. W niektórych przypadkach klient będzie musiał taką informację móc wyciągnąć, bo na przykład będzie dostawcą systemu wysokiego ryzyka i musi mieć logi zawsze aktualne i tak dalej. W związku z czym musi mieć określony pakiet informacji zawsze dostępny od swojego software house'u. To na co najczęściej się nie zgadzają klienci dotyczy etapu jeszcze przed zawarciem umowy, czyli właśnie tego poziomu NDA'ki, nagrywania spotkań i tego rodzaju rzeczy. To tak z mojej perspektywy już jest pierwszy taki odsiew.

W drugim etapie, gdy już współpraca jest nawiązywana raczej nie. Raczej większą taką niepewność widzę właśnie wśród agencji, czy firm które nie wiedzą jak bardzo muszą się przyznać do tego, że z czegoś korzystają i w zasadzie w praktyce, jeżeli miałabym wskazać na jakieś problemy, czy fuck-up'y, to najczęściej dotyczą sytuacji w której ktoś skorzystał z jakiegoś narzędzia Gen AI i najprawdopodobniej zaufał mu za bardzo na jakimś poziomie, klient był niezadowolony, bo to co dostał nie nadaje się do użytku i nagle się okazuje, że przecież myśmy myśleli, że to człowiek będzie dla nas robił, a to dostaliśmy wygenerowane.

Piotr: Czy to nie otwiera furtki dla klienta do powiedzmy negocjacji, takich błędnych, jeżeli chodzi o negocjacje stawki czy nawet tych prac, które są wykonywane? No bo stwierdza "No dobra, no jakby część pracy wykonuje dla mnie AI, to dlaczego ja mam tak naprawdę za tą część pracy, która jest wykonywana automatycznie, której wy nie robicie - płacić i czy jakby tego typu zabezpieczenia prawne nie powodują różnych komplikacji biznesowych?

Paula: Nie spotkałam się z nimi na jakąś szerszą skalę. Poza tym warto pamiętać, żeshit in, shit out. To nie jest tak, że sztuczna inteligencja uczyni nas teraz bogami programowania, jeżeli nic nie potrafiliśmy. Płacimy nadal za kompetencje, za kompetencje obchodzenia się z narzędziami również. W związku z czym to są argumenty, które pewnie się pojawiają gdzieniegdzie, ale znowu nie są to argumenty nie do zbicia, tylko w ogóle już nawet nie w płaszczyźnie prawnej, ale czysto biznesowej argumentacji, że na przykład dzięki temu możemy zrobić ci więcej, a rozliczamy się time and materials.

Piotr: Okej, tym sposobem przeszliśmy płynnie do kwestii błędów i jakiś tam problemów, które jakby napotykamy przy tego typu regulacjach. Czy masz jeszcze w głowie jakieś problemy, czy fuckup'y, które można popełnić przy obsłudze klienta pod kątem nawet procesowym, czy nawet tworzenia dla niego narzędzi AI i wrzucania tego typu rzeczy do umów, czy regulowania ich w jakikolwiek sposób prawny?

Paula: Myślę że tutaj nie będzie to dużym zaskoczeniem jak powiem, że najczęściej kuleje po prostu określenie zakresu obowiązków jednej i drugiej strony, a zwłaszcza tego usługodawcy, co on konkretnie ma zrobić i za co konkretnie jest odpowiedzialny. I druga rzecz, która bardzo boli moje serduszko za każdym razem to to że w 80. % umów nie pada ani razu słowo bezpieczeństwo. Dlaczego nikt nie myśli o tym? Wszyscy mówią, że to będzie takie ładne, będzie takie efektywne i w ani jednym miejscu nie pojawia się nawet zalążek gwarancji, że to będzie bezpieczne, albo słaba jakość informacji ze strony podwykonawców. To jest klasyk. Zadaję pytanie na czym model został wytrenowany? Na danych publicznych. Czyli na czym? Co to są dane publiczne?

Piotr: Okej, a jeżeli chodzi o kwestie właśnie odpowiedzialności i tutaj wracamy płynnie do kwestii decyzji podejmowanych przez narzędzia AI. Jak tutaj jest przerzucane czy balansowane, jeżeli chodzi o ciężar odpowiedzialności? Kiedy to, nie wiem, dostawca jest odpowiedzialny za podejmowanie decyzji? Właśnie znowu wracam do kontekstu, gdzie człowiek trochę podejmuje decyzję na bazie narzędzi AI'owych, a z jeszcze innej strony gdzie tak naprawdę klient nawet nie wie kto podejmował decyzję, jak on może się w ogóle w tym rozeznać, czy upewnić, czy ta decyzja została podjęta w określony sposób?

Paula: Generalnie te problemy o których mówisz to nie są problemy z mojej perspektywy specyficzne dla kwestii AI'owych, bo AI jest po prostu katalizatorem takich problemów, które już istniały na wcześniejszym etapie i technologia po prostu wymusza teraz bardziej uporządkowanie tej kwestii. Jeżeli chodzi o zakres odpowiedzialności w umowie, no to mówiąc brutalnie: kreuje go ten, kto ma większą siłę negocjacyjną i lepszą pozycję, bo zasady prawa cywilnego na sam koniec są bardzo plastyczne. Są bardzo wąsko określone przypadki, kiedy naszej odpowiedzialności wyłączyć się nie da, a reszta jest już trochę kwestią tych wzajemnych negocjacji. W związku z czym tutaj dużo może się zadziać, ważne żeby to uwzględniało też po pierwsze specyfikę danego narzędzia, co ono właściwie ma robić, do kogo będzie adresowane. Jeżeli na przykład to ma być narzędzie, które ma umożliwiać generowanie avatarów przez dzieci, to poziom zabezpieczeń powinien być wyższy. Poziom jakiś dodatkowych wymogów chociażby dotyczących cenzury, czy filtrów wprowadzanych przez dostawcę i ich aktualizacji, na przykład jeżeli chodzi o naruszenia własności intelektualnej. Jeżeli produkty umożliwiały tego rodzaju działania, to znowu określenie pomiędzy sobą, czy za wprowadzanie jakiejś cenzury i na jakim poziomie odpowiada software house, czy może klient, który sam będzie jeszcze własnymi siłami to robił. No to nawet nie trzeba tutaj odwoływać się do jakichś bardzo abstrakcyjnych przykładów. Wystarczy, że zaadaptujemy sobie Midjourney i będziemy sami nakładać różne filtry. W związku z czym, jeżeli współpracujemy z kimś jeszcze, to warto opisać realnie jak wygląda ten podział ról. Jeżeli software house nie będzie miał dostępu do danych osobowych prawdziwych, takich nie zanonimizowanych i produkcyjnych, to nie zawierajmy na wyrost umowy powierzenia, bo może kiedyś będzie miał, bo w praktyce zdarzają się takie sytuacje, gdzie później do software house'ów wpływają roszczenia dotyczące danych, których software house nigdy na oczy nie widział, ale umowa była podpisana. Teraz się zmienił inspektor, więc trzeba się z tego wytłumaczyć. Także dobrze, żeby po prostu te umowy odzwierciedlały realny podział ról, realne dostępy i realny wpływ na to, jak się narzędzie zachowuje, bo może być tak, że produkt jest budowany w oparciu o gotowe klocki, klocki dostarczane z zewnątrz i to nie jest nic złego, ale w takim razie nie bierzmy odpowiedzialności na wyrost za wszystko, której nie jesteśmy w stanie dowieść, bo w razie awarii ChatGPT nagle wszystkie autorskie narzędzia padają i pojawia się kłopot, bo mamy SLA, które nas zobowiązuje do naprawy błędów w trzy godziny.

Piotr: Okej. A czy takie wyłączanie znowu odpowiedzialności nie pakuje nas w wir kolejnych problemów, bo wskazujemy tak naprawdę wzrok klienta na tą kwestię i to, że ta kwestia może być w jakikolwiek sposób sporna, czy że my chcemy się pozbyć tej odpowiedzialności?

Paula: No tak, chcemy. 😊

Piotr: Zwykle będziemy chcieli tylko, że właśnie to znowu może triggerować klienta.

Paula: Może, dlatego on powinien być świadomy, jak realnie wygląda ten proces i doinformowany na sam koniec przez software house na czym to polega - budowanie narzędzia, za co realnie jesteśmy w stanie wziąć odpowiedzialność, a za co nie, bo często jest tak i to jest często problem też prawników klientów. Prawnik jak przychodzi do tej umowy to on ma jeden cel - zabezpieczyć wszystko co się da, przenosić prawa autorskie, dostępność, zabezpieczyć wszelkie możliwe roszczenia. Nie zawsze jest to sensowne i nie zawsze jest to możliwe, bo jeżeli korzystamy z jakichś gotowych klocków, to software house też nie ma praw autorskich. Ma tylko jakąś licencję w ramach której się porusza i jak klient chce później na przykład w oparciu o ten produkt tworzyć swój SaaS to też musi te licencje znać. Więc w gruncie rzeczy zamykamy się w takim pojęciu budowania trochę świadomości, edukacji i takiego partnerstwa w tego rodzaju projektach, a umowa jest wtórna wobec tego, co wydyskutujemy jako ten obszar naszej współpracy tak realnie i budowanie świadomości dotyczącej tego, co tak naprawdę robimy. To akurat jest podchwytliwe, dlatego, że czasami software house'y nie chcą żeby klient dużo rozumiał. Oni tam obiecują różne magiczne rzeczy, one będą tak same robić, albo będzie voicebot i będzie odpowiadał na pytania ładnym kobiecym głosem i my nie chcemy wcale się jakoś bardzo tłumaczyć nawet, jeżeli potencjalnie będzie dużo tych błędów, więc to jest taki obszar myślę dosyć indywidualnej oceny na sam koniec.

Piotr: Okej, jakby dotknęliśmy trochę sporów i kwestii własności intelektualnej, alejakbyśmy mogli można powiedzieć połączyć te dwa tematy i skierować się w kierunku mechanizmów, które będą nas zabezpieczały przed takimi sporami już trochę mówiłaś o tym, żeby wskazywać co tak naprawdę, w jakim momencie jest utworem i żeby zdefiniować sobie to z klientem, czy istnieją jeszcze jakieś mechanizmy, które będą zabezpieczały nas przed ewentualnymi niesnaskami, gdzie klient będzie chciał dochodzić jakichś roszczeń w tym zakresie.

Paula: Poza tym klasyfikowaniem tego, co jest utworem, co utworem nie jest, warto żeby klient miał świadomość tego, jakiego rodzaju licencje obowiązują go jako pośrednio użytkownika określonych klocków. Po trzecie kwestia znowu dosyć uniwersalna, czyli jakieś zabezpieczenia pokrywania, spełnienia roszczeń jakichś osób trzecich, które mogą się pojawić w związku z wykorzystaniem z naruszeniem w ich ocenie ich praw autorskich, jeżeli chodzi o Gen AI to tutaj bardziej myślę z punktu widzenia tworzenia software'u, to może nie jest bardzo istotne ryzyko. Chociaż Copilot github'owy ma proces o naruszenie praw autorskich, bo korzystał z Open source'owych bibliotek. Rzekomo do generowania kodów z naruszeniem warunków licencji. Proces jest w toku więc jeszcze nie wiemy jak to zostanie rozsądzone. Natomiast bardziej jest to widoczny problem przy tworzeniu grafik, przy tworzeniu content'u innego niż chociażby kody, gdzie po pierwsze istnieje szansa, że ta sama grafika zostanie wykorzystana przez kogoś jeszcze, kto mógł ją wygenerować niezależnie, po drugie mógł ją pozyskać, bo po prostu część z tych grafik, które są generowane przez nas, jest też dostępna dla innych użytkowników i tutaj pojawiają się jakieś roszczenia, czy wątpliwości. Dlatego na sam koniec z perspektywy software house'u musimy postawić granice tam gdzie realnie już nie mamy wpływu na to, jak użytkownik wykorzysta te treści i czy na przykład zweryfikował, czy może ich użyć w określonym kontekście, bo co z tego że na przykład możemy wygenerować reklamę wódki? Możemy, ale w Polsce mamy przepisy zabraniające reklamy mocnych alkoholi i to że nam zostanie wygenerowane to jedno albo dwa, to użytkownik, czy agencja, czy klient powinni wiedzieć, kiedy mogą użyć tego rodzaju grafiki, że na przykład tylko na zamkniętym evencie a nie na billboardzie.

Piotr: Okej spory sporami, mamy nowe regulacje prawne więc pojawiają się też kontrole i audyty. Jakbyś mogła powiedzieć coś w tym zakresie. Czyli tak naprawdę jakie kontrole mogą nam, że tak powiem zagrażać jako przedsiębiorcom, a z drugiej strony, jak się na nie przygotować?

Paula: Przeróżne kontrole organów, które mogą kontrolować różne rzeczy jest całe mnóstwo. Począwszy od UOKiKu, przez Urząd Ochrony Danych, który może jeszcze sprawdzać wymogi z Digital Services, to jeszcze nie wiadomo kto w Polsce będzie się tym zajmować do końca przez KNF. Jeżeli działamy na rynku finansowym, inspekcję handlową i kogo tam jeszcze nie znajdziemy, więc tych organów, które mogą pośrednio pytać nas o rzeczy związane z wykorzystaniem sztucznej inteligencji jest całkiem sporo.

Jak się przygotować w kontekście AI Act'u? W zasadzie moglibyśmy się cofnąć do pierwszego pytania. Zmapujmy sobie te nasze wymogi, także te formalne i opracowujmy sukcesywnie te dokumentacje. Dokumentację robimy nie tylko po to, żeby ją mieć i żeby ją pokazać, że ona istnieje. Chociaż to też jest walor w biurokratycznym systemie prawnym, ale jak już ją robimy i chcemy ją robić z sensem to ona jest po to, żeby była naszą polisą. Jak ktoś nas zapyta "a dlaczego", bo może się okazać, że odpowiedź na pytanie "dlaczego" w 2024 roku brzmi zupełnie inaczej niż w 2026, kiedy przyjdzie kontrola i powie. ale teraz się już tak nie robi, ale wtedy się tak robiło. I tu mamy całe uzasadnienie, dlaczego to było zgodne. Dopiero formują się unijne instytucje, które będą formułować konkretne wytyczne, czym możemy się na dzisiaj kierować oprócz treści AI Act'u. Na pewno normami ISO i to przede wszystkim ISO 42001, czyli to dotyczące zarządzania systemami sztucznej inteligencji. Ono w dużej mierze pokrywa potrzeby, czy wymogi AI Act'u. Jeżeli chodzi o analizę ryzyka, o mapowanie procesów, o zarządzanie jakością, która też jest takim istotnym punktem AI Act'u. Po drugie tworzą się inne frameworki organizacji zajmujących się, a to cyberbezpieczeństwem, a to ochroną danych osobowych, które będą budowały standardy dotyczące tego, jak rozwijać tego rodzaju produkty. Na przykład mamy dyrektywę Digital Single Market, która daje możliwość zbierania utworów i wykorzystywania ich do trenowania sztucznej inteligencji i ona określa wyjątki od możliwości korzystania z publicznie dostępnych utworów, bez licencji i ona zawiera w sobie jakiś taki już pierwiastek technicznych wymogów, bo na przykład utwór co do którego twórca nie zgadza się, żeby był zeskrapowany, musi mieć oświadczenie w formie możliwej do odczytania przez boty. I teraz praktyka będzie wykształcać znaczenie tego pojęcia, co to znaczy w formie możliwej do odczytania przez boty. Co tam ma być konkretnie? Więc te wymogi techniczne będą się dopiero kształtować. Na dzisiaj bym powiedziała tak: AI Act i lista dokumentów, która z tego wynika, czy też procedur i kompetencji, bo na sam koniec mamy w AI Akcie chociażby obowiązek zapewnienia udziału człowieka w procesach prowadzonych przez systemy sztucznej inteligencji wysokiego ryzyka, co to dla nas w naszej organizacji oznacza ten human oversight, biorąc pod uwagę naszą specyfikę. A po drugie normy ISO-wskie, są dobrym wsparciem, bo też mają taki charakter bardziej techniczny niż etyczny. AI Act miesza w sobie kwestie prawne i etyczne na dosyć wysokim poziomie, więc mogą być łatwiejsze do zaadaptowania w organizacji, jaką jest software house i te dwie rzeczy plus praktyka dotycząca chociażby danych osobowych myślę, że jest już bardzo bardzo sensowną bazą.

Piotr: Okej, sam AI Act obowiązuje w Unii Europejskiej i jeżeli spojrzeliśmy na rynki takie jak np. USA, Chiny. Czy istnieją różnice w ogólnie podejściu legislacyjnym? Jeżeli tak, to jakie te główne różnice występują i czy na przykład AI Act ma impact bezpośredni na USA czy Chiny?

Paula: Różnice istnieją. Po pierwsze, pierwsza różnica jest taka, że AI Act jest kompleksową regulacją komercyjnego tworzenia, wykorzystywania, wdrażania i tak dalej systemów sztucznej inteligencji. Regulacje w innych państwach, czy na innych rynkach, zazwyczaj dotyczą jakiegoś wycinka działalności, czy to komercyjnej, czy działalności agencji rządowych. Więc nie ma drugiego takiego aktu prawnego, który by stwierdził, że wszystko co się da od początku, od projektowania do monitorowania i dalszego rozwoju obejmujemy jedną regulacją. To jest pierwsza różnica. Druga różnica - my się skupiliśmy na regulacji. Ta regulacja AI Act'u jest nakierowana na człowieka, na osobę fizyczną z której danymi, z której wizerunkiem, czy z której jestestwem. Jak mówimy na przykład o jakimś systemie scoringu czy rozpoznawania twarzy, czy predykcji kryminalnej z naszym jestestwem coś się dzieje w kontekście sztucznej inteligencji i teraz wyznaczamy ramy w jakich to może się dziać. W innych państwach jest tak, że czasami, że te regulacje dotyczą na przykład są. Po pierwsze nie mają charakteru generalnego na przykład, są to w USA executive orders, które dotyczą chociażby działalności agencji rządowych względem obywateli. Czyli nie kładziemy nacisku na to, jak przedsiębiorcy mają się zachowywać w stosunku do danych konsumentów osób fizycznych, jak się ma zachowywać rząd w stosunku do swoich obywateli, natomiast AI Act tak czy inaczej został zaprogramowany z myślą żeby stać się międzynarodowym standardem, taką ma ambicję podobnie jak RODO i dlaczego? Dlatego że AI Act nie obowiązuje tylko firm, które mają siedzibę w Unii Europejskiej, obowiązuje wszystkie firmy, które dostarczają swoje usługi na rynek unijny, których wynik działania systemów sztucznej inteligencji dostarczanych przez te podmioty jest tutaj zauważalny. Tutaj się coś dzieje. Jakiś następuje wynik, jakiejś operacji, czyli na przykład, jeżeli mamy system, który daje nam rekomendacje w oparciu o dane konsumentów z Chin. Nie mam pojęcia komu by to było użyteczne, ale załóżmy, że tak jest, on też może być objęty tymi przepisami, bo tutaj bierzemy te wyniki i tutaj coś się z tymi wynikami dzieje, czyli ucieczka ze spółeczką w Delaware to niekoniecznie, jeżeli klienci tej spółeczki będą mieli tutaj swoich klientów. To jest pierwsza kwestia. Druga kwestia. AI Act ma z założenia budować międzynarodowy standard, na przykład dotyczący ochrony własności intelektualnej, bo zawiera w sobie postanowienia. Co prawda są to motywy, a nie przepisy z których wynikałby jakiś konkretny obowiązek sformułowania jakiegoś dokumentu, czy umowy - zawiera w sobie postanowienia zgodnie z którymi modele mają być trenowane zgodnie z zasadami prawa autorskiego unijnego, nawet jeżeli pochodzą z jakiejś innej jurysdykcji. To jeżeli chcą być legalnie tutaj rozwijane i dostarczane jako narzędzia, czy też produkt to mają być zgodne z unijnym prawem własności intelektualnej, więc to są te ambicje analogiczne zupełnie do tego co było w RODO. Zobaczymy na ile one się gdzieś ziszczą. RODO doczekało się różnych adaptacji na różnych rynkach, na przykład wspominana ta kalifornijska regulacja, która w dużej mierze kopiuje postanowienia RODOwskie. Zobaczymy, czy z AI Act'em będzie podobnie. Obawiam się że nie, znaczy obawiam się w sumie się nie obawiam. Myślę, że nie. Z tego względu że AI Act jest przeładowany formalnościami w przeciwieństwie do RODO i nie widzę specjalnie powodu dla którego inne systemy prawne miałyby adaptować aż tak daleko idące formalne obowiązki budując chociażby swoją przewagę konkurencyjną.

Piotr: Okej, ma to sens. To było ostatnie moje pytanie z całej tej puli AI-owych zagwozdek prawnych. Moja wiedza została niesamowicie pogłębiona, więc pozostaje mi tylko Tobie podziękować za tą burzliwą rozmowę.

Paula: Przygodę.

Piotr: Przygodę prawną.

Paula: Tak jest. Dziękuję bardzo.

Piotr: 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

Jeśli chcesz zobaczyć wersję video, kliknij poniżej:

Jesteśmy też na Spotify!

Jesteśmy też na Apple Podcasts!

FAQ