পেশাগত নৈতিকতা — ACM/IEEE code, privacy, accessibility আর AI-সহায়তায় দায়িত্ব

১ · কেন software engineering-এ নৈতিকতা — কোডের সিদ্ধান্ত মানুষের জীবনে

এই কোর্সের প্রায় সব পর্ব “কীভাবে” প্রশ্নের উত্তর দিয়েছে: কীভাবে requirement লিখবেন, কীভাবে নকশা করবেন, কীভাবে test আর release করবেন। এই পর্বের প্রশ্ন আলাদা: করা উচিত কি না, আর কার জন্য। পেশাগত নৈতিকতা (professional ethics) মানে একটি পেশার মানুষ কাজের সময় কোন আচরণকে ঠিক আর কোনটিকে ভুল ধরবেন, তার নীতি।

Software আজ চারটি বড় জায়গায় মানুষের জীবনে সরাসরি হাত দেয়:

আইন মানা আর নৈতিক হওয়া এক জিনিস নয়

আইন সাধারণত সমাজের ন্যূনতম শর্ত, আর প্রযুক্তির চেয়ে ধীরে চলে। Subscription এক ক্লিকে নেওয়া আর বাতিল করতে সাত পাতা ঘোরানো অনেক জায়গায় আইনসিদ্ধ, কিন্তু নৈতিকভাবে প্রশ্নবিদ্ধ; আবার নতুন ধরনের AI feature-এর জন্য অনেক দেশে এখনো নির্দিষ্ট আইনই নেই — তখন সিদ্ধান্ত নিতে হয় পেশাগত নীতি দিয়ে।

২ · ACM/IEEE-CS Software Engineering Code — আটটি নীতি, কেন্দ্রে জনস্বার্থ

১৯৯০-এর দশকে ACM আর IEEE Computer Society একটি যৌথ task force গঠন করে। তাদের লেখা Software Engineering Code of Ethics and Professional Practice-এর সংস্করণ ৫.২ ১৯৯৯ সালে দুই সংগঠনই গ্রহণ করে। এর দুটি রূপ আছে: একটি সংক্ষিপ্ত রূপ, যেখানে আটটি নীতির প্রতিটি এক বাক্যে; আর একটি পূর্ণ রূপ, যেখানে প্রতিটি নীতির নিচে অনেকগুলো নির্দিষ্ট ধারা (clause). ভূমিকায় বলা আছে, এটি কোনো যান্ত্রিক নিয়মের বই নয় — বিচারবুদ্ধি দিয়ে প্রয়োগের নির্দেশিকা, আর সব নীতির মধ্যে জনস্বার্থ (public interest) সবচেয়ে গুরুত্বপূর্ণ।

নিচের তালিকায় প্রতিটি নীতির সংক্ষিপ্ত রূপ নিজের ভাষায় (হুবহু অনুবাদ নয়), আর দৈনন্দিন কাজে তা কী চায়। মূল ইংরেজি লেখা ACM-এর ওয়েবসাইটে বিনামূল্যে পড়া যায় — পরীক্ষা বা উদ্ধৃতির আগে সেখান থেকে মিলিয়ে নিন।

ACM Code of Ethics (২০১৮) — সব computing পেশাজীবীর জন্য

SE Code শুধু software engineering-এর জন্য। এর পাশাপাশি ACM-এর সাধারণ Code of Ethics and Professional Conduct আছে, যার আগের রূপ ছিল ১৯৯২ সালের, আর বড় হালনাগাদ ২০১৮ সালে। এর প্রথম অংশে আছে মানুষের কল্যাণে অবদান, ক্ষতি এড়ানো, সততা, ন্যায্যতা ও বৈষম্য না করা, নতুন ধারণার পেছনের শ্রমকে সম্মান, privacy আর গোপনীয়তা রক্ষা; পরের অংশে system-কে শক্তভাবে এবং ব্যবহারযোগ্যভাবে নিরাপদ করার দায়িত্ব। IEEE আর বিভিন্ন দেশের পেশাজীবী সংগঠনেরও (যেমন যুক্তরাজ্যের BCS) নিজস্ব আচরণবিধি আছে।

এই code-গুলো আইন নয়, তবে এদের আসল শক্তি হলো: চাপের মুহূর্তে আপনি একটি স্বীকৃত, লিখিত মানদণ্ড দেখিয়ে বলতে পারেন, “এটা শুধু আমার ব্যক্তিগত মত নয়।”

৩ · নৈতিক দ্বিধায় সিদ্ধান্ত — ছয় ধাপের কাঠামো

