ডেটা অধিকার, স্থানান্তর ও রেকর্ড: অনুরোধ, সংরক্ষণ ও অডিট ট্রেইল

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

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

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

যা শিখবেন

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

সীমান্ত-পেরোনো স্থানান্তর

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

আইনি নোট (২০২৬-১০-১২ অনুযায়ী; আইনি পরামর্শ নয়): GDPR-এর অধীনে, ইউরোপীয় কমিশনের ডেটা-সুরক্ষা পাতাগুলো EU-এর বাইরের প্রাপকের কাছে ব্যক্তিগত ডেটা পাঠানোর কয়েকটা পথ বর্ণনা করে। Article 45 অনুযায়ী কমিশন সিদ্ধান্ত নিতে পারে যে কোনো দেশ পর্যাপ্ত সুরক্ষা দেয়, ফলে বাড়তি সুরক্ষা ছাড়াই ডেটা যেতে পারে; কমিশনের পাতা এমন দেশের তালিকা দেয় (যা একটা স্ন্যাপশট, বদলায়), আর যুক্তরাষ্ট্রের ক্ষেত্রে ২০২৩ সালের ১০ জুলাইয়ের সিদ্ধান্ত শুধু EU-US Data Privacy Framework-এর অন্তর্ভুক্ত সংস্থার জন্য প্রযোজ্য, অর্থাৎ পর্যাপ্ততা দেশ-নির্দিষ্ট এবং যুক্তরাষ্ট্রের ক্ষেত্রে সংস্থা-নির্দিষ্ট। স্ট্যান্ডার্ড কন্ট্রাকচুয়াল ক্লজ (Standard Contractual Clauses) হলো আগে-অনুমোদিত মডেল চুক্তি-ধারা, যার হালনাগাদ সংস্করণ ২০২১ সালের ৪ জুন গৃহীত হয়েছে এবং সুরক্ষাসহ EU-বহির্ভূত প্রাপকের কাছে স্থানান্তরে ব্যবহার করা যায়। কমিশনের পাতাগুলো বাইন্ডিং কর্পোরেট রুলস, সার্টিফিকেশন, আচরণবিধি ও ডিরোগেশনের নামও বলে। EU-এর বাইরের নিয়ম এখানে আলোচিত হয়নি। উৎসের ধরন: কমিশনের ডেটা-সুরক্ষা পাতা। আপনার দেশ ও খাতের বর্তমান সরকারি পাঠ দেখে নিন।

থার্ড পার্টি ও সাব-কন্ট্রাক্টর

থার্ড-পার্টি প্রসেসিং ও সাব-কন্ট্রাক্টর নথিভুক্ত করুন। ডেটা প্রায়ই একটা শৃঙ্খল ধরে যায়: আপনার কোম্পানি, একজন ভেন্ডর, ভেন্ডরের হোস্টিং প্রোভাইডার, একটা সাপোর্ট টুল। প্রতিটা সংযোগ এমন একটা পক্ষ যাকে হয়তো আপনি বাছেননি। কোন আইনি শর্ত কোন সংযোগে প্রযোজ্য তা আপনার নিয়মের ওপর নির্ভর করে, তাই যাচাই করুন; রেকর্ডটা নিজে সরল।

টেমপ্লেট:

Processing chain: <feature>
party            role               data seen     location   agreement   told of changes?
Harbourline      holds the CVs      all fields    Country P  n/a (owner) n/a
ScoreVendor      scores CV text     cv_text       MISSING    MISSING     MISSING
  its host       runs the servers   cv_text copy  MISSING    MISSING     MISSING
  its support    shows errors       cv excerpts   MISSING    MISSING     MISSING
Rule: a MISSING link is not "probably fine"; it is a question with an owner and a date.

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

শিশু ও দুর্বল গোষ্ঠী

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

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

Situation:  Selam in Addis Ababa runs StudyBuddy, a homework-help app for ages 11 to 17 (invented).
Feature:    an AI helper answers questions; the app stores the chats to "improve the product".
People:     students, parents or guardians, teachers, a vendor that hosts the model.
Harm:       chats may hold personal worries, names and school details, and are kept for years.
Options:    A keep everything;  B keep chats 30 days, then delete;  C store nothing, keep counts.
Unknowns:   the age rules where the students live; what the vendor does with the chats.

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

