একটি AI-চালিত সাপোর্ট সিস্টেম যা মডেল-আউটপুট পর্যায়ে সুরক্ষিত বলে মনে করা হয়েছিল, সেটি "সাইড ডোর"-এর মাধ্যমে গ্রাহকের তথ্য ফাঁস করছিল, যা প্রম্পটে CRM রেকর্ড সরবরাহ করে। এর নির্মাতার পোস্ট-মর্টেম থেকে দেখা যায় যে, মডেলটি যে টেক্সট তৈরি করে তা রক্ষা করাই যথেষ্ট নয় – ইনবাউন্ড রিকোয়েস্ট, ইন্টারনাল টুল থেকে আনা ডেটা এবং চূড়ান্ত এমিশন – এই সবগুলোর জন্য স্বতন্ত্র সুরক্ষা প্রয়োজন; অন্যথায় একটি ব্যবসা মডেল-আউটপুট লঙ্ঘন ছাড়াই নাম, ইমেল এবং আইডি প্রকাশ করে ফেলতে পারে।

কেন এই তিনটি সীমানা গুরুত্বপূর্ণ

বেশিরভাগ অপারেটর মনে করেন যে ল্যাঙ্গুয়েজ মডেল যখন তার দেখা কোনো গোপন তথ্য পুনরায় প্রকাশ করে তখনই তথ্য ফাঁস হয়। বাস্তবে, সবচেয়ে বড় ঝুঁকি তৈরি হয় মডেলটি ডেটা দেখার আগেই। একটি AI এজেন্ট তিন ধরনের তথ্যের প্রবাহ গ্রহণ করে:

  • Ingress – গ্রাহক যে র (raw) কুয়েরি টাইপ করেন।
  • Return path – এজেন্ট যে তথ্য ডাউনস্ট্রিম সিস্টেম (যেমন CRM) থেকে সংগ্রহ করে।
  • Emission – মডেলটি ব্যবহারকারীকে যে টেক্সট প্রদান করে।

যদি এই প্রবাহগুলোর যেকোনো একটিতে অরক্ষিত আইডেন্টিফায়ার (identifiers) থাকে, তবে আউটপুট লেয়ার ফিল্টার করা থাকলেও এজেন্ট অনিচ্ছাকৃতভাবে সেগুলো তার উত্তরের মধ্যে অন্তর্ভুক্ত করে ফেলতে পারে।

ডেমো থেকে প্রোডাকশন: কঠিন অভিজ্ঞতা থেকে পাওয়া শিক্ষা

