Чат как рабочее пространство юриста и ИИ

Редакционная версия внутренней спецификации. Это концепция модуля, в котором чат с клиентом становится не просто перепиской, а рабочим интерфейсом юриста и ИИ: с внутренней правой панелью, рабочими вопросами, черновиками ответов, задачами, публикациями и Skills.

1. Общая идея

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

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

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

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

1. Внешний коммуникационный контур — чат с клиентом или иным собеседником.
2. Внутренний рабочий контур — анализ, подготовка ответа, работа с документами, задачами, делом, базой знаний и ИИ.

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

2. Цель модуля

Цель модуля — превратить чат из простой ленты сообщений в производственный интерфейс юридической работы.

Система должна позволять:

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

3. Концепция интерфейса

Интерфейс чата должен быть трехзонным.

3.1. Левая зона

Левая зона — навигационная.

В ней могут находиться:

• список разделов системы;
• список чатов;
• избранные чаты;
• прямые сообщения;
• группы;
• дела;
• задачи;
• помещения;
• собственники;
• контакты;
• административные разделы.

Эта зона не является центральной для данной концепции, но обеспечивает навигацию по системе.

3.2. Центральная зона

Центральная зона — это обычный чат.

В ней отображаются:

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

Центральная зона — это внешний слой коммуникации. Все, что отправляется из этой зоны, потенциально видит клиент или иной собеседник.

3.3. Правая зона

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

Ее не следует воспринимать только как «AI Actions». Правильнее рассматривать ее как Workbench / Inspector / Рабочую область по вопросу.

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

• если выбрано сообщение клиента — справа показывается работа над этим сообщением;
• если выбран весь чат — справа показывается саммари, задачи, сущности, нерешенные вопросы, история и общий контекст;
• если выбран документ — справа показывается анализ документа;
• если выбрано дело — справа показывается карточка дела, связанные задачи, сроки, документы, стратегия;
• если выбрана задача — справа показывается выполнение задачи;
• если выбран ранее созданный рабочий вопрос — справа показывается его статус, анализ, черновики, действия и источники.

4. Ключевой принцип: разделение внешнего и внутреннего

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

Клиент не должен видеть:

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

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

Рекомендуемый сценарий:

1. В правой панели создается черновик ответа.
2. Юрист проверяет и редактирует черновик.
3. Юрист нажимает «Вставить в ответ».
4. Текст переносится в поле ввода центрального чата.
5. Юрист еще раз видит текст в поле ответа.
6. Юрист вручную нажимает «Отправить».

Не рекомендуется делать кнопку «Сгенерировать и сразу отправить клиенту» для юридически значимых ответов.

5. Основной объект: рабочий вопрос из чата

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

Поэтому в системе нужен отдельный объект: ChatIssue / Вопрос из чата / Рабочий вопрос.

6. Базовый пользовательский сценарий

Пример: клиент пишет в чат:

«Сергей, если у собственника нежилого помещения отдельное крыльцо, которое является входом только в его помещение, то кто должен обслуживать это крыльцо — собственник или ТСН?»

Пользователь выбирает сообщение и нажимает:

• «Разобрать вопрос»;
• «Создать рабочий вопрос»;
• «Проанализировать с ИИ»;
• «Создать задачу»;
• «Подготовить ответ».

Система создает ChatIssue и открывает справа рабочую область.

Правая панель показывает:

1. Суть вопроса.
2. Предварительную юридическую квалификацию.
3. Что нужно проверить.
4. Связанные документы и данные.
5. Возможные правовые позиции.
6. Недостающие сведения.
7. Черновик ответа.
8. Действия, которые можно создать.
9. Источники.
10. Производные материалы: статья, Skill, чек-лист, шаблон, методичка.

7. Структура правой рабочей панели

Правая панель должна быть структурированной. Она не должна превращаться в набор хаотичных кнопок.

Рекомендуемая структура:

