Maastricht i Tübingen mówią adwokatowi: "accuracy" nie jest pomiarem, jest wyborem normatywnym.

Paper zaczyna się od zdania, które polski adwokat reprezentujący osobę dotkniętą decyzją AI w postępowaniu administracyjnym czyta jako fundament obrony klienta. "Technical and legal debates frequently suggest that 'accuracy' is an objective, measurable, and purely technical property. We challenge this view, showing that evaluating AI performance fundamentally depends on context-dependent normative decisions." Cztery zdania niżej autorzy precyzują: "these techno-normative choices are crucial for rigorous AI deployment, as they determine which errors are prioritised, how risks are distributed, and how trade-offs between competing objectives are resolved". To jest argument prawniczy w opakowaniu pracy informatycznej. Dotychczas dostawca LegalTech mówił klientowi-kancelarii: "nasz model ma 94% accuracy, więc spełnia art. 15 AI Act". Po tym paperze polska kancelaria odpowiada: "94% pod jaką metryką, balansowaną w jaki sposób, na jakiej próbie, z jakim progiem akceptacji - i kto poniesie koszt błędów po waszej stronie wyboru".

O czym jest ten materiał

Paper liczy 19 stron i ma osiem sekcji. Sekcja 1 (Introduction) wprowadza tezę i terminologię techno-normative choices. Sekcja 2 (Accuracy in the EU AI Act) mapuje accuracy w art. 15 AI Act i innych high-risk requirements. Sekcja 3 (From Legal Requirements to Technical Practice) wprowadza ML workflow i illustrative use case (zdaje się być healthcare lub public sector classification). Sekcje 4-7 to rdzeń paperu - cztery techno-normative choices, każda z dwiema podsekcjami: relevance for the AI Act plus technical considerations in practice. Sekcja 8 (Conclusions) dostarcza rekomendacji dla "more meaningful performance evaluations". Każda sekcja choice'a ma identyczną strukturę, co ułatwia przekład na operacyjną listę pytań audytowych dla polskiej kancelarii.

Cztery techno-normative choices jako szkielet pracy compliance officera kancelarii reprezentującej deployera AI:

Centralne pojęcie paperu - techno-normative choices - autorzy definiują tak: "choices that are simultaneously technical and normative, where the technical implementation determines how normative assumptions materialise in practice". To znaczy, że nie istnieje "czysto techniczne" rozwiązanie problemu accuracy w high-risk AI - każda decyzja inżynieryjna jest jednocześnie decyzją etyczno-prawną, którą prawnik klienta-deployera lub strony postępowania administracyjnego ma prawo podważyć i renegocjować.

Recenzja właściwa

Najmocniejsza warstwa - Choice 1: Selecting Metrics

Sekcja 4 jest dla polskiej kancelarii najwartościowszym pojedynczym argumentem w paperze. Autorzy pokazują, że wybór metryki nie jest neutralny - klasyczna accuracy (procent poprawnych klasyfikacji) jest myląca dla zbiorów niezbalansowanych klas (np. wykrywanie nadużyć w bazie świadczeń socjalnych, gdzie prawdziwych nadużyć jest 2%, a model przewidujący "brak nadużycia" zawsze osiąga 98% accuracy). Precision (z ilu wskazanych przez model rzeczywiście jest pozytywnych) chroni przed false positives - kluczowe gdy koszt fałszywego oskarżenia jest wysoki. Recall (z ilu rzeczywistych pozytywnych model wskazał) chroni przed false negatives - kluczowe gdy koszt przeoczenia jest wysoki (rak, terror). F1 jest średnią harmoniczną precision i recall. MCC (Matthews Correlation Coefficient) jest najbardziej rygorystyczny dla niezbalansowanych klas, ale rzadko używany. AUC mierzy klasyfikator niezależnie od progu, ale ukrywa rzeczywiste decyzje progowe.

Polska kancelaria reprezentująca klienta-osobę dotkniętą decyzją AI w sprawie świadczenia socjalnego ZUS-u argumentuje: "system użyty przez ZUS optymalizuje accuracy 96%, ale recall dla naszej klasy ryzyka wynosi 12% - oznacza to, że 88% prawdziwych przypadków potrzebujących świadczenia jest pomijanych. Wybór accuracy jako głównej metryki jest techno-normative choice, którego nikt nie zwalidował z perspektywy prawa do świadczenia". Bez tego paperu argument jest abstrakcyjny - z paperem ma osadzenie w literaturze akademickiej i terminologii AI Act.

