শেয়ার করার আগে: AI গোপনীয়তার জন্য প্রতিশ্রুতির চেয়েও বেশি কিছু দরকার

ভূমিকা: এই কথোপকথনই ধীরে ধীরে আপনার জীবন হয়ে উঠছে

একটি কঠিন জবাব লিখতে আপনি একটি AI সহকারী খুললেন। আপনি বার্তাটি পেস্ট করলেন, সম্পর্কের প্রেক্ষাপট ব্যাখ্যা করলেন, আর এমন কিছু বিস্তারিত যোগ করলেন যা আপনি আর কোথাও শেয়ার করেননি। আরেক দিন আপনি একটি চুক্তিপত্র আপলোড করলেন, অসমাপ্ত একটি ধারণা নিয়ে আলোচনা করলেন, বা আপনার ইনবক্স সংযুক্ত করলেন যাতে সহকারী বুঝতে পারে কোন বিষয়গুলো আপনার মনোযোগ চায়।

এর কোনোটাই প্রকাশ করার মতো মনে হয় না। আপনি শুধু সাহায্য চাইছেন।

তবু এই তথ্য এমন অবকাঠামো, স্টোরেজ সিস্টেম, পর্যালোচনা প্রক্রিয়া এবং আইনি বাধ্যবাধকতার মধ্য দিয়ে যেতে পারে, যেগুলো কথোপকথনের উইন্ডো থেকে প্রায় অদৃশ্য। কোনো সহকারী খুব দ্রুতই ব্যক্তিগত মনে হতে পারে, তার আগেই আপনার ডেটা ব্যবহারের ধরন সেই প্রত্যাশার সঙ্গে মেলে।

আমার অবস্থান সরল: AI গোপনীয়তা শুধু এই বিষয়ে নির্ভর করা উচিত নয় যে কোনো কোম্পানি আপনার তথ্য পাওয়ার পর কী করার প্রতিশ্রুতি দেয়। এটি এ বিষয়েও নির্ভর করা উচিত যে তাদের সিস্টেম শুরুতেই কী কী তথ্য মডেলের কাছে পৌঁছাতে বাধা দেয়। নীতিমালা গুরুত্বপূর্ণ। কিন্তু তার পেছনে প্রযুক্তিগত সুরক্ষা থাকাও জরুরি।

আমি Dvina টিমের সহায়তায় এই নিবন্ধটি প্রস্তুত করেছি। এতে ChatGPT, Claude, Cursor, Perplexity, Manus, Meta’s Muse এবং Dvina জুড়ে নথিভুক্ত ঘটনা ও বর্তমান চর্চা পর্যালোচনা করা হয়েছে। উদ্দেশ্য হলো ব্যাখ্যা করা কেন AI আমাদের জীবনে আরও গভীরভাবে জড়িয়ে পড়ার সঙ্গে সঙ্গে গোপনীয়তাকে একটি কেন্দ্রীয় প্রকৌশল অগ্রাধিকার হতে হবে—এবং Dvina কীভাবে সেই দায়িত্বের দিকে এগোচ্ছে।

ঘটনাগুলো আমাদের কী বলে

এই উদ্বেগ কল্পিত নয়। তবে ভিন্ন ধরনের প্রমাণ ভিন্ন ধরনের সমস্যার ইঙ্গিত দেয়। নিশ্চিত ডেটা-উন্মোচন, অনুমোদিত মানব-পর্যালোচনা, এবং গবেষণার অপব্যবহার নিয়ে কোনো অভিযোগ—এসবকে যেন একই ধরনের ঘটনা, সে ভাবে উপস্থাপন করা উচিত নয়।

ChatGPT-এর 2023 সালের উন্মোচন: সিস্টেমের ভেতরেরই একটি ব্যর্থতা।

20 March 2023-এ, একটি সফটওয়্যার বাগের কারণে কিছু ChatGPT ব্যবহারকারী অন্য সক্রিয় ব্যবহারকারীর কথোপকথন-ইতিহাসের শিরোনাম দেখতে পেরেছিলেন। OpenAI জানায়, কিছু নির্দিষ্ট পরিস্থিতিতে সদ্য তৈরি করা কথোপকথনের প্রথম বার্তাটিও দৃশ্যমান হয়ে থাকতে পারে। তাদের তদন্তে দেখা যায়, একটি নির্দিষ্ট নয়-ঘন্টার সময়সীমায় সক্রিয় থাকা Plus গ্রাহকদের 1.2%-এর ক্ষেত্রে পেমেন্ট-সংক্রান্ত তথ্য উন্মোচিত হয়ে থাকতে পারে। সম্পূর্ণ কার্ড নম্বর উন্মোচিত হয়নি। OpenAI বাগটি ঠিক করে এবং প্রভাবিত ব্যবহারকারীদের জানায়। 1

