পাঠ ৩৮ · ৫৭-এর মধ্যে · মডিউল ৯
Home / AI Courses / AI Ethics / EU AI Act

EU AI Act — রিস্ক-বেসড রেগুলেশন

The EU AI Act: Risk-Based Regulation
৯ মিনিট পড়া মধ্যম · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

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

  • EU AI Act কী এবং কেন "রিস্ক-বেসড" কাঠামো বেছে নেওয়া হয়েছে
  • চারটি রিস্ক টায়ার এবং প্রতিটির বাস্তব উদাহরণ
  • কীভাবে একটি নিয়ম-ভিত্তিক সিস্টেম একটি AI সিস্টেমের বর্ণনা থেকে তার রিস্ক টায়ার নির্ধারণ করতে পারে
  • একটি সত্যিকারের, চলমান রিস্ক-টায়ার ক্লাসিফায়ার — একাধিক উদাহরণ সিস্টেমে প্রয়োগ করে যাচাই করা

১ · কেন রিস্ক-বেসড রেগুলেশন

EU AI ActEU AI Actইউরোপীয় ইউনিয়নের AI-নির্দিষ্ট রেগুলেশন, ২০২৪ সালে গৃহীত — AI সিস্টেমকে চারটি রিস্ক টায়ারে ভাগ করে ভিন্ন মাত্রার বাধ্যবাধকতা আরোপ করে। সব AI সিস্টেম সমান ঝুঁকিপূর্ণ নয় — একটি স্প্যাম ফিল্টার আর একটি ল-এনফোর্সমেন্ট রিস্ক-অ্যাসেসমেন্ট টুল একই নিয়মে বাঁধা হলে হয় স্প্যাম ফিল্টারকে অপ্রয়োজনীয়ভাবে ভারী কমপ্লায়েন্স বোঝা বহন করতে হবে, নয়তো ল-এনফোর্সমেন্ট টুল যথেষ্ট কঠোর তদারকি ছাড়াই চলবে। এই সমস্যা সমাধানে EU AI Act (২০২৪ সালে গৃহীত) একটি রিস্ক-বেসড কাঠামো বেছে নিয়েছে — AI সিস্টেমকে চারটি টায়ারে ভাগ করে, প্রতিটির জন্য ভিন্ন মাত্রার বাধ্যবাধকতা।

Unacceptable Risk নিষিদ্ধ High Risk কঠোর বাধ্যবাধকতা Limited Risk স্বচ্ছতার বাধ্যবাধকতা Minimal Risk মূলত অনিয়ন্ত্রিত
টায়ার যত উপরে, বাধ্যবাধকতা তত কঠোর — কিন্তু বাস্তবে সিস্টেমের সংখ্যা যত নিচে, তত বেশি: বেশিরভাগ AI সিস্টেম minimal বা limited risk-এ পড়ে, খুব অল্প সংখ্যক unacceptable risk-এ।

২ · চারটি টায়ার — সংজ্ঞা ও উদাহরণ

Unacceptable Risk — নিষিদ্ধ
একেবারে নিষিদ্ধ। উদাহরণ: নির্দিষ্ট সোশ্যাল-স্কোরিং সিস্টেম (নাগরিকদের সাধারণ আচরণ স্কোর করে সেবা প্রদান/অস্বীকার), এবং সচেতনতার বাইরে গিয়ে মানুষকে প্রভাবিত করার মতো ম্যানিপুলেটিভ কৌশল ব্যবহারকারী সিস্টেম।
High Risk — কঠোর বাধ্যবাধকতা
নিষিদ্ধ নয়, কিন্তু কঠোর প্রয়োজনীয়তা মানতে হয় (ডকুমেন্টেশন, মানব-তদারকি, রিস্ক-ম্যানেজমেন্ট)। উদাহরণ: হায়ারিং, ক্রেডিট স্কোরিং, ল-এনফোর্সমেন্ট AI।
Limited Risk — স্বচ্ছতার বাধ্যবাধকতা
ব্যবহারকারীকে জানাতে হবে তারা AI-এর সাথে ইন্টারঅ্যাক্ট করছে। উদাহরণ: চ্যাটবট — এটিকে অবশ্যই নিজেকে AI হিসেবে প্রকাশ করতে হবে।
Minimal Risk — মূলত অনিয়ন্ত্রিত
বেশিরভাগ AI অ্যাপ্লিকেশন এই বিভাগে পড়ে — বিশেষ AI Act-নির্দিষ্ট বাধ্যবাধকতা নেই। উদাহরণ: স্প্যাম ফিল্টার, ইনভেন্টরি ফোরকাস্টিং।
GDPR (L37) ডেটা প্রসেসিংকে নিয়ন্ত্রণ করে, ব্যবহৃত AI সিস্টেমের ধরন নির্বিশেষে। EU AI Act এর চেয়ে ভিন্ন কোণ থেকে আসে — এটি নিজেই AI সিস্টেমটিকে নিয়ন্ত্রণ করে, তার ঝুঁকির স্তর অনুযায়ী। বাস্তবে দুটো একসাথে প্রযোজ্য হতে পারে — একটি হাই-রিস্ক হায়ারিং AI GDPR-এর ডেটা-প্রোটেকশন বাধ্যবাধকতা এবং AI Act-এর হাই-রিস্ক বাধ্যবাধকতা দুটোই মানতে বাধ্য।

