Stručně: legal engineering je práce, která mění právní úkol v opakovatelný, testovatelný pracovní postup, jejž mohou spouštět software a modely AI, přičemž výsledek schvaluje právník. Jeho základním nástrojem je TIRO: každé ustanovení nebo úkol rozdělte na Trigger (spouštěč), Inputs (vstupy), Requirements (požadavky) a Output (výstup). Níže ve čtyřech krocích rozebíráme jedno ustanovení o odškodnění.
Klíčová fakta
- Profese je starší než generativní AI: Richard Susskind uvedl „legal knowledge engineer“ mezi novými právními rolemi v knize Tomorrow's Lawyers (Oxford University Press, 2013).
- Proč záleží na ověřovacích krocích: ve věci Mata v. Avianca, Inc., No. 22-cv-1461 (PKC), 678 F. Supp. 3d 443 (S.D.N.Y. 2023) uložil soudce P. Kevin Castel dne 22. června 2023 sankci $5,000 dvěma právníkům a jejich kanceláři za podání neexistujících citací judikatury vygenerovaných ChatGPT.
- Knihovna promptů HAQQ obsahuje 631 promptů a Justinian je engine Legal AI, který spouští pracovní postupy HAQQ (haqq.ai, říjen 2026).
Co je legal engineering?
Legal engineering je navrhování, tvorba a údržba systémů, které určitý vymezený kus právní práce provádějí pokaždé stejně: revize nájemní smlouvy podle playbooku, vytažení dat obnovení z 500 smluv s dodavateli, kontrola marketingového e-mailu podle pravidel reklamy. Systém rozdělí úkol na kroky, každému kroku dá jediný úkol, zkontroluje výstup každého kroku a předá právníkovi výsledek s připojeným odůvodněním a zdroji.
Setkávají se v něm tři dovednosti. Právní znalosti říkají, jak vypadá správná práce. Softwarová praxe (typy, testy, správa verzí, logy) udržuje systém spolehlivý. Návrh AI rozhoduje, které kroky má dělat model, které pravidlo nebo vyhledání v databázi a kde se podepisuje člověk. Prompt je jednou součástí takového systému, stejně jako je jediný dotaz jednou součástí databázové aplikace.
Naše pracovní definice v HAQQ: pokud nedokážete sepsat kroky, vstupy, které každý krok potřebuje, a test, který prozradí, že krok selhal, je úkol stále jen prompt. Jakmile to dokážete, je to pracovní postup, který lze navrhnout jako inženýrské dílo.
Co dělá legal engineer?
- Mapuje úkol spolu s právníky, kteří jej dnes dělají: co jej spouští, jaké dokumenty přicházejí, jak vypadá hotový výstup a která rozhodnutí vyžadují partnera.
- Rozkládá ustanovení a postupy na kroky TIRO a zapisuje definice, prahové hodnoty a pravidla pro střety, na nichž každý krok závisí.
- Vybírá nástroj pro každý krok: volání modelu, deterministické pravidlo (výpočet dat, výpočet stropu), vyhledávací dotaz do databáze předpisů nebo kontrolní bod s lidskou revizí.
- Sestavuje testovací sadu: skutečné nebo anonymizované dokumenty se známou správnou odpovědí, včetně nepohodlných (chybějící přílohy, protichůdná ustanovení, skeny).
- Měří pracovní postup proti této testovací sadě před nasazením i po každé změně modelu nebo promptu a uchovává logy, které ukazují, který krok vytvořil které zjištění.
- Odpovídá za nakládání s daty: kde se dokumenty zpracovávají, kdo vidí který spis a co se uchovává, protože pravidla mlčenlivosti a důvěrnosti se vážou na architekturu.
V kanceláři tato role často stojí mezi týmem správy znalostí a IT. Někteří legal engineeři jsou právníci, kteří se naučili programovat; jiní jsou inženýři, kteří strávili roky po boku praxe. Společný je jim zvyk ptát se „jak poznáme, že tento krok selhal?“ dříve, než se zeptají „který model použijeme?“
Co je vzorec TIRO?
TIRO čte ustanovení nebo úkol jako čtyři části. Trigger (spouštěč) je událost, která ustanovení uvede do hry. Inputs (vstupy) jsou fakta a dokumenty, které ustanovení potřebuje. Requirements (požadavky) jsou to, co je třeba ověřit nebo vypočítat, a dělí se na čtyři druhy: Definitions (co pojmy znamenají), Validations (podmínky, které musí platit), Arbitration (které pravidlo převáží, když si dvě odporují) a Transformations (výpočty, které mění vstupy ve výsledek). Output (výstup) je to, co ustanovení vytváří: povinnost, právo, částku, nebo nic.
Hodnota tohoto vzorce je praktická. Každý požadavek se stává jedním krokem, který systém umí spustit, a jednou věcí, kterou může kontrolor ověřit. Když revize AI posoudí ustanovení špatně, TIRO ukáže kde: přehlédnutá definice, přeskočená validace, střet vyřešený nesprávným způsobem.
Jak rozložit ustanovení pomocí TIRO? Praktický příklad
Zde je typické odškodnění za porušení duševního vlastnictví ze smlouvy o SaaS. Napsali jsme je pro tento příklad; je blízké tomu, co vídáme v dokumentech dodavatelů.
12.1 The Supplier shall indemnify the Customer against all Losses arising from any claim that the Services infringe the Intellectual Property Rights of a third party, provided that the Customer notifies the Supplier in writing within ten (10) Business Days of becoming aware of the claim, and subject to clause 14.2.
Krok 1: Trigger
Třetí strana uplatní nárok, že Služby porušují její práva duševního vlastnictví. Nárok týkající se něčeho, co Zákazník postavil nad Službami, je jiná událost a ustanovení by se pro něj spustit nemělo. Toto rozlišení se stává první kontrolou.
Krok 2: Inputs
- Samotný nárok: kdo jej uplatnil, co tvrdí, na kterou část Služeb míří.
- Datum, kdy se Zákazník o nároku dozvěděl, a datum a forma jeho oznámení Dodavateli.
- Uplatněné Ztráty (Losses) s částkami.
- Článek 1 (definice Losses, Business Days, Intellectual Property Rights), článek 14.2 (strop) a případné výjimky v článku 14.3.
- Doložka o rozhodném právu, protože to, zda opožděné oznámení nárok zmaří, nebo jej jen sníží, závisí na použitelném právu.
Krok 3: Requirements
| Druh | Co krok dělá v ustanovení 12.1 | Jak jej provádíme |
|---|---|---|
| Definitions | Určit „Losses“, „Business Days“ a „Intellectual Property Rights“ z článku 1 | Vyhledání ve stejné smlouvě, citace zpět s čísly článků |
| Validations | Oznámení bylo písemné; oznámení bylo do 10 Business Days od zjištění; nárok se týká Služeb, nikoli úprav Zákazníka | Výpočet dat v kódu s použitím definice Business Day ze smlouvy; model přečte nárok a určí jeho cíl |
| Arbitration | Ustanovení 12.1 říká „subject to clause 14.2“; ověřit, zda článek 14.3 vyjímá odškodnění za duševní vlastnictví ze stropu, a co převáží, pokud si odporují | Model porovná ustanovení a musí citovat obě; právník potvrdí každý rozpor, na který model upozorní |
| Transformations | Uplatněné Losses, minus vše vyloučené definicí Losses, omezené stropem, pokud se použije | Výpočet v kódu, s vyznačením každého vstupu |
Krok 4: Output
Jeden ze tří výsledků, každý s citovanými ustanoveními: Dodavatel musí zaplatit uvedenou částku (se stropem nebo bez něj); povinnost je sporná, protože oznámení bylo opožděné, s poznámkou, že důsledek závisí na rozhodném právu; nebo se ustanovení nepoužije, protože nárok míří na úpravy Zákazníka. Právník vždy přezkoumá druhý a třetí výsledek.
Takto pojatá je revize, která říká jen „odškodnění za duševní vlastnictví přítomno, standardní“, zjevně neúplná. Přeskočila validaci oznámení a rozhodování o stropu, tedy místa, kde většina sporů o toto ustanovení začíná. Rozklad také ukazuje, že dva ze čtyř kroků požadavků nepotřebují jazykový model vůbec: počítání pracovních dnů a použití stropu je aritmetika.
Vyzkoušejte HAQQ AI zdarma
Zažijte sepisování a rešerše s podporou AI
Jak se rozklad TIRO stává pracovním postupem?
Každý krok požadavku se stává fází s typovaným vstupem a výstupem, takže další fáze dostává strukturovaná data místo volného textu. Nezávislé fáze běží paralelně (odškodnění za duševní vlastnictví, omezení odpovědnosti a ustanovení o ukončení lze revidovat současně) a závěrečná syntetizační fáze je sjednotí, protože dvě paralelní zjištění si mohou odporovat. V našem vlastním experimentu s data room na syntetických dokumentech našla pipeline se 3 agenty problémy napříč dokumenty, které jediný dlouhý prompt přehlédl: viz jediný prompt versus roj 3 agentů.
Důležitější než počet agentů jsou dvě pravidla návrhu. Za prvé, každá citace, kterou model vytvoří, se před doručením právníkovi ověří proti zdroji; Mata v. Avianca je trvalou připomínkou toho, co se stane jinak. Za druhé, náklady sledují směrování: levný model dokáže dokument klasifikovat, zatímco krok rozhodování o střetu zaslouží nejsilnější model, jaký máte. Tuto kompromisní volbu jsme změřili v článku kolik stojí návrh podaný s pomocí AI.
Které právní pracovní postupy se pro legal engineering hodí?
Dobří kandidáti se často opakují, mají ověřitelnou správnou odpověď a řídí se playbookem, který už existuje v něčí hlavě nebo v bance precedentů. Podle našich zkušeností je pořadí, v jakém je zkoušet, zhruba toto:
- Extrakce povinností a lhůt (oznámení o obnovení, pojistné certifikáty, lhůty k nápravě). Jasné vstupy, jasné výstupy, vysoké náklady při přehlédnutí.
- Revize podle playbooku a redlining příchozích dokumentů dodavatelů nebo zákazníků.
- Třídění dokumentů pro podnikové právní týmy: klasifikovat, vytáhnout lhůtu, předat správnému právníkovi.
- Analytika portfolia: stropy odpovědnosti, rozhodné právo a příznaky automatického obnovení napříč souborem smluv brát jako pole, která lze filtrovat.
- Due diligence nad data room, kde se kontroly napříč dokumenty (změna kontroly oproti licenci) vyplatí nejvíce.
- Rešeršní memoranda, jakmile je zavedeno ověřování citací proti databázi předpisů a judikatury.
V HAQQ tyto pracovní postupy přicházejí jako legal skills: zabalené, otestované postupy, které běží na Justinian, s kroky, zdroji a body schválení viditelnými pro právníka. Kanceláře si mohou ze stejných součástí vytvořit i vlastní.
Jak začít s legal engineeringem v kanceláři?
- Vyberte z výše uvedeného seznamu jeden pracovní postup, který některá praxe provádí každý týden.
- Shromážděte 20 až 30 minulých příkladů s odpovědí, kterou by schválil starší právník. To je vaše testovací sada.
- Rozložte klíčová ustanovení pomocí TIRO, na papíře, s právníky v místnosti.
- Postavte nejmenší verzi, která projde testovací sadou, s lidským schválením v kroku Output.
- Spusťte testovací sadu znovu při každé změně modelu, promptu nebo pravidla playbooku a uchovávejte výsledky.
Otázku dat mějte na očích od prvního dne. Kde se dokumenty zpracovávají, pod čími klíči a kdo vidí každou věc, ovlivňuje mlčenlivost a důvěrnost klientských informací, a po zavedení pracovního postupu je mnohem těžší to změnit. Naše bezpečnostní průvodce uvádí otázky, které je třeba klást.
Doporučené čtení
Slovník TIRO použitý zde pochází z knihy Roberta Taylora Legal Engineering: Building AI-Powered Legal Workflows with Multi-Agent Architectures. Její první část pokrývá základy (technologický stack, TIRO, víceprůchodové pipeline, paralelní provádění, integraci se sledováním změn ve Wordu a mlčenlivost a bezpečnost). Druhá část je aplikuje na deset pracovních postupů, které tvoří užitečný seznam četby:
- Sepisování smluv podle playbooku klienta
- Redlining smluv
- Analytika smluv napříč portfoliem
- Revize regulované komunikace
- Riziko třetích stran (dodavatelů)
- Třídění dokumentů
- Sledování povinností
- Due diligence při fúzích a akvizicích
- Podpora soudních sporů a e-discovery
- Právní rešerše s ověřováním citací
- Legal Engineering od Roberta Taylora (web knihy)
- Mata v. Avianca, Inc., No. 22-cv-1461 (S.D.N.Y.), spis na CourtListener
- Richard Susskind, Tomorrow's Lawyers (Oxford University Press)