এখান থেকে শিক্ষা এই নয় যে একই দুর্বলতা এখনও খোলা রয়েছে। শিক্ষা হলো, শুধু একটি গোপনীয়তা-প্রতিশ্রুতি নিজে থেকেই কোনো সিস্টেমকে ভুল ব্যক্তির কাছে তথ্য ফেরত দেওয়া থেকে আটকাতে পারে না। বিচ্ছিন্নতা, অ্যাক্সেস যাচাই, এবং উন্মোচিত হওয়ার মতো শনাক্তযোগ্য তথ্যের পরিমাণ—সবই গুরুত্বপূর্ণ।

The New York Times মামলা: মুছে ফেলা একটি আইনি বাধ্যবাধকতার মুখোমুখি হয়েছিল।

২০২৫ সালে, OpenAI এমন একটি আদালতের আদেশের মুখোমুখি হয়েছিল, যাতে এমন ডেটাও সংরক্ষণ করতে বলা হয় যা অন্যথায় মুছে ফেলা হতো। তাদের অক্টোবরের আপডেটে বলা হয়, নতুন ডেটা অনির্দিষ্টকালের জন্য সংরক্ষণের বিস্তৃত বাধ্যবাধকতা ২৬ সেপ্টেম্বর ২০২৫-এ শেষ হয়েছে, যদিও সীমিত একটি ঐতিহাসিক ডেটাসেট আইনি হোল্ডের অধীনে রয়ে গেছে। মূল সংরক্ষণ-সংক্রান্ত শর্তে কিছু নির্দিষ্ট পণ্য এবং zero-data-retention ব্যবস্থা বাদ ছিল। 2

পরবর্তী একটি অগ্রগতি আলাদাভাবে পড়তে হবে: ২০২৫ সালের ডিসেম্বরে Reuters জানায়, কপিরাইট মামলায় একজন বিচারক OpenAI-কে ২ কোটি anonymized chat log জমা দিতে নির্দেশ দেন; OpenAI-এর আপত্তি খারিজ করে তিনি de-identification এবং সুরক্ষামূলক নিরাপত্তাব্যবস্থার ওপর নির্ভর করেন। এটি ছিল একটি discovery order, সবার ব্যক্তিগত চ্যাট ইন্টারনেটে প্রকাশ করার নির্দেশ নয়। 3

একসঙ্গে দেখলে, এই ঘটনাগুলো বোঝায় কেন কোনো deletion setting থাকলেই সংরক্ষিত তথ্য নিয়ে সব প্রশ্নের নিষ্পত্তি হয়ে যায় না। একবার কোনো কপি থেকে গেলে, ব্যবহারকারীর নিয়ন্ত্রণের বাইরের বাধ্যবাধকতাও তার পরিণতিকে প্রভাবিত করতে পারে। অপ্রয়োজনীয় সংরক্ষণ কমিয়ে আনা বিরোধ শুরু হওয়ার আগেই সেই ঝুঁকি বদলে দেয়।

মানবীয় পর্যালোচনা: লঙ্ঘন ছাড়াও অ্যাক্সেস অনুমোদিত হতে পারে।

OpenAI-এর consumer documentation-এ স্পষ্টভাবে বলা আছে যে নির্দিষ্ট কিছু উদ্দেশ্যে—যেমন নিরাপত্তা তদন্ত, সহায়তা, আইনি বিষয়, এবং eligible model improvement—অনুমোদিত কর্মী ও service provider-দের সীমিত অ্যাক্সেস দেওয়া যেতে পারে। Anthropic-এর consumer guidance-এও বলা আছে, usage-policy enforcement-এর জন্য নির্ধারিত কর্মীরা কথোপকথন পর্যালোচনা করতে পারেন; আর সম্মতিসহ দেওয়া feedback-এর সঙ্গে সম্পর্কিত আলাদা অ্যাক্সেসও রয়েছে। 4, 8

এগুলো নথিভুক্ত অ্যাক্সেসের পথ, গুজব নয়। এগুলো থেকে এই সিদ্ধান্তে পৌঁছানো যায় না যে কর্মীরা প্রতিটি কথোপকথন পড়েন। তবে এটুকু স্পষ্ট হয় যে বাইরে থেকে ব্যক্তিগত মনে হওয়া chat interface সবসময় provider-এর অ্যাক্সেসের বিরুদ্ধে প্রযুক্তিগত বাধা নয়।

