anonym.legal

By · Last updated 2026-03-12

Назад до блогуЮридичні технології

Санкції в e-discovery: провали ШІ-редагування

У справі Athletics Investment Group v. Schnitzer Steel (2024) неналежне редагування призвело до санкцій у рамках e-discovery. При тому що ШІ-інструменти досягають лише 22,7% точності на юридичних документах.

March 12, 202610 хв читання
e-discovery sanctionsredaction liabilityAI redaction precisiondocument reviewlegal technology

Подвійна відповідальність за неналежне редагування

Юридичні команди стикаються з двома окремими видами помилок редагування, і кожен із них тягне відповідальність.

Недостатнє редагування розкриває привілейований вміст, конфіденційну ділову інформацію або персональні дані, які мали бути приховані. Сторона, що розкриває документи, оголює матеріали, які мала право — а в деяких випадках і зобов'язання — захистити.

Надмірне редагування приховує відповідну інформацію, яку протилежна сторона має право отримати. Сторона, що розкриває документи, перешкоджає процесу disclosure, потенційно ховаючи докази за незаконними твердженнями про привілей. Суди розцінюють надмірне редагування як порушення e-discovery, що тягне санкції.

ШІ-інструменти редагування, що надають перевагу повноті над точністю — максимально позначаючи потенційно конфіденційний вміст — систематично породжують другий тип помилок. Коли двигун ШІ-редагування закриває 80% вмісту документа, щоб не пропустити нічого привілейованого, результуюча продукція є функціонально непридатною і потенційно може тягти санкції.

Athletics Investment Group v. Schnitzer Steel (2024)

Справа 2024 року Athletics Investment Group v. Schnitzer Steel ілюструє реакцію судів на неналежне редагування в e-discovery.

Справа стосувалася комерційного спору, в якому документальна продукція однієї зі сторін містила редагування, що протилежна сторона оскаржила як необґрунтовані. Суд вивчив відредаговані матеріали та встановив, що редагування виходить за межі дозволеного правом привілею або доктрин конфіденційності.

Наслідок: санкції в e-discovery. Суд наклав стягнення на сторону, що розкривала документи, за неналежне редагування — засіб захисту, доступний відповідно до Федерального правила цивільного судочинства 37 за порушення правил disclosure. Тягар неадекватного процесу редагування поніс позивач.

Справа є значущою не тому, що санкції за надмірне редагування є новиною — суди присуджували їх роками — а тому, що це сталося в умовах, коли ШІ-інструменти рецензування стали поширеними. Питання, яке порушує ця справа: чи оцінювали юридичні команди характеристики точності своїх ШІ-інструментів редагування перед тим, як покладатися на них у продукції?

Проблема точності 22,7%

Presidio — рушій виявлення PII з відкритим кодом, розроблений Microsoft і широко використовуваний у додатках для юридичних технологій — досягає точності 22,7% на юридичних документах за результатами незалежного бенчмаркінгу.

Точність вимірює, як часто позитивні ідентифікації інструменту є правильними. Точність 22,7% означає, що приблизно 77 із кожних 100 елементів, позначених інструментом як конфіденційні, насправді не відповідають порогу чутливості, за яким їх позначено.

Для застосування в e-discovery це має прямі операційні наслідки. Набір продукції з 10 000 документів, оброблений інструментом із точністю 22,7%, міститиме тисячі редагувань, що не мають законних підстав на привілей або конфіденційність. Сторона, що покладається на такий результат, стикається з тим самим ризиком, що й сторона у справі Athletics Investment Group: продукція, яку оскаржить протилежна сторона, суд, що вивчить відредагований вміст, і санкції, якщо редагування не можна обґрунтувати.

Цифра 22,7% відображає роботу Presidio у стандартній конфігурації на юридичному контенті. Вона не стосується всіх ШІ-інструментів редагування — але є базовою продуктивністю найпоширенішого рушія з відкритим кодом, що використовується в юридично-технологічних інтеграціях.

