# Kulular Teknoloji, النسخة العربية الكاملة

## زر الموافقة الذي تسمّونه رقابة بشرية غالبًا لا يعمل

Source: https://kulular.com.tr/ar/writing/ai-oversight

الجملة التي أسمعها أكثر من غيرها حين يُطرح موضوع حوكمة الذكاء الاصطناعي هي هذه: "هناك موافقة بشرية، القرار ليس متروكًا للآلة."
حين أسمعها، لديّ سؤال واحد. ما معدل موافقتكم؟
عادةً لا يوجد جواب، لأن أحدًا لا يقيسه. وحيث يُقاس، يكون الرقم عادةً فوق ثمانية وتسعين بالمئة. المراجِع يرفض توصية النموذج مرة واحدة تقريبًا من كل خمسين قرارًا. تسمية ذلك رقابة بشرية صحيحة شكليًا وخاطئة وظيفيًا. النظام هو من يقرر، والإنسان يوقّع فقط.
لماذا يتوقف زر الموافقة عن العمل
السبب ليس سوء نية. إنه تصميم.
أروا شخصًا ثلاثمئة توصية يوميًا واطلبوا منه الموافقة على كل واحدة، وسيؤتمت هو نفسه خلال أسابيع. وإذا كانت دقة النموذج عالية، يحدث هذا أسرع، لأن المراجِع يكون عادةً محقًا في المرات القليلة التي يرفض فيها، فيتوقف عن الثقة بحكمه الخاص.
هذه ظاهرة موثّقة تُسمى تحيّز الأتمتة: كلما كان أداء النظام أفضل، ضَعُفت الرقابة البشرية عليه. أي تصميم للرقابة يجب أن يأخذ ذلك بعين الاعتبار منذ البداية.
ثلاثة شروط لتكون الرقابة حقيقية
لكي تكون الرقابة فعّالة، يجب أن تتحقق ثلاثة أمور معًا.
يجب أن يكون بمقدور المراجِع رؤية أساس التوصية. إذا لم تُعرض المدخلات التي اعتمد عليها النموذج، لا يمكن للشخص إلا الحكم على النتيجة، والحكم الصحيح على النتيجة يعني إعادة البتّ في القضية من الصفر. هذا يجعل الرقابة مستحيلة عمليًا.
يجب ألا يكلّف الرفض أي جهد إضافي. المستخدم الذي يضطر لملء استمارة وكتابة تسويغ والحصول على موافقة مدير كلما رفض توصية سيتوقف عن الرفض. مسار الرفض يجب أن يكون سهلًا على الأقل بقدر مسار الموافقة.
يجب أن يؤدي الرفض إلى نتيجة ما. إذا سُجّلت التوصيات المرفوضة ولم يطّلع عليها أحد، يلاحظ المراجِع ذلك وينسحب تدريجيًا. إعادة تغذية الحالات المرفوضة في تحسين النموذج يُبقي الرقابة حيّة.
لا رقابة من دون قياس
حتى بعد تحقق هذه الشروط الثلاثة، يبقى القياس ضروريًا.
كحد أدنى، ينبغي تتبّع ثلاثة مؤشرات: معدل الرفض، متوسط الوقت المستغرق لكل قرار، وعدد المرات التي تبيّن فيها لاحقًا أن التوصية المرفوضة كانت صحيحة. إذا انخفض الوقت لكل قرار إلى ثوانٍ معدودة، فالرقابة لا تحدث. وتنطبق النتيجة نفسها إذا اقترب معدل الرفض من الصفر.
قلة قليلة من المؤسسات تستطيع الإجابة عن هذه الأسئلة عند طرحها في تدقيق. ومع ذلك، ليست صعبة القياس، فهي تُستخرج من بيانات ينتجها النظام أصلًا.
حق الاعتراض يشكّل البنية
الحكم ذو الصلة من المادة 11 من القانون التركي رقم 6698 يمنح الشخص حق الاعتراض حين تنشأ نتيجة ضارة به حصرًا عن تحليل أنظمة آلية.
النتيجة التقنية مباشرة. عندما يصل اعتراض، يجب أن تكون قادرًا على إثبات كيفية التوصل إلى القرار. إن لم تستطع إثباته، لا يمكنك الدفاع عنه.
القاعدة البنيوية المترتبة على ذلك هي: نموذج لا يُنتج تسويغًا لا يمكن استخدامه في مسار يُنتج نتيجة تخص شخصًا. يجب كتابة هذا كقيد على اختيار النموذج منذ البداية. إضافة قابلية التفسير لاحقًا غير ممكنة في معظم البنى.
الاحتفاظ بسجل لا يكفي، عليك تسجيل الشيء الصحيح
سجل التدقيق يُفهم عادةً على أنه الاحتفاظ بسجل، لكن محتوى السجل هو ما يحدد قيمته.
لكي يكون القرار قابلًا للمراجعة لاحقًا، يجب تسجيل خمسة عناصر معًا: البيانات التي دخلت إلى النظام، إصدار النموذج، المخرج المُنتَج، التسويغ الذي يستند إليه المخرج، وقرار الإنسان النهائي. إذا حُفظت هذه العناصر الخمسة في أنظمة منفصلة، لا يمكن مطابقتها لاحقًا. إذا لم يُسجَّل إصدار النموذج، فلا سبيل للإجابة، بعد أشهر، عن سؤال "ماذا كان يقوله النموذج في تلك اللحظة؟"
عدم تسجيل إصدار النموذج هو الثغرة الوحيدة التي أراها الأكثر تكرارًا عمليًا. يُحدَّث النموذج، وتُفسَّر القرارات القديمة بالرجوع إلى النموذج الجديد، وهذا لا يصمد.
يجب إظهار الفرق بين الثقة واليقين وعدمهما
نقطة أخيرة. يجب على النظام أن يُظهر، بطريقة يستطيع المستخدم تمييزها، متى يُنتج مخرجًا بثقة منخفضة مقابل ثقة عالية.
من دون هذا التمييز، يثق المستخدم بكل شيء على قدم المساواة ولا يحصل على تحذير بالضبط أين يكون الخطأ أكثر احتمالًا. ومع ذلك، فإن عدم يقين النموذج نفسه قابل للقياس عادةً. إظهار هذا القياس في الواجهة هو أرخص تحسين وأكثره فعالية يمكن إجراؤه على الرقابة.
لو كان عليّ اختيار شيء واحد لفعله في مشروع ذكاء اصطناعي اليوم، فهذا ما سأختاره.

## معظم نزاعات البرمجيات تعود إلى بند واحد مفقود

Source: https://kulular.com.tr/ar/writing/software-development-contracts

