စျေးကွက်ဌာနက AI ကိုယ်စားလှယ်သုံးခုကို တိတ်တဆိတ်ချိတ်ဆက်ခဲ့ပြီး IT က လုံးဝမသိ: Shadow AI သည် ဆိုက်ဘာလုံခြုံရေးတွင်းနက်ကြီးဖြစ်လာနေသည်

အလတ်စား e-commerce တစ်ခု၏ ဆိုက်ဘာလုံခြုံရေးဝန်ထမ်းက ကျွန်တော့်ကို မြင်ကွင်းတစ်ခု ဖော်ပြဖူးသည်။ သူသည် ပုံမှန် API ဝင်ရောက်မှုမှတ်တမ်း စစ်ဆေးနေစဉ်၊ credential တစ်စုံသည် နံနက် သုံးနာရီတွင် order database ကို အဆက်မပြတ်ဖတ်နေကြောင်း တွေ့ရသည်။ တစ်ကြိမ်လျှင် ရာဂဏန်း၊ နှစ်လကျော် ကြာနေပြီ။

ဝင်ဖောက်ခြင်း မဟုတ်ပါ။ စျေးကွက်ဌာနက သုံးလကျော်က ချိတ်ဆက်ခဲ့သည့် AI ကိုယ်စားလှယ်တစ်ခုဖြစ်ပြီး၊ နေ့စဉ်အရောင်းအနှစ်ချုပ်ကို အလိုအလျောက်ထုတ်ရန်ဖြစ်သည်။ credential မှာ ထိုစဉ်က အင်ဂျင်နီယာတစ်ဦးက "အရင်စမ်းကြည့်အုံး" ဟုဆိုကာ ပေးထားခြင်းဖြစ်ပြီး၊ ခွင့်ပြုချက်မှာ table တစ်ခုလုံး read-only ဖြစ်သည်။

ဆိုးသူ တစ်ဦးမျှ မရှိပါ။ ကုမ္ပဏီစည်းမျဉ်းကို ချိုးဖောက်သူ တစ်ဦးမျှ မရှိပါ—အကြောင်းမှာ ကုမ္ပဏီတွင် ဤစည်းမျဉ်း လုံးဝမရှိသောကြောင့်ဖြစ်သည်။

ဖြစ်စဉ်နောက်ခံ

Shadow IT ဆိုသည့်စကားလုံးသည် ကြာမြင့်စွာက ရှိနေပြီ: ဝန်ထမ်းများသည် IT ဌာနကို ကျော်ဖြတ်ကာ ကိုယ်တိုင်ကိရိယာအသုံးပြု၊ ကိုယ်ပိုင် Dropbox ဖြင့် ဖိုင်ပို့၊ အခမဲ့ online ကိရိယာဖြင့် PDF ပြောင်း။ အန္တရာယ်သည် အစစ်အမှန်ရှိသော်လည်း၊ နယ်နိမိတ်မှာ တော်တော်ရှင်းသည်—ထိုကိရိယာများသည် passive ဖြစ်၊ သင်ဘာထည့်လျှင် ၎င်းက ဘာလုပ်သည်။

AI ကိုယ်စားလှယ်က မတူပါ၊ ဤကွာခြားချက်သည် သော့ချက်ဖြစ်သည်။ ကိုယ်စားလှယ်သည် လုပ်ဆောင်ချက်များကို တက်ကြွစွာ လုပ်ဆောင်သည်: စနစ်ကိုဖတ်၊ API ကိုခေါ်၊ အချက်အလက်ရေးသွင်း၊ မက်ဆေ့ချ်ပို့။ ၎င်းသည် သင်တစ်ခါတစ်ရံ ဖိုင်တင်သည့် ဝဘ်ဆိုက်မဟုတ်ဘဲ၊ အဆက်မပြတ်လည်ပတ်၊ credential ကိုင်ဆောင်၊ သင့်စနစ်အတွင်း လက်တွေ့လုပ်ကိုင်နေသည့်အရာဖြစ်သည်။

