Pytanie, które dotąd brzmiało akademicko, robi się operacyjne. Gdy prawnik użył AI do napisania pisma i wkradł się błąd, odpowiedzialność jest jasna: odpowiada prawnik, bo to on podpisał. Ale agent AI to inny gatunek narzędzia. Działa autonomicznie, sam podejmuje decyzje, sam wykonuje czynności, czasem odbiega od instrukcji w sposób, którego nikt nie przewidział. Gdy taki agent wyrządzi szkodę osobie trzeciej, pytanie "kto odpowiada" przestaje mieć oczywistą odpowiedź.

IMDA, singapurski regulator mediów i technologii, zebrał ponad dwudziestu prawników i przez kilka miesięcy szukał tej odpowiedzi w prawie cywilnym. Dokument jest dyskusyjny, nie normatywny: nie ustanawia reguł, mapuje teren. I właśnie dlatego jest cenny. Pokazuje, gdzie istniejące prawo prywatne radzi sobie z agentami AI, gdzie się napina, a gdzie po prostu pęka. Czyta się go jak notatkę z narady, na której mądrzy ludzie mówią wprost, czego jeszcze nie wiedzą.

O czym jest ten materiał

Trzy cechy agentowej AI, które według grupy decydują o odpowiedzialności, to autonomia, podejmowanie decyzji i wykonywanie czynności. Agent, który działa z ograniczonym udziałem człowieka, rozprasza odpowiedzialność za skutek, zwiększa ryzyko zachowania rozbieżnego z intencją i, dzięki szerszej przestrzeni działania, podnosi skalę możliwej szkody. Do tego dochodzi liczba aktorów: model, narzędzia, system, wdrożenie, użytkownik. Odpowiedzialność trzeba jakoś rozłożyć między nimi.

Grupa wskazała cztery wartości, które normalnie sterują tym, na kogo nakładamy odpowiedzialność: przypisanie winy (odpowiada ten, kto miał obowiązek staranności i go naruszył), kompensacja (poszkodowany ma być przywrócony do stanu sprzed szkody), odstraszanie (konsekwencje zniechęcają do nieostrożności) i innowacja (zbyt twarda regulacja może ją zdławić). Problem w tym, że przy agentach AI te cztery wartości trudno pogodzić, bo zawodzą u podstaw dwa mechanizmy, na których stoją.

Pierwszy zawód to atrybucja. Nawet gdyby udało się ustalić wszystkie fakty, może nie być jasne, kto zawinił i w jakiej proporcji. A często samych faktów nie da się ustalić, bo to za drogie, za wolne albo zasłonięte tajemnicą handlową dostawcy. Drugi zawód to autonomia połączona z nieprzejrzystością: gdy agent odbiega od instrukcji w nieoczekiwany sposób, a jego rozumowania nie da się odtworzyć ani wyjaśnić, trudno powiązać jego czyn z konkretnym człowiekiem. To nie jest problem złej woli. To problem konstrukcji.

Recenzja właściwa

Hipoteza, która robi całą robotę

Siłą dokumentu jest jeden dobrze dobrany przykład. Firma Y udostępnia agenta typu computer use jako osobistego asystenta. Regulamin mówi: wolno używać go do codziennych spraw, nie wolno do działań nielegalnych, użytkownik odpowiada za działania agenta, który czasem robi rzeczy nieoczekiwane. Alice korzysta z agenta na co dzień. Daje mu dostęp do swoich danych (imię, telefon, karta z limitem), trzymanych w chmurze dostawcy Z, i dokłada zabezpieczenie w prompcie: pytaj o zgodę przed działaniami wrażliwymi albo o dużym wpływie, na przykład przed zakupem.

Pewnej nocy Alice każe agentowi zapisać ją na popularny kurs, którego rejestracja otwiera się o północy. W tym momencie chmura Z jest niedostępna z powodu planowanej przerwy. Agent, żeby zdobyć dane Alice, włamuje się na serwery Z. Udaje mu się, mimo standardowych zabezpieczeń. Z ponosi stratę z przestoju, a przy okazji agent przypadkiem upublicznia cudze dokumenty, dane osób trzecich wyciekają, część z nich pada ofiarą kradzieży tożsamości. Z chain-of-thought agenta wynika, że uznał to za działanie o dużym wpływie i normalnie spytałby Alice, ale ocenił, że śpiącej nie dobudzi, a miejsca się kończą. Z i osoby trzecie żądają odszkodowania.

Hipoteza jest celowo skonstruowana tak, by zaboleć: wszyscy zachowali się rozsądnie. Firma ostrzegła, Alice dodała zabezpieczenie, Z miał standardową ochronę. A szkoda i tak powstała, bo agent zrobił coś, czego nikt nie zaplanował. To jest właśnie ten przypadek, w którym intuicja "winny jest ten, kto zawinił" nie ma do kogo przylgnąć.

