Автоматизация согласования договоров аренды с ИИ: протокол разногласий за 30 секунд

Применение ИИ для автоматизации согласования договоров аренды позволяет решить проблему избыточной нагрузки на юридический департамент. В практике крупных операторов связи эта нагрузка связана не с подготовкой новых документов, а на проверку версий контрагентов. Несмотря на наличие типовых форм и шаблонов, собственники земельных участков и зданий практически всегда возвращают документы с изменениями. В каждом вложении может быть до 20 страниц текста, где пункты переставлены, формулировки ответственности смягчены, а сроки скорректированы под интересы контрагента.

Для крупного телекома это оборачивается тысячами согласований в год. Пока юрист вычитывает каждую страницу, чтобы найти отличия от типовой формы, другие договоры простаивает в очереди. Скорость сделки в этом случае напрямую зависит от того, насколько быстро удастся провести первичный разбор: понять, что именно изменил собственник и насколько эти правки допустимы.

Мы интегрировали в этот процесс ИИ-конвейер, который берет на себя черновую работу по сверке. Система получает заполненный договор от контрагента, находит в базе соответствующую типовую форму и проводит смысловой анализ различий. Итогом становится автоматически сформированный протокол разногласий, в котором зафиксированы все отклонения: добавления, удаления и изменения текста.

Помимо фиксации факта правок, система выполняет три ключевые функции:

• Классификация по смыслу: ИИ понимает, что перестановка слов или пунктов, не меняющая сути, — это техническая правка, а изменение срока уведомления о расторжении — коммерческий риск.
• Оценка критичности: на основе заложенных правил система помечает правки как допустимые, спорные или неприемлемые.
• Подготовка рекомендаций: юрист получает подсказку, какую позицию лучше занять по конкретному пункту и на какую базовую редакцию стоит сослаться при отказе.

Весь цикл анализа занимает от 10 до 30 секунд. Важно, что система работает «в фоне»: протокол прикрепляется к карточке договора в 1С еще на этапе регистрации входящего сообщения. К моменту, когда юрист приступает к работе, у него уже есть готовая разметка документа.

Такой подход меняет роль специалиста: он не тратит время на поиск отличий, а сразу переходит к оценке рисков и переговорам. Это позволяет сократить количество циклов согласования и быстрее выпускать финальные редакции договоров, что особенно важно при масштабном строительстве сетевой инфраструктуры.

Работа с договорами почти всегда оказывается самым ресурсоёмким участком в работе юридического подразделения. Поэтому неудивительно, что, по наблюдениям Gartner, многие компании используют ИИ в проверке и управлении договорами, чтобы ускорять согласование, снижать стоимость рутины и повышать стабильность решений с точки зрения риска.

О клиенте

Крупный телеком-оператор с распределённой инфраструктурой размещения базовых станций по всей стране. Договорная работа связана с арендами площадок (земельные участки и крыши), большим количеством собственников и постоянным потоком согласований.

Как выглядел процесс до проекта

Для согласования договоров аренды контрагентам (собственникам) направлялись типовые формы. Контрагент заполнял форму и возвращал документ в компанию; затем договор регистрировался в 1С и попадал в очередь на согласование у юриста.

Проверка выполнялась вручную. Юрист открывал полученный договор, подбирал соответствующую типовую форму (их несколько — по типам объектов) и сравнивал документы в стандартном режиме сравнения Microsoft Word. Формально этот режим работает правильно: он показывает все отличия между файлами.

Но для проверки этого оказалось недостаточно — Word одинаково отмечает и редакционные правки, и заполнение пустых полей (даты, реквизиты, адреса), и существенные изменения условий. Дополнительно отчёт усложняли переносы и перестановки: перемещённые пункты часто отображались как «удалено в одном месте и вставлено в другом», даже когда смысл не менялся.

Поэтому перед подготовкой протокола разногласий юристу приходилось вручную разбирать результат сравнения: отделять заполнение полей и несущественные правки от изменений, которые действительно меняют смысл условий и влияют на права, обязанности и риски сторон. При массовом потоке договоров это превращалось в узкое место и задерживало выдачу первых замечаний контрагенту.

