Коротко: под Triage Logic (триаж-логикой) понимают набор правил, по которым LegalTech-сервис (онлайн-программа для автоматизации части юридических услуг) сортирует обращения: отвечает сам, уточняет данные или передаёт случай юристу.
Слово пришло из медицины, где триажем называют сортировку пациентов по тяжести состояния. Юридический сервис применяет эту идею к обращениям: распределяет их по срочности и цене ошибки.
Житейский пример: приёмное отделение больницы. Врач смотрит на тяжесть состояния, а время прихода значения не имеет: пациент с травмой проходит раньше пациента с насморком, который пришёл час назад.
Triage Logic задаёт сервису такие же правила приёма.
Чем триаж отличается от анкеты?
Анкета собирает данные и выдаёт итог. Триаж после каждого ответа решает, что делать дальше: продолжать, уточнять или остановиться. Один и тот же ответ в разных обстоятельствах ведёт к разным маршрутам.
Три маршрута
Для старта хватает трёх маршрутов:
- Решает сервис. Типовой случай без риска: сервис отвечает сам.
- Нужно уточнение. Данных не хватает: сервис задаёт следующий вопрос.
- Передать юристу. Случай опасный, срочный или нуждается в решении юриста: сервис останавливается и отправляет специалисту карточку случая с указанием приоритета.
Уточнение возвращает случай на шаг ввода, а два других маршрута завершают триаж. Число повторных вопросов ограничено, и пользователь не застревает: когда попытки исчерпаны, случай уходит юристу с пометкой «данные неполные». Предел задаёт владелец сервиса.
Пример: первичная оценка трудового спора
Возьмём вымышленный сервис, который по рассказу работника подсказывает, сколько времени осталось на обращение в суд. Придуман здесь только сервис. Сроки настоящие: ст. 392 Трудового кодекса РФ.
| Тип спора | Срок обращения в суд | Откуда считается | Основание |
|---|---|---|---|
| Увольнение | 1 месяц | Со дня вручения копии приказа, выдачи трудовой книжки или предоставления сведений о трудовой деятельности | ч. 1 ст. 392 ТК РФ |
| Невыплата или неполная выплата заработной платы и других выплат | 1 год | Со дня установленного срока выплаты, в том числе при увольнении | ч. 2 ст. 392 ТК РФ |
| Остальные споры работника | 3 месяца | Со дня, когда работник узнал или должен был узнать о нарушении своего права | ч. 1 ст. 392 ТК РФ |
Суд вправе восстановить пропущенный срок по уважительным причинам (ч. 5 ст. 392 ТК РФ). Но таким исключением распоряжается суд, поэтому сервис исходит из обычных сроков. Пропуск срока учитывается, только если о нём заявил работодатель (п. 5 постановления Пленума Верховного Суда РФ от 17.03.2004 № 2).
Откуда считать срок
Сложнее всего для программы определить дату, от которой идёт срок. Сервис эту дату не угадывает: он спрашивает о конкретном событии.
Для спора об увольнении это день вручения копии приказа, день выдачи трудовой книжки или день предоставления сведений о трудовой деятельности. Дата подписания приказа в расчёте срока не участвует.
Если работнику не вручили ни копию приказа, ни трудовую книжку, и он не отказывался их получать, месячный срок, по определению Верховного Суда РФ от 07.12.2020 № 5-КГ20-101, не пропущен. Сервис такой срок истёкшим не объявляет и передаёт случай юристу.
Если работник отказался получать приказ или трудовую книжку, срок идёт со дня отказа (п. 3 постановления Пленума Верховного Суда РФ от 17.03.2004 № 2).
Для зарплаты это день, в который выплата должна была состояться. Конкретную дату выплаты устанавливают правила внутреннего трудового распорядка, коллективный или трудовой договор (ст. 136 ТК РФ), поэтому сервис спрашивает: какого числа вам должны были выплатить деньги?
Если этот день выпадает на выходной или праздник, выплата производится накануне, и сервис учитывает такой сдвиг.
Если работник продолжает работать, а начисленная зарплата не выплачена, нарушение считается длящимся. По разъяснению Пленума Верховного Суда РФ (п. 56 постановления от 17.03.2004 № 2) срок обращения в суд не пропущен, пока длятся трудовые отношения. Остаток срока по календарю выплат сервис в такой ситуации не считает.
Для расчёта при увольнении срок выплаты определяет ст. 140 ТК РФ: все суммы выплачиваются в день увольнения, а если работник в этот день не работал, не позднее следующего дня после требования о расчёте. В таком случае сервис уточняет день увольнения и выясняет, работал ли человек в этот день. Календарь выплат по правилам внутреннего трудового распорядка здесь не применяется.
Бывает, что человек работал по договору подряда или оказания услуг и просит признать отношения трудовыми. В этом случае сроки по ст. 392 ТК РФ применяются к ним только после признания отношений трудовыми судом (определение Верховного Суда РФ № 64-КГ24-4-К9, Обзор судебной практики № 3 за 2025 год). Сервис сроки для такого случая не считает и передаёт его юристу.
Правило срочности
Сервис считает, сколько времени осталось до конца срока, и по остатку назначает приоритет. Порог срочности задаёт владелец сервиса. Значение порога хранится в файле настроек (отдельном файле, из которого программа берёт сроки и пороги), как описано в статье Как составить ТЗ для LegalTech-сервиса.
От приоритета зависит срок ответа: для срочных случаев он короче, и сервис сразу уведомляет юриста.
Если до конца срока далеко и данных достаточно, сервис отвечает сам: называет дату окончания срока и остаток времени. Оценку перспектив дела он не даёт.
В техническом задании (ТЗ) нужно прописать правило для границы: относится ли значение, равное порогу, к срочным («строго меньше» или «меньше либо равно»). Разница в сутки способна изменить маршрут.
Что делать, когда в обращении несколько требований
Работника уволили и не выплатили зарплату. Это два требования с разными сроками: месяц по спору об увольнении и год по зарплате.
Правило приоритета. Сервис разбирает обращение на отдельные требования и считает срок по каждому. Пропущенный срок по одному требованию не закрывает остальные, и сервис сообщает об этом раздельно. Срочность всего случая определяет требование с самым коротким остатком из ещё не пропущенных.
Пропущенный срок по любому требованию сам по себе служит основанием передать случай юристу: он оценивает, можно ли просить суд восстановить срок и стоит ли идти в суд.
Правило приоритета записывается заранее, иначе результат зависит от порядка, в котором программа проверяет условия.
Когда данных не хватает
Ответ «не помню» отличается от ответа «нет». Если работник не может указать дату вручения приказа, сервис просит её уточнить и не подставляет сегодняшнюю.
Для спора об увольнении закон называет три отправные точки: вручение копии приказа, выдачу трудовой книжки и предоставление сведений о трудовой деятельности. Если работник указывает несколько дат, сервис считает срок от самой ранней. Когда по разным датам результат отличается (по одной срок уже истёк, по другой идёт), случай передаётся юристу.
Самая ранняя дата выбирается только внутри одного требования. Даты разных требований, например увольнения и невыплаты зарплаты, между собой не сравниваются.
Журнал решений
Каждое решение сервис записывает в журнал: полученные ответы, сработавшее правило и выбранный маршрут. По журналу юрист разбирает спорные случаи и проверяет, правильно ли настроены правила.
Как проверить триаж
Для каждого правила нужна хотя бы одна тестовая ситуация с известным маршрутом (калибровочный датасет).
Вот семь для нашего примера:
- Работник сообщает об увольнении, но не называет дату вручения приказа. Ожидаемый маршрут: нужно уточнение.
- Работника уволили и не выплатили расчёт; с вручения приказа и выдачи трудовой книжки прошло два месяца. Ожидаемый маршрут: передать юристу в обычном порядке, потому что срок по увольнению пропущен, а срок по зарплате идёт.
- Работник называет две даты: получения копии приказа и выдачи трудовой книжки; по обеим остаётся много времени. Ожидаемый маршрут: срок считается от более ранней даты, сервис отвечает сам.
- Остаток срока равен порогу срочности. Ожидаемый маршрут: передать юристу со срочным приоритетом, потому что в нашем ТЗ граница относится к срочным.
- Работнику не вручили копию приказа и не выдали трудовую книжку, и он не отказывался их получать. Ожидаемый маршрут: срок не объявляется истёкшим, случай передаётся юристу.
- Работник продолжает работать, а начисленная зарплата не выплачена. Ожидаемый маршрут: остаток срока не считается, срок не объявляется истёкшим, случай передаётся юристу.
- Человек работал по договорам оказания услуг и считает отношения трудовыми. Ожидаемый маршрут: срок не считается, случай передаётся юристу.
В тесте 2 случай уходит к юристу из-за пропущенного срока по увольнению, а приоритет задаёт требование по зарплате: срок по нему идёт, и случай несрочный.
Что юрист записывает в ТЗ для триажа
Набор для разработчика состоит из шести частей:
- Маршруты и условия перехода на каждый из них.
- Параметры сроков и порогов для файла настроек, включая правило для значений на границе порога.
- Правило приоритета для обращения с несколькими требованиями.
- Ветка «данных недостаточно» и предел числа повторных вопросов.
- Состав записей журнала.
- Тестовые ситуации с ожидаемым маршрутом.
Четыре ошибки при проектировании триажа
- Непрозрачный общий балл риска. Скоринг (оценка по баллам) работает, когда юрист видит вес каждого фактора и сработавшие условия. Сумма без расшифровки даёт число, но не объясняет решение.
- Отсутствие ветки «данных недостаточно». Сервис подставляет значение по умолчанию и ошибается молча.
- Отсутствие правила приоритета. При нескольких требованиях в одном обращении результат зависит от порядка, в котором программа проверяет условия.
- Маршрут к юристу на любое сомнение. Юрист получает слишком много случаев, и автоматизация теряет смысл: к нему должны идти только случаи с высокой ценой ошибки.
Часто задаваемые вопросы
Чем Triage Logic отличается от чат-бота на ИИ? Чат-бот ведёт разговор, а триаж выбирает маршрут. Модель может помогать понять рассказ пользователя, но маршрут определяют правила.
Сколько маршрутов нужно? Для старта хватает трёх: «решает сервис», «нужно уточнение», «передать юристу». Новые маршруты добавляют, когда в журнале видны повторяющиеся случаи.
Как часто пересматривать правила? Правила пересматривают при каждом изменении нормы, на которую они опираются, и после разбора ошибок из журнала. Для регулярного отслеживания норм на странице услуги есть формат сопровождения (Legal Maintenance).
Читайте также
- Red Flags в LegalTech: когда юридический ИИ-сервис передаёт дело человеку: какие условия останавливают сервис раньше остальных правил
- Как составить ТЗ для LegalTech-сервиса: шесть шагов от таблицы параметров до тестовых сценариев
- Где проходит грань между сбоем и отказом: что делать сервису, когда реестр молчит
- Промпт-инженер vs юридический архитектор: кто задаёт рамки для ИИ-модели
- API-верификация клиента: что юридический сервис вправе проверять: на каком основании сервис получает данные, из которых строится маршрут
Проектируете LegalTech-сервис и хотите, чтобы он сам отличал срочные случаи от обычных? Напишите мне: опишу маршруты, правила приоритета и тестовые ситуации для вашего продукта. Подробности на странице услуги.