Anthropic-এর বর্তমান documentation ব্যবসায়িক দিকের একটি গুরুত্বপূর্ণ উদাহরণও যোগ করে। তাদের নির্ধারিত Covered Models-এর ক্ষেত্রে, কিছু deployment-এ ৩০ দিনের retention বাধ্যতামূলক, যদিও আগে সেখানে zero data retention ব্যবহৃত হতো; এর সঙ্গে রয়েছে নিয়ন্ত্রিত মানবীয় পর্যালোচনা এবং কিছু ব্যতিক্রম। এই নিয়মের model, platform, এবং eligibility-সংক্রান্ত সীমা আছে; এটি Claude-এর প্রতিটি পণ্যে একযোগে প্রযোজ্য কোনো পরিবর্তন নয়। Consumer plan-গুলোর ক্ষেত্রে বলা হয়েছে, সেগুলো প্রভাবিত নয়, কারণ ওই surface-গুলোতে আগেই input এবং output সংরক্ষিত হয়। 9

নিরাপত্তা পর্যবেক্ষণের একটি বৈধ উদ্দেশ্য আছে। প্রকৌশলগত চ্যালেঞ্জ হলো, সেই উদ্দেশ্য পূরণ করার পাশাপাশি monitoring system এবং reviewer-দের কাছে উপলভ্য সংবেদনশীল তথ্যকে যতটা সম্ভব কমিয়ে আনা। নিরাপত্তার যুক্তি দেখালেই গোপনীয়তার প্রশ্ন মিলিয়ে যায় না।

গণিত-সংক্রান্ত বিতর্ক: অমীমাংসিত অভিযোগ, বাস্তব আস্থার সমস্যা

২০২৬ সালের সেপ্টেম্বর মাসে OpenAI-এর Navier–Stokes ঘোষণা ঘিরে যে বিতর্ক তৈরি হয়, তা ভিন্ন এক উদ্বেগ সামনে আনে: ব্যক্তিগত গবেষণায় সহায়তা করা assistant যদি এমন একটি কোম্পানির হয়, যে নিজেও গবেষণা চালায়, তাহলে কী ঘটে?

বিতর্কটি ছিল অপ্রকাশিত গাণিতিক কাজ এবং কৃতিত্ব নিয়ে। বিভিন্ন প্রতিবেদনে বলা হয়, গণিতবিদ Tristan Buckmaster এবং Levent Alpöge তাদের কাজে AI tools ব্যবহার করেছিলেন, এবং Buckmaster প্রশ্ন তোলেন যে তাদের ব্যক্তিগত উপাদান OpenAI-এর ফলাফলে অবদান রেখেছিল কি না। 10

OpenAI এই বিবরণ নিয়ে দ্বিমত পোষণ করে। তাদের প্রকাশিত জবাবে বলা হয়েছে, প্রকাশের আগে তাদের গবেষক বা তাদের প্রতিনিধিদের কেউই ওই দুজনের কাজ দেখেননি। ১০ সেপ্টেম্বর তারিখের একটি আপডেটে তারা আরও জানায়, তদন্তে আগের দুই মাসে Buckmaster-এর Codex prompts থেকে কোনো প্রভাব ছিল না—training-এর মাধ্যমেও নয়—এমনটি নিশ্চিত করা হয়েছে। সময়সীমা-নির্দিষ্ট এই বক্তব্য কিছু প্রতিবেদনের আগের বিবরণের তুলনায় বেশি নির্দিষ্ট। 11

সার্বজনিক বিবরণগুলো এখনো বিতর্কিত। এখানে পর্যালোচিত সূত্রগুলো স্বাধীনভাবে প্রমাণ করে না যে OpenAI তাদের ফলাফল তৈরিতে ওই ব্যক্তিগত কথোপকথনগুলো ব্যবহার করেছে।

তবু এই বিরোধ একটি প্রশ্নকে সামনে আনে, যার স্পষ্ট উত্তর দরকার: মানুষ যখন অসমাপ্ত কাজ AI-এর কাছে নিয়ে আসে, তখন সেই কাজের তথ্যগত মূল্যকে কী সুরক্ষা দেয়? কোনো প্রমাণ থেকে লেখকের নাম সরিয়ে দিলেই প্রমাণটি মুছে যায় না। কোনো বাণিজ্যিক কৌশল de-identify করলেই তা জনসাধারণের সম্পত্তি হয়ে যায় না।

