Финансы, банки и страхование: большие языковые модели как управляемый слой документов, комплаенса, разработки и клиентских процессов

1. Финансовый сектор: цифровая плотность выше, цена ошибки тоже

Российский финансовый сектор уже не является «поздним потребителем» цифровых решений. Платежная инфраструктура, удаленная идентификация, цифровой профиль, открытые программные интерфейсы, антифрод-контуры, дистанционное банковское обслуживание, страховые витрины и регуляторная отчетность образуют среду, где каждое новое решение должно быть встроено в существующую систему доверия. Банк России прямо относит Единую биометрическую систему, Цифровой профиль, платежную систему «Мир» и Систему быстрых платежей к инфраструктурным решениям, ставшим привычными элементами финансовой жизни.^[1]

Для руководителя это означает: большие языковые модели нельзя рассматривать как отдельный эксперимент отдела инноваций. В банке или страховой компании модель почти сразу касается данных клиентов, регламентов, договоров, обращений, кода, отчетности, внутренней базы знаний и решений, которые могут повлиять на клиента. Поэтому первый вопрос — не «какая модель лучше?», а «какой контур допуска, журналирования, контроля качества и ответственности мы строим?».

В 2025 году Банк России инициировал обсуждение национальной цифровой инфраструктуры финансового рынка — сервисов идентификации, платежных решений и механизмов обмена данными. Цифровой профиль позволяет финансовым организациям получать данные из государственных информационных систем с согласия клиента, что сокращает время оформления займов, страховых полисов и других услуг.^[3]

В страховании также растет значение качества данных: Банк России указывает на работу по улучшению данных в АИС «Страхование», развитие контрольных процедур, кросс-проверки с разными источниками и интеграцию с государственными информационными системами.^[4]

Управленческий вывод: большие языковые модели в финансах должны работать не «рядом» с цифровой инфраструктурой, а внутри архитектуры доступа, согласий, журналов, регламентов и защищенных контуров.

2. Где большая языковая модель дает отраслевой эффект

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

Наиболее зрелые сценарии — те, где модель готовит черновик, классифицирует, ищет по базе знаний, сверяет документы, предлагает маршрут или формирует тестовые артефакты, но результат утверждает человек или автоматизированный контроль по правилам. Такой подход соответствует риск-ориентированной логике: Банк России отмечает, что большинство регуляторов придерживаются технологически нейтрального и риск-ориентированного подхода к ИИ, а фокус рисков включает модельные риски и ИБ.^[5]

Ключевые сценарии для банков и страховщиков

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

В этой логике большая языковая модель не заменяет АБС, систему управления клиентскими отношениями, DWH, скоринговый движок, процессинг, антифрод или страховое ядро. Он становится интерфейсом к знаниям и рабочим артефактам, но не получает права самостоятельно менять состояние критичных систем.

В финансах большая языковая модель должна быть не советником, а контролируемым слоем работы с текстом, кодом и знаниями.

3. Метаплатформа: почему нельзя внедрять большие языковые модели напрямую в ядро

Типовая финансовая ИТ-архитектура неоднородна: АБС, система управления клиентскими отношениями, DWH, система бизнес-аналитики, скоринговые системы, процессинг, ДБО, антифрод, системы комплаенса, страховые ядра, документооборот, контакт-центр, хранилища регламентов, шлюзы программных интерфейсов и десятки самописных интеграций. Старые системы возникают не только в старом коде, но и в организационных привычках: Excel-отчетность, ручная сверка документов, индивидуальные трактовки регламентов, неформальные таблицы продуктовых условий, ручные юридические заключения.

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

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

4. Шлюз доступа к большим языковым моделям: контрольная точка финансового ИИ

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

Для финансового сектора шлюз должен выполнять минимум восемь функций:

1. классификация запроса: персональные данные, банковская тайна, страховая тайна, коммерческая тайна, код, открытая информация, регламент;
2. маршрутизация в допустимый контур: публичное облако, частное облако, во внутреннем контуре организации или изолированный контур;
3. маскирование и обезличивание, где это допустимо и проверено профильными специалистами;
4. управление корпусами проверенных источников для ответов модели — то есть поиском по разрешенным источникам с привязкой ответа к документам;
5. контроль внедрения вредоносных инструкций в запрос, утечек системных инструкций и попыток извлечения закрытых данных;
6. журналирование запросов, ответов, источников, версии модели и пользователя;
7. проверка результата по правилам, шаблонам, справочникам и контрольным спискам;
8. сбор метрик качества, инцидентов и обратной связи.

OWASP в актуальных материалах по большим языковым моделям выделяет внедрение вредоносных инструкций в запрос, утечку чувствительной информации, уязвимости цепочек поставки, избыточную автономность и чрезмерное доверие к ответам модели как отдельные классы рисков.^[6]

5. Облако, частное облако, во внутреннем контуре организации, изолированный контур: где допустимы разные контуры

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

Решение о контуре должно учитывать требования к персональным данным, КИИ, импортонезависимости и отраслевым режимам тайны. Федеральный закон №152-ФЗ определяет цель защиты прав и свобод человека при обработке персональных данных, а в 2025 году Роскомнадзор утвердил требования и методы обезличивания персональных данных, которые финансовым организациям нужно учитывать при проектировании сценариев применения ИИ.^[7][8]

