Як Harvey використовує Claude для legal workflows і domain evals
Production-розбір Harvey + Claude: long-context legal work, BigLaw Bench, human checkpoints, model-upgrade evals, confidentiality controls і rollout без магічної legal accuracy.
Картка кейсу
Що тут автоматизовано
Обсяг автоматизації
Claude виконує складний analysis/drafting у Harvey Assistant, Vault і Workflows; public case описує інтерактивні checkpoints, де legal professional переглядає й затверджує work product.
Роль людини
Legal professionals і domain researchers визначають task/evaluation policy, перевіряють material issues, редагують outputs і зберігають authority над consequential legal judgment.
Заявлені результати
- Claude deployed across Harvey platform менш ніж за один місяць
- Statistically significant improvements у complex long-context workflows за Harvey evaluation
- Harvey reported 91,3% BigLaw Bench score для Sonnet 5 у червні 2026
Anthropic/Harvey customer story підтверджує швидкий deployment, strong proprietary BigLaw Bench performance і statistically significant long-context improvements. Harvey 2026 releases підтверджують Sonnet 5/Opus 5 availability та власні benchmark updates. Усі benchmark цифри трактуються як Harvey proprietary results, не універсальна legal accuracy. AI-Magister controls — reproduction guidance.
Зміст статті
- 01Бізнес-задача: AI у legal workflow має бути корисним і перевірюваним
- 02Workflow: documents → scoped task → model reasoning → checkpoints → final work product
- 03Evaluation: чому загального benchmark недостатньо
- 04Reported metrics і current model evidence
- 05Data, privacy і tenant isolation
- 06Failure modes: long context не дорівнює grounded truth
- 07Authority і autonomy A3
- 08Як повторити: domain eval before model choice
Передумови
Бізнес-задача: AI у legal workflow має бути корисним і перевірюваним
Legal AI працює з довгими договорами, due diligence, litigation material і compliance, де гарно написана помилка може коштувати значно дорожче за повільну відповідь. Harvey інтегрував Claude у domain-specific platform і оцінює моделі не лише на загальних benchmarks, а через власний BigLaw Bench, product environments і перевірку legal та AI researchers.
Anthropic customer story повідомляє, що Claude був розгорнутий у Harvey менш ніж за місяць, показав один із найсильніших результатів на їх proprietary evaluation і statistically significant improvements у складних long-context workflows. Це provider/customer evidence, не незалежний legal benchmark. Сильна частина кейсу — не headline score, а дисципліна: model selection прив'язаний до domain evals.
architecture
Карта системи: Як Harvey використовує Claude для legal workflows і domain evals
Workflow: documents → scoped task → model reasoning → checkpoints → final work product
Harvey описує Assistant, Vault і Workflows, де legal users працюють із документами та end-to-end tasks. Відтворюваний pattern: визначити matter/tenant і authorized sources, нормалізувати documents, поставити конкретну legal task, отримати structured intermediate work, дати reviewer checkpoint, зафіксувати edits/approval і лише після цього сформувати final artifact.
Human-in-the-loop тут не декоративний. Customer story прямо описує checkpoints, де користувач може додати, змінити, видалити або переформувати content перед approval. Це правильна authority boundary для high-stakes knowledge work: модель прискорює synthesis і reasoning, але professional judgment, client-specific interpretation і consequential filing або advice не стають автоматично model-owned.
- Scope → matter, user, jurisdiction, authorized corpus.
- Retrieve/read → exact documents and versions.
- Reason → task-specific analysis або draft.
- Cite/trace → evidence to source passages where supported.
- Checkpoint → lawyer edits, approves або escalates.
- Finalize → work product with version/provenance.
- Evaluate → substance + form + hallucination/materiality errors.
timeline
Контрольні точки для практичного застосування
- Scope → matter, user, jurisdiction, authorized corpus.
Контрольна теза з матеріалу статті.
- Retrieve/read → exact documents and versions.
Контрольна теза з матеріалу статті.
- Reason → task-specific analysis або draft.
Контрольна теза з матеріалу статті.
- Cite/trace → evidence to source passages where supported.
Контрольна теза з матеріалу статті.
- Checkpoint → lawyer edits, approves або escalates.
Контрольна теза з матеріалу статті.
- Finalize → work product with version/provenance.
Контрольна теза з матеріалу статті.
Evaluation: чому загального benchmark недостатньо
Harvey описує три шари оцінки: proprietary BigLaw Bench, реальні product environments і unstructured assessment AI та legal researchers. У BigLaw Bench оцінюють substance — accuracy, materiality, hallucination — та form: tone, length, formatting. Така схема набагато ближча до production truth, ніж одна leaderboard цифра.
У 2026 Harvey продовжує публічно оновлювати model portfolio: Sonnet 5 та Opus 5 доступні у відповідних product surfaces, а Harvey публікує власні benchmark results для нових releases. Це current product evidence, але його не слід змішувати з первинним integration case. Для AI-Magister головний pattern — кожен model upgrade проходить domain eval before routing або rollout.
Reported metrics і current model evidence
Anthropic/Harvey повідомляють deployment Claude across platform менш ніж за місяць і statistically significant improvements у complex long-context workflows. Harvey у червні 2026 повідомив, що Claude Sonnet 5 набрав 91,3% на їх BigLaw Bench — найвищий зафіксований Harvey результат серед Sonnet та Opus на момент публікації. У липні 2026 Harvey також зробив Opus 5 доступним у Model Selector.
Ці числа — Harvey proprietary evaluation, не універсальна legal accuracy. Вони не означають 91,3% «правильних юридичних відповідей» у будь-якій юрисдикції. Для власного deployment потрібні task-level metrics: issue spotting, citation validity, clause extraction accuracy, material omission rate, unsupported claim rate, reviewer correction severity, time-to-approved-work-product і critical-error ceiling.
Data, privacy і tenant isolation
Legal workload часто містить privileged, confidential або deal-sensitive data, тому architecture починається з identity й matter boundary. Retrieval має бачити лише дозволений corpus, temporary uploads не повинні випадково стати shared knowledge, а cross-matter leakage тестується adversarially. Model/provider policy не замінює application-side access control.
Для audit зберігайте source/version IDs, task contract, model/version, retrieval evidence, generated artifact hash, reviewer edits і final approval — але retention має відповідати legal/data policy. Логи з повними договорами «для observability» можуть створити новий uncontrolled repository. Мінімізація даних тут є і security control, і operational discipline.
Failure modes: long context не дорівнює grounded truth
Модель може добре працювати з великим контекстом і все одно пропустити критичний exception, переплутати amendment version, зробити unsupported inference або надати правильне правило не для тієї jurisdiction. Тому потрібні versioned source packs, conflict detection, explicit unknown/abstain behavior і critical-issue checklist.
Другий ризик — automation bias: красивий draft прискорює review настільки, що reviewer перестає шукати omission. Розв'язання — targeted graders і blind spot tests: навмисно підмішати superseded clause, contradictory schedules, missing annex, adverse precedent або prompt injection у document text. High-severity miss блокує rollout незалежно від середнього score.
Як повторити: domain eval before model choice
Виберіть 30–100 завершених legal tasks із approved work product і source corpus. Розбийте scoring на substance і form; substance має більшу вагу для high-risk tasks. Додайте material omissions, hallucinations, citation errors і jurisdiction mistakes як hard failures. Запустіть кілька моделей blind, не показуючи reviewer brand або model, і порівняйте не лише quality, а reviewer time та cost.
Після offline eval — shadow mode на live matters, потім bounded pilot для одного workflow, наприклад contract review. Model upgrade або prompt/retrieval change проходить regression set. Production KPI — time to approved work product при незмінному або кращому critical-error budget. Якщо модель пише удвічі швидше, а senior lawyer витрачає стільки ж часу на verification, business outcome не змінився.
Практичні приклади
Приклад: contract review із material-omission gate
Matter workspace містить master agreement, amendments і current policy. AI формує issue table з evidence pointers. Reviewer перевіряє material clauses та high-severity exceptions; навмисно superseded amendment у eval set повинен бути виявлений. Final memo створюється тільки після human approval, а model upgrade повторно проходить той самий regression set.
FAQ
Чи означає 91,3% BigLaw Bench, що Claude має 91,3% юридичної точності?
Ні. Це proprietary Harvey benchmark result для конкретної моделі й набору tasks. Його не можна переносити на всі юридичні питання, юрисдикції або workflows.
Навіщо domain eval, якщо модель сильна на загальних benchmarks?
Production failure визначається вашими material omissions, citation errors, jurisdiction mistakes і reviewer workload. Загальний benchmark не моделює конкретний legal process та risk budget.
Який рівень автономності доречний для legal AI?
Для описаного public case — A3: автоматизований analysis і drafting із explicit human checkpoints. Consequential legal judgment і зовнішні дії залишаються за qualified people та application controls.
Пов’язані матеріали
Production-розбір кейсу Rakuten: довгі автономні coding tasks, паралельна робота, verification gates, reported 79% time-to-market reduction і шлях до managed agents.
Як Apollo масштабує outbound sales із Claude: +35% meeting bookings у reported caseРозбір Claude + Apollo: signal aggregation, персоналізація, MCP/connector actions, human approval, attribution і безпечний rollout для B2B outbound.
Як Claude бере на себе до 90% support tickets: кейс KodifKodif використовує Claude в Amazon Bedrock не як FAQ-бота, а як ядро AI-агентів, які розбирають звернення, працюють із knowledge base, запускають refunds і cancellations через підключені інструменти та перетворюють support-дані на бізнес-сигнали.
RAG з нуля: від документа до перевіреної відповідіProduction-конвеєр RAG: ingestion, нормалізація, chunking, embeddings, retrieval, reranking, grounded generation, цитати й evaluation.
Оцінювання LLM-систем у productionЯк побудувати evaluation set, автоматичні та людські метрики, regression gates і спостережуваність для промптів, RAG та агентів.
Red teaming LLM-системПрактичний red teaming перетворює припущення про безпеку LLM-системи на відтворювані атаки, докази та regression-тести. Розглядаємо threat model, ручні й автоматизовані кампанії, triage, безпечну лабораторію та перевірку виправлень.