রিভিউ, অডিট ও বাস্তব গভর্ন্যান্স: পরিবর্তনের অনুমোদন, ঝুঁকি গ্রহণ ও কর্মীদের উদ্বেগ

আগের পাতায় ঠিক হয়েছে কে একটা AI সিস্টেমের মালিক, কে তা অনুমোদন করেন, আর ভেন্ডরকে কীভাবে যাচাই করা হয়। এই পাতায় আছে কাগজপত্র তৈরির পরের কাজ: সেগুলো সত্যি কি না কে যাচাই করেন, পরিবর্তনে কে অনুমোদন দেন, বাকি থেকে যাওয়া ঝুঁকি কে মেনে নেন, নিয়মগুলো নিজে কখন রিভিউ হয়, আর কোনো কর্মী কীভাবে বলতে পারেন "এখানে কিছু একটা ঠিক নেই"। উল্টো বিপদের কথাও আছে: গভর্ন্যান্স এত ভারী হয়ে যাওয়া যে কেউ তা ব্যবহার করে না।

আপনার দরকার Python 3.12 এবং শুধু তার স্ট্যান্ডার্ড লাইব্রেরি। একটা ছোট স্ক্রিপ্ট গভর্ন্যান্স রেজিস্টার বানিয়ে ফাঁকগুলো চিহ্নিত করবে। ব্লকগুলো ক্রমে একটা সেশনে লিখুন; প্রতিটা ব্লকের নিচের লেখাটা তার আসল আউটপুট।

সততার নিয়ম। প্রতিষ্ঠান, তার কর্মী, টুল এবং প্রতিটা তারিখ ও সংখ্যা কাল্পনিক। রেজিস্টার স্ক্রিপ্ট যা নেই তা "নেই" বলে জানায়, ফাঁক কখনও অনুমানে ভরে না। এখানে কিছুই আইনি পরামর্শ নয়, আর দেখানো প্রতিটা নিয়ম (রিভিউয়ের ব্যবধান, স্তর, সময়সীমা) উদাহরণের জন্য বেছে নেওয়া।

যা শিখবেন

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

যে প্রতিষ্ঠানের গভর্ন্যান্স আমরা বানাব

কাল্পনিক পরিস্থিতি:

Organisation: Baobab Learning Hub (invented), 40 staff, online tutoring for secondary students
              in Accra and Nairobi. No compliance department.
AI in use:    EssayFeedback  drafts comments on student essays; a tutor reviews them
              Scheduler      suggests tutor timetables
              ParentBot      answers questions from parents on the website
              Translator     drafts translations of course material
              Marking pilot  scores short answers (one team is trying it; nobody has approved it)
People:       Director; Head of Learning (Chidi); Operations lead (Nadia); Content lead (Hana);
              Assessment lead (Luis); safeguarding lead (Ines, part time); IT contractor (Tariq)
Question:     with so few people, how do we make sure the AI tools are reviewed, changes are
              approved, leftover risks have a named owner and nothing is forgotten?

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

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

রিভিউ ও অডিট: যাচাইকারীকে কে যাচাই করে

অভ্যন্তরীণ অডিট ও রিভিউয়ের দায়িত্ব ঠিক করুন। তিনটা কাজ প্রায়ই গুলিয়ে যায়। নিজের যাচাই (self-check) হলো মালিক নিজের কাজ নিশ্চিত করা। রিভিউ করেন এমন একজন, যিনি সিস্টেমটা বানাননি বা চালাননি; তিনি লঞ্চ বা পরিবর্তনের আগে প্রমাণ পড়েন। অডিট পিছনে তাকায়, সাধারণত একটা নমুনা ধরে, দেখতে যে প্রক্রিয়া মানা হয়েছে কি না আর রেকর্ড সত্য কি না। NIST AI RMF 1.0 (জানুয়ারি ২০২৩, স্বেচ্ছামূলক)-এ Govern নামে একটা ফাংশন আছে; আমাদের ভাষায় সেটা নীতি ও জবাবদিহি (accountability) নিয়ে, আর এই পাতা সেখানেই পড়ে।

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