Границы пилота

Договорились начать с тех договоров аренды, где типовые формы используются чаще всего.

Что исключили на первом этапе:

• дополнительные соглашения — в потоке их много, но типовой формы нет, они слишком разнообразны и плохо типизируются;
• нетиповые договоры (например, аренда муниципальных земель);
• PDF и сканы — автоматизируем только Word-документы, так как они составляют основную часть потока договоров.

Что интересного в кейсе

• Много собственников → у каждого свои привычки, свои шаблоны, свои «любимые» пункты.
• Разные типы объектов для аренды (земельные участки / части земельных участков, помещения / крыши зданий) → разные юридические нюансы (предмет, доступ, ограничения, обслуживание, ответственность).
• Контрагенты часто присылают свой документ, а не заполненную типовую форму.

Цель проекта

Цель проекта — сократить время прохождения договоров аренды в массовом потоке за счёт автоматизации первичного разбора договоров и подготовки протокола разногласий. Мы убрали избыточные ручные операции в цепочке согласования: юрист начинает работу не с чтения и сравнения документов, а с готового результата, который сразу показывает отклонения от типовой формы и приоритеты.

• Сократить время до первых замечаний контрагенту: протокол разногласий должен формироваться автоматически ещё до того, как юрист откроет карточку договора.
• Снизить число кругов согласования: быстрее выявлять существенные отклонения и сразу фиксировать позицию (принять / вернуть к типовой редакции / вынести на отдельное согласование).
• Повысить качество и снизить риск ошибок: минимизировать пропуски критичных правок в «похожих» документах.
• Увеличить пропускную способность юридического подразделения: уменьшить долю ручных операций.
• Обеспечить тиражируемость решения: перенести подход на другие потоки документов потоки с типовыми формами (следующий кандидат — договоры подряда).

Автоматизация согласования договоров аренды с ИИ в этом проекте нацелена на сокращение рутины и ускорение обратной связи контрагенту.

Как мы сделали так, чтобы юристы доверяли результату

Чтобы юрист мог доверять результату, протокол разногласий

1. ссылается на конкретные места в договоре и в типовой форме;
2. объясняет критичность выявленных расхождений (почему это «красное/жёлтое/зелёное»);
3. фиксирует версии типовой формы и логики анализа — с какой именно редакцией сравнивался договор и какие правила применялись;
4. учитывает разметку юриста и превращает её в правила и исключения на будущее.

Автоматизация согласования договоров аренды с ИИ: почему задача сложнее, чем кажется

Задача оказалась сложнее, чем просто «сравнить два файла». В массовом потоке договоров важно не найти все отличия подряд, а быстро отделить шум от юридически значимых разногласий — так, чтобы юрист сразу видел то, что влияет на риск и скорость сделки.

Сначала нужно выбрать правильный эталон для сравнения

У Заказчика несколько типовых форм по типам объектов и несколько редакций для каждого типа. Если сравнивать документ собственника «не с той» версией, система будет отмечать ложные расхождения, хотя фактически условия укладываются в допустимую редакцию. Поэтому первый шаг — определить, какую типовую форму и какую редакцию брать за основу.

Собственники меняют структуру договора — построчное сравнение не работает

В присылаемых черновиках меняется порядок разделов и пунктов, переименовываются заголовки, абзацы объединяются или дробятся. В таких условиях простое построчное сравнение даёт множество “разрозненных” отличий и плохо показывает, какие фрагменты действительно соответствуют друг другу.

Заполненный договор отличается от типовой формы и в ряде случаев это не ошибки

В документе много ожидаемых отличий, которые не должны попадать в протокол разногласий

Типовые формы содержат поля для заполнения: ФИО, адреса, реквизиты, даты, параметры площадки. При сравнении шаблона и заполненного договора такие места выглядят как изменения (вместо «____» появляется значение), хотя это параметры сделки, а не правки условий.

Кроме того, в шаблонах часто предусмотрены альтернативы формулировок — например, разные пункты для ИП и ЮЛ или аренда земельного участка целиком или аренда части участка, аренда нежилого помещения или крыши (кровли). Выбор допустимого варианта тоже не должен считаться расхождением, иначе система будет постоянно отмечать эти случаи как ошибки.