Gdzie pęka istniejące prawo

Większość grupy uznała, że wiele spraw da się rozwiązać istniejącym common law: kontraktem i deliktem niedbalstwa, choć prawo trzeba będzie dostosować. Ale każdy z tych mechanizmów ma słaby punkt.

Kontrakt świetnie rozkłada ryzyko między stronami, które go podpisały. Problem to privity, czyli względność zobowiązania: umowa wiąże tylko strony, więc osoba trzecia poszkodowana przez agenta (jak Z czy ofiary wycieku) z reguły nie skorzysta z postanowień uzgodnionych przez innych. W polskim prawie to ta sama zasada (art. 353 i nast. KC): umowa między firmą Y a Alice nie ochroni osoby, która ucierpiała z boku.

Delikt niedbalstwa (u nas czyn niedozwolony, art. 415 KC) wymaga obowiązku staranności, jego naruszenia, związku przyczynowego i niezbyt odległej szkody. Każdy z tych elementów się napina. Bliskość prawna może wykluczyć obowiązek wobec osoby tak odległej jak Z. Standard staranności jest niejasny: co dokładnie musiał zrobić model developer, dostawca narzędzi, dostawca systemu i użytkownik, żeby go dochować. Związek przyczynowy jest najtrudniejszy, bo zachowanie agenta to splot treningu modelu, projektu systemu i promptu Alice, a chain-of-thought nie jest ludzkim rozumowaniem i jako dowód przyczyny jest wątpliwy. Nawet gdyby przyczynę ustalić, rozłożenie odpowiedzialności między aktorów pozostaje problemem. A na końcu czeka remoteness: szkoda jest naprawialna, jeśli jej rodzaj był rozsądnie przewidywalny, a tu cały kłopot polega na tym, że agent zadziałał nieprzewidywalnie.

Konkluzja grupy o reżimie winy jest niewygodna: nawet gdy wszyscy dochowali staranności, agent może wyrządzić szkodę w sposób, którego nikt nie przewidział. Pozostaje pytanie, kto ma ponieść ryzyko takich nieprzewidywalnych działań.

Wina czy ryzyko

Stąd druga droga: odpowiedzialność na zasadzie ryzyka (strict liability), niezależna od winy, znana z odpowiedzialności za produkt i działalności szczególnie niebezpiecznej. W tym modelu model developer, dostawca systemu i wdrażający mogliby z góry dzielić odpowiedzialność, a poszkodowany pozywałby któregokolwiek z nich, z rozliczeniem między nimi w drugim kroku. Zaleta jest realna: zdejmuje z ofiary i użytkownika ciężar dowodzenia, kto zawinił w nieprzejrzystym łańcuchu treningu, projektu i wdrożenia.

Wady też. Po pierwsze, odpowiedzialność bez granic: tradycyjnie ryzyko nakładano na zamknięte, dające się określić kategorie szkód, a agent o otwartej przestrzeni działania takiej granicy nie ma. Po drugie, pokusa nadużycia: zdjęcie odpowiedzialności z użytkownika może go rozzuchwalić. Grupa rozważa rozwiązania pośrednie: ograniczyć ryzyko kwotowo, zawęzić je przez bliskość (odpowiedzialność jeden krok albo dwa kroki w łańcuchu), objąć nim tylko relacje biznes-konsument, albo zamiast pełnego ryzyka przerzucić ciężar dowodu. Polskiemu czytelnikowi to znajome: art. 435 i 436 KC (odpowiedzialność na zasadzie ryzyka) oraz reżim odpowiedzialności za produkt niebezpieczny pokazują, że prawo umie nakładać ryzyko, ale zawsze na rzecz dobrze obrysowaną.

Łańcuch wartości i rozmycie odpowiedzialności

Najtrwalszy wniosek dokumentu dotyczy łańcucha wartości. Im dalej w łańcuchu, tym inna wiedza i inna kontrola. Model developer kształtuje bazowe zdolności i właściwości bezpieczeństwa, ale nie wie, jak agent zostanie ostatecznie użyty. Wdrażający i użytkownik znają konkretny przypadek użycia, ale mają coraz mniejszy wpływ na to, co model zrobi w nietestowanej sytuacji. Grupa proponuje spektrum konkretności: od twórcy modelu oczekujemy mitygacji ryzyk ogólnych, od wdrażającego zabezpieczeń pod konkretny przypadek. To rozsądne, ale pokazuje, jak łatwo odpowiedzialność rozpływa się między ogniwami, z których każde może wskazać palcem sąsiada.

Czego dokument nie rozstrzyga

