Ещё несколько лет назад AI в платёжной индустрии чаще всего ассоциировался с fraud detection: модель анализирует транзакции и помогает выявлять потенциальное мошенничество.
Сегодня AI находится значительно глубже в технологическом стеке: участвует в risk scoring, анализирует security telemetry, помогает приоритизировать уязвимости, генерирует код и в отдельных сценариях самостоятельно выполняет действия через API.
Пока AI только предлагает текст для письма, последствия ошибки обычно ограничены качеством этого письма. Но когда модель влияет на платёжное решение, production-код или действие в критичной системе, вопрос «насколько хорошо она отвечает?» превращается в другой: «что именно ей разрешили делать и кто за это отвечает?»
В первой статье нашей серии — «PCI DSS и Swift CSP: разные экосистемы, знакомая ДНК безопасности» — мы говорили о том, что разные security frameworks во многом опираются на одни и те же фундаментальные принципы. С AI происходит похожая история: технология новая, а вопросы — удивительно знакомые.
PCI SSC: AI не отменяет PCI DSS
В сентябре 2026 года PCI Security Standards Council опубликовал Information Supplement «Security Considerations for AI Systems», посвящённый безопасности AI в платёжной среде.
Важно: это guidance, а не новый набор обязательных PCI DSS requirements.
Если AI-система получает доступ к account data, входит в CDE либо может повлиять на безопасность CDE, её нужно рассматривать в рамках PCI DSS scope и применять к ней соответствующие требования — так же, как к любой другой технологии.
Поэтому вопрос «в каком PCI DSS requirement написано про AI?» не всегда самый правильный. Сначала нужно понять архитектуру, данные, функции и влияние технологии на CDE — и только затем определить применимые controls.
AI — это не только chatbot
Когда сегодня говорят об AI, разговор слишком быстро сводится к корпоративному assistant: сотрудник задаёт вопрос, модель отвечает, и вся security-дискуссия заканчивается тем, можно ли вставлять PAN в prompt.
Но это далеко не единственный сценарий.
AI может оценивать вероятность мошенничества при транзакции, формировать risk score, анализировать security events, рекомендовать remediation, генерировать код для payment application или искать дефект в существующем коде.
А agentic AI уже может получить собственные credentials и взаимодействовать с другими системами — не только рекомендовать действие человеку, но и выполнять его.
Поэтому оценивать AI только через призму «не отправляйте чувствительные данные в ChatGPT» уже недостаточно.
Данные — только первый слой
Какие данные получает модель? Может ли в training, fine-tuning, RAG knowledge base, prompts или outputs попасть PAN? Где данные хранятся? Кто имеет к ним доступ? Передаются ли они внешнему provider? Какова политика retention?
Но зрелая оценка AI должна идти дальше.
Откуда появилась сама модель? Кто её поставщик? Как контролируется версия? На каких данных она обучалась или дообучалась? Какие внешние компоненты находятся вокруг неё?
Современная AI-система редко состоит только из «модели»: рядом могут находиться inference service, vector database, RAG, API, plugins и downstream systems.
Иными словами, у AI тоже есть supply chain и trust boundaries. Если схема архитектуры заканчивается прямоугольником с надписью «AI», это, скорее всего, не конец анализа, а только его начало.
Когда AI начинает принимать решения
Самая интересная граница появляется тогда, когда AI перестаёт быть советником.
Представим систему, которая анализирует security telemetry и при высокой вероятности атаки автоматически изолирует endpoint. Или модель, которая помогает принять решение по подозрительной транзакции. Или agent, способный выполнить действие через privileged API.
Такие сценарии могут быть оправданы: автоматическое fail-secure действие иногда позволяет отреагировать быстрее человека.
Но вместе с автономностью растёт цена ошибки.
False positive в отчёте — неприятность. False positive, который автоматически блокирует критичную систему или влияет на реальную операцию, — уже архитектурный риск.
Поэтому нужно заранее определить, какие действия AI выполняет самостоятельно, где требуется human approval, какие установлены лимиты, можно ли отменить действие и как быстро систему можно отключить.
«AI решил» — удобное объяснение до первого серьёзного инцидента. После него обычно всё равно приходится искать человека, который отвечал за архитектуру, права доступа и правила принятия решений.
Least privilege теперь нужен не только людям
Agentic AI хорошо возвращает нас к классическому принципу least privilege.
Если AI требуется доступ к API, базе данных или инфраструктуре, ему не нужен универсальный service account с правами «потому что так быстрее настроить».
Credentials должны быть идентифицируемыми, ограниченными конкретным use case и по возможности быстро отзываемыми. Действия AI должны быть отделимы от действий пользователей и других сервисов.
То есть к AI-agent стоит задать те же вопросы, которые assessor задаёт к privileged account: что он может видеть, что может изменить, какие команды способен выполнить и где заканчиваются его полномочия?
Новая технология не делает чрезмерные привилегии менее опасными. Иногда она просто позволяет использовать их быстрее.
Можно ли доверять самой модели?
Поведение AI-систем может быть недетерминированным. Оно способно меняться после обновления модели, изменения training data, fine-tuning или накопления нового контекста.
Отсюда отдельная задача — validation не только перед production deployment, но и в течение жизненного цикла.
Нужно понимать, продолжает ли модель работать в ожидаемых границах, не появился ли model drift и не изменилось ли поведение после обновлений.
Сюда же относятся data poisoning и prompt injection.
Названия новые, но идея старая: если система принимает внешние данные и на их основании выполняет логику, входным данным нельзя доверять автоматически.
Просто теперь неправильный input потенциально способен убедить систему не только выдать странный текст, но и выполнить вполне реальное действие.
А если AI пишет код?
AI-assisted development уже сложно назвать будущим.
Но «код компилируется» и «код безопасен» — всё ещё не синонимы.
Модель может предложить устаревшую библиотеку, слабую authentication logic, небезопасную работу с secrets или функционально правильное решение с security-дефектом внутри.
Поэтому AI-generated code не получает иммунитет от secure SDLC. Code review, security testing, vulnerability identification, change management и approval остаются частью процесса.
AI может ускорить разработчика. Он не должен ускорять обход контрольных точек.
Что в итоге будет смотреть assessor?
Для assessment AI важен прежде всего потому, что быстро превращается из отдельного инструмента в часть реальной архитектуры.
Поэтому вопрос «используете ли вы AI?» сам по себе мало что говорит.
Гораздо важнее другое:
Какие AI-системы существуют и какие функции выполняют?
Какие данные они получают и где эти данные проходят?
Какие модели, providers и внешние компоненты участвуют?
Может ли система повлиять на CDE или security controls?
Какие credentials и privileges она имеет?
Какие действия выполняет самостоятельно, а какие требуют approval?
Как логируются действия и проводится validation?
И, наконец, как AI будет быстро ограничен или отключён, если начнёт вести себя не так, как ожидалось?
Ответы на эти вопросы и определяют реальный risk profile. Не само наличие букв AI в архитектурной схеме.
Для Q.V.— этот вопрос уже не выглядит исключительно теоретическим. По мере того как AI становится частью payment и security architecture, assessor должен понимать не только классические network и application flows, но и роль модели, данных, внешних AI services и автономных действий в общей trust model.
Технология новая. Ответственность — нет
AI способен заметно изменить платёжную индустрию: быстрее выявлять fraud, анализировать риски, помогать разработчикам и автоматизировать действия.
Чем глубже AI входит в критичную инфраструктуру, тем меньше смысла относиться к нему как к экспериментальной игрушке.
В какой-то момент это просто ещё один компонент системы — возможно, очень умный, очень быстрый и не всегда полностью предсказуемый.
И тогда снова приходится отвечать на старые вопросы: какие данные он видит, какие права имеет, кто контролирует его действия, как проверяется его корректность и кто в конечном итоге несёт ответственность?
AI может изменить способ, которым работает платёжная среда.
Но ответственность за её безопасность он на себя пока не забрал.
Автор статьи
Камран Нагиев
PCI DSS QSA | Swift CSP Assessor
Q.V. LLC
qvisoft.com
