Operations-এ AI Guardrails: Proposal, মোট Limit ও Actual Outcome যাচাই

রাতের মধ্যে 37টি refund হয়ে গেছে, মোট 8,400। প্রতিটিই assistant-এর প্রতি action-এর 300 limit-এর নিচে; সব মিলিয়ে কোনো limit ছিল না। এটি কাল্পনিক failure, সব amount একই অনির্দিষ্ট currency-তে। কিন্তু ফাঁকটি পরিচিত: এক request যাচাই করলেই পুরো run নিয়ন্ত্রিত হয় না।

Finance lead-কে কী ঘটেছে বুঝে নতুন exposure থামাতে হবে; একই সময়ে বৈধ customer case-ও সময়মতো দেখতে হবে। “Model-কে সাবধান হতে বলুন” এই control দিতে পারে না। Assistant message ভুল বুঝলেও permission, approval ও transaction rule কাজ করতে হবে।

এটি তিন পর্বের শেষ লেখা। প্রথম পর্বে agent-এর উপযুক্ত কাজ, দ্বিতীয়তে MCP connection। এখানে একটি proposed action-কে এমন control process-এ নেব, যা দেখা ও পরীক্ষা করা যায়।

Threshold বাছার আগে সীমা লিখুন

প্রতি task-এর owner, permitted record/field, allowed operation, money/customer impact ও recovery path লিখুন। Conversational agent user rights, delegated tool scope ও current policy-র মিলিত অনুমতির মধ্যে কাজ করে। Unattended service-এর limited identity, owner ও review চাই। কোনোটিই shared admin login পাবে না।

Control application ও downstream service-এ থাকবে। Menu লুকানো বা model-কে বাক্য মেনে চলতে বলা যথেষ্ট নয়। প্রতি tool call, retrieved context, cache, output ও log-এ access check দিন। Internal note ও external message—দুটিতেই hostile instruction থাকতে পারে; কোনোটি নতুন authority দিতে পারে না।

বাস্তব loss ও legal/business obligation দেখে limit ঠিক করুন; blog-এর সুন্দর সংখ্যা কপি করে নয়। Per-action value, aggregate value, count, concurrency, data export, runtime ও model spend ধরুন। Technical reversibility একটি বিষয় মাত্র; পরে reservation cancel করলে হারানো sale ফেরে না।

বদলে যাওয়া Draft নয়, Exact Proposal Approve করুন

এই উদাহরণে agent refund proposal বানাতে পারে, টাকা ছাড়তে পারে না। Authorised finance reviewer original payment, eligible remaining amount, currency, customer remedy, destination, reason, evidence ও proposed change দেখেন। প্রয়োজনীয় separation of duties enforce হবে; policy-তে human approval লাগলে অন্য agent সেটি দিতে পারবে না।

Approval-কে exact action, target, amount, currency, destination ও version-এর সঙ্গে validity condition-সহ বাঁধুন। গুরুত্বপূর্ণ change হলে তা invalid হবে। Execute-এর সময় access, payment eligibility, remaining refundable balance ও policy আবার দেখুন; অন্য pending refund-ও ধরুন। আলাদা draft-কে পুরোনো approval ব্যবহার করতে দেবেন না।

Preview ও dry run reviewer-কে সাহায্য করে; simulation payment result নয়, future state-ও lock করে না। Reviewer যে evidence দেখতে পারেন সেটি ও unresolved uncertainty দেখান। Queue-এর owner, deadline, escalation ও staffing ঠিক করুন। Owed refund cap-এ আটকালেও দ্রুত authorised handling-এ যাবে; customer-এর অধিকার নীরবে বাতিল হবে না।

Review quality, sampled correctness ও delay দেখুন। High acceptance ভালো judgement-এর প্রমাণ নয়; zero rejection-ও একা rubber stamping প্রমাণ করে না। Policy মানলে অপ্রয়োজনীয় approval কমান, কিন্তু required approval-এর বদলে পরের sample check নয়।

Concurrent Action-এর আগে Shared Budget Reserve করুন

