কাজে Claude AI নেওয়ার আগে দেখুন: আসনমূল্যের বাইরেও token bill

Claude AI কাজে নেওয়ার সিদ্ধান্ত শুধু আসনমূল্য দেখে নেওয়া যায় না। সাধারণ লেখা, গবেষণা ও বিশ্লেষণের জন্য Chat, সফটওয়্যার repository-তে কাজের জন্য Claude Code এবং বহু ধাপের knowledge-work অর্পণের জন্য Cowork প্রাসঙ্গিক; Enterprise-এ এগুলোর token usage আসনমূল্যের বাইরে আলাদাভাবে bill হয়।

তাই ক্রয়ের আগে একই হিসাবে পাঁচটি বিষয় আনতে হবে: কোন কর্মী কোন surface ব্যবহার করবেন, প্রত্যাশিত token consumption কত, connector কোন তথ্য ও tool ছুঁতে পারবে, প্রশাসক কী audit evidence পাবেন এবং agent ভুল করলে ক্ষতির সীমানা কোথায় থামবে। এর কোনোটি বাদ পড়লে প্রাথমিক আসনমূল্য মোট পরিচালন ব্যয় বা নিরাপত্তা-ঝুঁকির সঠিক ছবি দেবে না।

আসনমূল্য মোট বিল নয়

Anthropic-এর Enterprise plan নির্দেশনা অনুযায়ী বর্তমান usage-based Enterprise plan-এ seat fee শুধু platform access দেয়; Chat, Claude Code ও Cowork-এর প্রতিটি token standard API rate-এ আলাদাভাবে bill হয়। এতে কোনো অন্তর্ভুক্ত token allowance বা seat-level usage limit নেই, তবে administrator organization ও individual user স্তরে spend limit বসাতে পারেন। পুরোনো Standard বা Premium seat-ভিত্তিক চুক্তি renewal পর্যন্ত ভিন্ন নিয়মে চলতে পারে, তাই বিদ্যমান গ্রাহককে নিজের contract model-ও মিলিয়ে দেখতে হবে।

Procurement sheet-এ তাই শুধু “আসনসংখ্যা × আসনমূল্য” রাখা যথেষ্ট নয়। কার্যকর মোট ব্যয়ের হিসাবে রাখুন বার্ষিক seat commitment, metered usage, প্রযোজ্য কর ও মুদ্রা রূপান্তর, rollout এবং security operations। বাংলাদেশ বা ভারতের buyer-এর জন্য invoice currency, bank বা card charge এবং স্থানীয় কর finance দলের আলাদা যাচাইয়ের বিষয়; এগুলো vendor-এর ঘোষিত পণ্যমূল্য নয়।

Token budget তৈরির সবচেয়ে নির্ভরযোগ্য ভিত্তি হলো সীমিত pilot। কাজের ধরন ধরে input-এর আকার, conversation history, output frequency ও agent চলার সময় নথিভুক্ত করুন; ছোট প্রশ্নোত্তর, দীর্ঘ document analysis, repository-wide coding এবং বহু ধাপের background task-কে একই গড়ের মধ্যে ফেলবেন না। স্বাভাবিক মাসের পাশাপাশি release, migration বা client-delivery সপ্তাহের peak scenario-ও রাখুন।

• Baseline: প্রতিটি role-এর সাপ্তাহিক কাজ ও সম্ভাব্য usage লিখুন।
• Allocation: user, project বা client account ধরে consumption আলাদা করুন।
• Guardrail: organization cap-এর নিচে group বা user limit নির্ধারণ করুন।
• Exception: limit বাড়ানোর অনুমোদনকারী, কারণ ও মেয়াদ আগে ঠিক করুন।

Chat, Claude Code না Cowork

Claude Enterprise-এর product বিবরণে Chat-কে research, brainstorming, writing ও analysis; Claude Code-কে software development; এবং Cowork-কে background-এ চলা জটিল task অর্পণের জন্য আলাদা করা হয়েছে। একই seat-এ Claude Design, Microsoft 365, Chrome ও Slack-এ ব্যবহারের সুবিধা, pre-built ও custom connector এবং SSO, SCIM, role-based access control, audit log, Compliance API ও Analytics API-র মতো প্রশাসনিক control-ও রয়েছে।