পরিবর্তনে অনুমোদন

পরিবর্তনে অনুমোদনের শর্ত ঠিক করুন। একটা অ্যাসেসমেন্ট সিস্টেমকে বর্ণনা করে সেই দিনের অবস্থায়, যেদিন তা অনুমোদিত হয়েছিল। একটা পরিবর্তন সেই বর্ণনাকে মিথ্যা করে দিতে পারে। আগে থেকে ঠিক করুন কোন পরিবর্তনে কার অনুমোদন লাগবে, যাতে ব্যস্ত সপ্তাহে কাউকে তর্ক করতে না হয়।

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

ঝুঁকি মেনে নেওয়ার রেকর্ড

ঝুঁকি মেনে নেওয়া ও অনুমোদনকারীর নাম লিখুন। নিয়ন্ত্রণের পরও কিছু ঝুঁকি থেকে যায়। কাউকে লিখিতভাবে বলতে হবে, "আমরা আপাতত এটা মেনে নিলাম।" রেকর্ড না থাকলে বাকি ঝুঁকি মেনে নেওয়া হয় না; স্রেফ ভুলে যাওয়া হয়।

টেমপ্লেট:

Risk accepted:   R4 - parent chat text kept for 90 days (vendor default)
Residual level:  likelihood 2, severity 4 (our scale); reversibility: irreversible
Why accepted:    the alternative is no ParentBot; parents get answers 3 days sooner (Toy data)
Alternatives:    ask the vendor for 30-day retention (asked 2026-09-01, no answer yet)
Conditions:      no health or payment details accepted in chat; review if the vendor answers
Accepted by:     Director (the role with authority for this tier), 2026-10-01
Informed:        Head of Learning, safeguarding lead
Expires:         2027-04-01; after this date the acceptance lapses and the risk is reviewed again
Not accepted by: the parents; they only see the privacy notice, so the notice must be accurate

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

রিভিউয়ের ট্রিগার

নিয়মিত পলিসি-রিভিউয়ের ট্রিগার ঠিক করুন। দুটো জিনিস রিভিউ হয়: প্রতিটা সিস্টেম, আর পলিসি নিজে। ক্যালেন্ডার ও ঘটনা, দুটোই ব্যবহার করুন।

একটা সহজ AI গভর্ন্যান্স রেজিস্টার

একটা সহজ AI গভর্ন্যান্স রেজিস্টার বানান। রেজিস্টার একটা তালিকা, প্রতি সিস্টেমে একটা রেকর্ড। নিচের স্ক্রিপ্ট এই পাতার জন্য বেছে নেওয়া নিয়মে যাচাই করে: মালিক ও স্তরের নাম থাকতে হবে, পরবর্তী রিভিউয়ের তারিখ থাকতে হবে এবং তা পার হয়ে যাওয়া চলবে না, অনুমোদনে কে ও কবে লেখা থাকতে হবে, আর মেনে নেওয়া ঝুঁকিতে অনুমোদনকারী ও এমন মেয়াদ থাকতে হবে যা শেষ হয়নি। এটা প্রতিটা সিস্টেমের বৈশিষ্ট্যও বিশেষজ্ঞ রিভিউয়ের একটা টেবিলের সঙ্গে মেলায় (পরের অংশে ব্যাখ্যা আছে)। "আজকের" জায়গায় একটা স্থির তারিখ বসানো, তাই প্রতিবার একই উত্তর আসে।

টয় ডেটা: বাওবাবের পাঁচটা কাল্পনিক সিস্টেম। খালি মানগুলো ইচ্ছাকৃত।

from datetime import date