বাস্তবের কঠিন প্রশ্নগুলো প্রায় কখনো “ভালো বনাম খারাপ” নয়; বেশিরভাগই নৈতিক দ্বিধা (ethical dilemma) — দুটি ভালো জিনিসের মধ্যে টানাপোড়েন: সময়মতো ডেলিভারি বনাম নিরাপত্তা, গ্রাহকের গোপনীয়তা বনাম সহকর্মীর প্রতি আনুগত্য, চাকরি রক্ষা বনাম জনগণের ক্ষতি ঠেকানো। আবেগের মুহূর্তে ভালো সিদ্ধান্ত নিতে একটি লিখিত কাঠামো সাহায্য করে। নৈতিকতার বিভিন্ন বইয়ে নানা রকম কাঠামো আছে; নিচেরটি তাদের সাধারণ সারাংশ:

ছয়টি ধাপ: তথ্য (কোনটা জানা, কোনটা অনুমান) → stakeholder (কারা প্রভাবিত, বিশেষ করে যাঁরা আলোচনায় নেই) → বিকল্প (অন্তত তিনটি, শুধু হ্যাঁ-না নয়) → পরিণতি (কার কী ক্ষতি, ফেরানো যায় কি না) → নীতি মেলানো (SE Code, আইন, প্রতিষ্ঠানের নিয়ম) → সিদ্ধান্ত, কাজ আর লিখে রাখা (issue, email বা ADR-এর মতো নথি — পর্ব ৩৮)। নীতি মেলানোর সময় দুটি সহজ পরীক্ষা কাজে দেয়: প্রকাশ্যতার পরীক্ষা — কাল খবরের কাগজে ছাপা হলে কি সিদ্ধান্তটির পক্ষে দাঁড়াতে পারবেন? উল্টো আসনের পরীক্ষা — আপনি ক্ষতিগ্রস্ত মানুষটি হলে কী চাইতেন? নিচের stepper-এ একটি কাল্পনিক ঘটনায় কাঠামোটি প্রয়োগ করা হয়েছে।

Feature : শিশুর ওজন দিয়ে ওষুধের ডোজ হিসাব (হাসপাতালের নার্সদের জন্য)
Bug     : ওজন 10 kg-এর কম হলে দশমিক ভুলভাবে round হয়
          যেমন 7.5 kg → হিসাব হয় 8 kg ধরে (প্রায় 7% বেশি ডোজ)
Test    : 3টি ব্যর্থ test, issue #212-এ লেখা
চাপ     : বৃহস্পতিবার release, গ্রাহক হাসপাতালের সাথে চুক্তি

শিশু রোগী ও পরিবার → সবচেয়ে বেশি ঝুঁকি, কণ্ঠ নেই
নার্স ও ডাক্তার     → app-এর ওপর ভরসা করবেন
হাসপাতাল (গ্রাহক)   → সময় চান, ক্ষতিতে দায় তাঁদেরও
প্রতিষ্ঠান, দল, আপনি → চুক্তি, সুনাম, পেশাগত দায়

A. যেমন আছে ship, পরে patch
B. ship, কিন্তু 10 kg-এর কম ওজনে হিসাব বন্ধ (feature flag)
   + স্পষ্ট বার্তা: "এই ওজনে হাতে হিসাব করুন"
C. release এক সপ্তাহ পিছানো, bug ঠিক করে পুরো test
D. চুপচাপ ship, issue বন্ধ করে দেওয়া   ← বিকল্পই নয়

A: অতিরিক্ত ডোজ → শিশুর ক্ষতি; ফেরানো যায় না
B: সময়মতো release; বার্তা স্পষ্ট হলে ঝুঁকি প্রায় শূন্য
C: সবচেয়ে নিরাপদ; দেরি, টাকা ও সুনামের খরচ
D: A-র সব ঝুঁকি + লুকানো

১ Public   : নিরাপদ বিশ্বাস না হলে অনুমোদন নয় → A, D বাদ
২ Client   : ঝুঁকি জানানোই গ্রাহকের আসল স্বার্থ
৪ Judgment : চাপে পড়ে "সব ঠিক" সই নয়

প্রস্তাব : B এখনই, C-র কাজ পরের সপ্তাহে
কারণ    : A-তে অপূরণীয় ক্ষতির ঝুঁকি (SE Code ১.০৩, ১.০৪)
জানানো  : team lead, product manager, হাসপাতাল
যাচাই   : <10 kg ইনপুটে হিসাব বন্ধ থাকার test যোগ
যদি B প্রত্যাখ্যাত হয় → লিখিতভাবে পরের স্তরে (অংশ ৪)

৪ · কথা বলা, escalation আর whistleblowing — পেশা আর লাইসেন্স

সমস্যা দেখলে কথা বলার ধাপে ধাপে পথকে বলে escalation:

শেষ ধাপটিকে বলে whistleblowing. SE Code-এর পূর্ণ রূপে (Profession নীতির নিচে) বলা আছে, যাঁরা জড়িত তাঁদের সাথে আলোচনা অসম্ভব, অকার্যকর বা বিপজ্জনক হলে গুরুতর লঙ্ঘনের কথা উপযুক্ত কর্তৃপক্ষকে জানাতে হবে। কয়েকটি পরামর্শ:

• তথ্যে থাকুন, ব্যক্তিতে নয়: “এই তারিখে এই test ব্যর্থ, এই সিদ্ধান্ত হয়েছে।”
• প্রমাণ রাখুন, data নয়: নিজের পাঠানো email-এর তারিখ লিখে রাখুন, কিন্তু অনুমতি ছাড়া গ্রাহকের personal data বা গোপন কোড বাইরে নেবেন না — তাতে নতুন অন্যায় আর নিজের আইনি ঝুঁকি তৈরি হয়।
• আইনি সুরক্ষা দেশভেদে আলাদা: পদক্ষেপের আগে পরামর্শ নিন।
• দলের দায়ও আছে: যে দলে প্রশ্ন তোলা নিরাপদ (psychological safety) আর ভুলের পরে দোষারোপ নয়, ব্যবস্থার উন্নতি হয় (blameless culture, পর্ব ৪৪), সেখানে খুব কম সমস্যাই শেষ ধাপে পৌঁছায়।

আরেকটি উপেক্ষিত বিষয় স্বার্থের সংঘাত: vendor বাছাইয়ে একটি প্রার্থী প্রতিষ্ঠান আপনার আত্মীয়ের হলে আগেই লিখিতভাবে প্রকাশ করুন, প্রয়োজনে সিদ্ধান্ত থেকে সরে দাঁড়ান।

পেশা আর লাইসেন্স — দেশভেদে খুব আলাদা

সিভিল engineering-এ অনেক দেশে পেশাগত লাইসেন্স লাগে; software-এ চিত্র মিশ্র। নিয়ম বদলায় — সর্বশেষ অবস্থা যাচাই করুন।

লাইসেন্স নিয়ে বিতর্কের ইতিহাস ভাবনার প্রশ্ন ০২-এ।

৫ · Privacy — পরে জোড়া নয়, নকশা থেকেই

Privacy প্রায়ই release-এর আগের দিন মনে পড়ে, যখন অপ্রয়োজনীয় data আর log-এ ফোন নম্বর আগেই জমে গেছে। Privacy by design ধারণাটি এর উল্টো: privacy-কে শুরু থেকেই requirement আর নকশার অংশ ধরা। ধারণাটি পরিচিত Ann Cavoukian-এর নামে — কানাডার Ontario প্রদেশের Information and Privacy Commissioner হিসেবে তিনি ১৯৯০-এর দশক থেকে এটি প্রচার করেন, পরে সাতটি মূলনীতিতে সাজান (নিচে নিজের ভাষায়):

GDPR — বহুল-উল্লেখিত একটি আদর্শ

ইউরোপীয় ইউনিয়নের GDPR (General Data Protection Regulation) ২০১৬ সালে গৃহীত হয়, প্রযোজ্য হয় ২০১৮ সালের ২৫ মে থেকে। কিছু ক্ষেত্রে এটি ইউরোপের বাইরের প্রতিষ্ঠানেও প্রযোজ্য। এর Article 5-এর মূলনীতিগুলো privacy-র একটি ভালো চেকলিস্ট:

• বৈধতা, ন্যায্যতা ও স্বচ্ছতা — বৈধ ভিত্তি থাকা, ব্যবহারকারীকে ঠকানো নয়, খোলাখুলি জানানো।
• Purpose limitation — নির্দিষ্ট, ঘোষিত উদ্দেশ্যে সংগ্রহ; পরে বেমানান কাজে ব্যবহার নয়।
• Data minimisation — উদ্দেশ্যের জন্য যতটুকু দরকার, শুধু ততটুকু।
• নির্ভুলতা, সংরক্ষণের সীমা (দরকারের বেশি দিন নয়), অখণ্ডতা ও গোপনীয়তা (নিরাপত্তা), আর জবাবদিহি — নিয়ম মানছেন, তা দেখাতে পারা।