မိတ်ဆက်ရ အခက်အခဲကလည်း မယုံနိုင်လောက်အောင် နည်းသည်။ ယခု low-code ပလက်ဖောင်းများက စျေးကွက်ဝန်ထမ်းတစ်ဦးကို တစ်နေ့လယ်အတွင်း CRM ကိုဖတ်၊ report ရေး၊ Slack မက်ဆေ့ချ်ပို့မည့် ကိုယ်စားလှယ်တစ်ခုကို ချိတ်ဆက်နိုင်စေသည်။ သူ IT အတည်ပြုချက် မလို၊ ဝယ်ယူမှုလုပ်ငန်းစဉ် မလို၊ "စနစ်မိတ်ဆက်နေသည်" ဟုပင် မခံစားရနိုင်—သူသည် အလိုအလျောက်လုပ်ဆောင်မှုတစ်ခုသာ တပ်ဆင်လိုက်သည်ဟု ခံစားရသည်။

ဤပြဿနာသည် startup များ အထူးလုပ်ကိုင်လောက်အောင် ကြီးမားသည်။ Y Combinator ၂၀၂၆ နွေရာသီ batch ၏ Decawork သည် "IT အဖွဲ့အတွက် ကိုယ်စားလှယ်ထိန်းချုပ်မှုအလွှာ" ဟု ကိုယ်တိုင်ဆိုကာ၊ IT ဌာနကို interface တစ်ခုတည်းတွင် အဖွဲ့အစည်းတစ်ခုလုံး၏ AI ကိုယ်စားလှယ်များကို တပ်ဆင်၊ စီမံ၊ ထိန်းသိမ်းစေရန် အဓိကထားသည်: အွန်လိုင်းမတက်မီ လက်မှတ်ရေးထိုးရ၊ credential ခွင့်ပြုချက်ကို အနည်းဆုံးအတိုင်းအတာသို့ ကျုံ့ရ၊ လုပ်ဆောင်ချက်အားလုံးကို စောင့်ကြည့်မှတ်တမ်းတင်ရသည်။ ကုမ္ပဏီကို Aman Raj နှင့် Sarthak Aggarwal တို့က ၂၀၂၆ ခုနှစ်တွင် San Francisco ၌ တည်ထောင်ခဲ့ပြီး၊ လက်ရှိ အဖွဲ့သည် နှစ်ဦးသာရှိသည်—အရွယ်အစားသေးသော်လည်း၊ ဦးတည်ချက်က ပြဿနာ၏ အစစ်အမှန်ဖြစ်မှုကို ရှင်းပြသည်။

ဤအကြိမ်၏ အဓိကအချက်များ

• Shadow AI နှင့် Shadow IT ၏ သော့ချက်ကွာခြားချက်: ကိုယ်စားလှယ်သည် လုပ်ဆောင်ချက်များကို တက်ကြွစွာ လုပ်ဆောင်သည်၊ သင်ပေးသည့်အရာကို passive ဖြင့် လုပ်ဆောင်ခြင်းမဟုတ်ပါ။
• မိတ်ဆက်ရ အခက်အခဲ အလွန်နည်းသည်၊ နည်းပညာမဟုတ်သူတစ်ဦး တစ်နေ့လယ်အတွင်း credential ကိုင်ဆောင်သည့် ကိုယ်စားလှယ်တစ်ခုကို ချိတ်ဆက်နိုင်သည်။
• အကြီးမားဆုံးအန္တရာယ်သည် အချက်အလက်ပေါက်ကြားခြင်းမဟုတ်ဘဲ၊ ခွင့်ပြုချက်လွန်ကဲပြီး ကြီးကြပ်သူမရှိသည့် အဆက်မပြတ်ဝင်ရောက်မှုဖြစ်သည်။
• စစ်ဆေးရခက်ခဲသည်: ကိုယ်စားလှယ်၏ အပြုအမူသည် dynamic ဖြစ်ပြီး၊ ရိုးရာ static ခွင့်ပြုချက်မော်ဒယ်ဖြင့် လွှမ်းခြုံရ မလွယ်ပါ။
• ဤပြဿနာကို စည်းမျဉ်းက သတိပြုမိလာနေသည်၊ ဥရောပသမဂ္ဂ AI ဥပဒေ၏ စစ်ဆေးနိုင်မှုလိုအပ်ချက်သည် စီးပွားရေးလုပ်ငန်းများ ကိုင်တွယ်မှုကို အရှိန်မြှင့်ပေးမည်။