AS_OF = date(2026, 10, 12)   # a fixed "today"
REGISTER = [  # Toy data: invented records. "" or a missing key means "not recorded".
    dict(system="EssayFeedback", owner="Chidi (Head of Learning)", tier="high",
         traits=["personal_data", "children"], last_review="2026-03-02", next_review="2026-09-02",
         approval=dict(by="Director", date="2026-03-01"), specialist_done=["privacy"], accepted=[]),
    dict(system="Scheduler", owner="Nadia (Operations)", tier="low", traits=[],
         last_review="2026-08-20", next_review="2027-02-20",
         approval=dict(by="Nadia (Operations)", date="2026-08-20"), specialist_done=[], accepted=[]),
    dict(system="ParentBot", owner="", tier="medium", traits=["personal_data", "untrusted_input"],
         last_review="2026-06-15", next_review="2026-12-15", approval=None, specialist_done=[],
         accepted=[dict(risk="R4 chat text kept 90 days", approver="Director", expires="2027-04-01")]),
    dict(system="Translator", owner="Hana (Content)", tier="medium", traits=["public_text"],
         last_review="2026-01-10", next_review="2026-07-10",
         approval=dict(by="Hana (Content)", date="2026-01-10"), specialist_done=[],
         accepted=[dict(risk="R2 odd phrasing", approver="Hana (Content)", expires="2026-09-30")]),
    dict(system="Marking pilot", owner="Luis (Assessment)", tier="", traits=None,
         last_review="", next_review="", approval=None, specialist_done=[], accepted=[]),
]

SPECIALIST = {  # a rule we chose: trait -> specialist who must have looked at the system
    "personal_data": "privacy", "children": "safeguarding", "public_text": "language/communications",
    "untrusted_input": "security", "legal_effect": "legal", "health_or_safety": "domain safety",
}

def when(text):
    try:
        return date.fromisoformat(text)
    except (TypeError, ValueError):
        return None

def flags(rec):
    out = []
    for field in ("owner", "tier"):
        if not rec.get(field):
            out.append(f"MISSING {field}")
    ap = rec.get("approval")
    if not ap or not ap.get("by") or not when(ap.get("date")):
        out.append("MISSING approval (who and when)")
    elif ap["by"] == rec.get("owner") and rec.get("tier") in ("medium", "high"):
        out.append("approver is the owner (chosen rule: not allowed above low tier)")
    due = when(rec.get("next_review"))
    if due is None:
        out.append("MISSING next_review date")
    elif due < AS_OF:
        out.append(f"OVERDUE review by {(AS_OF - due).days} days")
    for acc in rec.get("accepted", []):
        end = when(acc.get("expires"))
        if not acc.get("approver") or end is None:
            out.append(f"acceptance '{acc.get('risk')}' lacks approver or expiry")
        elif end < AS_OF:
            out.append(f"acceptance '{acc['risk']}' EXPIRED {end}")
    if rec.get("traits") is None:
        out.append("traits not recorded: cannot tell if a specialist review is needed")
    else:
        for need in sorted({SPECIALIST[t] for t in rec["traits"] if t in SPECIALIST}):
            if need not in rec.get("specialist_done", []):
                out.append(f"SPECIALIST review needed: {need} (none recorded)")
    return out

total = 0
for rec in REGISTER:
    found = flags(rec)
    total += len(found)
    print(f"{rec['system']}: {'ok' if not found else str(len(found)) + ' flag(s)'}")
    for line in found:
        print("   -", line)
print(f"\n{len(REGISTER)} systems, {total} flags, as of {AS_OF}")

EssayFeedback: 2 flag(s)
   - OVERDUE review by 40 days
   - SPECIALIST review needed: safeguarding (none recorded)
Scheduler: ok
ParentBot: 4 flag(s)
   - MISSING owner
   - MISSING approval (who and when)
   - SPECIALIST review needed: privacy (none recorded)
   - SPECIALIST review needed: security (none recorded)
Translator: 4 flag(s)
   - approver is the owner (chosen rule: not allowed above low tier)
   - OVERDUE review by 94 days
   - acceptance 'R2 odd phrasing' EXPIRED 2026-09-30
   - SPECIALIST review needed: language/communications (none recorded)