Druga mocna warstwa - Choice 2: Balancing multiple metrics

Sekcja 5 dostarcza operacyjnego rozumienia trade-offów, których dostawcy LegalTech rzadko ujawniają. W każdym praktycznym systemie AI istnieje tension między precision i recall: optymalizacja jednego pogarsza drugie. Pytanie strategiczne: który błąd jest droższy - fałszywie dodatni czy fałszywie ujemny? Dla wykrywania pranych pieniędzy w banku: false positive jest tani (klient przepytany, niewygodne), false negative jest drogi (kara KNF). Dla diagnostyki medycznej raka: false positive jest drogi (niepotrzebna operacja), false negative jest dramatyczny (niewykryty rak). Dla decyzji o przyznaniu kredytu: false positive jest drogi dla banku (default), false negative jest drogi dla obywatela (odmowa).

Polski adwokat doradzający bankowi wdrażającemu AI scoring kredytowy znajduje w sekcji 5 argumenty do dokumentacji art. 9 AI Act risk management. "Balansowanie precision i recall to nie decyzja inżyniera, to decyzja zarządu z dokumentacją uzasadnienia. Bez tej dokumentacji nasz audyt nie zda kontroli KNF ani UODO". Paper dostarcza języka, którym zarząd banku może opisać tę decyzję w protokole - z odniesieniem do literatury akademickiej, nie tylko dyrektyw wewnętrznych.

Trzecia warstwa - Choice 3: Measuring metrics

Sekcja 6 zajmuje się problemem, który polski adwokat reprezentujący stronę postępowania administracyjnego znajduje praktycznie najczęściej: na jakim datasecie zmierzono accuracy. Klasyczny problem sample bias - jeśli dataset treningowy reprezentuje populację z 2018 roku, a model jest deployowany w 2026 - distribution shift psuje accuracy. Jeśli dataset ewaluacyjny jest wewnętrzny (z internal test split), accuracy jest zawyżona. Jeśli ewaluacja jest na zewnętrznym datasecie (out-of-distribution), accuracy jest realistyczna ale zwykle niższa. Jeśli dataset nie zawiera grup demograficznych klienta (etniczność, region, dochód), accuracy nie ma żadnego znaczenia dla niego.

Polska kancelaria reprezentująca obywatela z mniejszej miejscowości w sprawie z urzędem skarbowym używającym AI do typowania kontroli: "Państwa system osiągnął 91% accuracy na datasecie zawierającym głównie deklaracje z dużych miast. Mój klient prowadzi działalność w gminie 8000 mieszkańców - sample size dla tej grupy w datasecie ewaluacyjnym wynosi 0.3%. Accuracy 91% nie ma żadnej mocy dowodowej dla decyzji o kontroli mojego klienta". To jest precyzyjny argument prawny, który dotąd nie miał osadzenia akademickiego.

Czwarta warstwa - Choice 4: Determining acceptance thresholds

Sekcja 7 dotyka pytania, które jest kluczowe dla art. 15 AI Act: jaki próg accuracy uznajemy za "good enough". Autorzy pokazują, że nie istnieje obiektywna odpowiedź - próg zależy od (a) kosztu błędu, (b) bazowej częstości problemu, (c) dostępności alternatyw, (d) regulacyjnego minimum, (e) ekonomii deploymentu. Polska kancelaria reprezentująca klienta-deployera AI w sektorze publicznym (np. urząd miasta wdrażający chatbot do triagowania petycji) buduje własny próg z protokolu uchwały zarządu, nie akceptuje progu narzuconego przez dostawcę. Argument: "Dostawca twierdzi, że 85% accuracy jest standardem branżowym. Nie ma takiego standardu. AI Act art. 15 wymaga 'appropriate level' - który dla naszego use case (decyzje administracyjne dotykające praw obywatelskich) musi być wyższy niż 85%, prawdopodobnie 95% z dodatkowym recall constraint".

Paper nie podaje konkretnych progów - słusznie, bo te są kontekstualne. Daje natomiast strukturę argumentacji prawnej: kto decyduje o progu (zarząd, audytor, regulator?), na podstawie jakich kryteriów (koszt błędu, populacja afektowana, alternatywy?), z jakim cyklem rewizji (co kwartał, co rok, ad hoc po incydencie?). Kancelaria wykonuje za zarząd klienta tę dokumentację, korzystając z paperu jako wzorca metodologicznego.