আইনি নোট (২০২৬-১০-১২ অনুযায়ী; আইনি পরামর্শ নয়): GDPR-এর অধীনে, একটা অনানুষ্ঠানিক পাঠ-সাইট থেকে সহজ ভাষায় (সরকারি পাঠ EUR-Lex-এ): Article 8 বলে, শিশুকে সরাসরি দেওয়া সম্মতি-ভিত্তিক অনলাইন সেবায় ১৬ বছর বয়স থেকে সম্মতি বৈধ, এর কম বয়সে তা অভিভাবকের কাছ থেকে আসতে হবে। সদস্য রাষ্ট্র কম বয়স ঠিক করতে পারে, তবে ১৩-র নিচে নয়, আর কন্ট্রোলারকে অভিভাবকের সম্মতি যাচাইয়ের যুক্তিসঙ্গত চেষ্টা করতে হবে। তাই বয়সের সীমা দেশভেদে আলাদা। উৎসের ধরন: Article 8-এর পাঠ। আপনার দেশ ও খাতের বর্তমান সরকারি পাঠ দেখে নিন।

ডেটার মান ও প্রতিনিধিত্ব

ডেটার মান ও প্রতিনিধিত্বের সীমাবদ্ধতা মূল্যায়ন করুন। মানের কয়েকটা অংশ আছে, আর প্রতিটা নীরবে ব্যর্থ হতে পারে।

রেফারেন্স থাকলে প্রতিনিধিত্ব তার সঙ্গে তুলনা করা যায়। নিচের কোড একটা কাল্পনিক টেস্ট সেটকে অঞ্চলভিত্তিক কাল্পনিক রেফারেন্স অংশের সঙ্গে তুলনা করে, আর রেফারেন্স না থাকলে তুলনা করতে অস্বীকার করে। ০.৭৫ কাট-অফটা একটা টিমের বাছাই, স্ট্যান্ডার্ড নয়।

টয় ডেটা: অঞ্চল অনুযায়ী ২০০টা কাল্পনিক টেস্ট সিভি।

TEST = {"region X": 150, "region Y": 30, "region Z": 20, "region W": 0}
REFERENCE = {"region X": 0.40, "region Y": 0.35, "region Z": 0.25}     # invented reference shares
total = sum(TEST.values())
for region, n in TEST.items():
    if region not in REFERENCE:
        print(f"{region}: no reference share (MISSING), not compared")
        continue
    ratio = (n / total) / REFERENCE[region]
    print(f"{region}: {n / total:.2f} of the test set vs {REFERENCE[region]:.2f} of the reference,"
          f" ratio {ratio:.2f}{'  <-- under-represented' if ratio < 0.75 else ''}")

region X: 0.75 of the test set vs 0.40 of the reference, ratio 1.88
region Y: 0.15 of the test set vs 0.35 of the reference, ratio 0.43  <-- under-represented
region Z: 0.10 of the test set vs 0.25 of the reference, ratio 0.40  <-- under-represented
region W: no reference share (MISSING), not compared

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

মালিকানা, প্রবেশাধিকার ও ব্যবহার

ডেটার মালিকানা আর প্রবেশাধিকারের পার্থক্য করুন। মানুষ "আমাদের ডেটা" বলতে কয়েক রকম সম্পর্ক বোঝান, আর রেকর্ডে বলা উচিত কোনটা। কে কী ধরে রাখেন তা ঠিক হয় চুক্তি, লাইসেন্স ও আইনে, তাই উত্তরটা লিখে রাখা হয়, ধরে নেওয়া হয় না।

Ngozi ক্লায়েন্টের টেবিল খুলতে পারেন, কিন্তু তার মানে এই নয় যে নিজের পোর্টফোলিওর জন্য একটা কপি রাখতে বা অন্য ক্লায়েন্টের কাজে পুনর্ব্যবহার করতে পারেন। প্রশ্নগুলো হলো কে অধিকার ধরে রাখেন, চুক্তি কপি ও পুনর্ব্যবহার নিয়ে কী বলে, আর টেবিলের মানুষেরা তা আশা করবেন কি না। চুক্তি চুপ থাকলে তিনি কাজ করার আগে জিজ্ঞেস করেন।

