Інтелекту в моделі вистачає на більшість юридичних задач - це видно з перших спроб на реальних документах. Бракує іншого: опису того, як саме ця фірма робить цю роботу. За замовчуванням модель має середню по світу версію будь-якого процесу: середній рев'ю договору, середнє клопотання, середню перевірку контрагента. Версія фірми - з її позиціями, винятками і порядком рішень - живе в головах людей.
Перенести цю версію з голів у робоче середовище займає більше часу, ніж налаштування будь-якого інструмента. На цьому етапі зупиняється більшість команд: інструмент підключено, результати "не ті".
Досвідчений юрист знає, чому цей пункт прийнятний, а той - ні; коли загальне правило не діє; хто ухвалює рішення в сумнівному випадку; як виглядає результат, який піде клієнту без правок. Це знання ніде не записане. Людина сама не знає, що воно в неї є, - доки не спробує пояснити стажеру. Тоді з'ясовується, що правил більше, ніж здавалося, і половина з них - винятки.
Для моделі це знання не існує, поки воно не стало текстом у її контексті. Усе, що лишилося в голові, вона замінює середньою версією, без ознак того, що чогось бракує.
У більшості випадків ця фраза означає "ми не сказали". Тест простий: чи зробив би це правильно новий колега з тими самими матеріалами і тим самим запитом? Якщо ні - проблема в описі. Модель добудовує незаповнене з загальних закономірностей; людина добудовує з досвіду фірми. Різниця в результаті - це різниця в контексті.
Сильніша модель тут допомагає, але в певний спосіб. Вона краще вловлює закономірності з наданих прикладів, сама дослідить документи глибше, витягне правило з п'яти кейсів там, де слабша потребувала б двадцяти. Тобто сильніша модель знижує обсяг пояснень, який потрібен, - але вловлює закономірності лише з того, що їй дали. Без прикладів і еталона вловлювати нема з чого, і найкраща модель повертає найкращу середню версію.
Прохання "напиши інструкцію" дає слабкий результат: експерт записує те, що вважає правилами, і пропускає те, що робить автоматично. Працює спостереження за реальними рішеннями. Береться п'ять справжніх кейсів з результатом. По кожному ставиться питання "чому тут так, а тут інакше?" - і кожна відповідь стає рядком в еталоні. Винятки цінніші за правила: правило модель здебільшого знає, виняток - ні.
Друга опора - модель як стажер. Їй дають задачу з наявним описом, дивляться, де вона помилилася, і записують, чого бракувало. Помилка моделі показує саме те місце, де експерт діяв автоматично. Два-три кола такого розбору дають більше, ніж день інтерв'ю.
Playbook - це записані позиції фірми по типових пунктах і рішеннях. У рев'ю договорів він має три шари для кожного пункту: стандартна позиція (що ми хочемо), прийнятний діапазон (на що погоджуємось без ескалації), тригер ескалації (коли рішення переходить до партнера). Ліміт відповідальності: стандарт - річна сума договору; прийнятно - від шести місяців; ескалація - без ліміту або з винятками, що його знімають.
Той самий каркас працює для будь-якого повторюваного рішення: які документи вимагаємо від контрагента, які строки в клопотаннях вважаємо типовими, які формулювання в листах клієнту не використовуємо. Playbook описує, як фірма вирішує. Модель - один з його читачів; інший - новий колега.
Playbook відповідає на "що ми вважаємо прийнятним". Карта процесу відповідає на "що відбувається по порядку". Для однієї рутини вона вміщується на сторінку: що приходить на вхід, які кроки, у яких точках ухвалюється рішення і за яким критерієм, хто ухвалює, що виходить на виході, куди воно йде далі.
Карта малюється до будь-якої автоматизації, і при малюванні з'ясовується головне: різні люди роблять цей процес по-різному. Тобто процесу нема - є три. Узгодити три в один - робота, яка передує моделі. Узгоджена карта стає скелетом скіла: кроки, точки рішень, формат виходу.
Клінічні протоколи існують для того самого: знання досвідчених лікарів має виконуватися молодшими стабільно і безпечно, а варіативність між виконавцями має бути малою. Протокол будується з фіксованих частин. Показання: коли протокол застосовується. Кроки: що робити по порядку. Критерії рішень: при яких показниках який наступний крок. Протипоказання і винятки: коли протокол не діє. Ескалація: коли кликати старшого. Версія і дата перегляду: протокол живе, поки його переглядають.
Юридичний процес лягає в той самий каркас один до одного. Показання - тип задачі і документа. Кроки - карта процесу. Критерії рішень - playbook. Протипоказання - межі: чого не робимо і що не автоматизуємо. Ескалація - тригери передачі партнеру. Версія - дата останнього перегляду позицій. Протоколи пишуть досвідчені лікарі для всіх інших - у цьому їхнє призначення.
Протокол без дати перегляду перестає бути протоколом. Той самий принцип для playbook і карти процесу: у них є власник, версія і ритм перегляду. Ритм задається двома подіями. Регулярна: щотижневий розбір помилок за живими задачами - кожна помилка або рядок в еталон, або крок у карту. Календарна: квартальний перегляд позицій - що змінилося в законі, у практиці, у клієнтах фірми, і які пункти playbook від цього застаріли.
Модель виконує процес за поточною версією і помилками показує, де версія відстала. Без перегляду позиції застарівають, а результати лишаються гладкими.
Одна рутина, один власник. Дві години з експертом на п'ять реальних прикладів - не інтерв'ю про правила, а розбір рішень. Перший playbook і карта того ж дня, на одну сторінку кожне. Тиждень ітерацій на живих задачах з моделлю як стажером: кожна помилка - правка. Мірило готовності: новачок із цим описом дає результат рівня експерта. Далі - наступна рутина. Перша працює сама, з датою перегляду в календарі.