عندما يصل ملف نزاع برمجي إلى مكتب، عادةً ما يتجادل الطرفان حول شيء واحد: هل تعمل البرمجية أم لا.
سبب تعذّر حسم ذلك الجدل ليس تقنيًا. العقد لم يحدد إطلاقًا ما تعنيه "تعمل". من دون معيار قبول، يقول المطوّر إنها سُلِّمت، ويقول العميل إنه لم يستلمها، وكلاهما محق بمقياسه الخاص.
هذه الفجوة الواحدة هي الخيط المشترك عبر معظم نزاعات البرمجيات التي رأيتها.
كيف تُكتب بند قبول يعمل فعليًا
القبول هو اللحظة التي تُطلق العواقب القانونية للتسليم، بما فيها بدء سريان فترة ضمان العيوب. تاريخ قبول غير محدد يعني تاريخ نهاية غير محدد للمسؤولية أيضًا.
بند قبول عامل يغطي: قائمة اختبارات القبول، والبيئة التي تعمل فيها، ومن يشغّلها، ومدة الاعتراض، وحكمًا باعتبار القبول قد وقع إذا لم يُثَر اعتراض خلال تلك المدة.
العنصر الأكثر إغفالًا هو بيئة الاختبار. البرمجية التي تعمل على جهاز المطوّر قد لا تعمل في بيئة العميل، وعند تلك النقطة تصبح المسؤولية مسألة جدال. حدّدوا البيئة في العقد ولن ينشأ الجدال.
ربط القبول بالرضا هو أسوأ الخيارات على الإطلاق. القبول المشروط بـ"رضا العميل" يخلق التزامًا مفتوحًا، وعمل المطوّر لا ينتهي فعليًا أبدًا.
حقوق الملكية الفكرية لا تنتقل من تلقاء نفسها
الخطأ الشائع الثاني هو افتراض حول الملكية. يميل العملاء إلى الاعتقاد بأن دفع ثمن العمل يجعلهم مالكي الشيفرة. هذا ليس الموقف القانوني.
برامج الحاسوب محمية كمصنّفات بموجب القانون رقم 5846، وما لم يُتفق على خلاف ذلك، تبقى الحقوق المادية مع المؤلف. أي نقل يجب أن يُنصّ عليه صراحةً، ويُصاغ كتابةً، ويسرد الحقوق المنقولة واحدًا تلو الآخر. بيان عام مثل "جميع الحقوق منقولة" عرضة للنزاع.
علاوة على ذلك، يجب إبقاء ثلاث فئات منفصلة. الشيفرة المكتوبة خصيصًا للعميل تُنقل عادةً. مكوّنات المطوّر الموجودة مسبقًا تُرخَّص عادةً بدلًا من نقلها، مع كتابة نطاق الترخيص ومدته بشكل منفصل. مكوّنات المصادر المفتوحة تخضع لتراخيصها الخاصة، وينبغي إرفاق قائمة بما استُخدم بالعقد.
عندما لا تُفصل هذه الفئات الثلاث، هذا ما يحدث: يعتقد العميل أنه يملك كل الشيفرة، ويستمر المطوّر باستخدام مكتبته الخاصة في مشروع آخر، ولا تظهر المشكلة إلا بعد أن يكون النزاع قد بدأ بالفعل.
عقد بلا عملية إدارة تغيير لا ينجو من احتكاك المشروع
مهما كُتب النطاق جيدًا، تصل طلبات تغيير أثناء المشروع. إذا لم يذكر العقد كيفية معالجة تلك الطلبات، يتحول كل طلب إلى تفاوض.
بند عامل يجيب عن خمسة أسئلة. إلى من يُوجَّه الطلب، وبأي شكل؟ من يقيّم الأثر، وخلال كم يوم؟ كيف يُحسب أثر السعر والجدول الزمني؟ من الذي يعتمده؟ ماذا يحدث لطلب لا يُعتمَد؟
أجيبوا عن هذه الخمسة ويتوقف التغيير عن كونه أزمة ويصبح عملية.
أن تصبح معالج بيانات يمكن أن يحدث من دون أن يلاحظ أحد
حيث يملك المطوّر وصولًا إلى بيانات العميل الشخصية، يصبح معالج بيانات بالمعنى الوارد في القانون رقم 6698. هذا الوضع غالبًا ما يُكتسَب من دون أن يدرك أي من الطرفين ذلك.
الطريق الأكثر شيوعًا هو استخدام بيانات حقيقية في بيئة اختبار. تُسحب نسخة من قاعدة بيانات الإنتاج إلى بيئة تجريبية، ويعمل المطوّرون بها، ومن تلك النقطة توجد علاقة معالجة بيانات. إذا لم يذكر العقد شيئًا عنها، تسير العلاقة من دون أساس قانوني.
الحل الأنظف هو عدم خلق ذلك الوضع إطلاقًا. الاختبار ببيانات مُقنَّعة أو اصطناعية ليس صعبًا تقنيًا ويزيل معظم المخاطرة. حيث يكون الوصول إلى بيانات حقيقية ضروريًا فعلًا، يجب أن تُصاغ كتابةً موضوع المعالجة ومدتها وغرضها، والتزام المطوّر بالعمل وفق التعليمات فقط، واستخدام معالجين فرعيين، والتدابير الأمنية، وإعادة البيانات أو حذفها في نهاية العقد.
الصيانة عقد منفصل
أخيرًا، الصيانة والدعم. هذا التزام منفصل عن التطوير وينبغي معاملته بشكل منفصل.
ما يجب كتابته ليس وقت الاستجابة بل تصنيف الأعطال. من دون تعريف أي عطل يقع تحت أي فئة، تُطرح كل مشكلة كأولوية قصوى. بمجرد تعريف الفئات، يمكن تحديد أوقات الاستجابة والحل بشكل منفصل لكل واحدة.
هناك أيضًا مسألة قياس. التزام مستوى خدمة لا يمكن قياسه ليس له أثر عند الإخلال به. يجب أن ينص العقد على كيفية حدوث القياس وعلى أي سجلات يستند.
من ينبغي أن يصوغ هذا
كل واحد من هذه البنود يحتاج إلى أن يقرر القانون والهندسة معًا. لا يستطيع محامٍ كتابة معايير القبول وحده، لأنه لا يعرف ما القابل للاختبار فعليًا. ولا يستطيع مهندس كتابة نقل الملكية الفكرية وحده أيضًا.
طرف يدخل تفاوض العقد من دون فريق تقني ينتهي به الأمر موافقًا على شروط تتبيّن أنها غير قابلة للتطبيق. الشرط غير القابل للتطبيق يتصرف، بمجرد نشوء نزاع، كما لو لم يُكتب إطلاقًا.

## إذا كان مزوّد السحابة لديكم في الخارج، فأنتم تنقلون بيانات بالفعل

Source: https://kulular.com.tr/ar/writing/cross-border-data-transfers

اسألوا مؤسسة "هل تنقلون بيانات إلى الخارج؟" وسيكون الجواب عادةً لا. اسألوا أي خدمات تستخدم، وستظهر قائمة: استضافة سحابية، بريد إلكتروني، برمجية دعم عملاء، أداة تحليلات، مزوّد دفع، خدمة نسخ احتياطي.
معظم الخدمات في تلك القائمة ليست خوادمها في تركيا. الجواب الحقيقي كان نعم، والمؤسسة لم تكن تعلم.
سوء الفهم ينبع من كلمة "نقل" نفسها، التي توحي بفعل متعمّد: أخذ ملف وإرساله. لكن الاحتفاظ ببيانات على نظام في الخارج، أو معالجتها هناك، هو نقل أيضًا. لا حاجة إلى فعل إرسال منفصل.
أين يبدأ النقل فعليًا
المادة 9 من القانون التركي رقم 6698 تحكم النقل إلى الخارج. الصعوبة عمليًا ليست في الحكم نفسه، بل في تحديد متى يكون النقل قد وقع فعلًا.
كل الحالات الثلاث التالية تُنشئ نقلًا: بيانات مستضافة على خادم في الخارج؛ فريق في الخارج قادر على الوصول إلى النظام لأغراض الدعم؛ وبيانات تُعالَج في الخارج وتُعاد نتيجتها. الحالة الثالثة هي الأكثر إغفالًا. إذا استخدمتم خدمة تحليل نصوص ومقرّها الخارج، فإن النص الذي ترسلونه يُعالَج هناك. استرجاع النتيجة لا يعني عدم وقوع نقل.
موقعنا نفسه فيه هذه الميزة بالضبط. حقل النص الحر في الصفحة الرئيسية يرسل النص المُدخَل إلى مزوّد في الخارج للتحليل. لهذا يخصص إشعار حماية البيانات لدينا قسمًا لذلك، ويستطيع الزائر تصفّح بقية الموقع كاملة من دون استخدام ذلك الحقل إطلاقًا. ضمان عدم وقوع أي نقل إطلاقًا حين لا تُستخدم الميزة كان قرار تصميم بقدر الميزة نفسها.
العمود المفقود في الجرد
معظم جرود البيانات تُدرج الفئة والغرض ومدة الاحتفاظ. العمود المفقود هو: في أي بلد تقيم هذه البيانات ماديًا؟
أضيفوا هذا العمود وستتغيّر الصورة. بعض البيانات التي افترضت المؤسسة أنها في مركز بياناتها الخاص تتبيّن أنها في الخارج. النسخ الاحتياطية هي العنصر الأكثر إغفالًا، لأن خدمة النسخ الاحتياطي عادةً مزوّد منفصل ولا يتحقق أحد من موقعها.
عند بناء الجرد، اسألوا المزوّد مباشرة. إذا التزم العقد بشأن مكان إقامة البيانات، وثّقوا ذلك كتابةً. إن لم يفعل، يمكن للمزوّد تغيير الترتيب من طرف واحد ولن تكتشفوا ذلك.
سلسلة المعالجين الفرعيين
الطبقة الثانية أقل ظهورًا. المزوّد الذي تستخدمونه قد يعتمد بدوره على مزوّدين آخرين لبنيته التحتية الخاصة.
تستخدمون أداة دعم عملاء؛ تلك الأداة تعمل على مزوّد سحابي؛ يستخدم خدمة منفصلة للبحث؛ ويتصل بطرف ثالث لإرسال الإشعارات. بياناتكم تمرّ عبر السلسلة بأكملها.
لا يمكنكم التحكم الكامل بتلك السلسلة، لكن يمكنكم جعلها مرئية. يجب أن يشترط العقد الإشعار عند استخدام معالجين فرعيين ويمنح حق الاعتراض على أي تغيير. معظم مزوّدي الخدمات للمؤسسات يقدمون هذا أصلًا، فقط يجب طلبه.
ما ينبغي فعله
الخطوة الأولى هي بناء جرد للخدمات: اسم كل خدمة خارجية مستخدَمة، والغرض منها، وفئات البيانات الشخصية التي يمكنها الوصول إليها، وموقع خوادمها.
بمجرد وجود هذا الجدول، هناك ثلاثة خيارات: استبدال الخدمة ببديل مستضاف في تركيا، أو الانتقال إلى المنطقة التركية للمزوّد إن وُجدت، أو وضع النقل على أساس قانوني سليم باستخدام إحدى الآليات التي ينص عليها القانون.
كل الخيارات الثلاثة له تكلفة، والاختيار الصحيح يعتمد على طبيعة العمل. لكن عدم اختيار أي منها، أي عدم ملاحظة الوضع إطلاقًا، هو الخيار الأكثر كلفة، لأنه يعني أيضًا أن إشعار حماية البيانات لديكم يقدّم معلومات غير دقيقة، وثغرة واحدة تنتهي بانتهاك التزامين في آن واحد.
القواعد في هذا المجال ما زالت تتطور، وقرارات المجلس تعيد رسم الإطار بشكل دوري. تحققوا من الوضع الحالي قبل اختيار آلية نقل.

