Hələ bir neçə il əvvəl ödəniş sektorunda Sİ (AI) çox vaxt fraud detection (fırıldaqçılığın aşkar edilməsi) ilə assosiasiya olunurdu: model tranzaksiyaları təhlil edir və potensial fırıldaqçılığı müəyyən etməyə kömək edir.
Bu gün Sİ texnoloji stेकdə xeyli dərinlikdə yerləşir: risk scoring-də iştirak edir, security telemetry-ni təhlil edir, boşluqların prioritetləşdirilməsinə kömək edir, kod generasiya edir və ayrı-ayrı ssenarilərdə API vasitəsilə müstəqil olaraq əməliyyatlar yerinə yetrir.
Hələlik Sİ yalnız məktub üçün mətn təklif edirsə, səhvin nəticələri adətən həmin məktubun keyfiyyəti ilə məhdudlaşır. Lakin model ödəniş qərarına, production-koda və ya kritik sistemdəki hərəkətə təsir etdikdə, “o, nə qədər yaxşı cavab verir?” sualı başqa bir suala çevrilir: “ona dəqiq olaraq nə etməyə icazə verilib və buna görə kim cavabdehdir?”
Silsilə yazılarımızın birincisində — “PCI DSS və Swift CSP: müxtəlif ekosistemlər, tanış təhlükəsizlik DNT-si” — biz qeyd etmişdik ki, müxtəlif təhlükəsizlik çərçivələri (security frameworks) əsasən eyni fundamental prinsiplərə əsaslanır. Sİ ilə də buna bənzər bir tarixçə baş verir: texnologiya yenidir, lakin suallar təəccüblü şəkildə tanışdır.
PCI SSC: Sİ, PCI DSS-i ləğv etmir
2026-cı ilin sentyabr ayında PCI Security Standards Council Sİ-nin ödəniş mühitində təhlükəsizliyinə həsr olunmuş “Security Considerations for AI Systems” adlı Information Supplement nəşr etdi.
Vacibdir: bu, yeni məcburi PCI DSS tələbləri dəsti deyil, sadəcə guidance (təlimat) xarakterlidir.
Əgər Sİ sistemi account data əldə edirsə, CDE-yə (Cardholder Data Environment) daxildirsə və ya CDE-nin təhlükəsizliyinə təsir edə bilərsə, onu PCI DSS scope (əhatə dairəsi) çərçivəsində nəzərdən keçirmək və digər istənilən texnologiyada olduğu kimi ona müvafiq tələblər tətbiq etmək lazımdır.
Ona görə də “hansı PCI DSS tələbində Sİ haqqında yazılıb?” sualı həmişə ən düzgün sual deyil. Əvvəlcə arxitekturanı, məlumatları, funksiyaları və texnologiyanın CDE-yə təsirini başa düşmək, və yalnız bundan sonra tətbiq olunan idarəetmə vasitələrini (controls) müəyyən etmək lazımdır.
Sİ təkcə çat-bot deyil
Bu gün Sİ haqqında danışdıqda söhbət çox tez korporativ köməkçiyə (assistant) gəlib çıxır: əməkdaş sual verir, model cavab verir və bütün təhlükəsizlik müzakirəsi PAN-ı prompt-a daxil etməyin mümkün olub-olmaması ilə bitir.
Lakin bu, yeganə ssenari deyil.
Sİ tranzaksiya zamanı fırıldaqçılıq ehtimalını qiymətləndirə, risk score formalaşdıra, təhlükəsizlik hadisələrini təhlil edə, bərpa tədbirləri (remediation) tövsiyə edə, ödəniş tətbiqi üçün kod yarada və ya mövcud kodda qüsur axtara bilər.
Və agentic AI artıq öz məlumat məlumatlarına (credentials) sahib ola və digər sistemlərlə qarşılıqlı əlaqədə ola bilər — təkcə insana hərəkət tövsiyə etməklə kifayətlənməyib, həm də onu yerinə yetirə bilər.
Ona görə də Sİ-ni yalnız “həssas məlumatları ChatGPT-yə göndərməyin” prizmasından qiymətləndirmək artıq kifayət deyil.
Məlumatlar yalnız birinci təbəqədir
Model hansı məlumatları alır? PAN training, fine-tuning, RAG knowledge base, prompts və ya outputs-a düşə bilərmi? Məlumatlar harada saxlanılır? Onlara kimin çıxışı var? Onlar xarici provayderə ötürülürmü? Saxlama (retention) siyasəti necədir?
Lakin yetkin Sİ qiymətləndirməsi daha irəliyə getməlidir.
Modelin özü haradan əmələ gəlib? Onun təchizatçısı kimdir? Versiya necə idarə olunur? O, hansı məlumatlar əsasında öyrədilib və ya yenidən öyrədilib? Onun ətrafında hansı xarici komponentlər mövcuddur?
Müasir Sİ sistemi nadir hallarda yalnız “məlumat”-dan ibarət olur: yaxınlıqda inference service, vector database, RAG, API, plugins və downstream systems ola bilər.
Başqa sözlə, Sİ-nin də təchizat zənciri (supply chain) və etibar sərhədləri (trust boundaries) var. Əgər arxitektura sxemi üzərində “Sİ” yazılmış düzbucaqlı ilə bitirsə, bu, çox güman ki, təhlilin sonu deyil, yalnız başlanğıcından ibarətdir.
Sİ qərarlar qəbul etməyə başlayanda
Ən maraqlı sərhəd Sİ məsləhətçi olmaqdan əl çəkəndə yaranır.
Təsəvvür edək ki, təhlükəsizlik telemetriyasını təhlil edən və hücum ehtimalı yüksək olduqda avtomatik olaraq nöqtəni (endpoint) təcrid edən bir sistem mövcuddur. Və ya şübhəli tranzaksiya üzrə qərar qəbul etməyə kömək edən model. Və ya imtiyazlı API vasitəsilə əməliyyat yerinə yetirməyə qadir olan agent.
Belə ssenarilər əsaslandırıla bilər: avtomatik fail-secure hərəkəti bəzən insandan daha sürətli reaksiya verməyə imkan yaradır.
Lakin avtonomluqla birlikdə səhvin qiyməti də artır.
Hesabatdakı False positive xoşagəlməz haldır. Kritik sistemi avtomatik bloklayan və ya real əməliyyata təsir edən False positive isə artıq memarlıq riskidir.
Ona görə də əvvəlcədən müəyyən etmək lazımdır ki, Sİ hansı hərəkətləri müstəqil şəkildə yerinə yetirir, harada insan təsdiqi (human approval) tələb olunur, hansı limitlər qoyulub, hərəkəti ləğv etmək (rollback) mümkündürlərmi və sistemi nə qədər tez söndürmək olar.
“Sİ qərar verdi” — ilk ciddi insidentə qədər rahat izahatdır. Ondan sonra adətən arxitekturaya, giriş hüquqlarına və qərar qəbuletmə qaydalarına cavabdeh olan insanı yenə də axtarmaq lazım gəlir.
Least privilege indi təkcə insanlar üçün lazım deyil
Agentic AI bizi klassik least privilege (ən az imtiyaz) prinsipinə çox yaxşı qaytarır.
Əgər Sİ-yə API, verilənlər bazası və ya infrastruktura çıxış lazımdırsa, ona “quraşdırmaq daha sürətlidir deyə” universal service account hüquqları lazım deyil.
İcazələr (credentials) identifikasiya olunan, konkret use case ilə məhdudlaşdırılan və mümkünsə tez geri çağırıla bilən olmalıdır. Sİ-nin hərəkətləri istifadəçilərin və digər xidmətlərin hərəkətlərindən ayrıla bilməlidir.
Yəni, Sİ agentinə auditorun (assessor) imtiyazlı hesaba verdiyi eyni sualları vermək lazımdır: o, nəyi görə bilər, nəyi dəyişə bilər, hansı əmrləri yerinə yetirməyə qadirdir və onun səlahiyyətləri harada bitir?
Yeni texnologiya həddindən artıq imtiyazları daha az təhlükəli etmir. Bəzən o, sadəcə olaraq onlardan daha sürətli istifadə etməyə imkan verir.
Modelin özünə etibar etmək olarmı?
Sİ sistemlərinin davranışı qeyri-determinik ola bilər. O, modelin yenilənməsindən, təlim məlumatlarının (training data) dəyişdirilməsindən, fine-tuning-dən və ya yeni kontekstin yığılmasından sonra dəyişə bilər.
Buradan da ayrı bir tapşırıq irəli gəlir — təkcə production deployment-dən əvvəl deyil, həm də həyat dövrü (lifecycle) ərzində validasiya aparılmalıdır.
Başa düşmək lazımdır ki, model gözlənilən sərhədlər daxilində işləməyə davam edirmi, model drift baş verməyib ki və yeniləmələrdən sonra davranış dəyişməyib ki.
Bura həmçinin data poisoning və prompt injection da daxildir.
Adlar yenidir, lakin ideya köhnədir: əgər sistem xarici məlumatları qəbul edirsə və onların əsasında məntiq yerinə yetirirsə, daxil olan məlumatlara avtomatik olaraq etibar etmək olmaz.
Sadəcə olaraq indi səhv input potensial olaraq sistemə yalnız qəribə mətn çıxarmağı deyil, həm də tamamilə real əməliyyat yerinə yetirməyi inandıra bilər.
Bəs Sİ kod yazırsa?
AI-assisted development-i artıq gələcək adlandırmaq çətindir.
Lakin “kod kompilyasiya olunur” və “kod təhlükəsizdir” hələ də sinonim deyil.
Model köhnəlmiş kitabxana, zəif autentifikasiya məntiqi, məxfi məlumatlarla (secrets) təhlükəsiz olmayan işləmə üsulu və ya daxilində təhlükəsizlik qüsuru olan funksional olaraq düzgün həll təklif edə bilər.
Ona görə də AI-generated code təhlükəsiz SDLC-dən toxunulmazlıq əldə etmir. Code review, security testing, vulnerability identification, change management və təsdiq (approval) prosesin bir hissəsi olaraq qalır.
Sİ proqramçını sürətləndirə bilər. O, nəzarət nöqtələrinin yanından keçməyi sürətləndirməməlidir.
Auditor nəticədə nəyə baxacaq?
Qiymətləndirmə (assessment) üçün Sİ hər şeydən əvvəl ona görə vacibdir ki, o, tez bir zamanda ayrı alətdən real arxitekturanın bir hissəsinə çevrilir.
Ona görə də “Sİ istifadə edirsinizmi?” sualı özlüyündə çox şey demir.
Çox daha vacibdir başqa məqamlar:
- Hansı Sİ sistemləri mövcuddur və hansı funksiyaları yerinə yetirirlər?
- Onlar hansı məlumatları alırlar və bu məlumatlar haradan keçir?
- Hansı modellər, provayderlər və xarici komponentlər iştirak edir?
- Sistem CDE-yə və ya təhlükəsizlik nəzarətinə (security controls) təsir edə bilrmi?
- Hansı hərəkətləri müstəqil şəkildə yerinə yetirir, hansılar isə təsdiq (approval) tələb edir?
- Hərəkətlər necə loqlaşdırılır (logging) və validasiya aparılır?
- Və nəhayət, əgər Sİ gözlənilməz davranmağa başlasa, onu necə sürətlə məhdudlaşdırmaq və ya söndürmək olar?
Bu sualların cavabları real risk profilini müəyyən edir. Arxitektura sxemində Sİ hərflərinin özünün mövcudluğu yox.
Q.V. üçün — bu sual artıq tamamilə nəzəri görünmür. Sİ ödəniş və təhlükəsizlik arxitekturasının bir hissəsinə çevrildikcə, auditor təkcə klassik şəbəkə və tətbiq axınlarını deyil, həm də ümumi etibar modelində (trust model) modelin, məlumatların, xarici Sİ xidmətlərinin və avtonom hərəkətlərin rolunu başa düşməlidir.
Texnologiya yenidir. Məsuliyyət — yox
Sİ ödəniş sektorunu nəzərəçarpacaq dərəcədə dəyişməyə qadirdir: fırıldaqçılığı daha tez aşkar etmək, riskləri təhlil etmək, proqramçılara kömək etmək və əməliyyatları avtomatlaşdırmaq.
Sİ kritik infrastruktura nə qədər dərin daxil olursa, ona eksperimental oyuncaq kimi yanaşmaq bir o qədər mənasız olur.
Müəyyən bir məqamda bu, sadəcə olaraq sistemin başqa bir komponentidir — ehtimal ki, çox ağıllı, çox sürətli və həmişə tam proqnozlaşdırıla bilən olmayan.
Və o zaman köhnə suallara yenidən cavab vermək lazım gəlir: o, hansı məlumatları görür, hansı hüquqlara malikdir, onun hərəkətlərinə kim nəzarət edir, onun düzgünlüyü necə yoxlanılır və son nəticədə kim cavabdehdir?
Sİ ödəniş mühitinin işləmə üsulunu dəyişə bilər.
Lakin onun təhlükəsizliyinə görə məsuliyyəti hələlik öz üzərinə götürməyib.
Məqalənin müəllifi
Kamran Nağıyev
PCI DSS QSA | Swift CSP Assessor
Q.V. LLC
qvisoft.com
