Real korporativ AI yol xəritəsi təxminən iki il ərzində beş mərhələdən keçir: hazırlıq, bir tətbiq, daha iki-üç tətbiq, platformanın konsolidasiyası və miqyas. Mərhələlərin özündən vacib onların arasındakı qapılardır — hər mərhələyə yalnız əvvəlki mərhələ konkret sübut istehsal edəndə keçmək lazımdır və uğursuz proqramların çoxu mərhələni yox, qapını atlayıb.

Ən çox rast gəlinən səhv 0-cı mərhələni keçmədən 1-ci mərhələdən başlamaqdır.

İlk tətbiqdən əvvəl nə doğru olmalıdır? (Mərhələ 0)

Dörd ilkin şərt. Onlarsız başlayan proqram ilk tətbiqini bunları kəşf etməyə sərf edir, bu isə bahadır.

Sübuta əsaslanan ssenari seçimi. Seminardan yox, tapşırıq həcmlərindən və proses datasından seçilmiş, sahələr üzrə AI agent ssenariləri məqaləsindəki meyarlara qarşı yoxlanmış: tapıla bilən həqiqi cavab, kifayət qədər həcm, nəticənin adlı sahibi, geri qaytarıla bilən səhvlər və onsuz da mövcud olan ölçülə bilən rəqəm.

Götürülmüş baza. Dövr müddəti, insan toxunma vaxtı, istisna nisbəti — hər şey qurulmazdan əvvəl ölçülmüş. Bu, sonradan bərpa oluna bilmir və onsuz proqram birinci qapıda dəyər göstərə bilmir.

Dataya çatmağın təsdiqi. Sistem lazımi dataya çata bilirmi, kimin kimliyi altında, hansı təsnifatla. Cavab bilinmirsə və ya data idarə olunmursa, əvvəlcə həmin iş gəlir — və bu, fərqli planı və fərqli qrafiki olan data governance layihəsidir.

Qərara alınmış deployment mövqeyi. İnferensin harada işlədiyi və jurnalların hara getdiyi. Azərbaycandakı nəzarət altındakı qurumlar üçün bunu adətən üstünlük yox, rezidentlik qaydaları həll edir; data rezidentliyi və şəxsi məlumat qanunu məqaləsində açılıb. Əvvəldən qərara almaq miqyaslama anında arxitekturanı yenidən qurmaqdan xilas edir.

0-cı mərhələ dörd-altı həftə çəkir və ən çox atlanan mərhələdir. Strukturlaşdırılmış hazırlıq qiymətləndirməsi məhz onu sıxlaşdırmaq üçün var.

1-ci mərhələyə qapı: adlı ssenari, yazılı baza, istifadəçi üzrə səlahiyyətlərlə təsdiqlənmiş data yolu və razılaşdırılmış deployment mövqeyi.

Mərhələ 1 — ilk tətbiq (1-ci rüb)

Bir ssenari, yalnız oxuyan, tez yox, düzgün quraşdırılmış.

1-ci mərhələnin məqsədi ssenari deyil. Məqsəd hər sonrakı tətbiqin miras alacağı bünövrəni qurmaqdır: kimliyin ötürülməsi, retrieval pipeline-ı, qiymətləndirmə dəsti, audit izi və təsdiq mexanizmi. Bunları bir dəfə, düzgün, aşağı riskli tətbiqdə qurmaq sonradan üç tətbiq boyu geydirməkdən qat-qat ucuzdur.

Mərhələnin içindəki ardıcıllıq kölgə rejimi, sonra köməkçi rejim, sonra nəzarətli rejimdir — AI agentləri biznes proseslərini necə avtomatlaşdırır məqaləsində təsvir olunub. Kölgə rejimi könüllü deyil; istifadəçilər cəlb olunmazdan əvvəl mövcud yeganə dürüst dəqiqlik ölçüsüdür.

1-ci mərhələnin işlək sistemdən başqa verməli olduqları: yüz real sualdan ibarət qiymətləndirmə dəsti, sənədləşdirilmiş uğursuzluq forması paylanması, bazaya qarşı ilk ölçmə və adlı sahibi olan iş ritmi.

2-ci mərhələyə qapı: ölçülmüş nəticə bazadan yaxşıdır, qiymətləndirmə dəsti mövcuddur və yenidən işlədilir, audit izinə isə onu müdafiə edəcək adam baxıb.

Mərhələ 2 — daha iki-üç ssenari (2–3-cü rüblər)

İndi genişlik — birinci uğuru təkrarlamaq üçün yox, fərqli formaları yoxlamaq üçün şüurlu seçilmiş.

