AI Due Diligence: где ручной разбор сделок ломается
Сделка встаёт не на переговорах, а на столе с документами: уставы, выписки, договоры, судебные решения, отчётность — сотни страниц в сканах и таблицах без единой структуры. Каждый аналитик читает свой блок, и к середине пакета внимание падает: юрлицо из выписки уже не сверяют с подписантом в договоре.
Ручной разбор документов масштабируется только людьми. Второй юрист удваивает трудозатраты, но не сокращает вдвое срок подготовки заключения — растёт время на сведение версий, снятие разночтений и согласование выводов между участниками.
Пропущенные риски почти никогда не лежат в одном файле. Они на стыке: цепочка владения, которая через третье юрлицо выходит на контрагента из списка неблагонадёжных; залог, всплывающий в одном договоре и не упомянутый в другом; арбитраж, где ответчик — не проверяемая компания, а её управляющая структура. Глазами такие связи собирают выборочно, а значит, случайно.
AI Due Diligence закрывает именно этот разрыв: документы разбираются целиком, сущности и связи между ними сводятся в граф, а заключение собирается из проверяемых фактов, а не из памяти аналитика. Ниже — как это устроено в автоматизации проверки контрагентов и что реально меняется в сроке сделки.
Что меняется после внедрения автоматического разбора
Первый эффект виден на входе: конвейер разбора принимает весь пакет документов, а не выборку по регламенту. Сканы, таблицы и приложения к договорам идут в тот же поток, что и текстовые файлы — извлечение построено на Apache Tika с распознаванием копий без текстового слоя. Полнота покрытия растёт с части пакета до практически полной, и пропущенный документ перестаёт быть делом везения.
Скорость заключения определяет не темп чтения, а время на сведение данных. Поля нормализуются в единую схему — суммы, даты, стороны, сроки, условия расторжения, — и аналитик получает черновик с готовыми таблицами вместо стопки файлов. Срок подготовки сжимается с дней до часов, а каждый вывод подкреплён ссылкой на страницу и абзац исходника: проверяющий смотрит точку, откуда взято значение, а не перечитывает документ целиком.
Уходит и класс ошибок ручного переноса — опечатки в суммах, потерянные приложения, неверно сшитые даты. Кросс-проверки в конвейере сверяют одно значение в договоре, приложении и выписке и помечают расхождение до того, как оно попадёт в заключение.
Повторные проходы тоже меняют природу: разбор версионируется, и при обновлении пакета заново обрабатываются только изменённые документы — команда закрывает дельту вместо сверки с нуля. Качество данных становится измеримым: доля полей, извлечённых и сверенных без ручной правки, показывает, где ещё нужна настройка.
Сценарии разбора: сплошной, выборочный и гибридный
При проверке перед сделкой режим выбирается не по размеру сделки, а по объёму корпуса документов и цене пропущенного пункта. Одно и то же извлечение сущностей и ссылок работает в трёх режимах — разница в том, сколько документов проходит полный разбор и на каком этапе в работу включается человек.
| Режим | Когда подходит | Ограничения |
|---|---|---|
| Сплошная проверка | Корпус укладывается в окно сделки либо пропуск одного пункта недопустим: заверения, условия смены контроля, отступные | Время растёт линейно объёму, а в массиве появляется доля однотипных документов, где разбирать нечего |
| Выборочная проверка | Нужна карта рисков по массиву в сотни договоров: важна плотность отклонений, а не каждый лист | Нетиповой пункт в невыбранном документе остаётся вне отчёта; выборка требует обоснования — стратификация по типу, дате, контрагенту |
| Гибридный режим | Корпус смешанный: основной том, приложения, переписка, сканы | Требует калибровки порога уверенности и правил маршрутизации, иначе эксперт либо тонет в потоке, либо видит только очевидное |
Роль эксперта и переключение режимов
Модель размечает и извлекает, но значимость пункта утверждает юрист или аналитик — на этом и строится гибридный режим. Первый проход идёт по всему корпусу без исключений, второй — только по документам, где сработал триггер или уверенность ниже порога, и каждое отклонение приходит со ссылкой на страницу и пункт.
Режимы совместимы между собой: разметка, ссылки и история правок общие, меняется только глубина прохода. Поэтому корпус можно начать выборочно, а по мере приближения к закрытию сделки расширить до сплошного разбора, не пересобирая результат с нуля.
Как проходит внедрение: от аудита данных до передачи
Внедрение идёт короткими циклами: на каждом шаге появляется артефакт, который можно проверить, — карта корпуса, схема извлечения, отчёт о качестве. Прогресс виден не по презентациям, а по тому, какую долю пунктов система закрывает сама, без ручной правки.
- Аудит корпуса документов. Разбираем, что реально придёт на вход: форматы, сканы без текстового слоя, дубликаты, языки, типовые шаблоны. На выходе — карта корпуса и оценка доли документов, пригодных к автоматическому разбору.
- Схема извлечения сущностей. Согласуем перечень сущностей и связей, нужных для выводов: стороны, доли, даты, обязательства, условия расторжения. Схема фиксируется до настройки — переделка на поздних шагах дороже.
- Разметка эталона. На контрольной выборке документов вручную размечаем правильные ответы — это эталон для замеров. Поверх настраиваем правила сверки и пороги, при которых система обязана передать пункт юристу.
- Приёмка на контрольной выборке. Считаем полноту и точность извлечения и долю пунктов, закрытых без ручной правки. Приёмка идёт по заранее согласованному набору документов, а не по показательной демонстрации.
- Пилот на реальном потоке. Запускаем на потоке сделок с параллельной ручной проверкой: расхождения разбираем, правила уточняем. Цель — стабильные метрики на документах, которых система раньше не видела.
- Передача решения и обучение команды. Отдаём документацию, регламенты, доступы и инструкции по обновлению правил, обучаем аналитиков и юристов. После передачи команда меняет пороги и добавляет сущности самостоятельно.
Модели, правила извлечения и шаблоны отчётов Due Diligence
Проект по автоматизации Due Diligence имеет смысл, если после сдачи контур остаётся управляемым без нас. Поэтому модели, правила и шаблоны живут не в коде, а в конфигурации и отдельных файлах: аналитик или юрист правит формулировки сам, без пересборки решения. Каждый артефакт версионируется — при спорном выводе видно, какое правило сработало и на каком документе.
Что именно остаётся у заказчика:
- Правила извлечения — набор правил и подсказок по каждому полю: что считать датой регистрации, как разбирать адрес, какие формулировки считать признаком связанности. Меняются в конфигурации, применяются без участия разработчика.
- Справочник контрагентов — нормализованный реестр с идентификаторами, прежними наименованиями и связями между компаниями и лицами. Основа для сопоставления сущностей из разных источников.
- Шаблон заключения — редактируемый шаблон отчёта: разделы, порядок выводов, обязательная ссылка на источник под каждым утверждением, поле для ручного комментария.
- Модели и пороги уверенности — настроенные модели извлечения и проверки с порогами, при которых вывод уходит на ручную валидацию, а не попадает в отчёт.
- Документация решения — схема обработки от загрузки пакета документов до готового заключения, словарь полей, перечень источников и правила их приоритета.
- Регламент сопровождения — инструкция по разбору отказов: что делать при низкой уверенности, как добавить поле, как корректно откатить изменение правил.
Отдельно фиксируем передачу артефактов: репозиторий с историей изменений, доступы и роли, сессия с командой заказчика по правке правил и шаблонов.
Кейс: автоматический разбор портфеля из 300+ компаний
До: выборочная проверка вместо сплошной
Портфель — 300+ компаний, от 30 до 200 документов на каждую: учредительные, выписки, договоры, протоколы собраний. Ручной разбор занимал около пяти недель и держался на выборке: аналитики успевали открыть примерно 2% файлов, остальное закрывалось со слов контрагента. Связи между компаниями — общие адреса, директора, доли участия — всплывали уже после закрытия сделки, когда перестраивать структуру поздно.
После: сплошной разбор и граф связей
Мы собрали конвейер: извлечение реквизитов и сущностей из сканов и таблиц, нормализация названий и адресов, сверка с внешними реестрами и базами Dow Jones Risk & Compliance. Поверх — граф, где ребро означает подтверждённое совпадение реквизита, а не похожесть строки, поэтому проверка аффилированности идёт по формальному признаку. Каждый вывод приходит со ссылкой на страницу и фрагмент исходного документа.
Метрики после запуска: подготовка выжимки по всему портфелю — два дня вместо пяти недель, сплошная проверка — 100% файлов вместо 2%, доля выявленных связей между контрагентами выросла втрое. Ложные срабатывания на похожих названиях снизились за счёт нормализации — спорные случаи уходят в очередь ручной проверки с приоритетом по риску, а повторный прогон после обновления реестров даёт сопоставимый результат.
Чем отличается автоматический разбор от ручной выборки?
Ручная выборка опирается на то, что эксперт успел открыть. Он читает документы, пока не исчерпан бюджет времени, и останавливается на достигнутой картине. Покрытие корпуса при этом редко доходит до десятой части, а состав выборки задают первичные гипотезы, а не структура данных. Пропуск не виден: непрочитанный договор с условием о смене контроля не оставляет в отчёте никакого следа.
Автоматический разбор проходит корпус целиком — с вложениями, сканами и перепиской. Система извлекает сущности, связи, даты, условия расторжения и обременения, по каждому факту сохраняя ссылку на источник. Покрытие корпуса становится измеримым: доля обработанных документов и доля полей, где нашлось подтверждение, видны в отчёте, а не оцениваются на глаз.
Воспроизводимость результата — вторая разница. Повторный прогон на том же наборе документов даёт тот же вывод: версия модели и правила разбора зафиксированы, промежуточные решения записаны в журнал. Ручная выборка таким свойством не обладает — при смене исполнителя меняются выборка, трактовка и итог, а объяснить расхождение задним числом почти невозможно.
Автоматический разбор при этом не отменяет участия эксперта. Человек остаётся в контуре в трёх точках: задать критерии существенности под конкретную сделку, разобрать противоречия между источниками и вынести суждение по выводам, помеченным как неоднозначные. Система снимает рутину и делает пропуски видимыми — трактовку по-прежнему держит эксперт.
Ограничения автоматизации и типовые ошибки внедрения
Осмысленнее сразу назвать границы: автоматизация уверенно закрывает типовой поток — договоры, выписки, уставные документы, отчётность стандартных форматов. Ломается она на копиях третьего-четвёртого поколения, где текст «плывёт», на рукописных приложениях, на самодельных таблицах и на документах редких языков, где мало обучающих данных. Ошибка здесь дороже ручной проверки: ложное извлечение уходит в отчёт и меняет вывод.
Мы не выдаём неопределённость за результат. У каждого поля есть порог уверенности; если он не пройден, значение не подставляется, а документ помечается как требующий проверки — эксперт получает страницу и фрагмент, который система не разобрала. Ограничения автоматизации остаются видимыми, а не растворяются в средней точности.
Как вы работаете с плохим качеством сканов?
Перед распознаванием идёт подготовка: выравнивание, подавление шума, коррекция контраста, разбиение разворотов. Дальше — проверка по контрольным полям: если ключевые реквизиты не читаются, документ уходит в ручную верификацию, а не в общий поток. Долю таких документов мы показываем до старта, а не после.
Что происходит с нестандартными документами и исключениями в правилах?
Правило описывается вместе с исключениями: какое условие, что делаем при отклонении, кто подтверждает. Набор правил версионируется, к нему приложен эталонный набор документов — после правки прогоняем его целиком и сравниваем с предыдущей версией. Откат занимает минуты, а не переработку всего процесса.
Типовые ошибки внедрения — попытка автоматизировать весь поток в первом релизе, правила без прописанных исключений и оценка по средней точности вместо критичных полей. Мы начинаем с узкого участка, измеряем долю документов, закрытых без человека, и только потом расширяем охват. Ниже — технические сомнения, которые чаще всего разбираем с командами заказчика.Обсудим задачу и вернёмся с оценкой и планом
Чтобы оценка опиралась на реальный объём работы, а не на усреднённую вилку, начинаем с вводных по корпусу: типы документов (сканы, текстовые слои, таблицы, почта), языки, примерный объём в тысячах страниц и то, какой результат считается верным — полное извлечение условий сделки или выборка рисковых пунктов с указанием источника. Чем точнее вводные, тем меньше допущений в плане и тем реалистичнее сроки.
С вашей стороны достаточно:
- 15–30 обезличенных документов, включая нетипичные и плохо читаемые экземпляры;
- где физически лежит корпус: файловое хранилище, электронный архив, сканы из внешних источников;
- примеры полей и условий, которые нужно вытаскивать, с парой эталонных ответов;
- как сегодня проверяют результат и кто выступает приёмщиком;
- требования к контуру: внутренний сервер, закрытое облако или гибрид;
- ограничения по доступам и работе с персональными данными;
- желаемый горизонт внедрения и то, что считаете первым полезным участком.
В ответ присылаем состав работ по этапам, схему обработки, требования к инфраструктуре, оценку сроков и порядок приёмки. Формат разметки и метрика качества согласуются до старта — иначе спор о точности уходит в бесконечность. Опишите задачу в свободной форме: вернёмся с оценкой и планом работ.
