Краткое summary договора удобно читать. Для операционного контроля мне этого мало. Нужна конкретная запись: кто что обязан сделать, к какому сроку, при каком условии и из какого пункта это следует.

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

Я бы особенно строго разделял извлечение и юридическое толкование. Модель может найти условие. Решить, как оно трактуется в спорной ситуации, — другой процесс.

Сначала определите схему обязательства

Поле `обязательство` слишком широкое. Я бы разложил запись на сторону, действие, объект, срок, условие наступления, сумму или лимит при наличии, а также ссылку на источник.

Для каждого типа договора схема может отличаться. В договоре поставки важны сроки и объём, в сервисном — SLA и отчётность, в аренде — платежи и условия продления.

Google Document AI custom extractor позволяет настраивать собственную schema сущностей. Но бизнес-схему всё равно должна определить команда, которая потом использует результат.

Проверяемые источники: Google Cloud — Custom extractor overview · Google Cloud — Extraction overview

Извлечённое значение сохраняется вместе с основанием

Запись `срок = 30 дней` без контекста опасна. Тридцать дней от чего: подписания, выставления счёта, поставки или получения требования?

Я бы сохранял текстовый evidence span, номер страницы и, если возможно, номер пункта. В интерфейсе сотрудник нажимает на срок и сразу видит фрагмент, из которого он извлечён.

Document AI возвращает структурированные сущности и anchors к документу. Такой provenance нужен downstream-процессу не меньше самого значения.

Проверяемые источники: Google Cloud — Extraction overview

MEDIA FRAME · PLACEHOLDERИллюстрация будет добавлена позже
AI для договоров: как извлекать обязательства, сроки и ответственных без потери основания · временная заглушка

Срок нельзя отделять от события, которое его запускает

Фраза `в течение пяти рабочих дней после получения акта` содержит как минимум длительность, тип дней и trigger event. Если сохранить только дату или число пять, обязательство искажается.

Я бы нормализовал duration отдельно, а событие-основание оставлял как structured relation. Фактическую календарную дату можно вычислить позже, когда известно, что trigger действительно произошёл.

Неоднозначные условия идут в review. Я не стал бы заставлять модель угадывать календарную логику по одному фрагменту.

Проверяемые источники: Google Cloud — Custom extractor overview

Версия договора — часть каждого извлечённого факта

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

Я бы связывал extraction run с конкретным файлом, checksum и версией. Новая редакция создаёт сравнение: какие обязательства появились, изменились или перестали действовать.

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

Проверяемые источники: Google Cloud — Signature detection in custom extractor

Автоматическая постановка задачи требует ещё одной проверки

Даже правильно извлечённое обязательство не всегда должно сразу создавать задачу. Нужно определить ответственное подразделение, статус договора и событие, после которого действие действительно наступает.

Я бы сначала создавал `candidate obligation` с evidence. После проверки оно получает статус active и только тогда может породить reminder, task или контрольный отчёт.

Так мы не превращаем probabilistic extraction в бесконтрольный генератор рабочих задач.

Проверяемые источники: Google Cloud — Document AI

Реестр готов, когда каждое поле можно проверить обратно

Для контрольной выборки я бы взял десятки обязательств и прошёл обратный путь: запись → документ → пункт → версия. Любое поле без понятного evidence считается непроверенным.

Отдельно полезно измерять, какие типы обязательств чаще требуют ручной правки. Это показывает не среднюю точность модели, а слабые места конкретной schema.

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

Проверяемые источники: Google Cloud — Custom extractor overview · Google Cloud — Extraction overview

Отрицательные и условные обязательства нужно хранить отдельно

Договор содержит не только «сделать до даты». Там есть запреты, условия продления, право расторгнуть, обязанность уведомить и действия, которые наступают только при событии.

Я бы не сводил всё к одной таблице задач. Тип обязательства влияет на downstream-контроль: reminder, запрет операции, проверка события или просто наблюдение.

Чем точнее schema отражает этот тип, тем меньше соблазн превратить сложное условие договора в неправильно назначенную задачу.

Проверяемые источники: Google Cloud — Custom extractor overview · Google Cloud — Extraction overview

Контрольные вопросы перед внедрением

Можно ли нейросетью автоматически анализировать договоры?

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

Как контролировать сроки из договоров?

Хранить не только длительность или дату, но и trigger event, тип дней, версию документа и статус обязательства. Задача создаётся только после подтверждения необходимых условий.

Что делать с допсоглашениями?

Обрабатывать как новую версию договорного набора и сравнивать извлечённые обязательства с предыдущей версией. Старые значения нельзя молча оставлять активными.

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

Для соседних проверок пригодятся для «анализ договоров нейросеть»: Как AI сравнивает договор, счёт и акт между собой · Как автоматизировать согласование договора и не потерять версии · Как автоматически извлекать данные из счетов, актов и договоров.