এক seat-এ একাধিক surface থাকলেও সবার জন্য সব entitlement চালু করার প্রয়োজন নেই। Summarisation, drafting বা সাধারণ বিশ্লেষণে Chat দিয়ে শুরু করা যায়। Terminal, IDE বা repository-তে পরিবর্তন প্রয়োজন হলে Claude Code প্রাসঙ্গিক, কিন্তু production credential বা unrestricted shell access তার আবশ্যিক শর্ত নয়। Cowork তখনই যুক্তিযুক্ত, যখন নির্দিষ্ট input, প্রত্যাশিত deliverable, সময়সীমা ও অনুমোদিত workspace-সহ একটি task সত্যিই অর্পণ করা যায়।

একটি role-to-surface matrix-এ role, অনুমোদিত product, model বা effort level, connector, filesystem scope ও spend limit আলাদা column-এ রাখুন। “সব কর্মীর জন্য সবকিছু” provisioning সহজ করলেও usage ও access surface একসঙ্গে বাড়ায়। Pilot-এ প্রমাণিত প্রয়োজন অনুযায়ী entitlement বাড়ানো তুলনামূলকভাবে নিয়ন্ত্রিত পথ।

Connector চালুর আগে permission boundary

Connector চালু থাকলেই প্রত্যেক ব্যবহারকারী প্রতিষ্ঠানের সব তথ্য দেখতে পান না: Claude Enterprise-এর connector underlying system-এর বিদ্যমান user permission অনুসরণ করে, আর administrator organization-wide availability ও per-tool permission নিয়ন্ত্রণ করতে পারেন। কিন্তু এতে দুর্বল Google Drive, GitHub বা Microsoft 365 permission নিজে থেকে ঠিক হয় না। Claude যুক্ত করার আগে মূল system-এর shared folder, inherited role, service account ও পুরোনো group membership পরিষ্কার করতে হবে।

প্রতিটি connector-এর জন্য একটি সংক্ষিপ্ত permission audit রাখুন:

1. কোন business task-এর জন্য connector প্রয়োজন এবং read-only access যথেষ্ট কি না লিখুন।
2. কোন user group, repository, mailbox, folder বা tenant scope দৃশ্যমান হবে তা নির্ধারণ করুন।
3. Shared drive, service account ও inherited permission অতিরিক্ত access দিচ্ছে কি না পরীক্ষা করুন।
4. Connector-এর content-এ prompt injection থাকতে পারে ধরে sensitive action-এর জন্য আলাদা approval রাখুন।
5. কর্মী বদলি, project সমাপ্তি বা incident-এর সময় access ও token কীভাবে revoke হবে তা যাচাই করুন।

প্রথম rollout-এ কম সংবেদনশীল data ও ছোট user group বেছে নেওয়া যুক্তিসঙ্গত। Connector catalogue-এ কোনো integration থাকা security approval-এর বিকল্প নয়; business owner, data owner ও security owner-কে নিজ নিজ ঝুঁকি অনুমোদন করতে হবে।

Governance কিনলেই audit evidence তৈরি হয় না

SSO, SCIM, retention control বা audit log feature হিসেবে উপস্থিত থাকা এবং প্রতিষ্ঠানের control হিসেবে কার্যকর থাকা এক বিষয় নয়। Procurement-এর আগে প্রতিটির owner, configuration, review frequency ও প্রত্যাশিত evidence লিখুন। SSO থাকলে unmanaged account-এর পথ বন্ধ কি না, আর SCIM থাকলে joiner, mover ও leaver flow-তে deprovisioning যথাসময়ে হচ্ছে কি না নমুনা account দিয়ে যাচাই করা দরকার।

Audit coverage-এর ক্ষেত্রে “log আছে” উত্তরটি অসম্পূর্ণ। Chat, Claude Code, Cowork, connector access, administrative change ও file action-এর কোন ঘটনা ধরা পড়ে, কোন পরিচয় ও timestamp পাওয়া যায় এবং SIEM-এ পৌঁছাতে কত দেরি হয়—pilot-এ পরিচিত কয়েকটি ঘটনা ঘটিয়ে মিলিয়ে দেখুন। কোনো প্রয়োজনীয় ঘটনা অনুপস্থিত হলে সেটিকে contract বা configuration-এর ফাঁক হিসেবে নথিভুক্ত করুন।