ဈေးကွက်သက်ရောက်မှု ခွဲခြမ်းစိတ်ဖြာချက်

မြန်မာအသုံးပြုသူများအတွက်

အရင်တရားမျှတသောစကားတစ်ခွန်း ပြောပါရစေ: ကိုယ်တိုင် AI ကိုယ်စားလှယ် ချိတ်ဆက်တတ်သည့်ဝန်ထမ်းသည် ပုံမှန်အားဖြင့် အဖွဲ့ထဲ၌ အတက်ကြွဆုံးလူများဖြစ်သည်။ သူတို့သည် စည်းမျဉ်းဖျက်ဆီးနေခြင်းမဟုတ်ဘဲ၊ ကိုယ့်ပြဿနာကို ဖြေရှင်းနေခြင်းဖြစ်ပြီး၊ မကြာခဏ ကောင်းစွာ ဖြေရှင်းနိုင်ကြသည်။

ထို့ကြောင့် Shadow AI ကို ကိုင်တွယ်ရာတွင် ပထမမူသည်: တားမြစ်နည်းဖြင့် မကိုင်တွယ်ပါနှင့်။ သင်တားမြစ်လိုက်တာနှင့် ဤကိစ္စသည် မြေအောက်သို့သာ ရွှေ့သွားမည်—မူလ ကုမ္ပဏီအကောင့်အောက်ရှိ ကိုယ်စားလှယ်သည် ကိုယ်ပိုင်အကောင့်သို့ ရွှေ့ခံရကာ၊ ပိုမို ခြေရာခံရ ခက်ခဲသွားမည်။

လက်တွေ့ကျသည့်နည်းလမ်းမှာ တရားဝင်လမ်းကြောင်းတစ်ခု ပေးခြင်းဖြစ်သည်။ ဝန်ထမ်းများကို ရှင်းလင်းစွာ ပြောပါ: သင်ကိုယ်စားလှယ်သုံးနိုင်သည်၊ သို့သော် မှတ်ပုံတင်ရမည်၊ ရိုးရှင်းသော စစ်ဆေးမှုတစ်ခုကို ဖြတ်ရမည်၊ အင်ဂျင်နီယာဆီတောင်းယူသည့် credential မဟုတ်ဘဲ IT ထုတ်ပေးသည့် credential ကို သုံးရမည်။ ပွတ်တိုက်မှုကို အနည်းဆုံးထားပြီး၊ လိုက်နာခြင်းက ချိုးဖောက်ခြင်းထက် ပိုအဆင်ပြေအောင် လုပ်ပါ။ ဤသည် မည်သည့်မူဝါဒစာရွက်စာတမ်းထက်မဆို ပိုထိရောက်သည်။

စီးပွားရေးအသုံးချမှုအတွက်

စီးပွားရေးအန္တရာယ်စီမံခန့်ခွဲမှုအမြင်အရ၊ Shadow AI ၏ အန္တရာယ်ကို စနစ်တကျ လျှော့တွက်ခံရသည်။ အကြောင်းရင်း သုံးခုရှိသည်။