## أين تذهب الساعات الاثنتان والسبعون فعليًا، ساعة بساعة

Source: https://kulular.com.tr/ar/writing/data-breach-notification

يصل تنبيه إلى مكتب مؤسسة صباح يوم اثنين: وصول غير معتاد اكتُشف على خادم. من تلك اللحظة، تبدأ عدّاد الساعات الاثنتين والسبعين بالعمل.
اثنتان وسبعون ساعة تبدو وقتًا كافيًا. ما يلي هو سرد ساعة بساعة لأين يذهب هذا الوقت فعليًا، لأنه من دون رؤية هذا التفصيل يصعب فهم لماذا يجب أن يحدث الاستعداد للاختراق قبل أشهر من وقوعه، لا أثناءه.
الساعات الثماني الأولى: هل هذا اختراق فعلًا
المهمة الأولى هي تحديد ما إذا كان التنبيه حقيقيًا. قد يكون إنذارًا كاذبًا، أو عملية صيانة، أو صلاحية مُهيَّأة خطأً.
في هذه المرحلة، يمرّ الفريق التقني على السجلات. إذا لم تكن السجلات جيدة بما يكفي، وهي في معظم المؤسسات ليست كذلك، يتأخر هذا الأمر. من دون معرفة أي حساب وصل إلى أي جدول من أي عنوان، لا يمكن اتخاذ أي خطوة تالية.
النقطة الحرجة الأولى هي هذه: إذا لم تحتفظوا بسجلات، فإن العدّاد يبدأ بالنفاد من هنا، وهذا الوقت لا يُستعاد أبدًا.
الأربع والعشرون ساعة التالية: أي بيانات تأثرت
بمجرد إثبات أن هذا اختراق، يترتب سؤال واحد: ما البيانات الشخصية التي كانت على ذلك الخادم؟
المؤسسة التي لديها جرد محدَّث تجيب عن هذا في عشر دقائق. أما التي ليس لديها فتحاول معرفة ذلك بفحص مخطط قاعدة البيانات، والتحقق من أسماء الجداول، وسحب سجلات عينة، وسؤال المطوّرين. هذا وحده قد يستغرق يومًا كاملًا بسهولة.
النصف الثاني من السؤال أصعب. ماذا يوجد في النسخ الاحتياطية؟ هل توجد نسخة صُدِّرت لأجل تقرير؟ هل حُمِّلت عيّنة في بيئة اختبار؟ إذا لم تكن الإجابات مكتوبة في أي مكان، ينتهي الأمر بالتخمين، وإشعار مبني على تخمين ينتهي به الحال محتاجًا للتصحيح لاحقًا.
الاثنتا عشرة ساعة التالية: كم عدد الأشخاص المتأثرين
بمجرد تحديد النطاق، يجب إنتاج رقم: كم عدد أصحاب البيانات، وأي فئات البيانات، وأي المناطق الجغرافية.
الخطأ الشائع هنا هو تقريب الرقم. قول "نحو عشرة آلاف شخص" لن يؤدي إلى رفض الإشعار، لكن ظهور رقم حقيقي مختلف بشكل جوهري لاحقًا يضرّ بمصداقية رواية المؤسسة. إذا تعذّر إنتاج رقم دقيق، من الأفضل قول ذلك، وذكر السبب، بدلًا من التخمين.
الوقت المتبقي: إعداد الإشعار وتقديمه
الإشعار إلى المجلس يجب أن يغطي متى وكيف وقع الاختراق، وأي فئات البيانات تأثرت، وعواقبه المحتملة، والتدابير المتخذة والمخطط لها.
كتابة ذلك من صفحة فارغة تستهلك ما تبقى من وقت. المؤسسة التي لديها نموذج جاهز تملؤه خلال نصف ساعة. من المخوّل بالتوقيع عليه يجب أن يُحسم مسبقًا أيضًا؛ إذا بدأ ذلك النقاش في هذه المرحلة، فلا وقت له.
إخطار الأشخاص المتأثرين مهمة منفصلة. يتم ذلك في أقرب وقت معقول ممكن بمجرد تحديد الأشخاص المتأثرين؛ وحيث يتعذّر التواصل المباشر، تُستخدم طريقة مناسبة أخرى. اللغة مهمة هنا. رسالة مدفونة في تفاصيل تقنية تمنع الشخص من فهم ما يحتاج فعلًا إلى فعله.
ما يجب أن تحتويه الخطة فعليًا
الدرس المستفاد من الجدول الزمني أعلاه هو هذا: خطة الاستجابة للحوادث لا تكون جيدة إلا بقدر ما فكّرت فيه مسبقًا قبل وقوع الحادث.
تحتاج إلى توزيع واضح للأدوار: من يحدد نطاق الحادث، من يقرر أنه اختراق، من يوقّع الإشعار. الخطة التي تعتمد على شخص واحد تنهار يوم يكون ذلك الشخص في إجازة.
تحتاج إلى عتبة محددة: ما الذي يُعدّ اختراقًا يجب أن يُكتب مسبقًا، وإلا فإن ذلك الجدل يحدث داخل الساعات الاثنتين والسبعين.
تحتاج إلى قاعدة للحفاظ على الأدلة. الدافع الأول غالبًا هو مسح الأنظمة المتأثرة، مما يجعل التحقيق السليم مستحيلًا. يجب أن تنص الخطة صراحة على أن السجلات تُحفظ دون مساس.
تحتاج إلى نماذج تواصل جاهزة، لكل من المجلس والأشخاص المتأثرين.
لا شيء ينتهي عند إرسال الإشعار
الإشعار ليس نهاية الالتزام. يقيّم المجلس ما إذا كانت التدابير التقنية والتنظيمية المتخذة كافية.
تكرار الاختراق في المؤسسة نفسها يُقرأ كدليل على أن تلك التدابير لم تكن كافية. لهذا يجب تسجيل الإجراء التصحيحي المتخذ بعد الاختراق وقياس أثره. جملة "التدابير اللازمة اتُّخذت" ليست، وحدها، دليلًا على شيء.
الشيء الوحيد الذي يستحق فعله اليوم
أعلى إجراء قيمة يمكنكم فعله قبل وقوع اختراق هو بناء الجرد مع تحديد الموقع المادي المرفق: أي قاعدة بيانات، أي جدول، أي حقل، أي نسخة احتياطية تحتفظ بأي بيانات.
إذا كان هذا الجدول موجودًا، تُستعاد فعليًا أول ثلاثين ساعة تقريبًا من الاثنتين والسبعين. وإن لم يكن موجودًا، فمهما كانت الخطة مكتوبة جيدًا، لن يكفي الوقت.

## ما الذي يتحقق منه المدقق أولًا في إشعار حماية البيانات

Source: https://kulular.com.tr/ar/writing/writing-a-privacy-notice