Faydalı seçim: biri birinciyə qonşu (eyni data, fərqli tapşırıq), biri başqa departamentdə (fərqli data, oxşar tapşırıq), biri isə yazma əməliyyatı tələb edən — beləliklə təsdiq mexanizmi istehsalatda sınaqdan keçir.

Yazma əməliyyatlı tətbiq vacib olanıdır, çünki siyasət qapıları, geri qaytarıla bilənlik təsnifatı və təsdiq iş axını məhz orada dizayn sənədi olmaqdan çıxır. O, dar planlaşdırılmalıdır — tək əməliyyat növü, aşağı hədd, aydın təsdiqləyən.

Bu mərhələdə adətən üzə çıxanlar: retrieval pipeline-ı yeni korpusa gözləniləndən pis ümumiləşir, ikinci departamentin datası birincidən az idarə olunmuş çıxır və təsdiq interfeysi real təsdiqləyənlərdən sonra yenidən dizayn tələb edir.

3-cü mərhələyə qapı: sahibləri olan iki-üç istehsalat tətbiqi, təsdiq altında insidentsiz işləyən yazma əməliyyatı və layihələr arasında hansı platforma komponentlərinin kopyalandığına dair aydın mənzərə.

Mərhələ 3 — platformanın konsolidasiyası (3–4-cü rüblər)

Proqramın miqyaslanıb-parçalanmayacağını həll edən mərhələ — və görünən heç nə sınmadığı üçün proqramların çoxunun atladığı mərhələ.

Bu vaxta eyni komponentlər artıq iki-üç dəfə qurulub: təhlükəsizlik nəzarətləri, təsdiq axınları, audit jurnalı, retrieval pipeline-ları, qiymətləndirmə vasitələri. Onlar bir-birindən ayrılıb. Onları layihələrin miras aldığı platforma qatına yığmaq qurumda ayrılıqda ağlabatan, birlikdə isə idarə olunmaz riskli sistemlər dəstinin toplanmasının qarşısını alır — HAVAA korporativ AI transformasiyasını necə mümkün edir məqaləsində təsvir olunan şablon budur.

Üç konsolidasiya hədəfi:

Platforma imkanı kimi təhlükəsizlik və siyasət. Bir təsdiq mexanizmi, bir geri qaytarıla bilənlik təsnifatı, bir siyasət mühərriki, bir dəst sürət limiti və kill switch.

Bir audit izi. Tətbiqlər boyu vahid, ixrac edilə bilən, bütöv nəzərdən keçirilən. Üç ayrı audit tətbiqi üç ayrı sübut problemidir.

Bir retrieval və qiymətləndirmə dəsti. Beləliklə retrieval-dakı yaxşılaşma bir tətbiqə yox, hamısına fayda verir.

Bu mərhələ həm də adətən 0-cı mərhələnin təxirə saldığı data governance sualını qaldırır: tətbiqlər çoxaldıqca retrieval əhatəsindəki aktivlərin sayı artır və təsnifat catalog olmadan idarə olunmaz olur. Bunun 3-cü, yoxsa 4-cü mərhələdə baş verməsi dəyişir; baş verməsi isə yox.

4-cü mərhələyə qapı: yeni tətbiqlər təhlükəsizliyi, auditi və retrieval-ı yenidən qurmaq əvəzinə miras alır və yeni ssenarinin tətbiq müddəti ölçülə bilən şəkildə azalıb.

Mərhələ 4 — miqyas (2-ci il)

Miqyas tətbiqdən fərqli fəaliyyətdir və üç komponenti var.

Ötürmə qabiliyyəti. Rübdə daha çox ssenari — ilkin komandadan başqa komandalar tərəfindən. Bunun üçün 3-cü mərhələdəki platforma və yeni komandanın ilkin mühəndislərə ehtiyac duymayacağı qədər yaxşı sənədləşmə lazımdır.

Avtonomluq. İmkan sübutlar yığıldıqca daha geniş verilir — yeni tətbiqləri tam avtonom işə salmaq yox, mövcud tətbiqləri pilləli rejimlər üzrə yuxarı qaldırmaq. Hər addımın sübutu əvvəlki addımın qəbul nisbəti və insident tarixçəsidir.

Tutum. On-premise-də GPU tutumunun planlaşdırılması məhz burada nəzəri yox, real məhdudiyyətə çevrilir. Model marşrutlaşdırması — ucuz tapşırıqlara ucuz modellər — optimallaşdırmadan tələbə keçir; ölçülmə mühakiməsi LLM-lərin on-premise tətbiqi məqaləsindədir.

Bu mərhələdəki uğursuzluq forması əvvəlkilərdən fərqlidir: tətbiqin sınması yox, portfelin idarəsiz qalması. İnventarı, sahib siyahısı və ləğv prosesi olmayan iyirmi agent uğur kimi görünən governance problemidir.