ပထမ ခွင့်ပြုချက်ထိန်းချုပ်မှုဆုံးရှုံးခြင်း။ credential ကို ပုံမှန်အားဖြင့် ယာယီပေးထားခြင်းဖြစ်ပြီး၊ ပေးသည့်အခါ "အရင်စမ်း" ဟုတွေးကာ၊ စမ်းပြီးလျှင် ပြန်လာသိမ်းသူ တစ်ဦးမျှမရှိ။ AI ကိုယ်စားလှယ်သည် အခြေအနေအမျိုးမျိုးကို ကိုင်တွယ်နိုင်ရန် ပေးထားသည့်ခွင့်ပြုချက်သည် တကယ်လိုအပ်သည်ထက် ပိုကြီးလေ့ရှိသည်—table တစ်ခုလုံး read-only က တစ်ချက်ချင်း ခွင့်ပြုသည်ထက် လွယ်သောကြောင့် table တစ်ခုလုံး read-only ကို ပေးလိုက်သည်။

ဒုတိယ အချက်အလက်စီးဆင်းရာ မရှင်းလင်းခြင်း။ ကိုယ်စားလှယ်နောက်ကွယ်တွင် ချိတ်ဆက်ထားသည်မှာ ဘယ်ကုမ္ပဏီ၏ မော်ဒယ်လဲ? အချက်အလက်သည် မြန်မာနိုင်ငံမှ ထွက်သွားသလား? လေ့ကျင့်ရေးအတွက် သုံးခံရသလား? မိတ်ဆက်သူ အများစုသည် ဤမေးခွန်းများကို မမေးဖူးပါ၊ အကြောင်းမှာ interface တွင် မပြသောကြောင့်ဖြစ်သည်။

တတိယ၊ အခက်ခဲဆုံးမှာ: စစ်ဆေးလမ်းကြောင်း မရှိခြင်း။ တစ်နေ့တွင် "ကျွန်တော်တို့ ဖောက်သည်အချက်အလက်ကို မလျော်ကန်စွာ ဝင်ရောက်ခံရသလား" ကို ဖြေရန်လိုသောအခါ၊ ကိုယ်စားလှယ်ကို ဌာနက ကိုယ်တိုင်ချိတ်ဆက်ထားလျှင် ဘယ်ကနေ စစ်ရမည်ဆိုတာတောင် သင်မသိပါ။

လက်တွေ့တွင် ပထမအဆင့်မှာ ကိရိယာဝယ်ခြင်း မဟုတ်ဘဲ စာရင်းကောက်ခြင်းဖြစ်သည်။ အရိုးရှင်းဆုံးနည်းဖြင့်: API key ထုတ်ပေးမှတ်တမ်း စစ်၊ database ၏ ပုံမှန်မဟုတ်သောဝင်ရောက်မှုပုံစံ စစ်၊ ဌာနအသီးသီး၏ SaaS subscription ဘေလ် စစ်၊ ဌာနခေါင်းဆောင်များကို "သင်တို့ အလိုအလျောက်လုပ်ပေးသည့် ကိရိယာတစ်ခုခု သုံးနေသလား" ဟု တိုက်ရိုက်မေး။ ဤစာရင်းသည် ပုံမှန်အားဖြင့် လူကို လန့်စေတတ်သည်။

စာရင်းကောက်ပြီးမှသာ အဆင့်ခွဲသည်: မည်သည့်ကိုယ်စားလှယ်များ ကိုယ်ရေးအချက်အလက်ကို ထိတွေ့နိုင်၊ မည်သည့်အရာ ဖတ်ရုံသာမက ရေးသွင်းနိုင်၊ မည်သည့်အရာ ပြင်ပသို့ မက်ဆေ့ချ်ပို့နိုင်။ ကိုယ်ရေးအချက်အလက်ထိ၊ ရေးသွင်းနိုင်၊ ပြင်ပသို့ပို့နိုင်သည့်အရာသည် အန္တရာယ်အမြင့်ဆုံးဖြစ်၍ ဦးစွာ ကိုင်တွယ်ပါ။

ဆော့ဖ်ဝဲရေးဆွဲသူများအတွက်