عندما أراجع إشعار حماية البيانات لمؤسسة ما، أول ما أفعله ليس قراءته. إنه أخذ فئات البيانات التي يسردها الإشعار ومقارنتها بمخطط قاعدة البيانات.
تلك المقارنة تُنتج تقريبًا النتيجة نفسها في كل مرة تقريبًا: توجد حقول لا يذكرها الإشعار. أحيانًا يحدث العكس أيضًا: فئات مدرجة في الإشعار لا يجمعها النظام فعليًا إطلاقًا. كلاهما يشير إلى المشكلة الأساسية نفسها: الإشعار اشتُق من نموذج، لا من تحقق سليم من الوقائع.
الالتزام ليس إنتاج وثيقة
المادة 10 من القانون رقم 6698 تشترط على المتحكم، عند جمع البيانات الشخصية، الإفصاح عن أمور معينة: هويته، وغرض المعالجة، والجهات التي ستُنقل إليها البيانات ولماذا، وطريقة الجمع والأساس القانوني، والحقوق المنصوص عليها في المادة 11.
الفعل الحاسم هنا هو "الإفصاح". الوثيقة وسيلة؛ الالتزام هو إعطاء معلومات دقيقة. إشعار يعطي معلومات غير دقيقة أسوأ من عدم وجود إشعار إطلاقًا، لأن المؤسسة تكون قد أصدرت بيانًا لا يطابق الواقع.
لهذا يجب أن تأتي صياغة الإشعار بعد الجرد، لا قبله. المؤسسة التي لديها جرد تكتب الإشعار في يوم واحد. تلك التي ليس لديها تكتبه من دون معرفة ما تكتب عنه فعليًا.
الأخطاء الخمسة الأكثر شيوعًا التي أراها
أرى الأخطاء نفسها منذ سنوات، ولا واحد منها ينبع من نقص في المعرفة القانونية.
دمج الإشعار والموافقة في مربع اختيار واحد. يحدد المستخدم "قرأت ووافقت" ويُعتبر أنه أُخطِر ووافق في آن واحد. الإشعار إفصاح، لا شيء يُقبل. دمج الاثنين يقوّض طابع الموافقة كإعلان إرادة منفصل.
عرض الإشعار بعد اكتمال العملية بالفعل. تُرسل الاستمارة، ثم يظهر رابط إلى الإشعار على صفحة شكر. عند تلك النقطة تكون البيانات قد جُمعت بالفعل.
إجبار إشعار واحد على مناسبة كل عملية. التوظيف، وتواصل العملاء، وعلاقات الموردين، وزيارات الموقع، كلها تُطوى في وثيقة واحدة. النتيجة إشعار عام لا يصف أيًا منها بدقة.
عدم ذكر الأساس القانوني، أو سرد جميعها دفعة واحدة. عبارة مثل "وفق الشروط المنصوص عليها في المادتين 5 و6" لا تذكر أي أساس قانوني إطلاقًا. أي أساس تعتمد عليه حالة معالجة معينة فعليًا هو ما ينبغي كتابته.
عدم ذكر مدة الاحتفاظ. التعميم يتوقع إدراج ذلك في المعلومات المُعطاة لصاحب البيانات، ومن دونها لا يملك صاحب البيانات وسيلة لمعرفة إلى متى ستُحفظ بياناته.
كيف ينبغي بناء الإشعار
الإشعار الجيد يُكتب عملية بعملية. لا يبدأ بـ"شركتنا تعالج بياناتكم الشخصية"، بل يبدأ بـ"عند ملء استمارة التواصل، تُعالَج البيانات التالية."
جدول من أربعة أعمدة لكل عملية يجعل هذا أسهل بكثير: فئة البيانات، غرض المعالجة، الأساس القانوني، مدة الاحتفاظ. مع وجود ذلك الجدول، يكتب الإشعار نفسه، ويستطيع القارئ إيجاد ما يبحث عنه فعليًا.
اللغة مهمة أيضًا. التعميم يتوقع نقل المعلومات بلغة واضحة ومفهومة وبسيطة. عمليًا نرى العكس: تطول الإشعارات، وتثقل الجمل، وتصبح النتيجة غير قابلة للقراءة. إشعار لا يقرأه أحد لا يفي بوظيفة الإفصاح. تبسيطه ليس خيارًا أسلوبيًا هنا، إنه ما يشترطه الالتزام.
إبقاء الإشعار محدَّثًا
إشعار حماية البيانات ليس وثيقة تُكتب مرة واحدة وتُنسى. عند إضافة حقل جديد، أو انضمام مورّد جديد، أو استحداث نقل جديد، يحتاج الإشعار إلى التحديث أيضًا.
الطريقة المستدامة الوحيدة لإدارة هذا هي ربط التحديث بعملية التطوير نفسها. تغيير يضيف حقل بيانات شخصية جديدًا إلى نموذج البيانات ينبغي أن يُطلق تحديثًا لكل من الجرد والإشعار معًا. من دون تلك الصلة، ينجرف الإشعار بعيدًا عن الواقع خلال السنة الأولى، ولا يلاحظ أحد ذلك.
بنينا تلك الصلة في موقعنا بهذه الطريقة: عندما أضفنا ميزة التحليل بمساعدة الذكاء الاصطناعي، دخل قسم منفصل يشرح النقل عبر الحدود إلى الإشعار في الوقت نفسه. الميزة لم تُطلَق من دونه. هذا هو الترتيب الذي ينبغي أن يحدث به الأمر.

## لماذا يسبق جرد البيانات كل وثيقة أخرى لامتثال قانون حماية البيانات

Source: https://kulular.com.tr/ar/writing/kvkk-compliance

زوروا مؤسسة للمساعدة في أعمال امتثال قانون حماية البيانات، وهذا عادةً ما تجدونه في الملف بالفعل: إشعار خصوصية، استمارة موافقة، سياسة احتفاظ وإتلاف. الثلاثة مُصاغة وموقّعة ومؤرشفة.
بعدها يُطرح سؤال واحد. من أين جاءت فئات البيانات المدرجة في هذه الوثائق؟
الجواب عادةً: نموذج وُجد على الإنترنت، مُلئ فيه اسم الشركة، أُضيفت بضع فقرات. بعبارة أخرى، البيان لم يُشتق من التحقق من الوقائع، بل اشتُق من نموذج. هذا هو الخطأ الأكثر شيوعًا، والأكثر كلفة، في ترتيب أعمال الامتثال الذي أراه.
لماذا يهم الترتيب إلى هذا الحد
إشعار الخصوصية بيان. المادة 10 من القانون رقم 6698 تشترط على المتحكم الإفصاح عن فئات البيانات المُعالَجة، والأغراض، والجهات التي تُنقل إليها البيانات، والأساس القانوني. إذا كنتم تُصدرون بيانًا، يجب أن يكون دقيقًا.
إشعار مكتوب من دون جرد لا يمكن أن يكون دقيقًا. في أفضل الأحوال، يكون ناقصًا. عندما يكشف تدقيق نشاط معالجة لا يغطيه الإشعار، ليست تلك ثغرة تقنية فحسب، إنها إخلال بالوفاء بالتزام الإخطار على الوجه الصحيح.
العكس صحيح أيضًا. المؤسسة التي لديها جرد بالفعل تكتب إشعار الخصوصية في يوم واحد، لأن كل ما يحتاج للكتابة محدد أصلًا.
ما الذي يحتاج الجرد فعليًا إلى التقاطه
جداول الجرد عادةً تُبنى بثلاثة أعمدة: فئة البيانات، الغرض، مدة الاحتفاظ. هذه الثلاثة غير كافية.
العمود المفقود هو: أين تقيم هذه البيانات ماديًا؟ أي قاعدة بيانات، أي جدول، أي حقل؟ هل هي في النسخ الاحتياطية أيضًا؟ هل توجد نسخة منها في نظام مزوّد خارجي؟
من دون طرح هذا السؤال، يعكس الجرد اعتقاد المؤسسة عن نفسها، لا الواقع الفعلي. أول سؤال يُطرح بعد اختراق بيانات سيكون "ما البيانات الشخصية التي كانت على ذلك الخادم"، وجرد لا يُسجَّل فيه موقع مادي عديم الفائدة في تلك اللحظة.
اختيار الأساس القانوني قرار بنيوي
المادة 5 من القانون رقم 6698 تسرد الأسس التي تُسمح بموجبها المعالجة. عمليًا، غالبًا ما تُعامَل هذه المادة كإجراء شكلي، لكن الأساس القانوني المختار يشكّل مباشرة كيفية بناء النظام.
حيث تعتمد المعالجة على الموافقة الصريحة، يمكن سحب تلك الموافقة في أي وقت، ويجب أن تتوقف المعالجة فور سحبها. هذا يجعل ثلاثة أمور ضرورية في النظام: سجل بأي إصدار من الإشعار أُعطيت الموافقة مقابله، وواجهة تتيح للمستخدم سحبها، وضابط يوقف فعليًا المعالجة ذات الصلة بمجرد سحب الموافقة. من دون الثلاثة معًا، يترك الاعتماد على الموافقة المؤسسة في موقف يصعب الدفاع عنه.
المعالجة الضرورية لتنفيذ عقد لا تحتاج إلى أي من تلك الآلية. البيانة نفسها، مُعالَجة على أساس قانوني مختلف، تحمل عبئًا تقنيًا مختلفًا تمامًا. لهذا لا ينبغي أبدًا أن يُتخذ اختيار الأساس القانوني من قِبل محامٍ وحده، بمعزل عن البنية.
مدد الاحتفاظ والمكوّن الذي يفرضها
تحديد مدة احتفاظ هو الجزء السهل من برنامج الامتثال. ضمان تطبيقها فعليًا هو الجزء الصعب.
التصميم العامل يبدو هكذا: كل سجل يحمل تاريخ انتهاء احتفاظه الخاص، حقل retention_expires مثلًا. تعمل مهمة وفق جدول لإيجاد السجلات التي تجاوزت ذلك التاريخ. تحذف المهمة السجل أو تتلفه أو تخفي هويته، وتكتب فعلها الخاص في جدول سجل منفصل. ما يُعرض عند التدقيق ليس وثيقة السياسة، إنه ذلك السجل.
المؤسسات التي تفتقر إلى هذا الهيكل تفعل عادةً العكس: تكتب المدة في السياسة، وتؤجل التنفيذ إلى تاريخ مستقبلي، وذلك التاريخ لا يأتي أبدًا. بعد عامين، توجد بيانات لم تُمحَ إلى جانب وثيقة تقول إنها كان يجب أن تُمحى. وجود كلا الأمرين معًا أسوأ من عدم وجود سياسة إطلاقًا.
سجل VERBİS ونطاقه
الالتزام بالتسجيل في سجل المتحكمين بالبيانات (VERBİS) يعتمد على معايير يضعها المجلس: عدد الموظفين السنوي، حجم الميزانية العمومية، وطبيعة البيانات المُعالَجة.
تحذير يستحق الذكر هنا. نطاق الإعفاء تغيّر مع الوقت من خلال قرارات المجلس ويمكن أن يتغيّر مجددًا. مؤسسة معفاة اليوم يمكن أن تصبح خاضعة للالتزام بمجرد نمو عدد موظفيها. هذه ليست مسألة تُحسم مرة واحدة وتُنسى، إنها تحتاج إلى التحقق سنويًا، مقابل العتبات الحالية المنشورة من الهيئة.
خطة الاختراق تُكتب مسبقًا
الفقرة الخامسة من المادة 12 من القانون رقم 6698 تشترط إبلاغ المجلس بالاختراق في أقرب وقت ممكن؛ وقد حددت قرارات المجلس تلك المدة بسبعين ساعتين.
تلك الساعات الاثنتان والسبعون هي إجمالي الوقت المتاح، بمجرد ملاحظة حادثة، لتحديد نطاقها، وتحديد الأشخاص المتأثرين، وإعداد الإشعار. حتى الخطوة الأولى من تلك الخطوات تستغرق أيامًا في معظم المؤسسات، لأنه لا يوجد سجل مكتوب بأي بيانات موجودة أين.
لذا يبدأ الاستعداد للاختراق قبل وقوعه بوقت طويل، ويعود إلى المكان نفسه: الجرد.
ماذا يحدث بمجرد أن يكون الامتثال "منجزًا"
إنه لا ينتهي. ميزة جديدة تخلق حقل بيانات جديدًا. مورّد جديد يخلق نقلًا جديدًا. قرارات المجلس تضيّق الإطار.
لهذا يعمل الامتثال بشكل أفضل حين يُدمج في عملية تطوير المنتج، بدلًا من تشغيله كمشروع لمرة واحدة. إذا أصبح تحديث الجرد عند إضافة حقل جديد جزءًا من مراجعة الكود، تستمر العملية بذاتها. وإلا، يبدأ العمل من جديد كل عام، ويتكرر خطأ الترتيب نفسه في كل مرة.