Проблема точності є структурною: системи розпізнавання сутностей на основі NLP, навчені на загальних текстових корпусах, показують гірші результати на юридичній мові, що використовує юридичні терміни, абревіатури, форматні конвенції документів і структуру посилань, які відрізняються від навчальних даних. Інструмент, що досягає прийнятної точності на медичних записах або фінансових звітах, може значно гірше справлятися з протоколами допитів, листуванням і додатками до контрактів.

Що розкриває аналіз вмісту ШІ-чатботів

Контекст для впровадження ШІ-інструментів у юридичній практиці встановлюють дані про використання: 27,4% вмісту ШІ-чатботів є конфіденційним, відповідно до незалежного аналізу моделей використання корпоративних ШІ-інструментів.

Ця цифра описує те, що співробітники надсилають до ШІ-інструментів під час виконання робочих завдань — не навмисно передані дані, а конфіденційний вміст, що потрапляє туди як побічний продукт звичайної роботи. Для юристів, що використовують ШІ-інструменти для складання кореспонденції, резюмування показань, аналізу контрактів або дослідження прецедентного права, конфіденційний вміст потрапляє на платформи ШІ-постачальників у результаті звичайної роботи.

Цифра 27,4% показує, що майже кожна третя взаємодія з ШІ-інструментами в юридичному середовищі передбачає конфіденційний вміст — інформацію про клієнтів, привілейоване листування, конфіденційну стратегію у справі або дані протилежної сторони. Цей вміст потрапляє до інфраструктури ШІ-постачальника у придатному для використання вигляді, якщо технічні засоби контролю не перехоплюють його заздалегідь.

Для юридичних фірм, що оцінюють свою позицію щодо безпеки ШІ, 27,4% — це не граничний ризик. Це базове припущення: майже третина використання ШІ-інструментів у юридичному середовищі передбачатиме вміст, що потребує захисту.

Каскадний ланцюг відповідальності

Надмірне редагування та розкриття даних ШІ-інструментами створюють для юридичних команд окремі, але пов'язані ланцюги відповідальності.

Ланцюг відповідальності за надмірне редагування: ШІ-інструмент максимально позначає документи → юрист перевіряє результат, не вивчаючи кожне редагування окремо → продукція подається з необґрунтованими редагуваннями → протилежна сторона оскаржує → суд вивчає → санкції.

Ланцюг відповідальності за розкриття даних ШІ: юрист використовує ШІ-інструмент для роботи зі справою → ШІ-інструмент отримує привілейоване листування клієнта, конфіденційні стратегії або конфіденційні дані справи → інфраструктура ШІ-постачальника зламана → дані клієнта розкриті → потенційно зачіпається адвокатська таємниця → ризик позову про неналежне виконання обов'язків.

Обидва ланцюги починаються в одній точці: юридичні команди розгортають ШІ-інструменти, не розуміючи їх технічних характеристик і не впроваджуючи засоби контролю, що відповідають юридичній роботі.

Редагування з пріоритетом точності для юридичної продукції

Судовий стандарт редагування не оптимізований для повноти. Суди, що оцінюють оскаржені редагування, питають, чи кожне конкретне редагування обґрунтоване привілеєм, доктриною конфіденційності або застосовним охоронним наказом — а не чи позначав інструмент якомога більше для безпеки.

Редагування, яке не можна обґрунтувати, є порушенням правил disclosure незалежно від того, чи виконано його людиною-рецензентом чи ШІ-інструментом. Розгляд судом є предметно-специфічним, а не системним.

Для юридичних команд це означає, що інструменти редагування необхідно оцінювати за точністю — відсотком позначених елементів, що є законно привілейованими або конфіденційними — а не лише за повнотою. Інструмент із повнотою 90% і точністю 22,7% може виявляти більше конфіденційного вмісту, але накладає тягар ручного перегляду для 77,3% хибних спрацьовувань і створює систематичний ризик надмірного редагування, коли такого перегляду не відбувається.

Юридичне середовище вимагає точності на рівні документа. Кожне редагування в продукції є імпліцитним твердженням перед судом, що відредагований вміст законно утримується. Стандарт після справи Athletics Investment Group є однозначним: це твердження має бути точним.

Джерела:

Готові захистити свої дані?

Почніть анонімізувати PII з 285+ типами сутностей на 48 мовах.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.