কপিরাইট ও ট্রেনিং-ডেটা বিতর্ক

কপিরাইট ও ট্রেনিং-ডেটা বিতর্ক পরীক্ষা করুন। মডেল ট্রেনিংয়ে কপিরাইটযুক্ত কাজ ব্যবহার আইনসম্মত কি না তা বিতর্কিত, আর একাধিক পক্ষের যুক্তি বিগিনার পাতা কপিরাইট, লাইসেন্স ও কৃতিত্বস্বীকার: AI-এর আউটপুট ও উৎস উপকরণ ব্যবহার-এ সাজানো আছে। এই পাতা তা পুনরাবৃত্তি করে না, পক্ষও নেয় না। এই পাতা জিজ্ঞেস করে একটা টিমের কী লিখে রাখা উচিত, যাতে সিদ্ধান্ত যা-ই হোক সে দেখাতে পারে কী ব্যবহার করেছে এবং কোন শর্তে। অবস্থা দ্রুত বদলায়, তাই নোটটা তারিখ-দেওয়া।

আইনি নোট (২০২৬-১০-১২ অনুযায়ী; আইনি পরামর্শ নয়): US Copyright Office-এর পাতা ট্রেনিং নিয়ে একটা Part 3 রিপোর্টের কথা বলে, যা ২০২৫ সালের ৯ মে প্রি-পাবলিকেশন সংস্করণ হিসেবে প্রকাশিত, আর চূড়ান্ত সংস্করণ পরে আসবে; এই কোর্স তার সিদ্ধান্তগুলোর সারাংশ দেয় না। Bartz v. Anthropic (একটা মার্কিন আদালত) মামলায় Authors Guild জানায়, একটা ক্লাস সেটলমেন্ট ২০২৬ সালের ২০ জুলাই চূড়ান্ত অনুমোদন পেয়েছে, যা ২০২৫ সালের ২৫ আগস্ট পর্যন্ত তালিকাভুক্ত কাজের অতীত সংগ্রহ ও কপির দাবি মীমাংসা করে, কিন্তু আউটপুট-সংক্রান্ত দাবি বা ভবিষ্যৎ আচরণ নয়। সেটলমেন্ট হলো পক্ষগুলোর মধ্যে একটা চুক্তি, ট্রেনিং আইনসম্মত কি না তা নিয়ে রায় নয়। Thomson Reuters v. ROSS মামলায় মার্কিন Third Circuit আপিল আদালত ২০২৬ সালের ২৯ সেপ্টেম্বর একটা মতামত দাখিল করেছে, যাতে বলা হয়েছে একটা প্রকাশকের হেডনোট কপিরাইটযোগ্য এবং বিবাদীর একটা নন-জেনারেটিভ AI আইনি-গবেষণা টুলে তার ব্যবহার ফেয়ার ইউজ নয়; আদালত নিজেই বলে টুলটা জেনারেটিভ AI ছিল না এবং জেনারেটিভ-AI মামলাগুলো থেকে এটাকে আলাদা করে। ইউরোপীয় কমিশনের পাতা বলে, জেনারেল-পারপাস AI মডেলের প্রোভাইডারদের একটা কপিরাইট-কমপ্লায়েন্স পলিসি থাকতে হবে এবং টেমপ্লেট ব্যবহার করে ট্রেনিং কনটেন্টের সারাংশ প্রকাশ করতে হবে। সিদ্ধান্তগুলো তাদের নিজস্ব তথ্য ও দেশের জন্য প্রযোজ্য, আর অন্যত্র অবস্থান আলাদা ও বদলাচ্ছে। উৎসের ধরন: Copyright Office ও কমিশনের পাতা, আদালতের মতামত, আর সেটলমেন্টের জন্য একটা গৌণ উৎস। আপনার দেশ ও খাতের বর্তমান সরকারি পাঠ দেখে নিন।

টেমপ্লেট:

Training or reference data record: <dataset>
source and how acquired    licensed, purchased, partner, public web, own work, MISSING
terms in force             licence or terms text kept? version and date, MISSING
statements by the source   notices or terms about reuse or AI use, checked on <date>, MISSING
date and method retrieved  <date>, <tool>
who approved, and on what  <role>, <date>, <conditions>
open questions             what we do not know, and who will find out by when

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

ওপেন, লাইসেন্সড ও সীমাবদ্ধ ডেটা

ওপেন, লাইসেন্সড ও সীমাবদ্ধ ডেটার তুলনা করুন। লেবেলগুলো ব্যবহারের শর্ত বোঝায়, মান বা নিরাপত্তা নয়।

"ওপেন" মানে "শর্তহীন" নয়, আর ওপেন ডেটাতেও ব্যক্তিগত ডেটা থাকতে পারে, যেমন সাত নম্বর পাতার পুনঃশনাক্তকরণ গণনা দেখিয়েছে। সময়ের সঙ্গে ডেটাসেটের ধরনও বদলাতে পারে: লাইসেন্সের মেয়াদ ফুরাতে পারে, বা ওপেন ডেটা সীমাবদ্ধ ডেটার সঙ্গে মিশে সীমাবদ্ধ হয়ে যেতে পারে।

প্রস্তাবিত ফিচারের জন্য ব্যবহারের সীমা

প্রস্তাবিত ফিচারের জন্য ডেটা-ব্যবহারের সীমা নথিভুক্ত করুন। কোনো ফিচার ডেটাসেট ব্যবহারের আগে লিখুন কোন সীমার ভেতরে তাকে থাকতে হবে। এটা সাত নম্বর পাতার পুনর্ব্যবহারের প্রশ্ন, যা এখন এমন একটা নিয়ম যা রিভিউয়ার যাচাই করতে পারেন।

কাল্পনিক পরিস্থিতি: ShortlistHelper-এর দ্বিতীয় সংস্করণ D1 আবেদনকারীর সিভি আর D3 চাকরির প্রয়োজনীয়তা পড়ার প্রস্তাব দিচ্ছে।

Use-restriction sheet: ShortlistHelper v2
dataset              allowed use                  not allowed                  enforced by
D1 applicant CVs     order CVs for the job they   tool testing, other jobs,    access list, job tag
                     were sent for                training, ranking staff      on each record
D3 job requirements  ordering and reports         sharing with other clients   contract clause
Conditions:         vendor may not keep or reuse CV text; shortlists go to clients without
                    scores; any new use needs a new sheet approved by the privacy owner.
Expires:            2027-03-31, or when notice v3 is replaced.
Owner:              Head of recruitment.

শিটটা কাজের কারণ, একটা প্রত্যাখ্যান তার দিকে নির্দেশ করতে পারে ("শিট বলছে ট্রেনিং নয়"), আর এটা পরিধি-বৃদ্ধি দৃশ্যমান করে: নতুন ব্যবহারের অনুরোধ মানে নতুন শিট, চুপচাপ ব্যতিক্রম নয়।

ইনভেন্টরি ও সংরক্ষণ-সূচি বানান

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

টয় ডেটা: পাঁচটা কাল্পনিক ডেটাসেট।

from datetime import date, timedelta

ASOF = date(2026, 10, 12)          # fixed "today"
REQUIRED = ["owner", "purpose", "collected_under", "includes_children", "recipients", "stored_in",
            "retention_days", "clock_date", "restrictions"]
UNCLEAR = {"", "not stated", "unknown", "tbc"}
BASE = {"owner": "Head of recruitment", "includes_children": "no", "recipients": "none",
        "stored_in": "Country P", "restrictions": "internal use only"}
INVENTORY = {
    "applicant CVs": {**BASE, "purpose": "assess applicants", "collected_under": "notice v3",
                      "retention_days": 365, "clock_date": date(2026, 3, 20),
                      "recipients": "ScoreVendor"},
    "fit scores": {**BASE, "purpose": "order CVs", "collected_under": "notice v3",
                   "retention_days": 365, "clock_date": date(2026, 3, 20)},
    "request logs": {**BASE, "owner": "IT lead", "purpose": "find faults", "collected_under": "internal",
                     "retention_days": 90, "clock_date": date(2026, 6, 1)},
    "past outcomes": {**BASE, "purpose": "label for tests", "collected_under": "employment records",
                      "clock_date": date(2025, 11, 4), "restrictions": "tbc"},
    "interview notes": {**BASE, "purpose": "record impressions", "retention_days": 180},
}