## التقنية القانونية: لماذا لا تحل أدوات قوالب العقود المشكلة الحقيقية

Source: https://kulular.com.tr/ar/writing/legal-technology

انظروا كيف تُسوَّق معظم منتجات التقنية القانونية، وستجدون الشيء نفسه: صياغة عقد، اقتراح بند، تنسيق وثيقة. هذه مفيدة. لكنها ليست المشكلة الحقيقية للمجال، والشيء الذي تبدو هذه الأدوات تحله هو في الواقع الجزء الأسهل منها.
المشكلة الحقيقية تقع في مكان آخر. مؤسسة خاضعة لالتزام قانوني. شخص ما يفسّر ما يعنيه ذلك الالتزام. يُكتب التفسير في وثيقة. تذهب الوثيقة إلى ملف، وتستمر عمليات المؤسسة اليومية غافلة عن وجودها. تلك الفجوة بين الوثيقة والنظام العامل هي الخطأ الأكثر كلفة الذي أراه عمليًا، ولا تسدّها أي أداة قوالب عقود.
التفسير عمل بشري؛ التطبيق عمل النظام
تحويل قاعدة إلى برمجية ليس مثل كتابة القاعدة في كود. هناك خطوة بينهما لا يمكن أتمتتها.
المادة 7 من القانون رقم 6698 تنص على وجوب حذف البيانات الشخصية أو إتلافها أو إخفاء هويتها بمجرد زوال الأسباب التي تتطلب معالجتها. هذا الحكم واضح. لكن ماذا يعني "زوال الأسباب" بالضبط، لبيانات فواتير مؤسسة ما؟ نهاية علاقة العميل؟ انتهاء مدة الاحتفاظ بموجب قانون الضرائب؟ أيهما يأتي لاحقًا؟ محامٍ يجيب عن هذا السؤال. الجواب تفسير، وما لم يُسجَّل، لن يتذكر أحد بعد ستة أشهر لماذا اختيرت تلك المدة بالذات.
هنا يبدأ عمل البرمجية: ضمان أن التفسير، بمجرد إعطائه، يُطبَّق بالطريقة نفسها في كل مرة، وأن هذا يمكن إظهاره. نظام يفعل ذلك هو تقنية قانونية. نظام ينتج قوالب فقط هو معالج نصوص.
ماذا يحدث حين تنفصل الوثيقة عن النظام
خذوا مثالًا ملموسًا. سياسة احتفاظ مؤسسة ما تقول إن سجلات تواصل العملاء تُحفظ لمدة عامين. يصل تدقيق، وتُعرض تلك السياسة.
يطرح المدقق سؤالًا واحدًا. أي مكوّن يفرض هذه المدة؟
عادةً لا يوجد جواب. قاعدة البيانات فيها حقل created_at، لكن لا يوجد expires_at. لا توجد مهمة تحذف سجلًا منتهي الصلاحية. حتى حيث يحدث الحذف، لا يُنتج سجلًا يثبت حدوثه. في النهاية، لا تستطيع المؤسسة إثبات أنها فعلت ما تقوله سياستها الخاصة. وثيقة السياسة ليست دليلًا، هي في أفضل الأحوال بيان نية.
الحل ليس سياسة مكتوبة بشكل أفضل. إنه إضافة حقل إلى نموذج البيانات يحمل مدة الاحتفاظ، وكتابة مكوّن يفرضها، وضمان أن ذلك المكوّن يُنتج سجلًا عند تشغيله. بمجرد وجود الثلاثة معًا، تتوقف السياسة عن كونها ادعاءً وتصبح وصفًا لما يفعله النظام فعليًا.
الحلقات الخمس في السلسلة
تحويل نص قانوني إلى ضابط عامل في نظام يحدث عبر خمس خطوات، والترتيب مهم، تخطّي أي واحدة منها يجعل النتيجة غير موثوقة.
أولًا، يُحدَّد الحكم: القاعدة المنطبقة وأي استثناء. ثم يأتي التفسير، تحديد ما تعنيه القاعدة لعملية تجارية ملموسة. هذه الخطوة تخص إنسانًا ويجب تسجيلها. ثالثًا، يُربط التفسير بالبنية: أي حقل يحمل أي قاعدة. رابعًا، يُكتب المكوّن الذي يفرض القاعدة وقت التشغيل. خامسًا، يُسجَّل عمل ذلك المكوّن.
ضابط يُبنى من دون تفسير يفرض القاعدة الخطأ. ضابط لا يُنتج دليلًا عديم الفائدة عند التدقيق. الخطأ الذي أراه أكثر من غيره هو القفز مباشرة من الخطوة الثالثة إلى الخطوة الخامسة: تحتفظ المؤسسة بسجل، وتكتب فيه شيئًا، لكن ليس واضحًا على أي قاعدة يشهد ذلك السجل فعليًا.
احتكار المحامين
على أي شخص يبني منتجًا في هذا المجال معرفة حد واحد. المادة 35 من القانون رقم 1136 بشأن المحاماة تحصر ممارسة العمل القانوني وإبداء الآراء القانونية بالمحامين.
عمليًا، هذا يحدد ما يمكن لمنتجكم قوله وما لا يمكنه. "عقدكم يفتقر إلى هذا البند" معلومة. "لا توقّعوا هذا العقد، سيعمل ضدكم" رأي. الخط رفيع ويجب حمايته عمدًا في تصميم المنتج. الطريقة الأكثر موثوقية لحمايته هي ألا يتخذ النظام القرار بنفسه أبدًا، وأن يبقى قرار بشري مرئيًا خلف كل مخرج.
ذلك الحد يبدو قيدًا، لكنه في الواقع انضباط تصميم جيد. نظام لا يتحمل القرار لا يتحمل المسؤولية حين يخطئ في شيء، وهذا يمنع المستخدمين من الثقة العمياء بالنظام.
ما الذي غيّره الذكاء الاصطناعي، وما لم يغيّره
معالجة اللغة الطبيعية تقدّم مكسبًا حقيقيًا في الإنتاجية لمراجعة الوثائق. إيجاد نوع بند معين عبر مئات العقود كان يستغرق أسابيع. الآن يستغرق ساعات.
ما لم يتغيّر هو المسؤولية. إذا لم يكن مخرج نموذج ما قابلًا للتتبع إلى أي وثيقة وأي فقرة جاء منها، فذلك المخرج تخمين، لا استنتاج. وبالمثل، إذا لم يميّز النظام بشكل مرئي بين نتيجة واثق منها وأخرى غير واثق منها، يثق المستخدمون بكليهما على قدم المساواة وتمرّ الأخطاء من دون ملاحظة.
من دون هذين الشرطين، أي مكسب في الكفاءة تحقق يُدفع ثمنه لاحقًا كمخاطرة، والأسوأ أن أحدًا لا يعلم متى ستتحقق تلك المخاطرة فعليًا.
من أين تبدأ
لبدء برنامج تقنية قانونية داخل مؤسسة، اختاروا التزامًا واحدًا. محاولة معالجة كل شيء دفعة واحدة تبدو جذابة لكنها لا تنتهي أبدًا عمليًا.
للالتزام المختار، ابنوا الحلقات الخمس كلها: اكتبوا الحكم، سجّلوا التفسير، اربطوه بنموذج البيانات، ابنوا الضابط، أنتجوا الدليل. ينتهي هذا العمل خلال نحو ستة أسابيع، وما تنتهون به ليس تقريرًا، إنه ضابط عامل وسجل يمكنكم عرضه عند التدقيق.
الالتزام الثاني يسير أسرع بكثير. الجزء الصعب لم يكن القاعدة أبدًا. كان بناء السلسلة لأول مرة.

