Claude EFS-এ log থাকবে নিজের cloud-এ—তবু monitoring বন্ধ হচ্ছে না
Anthropic-এর ১ সেপ্টেম্বরের ঘোষণা অনুযায়ী, Enterprise Frontier Safeguards বা EFS ধাপে ধাপে চালু হলে যোগ্য গ্রাহকেরা monitoring-এর জন্য রাখা activity data নিজেদের নিয়ন্ত্রিত cloud infrastructure-এ রাখতে পারবেন। কিন্তু Claude-এর গুরুতর অপব্যবহার শনাক্ত করার automated monitoring বন্ধ হবে না; পণ্যটির rollout ২০২৬ সালের শরতের পরবর্তী ভাগে শুরু হওয়ার কথা।
ঘোষণার পর ২ সেপ্টেম্বর প্রকাশিত TechRadar-এর প্রতিবেদন একই ব্যবস্থাকে customer cloud-এ automated monitoring চালিয়ে flag গ্রাহকের কাছে পাঠানোর মডেল হিসেবে বর্ণনা করেছে। অর্থাৎ, EFS-এর ঘোষিত পরিবর্তনটি monitoring তুলে দেওয়া নয়; বদলাবে retained monitoring data কোথায় থাকবে, তার key ও access কার নিয়ন্ত্রণে থাকবে এবং flag পাওয়ার পর মানবিক পর্যালোচনা কারা করবেন।
ডেটার custody বদলাবে, monitoring নয়
EFS-এ activity data গ্রাহকের Amazon S3, Azure Blob Storage বা Google Cloud Storage account-এ রাখা যেতে পারে। সেই data store-এর encryption key, access policy এবং audit logging গ্রাহকের নিয়ন্ত্রণে রাখার সুযোগ থাকবে। Customer-owned storage, Customer-Managed Encryption Keys এবং fully automated review—তিনটি control-ই opt-in; তাই “EFS ব্যবহার” বললেই প্রতিটি tenant-এ একই configuration কার্যকর হবে, এমন নয়।
এই সীমাটি গুরুত্বপূর্ণ: নিজের cloud-এ log থাকা মানে safety analysis বন্ধ হওয়া নয়। Anthropic-এর নকশায় automated system সময় ও account জুড়ে activity মিলিয়ে গুরুতর misuse-এর pattern খুঁজবে, কারণ কিছু ঘটনা একক request দেখে শনাক্ত করা যায় না। গ্রাহক storage বেছে নিলে সংশ্লিষ্ট read, write, storage ও data-egress charge cloud provider-এর কাছ থেকে আসতে পারে, যদিও Anthropic EFS-এর জন্য আলাদা charge না নেওয়ার কথা বলেছে।
EFS-এর জন্য Claude Code, Claude Enterprise, Claude Platform, Amazon Bedrock, Claude Platform on AWS, Google Agent Platform এবং Microsoft Foundry-কে পরিকল্পিত support surface হিসেবে উল্লেখ করা হয়েছে। AWS, Google Cloud ও Microsoft Azure-এ সমমানের control দেওয়ার লক্ষ্য আছে, তবে EFS এখনো broadly available নয়; access ধাপে ধাপে দেওয়া হবে।
Request থেকে human review পর্যন্ত data flow
EFS-এর data flow-তে চারটি আলাদা boundary আছে। এগুলো পৃথক করে দেখলেই “customer-controlled” কথাটির প্রকৃত পরিধি বোঝা যায়:
- ব্যবহারকারী বা enterprise application একটি covered Claude model-এ request পাঠায় এবং response গ্রহণ করে।
- Automated safety system traffic-এর rolling window বিশ্লেষণ করে, যাতে একাধিক session বা account-এ ছড়িয়ে থাকা গুরুতর misuse pattern ধরা যায়।
- Monitoring-এর জন্য retained activity data গ্রাহকের cloud account-এ রাখা যেতে পারে; storage, key, access rule ও audit trail তখন গ্রাহকের governance boundary-তে থাকে।
- কোনো pattern flag হলে signal গ্রাহকের কাছে যায়। অনুমোদিত internal reviewer সম্ভাব্য misuse নিশ্চিত করতে বা false positive বাদ দিতে পারেন।
Automated flag নিজে চূড়ান্ত মানবিক সিদ্ধান্ত নয়। আবার flag মানুষ দেখবেন বলে Anthropic-এর কর্মীকেই sensitive content দেখতে হবে, এমনও নয়। ঘোষিত architecture-এ machine analysis বহাল থাকে, আর প্রয়োজনীয় human review গ্রাহকের security ও compliance কাঠামোর ভেতরে নেওয়া যায়।
Human review-এর দায়িত্ব কার
EFS-এ Anthropic কর্মীর human review আবশ্যক নয়; flag সরাসরি গ্রাহকের কাছে পাঠানো হবে এবং গ্রাহকের নিজস্ব কর্মীরা পরবর্তী পর্যালোচনা করতে পারবেন। Regulated প্রতিষ্ঠানের জন্য এর তাৎপর্য হলো privileged legal material, non-public financial information বা অন্য সীমাবদ্ধ data দেখার অনুমতি প্রতিষ্ঠানের নিজস্ব প্রশিক্ষিত ও অনুমোদিত কর্মীদের মধ্যে রাখা সম্ভব।
তবে customer-led review Anthropic-এর Usage Policy বা enforcement system বাতিল করে না। দায়িত্বের বিভাজনটি বরং এমন: retained data-এর custody, key এবং স্থানীয় human access গ্রাহকের control-এ যেতে পারে; গুরুতর misuse শনাক্ত করার automated layer EFS-এর অংশ হিসেবেই থাকে। “No Anthropic human review required” মানে Anthropic-এর কোনো system data process করবে না—এমন দাবি নয়।
প্রতিষ্ঠানকেও reviewer-এর ভূমিকা স্পষ্ট করতে হবে। কারা flag queue দেখতে পারবেন, কোন ঘটনায় legal, fraud বা incident-response দল যুক্ত হবে, reviewer-এর action কোথায় audit হবে এবং escalation authority কার—এসব EFS নিজে নির্ধারণ করে দেয় না; এগুলো গ্রাহকের governance সিদ্ধান্ত।
Rollout-এর আগে সীমিত ZDR
Claude-এর Covered Models নীতি বলছে, EFS ২০২৬ সালের শরৎ থেকে ধাপে ধাপে চালু হবে এবং এর আগে যোগ্য গ্রাহকেরা নিজেদের internal business application-এ Fable 5 ও Fable 5.1-এর জন্য সীমিত সময়ের ZDR বিকল্প পেতে পারেন। Anthropic বা সংশ্লিষ্ট cloud provider যোগ্য প্রতিষ্ঠানকে যোগাযোগ করতে পারে; প্রতিষ্ঠানগুলো বিবেচনার জন্য আবেদনও করতে পারবে।
এই temporary ZDR শুধু stored data-এর retention ও review-কে প্রভাবিত করে। Real-time safety classifier, Usage Policy এবং Anthropic-এর enforcement system সব traffic-এ বহাল থাকবে; misuse-এর প্রতিক্রিয়ায় ব্যবস্থাটি বদলানো বা প্রত্যাহার করাও সম্ভব। তাই ZDR এখানে “কোনো monitoring নেই” নয়, বরং EFS প্রস্তুত হওয়ার আগের সীমিত retention arrangement।
Standard policy-তে covered model-এর prompt ও completion অন্তত ৩০ দিন রাখা হয় এবং পরে স্বয়ংক্রিয়ভাবে মুছে ফেলা হয়, যদি safety investigation বা আইনি বাধ্যবাধকতায় আরও retention প্রয়োজন না হয়। ফলে একই প্রতিষ্ঠানে model, workspace, application ও access surface অনুযায়ী standard retention, temporary ZDR এবং ভবিষ্যৎ EFS—তিনটি ভিন্ন অবস্থা থাকতে পারে।
Procurement review-তে যে সীমাগুলো লিখিতভাবে চাইতে হবে
“Customer-controlled” শব্দটি একা procurement সিদ্ধান্তের জন্য যথেষ্ট নয়। চুক্তি ও architecture review-তে অন্তত নিচের প্রশ্নগুলোর নির্দিষ্ট উত্তর প্রয়োজন:
- আমাদের tenant, model, workload ও cloud access path কি EFS অথবা temporary ZDR-এর জন্য যোগ্য?
- কোন activity field রাখা হবে, কোন cloud account ও region-এ থাকবে এবং retention window কত?
- Encryption key তৈরি, rotation, revocation ও recovery কার নিয়ন্ত্রণে থাকবে?
- Automated analyzer কী permission পাবে এবং data read বা egress হলে কোন audit event তৈরি হবে?
- Flag-এর সঙ্গে raw prompt, completion, metadata নাকি শুধু signal—কোন অংশ reviewer দেখতে পারবেন?
- কারা human reviewer হবেন, least-privilege access কীভাবে কার্যকর হবে এবং review action কোথায় নথিবদ্ধ হবে?
- Temporary ZDR কখন শেষ হবে, migration notice কত আগে আসবে এবং EFS চালু না করলে workload কোন retention policy-তে ফিরবে?
- Safety investigation, legal hold বা policy enforcement সাধারণ retention rule কীভাবে বদলাতে পারে?
এখন পর্যন্ত নিশ্চিত অবস্থা হলো, EFS ঘোষিত হলেও broad availability ভবিষ্যৎ phased rollout-এর লক্ষ্য। Customer-controlled storage, customer-managed key, automated detection এবং customer-led human review-এর কাঠামো প্রকাশিত হয়েছে; কিন্তু প্রতিটি cloud-এর পূর্ণ configuration, customer eligibility এবং operational retention window-এর সব বিবরণ এখনো প্রকাশিত হয়নি। এই কারণেই procurement নথিতে ঘোষিত EFS capability, অন্তর্বর্তী ZDR এবং বর্তমানে কার্যকর standard retention-কে আলাদা control হিসেবে ধরতে হবে।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।