အင်ဂျင်နီယာအဖွဲ့အတွက် ဤကိစ္စ၏ အလက်တွေ့အကျဆုံးသင်ခန်းစာမှာ: credential ထုတ်ပေးမှုတွင် သက်တမ်းစက်ဝန်း ရှိရမည်။

"အရင်စမ်းကြည့်" သည် ပြဿနာအားလုံး၏ အစဖြစ်သည်။ ဆီလျော်သောနည်းလမ်းမှာ မည်သည့်ယာယီ credential မဆို သက်တမ်းကုန်ရက် ရှိရမည်၊ အချိန်ကုန်လျှင် အလိုအလျောက်ပျက်ပြယ်၊ တိုးချဲ့လိုလျှင် ပြန်လျှောက်ရမည်။ ဤကိစ္စသည် နည်းပညာအရ မခက်ပါ၊ ခက်တာက အလေ့အထဖြစ်သည်။

နောက်ထပ်တည်ဆောက်ရမည်မှာ အနည်းဆုံးခွင့်ပြုချက် default ဖြစ်သည်။ ကိုယ်စားလှယ်က order အချက်အလက်ဖတ်ရန်ဆိုလျှင်၊ order အချက်အလက်၏ read-only ခွင့်ပြုချက်ကိုသာ ပေးပါ၊ database တစ်ခုလုံး မဟုတ်။ ဤသည် ဆိုက်ဘာလုံခြုံရေးအခြေခံဟု ကြားရသော်လည်း၊ "မြန်မြန် လည်ပတ်စေ" ဆိုသည့်ဖိအားအောက်တွင် အဖြစ်အများဆုံး ကျော်လွှားခံရသည်။

ကိုယ်စားလှယ်၏ အပြုအမူ log ကိုလည်း ပထမတန်းစားနိုင်ငံသားအဖြစ် ဒီဇိုင်းဆွဲရန် အကြံပြုသည်။ ကိုယ်စားလှယ်က ဘာလုပ်ခဲ့၊ ဘာဝင်ရောက်ခဲ့၊ ဘာ output ထုတ်ခဲ့သည်ကို ဒီဇိုင်းဆွဲစဉ်ကပင် မချန်ထားလျှင် ဖြစ်ပြီးနောက် လုံးဝ ပြန်ဖြည့်၍မရ။ ဥရောပသမဂ္ဂ AI ဥပဒေ၏ စစ်ဆေးနိုင်မှုလိုအပ်ချက်သည် ဤကိစ္စကို အကောင်းဆုံးအလေ့အထမှ မရှိမဖြစ်အခြေအနေသို့ တွန်းပို့နေသည်။

အနာဂတ်ဖွံ့ဖြိုးတိုးတက်မှုလမ်းကြောင်း

ပထမ၊ ကိုယ်စားလှယ်စီမံအုပ်ချုပ်မှုသည် IAM (identity နှင့် access management) ၏ တိုးချဲ့နယ်ပယ်ဖြစ်လာမည်။ ရှိပြီးသား ခွင့်ပြုချက်စီမံခန့်ခွဲမှုကိရိယာသည် လူနှင့် application အတွက် ဒီဇိုင်းဆွဲထားပြီး၊ ကိုယ်စားလှယ်၏ အပြုအမူပုံစံသည် နှစ်ခုကြားတွင်ရှိသည်—application ကဲ့သို့ အဆက်မပြတ်လည်ပတ်သော်လည်း၊ လူကဲ့သို့ ကြိုတင်မခန့်မှန်းနိုင်သော ဆုံးဖြတ်ချက်ချသည်။ ဤကွက်လပ်ကို ဖြည့်ဆည်းလိမ့်မည်၊ ရှိပြီးသား ဆိုက်ဘာလုံခြုံရေးကုမ္ပဏီကြီးများက startup ကို ဝယ်ယူ၍ ပြီးမြောက်နိုင်သည်။