এই কারণেই শক্তিশালী গোপনীয়তার জন্য পরিচয় এবং বিষয়বস্তু—দুটিরই সুরক্ষা দরকার। ব্যবহারকারীদের বোঝার সুযোগ থাকা উচিত, তাদের উপাদান training, research, evaluation, বা review workflow-এ যেতে পারে কি না—এবং সেই সীমারেখা কার্যকর করতে কী প্রযুক্তিগত নিয়ন্ত্রণ আছে।

চারটি প্রশ্ন, যেগুলোকে কখনোই একটিতে গুলিয়ে ফেলা উচিত নয়

বিভ্রান্তির বড় অংশ আসে “private” শব্দটিকে একক বৈশিষ্ট্য হিসেবে দেখার কারণে। বাস্তবে, একটি কথোপকথনের ক্ষেত্রে কী ঘটবে তা চারটি আলাদা প্রশ্ন নির্ধারণ করে।

Training: এই বিষয়বস্তু কি একটি model তৈরি বা উন্নত করতে সাহায্য করতে পারে? opt-out কোনো তথ্যের অনুমোদিত ব্যবহারে পরিবর্তন আনে। কিন্তু তথ্যটি আদৌ প্রেরিত বা সংরক্ষিত হয়েছে কি না, তা এতে অবশ্যই বদলে যায় না।

Access: কোন system এবং কোন মানুষ এটি পরীক্ষা করতে পারে? transmission এবং storage-এর সময় encryption গুরুত্বপূর্ণ, কিন্তু তা স্বয়ংক্রিয়ভাবে এই নিশ্চয়তা দেয় না যে কোনো অনুমোদিত service processing বা review-এর জন্য content decrypt করতে পারবে না।

Retention: কী থাকে, কোথায় থাকে, এবং কতদিন থাকে? interface থেকে একটি chat সরিয়ে দেওয়া, production records মুছে ফেলা, backups-এর মেয়াদ শেষ হওয়া, এবং ভবিষ্যৎ training থেকে data বাদ দেওয়া—এসব আলাদা আলাদা প্রক্রিয়া।

অ্যাকশনস: একটি সংযুক্ত সহকারী কী পড়তে, পরিবর্তন করতে বা পাঠাতে পারে? এটি একবার আপনার অ্যাকাউন্টগুলোর মাধ্যমে কাজ করতে পারলে, গোপনীয়তা তখন অনুমতি এবং বহির্গামী ডেটার ওপর নিয়ন্ত্রণের ওপরও নির্ভর করে।

একটি কার্যকর গোপনীয়তা-তুলনা এই প্রশ্নগুলোকে আলাদা রাখে। একটি paid subscription, একটি training switch, বা একটি private-task label—এই চারটির সবকটির উত্তর দিতে পারে না।

পরিষেবাগুলোর তুলনা

নিচের টেবিলটি, ভিন্ন কোনো পরিসর উল্লেখ না থাকলে, ব্যক্তিগত ব্যবহারের ওপর কেন্দ্রীভূত। এটি স্বাধীন নিরাপত্তা নিরীক্ষার ফল নয়; বরং পর্যালোচিত ডকুমেন্টেশনের সারসংক্ষেপ।

নিচের বিস্তারিত অংশে ব্যাখ্যা করা হয়েছে, দৈনন্দিন ব্যবহারে কোথায় এই পার্থক্যগুলো গুরুত্বপূর্ণ হয়ে ওঠে।

ChatGPT এবং Claude: আপনি কী করেন, তার ওপর নিয়ম বদলে যায়।

OpenAI ব্যবহারকারীদের সাধারণ chat history মুছে না ফেলেও training বন্ধ করার সুযোগ দেয়। Temporary Chat একটি কথোপকথনের ব্যবস্থাপনাকে আরও বদলে দেয়, তবে এর ডকুমেন্টেশন তবু abuse review-এর অনুমতি দেয় এবং 30 দিনের deletion period-এর কথা বলে। Codex ব্যবহারকারীদেরও account-wide content setting এবং এর আলাদা full-environment setting-এর মধ্যে পার্থক্য করা উচিত। 4, 5