Marking pilot: 4 flag(s)
   - MISSING tier
   - MISSING approval (who and when)
   - MISSING next_review date
   - traits not recorded: cannot tell if a specialist review is needed

5 systems, 14 flags, as of 2026-10-12

এটাকে করণীয় তালিকা হিসেবে পড়ুন, রায় হিসেবে নয়। নম্বর-দেওয়ার পাইলট সবচেয়ে তীক্ষ্ণ উদাহরণ: তার স্তর, অনুমোদন, তারিখ ও বৈশিষ্ট্য কিছুই নেই, তাই স্ক্রিপ্ট বলতে পারে না তার কী দরকার। সে "নিচু ঝুঁকি" অনুমান করে না; কী নেই তা বলে, আর উত্তর দেন একজন মানুষ। Translator-এ আরও শান্ত কিছু সমস্যা আছে: অনেক দিন আগে পার হওয়া রিভিউ, মাঝারি স্তরের সিস্টেমে মালিকেরই অনুমোদন, আর সেই একই ব্যক্তির মেনে নেওয়া একটা ঝুঁকি, যার মেয়াদ এখন শেষ। Scheduler-এ কোনো ফ্ল্যাগ নেই, যার মানে শুধু এই নিয়মগুলো কিছু পায়নি; এটা কোনো সনদ নয়।

কখন বিশেষজ্ঞ রিভিউ লাগে

কখন বিশেষজ্ঞ রিভিউ লাগবে তা চিহ্নিত করুন। সাধারণ কর্মী সবকিছু বিচার করতে পারেন না। টেবিলটা SPECIALIST-এর পেছনের নিয়ম; আপনার প্রতিষ্ঠান অনুযায়ী বদলান এবং কেন বদলালেন লিখে রাখুন।

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

কর্মীদের উদ্বেগ জানানোর প্রক্রিয়া

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

1 Raise     any channel: own manager, a named person outside the line, or an anonymous form
2 Receive   acknowledge within 2 working days (our example); give a reference number
3 Triage    someone not involved decides severity; urgent harm goes straight to the incident process
4 Act       owner or reviewer investigates; a concern about a leader goes to a different person
5 Feedback  tell the reporter what was decided, as far as privacy allows
6 Record    outcome and lessons go in the register; a pattern of concerns triggers a policy review
Promise     no punishment for a concern raised in good faith, written down and signed by leadership

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

গভর্ন্যান্সকে ব্যবহারযোগ্য রাখা

গভর্ন্যান্স পলিসিকে অব্যবহারযোগ্য চেকলিস্ট হতে দেবেন না। যে পলিসি কেউ মানতে পারে না তা না থাকার চেয়েও খারাপ, কারণ তা মানুষকে বাক্স টিক দিতে শেখায়। নিচে একটা চেকলিস্ট, যা দেখতে পুঙ্খানুপুঙ্খ।

কাল্পনিক পরিস্থিতি: প্রতিটা টুলের জন্য একই ৪০ আইটেমের চেকলিস্ট।

 1 Ethics reviewed      11 Risks mitigated      21 Backups made         31 Access ensured
 2 Fairness ensured     12 Impact assessed      22 Training completed   32 Environment checked
 3 Bias eliminated      13 Data quality good    23 Incident plan exists 33 Copyright considered
 4 Transparency done    14 Model accurate       24 Complaints process   34 Misuse prevented
 5 Privacy respected    15 Model explainable    25 Documentation done   35 Harm avoided
 6 Security considered  16 Oversight in place   26 Version recorded     36 Values aligned
 7 Stakeholders asked   17 Accountability clear 27 Owner named          37 Culture supportive
 8 Legal reviewed       18 Vendor trustworthy   28 Review scheduled     38 Innovation backed
 9 Policy read by all   19 Contract checked     29 Board informed       39 Compliance confirmed
10 Risks identified     20 Logs kept            30 Users informed       40 Sign-off obtained

