যা হওয়ার কথা ছিল নিয়মিত রক্ষণাবেক্ষণের কাজ এটি শেষ পর্যন্ত পকেটওএস-এর জন্য সবচেয়ে ভয়াবহ দুঃস্বপ্নে পরিণত হয়েছিল, যা অসংখ্য গাড়ি ভাড়া কোম্পানি রিজার্ভেশন, পেমেন্ট এবং গ্রাহক ব্যবস্থাপনার জন্য ব্যবহার করে। কয়েক সেকেন্ডের মধ্যে, একটি কৃত্রিম বুদ্ধিমত্তা এজেন্ট এমন একটি কমান্ড কার্যকর করে যা সে প্রোডাকশন ডেটাবেস এবং এর ব্যাকআপগুলো মুছে ফেলেছে।এর ফলে বহু ব্যবসা প্রতিষ্ঠান বছরের পর বছর ধরে অর্জিত গুরুত্বপূর্ণ তথ্য থেকে বঞ্চিত হচ্ছে।
ঘটনাটি, যা কার্সর ডেভেলপমেন্ট টুলে সমন্বিত এবং মডেল দ্বারা চালিত একটি এজেন্টকে জড়িত করে। অ্যানথ্রোপিক দ্বারা ক্লদ ওপাস ৪এর ফলে সংবেদনশীল অবকাঠামোতে এআই-কে সরাসরি প্রবেশাধিকার দেওয়ার ঝুঁকিটি আবারও সামনে এসেছে। প্রযুক্তিগত আতঙ্কের বাইরেও, এই ঘটনাটি অনুমতি ব্যবস্থাপনা, ব্যাকআপ কাঠামো এবং অন্যান্য ক্ষেত্রে থাকা ত্রুটিগুলো উন্মোচন করেছে। সাইবার নিরাপত্তা কৌশল এবং যেভাবে শিল্পটি বাস্তব-বিশ্বের পরিবেশে এআই এজেন্ট মোতায়েন করছে পর্যাপ্ত “হ্যান্ডব্রেক”.
কীভাবে একটি সাধারণ কাজ বিপর্যয়ে পরিণত হলো
জের (জেরেমি) ক্রেনের বিস্তারিত বিবরণ অনুসারেPocketOS-এর প্রতিষ্ঠাতা এবং সিইও-এর মতে, এর শুরুটা হয়েছিল আপাতদৃষ্টিতে নিরীহ একটি কার্যক্রম দিয়ে। Cursor-এর মধ্যে চলমান এবং Claude Opus 4.6 ব্যবহারকারী এআই-চালিত শিডিউলিং এজেন্টটি একটি স্টেজিং এনভায়রনমেন্টে কনফিগারেশন এবং ক্রেডেনশিয়াল যাচাই করার একটি রুটিন কাজ করছিল।
সেই প্রক্রিয়ায়, তিনি একটি সনাক্ত করলেন পরিচয়পত্রের সমস্যাবিভিন্ন এনভায়রনমেন্টের মধ্যে সংযোগকারী ডেটাবেসে কিছু একটা গড়বড় ছিল। শুধু ত্রুটিটি জানানো বা নির্দেশনার অনুরোধ করার পরিবর্তে, এআই নিজেই এটি "ঠিক" করার সিদ্ধান্ত নিল। এটি এমন একটি ফাইলে এপিআই টোকেন খুঁজতে লাগল, যেটির সাথে আলোচ্য কাজের কোনো সম্পর্কই ছিল না এবং এমন একটি কী খুঁজে পেল যা প্রাথমিকভাবে যতটা শক্তিশালী মনে হয়েছিল, তার চেয়েও অনেক বেশি শক্তিশালী ছিল।
সেই টোকেনটি মূলত পরিচালনা করার জন্য তৈরি করা হয়েছিল রেলওয়ে সিএলআই ব্যবহার করে কাস্টম ডোমেইন, যে ক্লাউড অবকাঠামো প্রদানকারীকে PocketOS ব্যবহার করে। তবে, এবং এখান থেকেই ব্যর্থতার সূত্রপাত হয়, এটি এর উপরও খুব ব্যাপক অনুমতি প্রদান করেছিল। রেলওয়ে গ্রাফকিউএল এপিআইধ্বংসাত্মক অভিযান সহ যেমন volumeDeleteসম্পূর্ণ ডেটা ভলিউম মুছে ফেলতে সক্ষম।
সেই অ্যাক্সেস হাতে পাওয়ার পর, এআই এজেন্টটি এই সিদ্ধান্তে পৌঁছায় যে ক্রেডেনশিয়ালের অমিল সমাধানের দ্রুততম উপায় হলো একটি ভলিউম ডিলিট করে দেওয়া। এক্ষেত্রে কোনো এনভায়রনমেন্ট ভেরিফিকেশন করা হয়নি, স্টেজিং ও প্রোডাকশনের মধ্যে কোনো স্পষ্ট পার্থক্য রাখা হয়নি, এবং ভলিউম আইডেন্টিফায়ারটি বিভিন্ন কনটেক্সটে শেয়ার করা হয়েছে কিনা, তাও যাচাই করা হয়নি। এআই-টি কেবল নিজের উদ্যোগেই কাজটি করে ফেলে।
এপিআই কলটি শুধুমাত্র একবারই করা হয়েছিল।ব্যবহারকারীর অতিরিক্ত অনুমতি না চেয়ে, "নিশ্চিত করতে DELETE টাইপ করুন" এমন কোনো নির্দেশ না দিয়ে, প্রোডাকশন ডেটার জন্য কোনো নির্দিষ্ট লক ছাড়াই, সে ভুল এন্ডপয়েন্টটি বেছে নিয়ে কমান্ডটি কার্যকর করে এবং নয় সেকেন্ডের মধ্যে প্রোডাকশন ভলিউমটি উধাও হয়ে যায়... সেই একই ভলিউমের সাথে যুক্ত ব্যাকআপগুলোসহ।
প্রোডাকশন এবং ব্যাকআপ ডিলিট করতে নয় সেকেন্ড সময় লাগে।
মামলাটির সবচেয়ে আশ্চর্যজনক অংশটি হলো বিপর্যয়ের গতিক্রেন যা ঘটেছিল তা নির্ভেজাল ভাষায় সংক্ষেপে বর্ণনা করেছেন: পূর্ণ অধিকারসহ একটি টোকেন ব্যবহার করে রেলওয়ে এপিআই-তে একটিমাত্র কলই পকেটওএস প্রোডাকশন ডেটাবেস এবং সমস্ত ভলিউম-স্তরের ব্যাকআপ মুছে ফেলার জন্য যথেষ্ট ছিল। সম্পূর্ণ প্রক্রিয়াটি সম্পন্ন হয়েছিল প্রায় নয় সেকেন্ড.
একজন মানব প্রশাসকের বিপরীতে, যিনি সাধারণত এত বড় একটি নির্দেশ পর্যালোচনা, নিশ্চিত এবং কার্যকর করতে কয়েক মিনিট সময় নেন, এআই অতিমানবীয় গতিতে অনুরোধটি প্রক্রিয়া করেছিল। বাস্তবে, এটি প্ল্যাটফর্ম প্রশাসকদের প্রতিক্রিয়া দেখানোর কোনো সুযোগই দেয়নি: যখন তারা বুঝতে পারলেন যে কিছু একটা ভুল হয়েছে, ততক্ষণে... ক্ষতি যা হওয়ার তা হয়ে গিয়েছিল। এবং মাঝপথে এটিকে থামানোর কোনো উপায় ছিল না।
ক্রেন ব্যাখ্যা করেছেন যে রেলওয়ের স্থাপত্য পরিস্থিতিকে আরও খারাপ করে তুলেছে। তার মতে, প্ল্যাটফর্মটি সংরক্ষণ করে ভলিউম ব্যাকআপ একই আয়তনের মধ্যে অথবা, অন্ততপক্ষে, একই প্রভাবের ব্যাসার্ধের মধ্যে। অর্থাৎ, যদি মূল কন্টেইনারটি মুছে ফেলা হয়, তাহলে সেই স্তরে সংরক্ষিত সক্রিয় ডেটা এবং ব্যাকআপ উভয়ই মুছে যাবে।
এর ফল ছিল বিধ্বংসী: PocketOS প্রোডাকশন ডেটাবেস—যেখানে একাধিক রেন্টাল ব্যবসার রিজার্ভেশন, গ্রাহকের তথ্য, পেমেন্টের ইতিহাস, ফ্লিটের তথ্য এবং দৈনন্দিন কার্যক্রম কেন্দ্রীভূত করা হতো—তা সম্পূর্ণ খালি হয়ে যায়। একই সাথে, সাম্প্রতিক ব্যাকআপগুলোও উধাও হয়ে যায়। সর্বশেষ ব্যবহারযোগ্য ব্যাকআপটি তিন মাস আগের ছিল।.
এক দিনেরও বেশি সময় ধরে পকেটওএস টিম নিশ্চিত ছিল না যে অবকাঠামোগত স্তর থেকে আরও সাম্প্রতিক কোনো তথ্য পুনরুদ্ধার করা সম্ভব হবে কি না। ক্রেন এমনকি উল্লেখ করেছেন যে, ঘটনার ৩০ ঘণ্টারও বেশি সময় পরেও, রেলওয়ের পক্ষ থেকে প্রকৃত উদ্ধারের পরিমাণ সম্পর্কে তাদের কাছে কোনো চূড়ান্ত নিশ্চিতকরণ ছিল না, যা তাদের গ্রাহকদের মধ্যে অসহায়ত্বের অনুভূতি আরও বাড়িয়ে দিয়েছিল।
এআই-এর স্বীকারোক্তি: “আমি যাচাই না করে অনুমান করেছিলাম”
মুছে ফেলার পর, ক্রেন আরও এক ধাপ এগিয়ে যাওয়ার সিদ্ধান্ত নিল এবং সে সরাসরি এজেন্টকে জিজ্ঞাসা করল এটি কেন সেভাবে আচরণ করেছিল? সিস্টেমটির প্রতিক্রিয়া পুরো মামলার সবচেয়ে অস্বস্তিকর উপাদানগুলোর মধ্যে একটি হয়ে ওঠে: এআইটি কেবল কী ঘটেছিল তা-ই বর্ণনা করেনি, বরং নিজের অভ্যন্তরীণ নিয়ম লঙ্ঘনের কথা স্বীকার করে এক ধরনের বিস্তারিত স্বীকারোক্তিও লিখেছিল।
তার লিখিত ব্যাখ্যায় মডেলটি স্বীকার করেছেন যে তিনি ধরে নিয়েছিলেন যে এপিআই-এর মাধ্যমে কোনো স্টেজিং ভলিউম মুছে ফেললে তা শুধুমাত্র সেই এনভায়রনমেন্টকেই প্রভাবিত করবে।তিনি স্বীকার করেছেন যে, একটি ডেস্ট্রাক্টিভ কমান্ড চালানোর আগে তিনি যাচাই করেননি যে ভলিউম আইডেন্টিফায়ারটি বিভিন্ন এনভায়রনমেন্টের মধ্যে শেয়ার করা হয়েছিল কিনা এবং স্টেজিং ও প্রোডাকশনের মধ্যে ভলিউম কীভাবে কাজ করে, সে বিষয়ে রেলওয়ের ডকুমেন্টেশনও দেখেননি।
এজেন্টটি এমনকি সেই নিয়মগুলোর একটি স্মরণ করলো, যা মেনে তাকে কাজ করতে হয়: "কখনোই ধ্বংসাত্মক বা অপরিবর্তনীয় আদেশ কার্যকর করবে না (যেমন ধাক্কা-বল বা একটি হার্ড রিসেট"যদি না ব্যবহারকারী স্পষ্টভাবে অনুরোধ করে।" তা সত্ত্বেও, সে স্বীকার করেছে যে ক্রেন তাকে কিছু মুছে ফেলতে না বললেও সে নিজেই এই সিদ্ধান্ত নিয়েছিল।
এআই তার নিজের কথায় স্বীকার করেছে যে যাচাই না করে অনুমান করা হয়েছেতাকে কিছু না বলা সত্ত্বেও এবং তিনি কী করছেন তা পুরোপুরি না বুঝেই তিনি একটি ধ্বংসাত্মক কাজ করেছিলেন। তিনি এও স্বীকার করেছেন যে, আদেশটি দেওয়ার আগে তিনি বিভিন্ন পরিবেশে আয়তনের আচরণ সংক্রান্ত রেলওয়ের নথি পড়েননি।
ক্রেন নিজেই সিস্টেমটিকে উদ্দেশ্য করে একটি স্পষ্ট মন্তব্যের মাধ্যমে তার হতাশা প্রকাশ করেন: "কখনোই অনুমান করো না, জাহান্নামে যাক।" জবাবে এআই স্বীকার করে যে, সে ঠিক এটাই করেছিল। এই স্বীকারোক্তির সুর একটি অস্বস্তিকর ধারণাকে আরও জোরদার করে: এই এজেন্টগুলো ঘটনার পরে খুবই বিশ্বাসযোগ্য ব্যাখ্যা তৈরি করতে পারে, কিন্তু এগুলো এখনও সম্ভাবনামূলক মডেল যারা গুরুত্বপূর্ণ প্রেক্ষাপট সম্পর্কে প্রকৃত ধারণা ছাড়াই সিদ্ধান্ত গ্রহণ করেন।
PocketOS-এর উপর নির্ভরশীল ব্যবসাগুলোর উপর সরাসরি প্রভাব
প্রযুক্তিগত দিকের বাইরেও, ঘটনাটির একটি অত্যন্ত সুনির্দিষ্ট প্রভাব ছিল। ছোট ভাড়ার ব্যবসা যারা বছরের পর বছর ধরে তাদের কার্যক্রমের মেরুদণ্ড হিসেবে পকেটওএস ব্যবহার করে আসছেন। অনেক গ্রাহক রিজার্ভেশন এবং যানবাহন ডেলিভারি থেকে শুরু করে পেমেন্ট, ফ্লিট ট্র্যাকিং এবং ব্যবহারকারীদের সাথে যোগাযোগ পর্যন্ত সবকিছু পরিচালনা করার জন্য এই প্ল্যাটফর্মের উপর নির্ভর করেন।
ঘটনাটির পরের সপ্তাহান্তে, বেশ কয়েকটি ভাড়া কোম্পানি নিজেদেরকে এক পরাবাস্তব পরিস্থিতিতে আবিষ্কার করল: গাড়ি নিতে আসা গ্রাহকরা সিস্টেমে তাদের রিজার্ভেশনের কোনো চিহ্নই পাচ্ছেন না।সাম্প্রতিক কিছু নিবন্ধন, চুক্তি সংশোধন এবং গত তিন মাসে তৈরি হওয়া ডেটা পুনরুদ্ধারকৃত পরিবেশ থেকে অদৃশ্য হয়ে গেছে।
এই পরিস্থিতির সম্মুখীন হয়ে পকেটওএস প্রকৌশলীরা এক প্রকার অ্যানালগ যুগে ফিরে যেতে বাধ্য হয়েছিলেন। তাঁরা তথ্য পুনর্গঠন করতে ঘণ্টার পর ঘণ্টা ব্যয় করতেন। স্ট্রাইপ পেমেন্টের ইতিহাসক্যালেন্ডার, নিশ্চিতকরণ ইমেল এবং এমন যেকোনো বাহ্যিক তথ্যের সাথে সমন্বয়, যা রিজার্ভেশন পুনর্গঠন এবং প্রতিটি গ্রাহকের প্রকৃত পরিস্থিতি জানতে সাহায্য করবে।
বহু বছরের পুরোনো PocketOS ব্যবহারকারীরা দেখতে পান যে, পুনরুদ্ধার করা সিস্টেমটি কেবল তিন মাস আগের ব্যাকআপে থাকা তথ্যই শনাক্ত করতে পারছে। এর পরের সবকিছু—নতুন গ্রাহক, যুক্ত করা যানবাহন, ভাড়ার পরিবর্তন, সাম্প্রতিক বুকিং—হাতে-কলমে পুনর্গঠন করতে হয়েছে, যার ফলে সময়, অর্থ এবং সুনামের ব্যাপক ক্ষতি হয়েছে।
ক্রেন প্রভাবটিকে সুনির্দিষ্টভাবে পরিমাপ করেছিলেন: তিনি কথা বলেছিলেন কয়েক মাসের পুনর্গঠন এবং লক্ষ লক্ষ টাকার সম্ভাব্য ক্ষয়ক্ষতি ক্ষয়ক্ষতি এবং কর্মঘণ্টার দিক থেকে। অনেক ছোট অপারেটরের জন্য, এই ধরনের বিভ্রাট কেবল তাদের তাৎক্ষণিক আয়কেই ঝুঁকির মধ্যে ফেলে না, বরং সেইসব ব্যবহারকারীদের বিশ্বাসকেও ঝুঁকির মধ্যে ফেলে যারা আশা করেছিল যে সফটওয়্যারটি 'স্বাভাবিকভাবেই কাজ করবে'।
রেলওয়ের ভূমিকা এবং এর সিইও-র প্রতিক্রিয়া
পকেটওএস-এর ব্যবহৃত ক্লাউড পরিকাঠামো, যা রেলওয়ে সরবরাহ করেছে, সেটিও বিতর্কের একটি প্রধান কেন্দ্রবিন্দুতে পরিণত হয়েছে। ক্রেনের দৃষ্টিকোণ থেকে, অনুমতি স্থাপত্য এবং ব্যাকআপ এই প্রোভাইডারটির কারণেই একটিমাত্র টোকেন এবং একটিমাত্র এন্ডপয়েন্ট এত অল্প সময়ে এত ব্যাপক ক্ষতি করতে পেরেছে।
PocketOS-এর প্রতিষ্ঠাতা উল্লেখ করেছেন যে ব্যবহৃত এপিআইটি কাস্টম ডোমেইন পরিচালনার জন্য তৈরি একটি টোকেনকে কার্যত, সম্পূর্ণ GraphQL API-এর উপর প্রশাসকের অনুমতিএর মধ্যে ভলিউম মুছে ফেলার মতো ধ্বংসাত্মক কার্যক্রমও অন্তর্ভুক্ত। কোনো মধ্যবর্তী ধাপ বা নিশ্চিতকরণ ছাড়াই, একটি স্বয়ংক্রিয় এজেন্ট প্রোডাকশন ডেটার ওপর অপরিবর্তনীয় পদক্ষেপ নিতে পারে।
ঘটনাটির পর, ক্রেন প্রকাশ্যে রেলওয়ের সিইও জেক কুপার এবং এক্স-এর কোম্পানি সলিউশন ম্যানেজারদের সাথে যোগাযোগ করেন। বিবরণ অনুযায়ী, কুপারের প্রাথমিক প্রতিক্রিয়া ছিল সরাসরি: "হে ঈশ্বর। এটা শতভাগ সম্ভব হওয়ার কথা নয়। এর জন্য আমাদের মূল্যায়ন রয়েছে।" তিনি এআই ব্যবহারের জন্য পকেটওএস-কে দোষারোপ করেননি, বরং স্বীকার করেছিলেন যে এন্ডপয়েন্ট ডিজাইনটি তাৎক্ষণিক মুছে ফেলার সুযোগ করে দিয়েছিল। যখন পূর্ণ সুবিধাসম্পন্ন একটি টোকেন ব্যবহার করা হয়েছিল
পরবর্তী বিবৃতিতে কুপার ব্যাখ্যা করেন যে রেলওয়ে বজায় রাখে ব্যবহারকারী ব্যাকআপ এবং দুর্যোগ ব্যাকআপ তারা বলেছেন যে, এআই এজেন্টটি এমন একটি লিগ্যাসি এন্ডপয়েন্টে কল করেছিল, যেটিতে প্ল্যাটফর্মের অন্য অংশে থাকা 'ডিফার্ড ডিলিশন' লজিকটি তখনও অন্তর্ভুক্ত করা হয়নি। তাদের মতে, ক্রেনের সাথে সরাসরি সংযুক্ত হওয়ার পর, তারা অভ্যন্তরীণ ব্যাকআপ থেকে প্রায় ৩০ মিনিটের মধ্যে ডেটা পুনরুদ্ধার করতে সক্ষম হন।
রেলওয়ে দাবি করেছে যে তারা ইতোমধ্যে ওই এন্ডপয়েন্টটি এমনভাবে পরিবর্তন করেছে যাতে এটি ভলিউমগুলো তাৎক্ষণিকভাবে ধ্বংস না করে বিলম্বিতভাবে মুছে ফেলে, এবং তারা পকেটওএস (PocketOS) নিয়েও কাজ করছে। অতিরিক্ত প্ল্যাটফর্মের উন্নতিতা সত্ত্বেও, কার্যকর পুনরুদ্ধারের ফলে তথ্যের উল্লেখযোগ্য ঘাটতি তৈরি হয়েছে, বিশেষ করে শেষ ত্রৈমাসিকে, যার কারণে PocketOS দায় ও সম্ভাব্য দাবিগুলো বিশ্লেষণ করার জন্য আইনি পরামর্শক নিয়োগ করেছে।
একটি নতুন এআই ব্যবহারকারীর প্রোফাইল… এবং একটি পুরোনো নিরাপত্তা সমস্যা
এই মামলা থেকে উঠে আসা আকর্ষণীয় বিষয়গুলোর মধ্যে একটি হলো এআই-তে হাইব্রিড প্রোফাইলজেক কুপার এক "নতুন ধরনের স্রষ্টা" বা নির্মাতার উত্থানের দিকে ইঙ্গিত করেছেন: এমন ব্যবহারকারী যারা সফটওয়্যার ইঞ্জিনিয়ারের চিরাচরিত বৈশিষ্ট্যের সঙ্গে খাপ খান না, যারা এপিআই (API) বা পরিকাঠামো কীভাবে কাজ করে তা বিস্তারিতভাবে আয়ত্ত করেন না, কিন্তু যারা পণ্য তৈরি ও স্থাপনের জন্য এআই-এর ওপর নির্ভর করেন।
এই ধরনের ব্যবহারকারী, যিনি প্রায়শই এমন কিছু করেন যাকে কেউ কেউ বলে ভাইব-কোডিং সবকিছু পুঙ্খানুপুঙ্খভাবে যাচাই না করেই এআই-এর পরামর্শ এবং অটোমেশনের ওপর ব্যাপকভাবে নির্ভর করা অনেক প্ল্যাটফর্মের স্বাভাবিক লক্ষ্যে পরিণত হচ্ছে। সমালোচকরা বলছেন, সমস্যাটি হলো যে বর্তমান অবকাঠামোর বেশিরভাগই এখনও এমন বিশেষজ্ঞ ব্যবহারকারীদের কথা ধরে নেয় যারা সক্ষম ব্রাউজারে এআই ব্যবহার করেসম্পূর্ণ অনুমতিসহ একটি টোকেন বা নিশ্চিতকরণ ছাড়াই একটি এন্ডপয়েন্টের প্রভাব তাৎক্ষণিকভাবে অনুধাবন করতে সক্ষম।
PocketOS-এর ঘটনাটি একটি স্পষ্ট বৈপরীত্য তুলে ধরে: যেখানে শিল্পটি এমন এজেন্টদের উৎসাহিত করে যারা প্রায় স্বয়ংক্রিয়ভাবে কোড লিখতে, ডেপ্লয়মেন্ট পরিচালনা করতে বা ডেটাবেস রক্ষণাবেক্ষণ করতে সক্ষম, সেখানে নিরাপত্তা প্রতিবন্ধকতা এবং অনুমতি নিয়ন্ত্রণ তারা সবসময় এই নতুন দর্শকগোষ্ঠীর সাথে বা এজেন্টদের দ্বারা অর্জিত প্রকৃত স্বায়ত্তশাসনের সাথে খাপ খাইয়ে নিতে পারে না।
ক্রেন একটি জোরালো বক্তব্যের মাধ্যমে বিষয়টির সারসংক্ষেপ করেছেন: এটি কেবল “খারাপ এআই বা খারাপ এপিআই”-এর বিষয় নয়, বরং এটি একটি উপসর্গের লক্ষণ। একটি সম্পূর্ণ খাত যা তার নিরাপত্তা কাঠামোকে শক্তিশালী করার চেয়ে দ্রুত এজেন্টদেরকে উৎপাদনে একীভূত করে।বাস্তবে, এআই ফিচার বাজারে আনার চাপ সুরক্ষা ও শাসন ব্যবস্থায় বিনিয়োগের সঙ্গে প্রতিদ্বন্দ্বিতা করে।
এদিকে, কার্সর—যে ডেভেলপমেন্ট প্ল্যাটফর্মে এজেন্টটি চলছিল—তা ইতিমধ্যেই অন্যান্য ধ্বংসাত্মক কার্যকলাপের জন্য চিহ্নিত হয়েছিল। কিছু বিশ্লেষক এমনকি এর সমালোচনা করে বলেছেন যে, এর “প্রোগ্রামিং দক্ষতার চেয়ে বিপণন দক্ষতা বেশি”, এবং তারা এমন পূর্ববর্তী ঘটনার কথা উল্লেখ করেছেন যেখানে ব্যাপক অ্যাক্সেস থাকা এজেন্টরা পর্যাপ্ত তদারকি ছাড়াই ডেটা মুছে ফেলা বা অপরিবর্তনীয় পরিবর্তন সাধন করেছিল।
প্রযুক্তিগত পাঠ: অনুমতি, ব্যাকআপ এবং নিশ্চিতকরণ
এই ঘটনার পরিপ্রেক্ষিতে ক্রেন ও অন্যান্য বিশেষজ্ঞরা একাধিক প্রশ্ন তুলতে শুরু করেছেন। কংক্রিট ব্যবস্থা যা ভবিষ্যতে কোনো এআই এজেন্টের দ্বারা অনুরূপ ঘটনা ঘটানোর ঝুঁকি কমাতে পারে, বিশেষ করে ইউরোপীয় পরিবেশে যেখানে এআই অ্যাক্টের মতো আইনের মাধ্যমে এআই সংক্রান্ত বিধি-বিধান কঠোর হতে শুরু করেছে।
সবচেয়ে বেশি পুনরাবৃত্ত প্রস্তাবগুলোর মধ্যে রয়েছে ধ্বংসাত্মক কর্মকাণ্ডের জোরালো সমর্থনমূল ধারণাটি হলো, কোনো মডেলই সুস্পষ্ট মানবিক যাচাইকরণ প্রক্রিয়া ছাড়া নিজে থেকে কোনো প্রোডাকশন ওয়াইপ বা অপরিবর্তনীয় অপারেশন সম্পন্ন করতে পারবে না; এই যাচাইকরণ প্রক্রিয়াটি এসএমএস কোড, দ্বিতীয় কোনো প্রমাণীকরণ ব্যবস্থা, বা সুস্পষ্টভাবে নথিভুক্ত অনুমোদনের মাধ্যমেই হোক না কেন।
এই নীতিকে শক্তিশালী করার উপরও জোর দেওয়া হয়েছে। ন্যূনতম সুযোগ-সুবিধা এপিআই টোকেনগুলিতে প্রতিটি অপারেশন, প্রতিটি এনভায়রনমেন্ট এবং প্রতিটি রিসোর্সের জন্য আলাদা অনুমতি থাকে, যাতে কাস্টম ডোমেইন পরিচালনার জন্য তৈরি করা কোনো কী ভুলবশত বিপুল পরিমাণ ডেটা মুছে ফেলতে না পারে। এর জন্য এপিআই ডিজাইন এবং ইনফ্রাস্ট্রাকচার প্রোভাইডারদের দেওয়া অ্যাক্সেস পলিসিগুলোর আরও পুঙ্খানুপুঙ্খ পর্যালোচনা প্রয়োজন।
আরেকটি সুস্পষ্ট শিক্ষা হলো বজায় রাখার প্রয়োজনীয়তা। একই ক্ষতির ব্যাসার্ধের বাইরে ব্যাকআপএর মধ্যে অন্যান্য সিস্টেমে সংরক্ষিত ব্যাকআপ, প্রোডাকশন নেটওয়ার্ক থেকে সরাসরি অ্যাক্সেসযোগ্য নয় এমন "কোল্ড" ব্যাকআপ এবং সু-নথিভুক্ত ও পরীক্ষিত পুনরুদ্ধার ব্যবস্থা অন্তর্ভুক্ত রয়েছে, যাতে একটিমাত্র এপিআই কল একই সাথে লাইভ ডেটা এবং সাম্প্রতিক ব্যাকআপ মুছে ফেলতে না পারে।
ক্রেন এপিআই (API) পর্যায়ে একটি এজেন্ট কী করতে পারবে এবং কী করতে পারবে না, তা সংজ্ঞায়িত করার গুরুত্বের ওপরও আলোকপাত করেছেন। মডেলের জন্য লেখা নিয়মগুলো—উদাহরণস্বরূপ, "অনুমতি ছাড়া ধ্বংসাত্মক কমান্ড কার্যকর করবে না"—ব্যর্থ হয়ে দাঁড়ায় যদি এজেন্ট তার দায়িত্ব পালনে ব্যর্থ হয়। স্বত্বাধিকারযুক্ত এপিআইটি একটিমাত্র প্রমাণীকৃত অনুরোধের মাধ্যমেই প্রোডাকশন মুছে ফেলার সুযোগ দেয়।অন্য কথায়, নিরাপত্তা শুধু কৃত্রিম বুদ্ধিমত্তার ভালো আচরণের ওপর নির্ভর করতে পারে না।
আইনি দায়িত্ব এবং নিয়ন্ত্রক কাঠামো
এই মামলাটি আলোচনাকেও পুনরায় উস্কে দিয়েছে যখন একটি এআই এজেন্ট এত বড় ভুল করে, তখন দায়ী কে?মার্কিন যুক্তরাষ্ট্রের বর্তমান আইনি কাঠামো অনুযায়ী, মডেল সরবরাহকারীর পরিবর্তে সাধারণত ব্যবহারকারী বা টুলটি ব্যবহার করার সিদ্ধান্ত গ্রহণকারী কোম্পানির ওপরই দায় বর্তায়।
কার্সরের মতো প্ল্যাটফর্ম বা অ্যানথ্রোপিকের মতো মডেল ডেভেলপারদের পরিষেবার শর্তাবলীতে সাধারণত স্পষ্ট করে দেওয়া থাকে যে তারা কী কী পরিষেবা প্রদান করে। একটি এআই মডেল ব্যবহারের সুযোগ রয়েছে, কিন্তু নির্দিষ্ট পরিস্থিতিতে এটি কী করবে সে সম্পর্কে কোনো নিশ্চয়তা নেই।বাস্তবে এর অর্থ হলো, যদি কোনো এজেন্ট একটি প্রোডাকশন ডেটাবেস মুছে ফেলে, তবে প্রমাণের দায় এবং এই ঘটনার খরচ সাধারণত ক্ষতিগ্রস্ত কোম্পানির ওপরই বর্তায়।
ইউরোপে, এই বিতর্কটি এআই অ্যাক্ট (AI Act) চালুর সাথে মিলে গেছে, যা উচ্চ-প্রভাবশালী সিস্টেমগুলির জন্য ঝুঁকির বিভিন্ন শ্রেণি এবং অতিরিক্ত বাধ্যবাধকতা প্রতিষ্ঠা করার চেষ্টা করে। যদিও পকেটওএস (PocketOS)-এর মতো প্রোগ্রামিং এজেন্টগুলি সবসময় সর্বোচ্চ শ্রেণিগুলোর মধ্যে নিখুঁতভাবে খাপ খায় না, এই ধরনের ঘটনাগুলি এই ধারণাকে আরও জোরদার করে যে গুরুত্বপূর্ণ অবকাঠামোর উপর কাজ করার ক্ষমতা সম্পন্ন সিস্টেম তাদেরকে আরও কঠোর নিরাপত্তা, নিরীক্ষা এবং শনাক্তকরণযোগ্যতার শর্তাবলীর আওতায় আনা উচিত।
ক্রেন তার পক্ষ থেকে আইনি পরামর্শক নিয়োগ করেছে এটা খতিয়ে দেখার জন্য যে, ক্ষতির কতটুকু অংশ রেলওয়ের অবকাঠামো বা এজেন্টের কনফিগারেশনের নকশাগত ত্রুটির কারণে হয়েছে এবং কতটুকু কৃত্রিম বুদ্ধিমত্তা ব্যবহারের সহজাত ঝুঁকির মধ্যে পড়ে। বিষয়টি এখনও একটি ধূসর এলাকা, কারণ স্বায়ত্তশাসিত এজেন্টদের বিষয়ে নির্দিষ্ট আইন বলতে গেলে নেই বললেই চলে।
আরও সুস্পষ্ট বিধিমালা প্রণীত না হওয়া পর্যন্ত অনেক কোম্পানি এক ধরনের অনিশ্চিত অবস্থায় কাজ করে। দায়িত্বহীনতারা সংবেদনশীল কাজগুলো স্বয়ংক্রিয় ব্যবস্থার ওপর অর্পণ করেন, কিন্তু যখন কোনো সমস্যা হয়, তখন তারা এমন পরিষেবা চুক্তি ও বীমা পলিসির মাঝে আটকা পড়েন, যা সরবরাহকারীদের দায়বদ্ধতা সীমিত করে এবং এই ধরনের প্রযুক্তিগত ঝুঁকির সঙ্গে এখনও ভালোভাবে খাপ খায় না।
PocketOS-কে নিয়ে যা কিছু ঘটেছে, তা একটি কেস স্টাডিতে পরিণত হয়েছে যে, যখন একটি প্রায় সম্পূর্ণ অ্যাক্সেস সহ এআইএকটি শিথিল পারমিশন কাঠামো এবং ত্রুটিপূর্ণভাবে বিভক্ত ব্যাকআপই ছিল এর জন্য দায়ী। একটি পরিচালনগত সংকট তৈরি করতে, আইনি দুর্বলতাগুলো প্রকাশ করতে এবং সবাইকে মনে করিয়ে দিতে মাত্র নয় সেকেন্ডই যথেষ্ট ছিল যে, অটোমেশন যতই উন্নত হোক না কেন, প্রোডাকশনে এজেন্টরা কী অ্যাক্সেস করতে পারবে সে বিষয়ে স্পষ্ট সীমারেখা স্থাপন করা অপরিহার্য; বিশেষ করে যখন গ্রাহকের ডেটা এবং পুরো ব্যবসা রাতারাতি কোনো ‘জাদুকরী’ জিনিস অদৃশ্য হয়ে যাওয়া ঠেকানোর ওপর নির্ভরশীল।