Claude-এর ক্ষেত্রে, feedback বিশেষ মনোযোগের দাবি রাখে। Anthropic বলছে, একটি thumbs-up, thumbs-down, বা bug report-এর ফলে সংশ্লিষ্ট কথোপকথন সর্বোচ্চ পাঁচ বছর পর্যন্ত সংরক্ষণ করা হতে পারে এবং model training-সহ বিভিন্ন উদ্দেশ্যে ব্যবহার করা হতে পারে। সাধারণ model improvement চালু করলে উপযুক্ত de-identified material-ও training pipelines-এ সর্বোচ্চ পাঁচ বছর পর্যন্ত থাকতে পারে। এগুলো সাধারণ chat deletion-এর নিয়মের মতো নয়। 6, 7

ফলে একজন ব্যক্তি একই পণ্যের ভেতরেই একাধিক গোপনীয়তা-সংক্রান্ত সিদ্ধান্ত নিতে পারেন, অথচ বুঝতেই নাও পারেন যে এগুলো আলাদা সিদ্ধান্ত। পণ্যের নকশায় ব্যবহারস্থলেই এই পার্থক্যগুলো স্পষ্ট করে দেখানো উচিত।

Cursor এবং Perplexity: কোনো পণ্যের label processing boundary নয়।

Cursor-এর Privacy Mode training এবং provider retention-এর ওপর অর্থবহ সীমাবদ্ধতা দেয়। তবে এটি editor-কে local-only করে না: Cursor বলছে, ব্যবহারকারী-সরবরাহকৃত API key থাকলেও requests তাদের backend দিয়েই যায়। এর ডকুমেন্টেশনে temporary encrypted file caching এবং abuse investigations বা designated models-সংশ্লিষ্ট exceptions-এরও বর্ণনা আছে। 12

Perplexity ভিন্ন ধরনের একটি পার্থক্য দেখায়। এর Free, Pro, এবং Max accounts consumer training controls-এর আওতায় পড়ে, যেখানে collection ডিফল্টভাবে চালু। প্রকাশিত opt-out পরবর্তীতে সংগৃহীত ডেটার ক্ষেত্রে প্রযোজ্য, আগের training data-কে retroactive removal করার জন্য নয়। ব্যক্তিগত subscription কিনলেই সেটি Enterprise account হয়ে যায় না। 13

দুই ক্ষেত্রেই প্রাসঙ্গিক প্রশ্ন হলো, নির্বাচিত mode এবং account কী বদলায়—পণ্যের নাম দেখে যা বোঝায় বলে মনে হয়, তা নয়।

Manus এবং Muse: private workspaces-এরও স্পষ্ট boundary দরকার।

Manus বলছে, share না করা হলে individual tasks private থাকে। এর Team documentation-এ আরও ব্যাখ্যা করা হয়েছে যে owners দলীয় session content-এ access করতে পারেন। এগুলো উপকারী visibility rules, কিন্তু এগুলো individual training policy প্রতিষ্ঠা করে না। এই পর্যালোচনার জন্য সম্পূর্ণ Manus privacy page উদ্ধার করা যায়নি, তাই অন্য কোনো plan থেকে তা পূরণ না করে প্রশ্নটি যাচাইহীনই রাখা হয়েছে। 14, 15

Muse-এর launch documentation operational restrictions এবং technical prevention-এর পার্থক্য নিয়ে অস্বাভাবিকভাবে স্পষ্ট। Meta বলছে, launch-time Secure VM নীতিমালার মাধ্যমে staff access সীমিত করে, কিন্তু service পরিচালনা, support, বা security নিশ্চিত করতে প্রয়োজন হলে access পুরোপুরি ঠেকায় না। operator access-কে cryptographically প্রতিরোধ করার উদ্দেশ্যে একটি Confidential VM আসছে বলে বর্ণনা করা হয়েছিল এবং সেটি সীমিত পরীক্ষায় ছিল। পরিকল্পিত সুরক্ষাকে এমন কিছু হিসেবে ধরা উচিত নয়, যা ইতিমধ্যেই সবার জন্য উপলভ্য। 16

Muse আরও একটি কাজ করে: এটি আসল connector credentials-কে তার main agent থেকে দূরে রাখে এবং action approvals-কে আলাদা permission authority-এর অধীনে রাখে। এটি একটি মূল্যবান নীতি দেখায়: কেবল সুবিধাজনক হতে পারে বলেই কোনো agent-এর হাতে একটি secret বা permission তুলে দেওয়া উচিত নয়। 16

সুরক্ষা এক্সপোজারের আগের ধাপে নিয়ে যান

