### Резюме
Автоматизация документов в банкротстве граждан оправданна, когда система преобразует проверенные данные дела в документ определённого назначения. Рабочая единица — не файл Word и не запрос к языковой модели, а цепочка:
`источник → поле → правило применимости → версия шаблона → черновик → юридические проверки → утверждение человеком → подпись → подача → квитанция → неизменяемый архив`
Заявление, список кредиторов и опись имущества имеют повторяющуюся структуру, но это не делает их безрисковыми. Ошибка в активе, кредиторе, сумме или приложении способна привести к оставлению заявления без движения, возвращению или к вопросу о полноте раскрытия.
Заголовочное обещание «−90% времени» не подтверждено как факт российского рынка БФЛ. Его можно проверять только как гипотезу на сопоставимых делах, измеряя полный цикл, критические дефекты и стоимость переделки.
### 1. Что действительно типизируется
Наиболее пригодны:
- повторяющиеся реквизиты заявления и приложений по статье 213.4 Закона № 127-ФЗ; - список кредиторов и должников и опись имущества по формам приказа Минэкономразвития № 530; - перечни приложений, сопроводительные письма и описи отправлений; - типовые ходатайства с ограниченным набором переменных; - технические таблицы требований, счетов, активов, сделок и доходов; - сверка реквизитов, дат, итогов, состава пакета и версии формы.
Не передаются автономной генерации правовая квалификация неплатёжеспособности, выбор процедуры, оценка полноты раскрытия, спорные возражения, риск неосвобождения, стратегия и решение о подписании.
### 2. Реальная причина трудоёмкости
Проблема не в количестве текста, а в фрагментации. Одни и те же сведения повторно вводятся в анкету, таблицу, заявление, опись, список приложений и систему подачи. Каждая копия становится отдельной версией истины.
Добавление LLM не устраняет причину. Оно лишь быстрее создаёт ещё один текст на основе неуправляемых входных данных. Сначала нужен единый реестр полей и происхождения, затем шаблоны и правила, и только потом — ограниченный генеративный слой.
### 3. Реестр юридически значимых полей
Для каждого критического поля хранятся:
1. значение и формат; 2. первоисточник и дата документа; 3. способ извлечения; 4. уровень уверенности; 5. кто и когда подтвердил значение; 6. где оно уже использовано; 7. конфликтующие версии; 8. срок актуальности.
Если анкета клиента, паспорт, выписка и ранее поданный документ расходятся, система блокирует выпуск и создаёт задачу юристу. Она не выбирает наиболее вероятный вариант.
### 4. Правила, шаблоны, OCR и LLM
| Инструмент | Допустимая роль | Критический контроль | |---|---|---| | Схема данных | хранение и проверка формата | обязательность, тип, источник | | Шаблон | детерминированная сборка | версия формы и условия блоков | | Бизнес-правило | расчёт и логический тест | тесты и юридический владелец | | OCR | извлечение кандидата из документа | сверка с оригиналом | | LLM | черновик некритичного текста, поиск противоречий | запрет выдумывать факты и ссылки |
Модель не должна сама заполнять пропущенный ИНН, сумму, дату, суд, кредитора, правовое основание или факт наличия актива. Для критических полей допустимы только подтверждённый источник и явная проверка.
### 5. Контрольная архитектура
Выпуск документа проходит через шлюзы:
- входные данные полны и не конфликтуют; - применена актуальная версия формы и нормы; - расчёты воспроизводимы; - обязательные приложения присутствуют; - черновик прошёл содержательную проверку; - утверждающий имеет полномочия; - подписывается именно проверенная версия; - отправленный файл, хэш и квитанция сохранены вместе.
После изменения критического поля ранее утверждённый документ теряет статус готового. Подача не должна продолжаться по старой версии.
### 6. Персональные данные и подрядчики
Передача материалов OCR-, облачному или LLM-провайдеру является обработкой персональных данных. Согласие клиента не заменяет определение цели, состава, основания, роли подрядчика, мер безопасности и срока хранения.
До интеграции проверяются:
- место и режим хранения; - субпроцессоры; - использование запросов для обучения; - удаление и резервные копии; - разграничение доступа; - журналирование и уведомление об инциденте; - экспорт данных при смене поставщика.
В пилотах используются обезличенные или синтетические наборы, пока контур не прошёл проверку.
### 7. Как доказать экономию
Полное активное время включает сбор и очистку данных, создание черновика, сверку, исправления, согласование, подписание, загрузку и устранение дефектов. Время ожидания генерации — лишь малая часть цикла.
Контрольная и автоматизированная группы должны включать сопоставимые документы и дела. До старта фиксируются:
- медиана активного времени и 90-й перцентиль; - критические и некритические дефекты; - число повторных вводов; - доля возвратов на доработку; - стоимость исправления; - правило остановки пилота.
Пилот останавливается при пропуске имущества или кредитора, ложной ссылке, подаче неутверждённой версии, утечке данных либо невозможности воспроизвести отправленный пакет — даже если среднее время стало меньше.
### 8. План внедрения
1. Инвентаризировать документы, поля и источники. 2. Выбрать один частый пакет с контролируемым риском. 3. Создать схему данных и реестр происхождения. 4. Версионировать шаблон, форму и правила. 5. Реализовать проверки конфликтов и состава пакета. 6. Встроить персональное утверждение и подпись. 7. Провести контролируемый пилот. 8. Масштабировать только после доказанной экономии без роста дефектов.
Полный отчёт содержит нормативную карту, инвентаризацию документов и полей, сценарии отказа, red-team, протокол пилота, матрицу ответственности и контрольные чек-листы.
Автор: Дмитрий Мартынов, основатель платформы «ТехнологИИ права».