Рис. 1. Выбор одного из предусмотренных в шаблоне вариантов пункта («ИЛИ») не является расхождением.

В примере на рисунке 1 типовая форма содержит альтернативные редакции: объект аренды может быть описан как «нежилое помещение» или как «часть крыши (кровли) здания». Контрагент выбирает крышу. Система должна распознавать выбор варианта и не считать альтернативную ветку «удалённым пунктом».

Рис. 2. Выбор сценария из типовой формы («ВАРИАНТ 1» или «ВАРИАНТ 2» ) не является расхождением.

В примере на рисунке 2 в типовой форме заранее предусмотрены два варианта: для долгосрочного договора — вступление в силу с момента государственной регистрации, для краткосрочного — с даты/после подписания. В договоре контрагента используется один из допустимых вариантов, а альтернативная ветка из шаблона не применяется. Система должна распознавать такой выбор как выбор варианта и не отмечать его как «удалённый пункт» или «правку условий».

Рис. 3. Заполнение пустых полей в типовой форме — это не расхождение.

В примере на рисунке 3 в типовой форме параметры оставлены как поля для заполнения («указать»), а в договоре подставлены конкретные значения (например, 380 вольт и 15 кВт). Такие изменения система должна распознавать как заполнение полей, а не как изменение условия.

При этом значения из заполненных полей проверяются отдельно: на корректность формата, на соответствие допустимым диапазонам/минимумам и на внутренние правила компании. Но даже при такой проверке заполнение поля само по себе не должно превращаться в «разногласие» — в протокол попадает только результат отдельной проверки (если выявлено отклонение от требований).

Рис. 4. Оговорки «указать, если имеются…» относятся к опциональным полям: их отсутствие не должно считаться расхождением.

В примере на рисунке 4 типовая форма содержит условную конструкцию: «за исключением: ____ (указать, если имеются обременения…)». Это поле заполняется только при наличии соответствующих обстоятельств. Если обременений нет, в договоре допустимо оставить его пустым или убрать уточняющую часть — такое расхождение система должна трактовать как «не применимо», а не как изменение условия.

Отдельно обрабатываются ситуации, когда: вместо пустого поля появляется конкретное перечисление обременений или меняется смысл гарантии (например, из безусловного заявления превращается в оговорку или ограничение).

Самые опасные изменения часто точечные и «незаметные»

Документ может выглядеть почти идентичным типовой форме, но содержать одну-две правки с высокой значимостью: сроки уведомлений, суммы, порядок индексации, ответственность, основания расторжения и другие условия. Именно такие изменения важнее всего выявлять в первую очередь.

Рис. 5. Критичное изменение смысла одной частицей «не»

В примере на рисунке 5 показано, что в типовой форме закреплено исключение: плата не начисляется и не уплачивается за определённый период. В договоре контрагента формулировка меняется на противоположную: плата начисляется и уплачивается. Это не «шум сравнения», а прямое изменение экономического условия. Такие случаи должны выделяться как критичные, даже если изменения минимальны по объёму текста.

Рис. 6. Замена правила «с даты подписания Акта» на конкретную дату — существенное изменение условия и должно попадать в протокол разногласий.

Пример на рисунке 6 показывает, почему для смысловой классификации нужны отдельные проверки дат и сроков. В типовой форме начало начисления платы привязано к событию — подписанию акта приёма-передачи. В редакции контрагента это условие заменено на фиксированную календарную дату. Формально текст выглядит похожим, но меняется юридическая логика: вместо «когда наступит событие» появляется «с какого числа», и плата может начать начисляться независимо от фактической передачи объекта.

Поэтому такие изменения система относит к юридически значимым и поднимает в приоритетную проверку: даты, сроки и числовые параметры выделяются как критичные маркеры и не могут автоматически трактоваться как «заполнение формы» или редакционная правка.

Когда договоры идут потоком, скорость первичной проверки очень важна

При сотнях документов в месяц ручное сравнение каждого договора с типовой формой становится экономически неэффективным. Возникает очередь на первичный разбор, растёт время до первых замечаний, увеличивается число кругов согласования — и в итоге замедляется цикл «получили черновик → подписали».