Mapping na polskie instrumenty prawne

Warstwa AI Act

Art. 15 AI Act jest centralny. Cytowana w paperze pięć razy klauzula wymaga od high-risk AI systems "appropriate level of accuracy, robustness and cybersecurity, throughout their lifecycle". Cztery techno-normative choices są operacyjną mapą drogi do spełnienia tej klauzuli: bez dokumentacji wyboru metryki, balansowania, próbki i progu nie można udowodnić "appropriate level" w postępowaniu kontrolnym Komisji ani polskiego organu nadzorczego (UOKiK ds. konkurencji, sektorowych UKE/KNF/UODO ds. specyficznych obszarów).

Mapowanie czterech choices na siedem high-risk requirements AI Act: Choice 1 i 2 dotyczą art. 15 (accuracy/robustness) plus art. 9 (risk management - identyfikacja i mitygacja ryzyka błędów). Choice 3 dotyczy art. 10 (data and data governance - jakość, prowenience, reprezentatywność datasetu). Choice 4 dotyczy art. 14 (human oversight - decyzja o progu wymaga nadzoru ludzkiego, nie inżynieryjnego). Wszystkie cztery razem zasilają art. 13 (transparency to deployers - dokumentacja czterech wyborów dla deployera) plus art. 26 (deployer obligations - klient-deployer ma obowiązek zrozumieć cztery wybory dostawcy i ocenić ich appropriateness dla własnego use case).

Warstwa RODO

Art. 22 RODO (zautomatyzowane decyzje) plus art. 35 (DPIA) razem wymagają dokumentacji wyborów, które wpływają na osobę. Cztery techno-normative choices są dokładnie tą dokumentacją. Polska kancelaria reprezentująca obywatela skarżącego decyzję zautomatyzowaną wykonaną przez gminę argumentuje pod art. 22 RODO: "Gmina nie udostępniła dokumentacji wyboru metryki, balansowania, próbki i progu. Bez tej dokumentacji decyzja zautomatyzowana nie spełnia wymogu rozliczalności art. 5 ust. 2 RODO ani prawa do informacji o logice decyzji art. 15 ust. 1 lit. h RODO". To jest narzędzie przelicznikowe między abstrakcyjnym art. 22 RODO a konkretnym dokumentem inżynieryjnym dostawcy.

Warstwa polskiego sektora LegalTech

Polski rynek LegalTech jest na początku adopcji AI w pracy kancelarii. Dostawcy (Gaius-Lex, Datapoint, Lexagent, mniejsze startupy) prezentują benchmarki accuracy na konferencjach i materiałach marketingowych. Polska kancelaria czytająca ten paper przed zakupem LegalTech ma teraz cztery konkretne pytania audytowe: jaką metrykę optymalizujecie i dlaczego (Choice 1), jak balansujecie precision/recall i kto ustalił trade-off (Choice 2), na jakim datasecie mierzyliście accuracy i czy obejmuje polskie orzecznictwo z ostatnich 24 miesięcy (Choice 3), jaki jest próg akceptacji i czy klient kancelaria może go renegocjować dla swojego use case (Choice 4). Te pytania zmieniają dynamikę rozmowy zakupowej - dostawca, który nie ma odpowiedzi, traci wiarygodność.

Warstwa tajemnicy zawodowej adwokackiej i radcowskiej

Tajemnica zawodowa wymaga, by accuracy systemu LegalTech nie tylko była wysoka, ale także żeby system nie ujawniał tajemnicy w trakcie ewaluacji ani treningu. Cztery techno-normative choices mają warstwę dodatkową dla kancelarii: Choice 3 (Measuring metrics) musi być wykonywane na datasecie, który nie zawiera akt klientów lub jest fully anonymized. Polski adwokat dopisuje wymóg: "Wasz benchmark accuracy nie może być mierzony na realnych aktach kancelarii naszych klientów - choć dataset z anonymized aktów może być akceptowalny po pełnej de-identification zgodnie z art. 4 ust. 5 RODO". To jest specyficzny polski wymóg, który paper nie omawia, ale którego strukturę pozwala wprowadzić.