## في الفضاء، أنتم تتصرفون نيابة عن الدولة، لا شركتكم فقط

Source: https://kulular.com.tr/ar/writing/space-law

هناك قاعدة واحدة في قانون الفضاء تعمل بشكل مختلف عن كل مجال آخر، ومعظم المؤسسين يتعلمونها متأخرين.
المادة 6 من معاهدة الفضاء الخارجي لعام 1967 تنص على أن الدول مسؤولة دوليًا عن الأنشطة الفضائية الوطنية. هذا لا يتغيّر إذا نفذت النشاط شركة خاصة. تقول المادة أيضًا إن هذه الأنشطة تتطلب ترخيصًا من الدولة المعنية وإشرافًا مستمرًا منها.
مثال يجعل هذا أوضح. شركة برمجيات ترتكب خطأً تكون مسؤولة أمام عميلها. شركة فضاء ترتكب خطأً تجعل الدولة مسؤولة أمام دولة أخرى. الفرق ليس في الحجم، إنه فرق في النوع.
كيف تُبنى سلسلة المسؤولية
اتفاقية المسؤولية لعام 1972 تجسّد ذلك. الدولة المُطلِقة مسؤولة مسؤولية مطلقة عن الضرر الذي يسببه جسمها الفضائي على سطح الأرض أو لطائرة أثناء الطيران، من دون الحاجة لإثبات خطأ.
لهذا نتيجة تجارية مباشرة. ستريد الدولة نقل هذه المسؤولية المحتملة إلى المشغّل الخاص. لهذا تحتوي وثائق الترخيص عادةً على بنود رجوع، وتأمين إلزامي، ومتطلبات ضمان. إذا لم تعرفوا حجم هذه البنود قبل الدخول في تفاوض العقد، فلن تعرفوا التكلفة الفعلية للمشروع أيضًا.
التسجيل ينبع من المنطق نفسه. اتفاقية التسجيل لعام 1975 تشترط تسجيل الأجسام المُطلَقة إلى الفضاء. التسجيل يحدد تحت ولاية ورقابة أي دولة يقع الجسم، وهذا هو المكان الذي تبدأ منه الإجابة عن "أي قانون ينطبق".
خريطة الترخيص في تركيا
أُنشئت الوكالة التركية للفضاء بمرسوم رئاسي عام 2018 وهي مسؤولة عن إعداد البرنامج الفضائي الوطني وتنسيق الأنشطة.
لكن النشاط الفضائي ليس محصورًا بجهة واحدة. استخدام الترددات والمواقع المدارية نظام منفصل، تحكمه قواعد الاتحاد الدولي للاتصالات؛ محليًا، هيئة تقنية المعلومات والاتصالات هي الجهة المختصة. حيث تتدخل ضوابط التصدير، تدخل جهات أخرى في الصورة.
قبل بدء مشروع، يجب رسم تلك الخريطة: أي ترخيص، من أي جهة، بأي ترتيب، وكم يستغرق. هذا الجدول الزمني يسير بشكل مستقل عن جدول التطوير التقني، وعادةً ما يكون أطول. ما يؤخر مشروعًا غالبًا ليس البرمجية، إنه الترخيص.
البيانات نفسها مسألة منفصلة
المشكلة العملية الأكثر شيوعًا التي أراها في مشاريع الفضاء ليست تقنية. إنها تتعلق بالبيانات.
الحقوق على بيانات المهمة يجب حسمها في اتفاقيات الإطلاق والتشغيل. فجوة تُترك في العقد يصعب إصلاحها لاحقًا جدًا، لأنه بحلول ذلك الوقت يكون الطرف الآخر قد حصل بالفعل على وصول إلى تلك البيانات، وتقييد ذلك بأثر رجعي لا يعمل عمليًا.
بيانات رصد الأرض تثير سؤالًا منفصلًا. مع تحسّن الدقة، يزداد احتمال أن تُصنَّف البيانات كبيانات شخصية. صور قادرة على تمييز لوحة مركبة لا تخضع للنظام نفسه الذي تخضع له صور بمقياس مدينة. عند تصميم نظام، يجب تحديد عتبة الدقة التي يبدأ عندها نظام معالجة مختلف بالانطباق، وبناؤها كنقطة ضبط في خط أنابيب البيانات.
المسألة الثالثة هي النزاهة. يجب أن يكون بالإمكان إثبات مصدر بيانات القياس عن بُعد وطابعها الزمني وحالتها غير المُعدَّلة. هذا هو الشيء الوحيد الذي سيحمل وزنًا إثباتيًا في مراجعة ما بعد الحادثة. إذا وجد احتمال أن السجل أُنتج بعد وقوع الحدث، فالسجل نفسه عديم القيمة كدفاع.
مسألة استخراج الموارد
المادة 2 من المعاهدة تحظر التملك الوطني. ما إذا كان استخراج الموارد من الأجرام السماوية يقف أمام ذلك الحظر أمر غير محسوم.
بعض الدول سنّت تشريعات محلية تعترف بملكية الموارد المستخرجة. مدى توافق تلك القوانين مع المعاهدة محل خلاف، ولم تتشكل بعد ممارسة دولية مستقرة. الشيء الصادق الذي يُقال لمشروع يعمل في هذا المجال هو هذا: الأرضية القانونية هنا لم تستقر، وذلك الغموض ينتمي إلى حالة الاستثمار كبند مخاطرة حقيقي. أي رأي يُقدَّم على أنه محسوم يعطي، في الوضع الراهن، معلومات ناقصة.
ما ينبغي إحضاره إلى الطاولة
أينما رأيت الفريق التقني والفريق القانوني يعملان بشكل منفصل في مشروع فضائي، أرى المشكلة نفسها. القرارات المتخذة أثناء كتابة برمجية القطاع الأرضي تؤثر مباشرة على نظام المسؤولية، وعادةً ما تُلاحَظ تلك الصلة فقط بعد توقيع العقد.
ثلاثة أمور يجب حسمها قبل التفاوض الأول: من أي جهة يأتي الترخيص وبأي شروط؛ كيف تُقسَّم المسؤولية وعبء التأمين بين الطرفين؛ ومن يملك بيانات المهمة ومن يستطيع الوصول إليها. التخطيط التقني الذي يُنجَز قبل حسم هذه الثلاثة عادةً ما يحتاج إلى إعادة إنجازه.

## نص التسويق لديكم هو من يحدد ما إذا كانت برمجيتكم جهازًا طبيًا

Source: https://kulular.com.tr/ar/writing/health-law

