পাঠ ২৩ · ৫৭-এর মধ্যে · মডিউল ৫
Home / Courses / Ethics in Computing & AI Safety / ডিসিশন-মেকিং ফ্রেমওয়ার্ক

ইঞ্জিনিয়ারদের জন্য এথিক্যাল ডিসিশন-মেকিং ফ্রেমওয়ার্ক

Ethical decision-making frameworks for engineers
১০ মিনিট পড়া মধ্যম · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • কেন একটি পুনরাবৃত্তিযোগ্য প্রক্রিয়া সময়ের চাপে ভালো নৈতিক সিদ্ধান্তের সম্ভাবনা বাড়ায়
  • চার-ধাপের ফ্রেমওয়ার্ক — কীভাবে M1, M2 ও M5-এর প্যাটার্নগুলো একসাথে কাজ করে
  • কীভাবে ফ্রেমওয়ার্কগুলোর মধ্যে দ্বন্দ্ব (যেমন উপযোগবাদ বনাম ডিওন্টোলজি) একটি সিদ্ধান্তকে "আরও পর্যালোচনা প্রয়োজন" চিহ্নিত করার সংকেত হতে পারে
  • Python দিয়ে চেকলিস্টটিকে একটি বাস্তব, ধাপে-ধাপে চালিত ফাংশন হিসেবে প্রয়োগ করা

১ · কেন একটি পুনরাবৃত্তিযোগ্য প্রক্রিয়া দরকার

M2-এ (L05-L09) আমরা শিখেছি উপযোগবাদ, ডিওন্টোলজি, ভার্চু এথিক্স ও কন্ট্র্যাক্টুয়ালিজম — চারটি ভিন্ন লেন্স যা প্রায়ই ভিন্ন উত্তর দেয়। M1-এ (L03) স্টেকহোল্ডার বিশ্লেষণ, আর M5-এ (L20-L22) প্রফেশনাল কোড, কনফ্লিক্ট অফ ইন্টারেস্ট ও হুইসেলব্লোয়িং। বাস্তব কাজের চাপে, একজন ইঞ্জিনিয়ারের হাতে এই সব তত্ত্ব থেকে একটি সুসংগঠিত সিদ্ধান্তে পৌঁছানোর সময় খুব কম থাকে। একটি পুনরাবৃত্তিযোগ্য চেকলিস্ট সমাধান দেয় না, কিন্তু নিশ্চিত করে যে গুরুত্বপূর্ণ কোনো কোণ (স্টেকহোল্ডার, ফ্রেমওয়ার্ক, কোড, সমানুপাতিকতা) তাড়াহুড়োয় বাদ পড়ছে না।

একটি প্রস্তাবিত সিদ্ধান্ত ১ · স্টেকহোল্ডার শনাক্তকরণ কারা প্রভাবিত হবে, কীভাবে? (M1) ২ · একাধিক ফ্রেমওয়ার্ক প্রয়োগ উপযোগবাদ, নিয়ম, maximin (M2) ৩ · প্রফেশনাল কোড যাচাই ACM/IEEE থিম, COI (M5) ৪ · প্রোপোরশনালিটি সমস্যা বনাম হস্তক্ষেপের মাত্রা দ্বন্দ্ব/ফ্ল্যাগ পেলে পুনরায় ডিজাইন পর্যালোচনা
চারটি ধাপ ক্রমানুসারে প্রয়োগ করা হয়, কিন্তু কোনো ধাপে গুরুতর দ্বন্দ্ব বা লঙ্ঘন পাওয়া গেলে সিদ্ধান্তটি ডিজাইন পর্যালোচনায় ফিরিয়ে নেওয়া উচিত — চেকলিস্টটি একমুখী নয়, পুনরাবৃত্তিমূলক।

২ · চারটি ধাপ বিস্তারিত

