AI agent workflow automation biznes prosesində mətn yaratmaqdan daha geniş anlayışdır: agent daxil olan müraciəti anlayır, yalnız səlahiyyətli məlumat mənbələrindən kontekst toplayır, konkret və dar çərçivəli alətlər seçir, təklif olunan əməliyyatı hazırlayır və müəyyən risk səviyyəsində həmin əməliyyatı insan təsdiqinə təqdim edir. Məqsəd insanları nəzarətsiz avtomatlaşdırma ilə əvəz etmək deyil; təkrarlanan koordinasiya işini sürətləndirərkən məsuliyyət, icazə və izlənəbilənliyi qorumaqdır.

Praktik sistem “agentə CRM-ə giriş verin və işi həll etsin” yanaşması ilə başlamamalıdır. Əvvəl prosesin sərhədləri, istifadə edə biləcəyi alətlər, yazma hüquqları, təsdiq qaydaları və uğursuzluq halında geri dönüş yolu müəyyən edilməlidir. POLADO-nun süni intellekt və avtomatlaşdırma xidmətləri bu cür idarə olunan agent axınlarını mövcud sistemlərə uyğun şəkildə layihələndirməyə yönəlir.

Çatbotdan idarə olunan iş axınına keçid

Çatbot əsasən suala cavab verir. İş axını agenti isə cavabdan sonra prosesdə müəyyən addımlar ata bilər. Məsələn, təchizatçıdan gələn sorğunu qəbul edən agent:

  1. məktubun təchizatçı sorğusu, status sualı və ya müqavilə dəyişikliyi olduğunu təsnifləndirir;
  2. təchizatçı kodunu, aid olduğu alış sifarişini və təsdiqlənmiş müqavilə sənədlərini axtarır;
  3. çatışmayan sahələri və ya ziddiyyətli məlumatı aşkar edir;
  4. cavab layihəsi, daxili tapşırıq və ya yenilənmiş sorğu hazırlayır;
  5. yalnız icazə verilmiş hallarda həmin layihəni iş sisteminə göndərir və ya məsul şəxsə təsdiq üçün təqdim edir.

Burada dil modeli qərarın yeganə mənbəyi deyil. Model niyyəti izah etmək, sənədləri ümumiləşdirmək və strukturlaşdırılmış plan yaratmaq üçün istifadə olunur. Qaydalar sistemi isə hansı alətin çağırıla biləcəyini, hansı məlumatın göstərilə biləcəyini və əməliyyatın təsdiqsiz icra olunub-olunmayacağını müəyyən edir.

Etibarlı agent axınının altı mərhələsi

1. Sorğunu qəbul edin və strukturlaşdırın

E-poçt, forma, daxili portal müraciəti və ya çat mesajı əvvəlcə standart sxemə çevrilməlidir: müraciətin növü, göndərən, əlaqəli obyekt, tələb olunan nəticə, həssaslıq səviyyəsi və çatışmayan məlumatlar. Modelin sərbəst mətn nəticəsi birbaşa əməliyyat komandası olmamalıdır. Sonrakı xidmətlərin yoxlaya biləcəyi JSON kimi strukturlaşdırılmış məlumat olmalıdır.

2. Konteksti mənbə və istifadəçi hüquqları ilə birlikdə tapın

Agentə “şirkətin bütün sənədlərini axtar” səlahiyyəti vermək əvəzinə, sorğuya və istifadəçi roluna uyğun məhdud kolleksiyalar təyin edin. Məsələn, əməliyyat koordinatoru açıq satınalma qeydlərini və təsdiqlənmiş təchizatçı təlimatlarını görə bilər, lakin məxfi HR qovluqlarını yox. Gətirilən hər sənəd parçası mənbə identifikatoru, versiya və giriş qərarı ilə birlikdə saxlanmalıdır. Bu, cavabın dayandığı sənədi sonradan yoxlamağa imkan verir.

3. Alətləri məqsədə görə ayırın

Alət siyahısını “oxu”, “hazırla” və “dəyiş” kateqoriyalarına bölmək faydalıdır. Oxu alətləri sifariş statusunu və ya xidmət qaydasını qaytara bilər. Hazırlama alətləri cavab layihəsi, tapşırıq qaralaması və ya strukturlaşdırılmış forma yarada bilər. Dəyişiklik alətləri isə CRM qeydi yaratmaq, status yeniləmək və ya rəsmi sorğunu göndərmək kimi xarici vəziyyəti dəyişir. Agent yalnız konkret istifadə ssenarisi üçün lazım olan alətləri görməlidir; istifadə edilməyən və ya geniş səlahiyyətli inteqrasiyalar deaktiv qalmalıdır.

4. Əməliyyatdan əvvəl siyasəti tətbiq edin