Для значимых объектов КИИ применяется отдельная логика защиты: 187-ФЗ регулирует безопасность критической информационной инфраструктуры, а приказ ФСТЭК №239 устанавливает требования по обеспечению безопасности значимых объектов КИИ.^[9][10]

Кроме того, Указ Президента №166 задает контекст технологической независимости и безопасности КИИ; с 1 января 2025 года для органов власти и заказчиков установлен запрет на использование иностранного ПО на принадлежащих им значимых объектах КИИ.^[11]

6. Отраслевая матрица сценариев

7. Комплаенс и документы: полезно, но не автономно

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

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

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

Главный риск — не галлюцинация модели, а отсутствие владельца результата.

8. Разработка и старый ИТ-контур: эффект быстрее, чем во фронт-офисе

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

Практические сценарии

• объяснение фрагментов наследованного кода;
• поиск зависимостей между модулями;
• генерация технической документации;
• подготовка тест-кейсов по требованиям;
• сверка программных интерфейсов, требований и фактической документации;
• генерация запросов к базам данных для аналитиков с последующей проверкой;
• подготовка миграционных карт при модернизации АБС, системы управления клиентскими отношениями или DWH;
• анализ дефектов и инцидентов по журналам.

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

9. Система управления применением ИИ: что должно быть до масштабирования

Система управления применением ИИ в финансовой организации — это не комитет «про инновации». Это операционная система управления сценариями применения ИИ.

Минимальный набор

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

Международные рамки также движутся в сторону управляемости. Рамка NIST по управлению рисками ИИ описывает риск-ориентированную рамку для организаций, которые проектируют, внедряют или используют системы ИИ, а ISO/IEC 42001 задает требования к системе менеджмента ИИ, включая ответственность, прозрачность и управление рисками.^[12][13]

10. Для кого создается эффект

Для бизнеса. Снижается нагрузка на поддержку и операционный контур, ускоряется разработка, повышается качество документации, уменьшается число ошибок в типовых ответах, быстрее выводятся изменения в продуктах и сервисах.

Для государства и регуляторного контура. Увеличивается прозрачность сценариев применения ИИ: журналы, владельцы, классификация, контроль рисков, единая логика работы с данными и возможность проверять, где модель применялась, а где решение принимал человек.

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

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

11. Что делать руководителю в ближайшие 90 дней

1. Провести инвентаризацию использования ИИ. Выявить официальные и теневые сценарии применения больших языковых моделей: сотрудники, подразделения, данные, сервисы, поставщики, цели.
2. Утвердить классификацию данных для больших языковых моделей. Отдельно выделить персональные данные, банковскую и страховую тайну, коммерческую тайну, код, регламенты, клиентские обращения, обезличенные и открытые данные.
3. Запустить шлюз доступа к большим языковым моделям как обязательную точку доступа. Все корпоративные сценарии должны идти через единый шлюз с журналами, политиками, запретами и маршрутизацией.
4. Выбрать 3–5 пилотов с контролируемым риском. Например: ассистент оператора, поиск по регламентам, черновики ответов, генерация тест-кейсов, документация наследованного кода.
5. Назначить владельцев сценариев применения ИИ. У каждого сценария должен быть бизнес-владелец, ИТ-владелец, представитель ИБ и ответственный за качество.
6. Ввести обязательную проверку человеком. Формально закрепить, где результат модели является черновиком, а где требуется утверждение специалистом.
7. Создать базовые приемочные тесты. Проверять точность, источники, утечки, устойчивость к внедрению вредоносных инструкций в запрос, качество отказов и корректность журналирования.
8. Подготовить дорожную карту модернизации старого ИТ-контура. Начать с документирования, карт зависимостей, тестового покрытия и сверки программных интерфейсов, не меняя ядро без достаточного контроля.

12. Метрики успеха

13. Риски и ограничения

Заключение

Финансовый сектор не нуждается в еще одном неконтролируемом цифровом канале. У банков, страховщиков, брокеров, НПФ и финансовых платформ уже достаточно сложная архитектура: платежи, данные, согласия, идентификация, антифрод, отчетность, персональные данные, коммерческая тайна, старый ИТ-контур и высокие ожидания клиентов. Поэтому большие языковые модели здесь должны внедряться не как технологический аттракцион, а как управляемый слой повышения операционной точности.

Главная ценность больших языковых моделей — не в том, что модель «знает ответ». В финансах это даже опасная формулировка. Ценность в другом: быстрее найти нужный регламент, подготовить черновик ответа, объяснить документ, подсветить несоответствие, помочь разработчику разобраться в старом коде, собрать тест-кейсы, связать требования и программные интерфейсы, снизить нагрузку на оператора и сделать корпоративные знания доступнее. Но каждое из этих действий должно оставлять след: кто запросил, какие данные использованы, какой источник был применен, какая модель ответила, кто проверил и где результат был принят в работу.

Метаплатформа, шлюз доступа к большим языковым моделям, суверенный контур работы с большими языковыми моделями и система управления применением ИИ превращают ИИ из теневого инструмента в промышленный сервис. Это особенно важно в условиях импортонезависимости, требований к КИИ, защиты персональных данных, роста цифровой инфраструктуры финансового рынка и необходимости модернизировать старый ИТ-контур без риска для ядра. Переход к большим языковым моделям не отменяет АБС, систему управления клиентскими отношениями, DWH, процессинг, скоринг, антифрод и страховые ядра. Он меняет экономику работы вокруг них: анализа, документации, тестирования, сопровождения, клиентских коммуникаций и комплаенса.

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