Ձեր AI գործակալը միայն-կարդալու է, բայց CRM-ը փոփոխվել է

Ինժեներներից մեկն անցկացրել է մի փոքրիկ փորձ և հրապարակել այն Habr-ում. AI մոդել, որը CRM-ում գրելու թույլտվություն չուներ, այնուամենայնիվ վերջում փոփոխել է CRM գրառում։ Ոչ թե այն պատճառով, որ մոդելը դուրս է եկել իր սահմաններից, այլ որովհետև նրա հետևում կանգնած բաղադրիչն ուներ բանալիները։ Եթե պատրաստվում եք թողնել, որ AI գործակալը մոտենա ձեր հաճախորդների բազային, հենց այս տարբերությունն է ավելի կարևոր, քան մատակարարի ցանկացած խոստում։

Ինչ իրականում տեղի ունեցավ փորձի ընթացքում

կարգավորումը հիմնված էր n8n-ի վրա կառուցված աշխատանքային հոսքի, DeepSeek մոդելի և HubSpot CRM-ի վրա։ Ինքը՝ մոդելը, HubSpot-ի մուտքի տվյալներ չուներ։ Այն ուղղակիորեն չէր կարող դիմել CRM-ին։ Այս սահմանափակումն իսկապես գործում էր։

Այնուամենայնիվ, աշխատանքային հոսքի հաջորդ քայլն ուներ գրելու իրավունքներ։ Նրա խնդիրն էր վերցնել մոդելի կառուցվածքային առաջարկը և իրականացնել այն։ Հսկիչ սցենարում մարդու համար ընթեռնելի հարցումը վերաբերում էր մեկ արհեստական թեստային գործարքի, մինչդեռ կառուցվածքային նպատակակետը ցույց էր տալիս մեկ այլ գործարք։ Աշխատանքային հոսքը շարունակվեց, կատարեց թարմացումը, և սխալ գործարքը փոփոխվեց։ Հետագա առանձին ընթերցումը դա հաստատեց. երկրորդ գործարքը փոփոխվել էր, առաջինը մնացել էր անձեռնմխելի։

Հետո հեղինակն ավելացրեց մեկ բան՝ առանձին, հստակ որոշիչ ստուգում մոդելի առաջարկի և CRM-ին կատարվող փաստացի կանչի միջև։ Այդ ստուգումն ուսումնասիրում էր պարամետրերի կարճ ցանկ՝ որ համակարգին են դիմում, որ օբյեկտի ID-ին, ինչ վիճակում պետք է լինի գրառումը, և ինչ անցում է թույլատրվում։ Մուտքի տվյալները ոչ մի տեղ չգնացին. աշխատանքային հոսքը դեռ կարող էր գրել։ Բայց հիմա գրելը կախված էր նախ այդ ստուգումն անցնելուց։ Նորմալ սցենարն անցավ և ավարտվեց հաջողությամբ։ Անհամապատասխանողը մերժվեց, և գրառումը մնաց նույնը։

Հեղինակի եզրակացությունը կարճ է. այն, ինչ մոդելին թույլատրված է անել, նույնը չէ, ինչ համակարգին թույլատրված է անել։ Դասական անվտանգության տերմիններով սա մոտ է «շփոթված ենթակայի» (confused deputy) խնդրին՝ հին գաղափար, որը հայտնվել է նոր տեղում։

Ինչու է սա կարևոր փոքր բիզնեսի համար

«Գործակալը միայն-կարդալու է» նախադասությունը հարմար է։ Այն մտնում է ճարտարապետական նշման, անվտանգության հարցաշարի, հաճախորդի պատասխանի կամ շահագործման որոշման մեջ։ Եթե այդ նախադասությունը հիմնված է միայն այն բանի վրա, թե որ մուտքի տվյալներն ունի մոդելը, ապա այն նկարագրում է շղթայի մի մասը, ոչ թե ամբողջը։