7.1. Блок «Вопрос»

Содержит:

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

Пример:

Вопрос клиента:
Кто должен ремонтировать крыльцо отдельного входа в нежилое помещение?

Квалификация:
Вопрос о составе общего имущества МКД и обязанности по содержанию.

Категория:
ЖКХ / МКД / общее имущество / нежилое помещение.

7.2. Блок «Что нужно проверить»

Содержит чек-лист проверки.

Для примера с крыльцом:

□ Входит ли крыльцо в состав общего имущества МКД
□ Указано ли крыльцо в технической документации
□ Является ли крыльцо конструктивным элементом дома
□ Обслуживает ли крыльцо одно помещение или несколько помещений
□ Есть ли доступ к помещению через общие помещения дома
□ Кто фактически пользовался крыльцом
□ Кто ранее ремонтировал и обслуживал крыльцо
□ Принимались ли решения общего собрания собственников
□ Есть ли устав ТСН / договор управления / локальные регламенты
□ Есть ли угроза безопасности
□ Нужен ли срочный осмотр
□ Нужны ли фото, акт, заключение специалиста

7.3. Блок «Контекст»

Содержит связанные данные:

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

7.4. Блок «Анализ»

Содержит:

• внутренний анализ ИИ;
• анализ юриста;
• правовые варианты;
• риски;
• аргументы «за» и «против»;
• предварительный вывод;
• недостающие сведения;
• ссылки на источники.

Важно: анализ должен быть внутренним и не должен автоматически попадать клиенту.

7.5. Блок «Черновик ответа»

Содержит текст, который можно после проверки вставить в чат.

Должны быть варианты:

• краткий ответ;
• подробный ответ;
• осторожный ответ при недостатке данных;
• официальный стиль;
• простой клиентский стиль;
• ответ с запросом дополнительных документов;
• ответ с предупреждением о предварительном характере вывода.

7.6. Блок «Действия»

Содержит кнопки создания объектов и выполнения действий.

Базовые действия:

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

Дополнительные действия для накопления знаний:

• создать статью / пост по ситуации;
• создать FAQ;
• создать клиентскую памятку;
• создать Skill;
• создать чек-лист;
• создать шаблон ответа;
• создать внутреннюю методичку;
• добавить ситуацию в базу знаний;
• создать сценарий автоматизации;
• создать правило классификации похожих обращений.

7.7. Блок «Источники»

Содержит все использованные источники:

• сообщения чата;
• документы дела;
• вложения;
• нормы права;
• судебная практика;
• внутренние методички;
• ранее созданные Skills;
• данные из базы;
• сведения по клиенту, помещению, делу;
• результаты поиска.

Для доверия к ИИ важно показывать, на чем основан вывод.

8. Группы создаваемых результатов

Все результаты работы по вопросу можно разделить на три группы.

8.1. Внешние результаты

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

Примеры:

• ответ клиенту в чат;
• официальный ответ;
• письмо;
• претензия;
• заявление;
• ходатайство;
• публикация;
• пост;
• FAQ;
• клиентская памятка;
• новость для сайта;
• скрипт для видео.

8.2. Внутренние результаты

Это материалы, которые остаются внутри юридической команды.

Примеры:

• анализ;
• правовая позиция;
• стратегия;
• риски;
• внутренние заметки;
• задачи;
• поручения;
• чек-листы;
• записи в дело;
• события хронологии;
• внутренние комментарии.

8.3. Системные результаты

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

Примеры:

• Skill;
• шаблон;
• сценарий автоматизации;
• правило классификации;
• новая категория вопроса;
• методика обработки похожих ситуаций;
• база типовых вопросов;
• база знаний.

9. Функция создания статьи / публикации по ситуации

9.1. Идея

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

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

Пример из ситуации с крыльцом:

• «Кто должен ремонтировать отдельное крыльцо нежилого помещения в МКД?»
• «Когда крыльцо магазина является общим имуществом дома?»
• «Может ли ТСН отказать в ремонте входа в нежилое помещение?»
• «Собственник нежилого помещения и общее имущество МКД: где проходит граница ответственности?»

9.2. Важный принцип безопасности

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

Система должна удалить или заменить:

• ФИО;
• адреса;
• номера помещений;
• кадастровые номера;
• телефоны;
• email;
• номера дел;
• названия клиентов;
• детали, позволяющие узнать клиента или объект;
• внутреннюю стратегию;
• конфиденциальные сведения;
• адвокатскую тайну;
• персональные данные третьих лиц.

Кнопку лучше назвать не просто «Создать статью», а:

• «Создать обезличенную публикацию»;
• «Обобщить ситуацию для публикации»;
• «Создать материал на основе ситуации».

9.3. Форматы публикаций

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

□ Короткий пост
□ Подробная статья
□ FAQ
□ Клиентская памятка
□ Новость для сайта
□ Карточка для соцсетей
□ Скрипт для видео
□ Рассылка клиентам
□ Заметка для базы знаний

9.4. Пайплайн создания публикации

1. Выделить суть ситуации
2. Удалить конфиденциальные данные
3. Обобщить факты
4. Определить целевую аудиторию
5. Выбрать формат публикации
6. Подготовить структуру текста
7. Подготовить черновик
8. Добавить дисклеймер
9. Передать на юридическую проверку
10. Передать на редакторскую проверку
11. Сохранить в публикационный план
12. Отметить как готово к публикации
13. Зафиксировать факт публикации и ссылку

9.5. Статусы публикации

publication_draft — черновик публикации
legal_review — на юридической проверке
editorial_review — на редактуре
ready_to_publish — готово к публикации
scheduled — запланировано
published — опубликовано
rejected — отклонено
archived — архивировано

10. Функция создания Skill по ситуации

10.1. Идея

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

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

Иными словами:

• статья отвечает на вопрос: «Как объяснить эту ситуацию людям?»;
• Skill отвечает на вопрос: «Как в следующий раз правильно обработать такую ситуацию?».

10.2. Пример Skill

На основе ситуации с крыльцом можно создать Skill:

«Определение обязанности по ремонту крыльца / отдельного входа в нежилое помещение МКД»

Назначение Skill:

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

10.3. Что должен содержать Skill

Skill должен содержать:

1. Название.
2. Описание.
3. Область применения.
4. Когда использовать.
5. Когда не использовать.
6. Входные данные.
7. Вопросы к пользователю / клиенту.
8. Документы, которые нужно запросить.
9. Проверочный чек-лист.
10. Алгоритм анализа.
11. Логику принятия решений.
12. Типовые варианты выводов.
13. Риски и исключения.
14. Источники.
15. Форматы результата.
16. Критерии качества.
17. Ограничения.
18. Требования к проверке юристом.
19. Возможные создаваемые артефакты.
20. Версию и статус.

10.4. Входные данные для Skill по крыльцу

Примерный список:

- адрес МКД
- номер помещения
- статус помещения: жилое / нежилое
- кто пользуется входом
- является ли вход единственным для помещения
- есть ли доступ через общее имущество
- фото дефектов
- технический паспорт
- проектная документация
- выписка ЕГРН
- поэтажный план
- экспликация
- протоколы ОСС
- устав ТСН
- договор управления
- локальные регламенты
- сведения о фактическом обслуживании
- сведения о предыдущих ремонтах
- сведения о наличии угрозы безопасности

10.5. Проверки внутри Skill

□ Является ли элемент частью конструкций дома
□ Включен ли элемент в состав общего имущества
□ Обслуживает ли элемент более одного помещения
□ Используется ли элемент исключительно одним собственником
□ Был ли элемент предусмотрен проектом дома
□ Был ли элемент создан позднее отдельным собственником
□ Есть ли решение ОСС по содержанию или ремонту
□ Кто ранее производил ремонт
□ Есть ли угроза жизни и здоровью
□ Нужно ли организовать срочный осмотр
□ Нужно ли составить акт
□ Нужно ли запросить техническую документацию
□ Нужно ли предупредить о предварительности вывода