training exclusion ডেটার একটি ব্যবহারকে নিয়ন্ত্রণ করে। masking processing-এর জন্য উপলভ্য ডেটাকেই বদলে দেয়। restricted retention অবশিষ্ট কপির সংখ্যা কমায়। permission controls সীমিত করে একটি agent কী করতে পারে। এই সুরক্ষাগুলো পরস্পর-পরিপূরক, এবং প্রতিটি কোন ধাপে কাজ করে তা গুরুত্বপূর্ণ।

একটি উদাহরণধর্মী অনুরোধ বিবেচনা করুন: কোনো নির্দিষ্ট ইমেইল ঠিকানায় একজন ক্লায়েন্টকে ফলো-আপ লিখতে হবে। মডেলের হয়তো উদ্দেশ্য, টোন এবং প্রাসঙ্গিক অঙ্গীকারগুলো জানা দরকার। কিন্তু বার্তাটি খসড়া করতে ক্লায়েন্টের আসল নাম বা ঠিকানা তার প্রয়োজন নাও হতে পারে। ইনফারেন্সের আগে শনাক্ত হওয়া ওই পরিচায়কগুলোকে প্লেসহোল্ডার দিয়ে বদলে দিলে, কাজের উপযোগী কাঠামো অক্ষুণ্ণ রেখেই মডেলের কাছে পৌঁছানো তথ্য কমানো যায়।

এটি মূল লেখাটি পাঠিয়ে পরে কোনো এক পর্যায়ে পরিচায়কগুলো সরিয়ে ফেলার প্রতিশ্রুতি দেওয়ার থেকে আলাদা।

একই নীতি ব্যক্তিগত পরিচায়কের বাইরেও প্রযোজ্য। গোপনীয় গবেষণার ক্ষেত্রে গবেষণার বিষয়বস্তুর ওপরই নিয়ন্ত্রণ দরকার; সংযুক্ত অ্যাকাউন্টের জন্য দরকার সীমিত-পরিসরের অনুমতি; সংরক্ষিত রেকর্ডের জন্য দরকার নির্ধারিত মেয়াদ এবং কার্যকর প্রবেশাধিকার-নিয়ন্ত্রণ। পরিচয় আড়াল করা এই নকশার একটি উপাদান, কোনো উদ্ভাবন বা নথির মূল বিষয়বস্তু সুরক্ষার বিকল্প নয়।

শিল্পজুড়ে এ বিষয়ে প্রাসঙ্গিক কাজ হচ্ছে। OpenAI এপ্রিল 2026-এ স্থানীয়ভাবে চালানো যায় এমন একটি Privacy Filter প্রকাশ করেছে, আর Meta-এর Muse ডকুমেন্টেশনে প্রযুক্তিগত বিচ্ছিন্নতা এবং উন্নয়নাধীন আরও শক্তিশালী confidential-computing নকশার বর্ণনা আছে। এসব উদ্যোগ সিস্টেমের ভেতরেই গোপনীয়তা প্রকৌশলগতভাবে গড়ে তোলার পক্ষে যুক্তি জোরদার করে। তবে কোনো টুল প্রকাশ বা রোডম্যাপ নিজে থেকেই এই প্রমাণ নয় যে প্রতিটি ভোক্তা-স্তরের কথোপকথন ইতিমধ্যে সেই সুরক্ষা পাচ্ছে। 16, 19

মানদণ্ড হওয়া উচিত, মানুষ আজ যে পণ্যটি ব্যবহার করছে তাতে সে কী ধরনের সুরক্ষা পাচ্ছে।

Dvina: স্বাভাবিক ইন্টারঅ্যাকশনের অংশ হিসেবে গোপনীয়তা

Dvina-এর পদ্ধতি এই আগাম সুরক্ষাকে সহকারীর অভিজ্ঞতার ভেতরে নিয়ে আসে। এর নথিভুক্ত নকশা অনুযায়ী, মানুষ টাইপ করার সময় বা কনটেন্ট আপলোড করার সময় সংবেদনশীল ব্যক্তিগত তথ্য স্থানীয়ভাবে শনাক্ত করা হয়, শনাক্ত ব্যক্তিগত ডেটা এনক্রিপ্ট করা হয়, এবং মডেল প্রক্রিয়াকরণের আগে প্লেসহোল্ডার বসানো হয়। মডেলটি মূল শনাক্ত পরিচায়কের বদলে ওই প্লেসহোল্ডার নিয়েই কাজ করে। 17, 18

পার্থক্যটি বাস্তব। ব্যবহারকারীকে যেন প্রতিটি কাজ থামিয়ে হাতে-কলমে নাম ও যোগাযোগের তথ্য মুছে ফেলতে না হয়, বা মডেল তথ্য পাওয়ার পর কী হবে—শুধু সেই প্রতিশ্রুতির ওপর নির্ভর করতে না হয়। সুরক্ষা ইন্টারঅ্যাকশনের সঙ্গেই থাকা উচিত।