Բիզնեսի համար գործնական ռիսկը դրամատիկ չէ։ Այն հանգիստ է և ձանձրալի. սխալ գործարքը թարմացվում է, սխալ պատվերը նշվում է որպես վճարված, սխալ հաճախորդի կարգավիճակը փոխվում է։ Մեկ շաբաթ ոչ ոք չի նկատում։ Հետո ինչ-որ մեկը փորձում է համադրել թվերը և չի կարողանում բացատրել դրանք։ Աուդիտի հետագիծը, եթե այն գոյություն ունի, ցույց է տալիս հաջողված API կանչ՝ տեխնիկապես ճիշտ, բայց փաստացիորեն սխալ։

Դա վերաբերում է ցանկացած բիզնեսի, որը թույլ է տալիս ավտոմատացմանը դիպչել գործառնական տվյալներին՝ CRM, պատվերների համակարգ, տոմսերի գործիք, պահեստ։ Որքան սովորական է թվում ավտոմատացումը, այնքան պակաս հավանական է, որ որևէ մեկը ստուգում է այն սահմանագիծը, որտեղ իրական փոփոխությունը տեղի է ունենում։

Ինչ պետք է ստուգել, մինչև գործակալը դիպչի հաճախորդների տվյալներին

Հոդվածն ավարտվում է վեց հարցով, որոնք արժե տալ մինչև արտադրության մեջ գործարկումը կամ մինչև գործակալի իրավունքների ընդլայնումը։ Ահա ստուգացանկը, որը կարող եք կիրառել այս ամսվա ընթացքում.

• Գտեք, թե որտեղ են ֆիզիկապես գտնվում գրելու մուտքի տվյալները։ Ոչ թե որտեղ է մոդելը, այլ որ բաղադրիչն է իրականացնում արտաքին կանչը։ Հենց այդ բաղադրիչն է սահմանում ձեր իրական ռիսկը։
• Թվարկեք, թե ինչ է ստուգվում ուղղակիորեն կանչից առաջ։ Թիրախային համակարգ, օբյեկտի ID, ընթացիկ ակնկալվող վիճակ, թույլատրված անցում։ Եթե այդ պահին ոչինչ չի ստուգվում, ապա ստուգումն ըստ էության գոյություն չունի։
• Հարցրեք, թե կարո՞ղ է թիրախը փոխվել հարցումի և գրման միջև ընկած ժամանակահատվածում։ Լաբորատոր դեպքը ճիշտ սա էր. հարցումն անվանում էր մեկ գրառում, կառուցվածքային առաջարկը՝ մեկ ուրիշը։ Ոչ մի չարամտություն, պարզապես անհամապատասխանություն, որը ոչինչ չկարողացավ բռնել։
• Դրեք անկախ ֆիլտր առաջարկի և հետևանքի միջև։ Փորձի մեջ այդ ֆիլտրը հստակ որոշիչ կոդ էր, ոչ թե մեկ այլ մոդել, որը որոշում է, թե արդյոք առաջին մոդելը ճիշտ էր։
• Հաստատեք գործողությունից հետո ստացված վիճակը, ոչ միայն այն, որ կանչը հաջողվել է։ Առանձին ընթերցումն էր, որ ապացուցեց արդյունքը փորձի երկու ուղղություններով էլ։
• Պահեք վերականգնելի շղթա։ Ինչ է առաջարկվել, ով կարող էր կատարել այն, ինչ է ստուգվել, ինչ է իրականում կանչվել, ինչ վիճակ է ստացվել դրանից։ Առանց դրա՝ ունեք հայտարարություն վերահսկողության մասին, ոչ թե դրա ապացույց։

Եզրակացություն

Դա եղել է լաբորատոր փորձ արհեստական գրառումներով, և հեղինակն ուղղակիորեն ասում է դա։ Բայց սկզբունքը փոխանցվում է։ Մոդելից մուտքի տվյալները հեռացնելը իրական վերահսկողություն է. այն պարզապես սահմանափակում է մոդելը, ոչ թե նրա շուրջ գտնվող համակարգը։ Մինչև գործակալին հաստատեք, հետևեք թույլտվությանն ամբողջովին մինչև այն բաղադրիչը, որը կարող է իրական փոփոխություն առաջացնել, և հենց այնտեղ դրեք ձեր ստուգումը։ Դա միակ վայրն է, որտեղ այն իրապես ինչ-որ բան է անում։