Hər mərhələ kadr baxımından nəyə başa gəlir?

Orta ölçülü qurum üçün təxmini — və vendor təkliflərinin göstərdiyindən şüurlu şəkildə kiçik.

Mərhələ 0: natamam iş rejimində bir analitik və bir mühəndis, dörd-altı həftə, üstəgəl prosesin sahibinin diqqəti.

Mərhələ 1: iki mühəndis, həftədə təxminən bir gün prosesin sahibi və qiymətləndirmə dəsti üçün domen mütəxəssisi — onun bir həftəlik vaxtı, əvvəldə cəmlənmiş.

Mərhələ 2: həmin iki mühəndis üstəgəl bir nəfər; hər tətbiqin öz proses sahibi olmaqla.

Mərhələ 3: platforma işi bir rüb üçün iki mühəndisdir və eyni adamlar uğrunda yeni tətbiqlərlə rəqabət aparır — ona görə bu, aralarda sıxışdırılan iş yox, qərar olmalıdır.

Mərhələ 4: iki-üç nəfərlik platforma komandası, üstəgəl ssenari başına icra tutumu, üstəgəl portfelin sahibi olan bir nəfər: inventar, sahiblik, ləğv.

Ən çox əskik olan rol sonuncudur və onun olmaması uğurlu ikinci il proqramını idarə olunmayan mühitə çevirir.

Yol xəritəsini nə sındırır?

Beş şey, təxmini tezlik sırası ilə.

0-cı mərhələni atlamaq. İlk tətbiq datanın idarə olunmadığını kəşf edir və heç vaxt planlaşdırılmamış governance layihəsinə bir rüb gedir. Ən çox rast gəlinən tək səbəb budur və Azərbaycanda korporativ AI mövzusunun niyə bu qədər tez-tez data hazırlığı sualına yığılmasının səbəbi də elə odur.

Bazanın olmaması. Proqram birinci qapıda dəyər göstərə bilmir və maliyyələşmə məhz bünövrənin ödənildiyi, gəlirin isə hələ gəlmədiyi anda sual altına düşür.

3-cü mərhələni atlamaq. Tətbiqlər bir-birindən ayrılan nəzarətlərlə yığılır, sonda isə proqramı layihə yox, uyğunluq baxışı dayandırır.

Qapılara mərhələ nişanı kimi baxmaq. Sübut olduğu üçün yox, tarix gəldiyi üçün keçilən qapı qapı deyil. Hər birinin konkret sübutu yuxarıda sadalanıb.

Sahibi itirmək. Sponsoru 2-ci mərhələdə dəyişən proqram adətən başqa ssenari ilə 1-ci mərhələdən yenidən başlayır. Sponsor dəyişikliyindən sağ çıxan şey sənədləşdirilmiş bazalar və qiymətləndirmə dəstləridir; həvəs yox.

Əsas məqamlar

  • Təxminən iki il ərzində beş mərhələ: hazırlıq, bir tətbiq, daha iki-üç tətbiq, platformanın konsolidasiyası, miqyas.
  • Qapılar mərhələlərdən vacibdir. Hər birinin konkret sübutu var və tarixə görə keçmək ən çox rast gəlinən uğursuzluqdur.
  • 0-cı mərhələ sübuta əsaslanan ssenari seçimi, götürülmüş baza, istifadəçi üzrə səlahiyyətlərlə təsdiqlənmiş data yolu və qərara alınmış deployment mövqeyi tələb edir.
  • 1-ci mərhələnin əsl məhsulu ssenari yox, bünövrədir — kimlik, retrieval, qiymətləndirmə dəsti, audit izi, təsdiqlər.
  • 2-ci mərhələyə təsdiq altında bir yazma əməliyyatı daxil olmalıdır ki, siyasət mexanizmi istehsalatda sınaqdan keçsin.
  • 3-cü mərhələdəki konsolidasiya ən çox atlanan və proqramın miqyaslanıb-parçalanmayacağını həll edən mərhələdir.
  • 4-cü mərhələ portfel idarəçiliyi gətirir: inventar, sahiblik, ləğv. Ən çox əskik olan rol portfelin sahibidir.
  • Kadr ehtiyacı vendor təkliflərinin göstərdiyindən kiçikdir, amma prosesin sahibinin həftəlik vaxtı könüllü deyil.

Yukon Labs 0-cı mərhələni strukturlaşdırılmış hazırlıq qiymətləndirməsi kimi aparır və 1-ci mərhələdən etibarən HAVAA-nı on-premise quraşdıraraq OvalEdge və Starburst vasitəsilə idarə olunan data üzərində əsaslandırır. Bu ardıcıllığı ən çox pozan səhvlər üçün korporativ AI tətbiqində ən çox edilən səhvlər məqaləsinə baxın.