def schedule(inventory, today=ASOF):
    for name, rec in inventory.items():
        absent = [f for f in REQUIRED if f not in rec]
        vague = [f for f in REQUIRED if f in rec and str(rec[f]).strip().lower() in UNCLEAR]
        days, start = rec.get("retention_days"), rec.get("clock_date")
        if isinstance(days, int) and start:
            due = start + timedelta(days=days)
            left = (due - today).days
            status = f"OVERDUE by {-left} days" if left < 0 else f"due in {left} days"
        else:
            due, status = None, "CANNOT SCHEDULE"
        print(f"{name:<16}delete by {str(due or 'n/a'):<11}{status}")
        if absent or vague:
            print(f"    MISSING: {', '.join(absent) or '-'} | UNCLEAR: {', '.join(vague) or '-'}")


schedule(INVENTORY)

applicant CVs   delete by 2027-03-20 due in 159 days
fit scores      delete by 2027-03-20 due in 159 days
request logs    delete by 2026-08-30 OVERDUE by 43 days
past outcomes   delete by n/a        CANNOT SCHEDULE
    MISSING: retention_days | UNCLEAR: restrictions
interview notes delete by n/a        CANNOT SCHEDULE
    MISSING: collected_under, clock_date | UNCLEAR: -

রিকোয়েস্ট লগ মুছে ফেলার তারিখ পেরিয়ে ৪৩ দিন হয়ে গেছে: IT লিডের জন্য একটা পর্যবেক্ষণ। "Past outcomes" সূচিবদ্ধ করা যায় না কারণ তার সংরক্ষণকাল নেই, আর তার সীমা শুধু "tbc"। "Interview notes"-এর ঘড়ির শুরুর তারিখ নেই এবং collected_under নেই। সাত নম্বর পাতার নিয়ম বহাল: ফাঁক হলো মালিকসহ একটা কাজ, ভরাট করার জিনিস নয়।

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

অডিট ও প্রকিউরমেন্ট রিভিউ চায় প্রসেসিং চেইন, ব্যবহার-সীমার শিট আর সংরক্ষণ-সূচি। কোনো গ্রাহক যখন জিজ্ঞেস করেন "আমার ডেটা কোথায় যায়, আর কবে মোছা হয়?", উত্তরটা এই রেকর্ড থেকে আসে, নইলে আদৌ আসে না।

সাধারণ ভুল

1. ভেন্ডরকে শৃঙ্খলের শেষ ধাপ ভাবা। জিজ্ঞেস করুন ভেন্ডর ডেটা কোথায় পাঠায় এবং তার সাব-কন্ট্রাক্টর কারা।
2. "ওপেন" বা "প্রকাশ্য" মানে শর্তহীন ধরে নেওয়া। লাইসেন্স ও শর্ত লিখে রাখুন।
3. প্রবেশাধিকারকে মালিকানা ভাবা। একটা ফাইল খুলতে পারা মানে তা রাখা বা পুনর্ব্যবহারের অধিকার নয়।
4. ডেটাসেটের নিয়ম আছে, কিন্তু তার কপির নেই। স্কোর, এক্সপোর্ট, ব্যাকআপ ও লগেরও তারিখ লাগে।
5. গভর্ন্যান্স রেকর্ডে কপিরাইট বিতর্কে পক্ষ নেওয়া। রেকর্ডের কাজ তথ্য ও শর্ত, রায় নয়।

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

এই পাতার নেমস্পেস ব্যবহার করুন। কঠিন অনুশীলন একটা কৃত্রিম ডেটাসেটের গভর্ন্যান্স রেকর্ড রিভিউ করতে বলে।