Model “e-poçtu göndər” deyə bilər, lakin siyasət mühərriki ayrıca sual verir: bu istifadəçinin bu təchizatçı ilə yazışmağa hüququ varmı, mətn yalnız təsdiqlənmiş mənbələrə əsaslanırmı, alıcı domeni etibarlıdırmı, prosesdə insan təsdiqi tələb olunurmu? Beləliklə, model təklif verir, deterministik yoxlamalar isə icazə qərarı qəbul edir.

5. Lazım olduqda insan təsdiqi alın

Human in the loop automation hər addımda əl ilə işləmək demək deyil. İnsan diqqətini nəticənin səhv olması daha böyük zərər yarada biləcək nöqtələrə yönəltmək deməkdir. Təsdiq ekranında məsul şəxs müraciətin xülasəsini, istifadə edilən mənbələri, planlaşdırılan aləti, dəyişəcək sahələri və agentin əsaslandırmasını görməlidir. Təsdiq “bəli/xeyr” düyməsindən ibarət olmamalıdır: redaktə, rədd etmə, əlavə məlumat istəmə və səlahiyyətli şəxsə yönləndirmə seçimləri olmalıdır.

6. Nəticəni yazın, yoxlayın və bağlayın

İcra olunduqdan sonra agent yalnız “uğurlu” statusu yazmamalıdır. Xarici sistemdən cavabı təsdiqləməli, yaranmış obyektin identifikatorunu saxlamalı və istifadəçiyə aydın nəticə qaytarmalıdır. Şəbəkə xətası və ya vaxt limiti baş verərsə, təkrar cəhd eyni əməliyyatı iki dəfə yaratmamalıdır. Bu səbəbdən yazma əməliyyatları idempotent açar, vəziyyət izləmə və istisna növbəsi ilə hazırlanmalıdır.

Praktik nəzarət modeli

Agentin risk səviyyəsi sadəcə modelin “əminlik” göstəricisi ilə ölçülməməlidir. Modelin öz qiymətləndirməsi faydalı siqnal ola bilər, lakin təkbaşına təhlükəsizlik nəzarəti deyil. Daha sağlam qərar aşağıdakı amilləri birləşdirir:

  • Əməliyyatın təsiri: daxili qaralama yaratmaqla üçüncü tərəfə rəsmi mesaj göndərmək eyni deyil.
  • Geri dönmə imkanı: qeyd yaratmaq silinmədən asan geri alına bilər; göndərilmiş məlumat və ya dəyişdirilmiş icazə isə daha çətindir.
  • Məlumatın həssaslığı: açıq əməliyyat qeydi ilə məxfi müqavilə əlavəsi eyni qayda ilə işlənməməlidir.
  • Girişin əhatəsi: yalnız konkret sifarişi oxuyan alətlə geniş məlumat bazasında dəyişiklik edən alətin riski fərqlidir.
  • Sübutun keyfiyyəti: agentin seçdiyi mənbələr aktual, səlahiyyətli və bir-biri ilə uyğun olmalıdır.

Bunun əsasında sadə matris yaradıla bilər. Aşağı təsirli, geri qaytarılan və yüksək keyfiyyətli sübutlu addımlar avtomatik icra oluna bilər. Orta riskli addımlar hazırlanıb operatora təqdim edilir. Yüksək təsirli, geri qaytarılması çətin və ya qeyri-müəyyən kontekstli addımlar isə bloklanır və xüsusi eskalasiyaya yönləndirilir. Məsələn, daxili xidmət masasında düzgün komandaya tapşırıq açmaq avtomatik ola bilər; xidmət hesabının rolunu dəyişmək isə məcburi təsdiq tələb etməlidir.

Ən vacib prinsip: ən az səlahiyyət

Ən az səlahiyyət prinsipi agentin hər inteqrasiyada yalnız məqsəd üçün zəruri olan məlumat və əməliyyatlara çıxışını nəzərdə tutur. Ayrı agent və ya alət identifikatorlarından istifadə edin; ümumi administrator hesabını inteqrasiyaya bağlamayın. Oxu və yazma üçün ayrı tokenlər, qısaömürlü etimadnamələr, konkret resurs məhdudiyyətləri və mühitlər üzrə ayrılmış sirlər riskin təsir dairəsini azaldır.

Alət girişini istifadəçinin adı ilə deyil, tapşırıqla əlaqələndirmək də vacibdir. “CRM girişinə malik agent” çox geniş anlayışdır. “Yalnız açıq əməliyyat sorğusunda aidiyyəti təsdiqlənmiş əlaqə üçün qaralama status yeniləməsi yarada bilən agent” isə yoxlanıla bilən siyasətdir. Daxili idarəetmə portalı və ya xüsusi tətbiq lazım olduqda, veb platformaların hazırlanması xidməti bu səlahiyyət, təsdiq və görünürlük qatını məhsulun özünə daxil edə bilər.

