Korporativ AI-ın qorunması mühəndislik məsələsindən əvvəl proqram məsələsidir. O, təşkilatdakı hər AI sisteminin inventarını, hər biri üçün risk təsnifatını, mütənasib tətbiq olunan yeddi nəzarət ailəsini və mövcud heç bir runbook-un əhatə etmədiyi uğursuzluq formasını idarə edə bilən insident prosesini tələb edir.
Mühəndislik nəzarətləri vacibdir və başqa yerdə açılıb. Bu məqalə onların üstündəki qat haqqındadır: təhlükəsizlik funksiyası nəyi müdafiə etdiyini necə müəyyən edir və bunu necə sübut edir.
AI-a niyə öz təhlükəsizlik proqramı lazımdır?
Təhdidlər görünməmiş olduğu üçün yox — onların çoxu injection-un, imtiyaz artırmasının, data ifşasının və təchizat zənciri riskinin tanış variantlarıdır. Səbəb aktivlərin görünməz olmasıdır.
AI sistemini yaratmaq asan, görmək çətindir. Komanda mövcud SaaS alətinin içindəki AI funksiyasını aktivləşdirir və təşkilatda artıq heç bir arxitektura baxışının təsdiqləmədiyi, xarici model təchizatçısına gedən data axını yaranır. Developer daxili sənəd anbarı üzərində assistent qurur və həmin anbarın giriş nəzarətlərinin ətrafından keçən retrieval yolu yaranır. Heç biri tətbiqlər və serverlər üçün nəzərdə tutulmuş aktiv reyestrində görünmür.
Buradan proqramı müəyyən edən üç nəticə çıxır:
Sahib olmadığınız inventarı qoruya bilməzsiniz. Əvvəlcə kəşf gəlir.
Risk eyni deyil. HR siyasəti suallarına cavab verən çatbot və ödəniş sisteminə yazma girişi olan agent tamamilə fərqli nəzarətlər tələb edir; vahid nəzarətlər tətbiq etmək isə ya birincini həddən artıq, ya ikincini yetərincə idarə etməmək deməkdir.
Uğursuzluq forması səssizdir. AI sistemləri sınmır, pisləşir; kompromis olunmuş və ya manipulyasiya edilmiş sistem inandırıcı nəticə verməyə davam edir. Aşkarlama güman edilməli yox, dizayn olunmalıdır.
AI sistem inventarında nə olmalıdır?
Sistem başına yeddi atribut — və inventar proqramın birinci nəticəsidir.
Nə edir, bir cümlə ilə, və sahibi kimdir.
Hansı dataya çata bilir — retrieval əhatəsi və alətlər, hər mənbənin təsnifatı ilə. Bu, ən çox qeyd olunmuş cavabı olmayan atributdur və onun müəyyən edilməsi təhlükəsizlik proqramının data governance proqramı ilə görüşdüyü yerdir.
Kimin kimliyi altında hərəkət edir. İstifadəçi üzrə kimlik, xidmət hesabı, yoxsa qrafikli subyekt.
Hansı əməliyyatları edə bilir. Yalnız oxuma, geri qaytarıla bilən yazmalar, ya da geri qaytarılmayan və kənara görünən əməliyyatlar.
İnferens harada işləyir və jurnallar hara gedir. İki ayrı sual, tez-tez iki fərqli cavabla, və hər ikisi rezidentlik üçün əhəmiyyət daşıyır — Azərbaycanda data rezidentliyi və şəxsi məlumat qanunu məqaləsində açılıb.
Hansı model və versiya, daxildə, yoxsa xaricdə hostlandığı da daxil olmaqla.
Audit izində nə var və nə qədər saxlanılır.
Kəşf səsləndiyindən çətindir, çünki AI funksiyaları təşkilatın onsuz da sahib olduğu məhsulların içində gəlir. İşləyən praktiki üsullar: məlum model təchizatçılarına gedən trafik üçün şəbəkə çıxışının təhlili, SaaS yeniləmələrinin satınalma baxışı ilə yeni aktivləşmiş AI funksiyalarının aşkarlanması və sadəcə hər departamentdən nəyi işə saldıqlarını soruşmaq. Sonuncu ilk ikisindən çox tapır.
Sistemlər necə risk üzrə təsnifləndirilməlidir?
İki ölçü, birlikdə nəzarət səviyyəsini verir.
Data həssaslığı — sistem nəyə çata bilir. Açıq məlumat, daxili məlumat, şəxsi məlumat, ya da məhdudlaşdırılmış və tənzimlənən data.
Əməliyyat imkanı — nə edə bilir. Yalnız oxuma, geri qaytarıla bilən yazmalar, geri qaytarılmayan və ya kənara görünən əməliyyatlar.
Açıq məzmun üzərində yalnız oxuyan sistemə yüngül nəzarətlər lazımdır. Tənzimlənən data üzərində geri qaytarılmayan əməliyyat imkanı olan sistemə isə tam dəst, üstəgəl hər nəticəli əməliyyatda insan təsdiqi lazımdır. Sistemlərin çoxu aralıqdadır və hansı nəzarətlərin tətbiq olunacağını hər layihənin mühakiməsi yox, təsnifat müəyyən edir.
Bu təsnifat həm də idarəetmə sistemi standartlarının gözlədiyi risk qiymətləndirməsinin girişidir və ISO/IEC 42001 standartındakı təsir qiymətləndirməsi gözləntilərinə səliqəylə oturur.
Hansı nəzarət ailələri tətbiq olunur?
Yeddi — təsnifata mütənasib tətbiq olunmaqla.
1. Kimlik və giriş. İstifadəçi kimliyi hər retrieval-a və hər alət çağırışına ötürülür, aşağıdakı sistemlər isə öz avtorizasiyasını tətbiq edir. Sistem bunun əvəzinə xidmət hesabı saxlayırsa, uğurlu manipulyasiya onu miras alır. Bu, bünövrə nəzarətidir və prototip kimi qurulmuş sistemlərdə ən çox əskik olan nəzarətdir.
2. Giriş və məzmun nəzarətləri. Modelə gələn hər giriş etibarsızdır — həm istifadəçidən, həm çəkilmiş məzmundan. Prompt injection LLM tətbiqləri üçün OWASP Top 10 siyahısının başındadır və təlimatla aradan qaldırıla bilməz. Nəzarət uğurlu injection-un nə edə biləcəyini məhdudlaşdırmaqdır — təhlükəsiz AI iş axınları qurmaq məqaləsində açılıb.
3. Nəticə nəzarətləri. Model nəticəsi onu istehlak edən üçün etibarsız girişdir. Tipləri və diapazonları doğrulayın, heç vaxt sorğuya və ya əmrə yerləşdirməyin, buraxılmazdan əvvəl kimlik məlumatına bənzər sətirləri və həssas datanı skan edin.
4. Əməliyyat nəzarətləri. Geri qaytarıla bilənlik təsnifatı, geri qaytarılmayan əməliyyatlarda təsdiq qapıları, icra vaxtı real parametrlər üzərində qiymətləndirilən siyasət və siyasət xidməti əlçatmaz olanda bağlı vəziyyətdə sınma.
5. Təcrid. Kod icra edən hər şey üçün sandbox, sandbox-dan şəbəkəyə çıxışın olmaması, tətbiq kodunda yox, data qatında tətbiq olunan kirayəçi təcridi və yüksək imtiyazlı alətlərin etibarsız məzmun qəbul edən kontekstlərdən ayrılması.
6. Monitorinq və aşkarlama. Anomal alət çağırışı ardıcıllıqları, qeyri-adi retrieval şablonları, heç kimin istəmədiyi əməliyyatlara istinad edən nəticələr və retrieval keyfiyyətinin sürüşməsi. AI sistemləri səssiz sındığı üçün aşkarlama əməliyyat xoşluğu yox, dizayn tələbidir.
7. Təchizat zənciri. Modelin mənşəyi və tamlığının yoxlanması, alət və konnektor paketlərinin nəzərdən keçirilməsi və yoldakı hər hansı hostlanan xidmət üzrə zəmanət. Air-gapped mühitə gələn model çəkiləri və konteyner obrazları əvvəlcədən razılaşdırılmış tamlıq yoxlaması olan nəzarətli yol tələb edir.
Üçüncü tərəf model riski necə işləyir?
Təhlükəsizlik funksiyasına verilən və ən çox dəqiq cavablandırıla bilməyən sual.
Emal harada və hansı şərtlərlə baş verir. Hostlanan model təchizatçısı prompt-da nə varsa onu emal edir. Saxlayıb-saxlamaması, təlimdə işlədib-işlətməməsi, infrastrukturunun harada olması və subemalçılarının nə etməsi konkret tənzimləyici nəticələri olan müqavilə suallarıdır. Azərbaycandan çıxan şəxsi məlumat üçün cavablardan asılı olmayaraq ötürmə qaydaları tətbiq olunur.
Model dəstəkdən çıxarılanda nə olur. Hostlanan modellər təchizatçının qrafiki ilə geri götürülür və əvəzlənir. Davranışı bir versiyaya qarşı doğrulanmış sistem yenidən doğrulama ilə öz qrafiki ilə yox, təchizatçının qrafiki ilə üzləşir — bu, yalnız keyfiyyət yox, əlçatanlıq və change control riskidir.
Zəmanət mövqeyi nədir. Təchizatçı audit hesabatları verirmi və onlar sizin sübut etməli olduğunuzu əhatə edirmi.
Buradakı nəzarət altındakı qurumlar üçün bu suallar tez-tez inferensin perimetr daxilində işlədilməsi ilə həll olunur — üstünlük kimi yox, alternativi ötürmə qaydaları və autsorsinq nəzarəti altında əsaslandırmaq çətin olduğu üçün; Mərkəzi Bankın İT və data tələbləri və suveren AI məqalələrində açılıb. Bu qərar riski üçüncü tərəf zəmanətindən daxili əməliyyatlara köçürür — yəni aradan qaldırmır, dəyişir.
AI insidentlərinə cavab necə görünür?
Mövcud insident prosesləri sistemin ya işlədiyini, ya sındığını güman edir. AI sistemləri isə normal işləyərkən səhv nəticə verir və bu güman pozulur.
Əvvəlcədən müəyyən edilməyə dəyən dörd insident sinfi, hər birinin cavabı fərqlidir:
Manipulyasiya. Sistem nəzərdə tutulmuş davranışından kənara çıxmağa sövq edilib. Cavab: təsirlənən aləti və ya imkanı söndürməklə saxlamaq, nəyin icra olunduğunu audit izində araşdırmaq, injection vektorunu qiymətləndirmək.
İfşa. Sistem məlumatı ona haqqı olmayan adama göstərib. Cavab: əhatəni retrieval jurnallarından müəyyən etmək, bunun bildirilməli şəxsi məlumat pozuntusu olub-olmadığını qiymətləndirmək və prompt-u yox, səlahiyyət yolunu düzəltmək.
Sistematik xəta. Sistem müəyyən müddət ərzində səhv nəticə verib — adətən köhnəlmiş məzmun, mənbə dəyişikliyi və ya retrieval pisləşməsi ucbatından. Cavab: müddəti müəyyən etmək, həmin nəticə əsasında verilmiş qərarları tapmaq və aşağı axında düzəltmək.
Pisləşmə. Konkret sınma olmadan keyfiyyət düşüb. Cavab: sabit sual dəstinə qarşı retrieval qiymətləndirməsi, korpus aktuallığının yoxlanması, mənbə dəyişikliklərinə baxış.
Bunların hər hansı birini mümkün edən üç tələb var: baş verəni bərpa etməyə kifayət edən tam audit izi, növbətçinin deployment olmadan işlədə biləcəyi sistem üzrə kill switch və iş saatlarından kənarda əlçatan adlı sahib. Audit izi tələbi AI orchestration arxitekturası məqaləsindəki tələblə eynidir və izin jurnal funksiyası yox, arxitektura xüsusiyyəti olmasının səbəbi də budur.
Bildiriş öhdəlikləri də əvvəlcədən xəritələnməlidir. İfşa insidenti bildiriş müddəti olan şəxsi məlumat pozuntusu ola bilər, nəzarət altındakı qurum üçün isə sahə hesabatlığı öhdəliyi də daşıya bilər. Bunu insident zamanı aydınlaşdırmaq gecdir.
Bu, mövcud çərçivələrə necə oturur?
Şüurlu şəkildə — və xəritə proqramın işi ikiqat etməməsini təmin edir.
Yeddi nəzarət ailəsinin çoxu yeni aktiv sinfinə tətbiq olunan mövcud ISO 27001 nəzarət ailələridir — giriş nəzarəti, təhlükəsiz işləmə, təchizatçı münasibətləri, jurnal və monitorinq, insidentlərin idarəsi. Real ISMS işlədən qurumda mexanizm onsuz da var.
AI-ın əlavə etdiyi əsasən idarəetmə sistemi qatındadır: AI sistemlərinin inventarı, təsir qiymətləndirmələri, modelin həyat dövrü və change control, həmçinin sistemlərin necə davrandığına dair sübut. ISO/IEC 42001 məhz bunu rəsmiləşdirir və onun doqquz məqsəd altındakı 38 Annex A nəzarəti 27001-i əvəz etmək əvəzinə onunla əhəmiyyətli dərəcədə üst-üstə düşür.
Konkret risk idarəçiliyi praktikası üçün NIST AI Risk Management Framework funksional quruluş verir — govern, map, measure, manage — ikisinin müqayisəsi isə NIST AI RMF və ISO 42001 müqayisəsi məqaləsindədir.
Praktiki göstəriş: təhlükəsizlik proqramının yanında AI təhlükəsizlik proqramı qurmaq əvəzinə mövcud nəzarət dəstini genişləndirin və xəritələyin.
Əsas məqamlar
- Fərqləndirici problem görünməzlikdir. AI sistemlərini yaratmaq asan, görmək çətindir — ona görə əvvəlcə kəşf və inventar gəlir.
- Sistem başına yeddi atribut qeyd edin, o cümlədən hansı dataya çata bildiyini və kimin kimliyi altında hərəkət etdiyini.
- Data həssaslığı və əməliyyat imkanı üzrə təsnifləndirin. Nəzarət səviyyəsini hər layihənin mühakiməsi yox, təsnifat müəyyən edir.
- Yeddi nəzarət ailəsi: kimlik və giriş, giriş nəzarətləri, nəticə nəzarətləri, əməliyyat nəzarətləri, təcrid, monitorinq, təchizat zənciri.
- Kimliyin ötürülməsi bünövrədir. Geniş girişli xidmət hesabı istənilən manipulyasiyanı imtiyaz artırmasına çevirir.
- Üçüncü tərəf model riski emalın harada baş verməsindən, dəstəkdən çıxarılma qrafiklərindən və zəmanətin əhatəsindən asılıdır — və tez-tez perimetr daxilində inferenslə həll olunur.
- Dörd AI insident sinfini əvvəlcədən müəyyən edin və tam audit izi, sistem üzrə kill switch və əlçatan sahib təmin edin.
- ISO 27001 mexanizmini təkrarlamaq yox, genişləndirin; ISO/IEC 42001 idarəetmə sistemi qatını, NIST AI RMF isə risk quruluşunu əlavə edir.
Yukon Labs AI siyasəti və governance üzrə məsləhət verir və HAVAA-nı bu nəzarətlər platforma imkanları kimi konfiqurasiya olunmuş halda on-premise quraşdırır. Hazırlıq qiymətləndirməsi adətən kəşf addımı ilə başlayır, çünki təşkilatların çoxu hələ neçə AI sistemi olduğunu bilmir.