Data control-এর জন্য চারটি প্রশ্ন যথেষ্ট ধারালো: input ও output কোথায় থাকে, retention কে বদলাতে পারে, deletion কীভাবে প্রমাণ করা যাবে এবং support বা incident investigation-এ কার access থাকে। Vendor documentation, contract, data-processing agreement ও নিজের configuration-এ উত্তর না মিললে পার্থক্যটি risk register-এ রাখুন; marketing feature list দিয়ে তা মিটে যায় না।

Autonomous agent-এর blast radius বেঁধে দিন

Agent যত বেশি file, command, credential ও network destination ব্যবহার করতে পারে, ভুল বা আক্রমণে সম্ভাব্য ক্ষতির পরিধিও তত বাড়ে। Anthropic-এর containment engineering বিশ্লেষণ মানব অনুমোদনকে একমাত্র প্রতিরক্ষা না ধরে sandbox, virtual machine, filesystem boundary ও egress control দিয়ে agent কী করতে সক্ষম তার কঠোর সীমা নির্ধারণের কথা বলে। সেখানে অনুমোদিত network path দিয়েও data বেরিয়ে যাওয়ার ঘটনা এবং VM isolation-এর কারণে endpoint monitoring-এর visibility কমে যাওয়ার সীমাবদ্ধতাও দেখানো হয়েছে।

Claude Code বা Cowork-এর containment checklist তাই সাধারণ chatbot policy-এর চেয়ে কঠোর হওয়া উচিত। Production ও development credential আলাদা রাখুন; agent workspace-এ শুধু প্রয়োজনীয় directory mount করুন; যেখানে সম্ভব read-only permission দিন; outbound allowlist থাকলেও কোন credential, header ও function দিয়ে request যাচ্ছে তা যাচাই করুন। Deployment, destructive command, অর্থ লেনদেন, customer communication ও sensitive data export-এর মতো কাজ human approval ছাড়া সম্পন্ন হতে দেবেন না।

একটি ব্যর্থতার মহড়ায় দেখুন agent ভুল file বদলালে rollback কীভাবে হবে, compromised document-এর নির্দেশ data কোথায় পাঠাতে পারে, connector token revoke করতে কত সময় লাগে এবং তদন্তে যথেষ্ট event পাওয়া যায় কি না। এখানে লক্ষ্য agent কখনো ভুল করবে না—এমন অনুমান নয়; ভুল হলেও তার নাগাল প্রতিষ্ঠানের সহনীয় সীমার মধ্যে রাখা।

ক্রয়ের আগে এক পাতার সিদ্ধান্ত-চেকলিস্ট

• প্রতিটি role-এর জন্য Chat, Claude Code বা Cowork-এর প্রয়োজন নির্দিষ্ট task দিয়ে প্রমাণিত।
• Seat commitment-এর বাইরে pilot-ভিত্তিক token budget ও peak-usage allowance রাখা হয়েছে।
• Organization, group বা user spend limit, alert এবং exception owner নির্ধারিত।
• প্রতিটি connector-এর data owner, scope, permission test ও revocation path নথিভুক্ত।
• SSO, SCIM, retention, audit export ও incident evidence বাস্তব configuration-এ যাচাই করা হয়েছে।
• Agent-এর filesystem, credential, network egress ও destructive action-এর সীমা নির্ধারিত।
• Rollback, access revocation ও investigation-এর মহড়া গ্রহণযোগ্য ফল দিয়েছে।

Claude AI উপযোগী কি না, তার উত্তর feature count দিয়ে নয়—কাজের ফল, metered usage এবং নিয়ন্ত্রিত access একসঙ্গে মেপে দিতে হবে। আসন, token, connector permission, audit gap ও সম্ভাব্য ক্ষতির সীমা একই approval document-এ থাকলে buyer বুঝতে পারবেন কোন capability চালু করা যায়, কোনটি pilot-এ থাকবে এবং কোনটির আগে আরও control প্রয়োজন।