৩ · একটি নিয়ম-ভিত্তিক রিস্ক-টায়ার ক্লাসিফায়ার

নিচের কোড সেলে একটি ফাংশন লেখা হয়েছে যা একটি AI সিস্টেমের বর্ণিত বৈশিষ্ট্য (ডিকশনারি হিসেবে) থেকে তার রিস্ক টায়ার নির্ধারণ করে — সম্পূর্ণ নিয়ম-ভিত্তিক যুক্তি দিয়ে, কোনো উদাহরণের উত্তর আলাদাভাবে হার্ডকোড না করে। যুক্তির ক্রম গুরুত্বপূর্ণ: প্রথমে unacceptable-এর শর্ত পরীক্ষা করা হয় (সবচেয়ে গুরুতর), তারপর high, তারপর limited, আর কোনোটিতেই না পড়লে minimal।

Python
HIGH_RISK_DOMAINS = {"hiring", "credit_scoring", "law_enforcement"}

def classify_risk_tier(system):
    # ধাপ ১: unacceptable -- সোশ্যাল-স্কোরিং বা সচেতনতার বাইরে গিয়ে প্রভাবিত করার কৌশল
    if system["social_scoring"] or system["manipulative_technique"]:
        return "unacceptable"
    # ধাপ ২: high risk -- নির্দিষ্ট উচ্চ-ঝুঁকিপূর্ণ ডোমেইনে ব্যবহৃত হলে
    if system["domain"] in HIGH_RISK_DOMAINS:
        return "high"
    # ধাপ ৩: limited risk -- সরাসরি মানুষের সাথে কথোপকথনে জড়িত (তাই disclosure প্রয়োজন)
    if system["direct_human_interaction"]:
        return "limited"
    # ধাপ ৪: বাকি সবকিছু minimal risk
    return "minimal"

example_systems = [
    {
        "name": "নাগরিক আচরণ-স্কোরিং সিস্টেম",
        "domain": "public_services",
        "social_scoring": True,
        "manipulative_technique": False,
        "direct_human_interaction": False,
    },
    {
        "name": "রিজিউমি স্ক্রিনিং ও র‍্যাংকিং AI",
        "domain": "hiring",
        "social_scoring": False,
        "manipulative_technique": False,
        "direct_human_interaction": False,
    },
    {
        "name": "লোন-অনুমোদন ক্রেডিট স্কোরিং AI",
        "domain": "credit_scoring",
        "social_scoring": False,
        "manipulative_technique": False,
        "direct_human_interaction": False,
    },
    {
        "name": "প্রেডিক্টিভ পুলিশিং রিস্ক-অ্যাসেসমেন্ট AI",
        "domain": "law_enforcement",
        "social_scoring": False,
        "manipulative_technique": False,
        "direct_human_interaction": False,
    },
    {
        "name": "কাস্টমার সার্ভিস চ্যাটবট",
        "domain": "customer_service",
        "social_scoring": False,
        "manipulative_technique": False,
        "direct_human_interaction": True,
    },
    {
        "name": "সাবলিমিনাল অডিও বিজ্ঞাপন AI",
        "domain": "advertising",
        "social_scoring": False,
        "manipulative_technique": True,
        "direct_human_interaction": False,
    },
    {
        "name": "ইমেইল স্প্যাম ফিল্টার",
        "domain": "email_filtering",
        "social_scoring": False,
        "manipulative_technique": False,
        "direct_human_interaction": False,
    },
    {
        "name": "ওয়্যারহাউজ ইনভেন্টরি ডিমান্ড ফোরকাস্টিং AI",
        "domain": "inventory_forecasting",
        "social_scoring": False,
        "manipulative_technique": False,
        "direct_human_interaction": False,
    },
]

tier_counts = {"unacceptable": 0, "high": 0, "limited": 0, "minimal": 0}

print(f"{'সিস্টেম':45s} -> টায়ার")
print("-" * 65)
for system in example_systems:
    tier = classify_risk_tier(system)
    tier_counts[tier] += 1
    print(f"{system['name']:45s} -> {tier}")