Audit izi hansı suallara cavab verməlidir?

AI agent audit trail yalnız istifadəçi mesajlarının arxivi deyil. O, hadisələri ardıcıllıqla birləşdirən texniki sübut zənciridir. Hər iş axını üçün ən azı bunları saxlayın:

  • iş axını və run identifikatoru, başlanma vaxtı, tetikleyici və istifadəçi/rol konteksti;
  • agent və siyasət versiyası, model konfiqurasiyası və aktiv alət siyahısı;
  • mənbələrin identifikatorları, versiyaları, giriş filtrləri və alınma vaxtı;
  • strukturlaşdırılmış plan, siyasət yoxlamalarının nəticələri və risk təsnifatı;
  • təsdiq edən şəxs, qərar, şərh və təsdiq vaxtı;
  • çağırılan alət, parametr xülasəsi, xarici sistem cavabı və yaranan obyekt identifikatoru;
  • xəta, təkrar cəhd, geri qaytarma və son vəziyyət.

Həssas məlumatın tam mətnini hər jurnalda saxlamaq düzgün yanaşma deyil. Məxfilik ehtiyacına uyğun olaraq maskalama, sahə səviyyəli redaksiya, şifrələnmiş sübut anbarı və məhdud saxlanma müddəti tətbiq edin. Audit izi dəyişdirilə bilməyən jurnal və ya uyğun nəzarətli saxlama ilə qorunmalı, əməliyyat dəstəyi isə onu konkret müraciətə görə axtara bilməlidir. texniki dəstək və konsaltinq mərhələsində monitorinq, insident araşdırması və audit məlumatının məhsul dəstəyi prosesinə bağlanması planlaşdırıla bilər.

Qiymətləndirmə: demo yox, sınaq ssenariləri

Agentin keyfiyyətini yalnız bir neçə uğurlu demo ilə qiymətləndirmək kifayət deyil. Təsnifat, məlumat tapma, alət seçimi, siyasət tətbiqi və eskalasiya ayrı-ayrılıqda sınaqdan keçirilməlidir. Test dəstinə adi işlərdən əlavə aşağıdakı hallar daxil edilməlidir:

  • qeyri-müəyyən və ya ziddiyyətli müraciətlər;
  • müddəti bitmiş sənədə əsaslanan sorğular;
  • icazəsi olmayan istifadəçinin məlumat tələbi;
  • sənədin içində aləti qaydadan kənar çağırmağa çalışan təlimat;
  • artıq mövcud olan tapşırığın təkrar yaradılması;
  • inteqrasiya xətası, gecikmiş cavab və yarımçıq əməliyyat;
  • agentin təsdiq tələb etməli olduğu halda avtomatlaşdırmağa çalışdığı addım.

Ölçüləcək göstəricilər yalnız “düzgün cavab faizi” olmamalıdır. Yanlış alət çağırışlarının sayı, doğru eskalasiyalar, rədd edilmiş əməliyyatların səbəbi, insanın etdiyi düzəlişlər, prosesin tamamlanma müddəti və geri qaytarma tezliyi daha faydalı siqnallar verir. NIST-in AI RMF yanaşması da risklərin idarə olunmasında idarəetmə, kontekstin xəritələnməsi, ölçmə və idarəetmə funksiyalarını vurğulayır; insan nəzarəti prosesləri əvvəlcədən müəyyənləşdirilib sənədləşdirilməlidir.

Başlamaq üçün dar və faydalı ssenari seçin

İlk agent üçün yüksək həcmli, qaydaları aydın və nəticəsi nəzərdən keçirilə bilən proses seçin. Məsələn, daxili xidmət müraciətlərinin düzgün komandaya yönləndirilməsi, təchizatçı sorğuları üçün məlumat toplamaq və cavab layihəsi hazırlamaq, yaxud əməliyyat sorğusunda çatışmayan sahələri yoxlamaq. Birinci versiyada yalnız oxu və qaralama funksiyalarından başlayın; sonra ölçülmüş nəticələrə əsasən məhdud yazma əməliyyatları və təsdiq qapıları əlavə edin.

İdarə olunan agent sistemi adətən mövcud portal, CRM, sənəd anbarı və xəbərdarlıq kanalları ilə birlikdə işləyir. Buna görə texniki arxitektura ilə yanaşı istifadəçi ekranları, rol dizaynı və istisna prosesləri də planlaşdırılmalıdır. Məqsədiniz real əməliyyatlar üçün nəzarətli AI agent qurmaqdırsa, POLADO ilə AI həllinin əhatəsini müzakirə edin: proses xəritəsi, alət səlahiyyətləri, təsdiq qaydaları, audit tələbləri və pilot ssenari birlikdə müəyyən edilə bilər.