এর ত্রুটি: "Bias eliminated" বা "Harm avoided" কেউ সততার সঙ্গে টিক দিতে পারেন না; আইটেমগুলো একে অপরের সঙ্গে মিলে যায় (১, ৮ ও ৩৯); প্রমাণ, মালিক বা তারিখের জায়গা নেই; আর একই ৪০ আইটেম একটা সময়সূচির সহায়ক এবং শিশুদের কাজে নম্বর দেওয়া টুল, দুটোর ওপরই খাটে। প্রতিটা আইটেমে ১০ মিনিট লাগলে একটা টুলে ছয় ঘণ্টার বেশি লাগে (টয় ডেটা), তাই মানুষ তাড়াতাড়ি টিক দেয়। এবার একই উদ্দেশ্যের একটা আনুপাতিক সংস্করণ।

ALL TOOLS (5 questions, each answered with a name, a date or a link)
  1 Who owns it? (a name)                    2 What is it for, and what is out of scope?
  3 What data goes in? Any personal data?    4 Who reads the output before it matters? (a role)
  5 When is the next review? (a date)
MEDIUM TIER (adds 4)
  6 Which test did we run, with what result? (a link)    7 Which risk remains, and who accepted it?
  8 How does a user or staff member report a problem?    9 What would make us pause it?
HIGH TIER (adds 3)
 10 Which specialist reviewed it, and when?   11 Who can appeal or override, and how fast?
 12 Which group checks did we run, and what did they miss?

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

আনুপাতিক নিয়ন্ত্রণ ও উদ্ভাবন

আনুপাতিক নিয়ন্ত্রণের সঙ্গে উদ্ভাবনের ভারসাম্য রাখুন। এটা চিন্তাশীল মানুষদের মধ্যে সত্যিকারের মতভেদ, এমন ধাঁধা নয় যার একটা উত্তর আছে। টেবিলে কয়েক পক্ষের সবচেয়ে শক্তিশালী যুক্তি দেওয়া হলো।

এই পাতা এদের মধ্যে বেছে নেয় না। আপনার কাজ এমন সিদ্ধান্ত নেওয়া যা আপনি ব্যাখ্যা করতে পারেন: যে ক্ষতির ভয় পাচ্ছেন তার নাম বলুন, তা কতটা ফেরানো যায়, কতজনকে ছোঁয়, আর একটা নিয়ন্ত্রণ সময় ও দেরিতে কত খরচ করে। তারপর বলুন আপনি কী ছাড়ছেন। ফেরানো-যায় ও কম মানুষের ব্যবহারে হালকা নিয়ন্ত্রণ, আর ফেরানো-যায় না ও ব্যাপক ব্যবহারে ভারী নিয়ন্ত্রণ, দুটোই পক্ষে দাঁড়ানো যায়; আর যে দল কারণ লিখে রাখে তার পরে মত বদলানো সহজ হয়।

অনুশীলনী: একটা AI গভর্ন্যান্স ওয়ার্কফ্লো ডিজাইন

এটা নিচের কঠিন কাজ। বাওবাবের পরিস্থিতি নিয়ে এক পাতার একটা ওয়ার্কফ্লো ডিজাইন করুন, যাতে থাকবে: নতুন AI ব্যবহার কীভাবে রেজিস্টারে ঢোকে, তার স্তর কীভাবে ঠিক হয়, প্রতিটা স্তরে কে অনুমোদন করেন, পরিবর্তন ও ঝুঁকি মেনে নেওয়া কীভাবে সামলানো হয়, কর্মীরা কীভাবে উদ্বেগ জানান, আর প্রতিটা জিনিস কখন রিভিউ হয়। ৪০ জন কর্মীর উপযোগী ছোট রাখুন এবং প্রতিটা ধাপে একটা ভূমিকার নাম দিন। এই ওয়ার্কশিটটা ব্যবহার করুন।

ওয়ার্কশিট:

Step               Who does it   Evidence kept   Time limit   Triggers a review of
1 Intake           ?             register entry  ?            ?
2 Tier decision    ?             ?               ?            ?
3 Approval         ?             ?               ?            ?
4 Change           ?             ?               ?            ?
5 Risk acceptance  ?             ?               ?            ?
6 Concern          ?             ?               ?            ?
7 Review / audit   ?             ?               ?            ?