ধরুন ঘোষিত period ও currency-তে illustrative execution cap 500। Committed বা reserved exposure 340। আলাদাভাবে approved A ও B proposal প্রতিটি 100 চায়। দুটোই update-এর আগে “160 বাকি” পড়লে দুটো pass করে exposure 540 হতে পারে।

Business system-এ shared allowance check ও reserve একসঙ্গে atomic হতে হবে। A আগে 100 reserve করলে exposure 440, বাকি 60; B-তে total 540 cap ছাড়ায়, তাই authorised exception queue-তে যাবে। Approval থাকলেই execution rule override হয় না।

Confirmed, in-flight ও uncertain operation-এর কোনগুলো গণনা হবে, period/timezone, প্রয়োজনীয় currency conversion ও limit কে বদলাতে পারেন—স্পষ্ট করুন। Reconcile না হওয়া পর্যন্ত uncertain exposure reserve রাখুন। Policy অনুযায়ী verified failure/cancellation হলেই ছাড়ুন। A-এর duplicate retry একই reservation ব্যবহার করবে, নতুন 100 খাবে না। Rate limit একা financial cap নয়।

Timeout মানেই Refund Failed নয়

Response হারানোর আগেই provider refund accept করতে পারে। Operation reference রাখুন; নতুন request-এর আগে existing result query করুন। Provider status, amount ও local record মেলান। Submitted, pending, succeeded, failed ও unknown একই outcome নয়।

Idempotency key একই logical operation-এর intended payload-এর retry চিহ্নিত করে। Durable local tracking, atomic duplicate protection ও সঠিক provider support চাই। Fresh key দিয়ে একই business request এলে তা একা ধরতে পারে না; provider retention-ও চিরস্থায়ী নাও হতে পারে। Stripe idempotency documentation একটি provider-এর উদাহরণ, সর্বজনীন contract নয়।

শুধু উপযুক্ত transient failure-এ bounded exponential backoff, jitter, attempt/time budget ও unresolved status-এর owner-সহ retry করুন। Permission denial, invalid input ও changed proposal-এ correction বা নতুন approval লাগবে। Response দেরি করছে বলে নতুন payment reference বানাবেন না।

Completed refund এক-click undo নয়। Cancellation provider, method ও state-এর ওপর নির্ভর করে; accounting reversal customer-এর কাছ থেকে টাকা টেনে আনে না। Stripe refund guidance-এ সীমিত cancellation case আছে। ভুল completed refund-এ authorised resolution চাই, অনুমতি ছাড়া নতুন charge নয়।

Run থামলেও Evidence যেন থাকে

Requester/acting identity, delegated scope, source reference/time, proposal/version, policy decision, approver, operation ID, provider reference, result transition ও correction link রাখুন। পাওয়া গেলে model/tool/prompt/policy version রাখুন; model alias একা পুরোনো response reproduce নাও করতে পারে। সংক্ষিপ্ত evidence-based explanation চাইবেন, hidden chain-of-thought নয়।

Execute-এর আগে attempt record, পরে confirmed outcome যোগ করুন; refusal/failure-ও থাকবে। High-impact action-এর আগে logging unavailable হলে কী হবে design করুন। Unauthorised edit আটকান, privileged change audit করুন, প্রয়োজনীয় tamper-evident/retention control পরীক্ষা করুন। শুধু append-only নাম দিলেই storage কেউ বদলাতে পারেন না প্রমাণ হয় না।

Reader/export limit, sensitive content redaction ও retention/deletion policy রাখুন। প্রতিটি message কপি করার চেয়ে প্রয়োজনীয় evidence-সহ reference নিরাপদ হতে পারে। বেশি log মানেই ভালো নয়। Blocked-attempt বাড়া test/configuration error-ও হতে পারে; সবই malicious customer নয়।

Kill switch নির্দিষ্ট scope-এ নতুন কাজ থামায়; bank ইতিমধ্যে accept করা operation ফিরিয়ে আনতে পারে না। Queued কাজ stop/drain/cancel, relevant access revoke ও in-flight outcome চিহ্নিত করা পরীক্ষা করুন। Circuit breaker-এর explicit signal, responder ও controlled recovery চাই; alert নিজে investigation করে না।

