ИИ для юридического департамента: ответы с источниками

Почему юристам нужны ответы только с источниками

Когда ИИ отвечает без источников, юрдепартамент получает не помощь, а новый риск. Ошибка может попасть в письмо контрагенту, в позицию по спору или во внутреннюю политику, а потом ее сложно открутить назад. В юридической работе важно не просто «правдоподобно», а проверяемо: чтобы любой тезис можно было открыть в документе и увидеть ровно то же самое.

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

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

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

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

Что считать источником и как понимать «цитату»

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

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

«Цитата» - это проверяемый фрагмент текста, который можно сопоставить с первоисточником без догадок. Хорошая цитата содержит контекст и координаты:

• название документа (при необходимости - орган, сторона, подразделение)
• реквизиты версии: дата, номер, редакция, отметка «с изменениями на ...»
• точное место: статья и пункт, либо раздел и пункт договора, либо страница и абзац
• сам фрагмент текста без перефразирования

Отдельная боль - версионность. Закон мог меняться, а договор мог дополняться допсоглашениями. Если ответ не фиксирует редакцию, получается «правильно, но не для того времени».

Здесь важно держать в голове два слоя: (1) факты из источника, (2) выводы пользователя. ИИ может показать цитату про срок уведомления или размер неустойки, но вывод «это нарушение» или «можно взыскать» должен быть явно помечен как интерпретация и опираться на выбранную норму.

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

Какие документы можно подключать и как их готовить

Юрдепартаменту стоит подключать только те материалы, где можно точно показать первоисточник. Обычно это НПА (кодексы, законы, постановления), судебные акты, письма и разъяснения регуляторов, типовые и подписанные договоры, внутренние политики и регламенты, приказы и инструкции, комплаенс-стандарты и матрицы полномочий. Чем ближе документ к реальной практике компании, тем полезнее ответы.

Чтобы «ответы с источниками» работали стабильно, документы приводят к единым правилам. Главная идея: любая цитата должна однозначно указывать на конкретную версию текста. Иначе при проверке неизбежно начнутся споры, какая редакция имелась в виду.

Единый идентификатор и версия

Заведите единый формат идентификаторов. Он должен быть коротким и одинаковым для всех типов документов: название, номер, дата и версия. Например: «Политика конфиденциальности, v3, приказ №12 от 05.02.2025». Для договоров добавьте тип и сторону: «Договор поставки с ТОО А., №45, 12.03.2024, редакция 2». Если документ меняется, новая редакция - это новая версия, а не замена старой.

Практическое правило: ИИ не должен «склеивать» разные редакции в один ответ. Лучше один документ - один набор цитат, даже если это выглядит менее «умно», зато проверяемо.

Хранение, доступ и журналирование

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

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

Минимальные метаданные для поиска и аудита

Минимум, который стоит хранить рядом с текстом:

• идентификатор (название, номер, дата, версия)
• владелец документа и ответственное подразделение
• тип (НПА, договор, политика, письмо, судебный акт)
• уровень конфиденциальности и срок действия
• источник получения и дата актуализации

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

Политика «нет источника - нет ответа» простыми словами

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

Правило поведения можно закрепить двумя пунктами:

• Если вопрос закрывается текстом из источников, ИИ дает ответ и прикладывает цитаты.
• Если в источниках нет нужных данных, ИИ пишет «нет данных в источниках» и задает 1-3 уточняющих вопроса (какой договор, редакция, дата, сторона, есть ли приложения и допсоглашения).

Важно, чтобы каждое существенное утверждение было проверяемым. На практике это означает: рядом с утверждением стоит ссылка-идентификатор на документ внутри системы (например: «Договор поставки, редакция от 12.03.2025, п. 4.2») или явная пометка, что в доступных материалах этого нет.

Как это выглядит в ответе

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

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

Запрет на «домыслы»

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

Формат выдачи: как показывать цитаты и ссылки

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

Практичный шаблон ответа:

• Вывод: 1-3 предложения по сути вопроса (без новых фактов, которых нет в источниках).
• Цитаты: 2-4 фрагмента текста, каждый отдельно и с подписью, откуда он.
• Источники: перечень документов, чтобы их можно было открыть и перепроверить целиком.

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

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

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

• название документа и версию (или дату утверждения)
• структурную метку: статья, пункт, подпункт, приложение
• страницу (для PDF) или номер раздела (для HTML/Word)
• внутренний идентификатор файла в системе (если есть)

Пример: вопрос про право на одностороннее расторжение. В выводе ИИ пишет: «Да, при просрочке поставки более 10 дней, с уведомлением за 5 рабочих дней». Ниже идут две цитаты: одна из договора про просрочку, вторая про порядок уведомления. В блоке источников - тот же договор с датой и указанием пункта, чтобы юрист открыл нужный фрагмент за секунды.

