Как составить ТЗ для LegalTech-сервиса

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

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

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

Чем юридическое ТЗ отличается от обычного?

Обычное ТЗ отвечает на вопрос, что делает система. Юридическое добавляет два слоя: границы допустимых решений и условия, при которых система останавливается и передаёт дело человеку.

Житейский пример: ремонт квартиры. Прорабу бесполезно говорить «сделайте красиво»: ему нужны чертёж, дизайн-проект, смета и перечень материалов, иначе красоту он поймёт по-своему.

С правовой логикой так же: разработчику нужен чертёж.

Пример для всех шагов

Возьмём вымышленный сервис, который подсказывает покупателю, можно ли отказаться от заказа на сайте интернет-магазина. Придуман здесь только сервис. Правила настоящие: п. 3 и 4 ст. 26.1 Закона «О защите прав потребителей» (от 7 февраля 1992 года № 2300-1).

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

Шаг 1. Таблица параметров

Каждое правило превращается в параметр: число, срок или условие, плюс ссылка на норму. Разработчик получает таблицу вместо абзаца текста.

Параметр	Значение	Основание
Срок отказа после получения заказа	7 дней	п. 4 ст. 26.1
Срок отказа, если продавец при доставке не вручил письменную информацию о порядке возврата	3 месяца	п. 3 и 4 ст. 26.1
Условие возврата	сохранены товарный вид и потребительские свойства	п. 4 ст. 26.1
Способ возврата	любой по выбору покупателя, если продавец может проверить состояние товара; расходы на доставку и риск повреждения в пути несёт покупатель	Постановление Конституционного Суда от 17.02.2026 № 7-П
Срок возврата денег после требования	10 дней, за вычетом расходов продавца на доставку возвращённого товара	п. 4 ст. 26.1
Исключение	товар надлежащего качества с индивидуально определёнными свойствами, который может использовать только этот покупатель	п. 4 ст. 26.1

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

Правило про способ возврата появилось в феврале 2026 года. Конституционный Суд признал п. 3 и 4 ст. 26.1 не соответствующими Конституции, потому что закон не предусматривал возврата дистанционно купленного товара дистанционным способом. До изменения закона возврат разрешён любым способом по выбору покупателя, если продавец может проверить состояние товара при получении.

Шаг 2. Файл настроек вместо чисел в коде

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

Файл настроек хранит значения нормы, схема решений хранит её структуру. При изменении срока или порога правится файл. При изменении состава условий правится схема, и тестовый набор прогоняется заново.

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

Шаг 3. Дерево решений

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

№	Вопрос	Если да	Если нет
1	Товар надлежащего качества имеет индивидуально определённые свойства и подходит только этому покупателю (например, мебель по его размерам)?	Сервис передаёт случай юристу: границы этого исключения оценивают по обстоятельствам.	Идёт следующий вопрос.
2	Прошло ли семь дней с получения заказа?	Идёт следующий вопрос.	Сервис готовит заявление об отказе.
3	Вручили ли при доставке письменную информацию о порядке возврата?	Сервис передаёт случай юристу.	Если с получения прошло меньше трёх месяцев, сервис готовит заявление об отказе, иначе передаёт случай юристу.

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

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

Как триаж работает на другом примере, с приоритетами и пропущенными сроками, разобрано в статье Что такое Triage Logic в LegalTech.

Шаг 4. Стоп-факторы

Под стоп-факторами (Red Flags) понимают ситуации, в которых автоматический ответ становится опасным: он заведомо противоречит закону или приведёт к убыткам. Для каждого записываются признак и действие сервиса.

В нашем примере их четыре:

Стоп-фактор	Основание
Заказ оформлен на компанию или предпринимателя	Закон применяется к покупкам исключительно для личных нужд (преамбула закона и п. 1 постановления Пленума Верховного Суда от 28.06.2012 № 17), поэтому цель покупки проверяет юрист.
Товар пришёл с недостатком	Действует другой набор правил (ст. 18–24 закона).
Заказ оформлен на маркетплейсе	С 1 октября 2026 года действует Федеральный закон от 31.07.2025 № 289-ФЗ «Об отдельных вопросах регулирования платформенной экономики в Российской Федерации», поэтому правила возврата проверяет юрист.
В сообщении покупателя упоминаются суд или письменная претензия	Признак возможного спора.

В каждом из этих случаев сервис останавливает автоматический ответ, показывает предупреждение и отправляет карточку случая юристу.

Список стоп-факторов короткий и точный: в него попадают только ситуации, где цена ошибки выше цены ручной проверки.

Как записывать такие правила для разных областей права и проверять их тестами, я разбирала в статье Red Flags в LegalTech: когда юридический ИИ-сервис передаёт дело человеку.

Шаг 5. Проверка данных во внешних базах

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

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

Шаг 6. Тестовые сценарии и критерии приёмки

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

Нужна как минимум одна ситуация на каждое правило и каждый стоп-фактор.

Вот две из них для нашего примера:

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

Критерий приёмки, то есть признак, по которому заказчик считает работу выполненной, простой: сервис выдаёт ожидаемый ответ в каждой ситуации набора.

После запуска набор пополняется реальными обращениями: каждая найденная ошибка становится новой тестовой ситуацией.

Что получает разработчик на выходе

Весь комплект состоит из шести документов:

Таблица параметров со ссылками на нормы.
Файл настроек для админки.
Схема решений.
Перечень стоп-факторов с действием для каждого.
Описание поведения сервиса при сбое внешних баз.
Набор тестовых ситуаций с ожидаемыми ответами.

Всё это разработчик переносит в код, не принимая самостоятельных юридических решений.

Четыре ошибки, которые встречаются чаще всего

Общие формулировки. «Корректный ответ» невозможно проверить, и фраза превращается в догадку разработчика.
Числа в коде. Закон поменялся, а число правит только программист.
Отсутствие точки остановки. Без стоп-факторов сервис отвечает уверенно даже там, где ответ зависит от неизвестных ему обстоятельств.
Отсутствие критериев приёмки. Заказчик принимает работу «на глаз», а ошибки находят первые пользователи.

Кто что пишет?

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

Границу между этими ролями я разбираю в статье Юридический архитектор vs разработчик.

Часто задаваемые вопросы

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

Что делать, если закон изменится после запуска? Если изменился срок или порог и числа лежат в файле настроек, обновление занимает минуты: юрист проверяет норму, сотрудник правит значение в админке. Когда изменился состав условий, обновляется схема решений, а тестовый набор прогоняется заново. Числа, зашитые в код, меняются только через задачу для разработчика. Для регулярного отслеживания норм на странице услуги есть формат сопровождения (Legal Maintenance).

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