AI agent-এর প্রতিটি কাজে approval দেবেন না—ঝুঁকি অনুযায়ী gate বসান
এন্টারপ্রাইজ AI agent-এর প্রতিটি কাজে অনুমোদন চাইবেন না। প্রস্তাবিত কাজের সম্ভাব্য ক্ষতি, প্রভাবের পরিধি এবং আগের অবস্থায় ফেরার সুযোগ বিচার করে সেটিকে স্বয়ংক্রিয় চালনা, চালানোর পর পর্যালোচনা অথবা কার্যকর করার আগে বাধ্যতামূলক মানব-অনুমোদন—এই তিন gate-এর একটিতে পাঠান।
কম ঝুঁকির অনুমোদিত read স্বয়ংক্রিয় হতে পারে; সীমিত ও সহজে ফেরানো যায় এমন পরিবর্তন audit-সহ চলার পর review queue-তে যেতে পারে; কিন্তু payment, privilege change, hard delete বা গুরুত্বপূর্ণ external communication আগে থামবে। AWS-এর critical-decision guidance বলছে, প্রতিটি action মানুষের কাছে পাঠালে reviewer fatigue ও rubber-stamp approval তৈরি হয়; তাদের সুপারিশ হলো deterministic risk classification, যথেষ্ট decision context, নির্দিষ্ট timeout, escalation এবং audit log।
Gate বাছতে চারটি প্রশ্ন করুন
Action-এর নাম একা ঝুঁকি নির্ধারণ করে না। Public documentation পড়া এবং payroll database পড়া—দুটিই read, কিন্তু data sensitivity ও সম্ভাব্য ক্ষতি এক নয়। একইভাবে staging-এর পুনর্গঠনযোগ্য file মুছে ফেলা আর production backup মুছে ফেলা একই delete class হলেও এক gate-এ রাখা যাবে না।
- Authority: agent শুধু তথ্য দেখছে, নাকি system of record, configuration, access অথবা বাইরের কোনো resource বদলাচ্ছে?
- Blast radius: প্রভাব একটি record বা account-এ সীমিত, নাকি বহু customer, tenant অথবা পুরো production environment-এ ছড়াবে?
- Reversibility: নির্ভরযোগ্য rollback আছে এবং সেটি পরীক্ষা করা হয়েছে, নাকি action শেষ হলে ক্ষতি আর পুরোপুরি ফেরানো যাবে না?
- External consequence: কাজটি কি অর্থ ব্যয়, বার্তা প্রকাশ, অধিকার পরিবর্তন, ব্যক্তিগত তথ্য উন্মুক্ত করা বা আইনগত দায় তৈরি করবে?
চার প্রশ্নের উত্তরে তিনটি কার্যকর outcome দিন। Low risk হলে policy মেনে auto-run; মাঝারি ঝুঁকি, ছোট scope ও পরীক্ষিত rollback থাকলে execute-and-review; উচ্চ ঝুঁকি বা সীমিত reversibility হলে pre-execution approval। অনুমোদন দিয়েও গ্রহণযোগ্য করা যায় না—এমন নিষিদ্ধ target, credential বা action-এর জন্য আলাদা deny rule রাখুন।
এই classification একটি policy engine বা rule-based service-এর authoritative সিদ্ধান্ত হওয়া উচিত। Agent ঝুঁকি সম্পর্কে ব্যাখ্যা দিতে পারে, কিন্তু যে request সে নিজেই তৈরি করেছে, সেটির tier কমানোর চূড়ান্ত ক্ষমতা তাকে দেবেন না। সময়, request frequency, environment, data class ও সাম্প্রতিক anomaly-ও static action class-এর সঙ্গে বিবেচনা করুন।
পাঁচ action class-এর deploy-ready matrix
- Read: অনুমোদিত non-sensitive source auto-run করুন। ব্যক্তিগত, আর্থিক, স্বাস্থ্য, secret বা cross-tenant data হলে data owner বা security reviewer-এর pre-approval নিন। Evidence bundle-এ query scope, data classification, purpose ও masking rule দিন; sensitive read timeout হলে deny হবে। Audit-এ principal, queried resource, returned data class ও policy rule রাখুন। তথ্য প্রকাশ হয়ে গেলে কার্যকর rollback নেই।
- Write: sandbox, draft বা version-controlled ছোট পরিবর্তন validation শেষে execute-and-review হতে পারে। Production record, access policy বা বড় batch update-এর আগে service owner অনুমোদন দেবেন। Request-এ exact target, affected-object count, before-and-after diff, validation result ও rollback version রাখুন; timeout হলে production write block করুন। Audit-এ change identifier, approved diff hash, execution result ও rollback result লিখুন।
- Communicate: internal draft তৈরি স্বয়ংক্রিয় হতে পারে, কিন্তু send-কে আলাদা action ধরুন। আগে থেকে অনুমোদিত template ও ছোট recipient scope-এর routine notice policy অনুযায়ী চলতে পারে; customer, regulator, public channel বা personalised bulk message communications বা business owner দেখবেন। পূর্ণ message, recipient list, attachment ও sending identity evidence হিসেবে দিন। পাঠানো message পুরোপুরি ফেরানো যায় না, তাই timeout-এ deny এবং send-এর আগে recipient validation রাখুন।
- Spend: অনুমোদিত vendor, purpose, সময়সীমা ও কঠোর ceiling-এর মধ্যে transaction policy চলতে পারে। নতুন vendor, recurring commitment, ceiling অতিক্রম বা payment release budget owner এবং প্রয়োজনমতো finance reviewer-এর আগে থামবে। Amount, currency, vendor identity, fee, budget code ও cancellation terms ছাড়া সিদ্ধান্ত চাইবেন না। Audit-এ authorization, payment reference ও cancellation বা void ফল রাখুন।
- Delete: cache বা পুনর্গঠনযোগ্য artifact soft-delete করে quarantine window-তে পাঠানো যেতে পারে। Production data, backup, audit record বা বহু object-এর hard delete-এর জন্য data owner-এর সঙ্গে operations বা security approver রাখুন। Exact target list, dependency check, retention rule, backup status ও পরীক্ষিত restore location দেখাতে না পারলে action deny করুন; audit-এ deleted-object manifest ও restore test reference রাখুন।
এটি baseline, সর্বজনীন threshold নয়। স্থানীয় আইন, sector regulation, customer contract ও প্রতিষ্ঠানের risk appetite অনুযায়ী amount, object count, data class এবং approver separation নির্ধারণ করুন। Agent যেন নিজের tier, target, evidence অথবা approver বদলাতে না পারে।
Approval request-কে সিদ্ধান্তযোগ্য ও action-bound করুন
Reviewer-এর সামনে শুধু “Allow” ও “Deny” রাখলে অর্থপূর্ণ নিয়ন্ত্রণ হয় না। Request-এ immutable request ID, initiating user ও agent identity, tool বা function, resolved parameters, target environment, affected resources, expected consequence, matched policy, validation result, risk tier, expiry এবং rollback instruction দেখান। Secret value প্রকাশ না করে credential-এর scope জানান।
Approval-কে exact action, parameters, target, policy version ও expiry-এর সঙ্গে bind করুন; কোনোটি বদলালে নতুন approval লাগবে। Microsoft Agent Governance Toolkit-এর প্রস্তাবিত ADR action digest, verified approver identity, expiry, একবার ব্যবহারযোগ্য resolution এবং execution-এর ঠিক আগে পুনরায় validation-এর একটি নির্দিষ্ট নকশা দিয়েছে; এটি প্রস্তাবিত protocol, প্রতিষ্ঠিত মান নয়।
Approve, reject এবং edit-and-resubmit outcome রাখুন। Reviewer target বা parameter সম্পাদনা করলে পুরোনো approval ব্যবহার করে সরাসরি execution নয়—পরিবর্তিত action আবার policy evaluation ও approval-এর মধ্য দিয়ে যাবে। এতে harmless preview দেখিয়ে পরে বেশি ক্ষমতাসম্পন্ন operation চালানোর সুযোগ সংকুচিত হয়।
Singapore IMDA-এর agentic AI framework agent-এর autonomy, tool ও data access আগে থেকে সীমিত করতে এবং গুরুত্বপূর্ণ checkpoint-এ human approval রেখে মানুষকে চূড়ান্তভাবে accountable রাখতে বলেছে। তাই approver-এর পরিচয় ও authority যাচাই করুন; agent-এর recommendation-কে মানব-অনুমোদন হিসেবে গণ্য করবেন না।
Timeout, rollback ও escalation policy-র অংশ করুন
Pending approval অনির্দিষ্ট queue-তে রাখবেন না। প্রতিটি gate-এর expiry, default outcome ও escalation role আগে লিখুন। Execute-and-review item-এর review window শেষ হলে alert বা trust grant স্থগিত করা যেতে পারে; pre-execution high-risk action timeout হলে সাধারণভাবে fail closed হবে।
Primary reviewer অনুপস্থিত থাকলে একই authority-র নির্ধারিত secondary role-এ request যাবে। জরুরি production response-এর জন্য আলাদা break-glass path রাখা যায়, তবে সেখানে নামযুক্ত on-call approver, সীমিত scope, স্বল্পমেয়াদি permission, লিখিত কারণ এবং বাধ্যতামূলক পরবর্তী review প্রয়োজন। Agent নিজে emergency ঘোষণা করে এই পথ নিতে পারবে না।
Rollback class অনুযায়ী আলাদা হবে: write-এর জন্য prior version ও idempotency key, spend-এর জন্য cancellation বা authorization-void path এবং delete-এর জন্য verified restore location। Communication-এর ক্ষেত্রে preview, recipient validation ও সম্ভব হলে ছোট cancel window-ই প্রধান সুরক্ষা, কারণ delivery-এর পর নির্ভরযোগ্য rollback থাকে না।
Audit record দিয়ে gate-এর কার্যকারিতা মাপুন
প্রতিটি decision-এর জন্য request ID, request ও response timestamp, initiating principal, agent ও version, tool, parameter বা action digest, target environment, data classification, risk tier, matched policy rule, approver identity ও role, decision, reason code, expiry, escalation, execution result এবং rollback result সংরক্ষণ করুন। Log এমন সুরক্ষিত বা append-only store-এ পাঠান যেখানে agent record বদলাতে পারবে না।
Approval count সাফল্যের মাপকাঠি নয়। কোন rule-এ reject, edit, timeout, escalation বা rollback বেশি হচ্ছে, সেটি দেখুন। একই সংকীর্ণ action বারবার clean validation ও audit trail দিলে নির্দিষ্ট command, parameter shape ও resource-এ সীমিত, revocable trust grant বিবেচনা করা যায়; wildcard approval নয়। নতুন target, বড় scope, অস্বাভাবিক সময়, policy mismatch বা rollback failure দেখা দিলে gate কঠোর করুন।
বাস্তবায়ন শুরু করুন tool-call inventory দিয়ে: প্রতিটি call-কে read, write, communicate, spend বা delete label দিন, চার risk question-এর উত্তর নথিবদ্ধ করুন এবং প্রথমে irreversible ও externally consequential action fail-closed করুন। এরপর sandbox-এ approve, reject, timeout, parameter mutation, duplicate execution, escalation ও rollback পরীক্ষা করে সীমিত production rollout দিন। এভাবে মানুষের মনোযোগ সেই সিদ্ধান্তে থাকে, যেখানে ভুলের ক্ষতি বড় এবং ফেরার পথ সবচেয়ে সংকীর্ণ।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।