Далее разберём, как работает автоматизация согласования договоров аренды с ИИ: сопоставление с типовой формой, очистка несущественных отличий, смысловая классификация и сборка протокола.

Автоматизация согласования договоров аренды с ИИ: как устроено решение

Логика решения определяется самой природой массового потока: здесь задача — не фиксировать все отличия подряд, а выделять юридически значимые расхождения.

Поэтому мы выстроили многоуровневую обработку:
• детерминированные алгоритмы приводят документы к единому представлению, сопоставляют пункты и отсекают несущественные различия;
• языковая модель выполняет смысловую классификацию и помогает приоритизировать оставшиеся расхождения.

В терминах корпоративного ИИ это пример архитектуры «вокруг модели»: надёжность системы обеспечивают данные, правила, алгоритмы и процесс, а не только сама языковая модель (подробнее: Архитектура корпоративного ИИ). При проектировании мы использовали чек-лист решений при проектировании промышленных ИИ-систем (см.: ИИ: из пилота в прод).

На выходе формируется протокол разногласий с привязкой к фрагментам документа и пунктам типовой формы, оценкой критичности и предложенной позицией. Финальная проверка и решение остаются за юристом.

Уровень 1. Сравнение договоров как документов Word

На первом уровне мы работаем с договором как с полноценным Word-документом — со структурой и оформлением: разделами, заголовками, списками, таблицами, реквизитами и приложениями. Это позволяет привести входные документы к единому представлению и получить отчёт о различиях, привязанный к конкретным местам в файле.

Мы перестали зависеть от того, в каком виде контрагент прислал документ: система приводит его к единому представлению для анализа

1.1. Что сделали

Мы научились сравнивать типовую форму и заполненный контрагентом договор на уровне структуры Word: система фиксирует различия и помечает их прямо в документе (в тех местах, где они обнаружены).

1.2. Что это даёт

Корректная работа со структурой договора. Важные условия часто находятся в таблицах и структурированных блоках — мы их не теряем.

• Получаем список конкретных фрагментов, которые контрагент добавил или удалил относительно типовой формы.
• Каждая правка привязана к месту в документе (раздел/абзац/таблица). Это база для следующего шага: «поднять» изменения до уровня пунктов договора и собрать итоговый протокол разногласий.

1.3. Какие ограничения остаются на первом уровне

Этот уровень хорошо отвечает на вопрос «чем отличаются два файла между собой», но для юридической экспертизы этого недостаточно:

• Перестановки выглядят как значительные изменения. Перенос пункта, объединение абзацев или перемещение текста в таблицу часто отображается как «удалили здесь и вставили там», и отчёт сравнения разрастается.
• Нет сопоставления «Пункт ↔ Пункт». Юристу важно видеть изменения по пунктам: чему соответствует пункт типового договора в документе контрагента. Простое сравнение Word этого не даёт.
• Заполнение полей воспринимается как правки. Даты, реквизиты, адреса, преамбула и другие заполняемые поля попадают в отчёт о различиях, хотя это параметры сделки, а не изменение условий.
• Нет оценки значимости. Даже увидев расхождения, уровень 1 не может отличить критичные изменения (сроки, суммы, индексация, ответственность, расторжение) от редакционных правок и технических отличий.

Поэтому дальше нужны следующие уровни: сопоставление по смыслу, исключение несущественных различий и оценка критичности изменений.

Уровень 2. Алгоритмическое сравнение текста и сопоставление пунктов

На первом уровне мы научились фиксировать различия между двумя Word-документами и привязывать их к конкретным местам в файле.

Но этого недостаточно, когда контрагент меняет структуру: переставляет пункты, перенумеровывает разделы или перефразирует условия. Поэтому на втором уровне мы переходим к сравнению на уровне текстовых фрагментов и пунктов — чтобы устойчиво сопоставлять «одно и то же» даже при разной форме подачи.

Система не сравнивает документы строка к строке — она сопоставляет пункты по содержанию и контекстным признакам: “Расторжение” остаётся “Расторжением”, даже если у контрагента это пункт № 9, а у нас — № 12

