Кибербезопасность, анализ данных и бизнес-мышление в ИТ-проектах крупного банка стали главными темами мартовского Техновечера Газпромбанк.Тех. Команда собрала формат, больше похожий на вечернее шоу, чем на классический митап: неоновый свет, визуальный стиль мегаполиса начала нулевых, непринужденная атмосфера - и при этом очень плотная повестка по содержанию.
В зале - около 180 человек: студенты старших курсов, начинающие айтишники, участники молодежных финтех-программ. В программе - четыре тематических выступления, круглый стол с полуфиналистами крупной молодежной программы и живой нетворкинг с практиками из индустрии. Темы распределились по ключевым направлениям, которые сегодня определяют развитие банковских технологий: искусственный интеллект в кибербезопасности, полный цикл Data Science-проектов, роль джунов в защите от угроз и бизнес-анализ как фундамент для успешной разработки.
Искусственный интеллект на стороне кибербезопасности - и против нее
Алексей Найденов, управляющий директор Управления алгоритмов машинного обучения, показал, что ИИ в банке - это уже не эксперимент, а рабочий инструмент, глубоко встроенный в процессы защиты. При этом он подчеркнул: искусственный интеллект не "вычеркивает" существующие системы безопасности, а надстраивается над ними, усиливая экспертов и помогая им быстрее разбираться с огромными объемами данных.
ИИ используется сразу в нескольких критичных зонах.
Во‑первых, статический анализ кода. Специализированные программы ежедневно прогоняют гигабайты исходников и формируют масштабные отчеты с сотнями и тысячами потенциальных уязвимостей. Человек физически не успеет оперативно разобрать такой массив. Здесь подключаются большие языковые модели: они помогают отсечь "шум", выделить реальные угрозы, сгруппировать повторяющиеся проблемы и подсказывают приоритеты для разработчиков и безопасников.
Во‑вторых, динамическое сканирование. При таком подходе проверяется уже работающая система: эндпоинты, API, интеграции. Модель генерирует сценарии атак, прогоняет их по инфраструктуре и затем обрабатывает миллионы результатов. В ручном режиме это заняло бы недели, а ИИ позволяет сократить анализ до приемлемых для бизнеса сроков и повысить полноту проверки.
В‑третьих, обнаружение аномалий. В банке каждую секунду происходят транзакции, логируются действия пользователей и сервисов. Среди этого потока нужно вовремя заметить нетипичное поведение: попытки подбора паролей, подозрительные операции, аномальные запросы к внутренним системам. Модели машинного обучения обучаются на "нормальном" профиле работы клиентов и инфраструктуры, а затем сигнализируют о любых выбросах, помогающих предотвратить инциденты еще на ранней стадии.
Однако с появлением больших языковых моделей и новых архитектур тот же ИИ стал источником совершенно новых угроз. Алексей подробно остановился на трех ключевых рисках.
Prompt injection. Злоумышленник пытается внедрить в запросы к модели скрытые инструкции, которые заставляют ее игнорировать системные правила и вести себя некорректно. В банковской среде это особенно опасно, если ИИ используется в чатах с клиентами или во внутренних помощниках для сотрудников: неправильный ответ может дорого обойтись.
Галлюцинации. Модель может "додумывать" факты и условия там, где ей не хватает данных. В потребительском сервисе это неприятно, но терпимо. В случае с договорами, ставками, лимитами и юридически значимой информацией - это уже прямая угроза: клиент может принять финансовое решение, опираясь на несуществующие условия.
Jailbreaking. Попытки обойти встроенные ограничения через продуманные цепочки запросов. По словам Алексея, по мере того как модели получают доступ к внешним инструментам - браузеру, корпоративным файлам, почте, - увеличиваются риски утечки данных и несанкционированных действий от имени пользователя.
Пока универсальных изящных решений нет, поэтому применяются прямолинейные, но рабочие меры: вокруг модели выстраивается "кольцо безопасности" из фильтров - на входе и на выходе. Эти фильтры проверяют содержание запросов и ответов, отслеживают попытки получить доступ к персональным данным, блокируют потенциально опасные инструкции и логируют все действия для последующего анализа.
Жизненный цикл DS-проекта: не только про код
Анастасия Еремина, начальник Управления розничного моделирования, предложила посмотреть на Data Science не как на набор алгоритмов и тетрадок в Jupyter, а как на длинный управляемый процесс, где программирование - только одна из стадий. Она описала жизненный цикл типового DS-проекта в банке как 11 этапов - от первой встречи с инициатором задачи до постоянного мониторинга модели в продакшене.
Ключевым узловым моментом Анастасия назвала формулирование и фиксацию бизнес‑требований. Это не "бумажка для галочки", а реальный механизм защиты и для команды, и для заказчика. Если БТ не оформить, в финале легко услышать: "Это не то, что я имел в виду". Когда же есть согласованный документ с четкими целями, метриками успеха, ограничениями и допущениями, у команды появляется опорная точка и аргументы в спорных ситуациях.
Отдельная постоянная проблема - поиск и подготовка данных. В крупных организациях витрины могут быть распределены по разным системам, документация устаревшей, а ответственные за наборы данных - неочевидными. На этом этапе легко "застрять" на месяцы. В реальности поиск исходных данных может занять от трех дней до полугода, особенно если речь о нестандартной задаче.
Чтобы не начинать каждый раз с нуля, команда Анастасии создала внутренний фича-стор - централизованное хранилище признаков по всей клиентской базе. Атрибуты туда собираются и обновляются каждые две недели. Для задач, которые повторяются или хотя бы частично похожи, это огромный выигрыш: вместо многоступенчатого согласования и ручного поиска таблиц, DS-команда за один‑два дня находит все нужное и может сосредоточиться на моделировании, а не на переписке с владельцами данных.
При этом жизненный цикл проекта не заканчивается в момент, когда модель "уехала" в продакшен. Бизнес‑среда меняется, поведение клиентов эволюционирует, появляются новые продукты, и качество предсказаний неминуемо деградирует. Поэтому мониторинг показателей модели - точности, полноты, экономического эффекта - становится постоянной обязанностью. В какой-то момент команда должна честно признать: старая версия себя исчерпала, нужно проводить пересмотр, переобучение или даже полный пересмотр подхода.
Джуны в кибербезопасности: зачем они нужны, если есть ИИ
Илья Коцюба, начальник Отдела защиты от киберугроз, сразу развеял популярный страх: никакой искусственный интеллект в обозримом будущем не заберет работу у начинающих специалистов в информационной безопасности. По его словам, наоборот - растущий объем угроз и усложнение инфраструктур делают спрос на свежие кадры только выше.
Для начала он описал масштаб. Любой крупный банк живет в режиме постоянной обороны: каждые сутки фиксируются попытки вывести из строя публичные сервисы, фишинговые рассылки в адрес клиентов и сотрудников, атаки вымогателей, активная социальная инженерия с подделкой личности руководителей или партнеров. Всю эту картину нужно не просто мониторить, но и уметь на нее грамотно реагировать.
Система защиты строится сразу по нескольким направлениям.
*Архитектура.* На уровне проектирования инфраструктуры закладываются принципы сегментации, ограничение прав, изоляция критичных сервисов, резервирование. Если архитектура спроектирована неграмотно, никакие "надстроечные" средства защиты ситуацию не спасут.
*Защита и мониторинг.* Администрирование средств защиты информации, работа центра мониторинга (SOC), антифрод-системы, киберразведка - все это требует постоянной ручной настройки, адаптации под новые виды атак и участия специалистов, которые понимают контекст происходящего.
*Наступательные команды.* Внутренний Red Team, команды анализа защищенности приложений, управления уязвимостями регулярно "атакуют" банковский периметр, симулируют реальные сценарии злоумышленников и проверяют, выдержат ли политики и настройки такой натиск.
*Комплаенс и регуляторика.* Банк обязан соответствовать целому набору требований: от национальных стандартов до отраслевых норм для работы с платежными картами и персональными данными. Это отдельный пласт работы, где важна внимательность к деталям и понимание юридических последствий.
На этом фоне становится ясно, что полагаться только на сеньоров бессмысленно: одна опытная команда не сможет физически покрыть все направления, особенно если организация активно растет. Однако, по словам Ильи, восемь из десяти студенческих резюме приходятся всего на две роли: SOC‑аналитик и пентестер. Остальные области - архитектура, управление уязвимостями, анализ инцидентов, форензика, комплаенс - остаются недооцененными, хотя именно там много точек входа для джунов.
Для старта, считает Илья, важнее всего не знание конкретного софта или "модных" тулов, а базовый фундамент: как устроены операционные системы, как работает стек сетевых протоколов, какие бывают классы угроз и векторы атак, где проходят границы ответственности разных команд. К этому добавляются дисциплина, аккуратность в работе с логами и отчетами и умение задавать правильные вопросы наставникам - без этого рост в профессии сильно замедляется.
Бизнес-анализ: цена ошибки растет с каждым этапом
Ксения Лисицкая, заместитель начальника Управления бизнес-технологий, сфокусировалась на теме, которую айтишники нередко недооценивают: бизнес-анализ. В современных организациях почти все ИТ-проекты делаются кросс‑функциональными командами - в одной связке работают аналитики, разработчики, тестировщики, представители бизнеса, безопасности, эксплуатации. Точка соприкосновения для всех - общие бизнес‑показатели, за которые команда отвечает.
Ксения акцентировала: стоимость одной и той же ошибки на разных этапах процесса отличается в разы. Если неверный коэффициент или пропущенное условие найти на стадии анализа и согласования требований, достаточно пары минут разговора со специалистом по предметной области. Если недочет всплывает уже в разработке - придется переписывать код и отвлекать разработчиков от других задач. Но хуже всего, когда ошибка проявляется в боевой среде: например, искажается бухгалтерская или управленческая отчетность, клиентам показываются неверные суммы, нарушаются регуляторные требования. В этом случае цена промаха исчисляется не только часами переработки, но и прямыми финансовыми потерями и ударом по репутации.
Она разобрала девять ключевых принципов качественных требований: атомарность, полнота, согласованность, однозначность, проверяемость, реализуемость, трассируемость, приоритизация и актуальность. Особое внимание Ксения уделила однозначности формулировок. В реальной практике даже одно неосторожно выбранное слово может породить две противоположные трактовки.
Так, в одном из проектов в требованиях было написано "открыть поля". Один разработчик понял это как "сделать видимыми для просмотра", другой - как "разрешить редактирование". В результате на тестовом стенде часть пользователей получила доступ к изменению данных, которые должны были быть только для чтения. Время на разбор полета и переделку ушло бы куда меньше, если бы изначально формулировка была точной: "сделать поля видимыми, но недоступными для редактирования".
Отдельный блок выступления Ксения посвятила инструментам структурирования бизнес-идей. В частности, она показала, как можно использовать компактное полотно для описания продукта: на одной странице фиксируются сегменты клиентов, их ключевые проблемы, ценностное предложение, каналы коммуникации, источники дохода и структура затрат. Такой подход помогает быстро проверить, есть ли у инициативы реальное бизнес‑основание, до того как к ней подключатся разработчики и начнутся серьезные траты ресурсов.
Зачем ИТ-специалисту понимать бизнес
Одна из сквозных мыслей Техновечера: ИТ в крупном банке давно перестало быть "подрядчиком по задачам". Технологические команды напрямую влияют на выручку, клиентский опыт и операционную эффективность, а значит - вынуждены мыслить бизнес‑категориями.
Для разработчика это значит, что приоритет задач определяется не только технической сложностью, но и влиянием на ключевые метрики: конверсию, NPS, стоимость обработки операции, уровень риска. Для аналитика данных - что модель, которая на процент улучшает метрику качества, но не приносит измеримого экономического эффекта, вряд ли имеет смысл. Для безопасника - что чрезмерно жесткие правила, из‑за которых клиенты массово не могут совершить легитимные операции, станут не достижением, а проблемой.
Участники мероприятий отмечали, что умение "переводить" языки друг друга - бизнеса и технологий - сегодня становится почти обязательным навыком. Там, где аналитик может четко объяснить разработчику, какой именно показатель важно посчитать и почему, а безопасник способен донести до продуктовой команды суть ограничений без абстрактных "так нельзя", проекты продвигаются заметно быстрее и с меньшими конфликтами.
Новые вызовы для Data Science в банке
В дополнение к рассказу о жизненном цикле DS-проектов, спикеры поднимали тему меняющегося ландшафта задач. Если еще несколько лет назад основное внимание уделялось скоринговым моделям и классическому кредитному риск‑менеджменту, то сейчас все сильнее растет доля задач, связанных с персонализацией и реалтайм‑анализом поведения клиентов.
Банк стремится делать предложения максимально релевантными и своевременными, не перегружая клиентов "шумными" уведомлениями. Для этого нужно объединять данные из разных систем - мобильного приложения, контакт‑центра, транзакционной активности, внешних источников. На стыке этих потоков формируются сложные модели, которые оценивают вероятность интереса к продуктам, оттока, отклика на коммуникацию.
Это повышает требования к инженерной культуре в Data Science: становится важен не только сам алгоритм, но и качество инфраструктуры, системы логирования, управление экспериментами. Без этого модель может "хорошо" работать в лабораторных условиях и вести себя непредсказуемо в продакшене.
Как ИИ меняет повседневную работу безопасника и аналитика
Спикеры отдельно обсуждали, как большие языковые модели уже сейчас встраиваются в повседневные рабочие процессы. В кибербезопасности ИИ помогает автоматически разбирать инциденты, формировать черновики отчетов по атаке, подсвечивать нетипичные последовательности действий злоумышленника в логах. В аналитике - генерировать первичный SQL‑код, строить черновые дашборды и визуализации, упрощать подготовку документации по моделям и требованиям.
Важно, что от специалистов при этом требуется не слепое доверие к рекомендациям модели, а критическое мышление. ИИ становится "усилителем" продуктивности, но ответственность за решения по‑прежнему несет человек. Умение проверить выводы модели, воспроизвести логику рассуждений и заметить нестыковки оказывается одним из ключевых скиллов.
Карьера в большом банке: что важно на старте
Вопрос, который звучал и в кулуарах, и во время официальной части: что делать студенту или джуну, который хочет попасть в ИТ-подразделение крупного банка? Спикеры сошлись в нескольких рекомендациях.
Во‑первых, не зацикливаться на одной "громкой" роли. В кибербезопасности, помимо SOC и пентеста, существуют направления архитектуры, анализа уязвимостей, реагирования на инциденты, расследований, комплаенса. В Data Science - продуктовая аналитика, инженерия данных, MLOps. В бизнес-анализе - как функциональный, так и системный уровень. Чем шире кругозор, тем больше шансов найти точку входа.
Во‑вторых, собирать практический трек‑запись: учебные проекты, пет-проекты, участие в хакатонах, стажировках. Работодателей интересует не только список курсов, но и реальное умение доводить задачи до результата.
В‑третьих, развивать софт‑скиллы: умение формулировать вопросы, презентовать свои решения, признавать ошибки и извлекать из них уроки. В кросс‑функциональных командах это часто оказывается не менее важным, чем знание конкретного фреймворка или языка программирования.
Командная работа и культура взаимодействия
Завершая вечер, участники неоднократно возвращались к теме командной динамики. Технологии стремительно меняются, но устойчивый результат дает только та команда, которая умеет договариваться о целях, прозрачно распределять ответственность и быстро обмениваться знаниями.
Кросс‑функциональные форматы, где рядом сидят разработчик, аналитик, бизнес‑представитель и безопасник, меняют стиль работы: исчезают "длинные" цепочки согласований, повышается скорость обратной связи. С другой стороны, возлагается большая ответственность на каждого члена команды: нужно уметь объяснить свои решения понятным языком для коллег других ролей и слышать их аргументы.
Техновечер показал, что современный ИТ‑ландшафт в большом банке - это не только про сложные технологии и строгие регламенты. Это еще и про живое взаимодействие людей, совместный поиск баланса между безопасностью, удобством и выгодой, а также постоянное обучение - и экспертов, и тех, кто только делает первые шаги в профессии.
