Распознавание в браузере без отправки файла на сервер

Что значит распознавание в браузере без отправки файла на сервер

Распознавание в браузере без отправки файла на сервер — это схема, при которой документ разбирается прямо на устройстве оператора, а не выгружается в облако или на удалённый бэкенд. Пользователь выбирает скан удостоверения или PDF-выписки, но сам файл не покидает вкладку: движок распознавания загружается как код (обычно скомпилированный в WebAssembly), выполняется локально и возвращает уже структурированный вывод — номер, дату, ИИН, сумму в тенге. На сервер, если он вообще нужен, уходит не изображение паспорта, а несколько текстовых полей.

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

Почему банкам и страховым это важнее, чем скорость

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

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

Какие документы реально распознаются на клиенте

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

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

Изолированное развёртывание, 1С и KYC

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

Когда объёмов браузера уже не хватает, тот же движок разворачивается в изолированном контуре клиента — на его собственном сервере, без выхода в интернет. Логика остаётся прежней: данные не покидают периметр, меняется только место выполнения. Такое изолированное развёртывание мы в ZoomApps считаем базовой конфигурацией для банков и страховых, а не платной опцией, потому что для этой аудитории закрытость контура важнее удобства подключения к чужому облаку.

Ограничения браузерного подхода

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

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

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