10.6. Логика анализа в Skill

Пример логики:

Если крыльцо конструктивно относится к МКД и включено в состав общего имущества, обязанность по организации содержания и ремонта, как правило, относится к зоне ответственности ТСН/УК в рамках управления общим имуществом.

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

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

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

10.7. Выходные результаты Skill

Skill должен уметь формировать:

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

10.8. Пайплайн создания Skill

1. Определить типовую юридическую ситуацию
2. Выделить из исходного анализа обобщаемую часть
3. Удалить персональные и конфиденциальные данные
4. Определить область применения Skill
5. Определить входные данные
6. Определить недостающие сведения, которые нужно запрашивать
7. Сформировать проверочный чек-лист
8. Сформировать алгоритм анализа
9. Сформировать типовые выводы
10. Указать источники и нормативную основу
11. Указать ограничения и риски
12. Указать форматы результата
13. Добавить критерии качества
14. Протестировать Skill на исходной ситуации
15. Передать Skill на проверку юристу
16. Утвердить Skill
17. Сохранить Skill в библиотеку
18. Сделать Skill доступным через API / MCP / внутренний каталог

10.9. Статусы Skill

skill_draft — черновик
review — на проверке
approved — утвержден
active — используется
needs_update — требует обновления
deprecated — устарел
archived — архивирован

10.10. Возможные поля Skill

Skill
- id
- title
- slug
- description
- category
- tags
- sourceChatIssueId
- sourceCaseId
- purpose
- applicability
- notApplicableWhen
- requiredInputs
- questionsToAsk
- documentsToRequest
- checklist
- analysisAlgorithm
- decisionLogic
- outputFormats
- qualityCriteria
- risks
- limitations
- sources
- version
- status
- createdByUserId
- reviewedByUserId
- approvedByUserId
- createdAt
- updatedAt
- publishedAt
- apiAvailable
- mcpAvailable

11. Концепция «из практики в знания»

В системе нужно заложить философию:

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

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

Обычная ситуация без такой системы:

1. Клиент задал сложный вопрос.
2. Юрист потратил время на анализ.
3. Юрист ответил клиенту.
4. Анализ остался в переписке или в голове юриста.
5. При похожей ситуации работа выполняется заново.

Целевая ситуация с системой:

1. Клиент задал сложный вопрос.
2. Юрист и ИИ провели анализ.
3. Клиент получил ответ.
4. Анализ сохранен в дело.
5. На основе анализа создан Skill.
6. Создан чек-лист или шаблон.
7. Создана обезличенная публикация.
8. Следующая похожая ситуация обрабатывается быстрее и качественнее.

Возможное название модуля:

• «Из практики в знания»;
• «Юридическая память команды»;
• «Фабрика знаний»;
• «Practice-to-Knowledge»;
• «Knowledge Factory»;
• «LawMatic Skills Factory».

12. Расширенный список действий в правой панели

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

12.1. Основные действия

[Ответ клиенту]
[Официальный ответ]
[Задача]
[Поручение]
[Запрос документов]
[Запрос фото]
[Запрос уточнений]
[Сохранить анализ в дело]

12.2. Действия для дела

[Добавить факт в хронологию]
[Добавить риск]
[Добавить доказательство]
[Связать с документом]
[Связать с помещением]
[Связать с собственником]
[Связать с договором]
[Создать событие]
[Создать напоминание]
[Создать запись в Activity Feed]

12.3. Действия для коммуникации

[Вставить краткий ответ в чат]
[Вставить подробный ответ в чат]
[Сформировать осторожный ответ]
[Сформировать запрос дополнительных сведений]
[Сформировать сообщение внутреннему сотруднику]
[Сформировать сообщение клиенту простым языком]