Dvina ব্যবহারকারীর কথোপকথন, ফাইল, prompts, এবং workspace data-ও মডেল প্রশিক্ষণ থেকে বাদ দেয়। এই সমন্বয়টি গুরুত্বপূর্ণ: no-training অঙ্গীকার পুনর্ব্যবহার সীমিত করে, আর pre-processing সুরক্ষা প্রথমেই মডেলের সামনে উন্মুক্ত হওয়া ব্যক্তিগত তথ্যের পরিমাণ কমায়। 17, 18

এই পদ্ধতিকে আরও কিছু স্তর সমর্থন করে। Dvina এনক্রিপ্টেড কথোপকথন-সংরক্ষণ, সংরক্ষিত বার্তা ও ব্যবহারকারীর পরিচয়ের মধ্যে পৃথকীকরণ, এবং GDPR-স্তরের সুরক্ষাসহ EU-hosted data-এর কথা বর্ণনা করে। প্রতিটি স্তর তথ্য-ব্যবস্থাপনার আলাদা অংশকে সমাধান করে; পুরো বোঝা একটিমাত্র training preference-এর ওপর চাপিয়ে দেয় না। 17, 18

প্রযুক্তিগত পার্থক্যটি নির্দিষ্ট: মডেলের ইনপুটে শনাক্ত ব্যক্তিগত পরিচায়কগুলো প্রতিস্থাপিত হয়, কিন্তু আশপাশের কাজটি প্রক্রিয়াকরণের জন্য উপলভ্য থাকে। ফলে গোপনীয়তা ডেটা-প্রবাহের অংশ হয়ে ওঠে, কেবল এমন একটি preference হয়ে থাকে না যা ব্যবহারকারীকে মনে রেখে সামলাতে হবে।

আমার কাছে AI-এর জন্য এটিই বেশি কার্যকর দিক: মানুষ যেন তাদের কাজের জন্য অর্থবহ প্রেক্ষাপট আনতে পারে, আর সিস্টেমটি এমনভাবে নকশা করা হয় যাতে কাজের প্রয়োজনের তুলনায় তাদের পরিচয়ের কম অংশ প্রকাশ পায়।

উপসংহার: মানুষ AI-কে জীবনে কতদূর ঢুকতে দেবে, তা নির্ধারণ করবে গোপনীয়তা

AI সহকারীরা আমাদের পরিস্থিতি যত বেশি বোঝে, তত বেশি উপকারী হয়ে ওঠে। আর সেটিই সেই বোঝাপড়ার পেছনের তথ্য সুরক্ষার দায়িত্ব তৈরি করে। মানুষের কাছ থেকে আরও বেশি প্রবেশাধিকার চেয়ে তার বদলে শুধু আরেকটি settings page দেওয়া যথেষ্ট উত্তর নয়।

প্রমাণ কয়েকটি স্বতন্ত্র ঝুঁকির দিকে ইঙ্গিত করে। সফটওয়্যার অ্যাকাউন্টের মধ্যে ডেটা উন্মুক্ত করে দিতে পারে। সংরক্ষিত কথোপকথন আইনি দাবির আওতায় আসতে পারে। নিরাপত্তা লঙ্ঘন না ঘটলেও অনুমোদিত পর্যালোচনা থাকতে পারে। আর ব্যক্তিগত গবেষণা নিয়ে বিরোধ, অভিযোগ স্বাধীনভাবে প্রতিষ্ঠিত না হলেও, আস্থাকে দুর্বল করতে পারে।

এই ঝুঁকিগুলোর জন্য শুধু ভালো ভাষা নয়, প্রকৌশলগত কাজ দরকার। সংবেদনশীল ডেটা শনাক্তকরণ, pre-processing সুরক্ষা, পরিচয়ের পৃথকীকরণ, সীমিত সংরক্ষণ, এবং কার্যকরভাবে প্রয়োগযোগ্য অনুমতিকে AI নিরাপত্তার মৌলিক সক্ষমতা হিসেবে ধারাবাহিক গুরুত্ব দেওয়া উচিত। একজন সহকারীর উপযোগিতা এবং তার ব্যবহারকারীর সুরক্ষা—দুটোকেই একসঙ্গে এগোতে হবে।