Article 25 সরাসরি “data protection by design and by default” দাবি করে। সম্মতি (consent) GDPR-এ processing-এর ছয়টি বৈধ ভিত্তির মাত্র একটি (অন্যগুলো চুক্তি, আইনি বাধ্যবাধকতা, জীবন রক্ষা, জনস্বার্থের কাজ আর বৈধ স্বার্থ)। সম্মতি নিলে তা হতে হবে স্বাধীন, নির্দিষ্ট, জেনে-বুঝে আর সক্রিয় পদক্ষেপে — আগে থেকে টিক দেওয়া বাক্স বা নীরবতা সম্মতি নয়, আর প্রত্যাহার দেওয়ার মতোই সহজ। ঝুঁকিপূর্ণ processing-এর আগে কিছু ক্ষেত্রে লিখিত মূল্যায়ন — DPIA — বাধ্যতামূলক।

Data minimisation — একটি form-এর নিরীক্ষা

একটি কাল্পনিক বাসের টিকিট কাটার form-এ দশটি field আছে। নিচের প্রোগ্রাম প্রতিটি field-কে ঘোষিত উদ্দেশ্যের সাথে মেলায়: কোনো উদ্দেশ্যে না লাগলে “সরান”, শুধু ঐচ্ছিক উদ্দেশ্যে লাগলে “ঐচ্ছিক, সম্মতি নিয়ে”।

// Data-minimisation audit for a FICTIONAL bus-ticket booking form.
const fields = ["name", "phone", "email", "nid", "date_of_birth",
  "father_name", "religion", "seat_pref", "home_address", "referral_code"];

// Each declared purpose lists the fields it truly needs.
const purposes = [
  { id: "ticket",   needs: ["name", "phone", "seat_pref"], optional: false },
  { id: "sms",      needs: ["phone"],                      optional: false },
  { id: "receipt",  needs: ["email"],                      optional: true },
  { id: "referral", needs: ["referral_code", "phone"],     optional: true },
];

function audit(fields, purposes) {
  const rows = [];
  for (const f of fields) {
    const users = purposes.filter(p => p.needs.includes(f));
    let verdict;
    if (users.length === 0) verdict = "REMOVE (no purpose)";
    else if (users.every(p => p.optional)) verdict = "optional + ask consent";
    else verdict = "keep";
    rows.push([f, users.map(p => p.id).join(",") || "-", verdict]);
  }
  return rows;
}

const rows = audit(fields, purposes);
for (const [f, used, v] of rows)
  console.log(f.padEnd(14), used.padEnd(20), v);
const removed = rows.filter(r => r[2].startsWith("REMOVE")).length;
console.log(`collect ${fields.length - removed} of ${fields.length} fields`);

name           ticket               keep
phone          ticket,sms,referral  keep
email          receipt              optional + ask consent
nid            -                    REMOVE (no purpose)
date_of_birth  -                    REMOVE (no purpose)
father_name    -                    REMOVE (no purpose)
religion       -                    REMOVE (no purpose)
seat_pref      ticket               keep
home_address   -                    REMOVE (no purpose)
referral_code  referral             optional + ask consent
collect 5 of 10 fields

এবার একটি নতুন feature-এ privacy by design ধাপে ধাপে প্রয়োগ করুন।

সংগ্রহ  : নাম, ফোন, রক্তের গ্রুপ, সবসময় GPS,
          শেষ রক্তদানের তারিখ, রোগের ইতিহাস
দেখানো  : সব কাছের দাতার নাম, ফোন, দূরত্ব
রাখা    : চিরকাল; অবস্থান শেয়ার default চালু

P1: জরুরি অবস্থায় কাছের উপযুক্ত দাতাকে অনুরোধ
P2: দাতা আবার রক্ত দিতে পারবেন কি না দেখা
"রোগের ইতিহাস" → কোনো উদ্দেশ্যে লাগে না

সবসময় GPS  → দাতার নিজের বাছাই করা এলাকা (থানা/ওয়ার্ড)
রোগের ইতিহাস → সংগ্রহ বন্ধ
শেষ রক্তদান  → তারিখ নয়, "আবার দিতে পারবেন: হ্যাঁ/না"
ফোন নম্বর    → রোগীর পরিবারকে সরাসরি দেখানো নয়

নতুন account : "দাতা হিসেবে দৃশ্যমান" = বন্ধ
অনুরোধ      : দাতাকে notification; "রাজি" চাপলে তবেই যোগাযোগ
বিরতি       : এক চাপে "৩০ দিন দেখাবেন না"

ফোন নম্বর  : encrypted; শুধু notification service পড়তে পারে
log        : ফোন বা নাম নয়, শুধু ছদ্ম-ID
অনুরোধের ইতিহাস : ৯০ দিন পরে মোছা (কাল্পনিক নিয়ম)
Account মুছলে : সব personal data মোছা, backup-এ মেয়াদসহ

"আপনার data" পাতা: কী, কেন, কতদিন — সহজ বাংলায়
Settings-এ এক জায়গায় সব; "সব data মুছুন" বোতাম
ফল: feature একই, ঝুঁকি অনেক কম (positive-sum)