12.4. Действия для документов

[Подготовить письмо]
[Подготовить претензию]
[Подготовить заявление]
[Подготовить акт]
[Подготовить служебную записку]
[Подготовить проект ответа]
[Подготовить шаблон документа]

12.5. Действия для знаний

[Создать статью / пост]
[Создать FAQ]
[Создать клиентскую памятку]
[Создать Skill]
[Создать чек-лист]
[Создать шаблон ответа]
[Создать внутреннюю методичку]
[Добавить в базу знаний]

12.6. Действия для автоматизации

[Создать сценарий обработки похожих обращений]
[Создать правило классификации]
[Создать автоматический чек-лист]
[Создать шаблон задачи]
[Создать типовой workflow]
[Создать правило автосвязки с делом]

13. AI-функции в правой панели

ИИ в этой концепции — не отдельный чат вместо юриста, а рабочий помощник внутри правой панели.

13.1. Базовые AI-функции

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

13.2. AI должен работать с источниками

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

• историю чата;
• карточку клиента;
• карточку дела;
• документы дела;
• задачи;
• Activity Feed;
• базу знаний;
• существующие Skills;
• нормативные источники;
• судебную практику;
• внутренние методики.

13.3. Результат ИИ должен иметь статус

Нужно явно показывать:

Черновик ИИ
Проверяется юристом
Проверено юристом
Готово к отправке
Отправлено

Юрист должен понимать, что текст ИИ не является автоматически утвержденной юридической позицией.

14. Видимость и уровни доступа

Для каждого объекта и результата необходимо хранить уровень видимости.

14.1. Возможные уровни видимости

client_visible — видно клиенту
team_visible — видно команде по делу
responsible_only — видно только ответственному
internal_only — только внутреннее
private_note — личная заметка пользователя
draft — черновик
forbidden_to_send — запрещено отправлять клиенту
publishable_after_review — можно публиковать после проверки

14.2. Уровни конфиденциальности

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

public — можно отправлять в ИИ исходный текст
restricted — отправлять в ИИ только обезличенный текст
confidential — отправлять в ИИ только описание без исходного текста
secret — никогда не отправлять в ИИ ничего

Эти уровни должны влиять на то, может ли ИИ анализировать исходный текст, документы, персональные данные и внутренние заметки.

15. Аудит и история действий

Система должна сохранять историю всех значимых действий.

Нужно фиксировать:

• кто создал рабочий вопрос;
• из какого сообщения он создан;
• кто запустил AI-анализ;
• какие источники использовались;
• какой черновик был создан;
• кто его редактировал;
• кто утвердил текст;
• какой текст был отправлен клиенту;
• когда он был отправлен;
• какие задачи были созданы;
• какие документы были созданы;
• какие публикации были созданы;
• какой Skill был создан;
• кто утвердил Skill;
• какие версии анализа существовали.

Это можно сохранять в Activity Feed дела.

15.1. Пример событий Activity Feed

ChatIssueCreated
AIAnalysisStarted
AIAnalysisCompleted
DraftAnswerCreated
DraftAnswerEdited
DraftAnswerApproved
AnswerInsertedToChat
AnswerSentToClient
TaskCreatedFromChatIssue
DocumentCreatedFromChatIssue
AnalysisSavedToCase
PublicationDraftCreated
SkillDraftCreated
SkillApproved
ChatIssueClosed

16. Работа с источниками и доверием

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

Для каждого анализа желательно хранить:

• список использованных сообщений;
• список использованных документов;
• список использованных норм;
• список использованных судебных актов;
• список внутренних методичек;
• список Skills;
• дату и время анализа;
• модель ИИ;
• версию промпта / Skill;
• ограничения анализа.

Если источников недостаточно, система должна явно показать:

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

17. Пример полного сценария: вопрос о крыльце нежилого помещения