2.1. Что сделали

Мы построили библиотеку типовых форм и добавили слой текстового сопоставления.

• Библиотека шаблонов: типовые формы по типам объектов + редакции + допустимые вариации.
• Выбор эталона: перед сопоставлением система определяет, какая типовая форма и редакция ближе всего к документу контрагента (по структуре и характерным формулировкам).
• Сопоставление пунктов: выравниваем пункты договора и типовой формы, даже если названия отличаются и порядок другой.

Технически этот уровень опирается на два механизма:

• Алгоритм сравнения текстов, устойчивый к перестановкам. Он ищет «опорные совпадения» и строит сопоставление вокруг них, а не пытается сравнить документ целиком строка к строке.
• Нечёткое сопоставление. Помогает находить вероятные пары «пункт типовой формы ↔ пункт договора» при перенумерации и небольших изменениях формулировок.

2.2. Что получилось решить

• Перестановки перестали выглядеть как «всё удалили и всё добавили». Если пункт перенесён в другое место, система находит соответствующий фрагмент и помечает изменение как перемещение, а не как новый текст.
• Сопоставление фрагментов текста меньше зависит от перенумерации. Даже если номера разделов и пунктов отличаются, система находит вероятные пары соответствующих фрагментов.
• Небольшие перефразы меньше влияют на результат. Незначимые изменения формулировок без изменения условий не «ломают» сопоставление и не дробят документ на несвязанные фрагменты.
• На выходе — структурированный список кандидатов на расхождения. Такой перечень уже пригоден для дальнейшей обработки и формирования протокола разногласий.

2.3. Какие ограничения остаются на втором уровне

Этот уровень заметно улучшает сопоставление, но сам по себе ещё не даёт готового результата:

• Приближённое сопоставление иногда ошибается. Похожие по словам пункты могут иметь разный смысл, а одинаковые по смыслу — сильно отличаться по формулировкам. Поэтому дальше нужны дополнительные проверки: правила, ограничения и валидации по ключевым условиям.
• Пока нет оценки значимости изменений. Уровень 2 находит отличия, но не определяет, какие из них критичны для рисков (например: сроки, суммы, индексация, ответственность, основания расторжения).
• Сложные изменения структуры дают неоднозначность. Разделение одного пункта на два, объединение двух в один, перенос части текста между пунктами — это случаи “один-ко-многим / многие-к-одному”, для которых нужна отдельная логика обработки.
• Результат остаётся промежуточным. На выходе формируется перечень потенциальных расхождений. Чтобы получить итоговый протокол разногласий, его нужно дополнительно очистить от несущественных различий, классифицировать по критичности и оформить в удобный для юриста вид.

Дальше переходим к следующим уровням обработки. На этих шагах вводятся дополнительные правила и проверки: они позволяют исключить ожидаемые различия (заполнение полей, допустимые варианты), выделить юридически значимые отклонения и собрать финальный протокол разногласий.

Уровень 3. Каскад правил, который исключает несущественные отличия

После первых двух уровней у нас получается большой список найденных отличий. Но значительная часть из них — это не разногласия по условиям, а технические и редакционные изменения: заполнение полей, перенумерация, оформление, служебные пометки в шаблоне. Если передать этот список дальше «как есть», он будет перегружать и модель, и юриста.

3.1. Что сделали

На третьем уровне мы добавили каскад из около 15 правил, которые последовательно «очищают» результат сравнения перед оценкой по смыслу и классификацией. Правила работают как фильтр: они не принимают юридическое решение, а убирают то, что обычно не влияет на условия договора, чтобы на следующих этапах анализировать только содержательные изменения.

Каскад выполняет, в частности, такие операции:

