Задача: проверять досье быстрее, не теряя прослеживаемость
Типовой заказ финансовой организации: на онбординг клиента и пересмотр досье уходит от нескольких часов до дней; сотрудники вручную сверяют сканы учредительных документов, анкеты, договоры и отчётность с требованиями внутренних регламентов и норм регулятора. Поток растёт, требования обновляются, а цена ошибки — предписания и репутация. Задача: автоматизировать первичную проверку каждого пакета документов так, чтобы любое автоматическое решение можно было проверить до источника за секунды.
Скрытая часть задачи — не «распознать документ», а собрать решение: все ли обязательные документы в досье, совпадают ли реквизиты между документами, нет ли ограничений по перечням, не истёк ли срок. Человек в этом процессе нужен там, где неопределённость, а не там, где рутина.
Почему это сложно
Первое — качество сканов: фотографии под углом, печати поверх текста, многостраничные PDF вперемешку; без надёжного OCR дальше двигаться нельзя. Второе — нулевая терпимость к галлюцинациям: модель, которая «додумывает» недостающие реквизиты, в комплаенсе запрещена; выход обязан быть либо полным, либо честно неполным с пометкой. Третье — аудируемость: регулятор и внутренний аудит спрашивают не «что решила система», а «на каком основании»; каждая цифра вердикта обязана ссылаться на страницу и координаты в исходнике. Четвёртое — документы являются недоверенным вводом: в тексте договора может быть всё что угодно, включая попытки внедрить инструкции модели — контур обязан это отражать.
Архитектура: от скана до вердикта
Архитектура комплаенс-контура (текстовая схема)
Входящие: сканы/PDF/фото ──► OCR + разметка страниц
│ (качество распознавания проверяется порогом;
│ ниже порога — сразу на ручной разбор)
▼
Классификация типа документа (устав / анкета / договор / отчётность…)
▼
Извлечение полей: строгий JSON по схеме типа документа
{реквизиты, даты, суммы, подписи} + ссылка на страницу/координаты
▼
Сверки: комплектность досье · перекрёстное совпадение реквизитов
· перечни и ограничения · актуальность редакций нормативки (RAG)
▼
Вердикт: {статус, перечень расхождений, уверенность}
├──► уверенно «чисто» / «есть расхождения» ──► дальше по процессу
└──► уверенность ниже порога ──► очередь сотруднику
с подсказкой: что проверить и где смотреть
▼
Журнал аудита: каждое поле → источник в документе; каждое решение → лог
Инженерный костяк контура. OCR-слой строится по практикам обзора «OCR: распознавание документов» — с контролем качества на контрольной выборке до боевой работы. Извлечение полей идёт через структурированные выходы LLM: модель физически не может ответить вне схемы, недостающее поле помечается как отсутствующее, а не выдумывается. Сверка с действующими редакциями норм и внутренними регламентами — это RAG-поиск по версионируемой базе нормативки; паттерны — в кейсе «LLM + RAG по базе документов». Защита от недоверенного ввода и контроль ответов модели — guardrails-фреймворки: инструкции в тексте документа не исполняются, ответы вне схемы отклоняются.
Этапы внедрения
| Этап | Что получается | Бюджет | Срок |
|---|---|---|---|
| Аудит процессов и документов | карта типов документов и проверок, требования ИБ, план метрик | от 90 000 ₽ | 1–2 недели |
| Пилот на одном типе документов | контур на одном документе (например, анкета), замер точности извлечения и полноты сверок | от 480 000 ₽ | 4–6 недель |
| Промышленный контур | все типы документов, интеграция с АБС/ECM, роли, журналы, отчётность | 0,9–1,2 млн ₽ | по ТЗ |
| Сопровождение | обновление схем под новые редакции нормативки, контроль качества | по регламенту | — |
Бюджеты — прайс НЬЮ-ССТ на сентябрь 2026, «от», без НДС (УСН, п. 2 ст. 346.11 НК РФ). Сроки — типовые вилки проектов этого класса.
Типовые метрики «до/после»
Ниже — типовые вилки результатов внедрений ИИ-комплаенса этого класса, а не отчёт конкретного банка. Базовая линия замеряется до старта: среднее время проверки пакета и доля досье с ошибками первичной обработки.
- Время проверки пакета документов: типовое снижение на 50–80% за счёт автоматической комплектности и сверок.
- Доля решений без ручного разбора: 60–85% досье проходят автоматически, остальные — в очередь с подсказкой.
- Скорость онбординга клиента: −30–60% времени от заявки до решения.
- Пропуски расхождений: типовое снижение на 30–60% — машина не устаёт на пятидесятом досье подряд.
- Прослеживаемость: 100% полей вердикта ссылаются на источник; проверка решения занимает секунды, а не повторный разбор досье.
Безопасность и 152-ФЗ
Клиентские досье — персональные данные повышенной чувствительности, поэтому типовой контур для финансового сектора — полностью закрытый: on-premise модели, шифрование хранилищ и каналов, журналирование каждого доступа, обезличивание там, где возможна аналитика без персоналий. Требования 152-ФЗ закрываются архитектурой, а не регламентом «постфактум»: минимизация состава данных, сроки хранения, уровни доступа. Отдельный контур защиты — сам ИИ: обученные под ваши документы схемы и модели становятся активом, который инвентаризируется и защищается по 243-ФЗ.
Об этом разборе. Это обезличенное типовое внедрение из нашей практики проектирования: имена заказчиков не раскрываются (NDA), метрики даны типовыми вилками класса проектов; фактические значения фиксируются в КП и на приёмке. Названий клиентов, сумм контрактов и «гарантированных процентов» здесь принципиально нет.