1. সহজ। সূচির আউটপুট থেকে বলুন এই সপ্তাহে কোন ডেটাসেটে পদক্ষেপ দরকার, আর প্রতিটার পদক্ষেপ কী।
2. মাঝারি। "interview notes"-কে ২০২৬-০৭-০১ একটা clock_date দিন এবং শুধু সেটার জন্য schedule চালান। কী বদলায়, আর কোন ভুল এখনও থাকে?
3. কঠিন। নিচের রেকর্ডটা রিভিউ করুন, যা স্কুলের শিক্ষার্থীদের সেবা দেওয়া একটা মেন্টরিং অ্যাপের জন্য কাল্পনিক। যত ফাঁক পান তার তালিকা করুন, প্রোগ্রাম যেগুলো ধরতে পারে আর মানুষকে যেগুলো বিচার করতে হয় সেভাবে ভাগ করুন, এবং সুপারিশ লিখুন।

টয় ডেটা: একটা গভর্ন্যান্স রেকর্ড।

REC = {"owner": "the product team", "purpose": "improve the app", "collected_under": "terms of use v2",
       "includes_children": "yes", "recipients": "analytics add-on", "stored_in": "overseas servers",
       "retention_days": "as long as needed", "clock_date": date(2026, 9, 1), "restrictions": "not stated"}

উত্তর

সহজ। রিকোয়েস্ট লগ মেয়াদোত্তীর্ণ: মুছে ফেলুন এবং কে নিশ্চিত করেছেন তা লিখুন। "Past outcomes" ও "interview notes" সূচিবদ্ধ করা যায় না: মালিকের কাছে সংরক্ষণকাল চান (আর নোটের ক্ষেত্রে শুরুর তারিখ ও অনুমতির ভিত্তিও)। Applicant CVs ও fit scores-এর মেয়াদ আসতে ১৫৯ দিন বাকি, কিন্তু তাদের একজন প্রাপক (ScoreVendor) আছে যার চুক্তি ফাইলে আছে বলে দেখানো হয়নি; সাত নম্বর পাতার প্রবাহ-যাচাই এখানে খাটে। পাস চেকলিস্ট: মেয়াদোত্তীর্ণ ও সূচিবদ্ধ-করা-যায়-না আইটেম আলাদা; প্রতিটা পদক্ষেপে একজন মালিকের নাম আছে; কোনো তারিখ বানানো হয়নি। দুর্বল উত্তর জিজ্ঞেস না করেই "past outcomes" মুছে দেয়, বা "ডিফল্ট হিসেবে" ৩৬৫ দিন বসিয়ে দেয়।

মাঝারি।

schedule({"interview notes": {**INVENTORY["interview notes"], "clock_date": date(2026, 7, 1)}})

interview notes delete by 2026-12-28 due in 77 days
    MISSING: collected_under | UNCLEAR: -

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

কঠিন। প্রথমে প্রোগ্রাম কী পায়:

schedule({"mentor chats": REC})

mentor chats    delete by n/a        CANNOT SCHEDULE
    MISSING: - | UNCLEAR: restrictions

প্রোগ্রাম শুধু দেখে সংরক্ষণকাল সংখ্যা নয়, আর সীমা অস্পষ্ট। বাকিটা একজন মানুষকে বিচার করতে হয়:

Program found:  retention_days is not a number (CANNOT SCHEDULE); restrictions UNCLEAR.
Person found:   owner is a team, not a named role;
                purpose "improve the app" is too broad to limit anything;
                "terms of use v2" is a weak basis for chats of children, and consent rules for
                children vary by country (see the legal note above);
                recipients "analytics add-on" has no name, agreement or subcontractor list;
                stored_in "overseas servers" names no country, so no transfer question can be asked;
                no use-restriction sheet; no representation check for the age groups.
Recommendation: do not use the transcripts for anything beyond running the app until the owner is
                named, a retention period is set, the add-on and location are identified, and the
                privacy owner has reviewed the basis for children's data.
                Review in 30 days.

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

সারসংক্ষেপ

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

এরপর: মডেল কার্ড, সিস্টেম কার্ড ও ডেটাশিট: কী নথিভুক্ত করবেন এবং কার জন্য পাতায় এই রেকর্ডগুলো পাঠকের জন্য ডকুমেন্টে রূপ পায়: একটা মডেল কার্ড, সিস্টেম কার্ড ও ডেটাসেট ডেটাশিটে কী লেখা উচিত।