• Распознаёт заполнение типовых полей (ФИО, адреса, даты, реквизиты, параметры объекта) и не выносит это в список разногласий, когда речь идёт о стандартных полях для заполнения.
• Убирает служебные подсказки и пометки из шаблонов (например, «Указать …», «Вариант 1», технологические комментарии).
• Игнорирует изменения нумерации разделов и пунктов.
• «Снимает» редакционные правки, которые не меняют смысл: регистр, пунктуацию, типовые мелкие различия формулировок.
• Обрабатывает типовые структурные эффекты, когда пункты объединяются или разбиваются, чтобы это не выглядело как «удалили одно и добавили другое».
• Учитывает опциональные блоки и приложения («В случае необходимости», «Если имеется») как допустимые элементы шаблона, чтобы они не попадали в расхождения.

Правила «снимают» различия только там, где они действительно относятся к заполнению формы или редакционным изменениям. Если изменение затрагивает ключевые условия (сроки, суммы, индексацию, ответственность, расторжение), оно остаётся в наборе кандидатов на разногласия и передаётся дальше.

3.2. Что получилось решить

• Сократили объём отличий. Из списка уходят изменения, не являющиеся разногласиями по сути.
• Заполнение пустых полей перестало восприниматься как «расхождение». Даты, реквизиты и другие параметры сделки больше не попадают в перечень отличий.
• Перенумерация и переоформление текста тоже перестали попадать в результат.
• Получили «очищенный» набор кандидатов на отличия. На выходе остаются фрагменты, которые действительно имеет смысл оценивать и классифицировать при подготовке протокола разногласий.
• При необходимости все отфильтрованные отличия можно просмотреть отдельно.

3.3. Какие ограничения остаются на третьем уровне

Даже после очистки остаются случаи, где только правил недостаточно:

• Нужна смысловая оценка: это допустимый вариант или реальное расхождение и риск.
• Юридические нюансы и сложные перефразы: иногда смысл меняется при минимальной правке, а иногда формулировка меняется сильно, но юридически остаётся эквивалентной.
• Граница между «параметром» и «условием». Даты и суммы могут быть обычными параметрами, а могут быть частью спорного условия — без контекста правила могут ошибиться.

Нужна приоритизация по риску. Поэтому дальше нужен уровень, который выполняет смысловую классификацию и приоритизацию отклонений, а затем собирает итоговый протокол разногласий в удобном для юриста виде. Для этого будем применять уже искусственный интеллект, а точнее — большие языковые модели.

Уровень 4. Смысловая классификация отличий с помощью большой языковой модели

После первых трёх уровней у нас остаётся «очищенный» список кандидатов: отличия уже привязаны к конкретным фрагментам и не перегружены техническими и редакционными изменениями. На четвёртом уровне мы подключаем языковую модель, чтобы дать этим отличиям понятную юридическую интерпретацию и подготовить материал для протокола разногласий.

4.1. Что сделали

Модель классифицирует каждое отличие в одну из трёх категорий:

• Заполнение пустых полей — данные сделки и заполнение полей (реквизиты, адреса, даты, технические параметры), которое не является разногласием по условиям.
• Допустимый вариант — выбранная формулировка соответствует одному из вариантов, заранее предусмотренных типовой формой/редакцией.
• Юридически значимое отклонение — изменение условий, которое нужно показать юристу как потенциальный риск или предмет согласования.

Чтобы снизить вероятность ошибок, поверх модели добавлены проверки:

• Контроль числовых значений. Мы извлекаем числовые значения и их словесные формы (даты, проценты, сроки, суммы) и сравниваем их в соответствующих пунктах и фрагментах. Если обнаружено расхождение, такое отличие не может быть отнесено к “безопасным” категориям без приоритетной проверки.
• Контроль тем повышенного риска. Мы поддерживаем список терминов и тем («индексация», «неустойка», «расторжение» и т. п.). Если модель отнесла отличие к безопасной категории, но в изменённом фрагменте встречается термин из этого списка, отличие автоматически помечается как «обязательная проверка юристом».
• Объяснение и действие. Дополнительно модель возвращает короткое объяснение «почему так» и рекомендацию по действию: принять / вернуть к типовой редакции / вынести на отдельное согласование.

4.2. Что получилось решить

• Появилась смысловая юридическая разметка отличий: система отделяет параметры и допустимые варианты от существенных отклонений.
• Результат стал пригодным для сборки протокола разногласий: классификация и объяснение позволяют автоматически сформировать документ, который юристу остаётся проверить и утвердить.