ဒုတိယ၊ "ကိုယ်စားလှယ် identity" သည် ရှင်းလင်းသောသဘောတရားတစ်ခု ဖြစ်လာမည်။ service account သည် ထိုစဉ်က လူ့အကောင့်မှ ကွဲထွက်လာသကဲ့သို့၊ ကိုယ်စားလှယ်သည် ကိုယ်ပိုင် identity အမျိုးအစား၊ ကိုယ်ပိုင်ခွင့်ပြုချက်မော်ဒယ်နှင့် ကိုယ်ပိုင်သက်တမ်းစက်ဝန်းစီမံခန့်ခွဲမှု လိုအပ်သည်။

တတိယ၊ စည်းမျဉ်းက ဤကိစ္စကို အရှိန်မြှင့်မည်။ စီးပွားရေးလုပ်ငန်းများ တာဝန်ရှိအာဏာပိုင်ကို မိမိ AI စနစ် ဘာလုပ်ခဲ့သည်ကို သက်သေပြရမည့်အခါ၊ တည်ရှိမှန်း မည်သူမျှမသိသည့် ကိုယ်စားလှယ်များသည် မခံနိုင်သောအန္တရာယ်ဖြစ်လာမည်။ လိုက်နာမှုဖိအားသည် ဆိုက်ဘာလုံခြုံရေးသတိပေးချက်ထက် ဘတ်ဂျက်ကို ပိုတွန်းအားပေးလေ့ရှိသည်။

TheAI Academy ၏ အနှစ်ချုပ်နှင့် သုံးသပ်ချက်

ဦးစွာ လူကြိုက်များမည်မဟုတ်သည့်စကားတစ်ခွန်း ပြောပါရစေ: ဤကိစ္စ၏ တာဝန်သည် ကိုယ်တိုင်ကိုယ်စားလှယ်ချိတ်ဆက်သည့်ဝန်ထမ်းများပေါ်တွင် မရှိပါ။

ကုမ္ပဏီက တရားဝင်လမ်းကြောင်း မပေး၊ စည်းမျဉ်း မရှင်းပြ၊ "table တစ်ခုလုံး read-only credential ကို ပြင်ပဝန်ဆောင်မှုသို့ ပေးခြင်း" တွင် ဘာပြဿနာရှိသည်ကို ပြောမည့်သူမရှိသောအခါ၊ ဝန်ထမ်းက ကိုယ့်နည်းဖြင့် ပြဿနာဖြေရှင်းခြင်းသည် လုံးဝ ဆီလျော်သောအပြုအမူဖြစ်သည်။ တာဝန်သည် အဖွဲ့အစည်းက ကိရိယာပြောင်းလဲမှုအရှိန်ကို မလိုက်နိုင်ခြင်းတွင် ရှိသည်။

ဤပြဿနာအပေါ် ကျွန်တော့်ဆုံးဖြတ်ချက်မှာ: ၎င်း ယခု မပေါက်ကွဲသေးသော်လည်း၊ စုဆောင်းနေဆဲဖြစ်သည်။ စီးပွားရေးလုပ်ငန်းအများစုရှိ Shadow AI သည် "report ထုတ်ပေးခြင်း" ကဲ့သို့ အတော်အသင့် အန္တရာယ်ကင်းသောအဆင့်တွင် ရှိသေးသော်လည်း၊ ကိုယ်စားလှယ်၏ စွမ်းရည်သည် လတိုင်း တောင့်တင်းလာနေပြီး၊ credential တစ်စုတည်းက လာမည့်နှစ်တွင် အချက်အလက်ဖတ်ရုံသာ မကတော့နိုင်ပါ။

ကိုင်တွယ်ရမည့်အချိန်သည် ယခုဖြစ်သည်၊ စာရင်းကို ကောက်နိုင်သေးသည့်အချိန်တွင်။

