Lokal süni intellekt və məlumat təhlükəsizliyi: şirkət datası harada saxlanmalıdır?

LLM layihəsində data yalnız istifadəçinin yazdığı sorğu deyil. Sistem prompta əlavə olunan sənədləri, RAG axtarış nəticəsini, modelin cavabını, loqları, analitika qeydlərini, ehtiyat nüsxələri və vendor telemetriyasını da emal edə bilər. Hər element üçün “haradan gəlir, harada saxlanır, kim oxuya bilir, nə qədər qalır?” sualı cavablandırılmalıdır. Bu xəritə olmadan “məlumatımız lokal qalır” və ya “vendor saxlamır” kimi ümumi bəyanatlar real riskə cavab vermir. Təhlükəsizlik arxitekturası görünən məlumat axınından başlayır.

Sonra məlumat sinifləri yaradın: açıq, daxili, məxfi, şəxsi, maliyyə, sağlamlıq və ya digər hüquqi həssas kateqoriyalar. Hər sinif üçün modelə göndərmə, maskalama, saxlanma, loqlaşdırma və insan təsdiqi qaydası təyin olunur. Məsələn, açıq məhsul FAQ-su xarici modeldə aşağı riskli ola bilər, amma şəxsiyyət sənədi və müqavilə mətni daha sərt nəzarət tələb edə bilər. Eyni şirkətdə bir neçə yerləşdirmə modeli birlikdə işləyə bilər; vacib olan tək etiket deyil, siyasətin texniki şəkildə icra olunmasıdır.

Bulud xidmətləri sürətli başlanğıc, elastik miqyaslama və hazır əməliyyat imkanları verə bilər. Bunun qarşılığında müqavilə, region, data emalı şərti, vendor asılılığı, qiymət və çıxış strategiyası diqqətlə qiymətləndirilməlidir. Lokal, yəni on-premise yerləşdirmə təşkilata şəbəkə və data üzərində daha birbaşa nəzarət verə bilər, lakin GPU infrastrukturu, əməliyyat, monitorinq, patching, ehtiyat nüsxə və ixtisaslı komanda tələbi yaradır. Yerli model ailəsi bəzi lokal və ya xüsusi yerləşdirmə ssenariləri üçün alternativ yarada bilər, amma texniki və təşkilati məsuliyyət yenə qalır.

Hibrid modeldə həssas sənəd və ya daxili axtarış qorunan mühitdə, aşağı riskli ümumi tapşırıq isə başqa idarə olunan xidmətdə işləyə bilər. Bu qərar performans və xərcə də təsir edir: ən yaxın server həmişə ən ucuz, ən böyük model həmişə ən faydalı seçim deyil. Pilotda gecikmə, keyfiyyət, əməliyyat yükü, məlumat riski və ümumi sahiblik xərci birlikdə ölçülməlidir. Arxitektura seçimi vendor adı deyil, biznes və risk tələblərinin nəticəsi olmalıdır.

Giriş nəzarəti ən vacib qatlardandır. İstifadəçi yalnız səlahiyyəti olan sənədi RAG nəticəsində görə bilməlidir; bu yoxlama model çağırışından əvvəl tətbiq edilir. Məlumat ötürülərkən və saxlanarkən şifrələmə, açar idarəetməsi, şəbəkə segmentasiyası, rate limit və xidmət hesablarının minimal səlahiyyəti kimi tədbirlər lazımdır. Sorğu və cavab loqları debug üçün faydalı ola bilər, lakin onlar da həssas data daşıya bilər. Loq siyasəti minimum toplama, maskalama, məhdud giriş və saxlanma müddəti ilə hazırlanmalıdır.

Prompt injection və məlumat sızması üçün də nəzarət lazımdır. Modelin aldığı sənəddəki təlimatlar sistem qaydasını dəyişməməli, alət çağırışları sxem və icazə ilə məhdud olmalıdır. İstifadəçi “gizli qaydaları göstər” yazanda backend onu ayrı təhlükəsizlik siyasəti ilə qiymətləndirir; LLM-in nəzakətli mətni təhlükəsizlik qərarının əvəzi deyil. Penetrasiya testləri, red-team nümunələri və insident planı AI funksiyasını standart tətbiq təhlükəsizliyi prosesinə daxil edir.