১ · স্টেকহোল্ডার শনাক্তকরণ
শুধু সরাসরি ব্যবহারকারী নয়, পরোক্ষভাবে প্রভাবিত তৃতীয় পক্ষও (L03) — কে সবচেয়ে বেশি প্রভাবিত হবে অথচ সিদ্ধান্তে সবচেয়ে কম কণ্ঠস্বর রাখে?
২ · একাধিক ফ্রেমওয়ার্ক প্রয়োগ
শুধু একটি লেন্স ("এটি বেশিরভাগ মানুষের উপকার করবে") যথেষ্ট নয় — একটি হার্ড কনস্ট্রেইন্ট লঙ্ঘিত হচ্ছে কিনা এবং সবচেয়ে খারাপ-অবস্থানে থাকা পক্ষের কী হবে তাও দেখা দরকার (L05-L09)।
৩ · প্রফেশনাল কোড যাচাই
ACM/IEEE-এর সাধারণ থিম (ক্ষতি এড়ানো, প্রাইভেসি, কনফ্লিক্ট অফ ইন্টারেস্ট) এবং সংশ্লিষ্ট প্রাতিষ্ঠানিক নীতির সাথে সিদ্ধান্তটি সংগতিপূর্ণ কিনা (L20-L21)।
৪ · প্রোপোরশনালিটি মূল্যায়ন
সমস্যাটি যতটা গুরুতর, হস্তক্ষেপের মাত্রা কি তার সাথে সংগতিপূর্ণ — নাকি সমস্যার আকারের তুলনায় অতিরিক্ত অনুপ্রবেশমূলক (L22-এর সমানুপাতিকতা ধারণার সম্প্রসারণ)?

৩ · একটি সত্যিকারের ধাপে-ধাপে প্রয়োগ

নিচের কোডে চারটি ধাপকে চারটি পৃথক ফাংশন হিসেবে লেখা হয়েছে, এবং একটি সিন্থেটিক দৃশ্যে ("একটি কোম্পানি কর্মীদের ইমেইল ও কীবোর্ড অ্যাক্টিভিটি পুরোপুরি মনিটর করার ফিচার চালু করতে চায়, উদ্দেশ্য প্রোডাক্টিভিটি বৃদ্ধি ও ডেটা-লিক শনাক্তকরণ") প্রয়োগ করা হয়েছে। লক্ষ্য করুন কীভাবে ধাপ ২-এ উপযোগবাদী স্কোর ইতিবাচক হলেও, ডিওন্টোলজিকাল লঙ্ঘন ও সবচেয়ে খারাপ-অবস্থানে থাকা পক্ষের (কর্মীদের) নেতিবাচক ফলাফল স্পষ্ট দ্বন্দ্ব তৈরি করে — L09-এর "ফ্রেমওয়ার্কগুলো একমত নাও হতে পারে" শিক্ষার একটি বাস্তব দৃষ্টান্ত।

Python
# একটি সিন্থেটিক, ইলাস্ট্রেটিভ দৃশ্য -- বাস্তব কোনো কোম্পানি নয়
# M1, M2 ও M5-এর প্যাটার্ন একত্র করে একটি চার-ধাপের এথিক্যাল রিভিউ

def identify_stakeholders(scenario):
    print("ধাপ ১ -- স্টেকহোল্ডার শনাক্তকরণ:")
    for s in scenario["stakeholders"]:
        print(f"  - {s['name']}: {s['impact']}")
    return scenario["stakeholders"]

def apply_frameworks(scenario):
    util_score = scenario["utilitarian_net_benefit"]
    violations = scenario["deontological_rule_violations"]
    worst_case = min(s["utility"] for s in scenario["stakeholder_utilities"])
    print("ধাপ ২ -- একাধিক এথিক্যাল ফ্রেমওয়ার্ক প্রয়োগ:")
    print(f"  - উপযোগবাদী নিট সুফল (ইলাস্ট্রেটিভ ইউনিট): {util_score:+.1f}")
    print(f"  - ডিওন্টোলজিকাল নিয়ম লঙ্ঘন: {violations if violations else 'কোনোটি পাওয়া যায়নি'}")
    print(f"  - Maximin (সবচেয়ে খারাপ-অবস্থানে থাকা পক্ষের ফলাফল): {worst_case:+.1f}")
    return util_score, violations, worst_case

def check_professional_codes(scenario):
    print("ধাপ ৩ -- প্রফেশনাল কোড যাচাই:")
    flagged = []
    for theme, satisfied in scenario["code_theme_check"].items():
        status = "ঠিক আছে" if satisfied else "লঙ্ঘিত হতে পারে"
        print(f"  - {theme}: {status}")
        if not satisfied:
            flagged.append(theme)
    return flagged

def assess_proportionality(scenario):
    severity = scenario["problem_severity"]
    intrusiveness = scenario["intervention_intrusiveness"]
    ratio = intrusiveness / severity
    print("ধাপ ৪ -- প্রোপোরশনালিটি মূল্যায়ন:")
    print(f"  - সমস্যার তীব্রতা: {severity}/১০, হস্তক্ষেপের অনুপ্রবেশমূলকতা: {intrusiveness}/১০")
    print(f"  - অনুপাত (intrusiveness / severity): {ratio:.2f}  (১.০-এর অনেক বেশি মানে সম্ভাব্য অতিরিক্ত হস্তক্ষেপ)")
    return ratio