কাজের জায়গায় এটা কোথায় দেখা যায়

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

সাধারণ ভুল

1. নির্মাতা নিজের কাজ নিজে রিভিউ করেন। এতে কাজ দ্রুত মনে হয়, কিন্তু যে রিভিউয়ার নির্মাতার অনুমানই ভাগ করেন তিনি অন্ধ জায়গাগুলোও ভাগ করেন। অন্য দলের একজনকে নিন, আর কেউ না থাকলে আপসটা লিখে রাখুন।
2. একবার অনুমোদন দিয়ে আর না দেখা। নীরব মডেল আপডেটে অনুমোদনটা একটা ভিন্ন সিস্টেমের বর্ণনা হয়ে যায়। অনুমোদন একটা ভার্সনের সঙ্গে বাঁধুন, আর পরিবর্তনে নতুন অনুমোদন চান।
3. মেয়াদহীন ঝুঁকি মেনে নেওয়া। তা ডিফল্টে স্থায়ী হয়ে যায়। প্রতিটা মেনে নেওয়ায় একটা তারিখ ও একটা নামধারী ভূমিকা থাকুক।
4. কিছু জানা না থাকলে রেজিস্টারে "নিচু" লেখা। খালি ফিল্ডে MISSING লেখা উচিত। অনুমান সেই সিস্টেমগুলোকে লুকায় যাদের সবচেয়ে বেশি মনোযোগ দরকার।
5. সবকিছুর জন্য একটাই চেকলিস্ট। তা হয় ছোট টুলে সময় নষ্ট করে, নয়তো বড় টুলে মিথ্যে স্বস্তি দেয়। প্রশ্নগুলো ঝুঁকির সঙ্গে মাপুন।

নিজে চেষ্টা করুন

এই কাজগুলো এই পাতার রেজিস্টার ব্যবহার করে। এগুলো ঝুঁকির স্কোরিং, নিয়ন্ত্রণ ও সিদ্ধান্ত: একটা টয় রিস্ক রেজিস্টার বানানো পাতার অবশিষ্ট ঝুঁকির ধারণা আবার ছোঁয়।

1. সহজ। প্রমাণ বানানো ছাড়া Marking pilot রেকর্ডটা ঠিক করুন: স্তর "high", বৈশিষ্ট্য "personal_data" ও "children"। চেকারটা চালান। এখনও কী কী ফ্ল্যাগ আসে, আর তা কেন ঠিক?
2. মাঝারি। কম-স্তরের একটা টুলের জন্য সর্বোচ্চ ৬ প্রশ্নের একটা আনুপাতিক চেকলিস্ট লিখুন, যার প্রতিটার উত্তর একটা নাম, তারিখ বা লিংক দিয়ে দেওয়া যায়, আর ৪০ আইটেমের কোন দুটো বাদ দিলেন ও কেন, তা বলুন।
3. কঠিন। বাওবাবের ওয়ার্কফ্লো ওয়ার্কশিট সম্পূর্ণ করুন, তারপর এমন দুটো জায়গা বলুন যেখানে একজন যুক্তিসঙ্গত সহকর্মী বেশি নিয়ন্ত্রণের পক্ষে বলবেন, আর দুটো যেখানে কম নিয়ন্ত্রণের পক্ষে।

উত্তর

সহজ। পরিস্থিতি যা দেয় শুধু তা-ই লিখুন, বাকি ফিল্ড খালি রাখুন।

for rec in REGISTER:
    if rec["system"] == "Marking pilot":
        rec.update(tier="high", traits=["personal_data", "children"])
        for line in flags(rec):
            print("-", line)

- MISSING approval (who and when)
- MISSING next_review date
- SPECIALIST review needed: privacy (none recorded)
- SPECIALIST review needed: safeguarding (none recorded)