17.1. Исходное сообщение

Клиент пишет:

Сергей, если у собственника нежилого помещения отдельное крыльцо, которое является входом только в его помещение, то кто должен обслуживать это крыльцо — собственник или ТСН?

17.2. Действие юриста

Юрист нажимает:

Разобрать вопрос

или

Создать рабочий вопрос

17.3. Система создает ChatIssue

Тема:
Обслуживание крыльца отдельного входа в нежилое помещение

Категория:
ЖКХ / МКД / общее имущество / нежилое помещение

Статус:
Анализируется

17.4. Правая панель показывает предварительную квалификацию

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

17.5. Система предлагает проверить

□ Техническую документацию дома
□ Проектную документацию
□ Поэтажный план и экспликацию
□ Устав ТСН / договор управления
□ Решения общего собрания собственников
□ Кто пользуется крыльцом
□ Кто ранее выполнял ремонт
□ Есть ли угроза безопасности
□ Есть ли фото дефектов

17.6. Система формирует предварительную позицию

Если крыльцо конструктивно относится к дому и входит в состав общего имущества, ТСН должно организовать осмотр и решение вопроса о ремонте в рамках содержания общего имущества.

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

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

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

17.7. Система предлагает черновик ответа клиенту

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

17.8. Юрист выбирает дальнейшие действия

[Вставить краткий ответ в чат]
[Запросить фото]
[Создать задачу проверки технической документации]
[Подготовить официальный ответ]
[Сохранить анализ в дело]
[Создать статью]
[Создать Skill]
[Создать чек-лист]

17.9. Возможная статья

Тема:
Кто должен ремонтировать отдельное крыльцо нежилого помещения в многоквартирном доме?

Формат:
Короткая статья / FAQ.

Требование:
Обезличить адрес, клиента, номер помещения и детали конкретного дома.

17.10. Возможный Skill

Название:
Определение обязанности по ремонту крыльца / отдельного входа в нежилое помещение МКД

Назначение:
Помогает юристу определить, кто должен содержать входную группу нежилого помещения: ТСН/УК как управляющий общим имуществом или собственник помещения.

18. Требования к UX

18.1. Правая панель не должна быть перегруженной

Нужно избегать хаотичного размещения множества кнопок. Рекомендуется группировать действия:

Основные
Для дела
Для коммуникации
Для документов
Для знаний
Для автоматизации

18.2. Должны быть состояния пустой панели

Если ничего не выбрано, правая панель может показывать:

• саммари чата;
• нерешенные вопросы;
• извлеченные задачи;
• упомянутые сущности;
• последние рабочие вопросы;
• предложения ИИ.

18.3. Должна быть привязка к выбранному сообщению

При выборе конкретного сообщения правая панель должна перестраиваться под него.

18.4. Должна быть возможность работать с несколькими сообщениями

Юрист может выделить несколько сообщений и создать один рабочий вопрос на основе цепочки переписки.

18.5. Нужна явная маркировка внутреннего режима

Правая панель должна визуально показывать, что это внутренняя зона:

Внутренняя рабочая область. Клиент этого не видит.

18.6. Кнопка отправки клиенту должна быть только в чате

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

19. Требования к данным и связям

19.1. Основные связи

ChatMessage -> ChatIssue
ChatIssue -> Case
ChatIssue -> Client
ChatIssue -> Contact
ChatIssue -> Property / Premises
ChatIssue -> Task
ChatIssue -> Document
ChatIssue -> TimelineEvent
ChatIssue -> Risk
ChatIssue -> PublicationDraft
ChatIssue -> Skill
ChatIssue -> ActivityFeedEvent

19.2. Почему это важно

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

• какой вопрос возник;
• как он был проанализирован;
• какие документы проверялись;
• какой ответ ушел клиенту;
• какие задачи были созданы;
• какие выводы сохранены;
• какие публикации и Skills появились из этой ситуации.