Təhlükəsizlik yalnız mühəndis komandasının işi deyil. Hüquq, risk, məxfilik, IT, məhsul və biznes sahibi məlumatın məqsədini və qəbuledilən riski birlikdə müəyyən etməlidir. Vendor istifadə olunursa, data emalı əlavəsi, region, model təlimində istifadə siyasəti, saxlanma müddəti, subprocessor, insident bildirişi, silinmə və müqavilə bitəndə çıxış planı yoxlanmalıdır. Bu suallar yalnız satınalma zamanı deyil, xidmətin dəyişməsi və yeni funksiya əlavə olunanda da yenidən nəzərdən keçirilməlidir.

Yaxşı idarəetmə sənədi sadə və işlək olur: hansı ssenari icazəlidir, hansı data qadağandır, kim təsdiq verir, necə test edilir, problem yarananda kim cavabdehdir. Təlim və istifadəçi maarifləndirməsi də vacibdir; əməkdaşın chat pəncərəsinə hansı məlumatı yazmamalı olduğunu bilməsi texniki filtrlər qədər əhəmiyyətlidir. Bu mədəniyyət qurulduqda lokal AI yalnız infrastruktur qərarı deyil, şirkətin məlumatla məsuliyyətli işləmə qabiliyyətinin hissəsinə çevrilir.

“Lokal süni intellekt və məlumat təhlükəsizliyi: şirkət datası harada saxlanmalıdır?” mövzusunda növbəti addımı texnologiyadan deyil, konkret istifadəçi problemindən başlayaraq seçin. Hədəf auditoriyanı, cavabın təsir etdiyi qərarı, istifadə olunacaq məlumatı və qəbul edilən risk səviyyəsini bir səhifəlik sənəddə aydınlaşdırın. Sonra həmin ssenaridə bu gün nə qədər vaxt sərf olunduğunu, hansı səhvlərin baş verdiyini və istifadəçinin hansı çətinliklə üzləşdiyini ölçün. Bu ilkin göstərici olmadan AI həllinin həqiqi faydasını və ya yan təsirini qiymətləndirmək mümkün deyil.

Kiçik pilotda nəticəni Azərbaycan dili, fakt və ya mənbə dəqiqliyi, istifadəçi təcrübəsi, gecikmə və təhlükəsizlik baxımından birgə yoxlayın. Yalnız ideal sorğunu deyil, qısa, səhv yazılmış, qeyri-müəyyən və riskli müraciətləri də sınayın. Cavabın modeldən, məlumatdan, axtarışdan və ya proses qaydasından hansı səbəblə yarandığını izləmək üçün versiyaları qeyd edin. Bu yanaşma problemi tez tapmağa, məhsulu təhlükəsiz təkmilləşdirməyə və komandanın qərarını fikrə yox, dəlilə əsaslandırmağa kömək edir.

Ən sonda insanın rolunu açıq saxlayın. Aşağı riskli işdə AI qaralama və axtarış köməkçisi ola bilər, yüksək təsirli qərarda isə səlahiyyətli ekspertin yoxlaması, rəsmi mənbə və eskalasiya yolu qorunmalıdır. Modelin və ya məlumat bazasının imkanları dəyişdikcə eyni qiymətləndirmə dövrünü yenidən işə salın. Qərar jurnalında istifadə olunan məlumat versiyasını, model konfiqurasiyasını, cavabın harada istifadə edildiyini və kimin təsdiqlədiyini qeyd edin. Bu məlumat sonradan keyfiyyət araşdırması, audit və komanda təlimi üçün praktik sübuta çevrilir. Beləliklə, bu mövzudakı AI təşəbbüsü bir dəfəlik demo deyil, istifadəçiyə real fayda verən və məsuliyyətlə idarə olunan məhsul imkanına çevrilir.