def ethical_decision_review(scenario):
    identify_stakeholders(scenario)
    print()
    util_score, violations, worst_case = apply_frameworks(scenario)
    print()
    flagged_codes = check_professional_codes(scenario)
    print()
    ratio = assess_proportionality(scenario)

    print("\nধাপ ৫ -- সারসংক্ষেপ ও সুপারিশ:")
    needs_review = bool(violations) or bool(flagged_codes) or ratio > 1.2
    if needs_review:
        print("  => আরও পর্যালোচনা প্রয়োজন -- বর্তমান ডিজাইনে পরিবর্তন ছাড়া এগোনো উচিত নয়")
    else:
        print("  => বর্তমান শর্তে এগিয়ে যাওয়া যুক্তিসঙ্গত, তবে ডকুমেন্টেশন ও পর্যায়ক্রমিক রিভিউ চালিয়ে যান")
    return needs_review

scenario = {
    "stakeholders": [
        {"name": "কর্মীরা",          "impact": "প্রাইভেসি হ্রাস, নজরদারিজনিত মানসিক চাপ বাড়ার ঝুঁকি"},
        {"name": "ম্যানেজমেন্ট",      "impact": "প্রোডাক্টিভিটি ডেটা ও সম্ভাব্য ডেটা-লিক শনাক্তকরণ সুবিধা"},
        {"name": "কোম্পানির ক্লায়েন্ট", "impact": "পরোক্ষভাবে ডেটা সুরক্ষা কিছুটা উন্নত হতে পারে"},
    ],
    "utilitarian_net_benefit": 3.5,  # ইলাস্ট্রেটিভ ইউনিট -- সামগ্রিকভাবে সামান্য ইতিবাচক
    "deontological_rule_violations": [
        "কর্মীদের স্পষ্ট সম্মতি ছাড়া ব্যক্তিগত ইমেইল বিষয়বস্তু স্ক্যান করা -- 'সম্মতি ছাড়া নজরদারি নয়' নিয়ম লঙ্ঘন"
    ],
    "stakeholder_utilities": [
        {"name": "কর্মীরা", "utility": -4},
        {"name": "ম্যানেজমেন্ট", "utility": 6},
        {"name": "ক্লায়েন্ট", "utility": 2},
    ],
    "code_theme_check": {
        "প্রাইভেসির প্রতি শ্রদ্ধা": False,
        "সততা/স্বচ্ছতা": True,
        "ক্ষতি এড়ানো": True,
    },
    "problem_severity": 4,          # ডেটা-লিক একটি বাস্তব কিন্তু এখানে মাঝারি মাত্রার উদ্বেগ
    "intervention_intrusiveness": 8, # সম্পূর্ণ কীস্ট্রোক/ইমেইল মনিটরিং অত্যন্ত অনুপ্রবেশমূলক
}

ethical_decision_review(scenario)

    
লক্ষ্য করুন ধাপ ২-এ ফলাফলের দ্বন্দ্ব — উপযোগবাদী নিট সুফল ইতিবাচক (+৩.৫), কিন্তু একটি ডিওন্টোলজিকাল নিয়ম লঙ্ঘিত হচ্ছে এবং maximin বিশ্লেষণ দেখায় সবচেয়ে খারাপ-অবস্থানে থাকা পক্ষ (কর্মীরা) প্রকৃতপক্ষে ক্ষতিগ্রস্ত হচ্ছে (−৪)। ধাপ ৪-এ অনুপাত 8 / 4 = 2.0, যা ১.২-এর সীমা ছাড়িয়ে যায় — তাই চূড়ান্ত ফাংশন সঠিকভাবে "আরও পর্যালোচনা প্রয়োজন" সুপারিশ করে, যদিও একটি ফ্রেমওয়ার্ক (উপযোগবাদ) একা দেখলে সিদ্ধান্তটি ন্যায্য মনে হতে পারতো।
মূল কথা · Key takeaway