Control পরীক্ষা করুন, Change-এর পরেও আবার

Representative ও adverse case নিন: অন্য store-এর record ID, supplier file-এ instruction, stale approval, changed destination, concurrent budget request, duplicate call, provider timeout ও unavailable audit storage। Synthetic বা authorised protected data ব্যবহার করুন। একটি injection test pass করলেই immunity প্রমাণ হয় না।

শুধু সুন্দর ভাষা নয়, expected permission ও business outcome মেলান। Language, partial refund, abstention, false block ও customer deadline ধরুন। Risk/rare event অনুযায়ী sample size ঠিক করুন; “50 case” universal acceptance standard নয়। Model/tool/prompt/policy বা গুরুত্বপূর্ণ data change-এ rerun করুন; ভালো average যেন critical regression না ঢাকে।

এক team, named reviewer ও tested stop/recovery দিয়ে rollout করুন। Verified error, unauthorised disclosure, unresolved outcome, review turnaround, aggregate exposure ও total cost মাপুন। Provider fail করলে human-led fallback রাখুন। Version rollback যতটা সম্ভব software behaviour ফেরায়; business action-এর compensation আলাদা সিদ্ধান্ত।

Framework ব্যবহার করুন, Checklist-কে Certificate ভাববেন না

NIST AI RMF voluntary risk-management reference। ISO/IEC 42001 organisational AI management system নিয়ে। Framework cite বা vendor badge দিয়ে প্রতিটি answer/workflow safe প্রমাণ হয় না; actual scope ও evidence দেখুন।

Legal duty use, jurisdiction ও আপনার role-এর ওপর নির্ভর করে। EU AI Act-এর Article 50-এ নির্দিষ্ট transparency obligation ও exception আছে; employment/credit use আলাদাভাবে classify করতে হবে। প্রতিটি সাধারণ ERP action-এ একই legal logging/disclosure duty ধরে নেবেন না। Deadline-এর ওপর নির্ভর করার আগে current applicable text দেখুন।

নিচের policy শুরু করার structure, তৈরি legal/spending authority নয়। Actual limit, reviewer, deadline ও recovery responsibility finance, operations ও security owner-কে ঠিক করতে হবে।

Task	Execute-এর আগে	Recovery-এর দায়িত্ব
Stock answer	Permitted record/field ও evidence time	উত্তর ঠিক করুন; disclosure হলে investigate
Purchase draft	Hidden send/reservation নয়; buyer exact version দেখেন	Policy মেনে withdraw; actual side effect সামলান
Refund proposal	Payment/eligibility, authorised approval ও shared execution limit	Finance provider status মেলায়; assumed undo নয়
Internal tag/reservation	Downstream effect, scope, volume ও permitted reversal দেখুন	Owner actual recovery নিশ্চিত করেন; one-click repair-এর promise নয়
Payroll, bank change বা accounting correction	আলাদা approved business process; open-ended agent authority নয়	Named accountable owner ও controlled correction

সকালে Finance Lead কী দেখবেন

লক্ষ্য হলো explainable queue: কোনটি proposed, approved, held, executed বা uncertain; কত exposure বাকি; পরের ধাপ কার দায়িত্ব। উদাহরণে A-এর actual outcome মেলার সময়ে shared cap B-কে hold করতে পারে। এটি সঠিক implementation ও test-এর ওপর নির্ভর করে; একই ধরনের message এলেই alarm হবে, এমন guarantee নয়।

Agent কাজে লাগার মতো preparation করতেই পারে। Business-এর হাতে থাকে সীমার মধ্যে approve, actual ঘটনা দেখা ও customer/evidence না হারিয়ে exception সামলানোর উপায়।

পর্যালোচনা: 5 নভেম্বর 2026। Anichur Rahaman StoreConsole-এর নির্মাতা। Retailer, refund total ও allowance-এর হিসাব কাল্পনিক শিক্ষামূলক উদাহরণ।