Dvina-এর মাধ্যমে আমরা সেই পরিবর্তনের নেতৃত্ব দিতে সহায়তা করছি, কারণ মডেল প্রক্রিয়াকরণের আগের সুরক্ষাকে আমরা পণ্যের ভিত্তির অংশ করছি। লক্ষ্যটি আরও জোরালো দাবি করে বেশি আস্থা চাওয়া নয়। বরং এমনভাবে ব্যবস্থা করা, যাতে আস্থার যতটা অংশ শুধু প্রতিশ্রুতির ওপর নির্ভর করে থাকতে হয়, তা কমে আসে।

মানুষ যেন সাহায্য চাইতে পারে, একটি ধারণা বিকাশ করতে পারে, এবং এগিয়ে যেতে যে প্রেক্ষাপট দরকার তা ভাগ করতে পারে—প্রতিটি কথোপকথনকে নিজের গোপনীয়তা সমর্পণের সম্ভাব্য মুহূর্ত হিসেবে না দেখে। AI-এর সামনে থাকা সবচেয়ে গুরুত্বপূর্ণ কাজগুলোর একটি হলো এই আস্থা গড়ে তোলা।

উৎস ও পরিসর

22 September 2026 তারিখে উৎসসমূহ পর্যালোচনা করা হয়েছে। এই নিবন্ধটি প্রদানকারীর ডকুমেন্টেশন এবং সূত্র-উল্লেখসহ প্রকাশিত প্রতিবেদনের ওপর ভিত্তি করে; এটি কোনো স্বাধীন নিরাপত্তা নিরীক্ষা নয়। তুলনার প্রধান পরিসর হলো individual plans। Commercial, API, এবং model-specific exceptions আলাদাভাবে চিহ্নিত করা হয়েছে। গণিত-সংক্রান্ত অংশে প্রতিবেদনভিত্তিক উদ্বেগ এবং OpenAI-এর হালনাগাদ প্রতিক্রিয়ার মধ্যে পার্থক্য করা হয়েছে; কোনোটিকেই স্বাধীন অনুসন্ধান হিসেবে উপস্থাপন করা হয়নি। Manus-এর individual-plan training rule এখনো যাচাই করা যায়নি, কারণ তাদের পূর্ণ privacy policy উদ্ধার করা সম্ভব হয়নি।

1. OpenAI: মার্চ 2023-এর ChatGPT ঘটনার প্রকাশ
2. OpenAI: 2025 সালের সংরক্ষণ আদেশ এবং অক্টোবরের আপডেট
3. Reuters: 20 million অ্যানোনিমাইজড লগ সম্পর্কিত ডিসেম্বর 2025-এর আদেশ
4. OpenAI: ভোক্তা-সংক্রান্ত ট্রেনিং, অনুমোদিত অ্যাক্সেস, এবং মুছে ফেলা
5. OpenAI: ChatGPT, Codex, এবং Temporary Chat নিয়ন্ত্রণসমূহ
6. Anthropic: ভোক্তা-সংক্রান্ত ট্রেনিং, ফিডব্যাক, এবং Incognito
7. Anthropic: ভোক্তা-সংক্রান্ত সংরক্ষণ এবং মুছে ফেলা
8. Anthropic: কর্মীদের অ্যাক্সেস সীমাবদ্ধতা এবং ব্যতিক্রমসমূহ
9. Anthropic: Covered Models-এর সংরক্ষণ-সংক্রান্ত প্রয়োজনীয়তা এবং ডিপ্লয়মেন্টের পরিসর
10. Andrew Cullen / The Conversation, Singularity Hub-এ পুনঃপ্রকাশিত: গণিতবিষয়ক বিতর্ক
11. OpenAI: Navier–Stokes ঘোষণা এবং 10 September প্রতিক্রিয়া আপডেট
12. Cursor: data-use মোড, backend processing, এবং ব্যতিক্রমসমূহ
13. Perplexity: ভোক্তা ডেটা সংগ্রহ এবং Enterprise-এর পার্থক্যসমূহ
14. Manus: individual এবং Team task visibility
15. Manus: প্ল্যানের বৈশিষ্ট্যসমূহ, যার মধ্যে Team training opt-out অন্তর্ভুক্ত
16. Meta: Muse launch architecture, training practices, এবং Confidential VM পরিকল্পনা
17. Dvina: গোপনীয়তা নীতি
18. Dvina: গোপনীয়তা নকশা এবং pre-processing সুরক্ষা
19. OpenAI: Privacy Filter প্রকাশ এবং এর নির্ধারিত ব্যবহারসমূহ