একটি চেকলিস্ট কোনো ফ্রেমওয়ার্ককে "সঠিক" ঘোষণা করে না — এর আসল মূল্য হলো, যখন ফ্রেমওয়ার্কগুলো ভিন্নমত পোষণ করে (যেমন ওপরের উদাহরণে উপযোগবাদ বনাম ডিওন্টোলজি ও maximin), তখন সেই দ্বন্দ্বটি স্পষ্টভাবে দৃশ্যমান করে তোলে, যাতে সেটি চাপা না পড়ে যায়। M2-M5-এর প্রতিটি মডিউল একটি ভিন্ন প্রশ্ন জিজ্ঞাসা করতে শেখায়; এই ফ্রেমওয়ার্ক সেই প্রশ্নগুলো ক্রমানুসারে জিজ্ঞাসা করার একটি অভ্যাস তৈরি করে।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ উপরের দৃশ্যে কেন উপযোগবাদী স্কোর ইতিবাচক হওয়া সত্ত্বেও চূড়ান্ত সুপারিশ "আরও পর্যালোচনা প্রয়োজন" হলো?

কারণ চেকলিস্টটি একক ফ্রেমওয়ার্কের ওপর নির্ভর করে না — একটি ডিওন্টোলজিকাল নিয়ম লঙ্ঘন এবং একটি অসামঞ্জস্যপূর্ণ প্রোপোরশনালিটি অনুপাত (২.০) উভয়ই আলাদাভাবে ফ্ল্যাগ তৈরি করে, এবং needs_review এই যেকোনো একটি ফ্ল্যাগ সত্য হলেই True হয়ে যায়। এটি ইচ্ছাকৃত — উদ্দেশ্য হলো একটি ইতিবাচক উপযোগবাদী সংখ্যা যেন অন্য গুরুতর সমস্যাগুলোকে ঢেকে না দিতে পারে।

প্র ০২ চেকলিস্টে "প্রোপোরশনালিটি" ধাপটি সবার শেষে কেন রাখা হয়েছে, স্টেকহোল্ডার শনাক্তকরণের আগে নয়?

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

প্র ০৩ এই ধরনের একটি চেকলিস্ট ব্যবহার করার পরেও কোন কোন সীমাবদ্ধতা থেকে যায়?

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

অনুশীলন

  1. চিন্তা করুন: আপনার পরিচিত কোনো প্রকল্পের কথা ভাবুন এবং এই চার-ধাপের চেকলিস্ট সংক্ষেপে প্রয়োগ করার চেষ্টা করুন (মনে মনে বা কাগজে) — কোন ধাপে আপনি সবচেয়ে বেশি অনিশ্চয়তা অনুভব করলেন, এবং কেন?

    অনেকে সাধারণত ধাপ ১ (স্টেকহোল্ডার শনাক্তকরণ) সবচেয়ে সহজ মনে করেন কিন্তু পরোক্ষভাবে প্রভাবিত তৃতীয় পক্ষ (যেমন এই লেসনের উদাহরণে "কর্মীদের পরিবার" বা বৃহত্তর কর্মক্ষেত্র সংস্কৃতি) বাদ দিয়ে ফেলেন — আর ধাপ ২ (একাধিক ফ্রেমওয়ার্ক) প্রায়ই সবচেয়ে বেশি অনিশ্চয়তা তৈরি করে, কারণ ফ্রেমওয়ার্ক ইনপুটে সংখ্যা বসানো (কতটা "খারাপ" একটি নিয়ম লঙ্ঘন) নিজেই একটি কঠিন বিচারমূলক কাজ।

  2. পরীক্ষা করুন: উপরের কোড সেলে intervention_intrusiveness-কে ৮ থেকে ৩ করে (অর্থাৎ শুধু ব্যাপক ফাইল-শেয়ারিং প্যাটার্নের ওপর নজরদারি, ব্যক্তিগত ইমেইল বিষয়বস্তু নয়) Run চেপে দেখুন সুপারিশ বদলায় কিনা।

    নতুন অনুপাত হবে 3 / 4 = 0.75, যা ১.২-এর সীমার নিচে — কিন্তু চূড়ান্ত সুপারিশ তবুও "আরও পর্যালোচনা প্রয়োজন"-ই থাকবে, কারণ needs_review এখনো ডিওন্টোলজিকাল লঙ্ঘন ও প্রাইভেসি কোড-ফ্ল্যাগের ওপর নির্ভরশীল, যেগুলো এই পরিবর্তনে বদলায়নি। এটি স্পষ্ট করে দেখায় — শুধু একটি ধাপ (প্রোপোরশনালিটি) ঠিক করলেই অন্য ধাপের গুরুতর সমস্যা (সম্মতি ছাড়া নজরদারি) স্বয়ংক্রিয়ভাবে সমাধান হয়ে যায় না।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

আগের পাঠ
হুইসেলব্লোয়িং — কখন ও কীভাবে