যে AI নিজে কাজ করে, তাকে সামলানোর উপায়: ন্যূনতম অধিকার, ফেরানোর সুযোগ ও অঙ্কভিত্তিক অনুমোদন ম্যাট্রিক্স, মেকার-চেকার, কিল সুইচ, অডিট রেকর্ড, প্রম্পট ইনজেকশন প্রতিরোধ, আর ২০২৬-এ ইইউ AI অ্যাক্ট, ISO 42001 ও NIST কী চায়।
Author
Anichur Rahaman
রাতারাতি ৩৭টি refund অনুমোদন হয়ে গেছে, মোট ৮,৪০০ ডলার, আর প্রতিটাই সীমার ভেতরে। ১২টি outlet-এর এক খুচরা বিক্রেতা গত মাসে যে support agent চালু করেছে, সে একবারে ৩০০ ডলার পর্যন্ত refund দিতে পারে, কিন্তু দিনের মোট সীমা সেটআপে কোথাও বাঁধা ছিল না।
মাঝরাতের পর ক্ষতিগ্রস্ত parcel-এর দাবি নিয়ে একের পর এক মেসেজ এল, প্রতিটাই ভদ্র আর বিশ্বাসযোগ্য, আর agent একটার পর একটা অনুমোদন দিয়ে গেল। মঙ্গলবার সকালে ফাইন্যান্স প্রধান মোট অঙ্কটা দেখতে পান। দৃশ্যটা কাল্পনিক উদাহরণ, তবে প্রতিটা ধাপ এমন সীমার খুবই চেনা ব্যর্থতা, যা একবারে একটা কাজই যাচাই করে।
agent ঠিক তা-ই করেছে, যা তার prompt অনুমতি দিয়েছিল, আর prompt-ই ছিল একমাত্র বেড়া। prompt একটা অনুরোধ মাত্র, আর অনুরোধ উপেক্ষা করা যায়, ভুল বোঝা যায়, কিংবা অচেনা কারও চালাক বার্তা দিয়ে উল্টে দেওয়া যায়। আসল নিরাপত্তা আসে model-এর বাইরে বসানো নিয়ন্ত্রণ থেকে: permission, সীমা, অনুমোদন, rate limit আর record। model ভালো আচরণ করুক বা না করুক, এগুলো একইভাবে কাজ করে।
এই লেখা সেই নিয়ন্ত্রণগুলোর নকশা-গাইড। কে কী অনুমোদন করবে, কাজ কীভাবে বারবার চালালেও নিরাপদ রাখবেন, audit রেকর্ডে কী কী থাকতে হবে, ক্ষতিকর টেক্সট থেকে কীভাবে বাঁচবেন, আর ২০২৬ সালের সেপ্টেম্বরের শুরুতে ইইউ, ISO ও NIST-এর নিয়ম একটা সাধারণ ব্যবসার কাছে কী চায়, সবই এখানে পাবেন।
এটি “অপারেশনে AI, ২০২৬” সিরিজের তৃতীয় ও শেষ পর্ব। প্রথম পর্বে ছিল ERP-র ভেতরে AI agent নিরাপদে কী করতে পারে। দ্বিতীয় পর্বে ছিল MCP কীভাবে ব্যবসার data-র সঙ্গে AI-কে নিরাপদে জোড়ে। এই শেষ পর্ব মানুষের হাতে নিয়ন্ত্রণ রাখার কথা নিয়ে।
ল্যাঙ্গুয়েজ মডেল পরের শব্দ অনুমান করে করে সিদ্ধান্ত নেয়। বেশির ভাগ সময় ঠিক, কখনো কখনো আত্মবিশ্বাসের সঙ্গে ভুল, আর কোন দিন কোনটা হবে, তার নিশ্চয়তা কেউ দিতে পারে না। মডেল আর আপনার payment system-এর মাঝখানে যদি শুধু একটা বাক্য থাকে, “৫০ ডলারের বেশি refund কখনো নয়”, সেটা নিয়ন্ত্রণ নয়, ভরসা।
নিয়ন্ত্রণ মানে এমন কিছু, যা মডেল কথার প্যাঁচে এড়াতে পারে না। refund টুল নিজেই সীমার ওপরের অঙ্ক ফিরিয়ে দেয়। অনুমোদনের ধাপ agent টপকাতে পারে না। agent-এর account-এ বেতন-ভাতার data ছোঁয়ার অধিকারই নেই। এই নিয়মগুলো সাদামাটা, নির্ধারিত কোড, আর ঠিক সেই কারণেই কাজ করে।
নতুন কর্মী নিলে আপনি যা করেন, এটাও তা-ই। নতুন লোক পায় সীমিত অ্যাক্সেস, খরচের সীমা আর বড় সিদ্ধান্তে সই করার একজন ম্যানেজার। শুধু তার সদিচ্ছার ওপর ভরসা করেন না, agent-এর ক্ষেত্রেও করা উচিত নয়।
প্রতিটি agent-কে তার কাজের নামে আলাদা account দিন, যেমন “purchasing-agent”। কোনো মানুষের login বা শেয়ার করা admin key কখনো ধার দেবেন না। তারপর কাজের জন্য যতটুকু দরকার, শুধু ততটুকু permission দিন।
আলাদা পরিচয়ের সুফল পরেও মেলে। কিছু অস্বাভাবিক লাগলে log বলে দেবে “purchasing-agent এটা করেছে মারিয়ার হয়ে”, আর বাকি কাউকে না থামিয়েই আপনি শুধু ওই একটা পরিচয় বন্ধ করে দিতে পারবেন।
প্রথম পর্বে agent-এর কাজকে চার স্তরে ভাগ করা হয়েছিল, উত্তর দেওয়া থেকে শুরু করে টাকা সরানোর মতো অফেরতযোগ্য কাজ পর্যন্ত। বাস্তবে আরেকটা অক্ষও লাগে: কাজটা কত বড়? ৮ ডলারের refund আর ৮,০০০ ডলারের refund একই ধরনের কাজ, কিন্তু একই মাপের ঝুঁকি নয়।
দুটো অক্ষ মিলিয়ে একটা ম্যাট্রিক্স বানান এবং লিখে রাখুন। নিচের অঙ্কগুলো উদাহরণ মাত্র। আপনার সীমা ঠিক করুন ভুল হলে ক্ষতি কত হবে তা দেখে, ছকটা সুন্দর দেখায় কি না তা দেখে নয়।
matrix কাজে লাগাতে তিনটা অভ্যাস দরকার। ছকের কোন ঘরে কাজটা পড়বে, তা code দিয়ে ঠিক করুন, model-কে জিজ্ঞেস করে নয় যে তার কাছে কতটা ঝুঁকিপূর্ণ মনে হচ্ছে। অনুমোদনকারীর কাছে কাজটা পাঠান proposal হিসেবে, যাতে স্পষ্ট থাকে এখনো কিছু ঘটেনি। আর অনুমোদনের মুহূর্তে অঙ্কটা আবার মিলিয়ে নিন, কারণ অনুরোধ আর ক্লিকের মাঝে cart বা draft বদলে যেতে পারে।
পুরো পথটা ধরলে matrix-টা চার দরজার একটা flow হয়ে দাঁড়ায়। প্রতিটা বেরোনোর পথ, প্রত্যাখ্যানসহ, একটা record রেখে যায়।
হিসাবরক্ষকেরা বহু প্রজন্ম ধরে maker-checker নিয়ম মানেন: যিনি payment তৈরি করেন, তিনি তা ছাড়েন না। agent-এর বেলায়ও একই ভাগাভাগি করুন। agent সব সময় maker। checker একজন মানুষ, আর সবচেয়ে ঝুঁকিপূর্ণ ঘরে দুজন। টাকার ব্যাপারে এক agent আরেক agent-এর কাজের checker হবে না, কখনোই না।
checker যা দেখতে পান, শুধু তা-ই যাচাই করতে পারেন। তাই প্রতিটা প্রস্তাবের সঙ্গে একটা পরিষ্কার preview থাকা চাই:
approval-এর ক্লান্তি থেকে সাবধান। দিনে দুশো item approval করতে বললে মানুষ না দেখেই ক্লিক করে যাবে। approval রাখুন শুধু যে ঘরগুলো গুরুত্বপূর্ণ সেখানে, কম ঝুঁকির কাজগুলো দিনের শেষে sample-reviewed-তে জড়ো করুন, আর approver-রা কত বার সম্পাদনা বা বাতিল করছেন তা খেয়াল রাখুন। যে approval সিল কখনো বাতিল করে না, সেটা সাফল্য নয়, সতর্কসংকেত।
agent আবার চেষ্টা করে। network timeout হয়, job restart হয়, আর model মাঝে মাঝে একই tool দুবার ডাকে। “purchase order তৈরি করো” দুবার চললে আপনি দুবার কিনে ফেলেন।
সমাধান idempotency key: প্রতিটি প্রস্তাবিত কাজের সঙ্গে জুড়ে দেওয়া একটা অনন্য reference। system মনে রাখে কোন key-র কাজ শেষ হয়েছে, আর একই key ফিরে এলে চুপচাপ সেটা বাদ দেয়। supplier-এর duplicate invoice, double refund, বারবার stock transfer, এই একটা অভ্যাসেই আটকে যায়।
এর পাশে আরও তিনটা brake রাখুন:
কিছু ভুল হলে পাঁচটা প্রশ্নের উত্তর দ্রুত লাগে: কে চেয়েছিল, agent কী দেখেছিল, কী করেছিল, কোন model সিদ্ধান্তটা নিয়েছিল, আর কে approval দিয়েছিল। log পাঁচটারই উত্তর না দিতে পারলে investigation করা যায় না, আর গ্রাহক, auditor বা regulator সংস্থাকে কী ঘটেছিল তাও প্রমাণ করা যায় না।
কাজে লাগার মতো log আর শুধু দেখানোর log-এর মধ্যে তিনটা খুঁটিনাটি পার্থক্য গড়ে দেয়। record লিখুন কাজ proposal করার সময়, শুধু শেষ হওয়ার পর নয়, তাহলে failed ও rejected কাজও চোখে পড়বে। model-এর নাম ও version রাখুন prompt বা policy-র version-সহ, কারণ দুটোর যেকোনোটা বদলালে behavior বদলায়। আর record রাখুন tampering-এর বিরুদ্ধে সুরক্ষিত: শুধু append-করা যায় এমন storage, অন্তত এমন নিয়ম যে agent বা তার administrator history edit করতে পারবে না।
গোপনীয়তার দিকটাও ভাবুন। গ্রাহকের পুরো বার্তা জমানো লগ নিজেই সংবেদনশীল data। যেখানে পারেন রেফারেন্স আর ছোট অংশ রাখুন, সংরক্ষণের মেয়াদ ঠিক করুন, আর কারা পড়তে পারবে তা সীমিত করুন।
দ্বিতীয় পর্বে prompt injection-এর কথা ছিল: email, review বা product-এর বিবরণে লুকানো এমন লেখা, যা model-কে এমন কিছু করতে বলে যা মালিক কখনো চায়নি। LLM application-এর OWASP Top 10 একে প্রথম jeopardy হিসেবে রেখেছে। কোনো filter এটা পুরোপুরি দূর করে না, তাই ধরে নিয়েই design করুন যে কিছু injection কাজ করবেই।
model, prompt, tool আর আপনার নিজের data, সবই বদলায়, আর যেকোনোটি agent-এর behavior চুপিসারে পাল্টে দিতে পারে। তাই launch-এর আগে একটা ছোট evaluation set বানান: পঞ্চাশ থেকে কয়েকশো real বা realistic case, প্রতিটার expected answer-সহ। সঙ্গে রাখুন tricky case-ও, যেমন duplicate order, missing data, angry customer আর injection attempt।
model, prompt বা permission বদলালেই সেটটা আবার চালান। আগের result-এর সঙ্গে মিলিয়ে দেখুন, আর number একই থাকলে বা improve হলে তবেই change deploy করুন। software-র regression testing-এর idea-ই, শুধু application-টা behavior-এর ওপর।
launch-এর পর প্রতি সপ্তাহে কয়েকটা metric দেখুন: proposal acceptance rate, rejection reason, action blocked by policy, cost per action, আর customer বা supplier পর্যন্ত পৌঁছে যাওয়া error। rollback-ও আগেভাগে ভেবে রাখুন। প্রতিটা action type-এর জন্য জানুন কীভাবে undo করবেন, কে করবেন আর কত সময় আছে। উত্তর যদি হয় “এটা undo করা যাবে না”, তাহলে কাজটা থাকবে শুধু human-only ঘরে।
বাড়তে থাকা ব্যবসার বেশির ভাগ অপারেশনাল AI ব্যবহার, যেমন stock-এর প্রশ্ন, ক্রয়ের খসড়া আর invoice মেলানো, ইইউ AI অ্যাক্টে “উচ্চ-ঝুঁকি” বলে ধরা হয় না। তার মানে এই নয় যে কিছুই করার নেই। ২০২৬ সালের সেপ্টেম্বরের শুরুতে অবস্থাটা এ রকম।
| কাঠামো | অবস্থা | আপনার জন্য মানে |
|---|---|---|
| ইইউ AI অ্যাক্ট, স্বচ্ছতা (ধারা ৫০) | ২ আগস্ট ২০২৬ থেকে প্রযোজ্য। বাজারে আগে থেকে থাকা system-এর AI-তৈরি কনটেন্ট চিহ্নিত করার ক্ষেত্রেই শুধু ২ ডিসেম্বর ২০২৬ পর্যন্ত ছোট বাড়তি সময় আছে। | কেউ AI-র সঙ্গে কথা বললে তাকে জানান, আর যেখানে দরকার সেখানে কৃত্রিম কনটেন্টে লেবেল দিন। |
| ইইউ AI অ্যাক্ট, উচ্চ-ঝুঁকির system (অ্যানেক্স III) | ২০২৬ সালের মে মাসে সম্মত এবং জুনে পার্লামেন্ট ও কাউন্সিল গৃহীত ডিজিটাল ওমনিবাস অন AI তারিখ ২ আগস্ট ২০২৬ থেকে সরিয়ে ২ ডিসেম্বর ২০২৭ করেছে। ইইউ পণ্য-নিরাপত্তা আইনের আওতাধীন পণ্যের তারিখ ২ আগস্ট ২০২৮। | নিয়োগ, কর্মী মূল্যায়ন, ঋণ বা অত্যাবশ্যক সেবা পাওয়ার সিদ্ধান্তে AI ব্যবহার করলে প্রযোজ্য। লগ, মানুষের তদারকি ও রেকর্ড লাগবে। |
| ISO/IEC 42001:2023 | ডিসেম্বর ২০২৩-এ প্রকাশিত। AI-র জন্য সার্টিফিকেশনযোগ্য ম্যানেজমেন্ট-system স্ট্যান্ডার্ড। | ঐচ্ছিক। নীতি, ভূমিকা, ঝুঁকি পর্যালোচনা ও উন্নয়নের কাজের কাঠামো হিসেবে দরকারি, আর বড় গ্রাহকদের কাছে একটা বিশ্বাসযোগ্যতার সংকেত। |
| NIST AI Risk Management Framework 1.0 | জানুয়ারি ২০২৩-এ প্রকাশিত, ২০২৪ সালের জুলাইয়ে জেনারেটিভ AI প্রোফাইলসহ। স্বেচ্ছাভিত্তিক। | ধার করার মতো চারটা কাজ: govern, map, measure, manage। |
দুটো সতর্কতা। এই ধরনের নিয়মের তারিখ ইতিমধ্যে একবার সরেছে, আর চূড়ান্ত পাঠের সারসংক্ষেপগুলো এখনো ভিন্ন ভিন্ন ভাষায় লেখা হচ্ছে, তাই কোনো তারিখের ওপর ভরসা করার আগে সরকারি পাঠ দেখে নিন বা পরামর্শ নিন। আর স্থগিত মানে বাতিল নয়: বাধ্যবাধকতা থেকেই যাচ্ছে, আর এই লেখার অভ্যাসগুলো, অর্থাৎ লগ, তদারকি ও লিখিত সীমা, উচ্চ-ঝুঁকির নিয়ম ঠিক এগুলোই চায়।
কম ঝুঁকির ব্যবহারেও দুটো কাজ লাগে: কেউ AI-র সঙ্গে কথা বললে তাকে জানানো, আর রেকর্ড রাখা। স্ট্যান্ডার্ডগুলো নিজে দেখতে চাইলে ISO/IEC 42001-এর ISO পেজ আর NIST AI Risk Management Framework দেখুন। ইইউর বাইরে দেশে দেশে নিয়ম আলাদা এবং বদলাচ্ছে, তাই আপনি যেখানে বিক্রি করেন সেখানকার নিয়ম দেখে নিন।
আপনার নিয়মগুলো এক পাতায় রাখুন, যা কর্মী, vendor আর audit-র সবাই পড়তে পারবেন। নিচে উদাহরণ-মানসহ একটা template। প্রতিটা সংখ্যা নিজের ঝুঁকি অনুযায়ী বদলে নিন।
| কাজ | agent যা পারবে | সীমা | অনুমোদন | ফেরানো |
|---|---|---|---|---|
| stock ও order-এর প্রশ্নের উত্তর | শুধু পড়া | নিজের ভূমিকার data | লাগবে না | দরকার নেই |
| ক্রয় order-এর খসড়া | খসড়া তৈরি | দিনে ২০টি খসড়া | পাঠানোর আগে ক্রেতা অনুমোদন করবেন | খসড়া মুছে ফেলা |
| order-এ ট্যাগ বা রিজার্ভ | বদলানো | ২০০ ডলারের কম order, ঘণ্টায় ৫০টি | প্রতিদিন নমুনা পর্যালোচনা | এক ক্লিকে ফিরিয়ে দেওয়া |
| গ্রাহকের উত্তরের খসড়া | খসড়া তৈরি | refund বা ক্ষতিপূরণের প্রতিশ্রুতি নয় | agent নিজে কিছু পাঠাবে না | পাঠানোই হয়নি |
| refund | শুধু প্রস্তাব | ১,০০০ ডলার পর্যন্ত একজন অনুমোদনকারী, তার বেশি হলে দুজন | সব সময় মানুষ | payment প্রদানকারীর মাধ্যমে ফেরত |
| সরবরাহকারীকে payment, বেতন, ledger পোস্টিং, মুছে ফেলা | কিছুই না | অনুমোদিত নয় | শুধু মানুষ | প্রযোজ্য নয় |
নীতিটা প্রতি প্রান্তিকে এবং প্রতিটি ঘটনার পর পর্যালোচনা করুন। প্রমাণ সমর্থন করলে একটা সারিকে এক ধাপ ওপরে তুলুন। কোনো vendor-এর স্লাইড বলছে বলে কখনো তুলবেন না।
সেই মঙ্গলবারে ফেরা যাক। এই নিয়ন্ত্রণগুলো থাকলে প্রতিটা refund হতো মানুষের অপেক্ষায় থাকা একটা প্রস্তাব, refund-এর দৈনিক মূল্যসীমা প্রথম কয়েকটার পরই চালানো থামিয়ে দিত, আর প্রস্তাবগুলো একই ছাঁচের হয়ে উঠতে শুরু করলে সার্কিট ব্রেকার agent-কে থামিয়ে দিত। ফাইন্যান্স প্রধান পেতেন একটা থামার সতর্কবার্তা আর দেখে নেওয়ার মতো ছোট একটা তালিকা, ৮,৪০০ ডলারের সমস্যা নয়। agent আগের মতোই সক্ষম। শুধু তার সবচেয়ে খারাপ রাতটা এখন একটা সীমার ভেতরে বাঁধা।
আনিছুর রহমান একজন সফটওয়্যার আর্কিটেক্ট এবং StoreConsole-এর নির্মাতা। বাড়তে থাকা ব্যবসার জন্য তিনি কমার্স ও ERP সিস্টেম ডিজাইন করেন — বিশেষ মনোযোগ event-driven আর্কিটেকচার, ডেটার নির্ভুলতা আর নিজের সার্ভারে চালানো সিস্টেমের ওপর।
About the Author
Anichur Rahaman
Continue Reading
