Безопасное распознавание страховых документов

Почему страховой документооборот — отдельный класс риска

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

Соблазн отдать этот поток во внешний облачный OCR понятен: так быстрее и дешевле на старте. Но для страховой компании в Казахстане это означает передачу чувствительных сведений за пределы своего периметра, часто в юрисдикцию, которую служба безопасности не контролирует. Когда речь идёт о медицинских диагнозах, данных о доходах и полном профиле клиента, цена утечки измеряется не только штрафом регулятора, но и репутацией перед корпоративными клиентами, которые сами требуют гарантий по защите данных.

Как устроено безопасное распознавание страховых документов

Ключевой принцип простой: данные не должны покидать контур страховщика. Мы в ZoomApps проектируем решения под изолированное развёртывание — движок распознавания ставится на серверы клиента или в его частное облако, а входящие сканы и фотографии обрабатываются внутри периметра. Наружу не уходит ни исходный документ, ни его фрагмент, ни промежуточный результат; система работает без обращения к внешним API, что снимает целый класс претензий от службы информационной безопасности.

Внутри контура пайплайн разбивается на предсказуемые этапы: приём файла, классификация типа документа, извлечение полей, валидация и передача структурированного вывода в учётную систему. Для страхования особенно важна именно классификация — один загруженный архив может содержать полис, удостоверение личности, справку и выписку одновременно, и система должна сама разложить их по типам, а не полагаться на то, что оператор верно назвал файлы. Общий подход к разным типам мы описываем в разделе распознавание документов.

Что именно приходится распознавать в страховом потоке

Состав документов зависит от вида страхования, но ядро повторяется. При заключении договора это сам полис и документы клиента: для распознавания удостоверений личности и извлечения ИИН применяется отдельная логика — подробнее в разделе удостоверения. При урегулировании убытка добавляются заявление на выплату, медицинские справки, счета лечебных учреждений и платёжные документы.

Отдельная нагрузка ложится на финансовую часть пакета. Реквизиты для выплаты возмещения выверяются по банковским выпискам, расчёты с клиниками и партнёрами проходят через счета-фактуры, а условия сотрудничества с агентами и перестраховщиками фиксируются в договорах. Для каждого типа настраивается свой набор целевых полей, поэтому система не пытается извлекать из справки то, что бывает только в полисе, и наоборот — это снижает число ложных значений на входе в учёт.

Специфика Казахстана: ИИН/БИН, тенге и два языка

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

Форматно-логический контроль строится вокруг местных сущностей. ИИН физического лица проверяется на двенадцать разрядов и корректность контрольной цифры, БИН организации — по своей структуре, а суммы в тенге распознаются с учётом того, как их пишут в реальных документах: с пробелом-разделителем тысяч, с обозначением «тг» или «₸», иногда прописью в акте. Такая проверка на этапе извлечения отсекает опечатки распознавания до того, как значение попадёт в выплатное дело, и снимает часть ручной сверки с оператора.

Структурированный вывод и интеграция с учётными системами

Распознавание имеет смысл только тогда, когда его результат сразу ложится в процесс. Поэтому на выходе система отдаёт не сплошной текст, а структурированный вывод: номер полиса, срок действия, ИИН и БИН сторон, сумма и валюта, банковские реквизиты — каждое значение в отдельном поле с привязкой к типу документа. Такой формат напрямую подключается к 1С и к внутренним системам андеррайтинга и урегулирования, что закрывает разрыв между сканом и записью в базе.

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

Соответствие требованиям по защите персональных данных

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

Для страхового бизнеса это не формальность, а часть переговоров с корпоративными клиентами, которые всё чаще включают требования по обработке данных в договор. Возможность показать, что распознавание документов работает в закрытом контуре и не выносит ничего наружу, становится конкурентным аргументом. Мы в ZoomApps исходим из того, что безопасность контура и точность извлечения — не две отдельные задачи, а одно инженерное требование, которое проектируется вместе с самого начала.

Хотите увидеть распознавание на своих документах? Посмотрите что умеет ZoomApps или сразу напишите нам в WhatsApp — покажем на демо.