৬ · নিরাপত্তা আর accessibility — দুটিই নৈতিক দায়িত্ব

নিরাপত্তা: অবহেলাও এক ধরনের ক্ষতি

Data breach-এ সবচেয়ে বেশি ক্ষতিগ্রস্ত হন নির্দোষ ব্যবহারকারীরা; তাই ACM-এর ২০১৮-র Code নিরাপত্তাকে পেশাগত দায়িত্ব বলে:

• জানা ঝুঁকি উপেক্ষা না করা: পুরোনো dependency বা খোলা admin পাতা জানা থাকলে লিখে রাখা আর ঠিক করার পরিকল্পনা।
• Secret কোডে নয়: পর্ব ৫৭-এ (Git-এ নিরাপত্তা) ফাঁস হওয়া secret সামলানো দেখেছেন; নকশার দিক System Design কোর্সের নকশায় নিরাপত্তা পর্বে।
• Log-এ personal data নয়: পুরো request log করলে OTP বা NID-ও চলে যায়।
• দায়িত্বশীল প্রকাশ: অন্যের system-এ দুর্বলতা চোখে পড়লে মালিককে গোপনে জানানো আর ঠিক করার সময় দেওয়া (coordinated vulnerability disclosure). অনুমতি ছাড়া অন্যের system পরীক্ষা করা বহু দেশে অপরাধ — নিজের বা অনুমতি পাওয়া system-এই security testing.

Accessibility: কাউকে বাদ না দেওয়া

পর্ব ৩-এ (Software quality) accessibility-কে quality-র অংশ হিসেবে দেখেছেন, আর ওয়েবের মানদণ্ড WCAG-এর কথা — লেখার সময়ে সর্বশেষ সংস্করণ WCAG 2.2, ২০২৩ সালে W3C-র recommendation (সর্বশেষ অবস্থা W3C-তে দেখুন)। নৈতিক দিকটি সরল: যে app একজন দৃষ্টিপ্রতিবন্ধী মানুষ screen reader দিয়ে চালাতে পারেন না, সেটি তাঁর জন্য একটি বন্ধ দরজা।

বাংলাদেশের প্রেক্ষাপটে “সবার জন্য” মানে কম দামের ফোন আর ধীর network-এও চলা, বাংলা screen reader-এ ঠিকমতো পড়া, বয়স্কদের জন্য সহজ ভাষা আর বড় বোতাম. বাস্তব HTML-এর জন্য HTML & CSS কোর্সের অ্যাক্সেসিবিলিটি পর্বে আছে। Accessibility-কে acceptance criteria আর CI-তে রাখুন।

৭ · Dark pattern — ঠকানো নকশা চেনা

২০১০ সালে UX বিশেষজ্ঞ Harry Brignull এমন UI নকশার জন্য “dark pattern” শব্দটি চালু করেন, যা ব্যবহারকারীকে ঠকিয়ে বা চাপ দিয়ে তাঁর নিজের ইচ্ছার বিরুদ্ধে কিছু করায়। পরে তিনি “deceptive design” নামটি বেশি ব্যবহার করেন (আমাদের জানামতে)। নিয়ন্ত্রকেরাও এ নিয়ে কাজ করছেন — যেমন যুক্তরাষ্ট্রের FTC-র ২০২২ সালের প্রতিবেদন, ইউরোপীয় ইউনিয়নের Digital Services Act-এর কিছু নিষেধাজ্ঞা; খুঁটিনাটি দেশভেদে আলাদা।

Dark pattern প্রায়ই শুরু হয় একটি metric থেকে — “sign-up rate বাড়ানো” — আর A/B test-এ হার বাড়লে সেটাই রয়ে যায়। Engineer হিসেবে কাজ: ticket-এ এমন কিছু এলে প্রশ্ন তোলা, আর review-তে একটি চেকলিস্ট রাখা। নিচে একটি খেলনা চেকলিস্ট-scorer:

// Toy dark-pattern checklist scorer. All three UI flows are FICTIONAL.
const flows = [
  { name: "shopA-checkout", newsletterPreChecked: true,
    declineText: "No thanks, I don't like saving money",
    shownPrice: 950, finalPrice: 1090, feesShownEarly: false,
    signupSteps: 2, cancelSteps: 7 },
  { name: "shopB-checkout", newsletterPreChecked: false,
    declineText: "No thanks", shownPrice: 950, finalPrice: 1000,
    feesShownEarly: true, signupSteps: 2, cancelSteps: 2 },
  { name: "appC-trial", newsletterPreChecked: false,
    declineText: "Maybe later", shownPrice: 0, finalPrice: 0,
    feesShownEarly: true, signupSteps: 1, cancelSteps: 5 },
];
const SHAME = /(don't|do not) (like|want|care)|i prefer paying more|i'm not smart/i;

const checks = [
  ["pre-checked consent", f => f.newsletterPreChecked],
  ["confirmshaming",      f => SHAME.test(f.declineText)],
  ["hidden costs",        f => f.finalPrice > f.shownPrice && !f.feesShownEarly],
  ["hard to cancel",      f => f.cancelSteps > 2 * f.signupSteps],
];

for (const f of flows) {
  const hits = checks.filter(([, test]) => test(f)).map(([label]) => label);
  const level = hits.length === 0 ? "clean" : hits.length === 1 ? "review" : "redesign";
  const why = hits.length ? " : " + hits.join("; ") : "";
  console.log(`${f.name.padEnd(15)} ${hits.length}/${checks.length} ${level}${why}`);
}

shopA-checkout  4/4 redesign : pre-checked consent; confirmshaming; hidden costs; hard to cancel
shopB-checkout  0/4 clean
appC-trial      1/4 review : hard to cancel

৮ · Algorithmic bias আর ন্যায্যতা — ফল মেপে দেখা

Algorithmic bias মানে software-এর সিদ্ধান্ত নিয়মিতভাবে কোনো গোষ্ঠীর প্রতি অন্যায্য ফল দেওয়া। এর জন্য machine learning লাগে না; সাধারণ নিয়মভিত্তিক কোডেও হয়। কয়েকটি সাধারণ উৎস:

• পুরোনো data-র পক্ষপাত: অতীতের সিদ্ধান্ত পক্ষপাতদুষ্ট হলে তা থেকে বানানো নিয়মও তা-ই করে।
• প্রতিনিধি নয় এমন data: শুধু শহরের ব্যবহারকারীদের নিয়ে পরীক্ষা (sampling bias).
• Proxy: ঠিকানা বা স্কুলের নাম লিঙ্গ, ধর্ম বা শ্রেণির প্রতিনিধি হয়ে যেতে পারে।
• ভুল লক্ষ্য: “app-এ কত সময়” মাপলে আসলে আসক্তির জন্য optimize করা হয়।

নিয়ম সবার জন্য একই হলেও ফল যদি কোনো গোষ্ঠীর ওপর অসমানুপাতিক খারাপ পড়ে, তাকে বলে disparate impact. এটি মাপার সবচেয়ে সহজ উপায় প্রতিটি গোষ্ঠীর selection rate তুলনা করা:

যুক্তরাষ্ট্রের ১৯৭৮ সালের Uniform Guidelines on Employee Selection Procedures-এ একটি মোটা দাগের নিয়ম আছে — four-fifths rule: কোনো গোষ্ঠীর হার সবচেয়ে বেশি হারের ৪/৫ (৮০%)-এর কম হলে সাধারণত তাকে বিরূপ প্রভাবের প্রমাণ হিসেবে দেখা হয়। মনে রাখুন, এটি একটি দেশের নিয়োগ-প্রেক্ষাপট থেকে আসা heuristic — প্রমাণ নয়, সব দেশের আইন নয়; ছোট সংখ্যায় পরিসংখ্যানগত তাৎপর্যও আলাদা করে দেখতে হয়। নিচে একটি কাল্পনিক CV-বাছাই tool-এর ফল:

from fractions import Fraction
# FICTIONAL applicants screened by a CV-ranking tool.
# One letter per applicant: Y = shortlisted, N = rejected.
APPLICANTS = {
    "city":          "YNYYNYNNYN" "YNNYYNNYNY" "YNYNYYNNYN" "NYNYNNYYNY",
    "district_town": "NYNNYNYNNY" "NNYNYNYYNN" "YNNYNNYNNY",
    "rural":         "NNYNNNYNNN" "YNNNNYNNNY" "NYNYNNNYNY",
}

def selection_rates(table):
    rates = {}
    for group, marks in table.items():
        chosen = marks.count("Y")
        rates[group] = (chosen, len(marks), Fraction(chosen, len(marks)))
    return rates

def four_fifths(rates, threshold=Fraction(4, 5)):
    best = max(r for _, _, r in rates.values())
    report = []
    for group, (chosen, total, r) in rates.items():
        ratio = r / best
        flag = "CHECK" if ratio < threshold else "ok"
        report.append((group, chosen, total, float(r), float(ratio), flag))
    return report

print(f"{'group':14} sel/total  rate  ratio  4/5-rule")
for g, c, t, r, ratio, flag in four_fifths(selection_rates(APPLICANTS)):
    print(f"{g:14} {c:3}/{t:<5} {r:5.2f}  {ratio:5.2f}  {flag}")
print("ratio < 0.80 is only a warning sign, not proof of bias")

group          sel/total  rate  ratio  4/5-rule
city            20/40     0.50   1.00  ok
district_town   12/30     0.40   0.80  ok
rural            9/30     0.30   0.60  CHECK
ratio < 0.80 is only a warning sign, not proof of bias

ন্যায্যতার একাধিক গাণিতিক সংজ্ঞা আছে — একই হারে বাছাই, একই ভুলের হার, একই নির্ভুলতা — আর গবেষণায় দেখানো হয়েছে, গোষ্ঠীভেদে মূল হার আলাদা হলে সবগুলো একসাথে পূরণ করা সাধারণত সম্ভব নয় (ভাবনার প্রশ্ন ০৩)। তাই সংজ্ঞা বাছাই নিজেই একটি নৈতিক সিদ্ধান্ত, যা লিখে রাখা দরকার। Machine learning-এর গভীর পদ্ধতি এই কোর্সের বাইরে।

পরিবেশের ওপর software-এর প্রভাব — সংক্ষেপে

Data center, network আর কোটি ফোন বিদ্যুৎ খরচ করে। Green software-এর চর্চা: অপ্রয়োজনীয় কাজ না করা, ছবি ও video ছোট রাখা, পুরোনো ফোনেও চলে এমন app. Green Software Foundation (২০২১)-এর মতো সংগঠন মাপার পদ্ধতি প্রস্তাব করছে; অনুমান পদ্ধতিভেদে আলাদা বলে এখানে সংখ্যা নেই।

৯ · Intellectual property — কার কোড, কোন শর্তে

Intellectual property (মেধাস্বত্ব) মানে সৃষ্টি আর উদ্ভাবনের ওপর আইনি অধিকার; আইন দেশভেদে আলাদা (বাংলাদেশের কপিরাইট আইনের সর্বশেষ রূপ যাচাই করুন)।

• আগের চাকরির কোড: আগের প্রতিষ্ঠানের কোড বা গ্রাহক-তালিকা নতুন জায়গায় নেওয়া যায় না — সাধারণত চুক্তি আর trade secret দুইয়েরই লঙ্ঘন; নেওয়া যায় শুধু অভিজ্ঞতা আর দক্ষতা।
• Internet থেকে কোড: প্রতিটি open source কোড একটি software license-এর শর্তে আসে; licence-এর ধরন পর্ব ৬৩-এ (দলগত কাজ আর open source). নৈতিক মূল কথা: শর্ত মানা আর কৃতিত্ব দেওয়া।

১০ · AI-এর যুগে — AI-সহায়তায় কোড লেখার দায়িত্ব

AI assistant এখন কোড, test আর commit বার্তা লেখে, কিন্তু SE Code-এর কোনো নীতিই দায় tool-এর ঘাড়ে দেয় না। ছয়টি দায়িত্ব:

1. যা commit করেন, তার মালিক আপনি: Commit-এ আপনার নাম (পর্ব ৮), review-তে আপনার সম্মতি।
2. সঠিকতা যাচাই: AI আত্মবিশ্বাসের সাথে না-থাকা function বা বানানো flag দিতে পারে (hallucination). নিজের edge case-সহ test চালান; AI-র test আসলে কিছু যাচাই করে কি না দেখতে পর্ব ৫০-এর mutation testing.
3. Prompt-এ secret আর personal data নয়: Prompt অন্য প্রতিষ্ঠানের server-এ যায়, আর সেখানে কীভাবে রাখা হয় তা tool ও চুক্তিভেদে আলাদা।
4. Licence আর copyright-এর অনিশ্চয়তা: AI-র কোড কখনো licence-ওয়ালা কোডের প্রায় হুবহু কপি হতে পারে; আর AI-তৈরি অংশের copyright কার বা আদৌ আছে কি না, তা নিয়ে দেশভেদে আইনি অবস্থান এখনো গড়ে উঠছে (যেমন যুক্তরাষ্ট্রের Copyright Office মানব-লেখকত্বের ওপর জোর দিয়ে নির্দেশনা দিয়েছে)। প্রতিষ্ঠানের নীতি মানুন।
5. দলের নিয়ম মেনে প্রকাশ: কোথাও PR-এ জানাতে হয়, কোথাও commit trailer-এ, কোথাও কিছু অবদানে AI নিষেধ। নিয়ম না থাকলে জিজ্ঞেস করুন।
6. অতিনির্ভরতা: সব কাজ AI-কে দিলে নিজের বোঝাপড়া দুর্বল হয়। Self নীতি আজীবন শেখার কথা বলে — AI সহকারী, বিকল্প মস্তিষ্ক নয়।

Prompt পাঠানোর আগে — একটি খেলনা PII redactor

একটি bug report AI-কে দেখাতে চান, কিন্তু তাতে গ্রাহকের তথ্য আছে। নিচের প্রোগ্রাম email, বাংলাদেশি ধাঁচের mobile নম্বর আর NID-কে চিহ্ন দিয়ে বদলায় (redaction). সব মান বানানো।

import re
# Toy PII redactor run BEFORE text is pasted into an AI tool.
# Every email, phone and NID below is FAKE, made up for this lesson.
PROMPT = """Bug: payment fails for customer Karim (karim.fake@example.com),
phone 01700-000001, NID 1234567890123. Retry from +8801800000002 also fails.
Order id 2026103012345 and error code 500 look normal.
Admin contact: support@example.org"""

RULES = [
    ("EMAIL", re.compile(r"\b[\w.+-]+@[\w-]+\.[\w.]+\b")),
    ("PHONE", re.compile(r"(?:\+?88)?01[3-9]\d{2}-?\d{6}\b")),
    ("NID",   re.compile(r"(?<=NID )\d{10}(?:\d{3}|\d{7})?\b")),
]

def redact(text):
    found = []
    for label, rx in RULES:
        def sub(m, label=label):
            found.append((label, m.group()))
            return f"[{label}]"
        text = rx.sub(sub, text)
    return text, found

clean, found = redact(PROMPT)
print(clean)
print("---")
for label, value in found:
    print(f"{label:5} removed ({len(value)} chars)")
print("names like 'Karim' are NOT caught: review by hand")

Bug: payment fails for customer Karim ([EMAIL]),
phone [PHONE], NID [NID]. Retry from [PHONE] also fails.
Order id 2026103012345 and error code 500 look normal.
Admin contact: [EMAIL]
---
EMAIL removed (22 chars)
EMAIL removed (19 chars)
PHONE removed (12 chars)
PHONE removed (14 chars)
NID   removed (13 chars)
names like 'Karim' are NOT caught: review by hand

AI-র লেখা কোড commit করার আগে — ধাপে ধাপে

+ def discount(total, code):
+     if code == "EID50":
+         return total * 0.5
+     return total
প্রশ্ন: total ঋণাত্মক হলে? code ছোট হাতে "eid50" হলে?
নিয়ম: প্রতিটি লাইন নিজে ব্যাখ্যা করতে না পারলে commit নয়

AI-র test   : assert discount(100, "EID50") == 50
যোগ করা test: 0, ঋণাত্মক, অজানা ও ছোট হাতের code, rounding
ফল          : rounding test ব্যর্থ → কোড ঠিক করা

☐ কোডে hard-coded key বা password নেই   (পর্ব ৫৭)
☐ log-এ গ্রাহকের ফোন বা NID ছাপা হয় না
☐ বাইরের input যাচাই হয়
☐ নতুন dependency? → নাম সত্যিই আছে কি না, licence, রক্ষণাবেক্ষণ

বড়, অস্বাভাবিক নিখুঁত অংশ? → হুবহু কপি কি না খোঁজা
কপি মিললে → licence মানা যায়? না হলে নিজে লেখা
প্রতিষ্ঠানের AI-নীতি মেনে tool বাছাই

commit বার্তার উদাহরণ (trailer-এর নাম দলভেদে আলাদা):

fix(cart): round Eid discount to whole taka

Handle lowercase codes and non-positive totals.
Assisted-by: AI code assistant (reviewed and tested)

commit-এ author: আপনার নাম
পরে bug এলে: "আমি merge করেছি, আমি দেখছি"
"AI লিখেছিল" কোনো ব্যাখ্যা নয়

নৈতিকতার প্রশ্নে AI-র চেনা ভুল

AI ব্যবহারের আগে-পরে — চেকলিস্ট

• Prompt-এ কোনো secret, গ্রাহকের personal data বা ভেতরের গোপন তথ্য নেই; redaction-এর পরে নিজে চোখ বুলিয়েছি
• AI-র কোডের প্রতিটি লাইন বুঝেছি, নিজের edge case-সহ test চালিয়েছি
• নতুন package বা API সত্যিই আছে, licence মানানসই — official docs-এ মিলিয়েছি
• AI-র উদ্ধৃত মানদণ্ড, আইন বা ধারা মূল উৎসে খুঁজে পেয়েছি; না পেলে বাদ দিয়েছি
• দলের নিয়ম অনুযায়ী PR বা commit-এ AI-র ব্যবহার জানিয়েছি, আর ফলের দায় নিজে নিচ্ছি