একটি প্রোটোটাইপকে লাইভ হেল্প ডেস্কে নিয়ে যাওয়ার সময় এমন কিছু বাস্তব ব্যর্থতা ধরা পড়েছে যা কেবল একটি সাধারণ “redact-then-send” পদ্ধতি দিয়ে এড়ানো সম্ভব ছিল না।

  • Redact করার পরিবর্তে Tokenize করুন – মডেলের কাছে পৌঁছানোর আগেই নাম বা ইমেল মুছে ফেললে সিস্টেমটি সঠিক উত্তর তৈরি করতে পারে না। মূল ভ্যালুটি একটি নিরাপদ ভল্টে (vault) সংরক্ষণ করুন, প্রম্পটে সেটিকে একটি র‍্যান্ডম UUID দিয়ে প্রতিস্থাপন করুন এবং মডেলের কাজ শেষ হওয়ার পর UUID-টি পুনরায় আসল ভ্যালু দিয়ে বদলে দিন। এটি কার্যকারিতা বজায় রেখে মডেলের কনটেক্সট থেকে র (raw) ডেটা দূরে রাখে।

  • Checksum দিয়ে আইডেন্টিফায়ার যাচাই করুন – একটি রেগুলার এক্সপ্রেশন (regular expression) অ্যাকাউন্ট নম্বরের মতো দেখতে স্ট্রিং শনাক্ত করতে পারে; কিন্তু একটি checksum নিশ্চিত করে যে এটি একটি প্রকৃত আইডি কি না। একটি checksum ফিল্টার এজেন্টকে যেকোনো এলোমেলো সংখ্যাকে সংবেদনশীল ডেটা হিসেবে গণ্য করা থেকে বিরত রাখে, যা অপ্রয়োজনীয় রিডাকশন (redaction) বা তথ্য গোপনের ঘটনা কমিয়ে দেয়।

  • ওভারল্যাপিং স্প্যানগুলো (overlapping spans) মার্জ করুন – গ্রাহকের রেকর্ডে প্রায়ই একটি নামের পরে ইমেল ঠিকানা থাকে যেখানে কিছু অক্ষর মিলে যেতে পারে (যেমন, “John Doe john.doe@example.com”)। শুধুমাত্র নামটিকে টোকেনাইজ করলে ইমেলের অংশটি প্লেইন টেক্সট হিসেবে থেকে যায়, যা আউটপুটে চলে আসতে পারে। সম্পূর্ণ ওভারল্যাপিং অঞ্চলটিকে একটি একক টোকেন হিসেবে বিবেচনা করুন।

  • সঠিক সীমানা পরীক্ষা করুন – শুধুমাত্র এমিশন লেয়ার পরীক্ষা করে পাস হওয়া টেস্ট একটি মিথ্যা নিরাপত্তার অনুভূতি দেয়। রিটার্ন পাথে (return path) তথ্য ফাঁস শনাক্ত করতে পারে এমন একটি ফেইল হওয়া টেস্ট প্রকৃত সমাধান নিশ্চিত করে। এমন টেস্ট স্যুট ডিজাইন করুন যা স্পষ্টভাবে তিনটি সীমানার প্রতিটি যাচাই করে।

  • Ground truth ট্র্যাক করুন – যখন একজন মানুষ AI-জেনারেটেড ড্রাফট পাঠানোর আগে সেটি এডিট করেন, তার মানে মডেলটি ইতিমধ্যে একটি ত্রুটিপূর্ণ উত্তর তৈরি করে ফেলেছে। AI-এর ড্রাফটের সাথে মানুষের অনুমোদিত চূড়ান্ত বার্তার তুলনা করলে কনফিডেন্স গ্যাপ (confidence gaps) বোঝা যায় এবং সিস্টেমটিকে ভুল পুনরাবৃত্তি করা থেকে বিরত রাখা যায়।

ব্যবসার জন্য এর গুরুত্ব

কাস্টমার-সার্ভিস AI এজেন্টগুলো পাবলিক ইন্টারঅ্যাকশন এবং ইন্টারনাল ডেটা স্টোরের সংযোগস্থলে অবস্থান করে।

পাল্টা যুক্তি: কেন কেউ কেউ এখনও রিডাকশন (redaction)-কে প্রাধান্য দেন

সারসংক্ষেপ

একটি AI-চালিত কাস্টমার-সার্ভিস এজেন্টকে সুরক্ষিত করা কোনো একক দরজার সমস্যা নয়। ইনবাউন্ড রিকোয়েস্ট, ইন্টারনাল সিস্টেম থেকে আনা ডেটা এবং আউটবাউন্ড টেক্সটকে আলাদা দেয়াল হিসেবে বিবেচনা করুন; যেকোনো একটিতে লঙ্ঘন ঘটলেই পুরো পরিষেবাটি ঝুঁকির মুখে পড়বে। সংবেদনশীল ফিল্ডগুলোকে টোকেনাইজ করা, আইডেন্টিফায়ার যাচাই করা, ওভারল্যাপিং স্প্যান মার্জ করা, সঠিক সীমানা পরীক্ষা করা এবং ক্রমাগত AI ড্রাফটের সাথে মানুষের পাঠানো চূড়ান্ত বার্তার তুলনা করা হলো সেই ব্যবহারিক পদক্ষেপ যা একটি “copilot”-কে একটি নির্ভরযোগ্য এবং এজেন্টিক (agentic) পরিষেবাতে রূপান্তরিত করে।