تخيّلوا تطبيقين. كلاهما يأخذ الأعراض التي يُدخلها المستخدم، ويشغّل خوارزمية، ويُعيد قائمة. الكود متطابق تقريبًا. أحدهما يقع ضمن تنظيم الأجهزة الطبية. الآخر لا يقع.
ما يصنع الفرق هو الوصف في صفحة متجر التطبيقات. الأول يقول: "يقدّم معلومات عن حالات محتملة استنادًا إلى أعراضكم." الثاني يقول: "يُقيّم أعراضكم ويُظهر تشخيصًا محتملًا." تلك الجملة الثانية تقدّم المنتج لغرض تشخيصي، ومعه تأتي التزامات تصنيف المخاطر، وتقييم المطابقة، والملف الفني، والتقييم السريري، والمراقبة بعد طرح المنتج في السوق.
هذا هو الخطأ الأكثر كلفة، والأسهل تجنبًا، الذي أراه في مشاريع تقنية الصحة. التسويق يكتب وصف المنتج، ولا أحد يفكّر في نتيجته القانونية، وينتهي المنتج داخل نظام امتثال لم يقصد الدخول فيه أبدًا.
بيان الغرض المقصود وثيقة قانونية
القاعدة العملية المترتبة على ذلك هي هذه: يجب كتابة وصف المنتج بالعناية نفسها التي تُكتب بها سياسة الخصوصية، ومراجعته قانونيًا قبل نشره.
المراجعة لا يمكن أن تتوقف عند صفحة متجر التطبيقات. عنوان في الموقع، سطر في فيديو ترويجي، ادعاء في عرض مبيعات، بيان في وثيقة دعم، كلها يمكن أن تُنتج الأثر نفسه. قول "يقدّم تشخيصًا" في مكان لا يُسحب بقول "لأغراض إعلامية فقط" في مكان آخر.
القرار يجب اتخاذه مسبقًا. إذا كان المنتج سيكون جهازًا طبيًا، تُبنى العملية التي يشترطها ذلك النظام منذ البداية وتُدرج تكلفتها كبند في الخطة. وإن لم يكن كذلك، يصبح إبقاء كل نص ترويجي ضمن ذلك الحد قاعدة من قواعد تطوير المنتج.
بنية الوصول إلى بيانات الصحة
المادة 6 من القانون رقم 6698 تصنّف بيانات الصحة كفئة خاصة من البيانات الشخصية وتُخضعها لشروط أضيق. النظير التقني لذلك التصنيف مفقود في معظم المشاريع.
النمط الذي أراه أكثر من غيره: التطبيق يعمل، والبيانات تُخزَّن، لكن الجميع داخل المؤسسة يستطيع رؤية كل شيء. المطوّرون يستطيعون استعلام قاعدة بيانات الإنتاج. موظفو الدعم يستطيعون فتح ملف المريض. المدير يستطيع رؤية بيانات خام في تقرير. هذا يعني أن الوصول لم يُقيَّد فعليًا، ويصعب الدفاع عنه في تدقيق.
الإعداد الصحيح يبدأ بالوصول القائم على الأدوار، لكنه لا يتوقف هناك. كل وصول يجب تسجيله، ويجب أن يُظهر السجل من وصل ولأي غرض، ويجب أن يكون الوصول غير المعتاد قابلًا للكشف. إذا فتح شخص ما ملف مريض في الثانية صباحًا، يجب أن يكون ذلك مرئيًا في النظام.
بيئة الاختبار مسألة منفصلة. الاختبار ببيانات مرضى حقيقية هو العادة الأكثر شيوعًا، والأكثر خطورة، في تقنية الصحة. العمل ببيانات مُقنَّعة أو اصطناعية يزيل معظم تلك المخاطرة وليس صعبًا تقنيًا لإعداده.
دعم القرار السريري والمسؤولية
أنظمة دعم القرار المدعومة بالذكاء الاصطناعي تثير سؤال أين تقع المسؤولية. عمليًا، التصميم الآمن هو أن يُنتج النظام توصية ويترك القرار النهائي للمهني الصحي المؤهل.
لكي لا يبقى ذلك التصميم نظريًا، يجب الاحتفاظ بثلاثة عناصر معًا: التوصية التي أنتجها النظام، والمدخلات التي اعتمد عليها، والقرار النهائي الذي اتخذه المهني الصحي. إذا حُفظت منفصلة، لا يمكن مطابقتها لاحقًا؛ وإن لم تُحفظ إطلاقًا، لا يمكن إثبات المسؤولية إطلاقًا.
مؤشر آخر يستحق الإضافة: تتبّع عدد المرات التي يرفض فيها المهني الصحي توصية النظام. إذا اقترب هذا المعدل من الصفر، أصبحت الرقابة البشرية اسمية، والنظام هو من يقرر فعليًا. هذه النتيجة يمكن أن تكون بالغة الأهمية في نزاع لاحق حول المسؤولية.
الرعاية الصحية عن بُعد
الخدمات الصحية عن بُعد في تركيا تعمل ضمن لوائح وزارة الصحة. أي الخدمات يمكن تقديمها عن بُعد، والتزامات حفظ السجلات، وحدود الخدمة، محددة في التشريع الثانوي، ولأن تلك القواعد يمكن أن تتغير، يجب مراجعة المنتج مقابل النص الحالي عند التصميم.
المبدأ الذي لا يتغير هو هذا: الحالات التي تتطلب فحصًا حضوريًا لا يمكن التعامل معها عن بُعد. منتج الصحة عن بُعد يحتاج إلى القدرة على التعرّف على طلب يتجاوز ذلك الحد وإعادة توجيهه. نظام قادر على القول "يُرجى مراجعة طبيب حضوريًا لهذا" ليس رفاهية في سهولة الاستخدام، إنه شرط قانوني.
البدء بمشروع
في الاجتماع الأول لمشروع تقنية صحية، السؤال الذي يجب الإجابة عنه ليس ماذا سيفعل المنتج، بل ماذا سيُعلن عن نفسه. كل سطر كود يُكتب قبل حسم تلك الإجابة قد ينتهي مكتوبًا للنظام الخطأ.
السؤال الثاني يخص نموذج البيانات: ما البيانات الضرورية فعلًا، ومن يستطيع رؤيتها، وأين يُسجَّل الوصول، وماذا يحدث بمجرد انتهاء الغرض. إجابات هذه الأسئلة الأربعة تشكّل مباشرة كيفية تصميم الجداول، وتغيير ذلك التصميم لاحقًا، لأنه يعني ترحيل بيانات مرضى موجودة، يخلق مشكلة تقنية وقانونية معًا.

## هل تجتاز برمجية المراقبة الإلزامية للامتحانات اختبار التناسب؟

Source: https://kulular.com.tr/ar/writing/education-law

طالب يرفض تشغيل كاميرته أثناء امتحان عن بُعد، قائلًا إنه لا يريد تسجيل منزله. المؤسسة تقول إن نزاهة الامتحان يجب حمايتها. مصلحتان مشروعتان تتواجهان هنا، والسؤال الحقيقي ليس أيهما يفوز، بل هل الطريقة التي اختارتها المؤسسة ضرورية فعلًا.
يتكرر هذا السؤال باستمرار في مشاريع تقنية التعليم، وعادةً ما يُصاغ بشكل خاطئ. يتحول النقاش إلى "الكاميرا مشغّلة أم مطفأة"، بينما السؤال القانوني أضيق: هل يمكن تحقيق الهدف نفسه بمعالجة بيانات أقل؟
ما الذي يسأله التناسب فعليًا
المادة 4 من القانون رقم 6698 تشترط أن تكون البيانات الشخصية ملائمة ومحدودة ومتناسبة مع الغرض الذي تُعالَج من أجله. هذا المبدأ ليس تطلعًا مجردًا، إنه مرشِّح ملموس.
نزاهة الامتحان هدف مشروع، لا جدال في ذلك. لكن الهدف المشروع لا يُشرعن جمع كل بيانة يمكن جمعها عن المرشح. التسجيل المرئي المستمر، التقاط الشاشة، تتبّع ضغطات المفاتيح وحركة الفأرة، تثبيت عميل بصلاحيات واسعة على الجهاز، كل هذه يجب تقييمها بمفردها، مقابل سؤال واحد: هل هذا ضروري فعلًا لتأمين نزاهة الامتحان أم لا؟
غالبًا لا يكون كذلك. عشوائية بنك الأسئلة، حدود الوقت، خلط ترتيب الأسئلة، الترجيح نحو الأسئلة المفتوحة، وكشف الشذوذ الإحصائي بعد الامتحان، توفر مستوى جادًا من النزاهة من دون تسجيل أي شيء إطلاقًا. اللجوء المباشر إلى تسجيل الكاميرا من دون تجربة هذه الأدوات أولًا موقف يصعب الدفاع عنه من زاوية التناسب.
لماذا لا تنفع الموافقة هنا
أول ما تلجأ إليه المؤسسات هو طلب موافقة الطالب. يظهر مربع اختيار قبل بدء الامتحان، ولا يستطيع الطالب دخول الامتحان من دون تحديده.
مشكلة هذا التصميم هي: الموافقة الصحيحة يجب أن تُعطى بحرية. من الصعب القول إن طالبًا لا يستطيع دخول الامتحان من دون تحديد المربع يوافق بحرية. علاوة على ذلك، الطرف الآخر يضع الدرجات ويسجّل الحضور ويؤثر في قرارات التخرج. هذا الخلل في توازن القوى يقوّض الموافقة من الأساس.
النتيجة العملية هي هذه: الاعتماد على الموافقة لبيانات الطلاب يمنح المؤسسة شعورًا بالأمان من دون أن يوفر فعلًا غطاءً قانونيًا. ما ينبغي للمؤسسة فعله بدلًا من ذلك هو تقييم ما إذا كانت المعالجة تستند إلى أساس قانوني آخر، وإن لم تكن كذلك، التخلي عن تلك المعالجة كليًا.
حيث يكون طفل معنيًا
بالنسبة لطلاب سن التعليم الإلزامي، الصورة أكثر حساسية. أهلية الموافقة، ودور الوالد، ومصلحة الطفل الفضلى، كلها يجب تقييمها بشكل منفصل هنا.
عند تصميم منصة تعليمية، يجب بناء مسارات مختلفة بحسب عمر المستخدم. تقديم الواجهة نفسها لطفل عمره عشر سنوات ولطالب دراسات عليا عمره خمس وعشرون سنة مشكلة ليس فقط من ناحية سهولة الاستخدام بل قانونيًا أيضًا. حقل يحمل الفئة العمرية في نموذج البيانات، مع قواعد معالجة مختلفة مرتبطة به، هو النظير التقني لذلك التمييز.
ما الذي يثبته سجل التعلّم فعليًا
الجانب الأقل نقاشًا في تقنية التعليم هو ما تصلح له السجلات التي تُنتجها لاحقًا.
عندما يستأنف طالب درجته، ماذا لدى المؤسسة؟ سجل "تم إكمال الامتحان" الذي يغلق التذكرة فحسب، أم سلسلة تُظهر أي سؤال حصل على أي إجابة، وبأي معيار صُحِّح، ومن صحّحه؟
مع الخيار الثاني، يُحلّ الاستئناف في عشر دقائق. من دونه، يتحول الاستئناف إلى دفاع يطلب من المؤسسة أن يُوثَق بسجلها الخاص، وهذا دفاع ضعيف. لهذا يجب بناء نظام التقييم بهذا الترتيب: تحديد مخرجات التعلّم أولًا، ربط معيار النجاح بتلك المخرجات، توليد الأسئلة وفق المعيار، الاحتفاظ بسجل للتقييم، وتحديد عملية الاستئناف وإجراء المراجعة مسبقًا.
ابنوا تلك السلسلة، وستحصل شهادة الإنجاز على أساس يمكن إثباته خلفها. من دونها، الشهادة مجرد بيان يستند إلى حسن نية المؤسسة.
ما أقترحه على المؤسسات
قبل شراء برمجية مراقبة، قيسوا كم من مشكلة النزاهة يمكن حلّه من خلال تصميم الامتحان وحده. معظم المؤسسات لا تجري هذا القياس إطلاقًا وتتجه مباشرة إلى الخيار الأكثر تطفلًا المتاح.
بمجرد إجراء ذلك القياس، إذا ظلت المراقبة ضرورية، اكتبوا تسويغًا منفصلًا لكل بيانة تُجمع. "النظام يجمع هذا" ليس تسويغًا. أي بيانة لا يمكن تسويغها ينبغي إزالتها من النظام. يجب أن تكون هذه أيضًا نقطة تفاوض مع المورّد، لأن معظم المنتجات الجاهزة تجمع أكثر مما تحتاجون وتُشحَن بهذه الإعدادات الافتراضية مفعّلة.