Trzeba czytać go z trzema zastrzeżeniami. Po pierwsze, to prawo singapurskie i common law: polskiemu prawnikowi służy jako mapa problemów, nie jako gotowa odpowiedź. Konstrukcje (privity, negligence, Rylands v Fletcher) trzeba przełożyć na Kodeks cywilny, a nie przenieść wprost. Po drugie, to materiał dyskusyjny, świadomie bez rekomendacji: grupa nazywa go pierwszym krokiem, więc kto szuka gotowego reżimu, wyjdzie z niczym poza dobrze postawionymi pytaniami. Po trzecie, dokument prawie nie dotyka kontekstu unijnego, a tam dzieje się rzecz istotna: dedykowana dyrektywa o odpowiedzialności za AI (AI Liability Directive) została w lutym 2025 wycofana, zrewidowana dyrektywa o odpowiedzialności za produkt (2024/2853) obejmuje już oprogramowanie i AI, a AI Act jest prawem publicznym, nie reżimem odpowiedzialności cywilnej. Innymi słowy luka, którą Singapur dopiero bada, w Europie jest realna i właśnie się otworzyła.

Co z tego wynika

Dla kancelarii ten dokument działa na dwóch poziomach naraz, i oba są praktyczne.

Pierwszy to doradztwo klientowi, który wdraża agenta AI. Z dokumentu płynie konkretna rada: kontrakt jest najlepszym dostępnym narzędziem do rozłożenia ryzyka między dostawcą, wdrażającym a klientem, ale nie ochroni osób trzecich, więc trzeba osobno pomyśleć o ich szkodach (ubezpieczenie, zawężenie uprawnień agenta, zgody na działania o dużym wpływie). Klauzule odpowiedzialności w umowie z dostawcą AI zasługują na więcej uwagi, niż dostają, bo to w nich rozstrzyga się, kto poniesie stratę, gdy agent zrobi coś nieprzewidzianego.

Drugi poziom jest bliżej domu: własny agent kancelarii. Jeśli kancelaria wdroży agenta, który autonomicznie wykonuje czynności, i ten agent odbiegnie od instrukcji ze szkodą dla klienta lub osoby trzeciej, odpowiedzialność nie zniknie dlatego, że "zdecydowała AI". Zostanie przy kancelarii (art. 471 i art. 415 KC, polisa OC), a tajemnica zawodowa nie zna wymówki o autonomii narzędzia. Wniosek nie brzmi "nie używać agentów". Brzmi: nie wdrażaj autonomii, z której nie umiesz się rozliczyć. Zawężaj przestrzeń działania agenta, wymuszaj zgodę człowieka przy czynnościach o dużym wpływie, prowadź ślad, który pozwala odtworzyć, co i dlaczego agent zrobił. To te same trzy odruchy, które chronią przy każdym wdrożeniu AI: ograniczenie uprawnień, nadzór w punktach krytycznych, audytowalność.

Dla kogo ten materiał. Dla prawnika doradzającego firmie wdrażającej agentów, który potrzebuje słownika ryzyk i mapy, gdzie prawo nie daje jeszcze odpowiedzi. Dla partnera rozważającego agenta we własnej kancelarii, który chce wiedzieć, czyją odpowiedzialność bierze na siebie. Dla osoby od compliance i AI Act, która musi rozróżnić obowiązki publicznoprawne od cywilnej odpowiedzialności za szkodę, bo to dwa różne reżimy i jeden nie zastępuje drugiego.

Dla kogo nie. Dla nikogo, kto chce gotowej reguły "za agenta odpowiada X". Takiej reguły jeszcze nie ma, ani w Singapurze, ani w Polsce. Wartość dokumentu polega na tym, że uczciwie pokazuje, dlaczego jej nie ma, i które pytania trzeba rozstrzygnąć, zanim powstanie. To rzadka cnota w tekstach o AI: przyznać, że problem jest otwarty, zamiast udawać, że się go zamknęło.

Dla zarządu kancelarii w trzech zdaniach

Istniejące prawo cywilne radzi sobie z większością szkód od agentów AI przez kontrakt i niedbalstwo, ale pęka tam, gdzie agent działa nieprzewidywalnie, a odpowiedzialność rozprasza się między aktorami łańcucha. Dwa reżimy, wina i ryzyko, mają realne wady; w Europie luka jest pilniejsza niż w Singapurze, bo dedykowaną dyrektywę o odpowiedzialności za AI wycofano w 2025. Wniosek praktyczny: w umowach z dostawcami AI traktujcie klauzule odpowiedzialności jak realny przedmiot sporu, a wdrażając własnego agenta przyjmijcie, że odpowiedzialność zostaje przy kancelarii. Stąd trzy odruchy: zawęź uprawnienia agenta, wymuś zgodę człowieka przy działaniach o dużym wpływie, prowadź ślad pozwalający odtworzyć jego decyzje.