Внедрение генеративного ИИ в банке требует четырёх решений. Нужно определить данные, контур, проверяющего и владельца процесса. Без этого пилот быстро создаёт новый канал передачи документов и решений, за который никто не отвечает. О применениях ИИ…
Внедрение генеративного ИИ в банке требует четырёх решений. Нужно определить данные, контур, проверяющего и владельца процесса. Без этого пилот быстро создаёт новый канал передачи документов и решений, за который никто не отвечает.
О применениях ИИ в финансовых организациях уже есть отдельный обзор. Там речь о документах, колл-центрах, залоговой деятельности, расшифровке совещаний и аналитике. Здесь разберём следующий этап — как провести один сценарий от идеи до рабочего процесса, не превратив удобный чат в неуправляемый внешний сервис.
Ни российское облако, ни договор с поставщиком, ни локальная модель сами по себе не означают автоматическое соответствие 152‑ФЗ, требованиям о банковской тайне и внутренним правилам банка. Основания обработки, трансграничная передача, состав мер защиты и локальные акты оцениваются для конкретного процесса вместе с ИБ, юридической службой, владельцем данных и подразделением, которое будет пользоваться результатом. Ниже — управленческая и техническая дорожная карта, а не юридическое заключение.
Начинать нужно с процесса, а не с модели
Самая частая ошибка — сначала выбрать модель, оформить доступ и только потом выяснять, какие документы сотрудники уже начали загружать. Для банка порядок обратный.
Сначала фиксируется сценарий. Например, нужно готовить черновик протокола совещания, выделять условия из типового обезличенного договора, классифицировать внутренние обращения или помогать сотруднику найти ответ в утверждённом регламенте. Для каждого сценария полезно описать бизнес-результат, входные данные, получателя результата, цену ошибки и сотрудника, который вправе остановить процесс.
Такой паспорт сценария быстро отделяет безопасную помощь сотруднику от процесса, где ошибка влияет на клиента, деньги, учёт или обязательства банка.
Генеративная модель — это стажёр с красным дипломом. Она хорошо снимает пласт рутины, умеет читать, сравнивать, собирать черновик и объяснять. Но стажёр не должен самостоятельно отправлять письмо клиенту, менять статус заявки, рассчитывать сумму платежа или принимать кредитное решение. Особенно если он получает данные через непредсказуемую цепочку файлов, внешних сервисов и интеграций.
Банк России в методических рекомендациях № 3‑МР от 16 июня 2026 года отдельно выделяет риски качества и конфиденциальности данных, уязвимости модели, риски поставщиков и операционной надёжности. Для критически важных автоматических операций с высоким риском, включая платёжные процессы, регулятор рекомендует валидацию результата сотрудником с возможностью его изменить. Полный текст рекомендаций Банка России стоит использовать как основу для разговора между бизнесом и ИБ.
Три контура для разных задач
Выбор контура определяется не географией сервера в рекламном описании, а полной траекторией данных. Нужно понимать, где выполняется запрос, где хранятся файлы и журналы, какие подрядчики участвуют в обработке, куда уходит телеметрия, есть ли внешние API и может ли банк управлять доступом.
| Контур | Какие задачи уместны | Что нельзя упускать |
|---|---|---|
| Открытое облако | Публичные источники, шаблоны, обучение на синтетических примерах, исследование рынка, черновики без чувствительных сведений | Клиентские данные, реквизиты, внутренняя переписка, непубличная отчётность, фрагменты баз и документы с банковской тайной |
| Российское облако | Контролируемые сценарии после оценки ИБ и юристов, минимизированные данные, пилоты с договорными требованиями к поставщику | Правовые основания, доступ подрядчиков, цепочка субподрядчиков, интеграции и сохранность журналов |
| Локальный или закрытый контур | Внутренние регламенты, чувствительные документы, защищённые базы знаний, сценарии с банковской тайной и персональными данными | Эксплуатация, обновления, контроль доступа, мониторинг, резервный сценарий и защита самой модели |
Открытое облако полезно, когда ценность даёт знание, уже доступное публично. Модель может помочь собрать проект программы обучения, превратить открытый документ Банка России в конспект, подготовить шаблон промта или структурировать публичный перечень изменений нормативной базы. В качестве учебных данных здесь используются синтетические наборы, обезличенные примеры, публичные документы и материалы, согласованные для внешнего использования.
Российское облако часто становится промежуточным вариантом между личным чат-ботом сотрудника и собственной инфраструктурой. Здесь важно не сводить проверку к одному вопросу о стране размещения. Нужны договорные условия, описание потоков данных, роли сторон, порядок уведомления об инцидентах, управление учётными записями, возможность аудита и правила подключения к внутренним системам. Если сервис строит ответ через внешний API, размещение пользовательского интерфейса в российском дата-центре не описывает весь маршрут данных.
Локальный или закрытый контур подходит для сценариев, где документ нельзя выпускать за пределы утверждённой инфраструктуры. Это может быть разбор внутренних регламентов через RAG, извлечение сведений из документов, подготовка черновика ответа сотруднику на основе внутренней базы знаний или обработка материалов, содержащих банковскую тайну. Закрытый контур обычно означает, что модель, векторная база, хранилище документов, журналы и интеграции работают внутри согласованного периметра, а выход во внешнюю сеть запрещён или жёстко ограничен.
При этом локальная модель не становится безопасной просто потому, что её установили на сервер. У неё есть администраторы, зависимости, обновления, плагины, API, журналы, учётные записи и резервные копии. Все эти элементы входят в модель угроз.
Подготовка данных важнее выбора БЯМ
Документ для модели — не просто файл. Внутри могут быть ФИО, телефоны, реквизиты, номера договоров, сведения о финансовом положении, служебные пометки, подписи, метаданные, история правок и косвенные признаки, по которым человека или клиента можно определить повторно.
Поэтому работа начинается с инвентаризации данных. Для каждого источника фиксируются владелец, категория данных, допустимая цель обработки, уровень доступа, место хранения, срок хранения результата и допустимый контур. Это кажется бюрократией ровно до первого инцидента, когда надо понять, кто передал файл, в какой сервис и зачем.
Полезно разделять три действия — удалить данные, которые не нужны для задачи, заменить прямые идентификаторы на заглушки и проверить, можно ли восстановить человека или сделку по сочетанию оставшихся признаков.
Замена ФИО на слово «Клиент» полезна, но не всегда достаточна. Если в тексте остались редкая должность, дата операции, сумма, регион, номер договора и уникальные обстоятельства, документ может быть сопоставлен с конкретным человеком или организацией. Таблица соответствия исходных значений и заглушек, если она нужна процессу, хранится отдельно и не отправляется в модель.
У обезличивания должна быть проверка. Для пилота достаточно взять подготовленный набор документов, прогнать его через правила очистки и вручную посмотреть, не остались ли в результате идентификаторы, подписи, реквизиты, комментарии или скрытые свойства файла. В продуктивном процессе эту проверку полезно автоматизировать, но сохранять выборочный контроль человеком.
Банк России рекомендует передавать поставщику для обучения модели очищенные, синтетические, обезличенные или специально подготовленные наборы данных. Обезличивание — отдельная стадия процесса со своим владельцем и критериями качества. Рекомендации № 3‑МР прямо рассматривают подготовку данных как часть жизненного цикла системы ИИ.
Трансграничная передача персональных данных требует отдельной правовой оценки. Порядок регулируется, в частности, статьёй 12 Федерального закона № 152‑ФЗ. Актуальный официальный текст закона не заменяет проверку конкретной архитектуры юристами, но помогает не принимать решение по принципу «у поставщика написано, что данные защищены».
Пилот должен проверять весь рабочий маршрут
Удачный пилот не обязан быть большим. Он обязан быть воспроизводимым. Его задача — доказать, что конкретный сценарий даёт полезный результат при заданных ограничениях, а команда умеет заметить и исправить ошибку.
Для пилота нужен заранее собранный тестовый набор. В него включают типовые, сложные и пограничные случаи. Для разборов документов это могут быть тексты с противоречивыми условиями, неполными реквизитами, нестандартными формулировками и намеренно добавленными ловушками. Для протоколов совещаний — записи с несколькими спикерами, неясными сроками и решениями, которые нельзя додумывать.
Критерии приёмки формулируются до запуска. Не «модель должна хорошо анализировать договоры», а «в черновике должны быть перечислены все найденные пункты из подготовленного контрольного списка, у каждого пункта должна быть ссылка на фрагмент документа, а непонятные места должны быть помечены как требующие проверки». Так модель перестаёт быть оракулом и становится инструментом подготовки материала.
Учебный пример. Внутреннее подразделение хочет ускорить разбор обращений сотрудников по утверждённому регламенту. В пилоте используются заранее подготовленные обезличенные обращения и версия регламента, согласованная для тестирования. Модель предлагает категорию и черновик ответа, но не отправляет его и не меняет статус обращения. Специалист видит исходный текст, фрагмент регламента, ответ модели и варианты исправления. Если модель не уверена или не нашла основание в регламенте, обращение уходит в обычную очередь.
Такой сценарий проверяет одновременно качество ответа, достаточность базы знаний, удобство интерфейса, подготовку данных, права доступа и работу сотрудника. Если пилот оценивает только красивый ответ в чате, почти все реальные риски остаются за кадром.
Перед переводом в продуктивный режим стоит ответить на неприятные вопросы. Что будет при недоступности модели? Можно ли пройти процесс без ИИ? Как быстро отключается интеграция? Кто проверяет обновление модели или промта? Что происходит, если сотрудник заметил некорректный ответ?
Галлюцинации с нами примерно навсегда. Поэтому задача пилота — не добиться обещания, что их не будет, а создать процесс, где галлюцинация не превращается автоматически в действие банка.
Human-in-the-loop — это конкретное действие сотрудника
Фраза «человек в контуре» часто звучит правильно, но остаётся пустой. Человек в контуре — не сотрудник, который когда-нибудь может посмотреть на результат. Это назначенная роль с понятным правом остановить, изменить или отклонить решение.
Для каждого сценария фиксируется контрольная точка. В ней сотрудник получает достаточно материалов, чтобы проверить результат. Он видит исходный документ в разрешённом объёме, использованную версию базы знаний, ссылку на источник, черновик модели и последствия подтверждения.
У модели разумно оставлять подготовительные задачи. Она может собрать черновик письма, выделить отличия двух редакций документа, предложить структуру отчёта, классифицировать обращение, подготовить варианты формулировок или найти фрагменты во внутренней базе. Решение о платеже, изменении учётной записи, клиентской коммуникации, финансовом расчёте, юридически значимом выводе или публикации остаётся за человеком, который понимает контекст и несёт ответственность.
Чем выше цена ошибки, тем раньше должна стоять проверка. В ряде процессов этого мало. Нужен второй контролёр, разделение ролей или полный запрет на автоматическое исполнение. При высоком риске автоматических операций Банк России рекомендует валидацию человеком, который может изменить результат. Это закреплено в рекомендациях № 3‑МР.
Логирование нужно для разбора, а не для накопления секретов
Когда процесс работает месяцами, вопрос «почему система так ответила» возникает неизбежно. Без журналов команда начинает восстанавливать цепочку по памяти, скриншотам и пересланным файлам. Это неудобно и само по себе создаёт новые риски.
В журнале полезно хранить технически достаточный след — идентификатор сценария, версию модели, версию системного промта, время запуска, класс входных данных, перечень источников для RAG, статус проверки человеком, итоговое действие и идентификатор ответственного сотрудника. Для документов лучше использовать защищённые ссылки или контрольные суммы, а не дублировать в журнале полный текст с чувствительными данными.
Отдельно фиксируются изменения. Новая версия модели, новая база знаний, подключённый плагин, изменение прав доступа, сбой интеграции, инцидент и решение по нему должны быть видимы владельцу процесса. Иначе невозможно понять, почему качество снизилось после обновления или откуда появился неожиданный источник в ответах.
Логи тоже являются данными. Им нужны ограничения доступа, срок хранения, защита от незаметного изменения и собственный владелец. Логирование не даёт права сохранять всё подряд.
Владелец процесса один, участников много
ИИ-проекты часто застревают между комитетами. Бизнес ждёт ИБ, ИБ ждёт описания процесса, ИТ ждёт выбора поставщика, юристы ждут схему потоков данных. Выход — назначить владельца бизнес-процесса, который отвечает за результат и собирает решения остальных ролей.
У владельца процесса должны быть полномочия утвердить цель пилота, критерии приёмки, допустимые сценарии применения и порядок остановки. Он не заменяет ИБ или юридическую службу. Он отвечает за то, чтобы их выводы превратились в работающий регламент, а не остались в переписке.
Роль ИБ — оценить угрозы, архитектуру, поставщика, доступы, интеграции и реакцию на инциденты. Роль владельца данных — подтвердить допустимость источника и порядок подготовки. Роль юристов и комплаенса — оценить применимые требования. Роль ИТ или эксплуатации — обеспечить доступность, обновления, резервное восстановление и мониторинг. Роль обучения — подготовить сотрудников к работе в пределах разрешённого сценария.
Банк России рекомендует возлагать разработку политики ИБ для систем ИИ и контроль её реализации на заместителя руководителя, ответственного за информационную безопасность. Это не отменяет владельца бизнес-процесса, а создаёт две необходимые линии ответственности — за ценность процесса и за безопасность его работы. Источник.
RAG не отменяет правила работы с документами
RAG — это умный библиотекарь. Система сначала находит фрагменты в подготовленной базе документов, а затем формирует ответ с опорой на них. Для банка это полезнее попытки «дообучить модель на всех регламентах», потому что актуальность ответа можно связывать с конкретной версией документа.
Но RAG не превращает любую папку в безопасную базу знаний. Перед загрузкой нужно определить, какие документы допустимы, кто подтверждает их актуальность, как отзывается устаревшая версия, кто видит найденные фрагменты и может ли система показать источник ответа. Векторная база, хранилище оригиналов, сервис эмбеддингов и журнал поиска тоже входят в контур обработки.
Подробно механику и подготовку корпоративной базы разбирает статья «Как научить нейросеть отвечать по документам компании — что такое RAG». Для банка особенно важен принцип — если модель не нашла подтверждения в утверждённом источнике, она должна сообщить об этом, а не достраивать правдоподобный ответ из общих знаний.
Дорожная карта внедрения
Сначала банк выбирает один ограниченный сценарий, где результат можно проверить человеком и где понятна цена ошибки. Затем описывает входные данные, контур, владельца, ограничения на интеграции и критерии приёмки. После этого готовится тестовый набор и проводится оценка угроз.
Следующим шагом создаётся пилот без автоматического действия во внешних или учётных системах. Модель делает черновик, сотрудник подтверждает или исправляет результат, команда собирает причины ошибок и дорабатывает промты, базу знаний, правила маршрутизации или подготовку данных.
Только после этого принимается решение о расширении. У процесса появляются регламент, обучение пользователей, контроль доступа, журналирование, порядок реакции на инциденты и план работы без ИИ. Если хотя бы один из этих элементов не готов, пилот стоит продлить или остановить. Это нормальный результат. Гораздо дешевле остановить неудачный сценарий на тестовом наборе, чем разбирать его последствия после реального клиента или реальной операции.
Банк России в своём консультационном докладе относит к существенным рискам ИИ на финансовом рынке не только ошибки модели, но и некачественные данные, утечки, уязвимости, зависимость от поставщиков и нарушения прав потребителей. Доклад и итоги его обсуждения полезны как чек-лист для руководителя, который оценивает не демонстрацию, а жизнеспособность процесса.
Перейти от пилота к практике
Программа «ИИ в финансовых организациях и банках» включает выбор контуров, работу с документами, RAG, ИИ-агентов и требования Банка России. Напишите исходные ограничения и состав команды, чтобы согласовать практику под ваши процессы.