Czego brakuje - z perspektywy polskiej kancelarii

Brak warstwy LLM-ów i generatywnej AI. Paper koncentruje się na klasycznych systemach klasyfikacyjnych (precision/recall/F1). Współczesna AI w kancelariach to coraz częściej LLM-y (GPT, Claude, Gemini), gdzie "accuracy" ma inny charakter - ocenia się halucynacje, faithfulness, groundedness, citation correctness. Cztery techno-normative choices są aplikowalne, ale wymagają tłumaczenia z metryki klasyfikacyjnej na metrykę generative. Polska kancelaria dopisuje tę warstwę za autorów - z odniesieniem do BW/034 Kumaran (LLM biases) i BW/035 Laban (delegacja LLM korumpuje dokumenty).

Brak konkretnego illustrative use case z sektora prawnego. Paper zapowiada use case w Sekcji 3.2, ale wybiera prawdopodobnie healthcare lub public sector classification. Polska kancelaria pracująca z LegalTech musi wykonać własny use case (predykcja wyniku sporu, klasyfikacja klauzul w umowie, eDiscovery) i zaaplikować cztery choices. Paper jest framework'iem, polska kancelaria konkretyzuje go dla LegalTech.

Brak rekomendacji konkretnych progów accuracy dla różnych domen. Słusznie - autorzy nie chcą ustanawiać arbitralnych standardów. Ale pozostawia to lukę praktyczną: polska kancelaria, która odpowiada klientowi "jaki próg jest appropriate dla naszego LegalTech?", nie znajduje w paperze odpowiedzi. Mitigacja: wzorowanie się na progach w sektorach pokrewnych (medycyna, lotnictwo) plus własna dokumentacja uzasadnienia z art. 9 AI Act.

Brak warstwy odpowiedzialności cywilnoprawnej za błędy modelu. Paper omawia konsekwencje "społeczne" (impact on affected persons), nie omawia odpowiedzialności cywilnej dostawcy lub deployera za błąd techniczno-normatywny. Polska kancelaria dopisuje warstwę: art. 415 KC (delikt) plus art. 471 KC (kontrakt) plus projektowane dyrektywy unijne o odpowiedzialności za AI. Bez tej warstwy paper jest narzędziem audytu, nie narzędziem dochodzenia roszczeń.

Brak pomysłu na automatyzację audytu czterech choices. Cztery techno-normative choices wymagają od audytora kompetencji techniczno-prawnych równoważnych. Paper nie sugeruje, czy istnieją lub powinny istnieć narzędzia do automatycznej weryfikacji (np. tooling sprawdzający, czy dataset ewaluacyjny zawiera odpowiednią reprezentację grup demograficznych). To jest agenda przyszła, której polska kancelaria może być uczestnikiem - poprzez zlecanie testowych audytów polskim Tech Lab'om uniwersyteckim (UJ, PW, AGH).

Komu polecam, komu odradzam

Compliance officer kancelarii doradzającej dostawcy LegalTech - obowiązkowo. Cztery techno-normative choices wprost do regulaminu wewnętrznego dokumentacji art. 15 AI Act. Bez tej dokumentacji audyt zewnętrzny nie zda kontroli.

Adwokat reprezentujący klienta-deployera kupującego LegalTech - obowiązkowo. Cztery pytania audytowe (jak w sekcji o polskim sektorze LegalTech) zmieniają dynamikę rozmowy zakupowej. Paper jest narzędziem renegocjacyjnym.

Adwokat reprezentujący stronę postępowania administracyjnego z udziałem AI - obowiązkowo. Argument "accuracy jest techno-normative choice" przesuwa ciężar dowodu z obywatela na organ administracji. Bez dokumentacji czterech wyborów decyzja zautomatyzowana nie spełnia art. 22 RODO ani art. 14 AI Act.

IOD organów administracji publicznej i regulatorów - obowiązkowo. Mapowanie czterech choices na art. 35 RODO DPIA daje strukturę raportu, której dotąd brakowało. Plus mapowanie na sektorowe wymogi (KNF dla finansów, UODO dla danych osobowych, MZ dla zdrowia).

Polski startup LegalTech (Gaius-Lex, Datapoint, Lexagent, etc.) - obowiązkowo. Paper jest narzędziem sprzedażowym: dostawca który dokumentuje cztery choices i je publicznie ujawnia, ma przewagę nad dostawcami które ukrywają. To inwestycja w wiarygodność na rynku polskim, gdzie zaufanie do LegalTech jest jeszcze niskie.