## قانون تقنية المعلومات التركي صعب لأنه ليس في تشريع واحد

Source: https://kulular.com.tr/ar/writing/it-law

لا يوجد جواب واحد لسؤال "ماذا يقول قانون تقنية المعلومات التركي عن هذا"، لأنه لا يوجد تشريع واحد يُسمى قانون تقنية المعلومات التركي. هذا أول ما يتعلمه أي عامل في هذا المجال، وهو الأصعب شرحًا لعميل.
في تركيا، يُنظَّم نشاط تقنية المعلومات عند تقاطع ستة تشريعات منفصلة على الأقل. لا واحد منها يستوعب الآخر. كل منها يعمل بمنطقه الخاص، ونظام عقوباته الخاص، وجهته الرقابية الخاصة. النتيجة: لا يمكنكم وضع قائمة التزامات بالنظر إلى نص واحد، والحدث نفسه يمكن أن يُنتج عواقب بموجب أكثر من نظام في الوقت نفسه.
اختراق بيانات واحد يمكن أن يظهر في ثلاثة أماكن منفصلة
مثال ملموس يوضح ذلك بأفضل شكل. لنفترض أن قاعدة بيانات عملاء شركة تجارة إلكترونية تعرّضت للوصول غير المصرّح به وسُرِّبت البيانات.
المسار الأول إداري. المادة 12 من القانون رقم 6698 تضع التزامات أمن البيانات، وفقرتها الخامسة تشترط إبلاغ المجلس بالاختراق. يقيّم المجلس ما إذا كانت التدابير التقنية والتنظيمية المتخذة كافية، وإذا وجدها قاصرة، يمكنه فرض غرامة إدارية.
المسار الثاني جزائي. فعل الشخص الذي حصل على الوصول قد يشكّل جريمة الدخول غير القانوني إلى نظام معلومات بموجب المادة 243 من القانون رقم 5237، وتسريب البيانات قد يشكّل بشكل منفصل جريمة توفير بيانات أو الحصول عليها بشكل غير قانوني بموجب المادة 136. هذا التحقيق يسير بشكل مستقل عن المسؤولية الإدارية للشركة.
المسار الثالث قانون خاص. الشخص الذي كُشفت بياناته يمكنه المطالبة بالتعويض عن الضرر الذي لحق به، والفقرة الأخيرة من المادة 11 من القانون رقم 6698 تحفظ ذلك الحق صراحة.
هذه المسارات الثلاثة ليست بدائل عن بعضها؛ إنها تسير بالتوازي. دفع غرامة المجلس لا ينهي التحقيق الجزائي، ونتيجة القضية الجزائية لا تحسم بذاتها مطالبة التعويض.
أي سؤال يجيب عنه كل تشريع فعليًا
الطريقة الأكثر عملية لفهم مدى تشتت هذا المجال هي: تحديد أي سؤال يجيب عنه كل تشريع فعليًا.
القانون رقم 6698 يجيب عن "هل يمكنكم معالجة هذه البيانات؟" شروط المعالجة، والتزام الإخطار، والتدابير الأمنية، وحقوق صاحب البيانات، كلها هنا.
القانون رقم 5651 يجيب عن "من المسؤول عن هذا المحتوى؟" التمييز بين مزوّد المحتوى، ومزوّد الاستضافة، ومزوّد الوصول، ومزوّد الاستخدام الجماعي، وإجراءات إزالة المحتوى وحجب الوصول، محددة هنا. نظام المسؤولية يتغيّر كليًا بحسب أي من هذه الأدوار الأربعة يقع الطرف تحته.
القانون رقم 5237 يجيب عن "هل هذا الفعل جريمة؟"
القانون رقم 6563 يجيب عن "هل يمكنكم إرسال هذه الرسالة التجارية، وما الذي يجب عليكم، كمزوّد خدمة، الإفصاح عنه؟"
القانون رقم 5070 يجيب عن "هل هذا التوقيع الإلكتروني يقوم مقام التوقيع بالحبر؟"
في مشروع حقيقي، تظهر كل هذه الأسئلة عادةً في آن واحد. قرار يُتخذ بالنظر إلى واحد منها فقط يخلق نقاط عمياء تجاه الأربعة الأخرى.
السلطة المشتتة تعني رقابة مشتتة
ما يزيد الأمر تعقيدًا هو أن تشريعات مختلفة موكولة إلى جهات مختلفة.
هيئة حماية البيانات الشخصية تشرف على نشاط معالجة البيانات. هيئة تقنية المعلومات والاتصالات لها اختصاص على الاتصالات الإلكترونية وتشارك في تنفيذ قرارات حجب الوصول. وزارة التجارة مسؤولة عن تنفيذ تشريع التجارة الإلكترونية.
النتيجة العملية: منتج واحد يمكن أن يكون مسؤولًا أمام أكثر من جهة تنظيمية في آن واحد، ولا واحدة منها مُلزَمة بقرار الأخرى. رأي إيجابي من جهة لا يمنع جهة أخرى من التوصل إلى استنتاج مختلف.
أين تحدث الأخطاء عمليًا
معظم الأخطاء التي أراها في هذا المجال تشترك في شيء واحد: التقييم القانوني يحدث بعد أن اتُّخذت القرارات التقنية بالفعل.
يُبنى نموذج البيانات، وتُنشأ الجداول، وتُكتب التكاملات. قُبيل الإطلاق، يطلب أحدهم من محامٍ "إلقاء نظرة." عند تلك النقطة، الخيارات محدودة، لأن أي ملاحظة تُثار الآن تعني تصحيحًا رجعيًا، والتصحيح الرجعي يخلق مشكلة منفصلة للبيانات المجمّعة أصلًا حتى تلك النقطة.
ومع ذلك، كل واحد من الأسئلة التالية كان يمكن الإجابة عنه أثناء بناء نموذج البيانات. أي فئات من البيانات الشخصية ستُعالَج؟ ما الأساس القانوني الذي تستند إليه كل فئة؟ ما مدة الاحتفاظ، وأي مكوّن يفرضها؟ أي جداول تُلمَس عند وصول طلب حذف؟ هل سيكون هناك نقل إلى الخارج؟
خمسة أسئلة. كلها قابلة للإجابة في اجتماع واحد. تكلفة عدم الإجابة عنها تنتهي بأن تكون أضعاف تكلفة ذلك الاجتماع بمرات عديدة.
الصعوبة الحقيقية للمجال
صعوبة قانون تقنية المعلومات التركي ليست في تعقيد القواعد. مقروءة كلٌّ على حدة، هي مفهومة.
الصعوبة هي معرفة اللحظة التي يُفعَّل فيها كل واحد منها. قرار مهندس، "لنسجّل هذا الحقل أيضًا، قد يكون مفيدًا"، يمكن أن يُطلق عواقب بموجب ثلاثة تشريعات منفصلة في آن واحد، والشخص الذي يتخذ ذلك القرار عادةً لا يعلم شيئًا عن ذلك. طريقة سدّ تلك الفجوة ليست ملفًا أثخن للامتثال. إنها وجود محامٍ على الطاولة عند اتخاذ القرار.