### Резюме
Открытых данных недостаточно, чтобы доказательно назвать технологических лидеров практики БФЛ или связать набор программ с производительностью. Для такого рейтинга нужны единая выборка компаний, доступ к их внутренним системам, одинаковые метрики, журналы операций и подтверждённые результаты.
Поэтому исследование анализирует не бренды, а операции. Технологическое преимущество создаёт управляемая цепочка состояний: у клиента, дела, документа, события и задачи есть устойчивые идентификаторы; переход стадии происходит по проверяемому событию; исходный факт не перезаписывается выводом модели.
Правильная последовательность зрелости:
`процесс → данные → документы → официальные каналы → измерение → ИИ`
Если начать с генеративной модели, автоматизация масштабирует дубли, неактуальные шаблоны и неконтролируемый доступ.
### 1. Семь слоёв архитектуры
| Слой | Ответственность | Что нельзя делать | |---|---|---| | Каналы | принять обращение и согласие | смешивать рекламу и обслуживание | | CRM | маршрут, роли, задачи, сроки | хранить единственную копию документов | | Данные дела | сущности и происхождение полей | заменять источник выводом ИИ | | Документы | оригиналы, версии, шаблоны, подписи | смешивать черновик и поданную версию | | Интеграционный шлюз | официальный обмен, очередь, повторы | хранить секреты в коде и логах | | Аналитика и ИИ | извлечение, классификация, черновик | самостоятельно подавать документ | | Аудит и безопасность | доступ, журнал, резервирование, инцидент | полагаться на один общий журнал |
CRM оркестрирует процесс, но не обязана быть хранилищем истины обо всём. Оригиналы и юридически значимые версии живут в документном контуре. Внешнее событие хранится с источником, временем, идентификатором и исходным ответом.
### 2. Официальные каналы без выдуманного API
Для КАД официально перечислены Картотека, «Электронный страж» и «Мой арбитр». В проверенных официальных материалах не найден универсальный открытый API КАД для произвольной CRM. Обещание интеграции требует технической документации, договора и приёмочного теста; экранный робот или скрейпинг не становятся официальным API.
Для ЕФРСБ оператор документирует авторизованный REST-сервис версии 1.6.0. Он работает по HTTPS, требует подключения и токена. Спецификация прямо оставляет анализ данных и решения за пользователем. Недоступность источника должна создавать состояние `unavailable`, а не ложное «событий нет».
Публичный Банк данных ФССП позволяет поиск в предусмотренном интерфейсе, но сам по себе не доказывает право на массовый программный сбор. Для ЕСИА требуется регламентированное подключение и допустимые области доступа; ЕСИА не является универсальным ключом ко всем документам Госуслуг.
### 3. Данные и происхождение
Критические поля — суд, номер дела, кредитор, сумма, залог, имущество, сделка, срок и статус отправки — имеют:
1. тип и формат; 2. первоисточник; 3. время получения; 4. способ извлечения; 5. версию правила интерпретации; 6. статус проверки; 7. конфликтующие значения; 8. автора подтверждения.
Показатель «карточка заполнена на 95%» бесполезен, если пропущены два поля, меняющие правовую стратегию. Качество измеряется по критичности и последствиям.
### 4. Документы
Автоматизация начинается с полей и правил, а не с генерации текста. Шаблон собирает подтверждённые реквизиты, проверяет обязательные приложения и хранит версию. После изменения критического поля готовый документ теряет статус утверждённого.
Перед подачей система проверяет адресата, полномочия, версию, подпись, формат, состав пакета и совпадение хэша. После отправки сохраняются фактически направленный файл и квитанция.
### 5. ИИ с ограниченными полномочиями
Полезные операции:
- классификация и извлечение кандидатов в поля; - поиск противоречий; - краткое резюме документа со ссылками на страницы; - черновик письма или процессуального блока; - проверка пакета по чек-листу.
Без отдельного контроля модель не должна устанавливать юридический факт, создавать несуществующую ссылку, выбирать стратегию, подписывать, подавать или публиковать документ. RAG снижает часть ошибок, но не гарантирует истинность, полноту и актуальность.
Загруженный PDF может содержать prompt injection. Документ рассматривается как данные, а не инструкция; модель не получает прямые права CRM, почты и подачи.
### 6. Персональные данные и безопасность
Для каждого потока фиксируются цель, основание, состав, получатель, место обработки, срок и механизм удаления. Согласие не отменяет минимизацию, безопасность и договорное поручение.
Webhook, токен, пароль и ключ подписи хранятся в системе секретов, имеют минимальные полномочия, владельца, срок и порядок отзыва. Production-данные не копируются в поддержку и тест без отдельного решения.
Резервная копия считается доказанной только после теста восстановления. Инцидентный план включает изоляцию, сохранение доказательств, оценку субъектов, выполнение применимых сроков уведомления и устранение повторной компрометации.
### 7. Метрики и TCO
Эффект измеряется по полному циклу:
- активное и календарное время; - 90-й перцентиль задержки; - возвраты и переделка; - критические дефекты; - пропущенные события; - ручные касания; - время проверки ИИ; - доля утверждений с источником.
`TCO = лицензии + внедрение + миграция + интеграции + инфраструктура + верификация + безопасность + сопровождение + изменения + выход − подтверждённая экономия`
Популярность продукта и общий рост LegalTech не доказывают бизнес-кейс конкретной практики.
### 8. План зрелости
В первые 30 дней картируются процесс, роли, данные, шаблоны и неучтённые передачи. Затем создаются единая карточка и документный контур. Внешние события подключаются только через подтверждённые каналы с очередью и резервным маршрутом. ИИ-пилот запускается на двух ограниченных операциях после появления базовой линии. Масштабирование происходит после теста качества, безопасности, восстановления и экспорта.
Полный отчёт содержит модели малой, растущей и индустриальной практики, threat model, red-team, TCO, 180-дневный план и приёмочные критерии.
Автор: Дмитрий Мартынов, основатель платформы «ТехнологИИ права».