Klient-zarząd polskiej spółki bez doradcy - tak, ale tylko Sekcja 1 (Introduction) plus Sekcja 8 (Conclusions). Reszta wymaga technicznego rozumienia ML, którego zarząd niekoniecznie ma. Wartość pojęciowa: świadomość, że accuracy to nie liczba, to wybór.

Mała kancelaria 5-10 osobowa bez klientów-deployerów AI - selektywnie. Paper jest pomocny pojęciowo, ale operacyjnie wykorzystuje czas, którego mała kancelaria nie ma. Lepsza inwestycja: BW/047 Turing PBG Framework (procesowy) lub BW/039 RAII Policy Template (firmowa polityka).

Powiązanie z innymi tomami Bazy Wiedzy

Direct partner do BW/034 (Kumaran et al. - dwa błędy w pewności LLM) - Kumaran pokazuje, że LLM-y mają systemowe biasy w pewności (choice-supportive bias plus hypersensitivity to contradiction); Uberti-Bona Marin pokazuje, że pomiar accuracy jest sumą czterech wyborów normatywnych. Razem stanowią parę: biasy modelu + biasy pomiaru = empiryczny argument za rygoryczną dokumentacją.

Direct complement do BW/035 (Laban et al. - LLMs Corrupt Your Documents) - Laban mierzy degradację jakości dokumentu po 20 iteracjach delegacji do LLM; Uberti-Bona Marin pokazuje, jak w ogóle mierzymy jakość. Bez paperu Maastricht/Tübingen pomiar Labana byłby naiwny - z paperem staje się rygorystyczny.

Direct complement do BW/047 (Leslie et al., Turing PBG Framework) - Turing dostarcza sześć zasad SSAFE-D (w tym Safety) plus jedenaście etapów cyklu życia projektu AI; Uberti-Bona Marin dostarcza cztery techno-normative choices, które są operacyjną dekompozycją zasady Safety w etapach Model Testing & Validation oraz System Use & Monitoring. Razem dają framework etyki AI plus praktyczny pomiar - polska kancelaria łączy oba w polityce dla klienta-administracji publicznej.

Direct complement do BW/046 (Berkeley CLTC GPAI Profile V1.2) - Berkeley syntetyzuje cztery funkcje GMMM (Govern/Map/Measure/Manage); Uberti-Bona Marin pogłębia funkcję MEASURE w czterech choices. Bez paperu funkcja MEASURE w Berkeley jest abstrakcyjna - z paperem ma operacyjną drabinkę decyzyjną.

Direct complement do BW/045 (Kenney - Runtime Enforcement) - Kenney mówi, że accuracy musi być continuously verified (Zasada 2 - continuous authorization not point-in-time); Uberti-Bona Marin mówi, jak verified - przez świadomy pomiar czterech wyborów. Razem dają Zasadę 2 w wymiarze operacyjnym: continuous techno-normative re-evaluation.

Direct complement do BW/040 (King AI Vendor Assessment Guide V2.0) - King daje 33 pytania audytowe w 12 domenach; Uberti-Bona Marin dostarcza cztery dodatkowe pytania w kategorii performance evaluation (Choice 1-4), które polski adwokat kupujący LegalTech używa równolegle z King.

Razem z BW/038 (Smuha Cambridge Handbook) uzupełnia akademiczną literaturę europejską - Smuha jest meta-encyklopedią etyki AI, Uberti-Bona Marin jest precyzyjnym narzędziem operacyjnym dla jednego z głównych obowiązków AI Act.

Dla MateMatic to warstwa pomiaru i rygoru technicznego w stack'u governance. Jedenastowarstwowy stack obejmuje teraz: BW/009 taksonomia ryzyk, BW/038 akademia etyki europejskiej, BW/039 polityka firmowa, BW/040 vendor assessment, BW/042 benchmark globalny, BW/044 sektor publiczny, BW/045 runtime architektura, BW/046 synteza standardów, BW/047 procesowy framework etyki, BW/048 regulacja konkurencji, plus BW/049 - rygorystyczny pomiar accuracy. Bez tej warstwy stack mówi co robić z accuracy, ale nie mówi jak ją audytować.