print("\nমোট বিতরণ:")
for tier, count in tier_counts.items():
    print(f"  {tier}: {count}টি সিস্টেম")

    


    

      লক্ষ্য করুন — classify_risk_tier() ফাংশনটি প্রতিটি সিস্টেমের জন্য আলাদাভাবে লেখা হয়নি; একই চারটি
      নিয়ম প্রতিটি উদাহরণে প্রয়োগ হয়েছে এবং ফলাফল সত্যিই গণনা করে বের হয়েছে। যাচাই করে দেখুন: নাগরিক
      আচরণ-স্কোরিং সিস্টেম social_scoring=True থাকায় unacceptable-এ পড়ে (ধাপ ১-এই থেমে যায়, ডোমেইন
      যাই হোক না কেন); সাবলিমিনাল বিজ্ঞাপন AI manipulative_technique=True থাকায় একইভাবে unacceptable;
      হায়ারিং/ক্রেডিট/ল-এনফোর্সমেন্ট AI তিনটিই HIGH_RISK_DOMAINS-এ পড়ায় high; চ্যাটবট শুধু
      direct_human_interaction=True থাকায় limited; আর বাকি দুটো (স্প্যাম ফিল্টার, ইনভেন্টরি ফোরকাস্টিং)
      কোনো শর্তেই না পড়ায় স্বাভাবিকভাবে minimal-এ পড়ে যায়।
    


    

      মূল কথা · Key takeaway
      

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

    


  


  

    
    
  


  

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

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


    

      
        প্র ০১
        উপরের ক্লাসিফায়ারে classify_risk_tier() ফাংশনটি প্রথমে unacceptable-এর শর্ত পরীক্ষা
        করে, তারপর high, তারপর limited। এই ক্রমটি কেন গুরুত্বপূর্ণ — যদি একটি সিস্টেম একই সাথে
        social_scoring=True এবং domain="hiring" হতো, তাহলে কী হতো?
      
      

        

          ফাংশনটি প্রথম if শর্তেই return করে থেমে যায়, তাই এমন একটি সিস্টেম unacceptable
          হিসেবেই শ্রেণিবদ্ধ হবে, high নয় — কারণ unacceptable সবচেয়ে গুরুতর বিভাগ এবং তার শর্ত প্রথমে পরীক্ষা করা
          হয়। এটি দেখায় কেন নিয়মের ক্রম (priority order) একটি রুল-বেসড ক্লাসিফায়ার ডিজাইন করার সময় স্পষ্টভাবে
          চিন্তা করে ঠিক করতে হয় — একাধিক শর্ত একসাথে সত্য হলে সবচেয়ে গুরুতর বিভাগ জিততে হবে।
        

      

    


    

      
        প্র ০২
        ক্লাসিফায়ারে HIGH_RISK_DOMAINS-এ শুধু তিনটি ডোমেইন আছে (hiring, credit_scoring,
        law_enforcement)। বাস্তব-জগতের একটি রিস্ক-বেসড রেগুলেশনে এই তালিকা কেন এত ছোট হওয়া বাস্তবসম্মত নয় বলে
        আপনার মনে হয়?
      
      

        

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

      

    


    

      
        প্র ০৩
        একটি সংস্থা তাদের সিস্টেমকে ইচ্ছাকৃতভাবে "কাস্টমার সার্ভিস চ্যাটবট" হিসেবে বর্ণনা করছে (যা limited
        risk), যদিও বাস্তবে এটি ক্রেডিট-যোগ্যতা সংক্রান্ত সিদ্ধান্তও নিচ্ছে। এই পরিস্থিতিতে কী সমস্যা দেখা দিতে
        পারে?
      
      

        

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

      

    

  


  

    
 অনুশীলন

    
    
      
  1. 
        চিন্তা করুন: যদি example_systems-এ একটি নতুন সিস্টেম যোগ করা হয়:
        {"name": "AI ভিডিও ইন্টারভিউ বিশ্লেষক", "domain": "hiring", "social_scoring": False,
        "manipulative_technique": False, "direct_human_interaction": True} — এটি কোন টায়ারে পড়বে বলে
        আপনার ধারণা?
        
    
          
          
    
            
    
              এটি high risk-এ পড়বে। যদিও direct_human_interaction=True (যা normally limited risk
              নির্দেশ করে), ফাংশনটি ধাপ ২-তেই (domain in HIGH_RISK_DOMAINS) থেমে যায়, কারণ
              domain="hiring" — এবং high-risk শর্ত limited-risk শর্তের আগে পরীক্ষা করা হয়, তাই
              ফাংশন সেখানেই return "high" করে থেমে যাবে, ধাপ ৩ পর্যন্ত পৌঁছাবেই না।
            
    
          
    
        
    
      
    2. 
      
  2. 
        পরীক্ষা করুন: উপরের কোড সেলের example_systems তালিকায় এই নতুন সিস্টেমটি
        যোগ করে Run চেপে আপনার অনুমান যাচাই করুন, এবং লক্ষ্য করুন "মোট বিতরণ"-এর সংখ্যাগুলো কীভাবে বদলায়।
        
    
          
          
    
            
    
              রান করলে দেখা যাবে নতুন সিস্টেমটি সত্যিই "high" হিসেবে প্রিন্ট হয়েছে, এবং "মোট বিতরণ"-এ
              high-এর কাউন্ট ৩ থেকে ৪-এ বেড়েছে — পুরো তালিকাটি আবার লুপে চলে গণনা হয়েছে, কোনো
              সংখ্যা ম্যানুয়ালি আপডেট করতে হয়নি।
            
    
          
    
        
    
      
    3. 
    

  


  

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

    
  







  
  
     এই পাঠে ভুল পেয়েছেন? জানান
  





  
    
 আগের পাঠ

    
GDPR ও AI-তে ডেটা প্রোটেকশন