পাস চেকলিস্ট: মালিক যেমন ছিল তেমনই থাকে; কোনো অনুমোদন, রিভিউয়ের তারিখ বা বিশেষজ্ঞ বানানো হয়নি; আউটপুটে অনুমোদনের অভাব, রিভিউ তারিখের অভাব আর দুটো বিশেষজ্ঞ রিভিউ (গোপনীয়তা ও শিশু-সুরক্ষা) আছে। দুর্বল উত্তর ফ্ল্যাগ সরাতে একটা তারিখ বা "privacy: done" বসিয়ে দেয়।

মাঝারি। একটা ভালো উত্তর: "কার মালিকানায়? এটা কীসের জন্য, কীসের জন্য নয়? কী ডেটা ঢোকে? আউটপুট গুরুত্ব পাওয়ার আগে কে পড়েন? সমস্যা কোথায় জানানো যায়? পরবর্তী রিভিউ কবে?" বাদ দেওয়া আইটেম হতে পারে "Culture supportive" (উত্তর দেওয়া যায় না) আর "Compliance confirmed" (অন্য আইটেমের পুনরাবৃত্তি)। পাস চেকলিস্ট: সর্বোচ্চ ৬ প্রশ্ন; প্রতিটার উত্তরের ধরন প্রমাণ; বাদ দেওয়া আইটেমের কারণ আছে। দুর্বল উত্তরে "ensured" বা "considered"-এর মতো অস্পষ্ট শব্দ থেকে যায়।

কঠিন। ৪০ জনের প্রতিষ্ঠানের জন্য বেছে নেওয়া ভূমিকাসহ একটা আদর্শ ওয়ার্কফ্লো:

Step              Who                         Evidence kept     Time limit    Triggers review of
1 Intake          requester, Operations lead  register entry    2 days        -
2 Tier decision   Operations lead, Ines       3 answers: data,  2 days        tier, if use grows
                                              users, harm
3 Approval        low: owner; medium: reviewer from another team; high: Director plus specialist
4 Change          owner proposes; the tier's  version + test    before        the assessment
                  approver decides            run               release
5 Risk acceptance Director, written template  signed record     6-month       the risk, when it
                                                                expiry        lapses
6 Concern         any manager or named person reference number  ack in 2      policy, if a
                  outside the line                              days          pattern appears
7 Review / audit  high: 6 months; others: 12; yearly audit of 3 systems by another team

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

সারসংক্ষেপ

• নিজের যাচাই, রিভিউ ও অডিট আলাদা রাখুন; স্বাধীনতা সীমিত হলে আপসটা লিখে রাখুন।
• আগে থেকে ঠিক করুন কোন পরিবর্তনে কোন অনুমোদন লাগবে, আর অনুমোদনকে একটা ভার্সনের সঙ্গে বাঁধুন।
• প্রতিটা ঝুঁকি মেনে নেওয়া একটা নামধারী ভূমিকা ও মেয়াদসহ লিখুন; সিস্টেম ও পলিসি দুটোই ক্যালেন্ডার ও ঘটনার ট্রিগারে রিভিউ করুন।
• রেজিস্টার MISSING ও OVERDUE জানাবে, অনুমান করবে না; বিশেষজ্ঞ রিভিউ আর কর্মীদের উদ্বেগ জানানোর নিরাপদ পথ ছবিটা সম্পূর্ণ করে।
• গভর্ন্যান্স ঝুঁকির সঙ্গে মাপুন, আর উদ্ভাবনের সঙ্গে ভারসাম্য খোলাখুলি ঠিক করুন, কী ছাড়ছেন তা নাম ধরে বলে।

এরপর: পরিমাপ ও ঝুঁকি-নিয়ন্ত্রণের পরীক্ষা: নিয়ন্ত্রণগুলো আসলে কাজ করছে কি না পাতায় লক্ষ্য ও নিয়ন্ত্রণকে পরিমাপ এবং একটা ছোট টেস্ট হারনেসে রূপ দেওয়া হবে।