Вчора після обіду ділився тим, як використовую Claude Code в юр роботі, а ввечері Антропік вже випустив нового агента Claude Cowork.
Коротко про функціонал Коворка: допомога з більшістю productivity тасок, окрім кодерських.
Але цікаве в цій історії не функціонал.
А те, як гарно реліз Коворка ілюструє те, як семантика впливає на наше сприйняття.
Коли Стів Джобс представив перший iPhone, він не назвав його «КПК» чи «смартфоном».
Він назвав його телефоном.
На той момент не існувало ринкової категорії для пристрою, який не лише дзвонить і надсилає SMS, а й робить та редагує фото, веде нотатки, працює з інтернетом тощо.
Завдяки знайомому слову Джобс суттєво знизив бар’єр для використання радикально нового продукту.
Коли Anthropic запустили Claude Code, це гарно допомогло їм проїхатись по нарративу coding-агентів та AI-продуктивності для розробників.
Назва була логічною - першою цільовою аудиторією були саме інженери.
Але далі сталося цікаве.
До кінця року не технічні користувачі (такі як я, наприклад) почали активно використовувати Claude Code для не-кодингових задач: написання текстів, аналізу, ресерчу, побудови воркфлоу, підтримки рішень.
Проте сама назва продовжувала сигналізувати:
«Цей інструмент - для програмістів».
А семантика має значення.
Тому для мене Claude Cowork виглядає як відповідь Anthropic на цю прогалину -> назва, яка відображає значно ширший спектр кейсів, що вже не вкладаються в поняття «Code».
Ті самі можливості -> інша семантика -> абсолютно інше сприйняття.
А дуже часто саме сприйняття і відкриває шлях до масового використання.
Коротко про функціонал Коворка: допомога з більшістю productivity тасок, окрім кодерських.
Але цікаве в цій історії не функціонал.
А те, як гарно реліз Коворка ілюструє те, як семантика впливає на наше сприйняття.
Коли Стів Джобс представив перший iPhone, він не назвав його «КПК» чи «смартфоном».
Він назвав його телефоном.
На той момент не існувало ринкової категорії для пристрою, який не лише дзвонить і надсилає SMS, а й робить та редагує фото, веде нотатки, працює з інтернетом тощо.
Завдяки знайомому слову Джобс суттєво знизив бар’єр для використання радикально нового продукту.
Коли Anthropic запустили Claude Code, це гарно допомогло їм проїхатись по нарративу coding-агентів та AI-продуктивності для розробників.
Назва була логічною - першою цільовою аудиторією були саме інженери.
Але далі сталося цікаве.
До кінця року не технічні користувачі (такі як я, наприклад) почали активно використовувати Claude Code для не-кодингових задач: написання текстів, аналізу, ресерчу, побудови воркфлоу, підтримки рішень.
Проте сама назва продовжувала сигналізувати:
«Цей інструмент - для програмістів».
А семантика має значення.
Тому для мене Claude Cowork виглядає як відповідь Anthropic на цю прогалину -> назва, яка відображає значно ширший спектр кейсів, що вже не вкладаються в поняття «Code».
Ті самі можливості -> інша семантика -> абсолютно інше сприйняття.
А дуже часто саме сприйняття і відкриває шлях до масового використання.
🔥8
Про новий тренд з harness engineering для АІ агентів
Якщо ви будуєте АІ агентів в зарегульованих індустріях (таких як юридична) - то скоріше за все ви зіштовхувались з питанням:
• де проходить лінія між “агентністю” АІ (який сам гуглить, сам робить read / write у вашій пошті і календарі, сам вирішує скільки на це витратити токенів) і комфортним рівнем контролю над такою агентністю?
Ось таку лінію для досягнення “комфортного” рівня контролю можна провести ч-з harness engineering, який виступає таким собі “control center” між автономним агентом і реальним світом.
Кажуть, що harness engineering - це наступний етап після context engineering-а (перед яким ще був prompt engineering, якщо ви памʼятаєте).
Мій кофаундер і СТО Legal Nodes Макс поділився зі мною сьогодні гарною статею на цю тему.
Додаю посилання нижче:
https://kenhuangus.substack.com/p/found-from-claude-code-chapter-1
Якщо ви будуєте АІ агентів в зарегульованих індустріях (таких як юридична) - то скоріше за все ви зіштовхувались з питанням:
• де проходить лінія між “агентністю” АІ (який сам гуглить, сам робить read / write у вашій пошті і календарі, сам вирішує скільки на це витратити токенів) і комфортним рівнем контролю над такою агентністю?
Ось таку лінію для досягнення “комфортного” рівня контролю можна провести ч-з harness engineering, який виступає таким собі “control center” між автономним агентом і реальним світом.
Кажуть, що harness engineering - це наступний етап після context engineering-а (перед яким ще був prompt engineering, якщо ви памʼятаєте).
Мій кофаундер і СТО Legal Nodes Макс поділився зі мною сьогодні гарною статею на цю тему.
Додаю посилання нижче:
https://kenhuangus.substack.com/p/found-from-claude-code-chapter-1
Substack
Found from Claude Code: Chapter 1: The Harness Paradigm
What Is an Agentic AI Harness?
🔥8
GPT і Клод скоро будуть по $1к+
Такий прогноз робить YC CEO.
Цілком можливо, що ми зараз в моменті, коли frontier models є найдоступнішими.
І так як це вікно може проіснувати недовго - важливо працювати одночасно на декількох горизонтах роботи з АІ:
1) перший горизонт - з клауд моделями тестувати гіпотези настільки активно, наскільки це можливо (пізніше такої можливості вже може не бути)
2) другий горизонт - розгортати опенсорсні моделі на власних девайсах (останню джемму можна розгорнути навіть на андроїд смартфоні). Так ви будете менше залежати від зовнішніх ллм провайдерів.
3)третій горизонт - файнтюнити опенсорсні моделі під спеціалізовані домени (ми в лігал нодс файнтюнимо під лігал, мали перші успішні кейси з містралівськими моделями для задач по GDPR).
Робота одночасно на всіх 3х горизонтах допоможе залишатись конкурентним в цьому швидкоплинному світі АІ :)
Такий прогноз робить YC CEO.
Цілком можливо, що ми зараз в моменті, коли frontier models є найдоступнішими.
І так як це вікно може проіснувати недовго - важливо працювати одночасно на декількох горизонтах роботи з АІ:
1) перший горизонт - з клауд моделями тестувати гіпотези настільки активно, наскільки це можливо (пізніше такої можливості вже може не бути)
2) другий горизонт - розгортати опенсорсні моделі на власних девайсах (останню джемму можна розгорнути навіть на андроїд смартфоні). Так ви будете менше залежати від зовнішніх ллм провайдерів.
3)третій горизонт - файнтюнити опенсорсні моделі під спеціалізовані домени (ми в лігал нодс файнтюнимо під лігал, мали перші успішні кейси з містралівськими моделями для задач по GDPR).
Робота одночасно на всіх 3х горизонтах допоможе залишатись конкурентним в цьому швидкоплинному світі АІ :)
🔥8
Субтотнє
Побачив у подруги в інсті смішне відео про сценарій, в якому робота працівників тарифікувалась би так само, як робота АІ агентів (aka “usage-based pricing for employees”)
1) якщо промптинг працівника виходить за рамки робочого міта -> працівник завершує «сесію», якщо немає доплати
2) складний різонінг -> працівник не приймає додаткових питань, якщо не збільшити винагороду
3) колаборація з іншими працівниками - екстра usage, за який теж прийдеться доплатити преміум
(бо «інтеграції» не входять в lowest tier plan 😂)
На будь-яку задачу, яку працівник не хоче виконувати, він просто відповідає «You’ve reached your usage limit”.
Ось такий неочікуваний «future of work» :))
Якщо ви активно використовуєте агентів і щоразу дивуєтесь від того, як швидко тане баланс ваших токенів щоразу, коли агент йде у web search, коннектиться ч-з MCP до gmail чи jira, чи намагається запхати велику пачку тексту у своє контекстне вікно - ви точно посмієтесь :)
Посилання:
https://www.instagram.com/reel/DW9CDp1jrH4/?igsh=MTNoNTNqZ25xN29rbg==
Побачив у подруги в інсті смішне відео про сценарій, в якому робота працівників тарифікувалась би так само, як робота АІ агентів (aka “usage-based pricing for employees”)
1) якщо промптинг працівника виходить за рамки робочого міта -> працівник завершує «сесію», якщо немає доплати
2) складний різонінг -> працівник не приймає додаткових питань, якщо не збільшити винагороду
3) колаборація з іншими працівниками - екстра usage, за який теж прийдеться доплатити преміум
(бо «інтеграції» не входять в lowest tier plan 😂)
На будь-яку задачу, яку працівник не хоче виконувати, він просто відповідає «You’ve reached your usage limit”.
Ось такий неочікуваний «future of work» :))
Якщо ви активно використовуєте агентів і щоразу дивуєтесь від того, як швидко тане баланс ваших токенів щоразу, коли агент йде у web search, коннектиться ч-з MCP до gmail чи jira, чи намагається запхати велику пачку тексту у своє контекстне вікно - ви точно посмієтесь :)
Посилання:
https://www.instagram.com/reel/DW9CDp1jrH4/?igsh=MTNoNTNqZ25xN29rbg==
🔥6
Зібрав трохи саморефлексій за останні 6 міс з моменту, як почав використовувати claude code
Основний інсайт - цифрові двійники.
Весь час думав, що це про людей, але ні.
Це можуть бути двійники бізнес функцій, потенційних покупців, компаній-конкурентів і навіть двійники середовища, в якому агент має виконати задачу.
Спробував - і зрозумів, що з двійниками абсолютно новий рівень intelligent decision making-a.
Більше деталей в блозі:
https://autonestor.substack.com/p/i-thought-self-automation-was-about?triedRedirect=true
Основний інсайт - цифрові двійники.
Весь час думав, що це про людей, але ні.
Це можуть бути двійники бізнес функцій, потенційних покупців, компаній-конкурентів і навіть двійники середовища, в якому агент має виконати задачу.
Спробував - і зрозумів, що з двійниками абсолютно новий рівень intelligent decision making-a.
Більше деталей в блозі:
https://autonestor.substack.com/p/i-thought-self-automation-was-about?triedRedirect=true
Substack
I Thought Self-Automation Was About Tasks. I Was Wrong
How six months of working with agentic AI changed my understanding of self-automation
🔥9
Приблизно рік тому їв з друзями піццу в недільний лондонський вечір. Трохи говорили про АІ.
Тоді якраз почали виходити перші новини про співпрацю frontier labs з Пентагоном і вже було очевидно що АІ набуває значення «dual use».
Питання яке ми обговорювали тоді:
чи введе США експортний контроль на американські моделі (по аналогії з тим як це працює з мілтеком)?
Після вчорашніх новин з Fable схоже що ця реальність значно ближче.
Fable - це нова версія Mythos (тієї самої моделі, яка вміє знаходити вразливості в коді).
Mythos не був доступним для всіх, але в останньому релізі Антропік зробив guardrails для Mythos (щоб всякі black hats не могли викостати її для кібератак) - і зарелізив її як Fable тиждень тому.
Тут постає питання: чому тоді Fable обмежили для неамериканських користувачів?
Відповідь: хтось зламав guardrails Фейбла і США побачили в цьому загрозу нац безпеці.
Гарна ілюстрація того, чому існує експортний контроль на технології, які можуть використані проти держави, в якій вони були розроблені.
Тоді якраз почали виходити перші новини про співпрацю frontier labs з Пентагоном і вже було очевидно що АІ набуває значення «dual use».
Питання яке ми обговорювали тоді:
чи введе США експортний контроль на американські моделі (по аналогії з тим як це працює з мілтеком)?
Після вчорашніх новин з Fable схоже що ця реальність значно ближче.
Fable - це нова версія Mythos (тієї самої моделі, яка вміє знаходити вразливості в коді).
Mythos не був доступним для всіх, але в останньому релізі Антропік зробив guardrails для Mythos (щоб всякі black hats не могли викостати її для кібератак) - і зарелізив її як Fable тиждень тому.
Тут постає питання: чому тоді Fable обмежили для неамериканських користувачів?
Відповідь: хтось зламав guardrails Фейбла і США побачили в цьому загрозу нац безпеці.
Гарна ілюстрація того, чому існує експортний контроль на технології, які можуть використані проти держави, в якій вони були розроблені.
👍7🔥1
Купляти Harvey вже не модно серед юрфірм
Останні 2 роки більшість юр фірм купляли Harvey ($500/mo/seat) в першу чергу для піару.
Цей гарного профінансовий legal AI бренд допомагав юр фірмам вигравати більше RFPs від клієнтів, бо був показником їх інноваційності.
А потім Kirkland & Ellis (BigLaw) анонсували створення своєї внутрішньої лаби за $500М (99% що теж для піару)
І сентимент навколо Harvey різко змінився в сторону того, що круті юр фірми вже не купляють АІ в зовнішніх вендорів.
Вони тренують власні моделі.
Will Chen (розробник опен-сорсного Harvey) запостив гарний мем на цю тему :)
Останні 2 роки більшість юр фірм купляли Harvey ($500/mo/seat) в першу чергу для піару.
Цей гарного профінансовий legal AI бренд допомагав юр фірмам вигравати більше RFPs від клієнтів, бо був показником їх інноваційності.
А потім Kirkland & Ellis (BigLaw) анонсували створення своєї внутрішньої лаби за $500М (99% що теж для піару)
І сентимент навколо Harvey різко змінився в сторону того, що круті юр фірми вже не купляють АІ в зовнішніх вендорів.
Вони тренують власні моделі.
Will Chen (розробник опен-сорсного Harvey) запостив гарний мем на цю тему :)
👍3
Харві починають тренувати суверенні моделі для юрфірм.
Цьому передувала наступна хронологія подій:
1) початок травня - Харві релізить власні бенчмарки
2) кінець травня - додатковий реліз лідерборда моделей, оцінених проти бенчмарок (спойлер: жодна модель не досягла вище 10% score)
3) початок червня - Kirklands & Ellis виділяють $500М на тренування власної моделі
4) зараз за вікном середина червня - і маєм такі новини про Харві.
Темп розвитку подій - insane.
Але їхнє значення фундаментальне:
ми спостерігаємо закінчення епохи врапперів навколо фронтір моделей і вступаємо в нову епоху тренування власного спеціалізованого АІ
Юристам приготуватись до нових професій:
- data counsels
- legal data annotators
- legal harness engineers
- forward deployed lawyers
Цьому передувала наступна хронологія подій:
1) початок травня - Харві релізить власні бенчмарки
2) кінець травня - додатковий реліз лідерборда моделей, оцінених проти бенчмарок (спойлер: жодна модель не досягла вище 10% score)
3) початок червня - Kirklands & Ellis виділяють $500М на тренування власної моделі
4) зараз за вікном середина червня - і маєм такі новини про Харві.
Темп розвитку подій - insane.
Але їхнє значення фундаментальне:
ми спостерігаємо закінчення епохи врапперів навколо фронтір моделей і вступаємо в нову епоху тренування власного спеціалізованого АІ
Юристам приготуватись до нових професій:
- data counsels
- legal data annotators
- legal harness engineers
- forward deployed lawyers
🔥6👍1
Літо в Legal AI було жарким:
• Harvey випустили власну юридичну АІ модель Tenet
• декілька тижнів потому це ж зробив Thomson Reuters
• після цього Біл Гейтс запропонував ввести “податок на АІ токени”
А також після хвиль “prompt engineering” (2024) і “harness engineering” (2025) АІ спільнота почала говорити про третій етап розвитку АІ - Context Graphs.
Що таке Context Graph?
Граф - це:
- онтологічні сутності (юр особа, контракт, акціонер, запис, каптейбл)
- і взаємозвʼязки між ними (юр особа [підписала] контракт [з] акціонером і [зробила] запис в [каптейбл])
Context Graph - це інформація, яка:
• необхідна для виконання задачі (“контекст задачі”), і
• яка структурована у вигляді графа (інформація розібрана на сутності і взаємозвʼязки).
Ми вже знаємо правило: “чим детальніший контекст - тим якісніший AI output”.
І є вже research papers (від Стенфорда і Майкрософта), які довели, що коли інформація для АІ структурована у вигляді графа знань - АІ:
• менше галюцинує (“deterministic inference”)
• менше палить токенів (бо швидше знаходить потрібну інформацію у графі в порівнянні з неструктурованими файлами)
Але відкритими залишаються питання:
• навіщо юридичним задачам контекст?
• як відрізняються AI outputs у випадках коли АІ має контекст, і коли він відсутній?
• як визначати яка інформація є корисною для контексту задачі, а яка - ні?
• коли зібрали контекст - в якій формі його структурувати, щоб його зміг безпомилково читати АІ?
• як юрист може будувати context graphs для вирішення юридичних задач з АІ?
Це питання, які ми зібрали в безкоштовний 4-тижневий курс для юристів.
На курсі будемо розбирати:
• як кваліфікувати інформацію як контекст для юридичних задач
• як структурувати контекст і форматі графа
• як підключати context graph до Клода (Claude Projects)
• як створювати Скіли і евалити аутпути Клода при вирішення юр задач
• як зробити так щоб Клод працював як твій юридичний клон, а не як gen purpose ai.
Курс на англ. Робимо його безкоштовним, але стартуємо лише з 20 місць. Заявку можна подати за посиланням: https://legalbrainacademy.com/
В курс вкладені наші дослідження роботи з legal AI за останні 3 роки, тому дуже чекаємо поділитись цими знаннями з юридичною спільнотою!
• Harvey випустили власну юридичну АІ модель Tenet
• декілька тижнів потому це ж зробив Thomson Reuters
• після цього Біл Гейтс запропонував ввести “податок на АІ токени”
А також після хвиль “prompt engineering” (2024) і “harness engineering” (2025) АІ спільнота почала говорити про третій етап розвитку АІ - Context Graphs.
Що таке Context Graph?
Граф - це:
- онтологічні сутності (юр особа, контракт, акціонер, запис, каптейбл)
- і взаємозвʼязки між ними (юр особа [підписала] контракт [з] акціонером і [зробила] запис в [каптейбл])
Context Graph - це інформація, яка:
• необхідна для виконання задачі (“контекст задачі”), і
• яка структурована у вигляді графа (інформація розібрана на сутності і взаємозвʼязки).
Ми вже знаємо правило: “чим детальніший контекст - тим якісніший AI output”.
І є вже research papers (від Стенфорда і Майкрософта), які довели, що коли інформація для АІ структурована у вигляді графа знань - АІ:
• менше галюцинує (“deterministic inference”)
• менше палить токенів (бо швидше знаходить потрібну інформацію у графі в порівнянні з неструктурованими файлами)
Але відкритими залишаються питання:
• навіщо юридичним задачам контекст?
• як відрізняються AI outputs у випадках коли АІ має контекст, і коли він відсутній?
• як визначати яка інформація є корисною для контексту задачі, а яка - ні?
• коли зібрали контекст - в якій формі його структурувати, щоб його зміг безпомилково читати АІ?
• як юрист може будувати context graphs для вирішення юридичних задач з АІ?
Це питання, які ми зібрали в безкоштовний 4-тижневий курс для юристів.
На курсі будемо розбирати:
• як кваліфікувати інформацію як контекст для юридичних задач
• як структурувати контекст і форматі графа
• як підключати context graph до Клода (Claude Projects)
• як створювати Скіли і евалити аутпути Клода при вирішення юр задач
• як зробити так щоб Клод працював як твій юридичний клон, а не як gen purpose ai.
Курс на англ. Робимо його безкоштовним, але стартуємо лише з 20 місць. Заявку можна подати за посиланням: https://legalbrainacademy.com/
В курс вкладені наші дослідження роботи з legal AI за останні 3 роки, тому дуже чекаємо поділитись цими знаннями з юридичною спільнотою!
Legalbrainacademy
Legal Brain Academy — Legal Context Engineering
A selective, practical Legal AI program for ambitious early-career legal professionals. Build better context for legal AI and a career-ready skill for the future of legal work.
🔥11
Гра в суверенний АІ на юр ринку продовжується.
Після інвестиції $500М у власну Applied AI команду від Kirklands і релізу двох пост-трейнд моделей від Harvey і Thomson Reuters в гру вступає Latham and Watkins.
Деталей поки небагато, але починає прослідковуватись паттерн:
Першу половину 2026-го ми спостерігали за тим, як комодитизуються харнеси: OpenClaw, Hermes etc.
Схоже, що друга половина року пройде під коммодитизацією пост-тренінга.
Для юр ринку це означатиме три речі:
1) юр фірми почнуть перетворюватись в full-stack AI companies, будуючи власні Applied AI команди і наймаючи ресерчерів для пост-тренінга
2) почне рости попит на training data (бо юрфірми НЕ зможуть будувати бенчмарки і розгортати пост-трен на даних своїх клієнтів)
3) і попит на компют (це вже видно з пресс-реліза Воткінсів)
А наступного року ми ймовірно побачимо цей тренд і в мід маркеті -
і це буде момент, коли АІ агентів з власними харнесами і моделями будуть мати не лише BigLaw, але і юридичні бутіки.
Після інвестиції $500М у власну Applied AI команду від Kirklands і релізу двох пост-трейнд моделей від Harvey і Thomson Reuters в гру вступає Latham and Watkins.
Деталей поки небагато, але починає прослідковуватись паттерн:
Першу половину 2026-го ми спостерігали за тим, як комодитизуються харнеси: OpenClaw, Hermes etc.
Схоже, що друга половина року пройде під коммодитизацією пост-тренінга.
Для юр ринку це означатиме три речі:
1) юр фірми почнуть перетворюватись в full-stack AI companies, будуючи власні Applied AI команди і наймаючи ресерчерів для пост-тренінга
2) почне рости попит на training data (бо юрфірми НЕ зможуть будувати бенчмарки і розгортати пост-трен на даних своїх клієнтів)
3) і попит на компют (це вже видно з пресс-реліза Воткінсів)
А наступного року ми ймовірно побачимо цей тренд і в мід маркеті -
і це буде момент, коли АІ агентів з власними харнесами і моделями будуть мати не лише BigLaw, але і юридичні бутіки.
🔥5👍2
Нове покоління моделей Fable одержало нову архітектуру.
Відповідно, старі підходи до context engineering-га (в яких ми намагались засунути максимум контексту в системний промпт і CLAUDE.md файл) вже не працюють.
Тому Anthropic нещодавно опублікував оновлений гайд з context engineering для AI-агентів.
Тепер ключові джерела контексту, які використовує Claude Agent, виглядають так:
1) system prompt
2) skills
3) files
4) memory
5) tools & scripts
Як це працює на практиці?
Якщо взяти задачу regulatory counsel з проведення gap assessment - архітектура контексту для вирішення цієї задачі буде виглядати так:
1. System prompt — пояснює роль regulatory counsel та очікувану поведінку агента.
2. Files — надають джерела юридичної інформації (регуляції, політики, реєстри).
3. Skill — містить інструкцію, як проводити gap assessment, порівнюючи вимоги регуляторного акту з compliance evidence компанії.
4. Memory — зберігає інформацію про попередні gap assessments, щоб уникати дублікатів.
5. Tools & scripts — підказують агенту, які сайти регуляторів потрібно моніторити.
Якщо правильно заінженерити ці джерела контексту - Claude Agent почне працювати як regulatory counsel, а не як general-purpose AI.
Context engineering - це обвіс («скаффолд») агента, який дозволяє йому виконувати задачі так, як ви це робите, і уникати generic AI slop.
Відповідно, старі підходи до context engineering-га (в яких ми намагались засунути максимум контексту в системний промпт і CLAUDE.md файл) вже не працюють.
Тому Anthropic нещодавно опублікував оновлений гайд з context engineering для AI-агентів.
Тепер ключові джерела контексту, які використовує Claude Agent, виглядають так:
1) system prompt
2) skills
3) files
4) memory
5) tools & scripts
Як це працює на практиці?
Якщо взяти задачу regulatory counsel з проведення gap assessment - архітектура контексту для вирішення цієї задачі буде виглядати так:
1. System prompt — пояснює роль regulatory counsel та очікувану поведінку агента.
2. Files — надають джерела юридичної інформації (регуляції, політики, реєстри).
3. Skill — містить інструкцію, як проводити gap assessment, порівнюючи вимоги регуляторного акту з compliance evidence компанії.
4. Memory — зберігає інформацію про попередні gap assessments, щоб уникати дублікатів.
5. Tools & scripts — підказують агенту, які сайти регуляторів потрібно моніторити.
Якщо правильно заінженерити ці джерела контексту - Claude Agent почне працювати як regulatory counsel, а не як general-purpose AI.
Context engineering - це обвіс («скаффолд») агента, який дозволяє йому виконувати задачі так, як ви це робите, і уникати generic AI slop.
👍9
Legora будує власну юридичну онтологію.
Що це і навіщо?
Онтологія - це:
- набір юридичних концептів (parties, considerations, warranties, remedies)
- і взаємозвʼязків між ними (ака “warranty breach -> results in other’s party remedy”)
На юрфаках нас (юристів) тренували читати юридичний текст крізь онтологію права -
це коли читаєш контракт «по діагоналі», намагаючись знайти очима [обовʼязки сторін] чи [відповідальність за порушення].
А потім складаєш це в більш цілісну картинку, щоб відповісти на запитання «вносим правки чи ні».
Іншими словами, онтологія - це інструмент, який допомагає спрямовувати нашу увагу на ту інформацію, яка необхідна для прийняття рішення чи вирішення задачі.
Така інформація, у свою чергу, є контекстом задачі чи рішення.
Когнітивний воркфлоу:
1) увага пропускає текст крізь юр онтологію
2) онтологія допомагає виділити з тексту контекст
3) контекст допомагає виконати задачу.
Без онтології нам приходилось би намагатись в наше «біологічне контекстне вікно» помістити ВЕСЬ юридичний текст (а не лише ключові концепти).
А це дуже швидко привело б до information overload, з яким наш біологічний мозок не справлявся б.
Аналогічно з АІ агентами:
1) в агента є контекстне вікно
2) воно обмежене (1М токенів)
3) якщо засунути в нього ВСЮ можливу регуляторку і весь датарум клієнта - агент НЕ знатиме на що звертати увагу при виконанні задачі по дью ділу чи комплаєнс ассессменту
4)онтологія стає таким «компасом» для уваги Агента - допомагаючи йому шукати і аналізувати в першу чергу ті концепти і їх взаємозвʼязки, які важливі для задачі («контекст задачі»).
Саме тому Легора почала робити юридичну онтологію, яку АІ агент використовує для швидкої навігації по міжнародній регуляторці.
Ймовірні апсайди агента, який робить legal research з використанням онтології:
-менше галюцинує
-менше палить токенів
Але треба дочекатись бенчмарків. Бо поки звучить як маркетинг.
Що це і навіщо?
Онтологія - це:
- набір юридичних концептів (parties, considerations, warranties, remedies)
- і взаємозвʼязків між ними (ака “warranty breach -> results in other’s party remedy”)
На юрфаках нас (юристів) тренували читати юридичний текст крізь онтологію права -
це коли читаєш контракт «по діагоналі», намагаючись знайти очима [обовʼязки сторін] чи [відповідальність за порушення].
А потім складаєш це в більш цілісну картинку, щоб відповісти на запитання «вносим правки чи ні».
Іншими словами, онтологія - це інструмент, який допомагає спрямовувати нашу увагу на ту інформацію, яка необхідна для прийняття рішення чи вирішення задачі.
Така інформація, у свою чергу, є контекстом задачі чи рішення.
Когнітивний воркфлоу:
1) увага пропускає текст крізь юр онтологію
2) онтологія допомагає виділити з тексту контекст
3) контекст допомагає виконати задачу.
Без онтології нам приходилось би намагатись в наше «біологічне контекстне вікно» помістити ВЕСЬ юридичний текст (а не лише ключові концепти).
А це дуже швидко привело б до information overload, з яким наш біологічний мозок не справлявся б.
Аналогічно з АІ агентами:
1) в агента є контекстне вікно
2) воно обмежене (1М токенів)
3) якщо засунути в нього ВСЮ можливу регуляторку і весь датарум клієнта - агент НЕ знатиме на що звертати увагу при виконанні задачі по дью ділу чи комплаєнс ассессменту
4)онтологія стає таким «компасом» для уваги Агента - допомагаючи йому шукати і аналізувати в першу чергу ті концепти і їх взаємозвʼязки, які важливі для задачі («контекст задачі»).
Саме тому Легора почала робити юридичну онтологію, яку АІ агент використовує для швидкої навігації по міжнародній регуляторці.
Ймовірні апсайди агента, який робить legal research з використанням онтології:
-менше галюцинує
-менше палить токенів
Але треба дочекатись бенчмарків. Бо поки звучить як маркетинг.
🔥5
Як юрист я щодня намагаюсь знаходити час на читання регуляторних новин.
Ці новини надходять з різних джерел:
- розсилки вендорів
- експертні блоги
- сайти регуляторів
В якийсь момент я зрозумів, що щодня витрачаю на це 1h+
Протягом тижня воно набігає на пів роб дня.
А в міс назбирується на цілих пів тижня.
Ця математика наштовхнула на думку: чи можу я дати Клоду задачу робити цей регуляторний моніторинг за мене?
Але так щоб він не просто збирав всі новини в один список.
А щоб ще фільтрував ті, які релевантні для мене, і підказував до чого готуватись.
Іншими словами: щоб Клод читав новини, контекстуалізуючи їх під мій бізнес.
Зробив під це воркфлоу:
1) зі списком сайтів, як «дають» себе моніторити,
2) зі структурованим контекстом мого бізнесу (“legal brain”)
3) зі скілом, який поясняє як аналізувати регуляторку на базі бізнес-контексту
4) з простенькою базою даних в GSheets, щоб уникати дублікатів
1го жовтня буду ділитись цим сетапом на безкоштовному live workshop.
Будемо автоматизовувати регуляторний моніторинг, щоб зменшувати час на мануальне читання і аналіз.
Приєднуйтесь!
Посилання для реєстрації:
https://riverside.com/webinar/registration/eyJldmVudElkIjoiNmFhM2MxYTBmZmYyNGM2YzRmNGJmMjQxIiwic2x1ZyI6Im5lc3RvcnMtc3R1ZGlvLUowNnFmIn0=
Ці новини надходять з різних джерел:
- розсилки вендорів
- експертні блоги
- сайти регуляторів
В якийсь момент я зрозумів, що щодня витрачаю на це 1h+
Протягом тижня воно набігає на пів роб дня.
А в міс назбирується на цілих пів тижня.
Ця математика наштовхнула на думку: чи можу я дати Клоду задачу робити цей регуляторний моніторинг за мене?
Але так щоб він не просто збирав всі новини в один список.
А щоб ще фільтрував ті, які релевантні для мене, і підказував до чого готуватись.
Іншими словами: щоб Клод читав новини, контекстуалізуючи їх під мій бізнес.
Зробив під це воркфлоу:
1) зі списком сайтів, як «дають» себе моніторити,
2) зі структурованим контекстом мого бізнесу (“legal brain”)
3) зі скілом, який поясняє як аналізувати регуляторку на базі бізнес-контексту
4) з простенькою базою даних в GSheets, щоб уникати дублікатів
1го жовтня буду ділитись цим сетапом на безкоштовному live workshop.
Будемо автоматизовувати регуляторний моніторинг, щоб зменшувати час на мануальне читання і аналіз.
Приєднуйтесь!
Посилання для реєстрації:
https://riverside.com/webinar/registration/eyJldmVudElkIjoiNmFhM2MxYTBmZmYyNGM2YzRmNGJmMjQxIiwic2x1ZyI6Im5lc3RvcnMtc3R1ZGlvLUowNnFmIn0=
🔥10
Вийшла відповідь ОпенАІ на Claude for Legal:
Astra for Law
Більшість фіч ми вже бачили в весняному релізі Антропіка:
- плагіни під різні practice areas
- бібліотека юридичних скілів
- конектор з Вордом
З цікавого - legal research.
1) OAI зробили власний search index.
Наче заявляють, що проіндексували 230млн urls (case law, акти, статути) і тепер GPT вміє цитувати регуляторку без галюцинацій.
2) legal research capability прогнали ч-з лігал сьорч бенч від Vals AI - і там Астра обігнала останній Фейбл.
Поки legal search працює тільки по американській регуляторці, але як тільки почне скейлитись в іншій країни - це стане game changer в регуляторній роботі.
Прес реліз: https://openai.com/index/astra-for-law/
Astra for Law
Більшість фіч ми вже бачили в весняному релізі Антропіка:
- плагіни під різні practice areas
- бібліотека юридичних скілів
- конектор з Вордом
З цікавого - legal research.
1) OAI зробили власний search index.
Наче заявляють, що проіндексували 230млн urls (case law, акти, статути) і тепер GPT вміє цитувати регуляторку без галюцинацій.
2) legal research capability прогнали ч-з лігал сьорч бенч від Vals AI - і там Астра обігнала останній Фейбл.
Поки legal search працює тільки по американській регуляторці, але як тільки почне скейлитись в іншій країни - це стане game changer в регуляторній роботі.
Прес реліз: https://openai.com/index/astra-for-law/
🔥6
Jev - перша АІ модель, яка мислить системно, але не вміє говорити
В 2025 я активно використовував n8n для автоматизацій процесів.
Щось навіть трохи получилося:
- сорсинг новин про конкурентів з інтернету і відправка їх аналізу в телеграм
- фільтування розсилок в імейлі
- навіть пробував трошки автоматизувати notetaking (скидав в телеграм канал цікаву статтю - n8n забирав її звідти і додавав у відповідну замітку в моєму обсідіані).
Мій воркфлоу з n9n був наступним:
1) я відкривав два паралельних вікна: зліва - ChatGPT, справа - n8n
2) давав GPT права «дивитись» в n8n
3) промптив GPT, щоб той крок за кроком інструктував мене як будувати автоматизовані workflows в n8n
З переходом в Claude Code з конекторами я перестав використовувати n8n - бо Claude Code сам знає як зʼєднати всі «ноди» мого воркфлоу в систему.
Але треба було багато ітерувати і намагатись моєю «не-інженерною» мовою пояснити клоду що я хочу досягти.
Зараз читаю про Jev (ще не тестив) і перше враження - що це наступний крок для автоматизацій після клод кода.
З цікавого:
- модель не чатиться з юзером
- ви даєте моделі «world state» (в моєму прикладі з фільтуванням імейл розсилок:
а) ціль сортування
б) критерії / рубрики того що вважається успішно посортованим інбоксом
в)доступ до пошти
-модель видає результат - імейли, які розсортовані по різних папках («важливе», «партнерське», «новинне», «спам» і тд)
Очевидно, що це також може зробити GPT чи Клод.
Але Jev робить це за долю секунди і за менш ніж 1 цент.
Виглядає так, що Jev не буде особливо корисним для creative industries, де потрібно писати ессе, генерувати креативи і тд.
Але наприклад для автоматизації data pipelines це виглядає як game changer.
Інший цікавий факт: класичний пропмтинг замінюється на системний context engineering - на побудову world state для Jev.
Тому і модель називається вже не large language, а system one.
Тобто, перша модель з «системним мисленням».
В 2025 я активно використовував n8n для автоматизацій процесів.
Щось навіть трохи получилося:
- сорсинг новин про конкурентів з інтернету і відправка їх аналізу в телеграм
- фільтування розсилок в імейлі
- навіть пробував трошки автоматизувати notetaking (скидав в телеграм канал цікаву статтю - n8n забирав її звідти і додавав у відповідну замітку в моєму обсідіані).
Мій воркфлоу з n9n був наступним:
1) я відкривав два паралельних вікна: зліва - ChatGPT, справа - n8n
2) давав GPT права «дивитись» в n8n
3) промптив GPT, щоб той крок за кроком інструктував мене як будувати автоматизовані workflows в n8n
З переходом в Claude Code з конекторами я перестав використовувати n8n - бо Claude Code сам знає як зʼєднати всі «ноди» мого воркфлоу в систему.
Але треба було багато ітерувати і намагатись моєю «не-інженерною» мовою пояснити клоду що я хочу досягти.
Зараз читаю про Jev (ще не тестив) і перше враження - що це наступний крок для автоматизацій після клод кода.
З цікавого:
- модель не чатиться з юзером
- ви даєте моделі «world state» (в моєму прикладі з фільтуванням імейл розсилок:
а) ціль сортування
б) критерії / рубрики того що вважається успішно посортованим інбоксом
в)доступ до пошти
-модель видає результат - імейли, які розсортовані по різних папках («важливе», «партнерське», «новинне», «спам» і тд)
Очевидно, що це також може зробити GPT чи Клод.
Але Jev робить це за долю секунди і за менш ніж 1 цент.
Виглядає так, що Jev не буде особливо корисним для creative industries, де потрібно писати ессе, генерувати креативи і тд.
Але наприклад для автоматизації data pipelines це виглядає як game changer.
Інший цікавий факт: класичний пропмтинг замінюється на системний context engineering - на побудову world state для Jev.
Тому і модель називається вже не large language, а system one.
Тобто, перша модель з «системним мисленням».
🔥4👎1
This media is not supported in your browser
VIEW IN TELEGRAM
Соц мережі заповнені новинами про Jev, який сортує імейли в інбоксі.
А якщо замість імейлів дати Jev задачу моніторити і сортувати акти на сайтах регуляторів?
Юристи витрачають на цю задачу години, з яких:
• перші 15-20 хв ще якось вдається тримати увагу, аналізуючи їх застосовність цих актів до бізнесу
• а решту часу це просто скроллинг по діагоналі і пошук по ключових словах.
Наступного тижня на live воркшопі спробуємо автоматизувати такий workflow з АІ.
А якщо замість імейлів дати Jev задачу моніторити і сортувати акти на сайтах регуляторів?
Юристи витрачають на цю задачу години, з яких:
• перші 15-20 хв ще якось вдається тримати увагу, аналізуючи їх застосовність цих актів до бізнесу
• а решту часу це просто скроллинг по діагоналі і пошук по ключових словах.
Наступного тижня на live воркшопі спробуємо автоматизувати такий workflow з АІ.
🔥8👍1
Чим більше ми працюєм з юр командами над впровадженням АІ - тим більше переконуюсь, що найважливішим скілом лігал інженера є Benchmark Design.
Кожна автоматизація повинна починатись з бенчмарка.
Проте сьогодні лігал інженери найчастіше описуються як експерти, які вміють:
1) декомпозувати юр задачі
2) визначати конектори для сорсинга контексту, який необхідний для виконання задачі
3) створювати скіли (.md інструкції для Клода).
І часто забувають, що лігал інженер на то і «лігал», що окрім знання Клода ще має мати експертизу в конкретній юрисдикції і сфері права (напр EU GDPR чи US corporate law).
Юр експертиза в автоматизації потрібна для того, щоб знати як виглядає «золотий стандарт» виконаної юридичної задачі, з яким потім можна буде порівняти аутпут АІ (зробити так звані evals).
Розглянем на прикладі задачі «ревʼю DPA софтверного вендора» з домену EU GDPR.
«Золотий стандарт» її виконання - це коли ревʼю такого DPA виконано відповідно до критеріїв:
1) legal soundness
2) grounding & citations
3) reasoning
Такі критерії в АІ ресерчі ще називають рубриками, а опис таски + приклад «ідеального» ревʼю яке зробив експерт + інструкція = складають семпл бенча.
Тобто, іншими словами «бенчмарк» - це декомпозована задача в ідеальному виконанні Експерта.
Без детально задизайненого бенчмарка процес автоматизації нагадує ходіння в темряві:
лігал інженер автоматизовує воркфлоу - але не може ніяк оцінити чи АІ аутпут якісний чи ні.
Бо немає проти чого оцінювати. Немає бенчмарка.
Тому ще ДО того як автоматизовувати будь-яку юр задачу - лігал інженер повинен спочатку задизайнити її бенчмарк.
А дизайнити бенчмарки - це окремий скіл, який вимагає так званого «мета-когнітивного» зусилля.
Цього тижня відбудеться перша лекція нашої Legal Brain Academy, і з 15-ма учасниками, які пройшли відбір на курс, в рамках context engineering-a ми також будемо розбирати дизайн бенчмарків і the art of metacognition.
Три місяці наша команда інтенсивно працювала над розробкою Академії і я дуже excited щодо її старту!
Кожна автоматизація повинна починатись з бенчмарка.
Проте сьогодні лігал інженери найчастіше описуються як експерти, які вміють:
1) декомпозувати юр задачі
2) визначати конектори для сорсинга контексту, який необхідний для виконання задачі
3) створювати скіли (.md інструкції для Клода).
І часто забувають, що лігал інженер на то і «лігал», що окрім знання Клода ще має мати експертизу в конкретній юрисдикції і сфері права (напр EU GDPR чи US corporate law).
Юр експертиза в автоматизації потрібна для того, щоб знати як виглядає «золотий стандарт» виконаної юридичної задачі, з яким потім можна буде порівняти аутпут АІ (зробити так звані evals).
Розглянем на прикладі задачі «ревʼю DPA софтверного вендора» з домену EU GDPR.
«Золотий стандарт» її виконання - це коли ревʼю такого DPA виконано відповідно до критеріїв:
1) legal soundness
2) grounding & citations
3) reasoning
Такі критерії в АІ ресерчі ще називають рубриками, а опис таски + приклад «ідеального» ревʼю яке зробив експерт + інструкція = складають семпл бенча.
Тобто, іншими словами «бенчмарк» - це декомпозована задача в ідеальному виконанні Експерта.
Без детально задизайненого бенчмарка процес автоматизації нагадує ходіння в темряві:
лігал інженер автоматизовує воркфлоу - але не може ніяк оцінити чи АІ аутпут якісний чи ні.
Бо немає проти чого оцінювати. Немає бенчмарка.
Тому ще ДО того як автоматизовувати будь-яку юр задачу - лігал інженер повинен спочатку задизайнити її бенчмарк.
А дизайнити бенчмарки - це окремий скіл, який вимагає так званого «мета-когнітивного» зусилля.
Цього тижня відбудеться перша лекція нашої Legal Brain Academy, і з 15-ма учасниками, які пройшли відбір на курс, в рамках context engineering-a ми також будемо розбирати дизайн бенчмарків і the art of metacognition.
Три місяці наша команда інтенсивно працювала над розробкою Академії і я дуже excited щодо її старту!
🔥6👍2
Вчора я зробив пост про Benchmark Design як один з найважливіших скілів лігал інженера.
Після цього отримав трохи пушбека від команди та колег:
1) хіба benchmark - це не просто історичні результати роботи юр команди?
2) у Skills вже є success criteria в інструкціях - хіба цього недостатньо для оцінки AI outputs?
3) кожен плейбук по аналізу контракту містить референс того “what good looks like” - це можна вважати бенчмарком?
Всі ці коментарі валідні.
Але ні історичні work products, ні success criteria самі по собі не роблять оцінювання AI аутпутів вимірюваним.
Що означає “вимірюваний” AI evaluation?
Це означає, що кожен критерій оцінки (rubric) повинен мати свою систему скоринга.
Наприклад, візьмемо критерій context grounding.
Для оцінки цього критерію визначимо шкалу, де:
1 = poor context grounding
5 = reliable context grounding
Таку ж шкалу можна зробити для критеріїв reasoning, legal soundness, citations, completeness, formatting, тощо.
Для перших 5–10 аутпутів агента такий скоринг має проводити domain Expert.
Пізніше можна підключати LLM-as-a-judge (зазвичай, сильніша модель яка має пройти alignment з евалами експерта).
В результаті евалів ми отримуємо scorecard, де кожен rubric має свою оцінку.
Наприклад:
Legal soundness — 4
Reasoning — 5
Context grounding — 2
На базі такого scorecard Legal Engineer отримує сигнал для подальшого тренування Агента:
агент добре робить reasoning (оцінка 5) АЛЕ погано працює з context grounding (оцінка 2)
Це дозволяє лігал інженеру перестати рандомно змінювати промпти - і сфокусуватись на перевірці тієї частини архітектури агента, яка відповідає за пошук та отримання необхідного контексту (connectors, retrieval logic, context selection ітд)
Такий підхід з measurable benchmarks перетворює розробку агента з лінійного процесу на процес по спіралі:
Benchmark → evaluation → diagnostic signal → improvement → evaluation again.
Бо без детально задизайненого бенчмарка оцінювання агентських аутпутів перетворюється на “vibe check” :)
А vibe check не дає корисного сигналу для покращення Agent.
Саме тому я переконаний, що кожна юр автоматизація має починатися з Benchmark Design.
І кожен Legal Engineer має вміти це робити.
Після цього отримав трохи пушбека від команди та колег:
1) хіба benchmark - це не просто історичні результати роботи юр команди?
2) у Skills вже є success criteria в інструкціях - хіба цього недостатньо для оцінки AI outputs?
3) кожен плейбук по аналізу контракту містить референс того “what good looks like” - це можна вважати бенчмарком?
Всі ці коментарі валідні.
Але ні історичні work products, ні success criteria самі по собі не роблять оцінювання AI аутпутів вимірюваним.
Що означає “вимірюваний” AI evaluation?
Це означає, що кожен критерій оцінки (rubric) повинен мати свою систему скоринга.
Наприклад, візьмемо критерій context grounding.
Для оцінки цього критерію визначимо шкалу, де:
1 = poor context grounding
5 = reliable context grounding
Таку ж шкалу можна зробити для критеріїв reasoning, legal soundness, citations, completeness, formatting, тощо.
Для перших 5–10 аутпутів агента такий скоринг має проводити domain Expert.
Пізніше можна підключати LLM-as-a-judge (зазвичай, сильніша модель яка має пройти alignment з евалами експерта).
В результаті евалів ми отримуємо scorecard, де кожен rubric має свою оцінку.
Наприклад:
Legal soundness — 4
Reasoning — 5
Context grounding — 2
На базі такого scorecard Legal Engineer отримує сигнал для подальшого тренування Агента:
агент добре робить reasoning (оцінка 5) АЛЕ погано працює з context grounding (оцінка 2)
Це дозволяє лігал інженеру перестати рандомно змінювати промпти - і сфокусуватись на перевірці тієї частини архітектури агента, яка відповідає за пошук та отримання необхідного контексту (connectors, retrieval logic, context selection ітд)
Такий підхід з measurable benchmarks перетворює розробку агента з лінійного процесу на процес по спіралі:
Benchmark → evaluation → diagnostic signal → improvement → evaluation again.
Бо без детально задизайненого бенчмарка оцінювання агентських аутпутів перетворюється на “vibe check” :)
А vibe check не дає корисного сигналу для покращення Agent.
Саме тому я переконаний, що кожна юр автоматизація має починатися з Benchmark Design.
І кожен Legal Engineer має вміти це робити.
🔥8👍2
Перша open-weight AI model, яка «перемогла» Фейбл на бенчмарку Харві.
“Open-weight” означає що будь-хто може скачати її «ваги», зафайнтюнити під свої задачі, і захостити на своїх серверах.
Це, у свою чергу, означає:
1) повний анлім по токенах
2) і сто-відсоткове data sovereignty
І по перформансу - це на рівні Фейбл.
Якщо озирнутись назад - цього літа три BigLaw нахайрили post-training teams і накупили компют (Кіркландс, Латам і Лінклейтерс).
Я думаю вже зовсім скоро буде реліз їхніх моделей (під якими буде пост-трейн GML - так само як Харві робив пострен Кімі, а Ройтерс - Квена).
Але щоб зробити якісний пост-трен - юрфірмам недостатньо мати open-weight model і компют.
Їм також потрібні дата пайплайни і пропріетарні бенчмарки.
Ось це основна експертиза в legal AI, на яку я роблю ставку в наступному році.
Бо вже стає очевидно, що наступний рік буде на 100% про sovereign AI.
“Open-weight” означає що будь-хто може скачати її «ваги», зафайнтюнити під свої задачі, і захостити на своїх серверах.
Це, у свою чергу, означає:
1) повний анлім по токенах
2) і сто-відсоткове data sovereignty
І по перформансу - це на рівні Фейбл.
Якщо озирнутись назад - цього літа три BigLaw нахайрили post-training teams і накупили компют (Кіркландс, Латам і Лінклейтерс).
Я думаю вже зовсім скоро буде реліз їхніх моделей (під якими буде пост-трейн GML - так само як Харві робив пострен Кімі, а Ройтерс - Квена).
Але щоб зробити якісний пост-трен - юрфірмам недостатньо мати open-weight model і компют.
Їм також потрібні дата пайплайни і пропріетарні бенчмарки.
Ось це основна експертиза в legal AI, на яку я роблю ставку в наступному році.
Бо вже стає очевидно, що наступний рік буде на 100% про sovereign AI.
🔥4
Я вірю в те, що корпорати платять юрфімам НЕ за виконану юр роботу.
В першу чергу вони платять за трансфер відповідальності.
Один з підтверджень цього тезису - вимога щодо страховки проф відповідальності, яка є в кожному вендор чеклісті ентерпрайзів.
Правило проте: нема страховки - нема контракту.
Минулого року я був дуже bullish щодо концепту AI-native firm (це можна простежити з минулорічних постів).
Але змінив свою думку після того, як усвідомив, що трансфер відповідальності є головним value prop в ентерпрайз контрактах на професійні послуги.
Це також допомогло зрозуміти, що головним барʼєром АІ адопшина є НЕ низькі оцінки агентів на юридичних бенчмарках, а gap у питанні того хто відповідальний за роботу, яку агент зафейлив.
Але нещодавно Crosby (американська AI-native law firm, $80M raised) заінтродюсила страховку для агентів - і це знову заставило мене переглянути ставлення до АІ юрфірм.
Якщо така agentic law firm може знайти андеррайтера, який готовий покрити фін втрати, які настали у звʼязку з неякісною роботою агента - тоді страховка агента має задовольнити вендор чекліст ентерпрайз клієнта.
І це, у свою чергу, має вирішити боттлнек АІ адопшина в professional services, який повʼязаний зі страхуванням АІ ризиків.
Кросбі поки єдина АІ юрфірма, яка активно піарить страхування своїх юр агентів.
Цікаво, чи це справді допомагає їм успішніше проходити онбординги у вендорів.
В першу чергу вони платять за трансфер відповідальності.
Один з підтверджень цього тезису - вимога щодо страховки проф відповідальності, яка є в кожному вендор чеклісті ентерпрайзів.
Правило проте: нема страховки - нема контракту.
Минулого року я був дуже bullish щодо концепту AI-native firm (це можна простежити з минулорічних постів).
Але змінив свою думку після того, як усвідомив, що трансфер відповідальності є головним value prop в ентерпрайз контрактах на професійні послуги.
Це також допомогло зрозуміти, що головним барʼєром АІ адопшина є НЕ низькі оцінки агентів на юридичних бенчмарках, а gap у питанні того хто відповідальний за роботу, яку агент зафейлив.
Але нещодавно Crosby (американська AI-native law firm, $80M raised) заінтродюсила страховку для агентів - і це знову заставило мене переглянути ставлення до АІ юрфірм.
Якщо така agentic law firm може знайти андеррайтера, який готовий покрити фін втрати, які настали у звʼязку з неякісною роботою агента - тоді страховка агента має задовольнити вендор чекліст ентерпрайз клієнта.
І це, у свою чергу, має вирішити боттлнек АІ адопшина в professional services, який повʼязаний зі страхуванням АІ ризиків.
Кросбі поки єдина АІ юрфірма, яка активно піарить страхування своїх юр агентів.
Цікаво, чи це справді допомагає їм успішніше проходити онбординги у вендорів.
🔥4