သုံးသပ်ချက်: Shadow AI သည် ဝန်ထမ်း၏ စည်းကမ်းပြဿနာမဟုတ်ဘဲ၊ အဖွဲ့အစည်း၏ စီမံအုပ်ချုပ်မှုကွက်လပ်ဖြစ်သည်။ တားမြစ်ခြင်းက အသုံးမဝင်ပါ၊ တစ်ခုတည်းသောထိရောက်နည်းမှာ လိုက်နာမှုလမ်းကို ချိုးဖောက်မှုထက် ပိုကောင်းအောင် ခင်းပေးခြင်းဖြစ်သည်။

မြန်မာစာဖတ်သူများအတွက် တိကျသောအကြံပြုချက်: သင်သည် ကုမ္ပဏီ၏ IT သို့မဟုတ် ဆိုက်ဘာလုံခြုံရေးကို တာဝန်ယူနေလျှင်၊ ဤလ ကိစ္စသုံးခု လုပ်ပါ။ ပထမ၊ စာရင်းကောက်—API key ထုတ်ပေးမှတ်တမ်း၊ database ပုံမှန်မဟုတ်သောဝင်ရောက်မှုပုံစံနှင့် ဌာနအသီးသီး SaaS ဘေလ်ကို စစ်ကာ၊ ကိုယ်စားလှယ်စာရင်းတစ်ခု ပြုစုပါ။ ဒုတိယ၊ credential ကို ကျုံ့—ယာယီ credential အားလုံးကို သက်တမ်းကုန်ရက်သတ်မှတ်၊ ကိုယ်စားလှယ်ခွင့်ပြုချက်အားလုံးကို အနည်းဆုံးလိုအပ်အတိုင်းအတာသို့ ကျုံ့ပါ။ တတိယ၊ တရားဝင်လမ်းကြောင်းတစ်ခု ဖွင့်—ငါးမိနစ်ဖြင့် ဖြည့်ပြီးနိုင်သည့် မှတ်ပုံတင်ပုံစံတစ်ခု ဒီဇိုင်းဆွဲကာ၊ ဝန်ထမ်းများ ကိုယ်တိုင်တင်ပြလိုစိတ်ရှိအောင် လုပ်ပါ။ စီမံအုပ်ချုပ်မှုကိရိယာအတွက်မူ၊ Decawork ကဲ့သို့ ထုတ်ကုန်၏ ဦးတည်ချက်မှန်သော်လည်း အဖွဲ့မှာ နှစ်ဦးသာရှိ၍ ယခုနှစ်မှ တည်ထောင်ခြင်းဖြစ်ရာ၊ လက်ရှိအဆင့်တွင် ပြဿနာကို ဦးစွာနားလည်၊ အနည်းငယ်စောင့်ကြည့်ရန် အကြံပြုသည်၊ ကုမ္ပဏီ၏ သော့ကို လက်လွှတ်ရန် မလောပါနှင့်။ ဆက်စပ်ကိရိယာများ ပိုမိုသိရှိလိုပါက ဆိုက်ပေါ်ရှိ AI ဖွံ့ဖြိုးရေးမူဘောင်နှင့် အခြေခံအဆောက်အအုံ အမျိုးအစား သို့မဟုတ် AI လုပ်ငန်းလမ်းညွှန် ကို ကြည့်နိုင်ပါသည်။

အချက်အလက်ရင်းမြစ်

• Decawork（Y Combinator ကုမ္ပဏီစာမျက်နှာ）
• ဥရောပကော်မရှင်: AI ဥပဒေ အာဏာသက်ရောက်မှုမူဘောင်

（ဤဆောင်းပါးကို အများသိအချက်အလက်များအရ စုစည်းထားပြီး၊ ဖြစ်ရပ်အခြေအနေကို အင်တာဗျူးများစွာ ပေါင်းစပ်၍ ပြန်လည်ရေးသားထားခြင်းဖြစ်ကာ၊ သတ်မှတ်ကုမ္ပဏီတစ်ခုကို ရည်ညွှန်းခြင်းမဟုတ်ပါ။）