Legal AI obejmuje systemy wspierające pracę z normami, orzeczeniami i materiałem sprawy. Wymaga jawnej aktualności źródeł, granic interpretacji i odpowiedzialności zawodowej.
Nie zakładam, że model „zna prawo”. Projektuję korpus, retrieval, ontologię zdarzeń, cytowanie, ewaluację i moment, w którym specjalista może zakwestionować wynik.
Prawo wymaga rozdzielenia dokumentu, faktu, normy, interpretacji i decyzji zawodowej. Płynny tekst może ukryć błąd źródła albo nieaktualny stan prawny, dlatego kontrola cytatu nie jest dodatkiem do interfejsu. Jest częścią architektury, podobnie jak zakres korpusu, data obowiązywania materiału i prawo specjalisty do zatrzymania procesu.
To centrum traktuję jako mapę praktyki, a nie automatyczny zbiór etykiet. Punktem wyjścia jest konkretne zadanie użytkownika, dopuszczalny materiał i błąd, którego nie wolno przepuścić. Dopiero potem można rozmawiać o modelu, retrievalu lub narzędziu. Każdy opis powinien rozdzielać obserwację, założenie, interpretację oraz decyzję człowieka. Dzięki temu czytelnik widzi nie tylko rozwiązanie, lecz także warunki, w których przestaje ono być wiarygodne.
Dowód ma tu kilka warstw: źródło i jego licencję, strukturę danych, wersję wykonania, scenariusz ewaluacji oraz ścieżkę odpowiedzialności. Projekt powinien prowadzić do publicznego artefaktu, a tekst do projektu lub materiału badawczego. W tym klastrze rolę takich punktów kontrolnych pełnią między innymi NormaLab, Legal Copilot Ukraine, AdmissusCase. Ich status jest jawny, a ograniczenia pozostają częścią opisu zamiast przypisu dodanego po demonstracji.
Czytanie warto zacząć od materiałów Prawo jako łańcuch zdarzeń, Pierwotne problemy LLM w systemach prawnych, Architektura kopilota prawnego: wyszukiwanie, graf i ścieżka dowodowa, Rój zamiast platformy: nowa architektura krajowych systemów prawnych, a następnie przejść do powiązanych case studies. Kolejność nie ma budować lejka sprzedażowego; ma skracać drogę od pojęcia do sprawdzalnego przykładu. Jeśli argument dotyczy wydajności, potrzebuje benchmarku. Jeśli dotyczy jakości źródła, potrzebuje korpusu i negatywnych przypadków. Jeśli dotyczy decyzji zawodowej, musi wskazać punkt nadzoru i możliwość zakwestionowania wyniku.
Granica tego obszaru jest równie ważna jak jego definicja. Nie każda automatyzacja wymaga LLM, nie każdy wynik można otworzyć publicznie i nie każdy prototyp jest dowodem gotowości produkcyjnej. Dlatego materiały mają wersję, datę, status i scope note. Readiness audit poniżej pomaga przełożyć te zasady na własny proces: pokazuje, czy przed pierwszą integracją istnieją już źródła, baseline, testy, odpowiedzialność i procedura bezpiecznej zmiany.
Aktualizacja tego centrum powinna zaczynać się od zmiany w dowodzie, a nie od potrzeby dodania nowej etykiety. Nowa wersja modelu, źródła lub procedury wymaga sprawdzenia, które wnioski nadal obowiązują, które lokalizacje stały się nieaktualne i czy link prowadzi do tej samej wersji artefaktu. W praktyce oznacza to mały rejestr zmian, datę przeglądu i nazwane kryterium ponownego testu. Taki porządek pozwala rozwijać temat bez ukrywania wcześniejszych błędów oraz odróżniać trwałą metodę od jednorazowego eksperymentu. Czytelnik może wtedy ocenić nie tylko aktualny rezultat, lecz także sposób, w jaki został poprawiony po krytyce lub zmianie danych.