4.3. Какие ограничения остаются и как мы их закрываем в архитектуре

Важно помнить: языковая модель — не детерминированный алгоритм и требует контроля.

1. Модель может ошибаться в классификации.

Поэтому используются страховочные проверки (числа, критические термины), а результат трактуется как “помощник юриста”, а не автоматическое решение.

2. Разница между «допустимым вариантом» и «существенным отклонением» не всегда формализуема.

Поэтому словари, правила критичности и шаблоны промптов настраиваются под юридическую политику и практику Заказчика.

3. Если используется внешний провайдер модели, появляется зависимость по доступности и качеству.

Это решается резервным сценарием на случай недоступности модели (можно временно работать без неё или использовать альтернативный контур), а также тем, что до обращения к модели мы заранее максимально сокращаем список кандидатов за счёт правил и сопоставления — поэтому зависимость от внешнего сервиса минимальна.

Уровень 5. Формирование Протокола разногласий

После того как система нашла отличия, исключила несущественные изменения и выполнила смысловую классификацию, мы переводим результат в прикладной документ, с которым юристу удобно работать в процессе согласования.

Работа юриста начинается с протокола разногласий, сформированного системой относительно типовой формы

5.1. Что получает юрист на выходе

• пропуски (обязательные пункты отсутствуют);
• изменения (что поменяли по сути);
• добавления (новые условия, которых нет в типовой форме);
• критичность (красный/жёлтый/зелёный);
• рекомендованная позиция и черновик формулировки для ответа контрагенту (как заготовка, требующая проверки юристом).

5.2. Как формируется документ

Система автоматически формирует протокол разногласий в формате Word. Для каждого отклонения фиксируются:

• идентификатор пункта типовой формы (и редакция типовой формы);
• текст пункта типовой формы;
• ссылка на место в документе контрагента (раздел/абзац/таблица или внутренний идентификатор фрагмента);
• текст соответствующего фрагмента у контрагента;
• тип отклонения (пропуск/добавление/изменение) и смысловая категория (параметрическое/допустимый вариант/юридически значимое);
• уровень критичности и предложенная позиция.

Параллельно система может сформировать структурированный реестр отклонений в формате JSON — для интеграции, аналитики и автоматической маршрутизации.

5.3. Что получилось решить

• Результат стал готовым к использованию, а не просто перечнем отличий: юрист получает документ, с которого можно начинать работу с договором.
• Отличия приведены к структуре «Типовая форма ↔ Редакция контрагента» с понятными опорами и ссылками на источники.
• Протокол встраивается в процесс согласования: автоматически прикрепляется к карточке договора, и юрист видит отклонения сразу при открытии задачи.
• Появился машинно-читаемый формат для статистики и маршрутизации (например, отправлять критичные случаи на дополнительную проверку).

5.4. Какие ограничения остаются

• Стабильная привязка к пунктам при радикальной переработке структуры. Если контрагент использовал собственный шаблон или сильно перестроил документ, не всегда корректно опираться на «номер пункта»; в таких случаях важнее внутренний идентификатор и ссылка на место в тексте.
• Не все отклонения автоматически превращаются в идеальную юридическую формулировку. Иногда юристу нужно отредактировать замечание, объединить связанные правки или уточнить позицию.
• Качество входного документа влияет на корректность. Внутренние комментарии и промежуточные правки нужно отличать от правок контрагента — для этого важны согласованный регламент и «чистый» документ перед загрузкой в систему.

Заключение

Практика показала, что автоматизация согласования договоров аренды с ИИ напрямую влияет на скорость сделки: юрист получает готовый протокол разногласий и начинает работу с приоритетных расхождений.

Каждое отклонение привязано к конкретным фрагментам документа и к пунктам типовой формы, имеет критичность и предложенную позицию. Это снижает рутинную нагрузку, но сохраняет ответственность и решение за юристом. Такой подход можно перенести на любые договорные процессы с типовыми формами и вариативной практикой контрагентов.

Есть идея для автоматизации? Запишитесь к нам на демонстрацию, и мы покажем, как встроить ИИ в обработку, анализ и согласование документов и в бизнес-процессы.