Пошаговая настройка внутреннего сервиса с источниками

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

Минимальная конфигурация, которая реально работает

Для старта достаточно простого процесса из пяти шагов.

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

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

Как выглядит это в живом запросе

Пример: сотрудник пишет «Какая у нас ответственность за просрочку поставки?». Сервис сначала уточняет, о каком шаблоне и редакции идет речь. Затем отвечает только по выбранному документу, показывает 1-2 цитаты из нужного пункта и добавляет короткое пояснение человеческими словами.

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

Частые ошибки и ловушки при внедрении

Частая проблема звучит так: «источники есть», но проверить ответ все равно нельзя. Обычно причина не в модели, а в том, как устроены документы, поиск и правила выдачи.

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

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

Третья ловушка - псевдодисклеймеры вместо контроля качества. Фразы вроде «может ошибаться» не защищают процессы комплаенса, потому что не заставляют сервис молчать, когда данных нет.

Четвертая - слишком общий ответ. Если вывод нельзя разложить на 2-3 проверяемых фрагмента, он обычно бесполезен для юриста.

Наконец, часто игнорируют контекст: юрисдикцию, дату, предмет договора. Например, для поставки в 2024 году сервис цитирует пункт типового договора 2021 года и склеивает его с нормой из другой страны.

Проверяйте внедрение по коротким признакам:

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

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

Шаблоны дисклеймеров без пустых формулировок

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

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

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

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

Ниже - шаблоны для разных режимов (их можно вставлять как готовые блоки в интерфейс):

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

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

Режим: поиск по базе
Результаты - это совпадения по документам. Нажмите на документ и проверьте фрагмент в контексте. Сервис не делает выводов, если в найденных материалах нет прямого основания.

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

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

Пример из практики: ответ по договору с проверяемыми цитатами

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

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

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

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

Вывод (пример): штраф по умолчанию применяется при нарушении срока, но может не применяться, если (а) срок изменен письменно или (б) задержка подпадает под форс-мажор и выполнены требования по уведомлению.

Цитаты (пример):

«Поставщик уплачивает неустойку в размере 0,1% от стоимости непоставленного товара за каждый день просрочки» (Договор поставки № 17/24 от 12.03.2024, п. 6.3).

«Изменение сроков поставки допускается только по письменному соглашению Сторон» (там же, п. 3.4).

«Сторона, для которой создались обстоятельства непреодолимой силы, обязана уведомить другую Сторону в течение 5 (пяти) рабочих дней» (там же, п. 9.2).

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

• Источник: «Договор поставки № 17/24 от 12.03.2024 (подписанная версия)», разделы 3, 6, 9
• Версия файла: имя или ID в хранилище, контрольная сумма (hash), дата загрузки
• Метаданные: дата и время ответа, кто запросил, ID обращения или тикета

Быстрый чеклист перед запуском и при аудите

Если вы запускаете ИИ для юридического департамента, лучше сразу договориться о простых правилах контроля. Тогда проверка не превращается в спор о том, «похоже ли это на правду», а сводится к тому, можно ли подтвердить каждую фразу.

Перед запуском (проверка готовности)

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

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

При аудите (что проверять регулярно)

Аудит удобнее делать по выборке: случайные запросы за период плюс несколько критичных тем.

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

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

Следующие шаги: как внедрить это в компании

Начните с малого, иначе проект быстро расползется. Для старта выберите 1-2 процесса, где «ответы только с источниками» дадут эффект уже в первый месяц. Частый выбор - ответы по типовым договорам (поставка, подряд, NDA) и по внутренним политикам (закупки, подарки, конфликт интересов). Такой пилот проще измерить: меньше споров, быстрее поиск, меньше ручной рутины.

Дальше зафиксируйте роли и границы ответственности. Обычно ломается не модель, а владение документами и правила обновлений. Владелец источников (часто это юрист) отвечает за актуальность и спорные формулировки. ИБ задает уровни доступа, требования к хранению, журналированию и срокам. ИТ отвечает за интеграции, учетные записи, поддержку и контроль изменений. Комплаенс или риск-функция определяет, где «нет источника - нет ответа» обязательно, а где допустим режим «нужно уточнение».

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

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

Если в компании нет ресурсов на полный цикл, GSE.kz может закрыть часть задач как системный интегратор: подобрать и развернуть AI и дата-центр инфраструктуру под внутренний сервис, настроить безопасный контур и обеспечить поддержку 24/7. Это уместно, когда требования ИБ строгие, а пользователи ожидают стабильной работы без ручных обходных решений.