شراء الخدمات الرقمية للأطفال: معيار مؤسسي لتقييم المورد قبل التعاقد وبعده

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

ابدأ بالغرض: لماذا نشتري الخدمة أصلًا؟

اكتب مشكلة واحدة أو أكثر تريد حلها: إدارة تعلم، تواصل أسري، تدريب، تقييم، علاج عن بعد، نشاط مجتمعي. إذا كانت الوظيفة يمكن تحقيقها بخدمة أقل جمعًا للبيانات أو أقل اتصالًا بالغرباء، فذلك عامل مهم. لا تبدأ من اسم منتج مشهور ثم تبحث عن سبب لإدخاله. الغرض يحدد البيانات والخصائص التي يجب أن يسمح بها العقد، وما يصبح خارج النطاق.

ميزة جذابة ليست حاجة

AI assistant أو leaderboard أو location map قد يبدو مميزًا لكنه قد لا يخدم الهدف الأساسي. صنف الخصائص إلى ضرورية، مفيدة، وغير لازمة. اطلب من المورد إمكانية تعطيل غير اللازم للحسابات الصغيرة. كل feature إضافي يوسع سطح الخطر والصيانة والتدريب، لذلك يجب أن يثبت قيمته لا أن يدخل تلقائيًا ضمن الحزمة.

بوابة صفر: هل الخدمة مصممة لاستخدام الأطفال؟

افحص شروط العمر وKids/Education designation والسياسات. لا تستخدم حسابًا بالغًا جماعيًا للالتفاف على حد عمر واضح. إذا يقول المورد إن الخدمة ليست موجهة للأطفال لكنه يقترح استخدامها في مدرسة، اطلب تفسيرًا مكتوبًا وتكوينًا مناسبًا. age rating في متجر التطبيقات مفيد لكنه ليس شهادة أن الخدمة مناسبة لنشاطك؛ اختبر الداخل والخصائص الاجتماعية والبيانات.

خريطة البيانات قبل العقد

اطلب جدولًا يجيب: ما الحقول؟ ما المصدر؟ لماذا تُجمع؟ أين تُخزن؟ من يصل؟ ما مدة الاحتفاظ؟ ما الموردون الفرعيون؟ ماذا يحدث عند حذف الحساب؟ أضف البيانات المشتقة مثل embeddings وrisk scores وanalytics وlocation inference، لا المدخلات فقط. إذا لا يستطيع vendor الإجابة، فالمؤسسة لا تستطيع شرح المعالجة للأسرة أو تقييم الخطر.

تقليل البيانات: اختبر الحساب التجريبي

لا تعتمد على privacy policy وحدها. أنشئ tenant تجريبيًا بحساب طفل وهمي، وراقب ما يطلبه التسجيل والpermissions. هل يطلب رقم هاتف رغم أن البريد المؤسسي يكفي؟ هل الموقع precise؟ هل الصورة إلزامية؟ هل يستطيع admin تعطيل analytics أو discoverability؟ سجّل الفروقات بين ما وعد به العرض وما يحدث فعليًا.

من يستطيع التواصل مع الطفل؟

ارسم matrix: معلم، موظف، طالب، ولي، مستخدم خارجي، support agent. من يبدأ DM؟ هل توجد مجموعات وروابط دعوة؟ هل يستطيع موظف التواصل من حساب شخصي؟ هل تُحفظ المحادثات أو تختفي؟ اطلب controls لعزل external users، وسجلًا إداريًا مناسبًا من دون مراقبة شاملة. إذا كانت الخدمة لا تحتاج تواصلًا، عطله.

الإبلاغ والحظر والتصعيد

اختبر report من حساب الطفل على الهاتف وقارئ الشاشة. ما الفئات؟ من يستلم؟ كم SLA للحالات العالية؟ هل يمكن report موظف أو مشرف خارج سلطته؟ هل block يمنع إعادة الاتصال؟ اطلب للمؤسسة نقطة اتصال لحوادث safeguarding وليس support ticket عامًا فقط. العقد يجب أن يحدد الإشعار بالحوادث وكيف تُحفظ المعلومات اللازمة.

الإعدادات الافتراضية للأطفال

افحص profile visibility، search indexing، location، people discovery، DMs، downloads، recommender، ads، وAI. الأفضل أن يبدأ الحساب الصغير بإعداد أكثر حماية ويحتاج اختيارًا واضحًا للتوسيع. لا تقبل أن يكون كل شيء عامًا ثم تطلب من المدرسة تعديل عشرات الإعدادات يدويًا لكل طالب ما لم يوجد admin template موثوق.

العمر والتحقق

إذا تحتاج الخدمة age assurance، اسأل عن الطريقة والدقة والبيانات والappeal وshared devices. لا ترسل تاريخ الميلاد الكامل إذا يكفي age band. وإذا تأتي إشارة عمر من النظام أو المتجر، اسأل كيف يستخدمها vendor وما الذي يحدث عند الخطأ. لا تجعل الطفل يقدم هوية لمورد صغير بلا حاجة.

الذكاء الاصطناعي: ما الوظيفة وما البيانات؟

اسأل هل توجد generative AI، recommender، automated moderation، scoring، transcription، face/voice recognition أو AI companion. ما النموذج؟ هل البيانات ترسل لطرف ثالث؟ هل تُستخدم للتدريب؟ هل يمكن تعطيل الميزة؟ ما human review؟ لا تكتفِ بعبارة AI-powered. كل وظيفة لها مخاطر مختلفة وتحتاج disclosure وعقدًا مناسبًا.

لا تسمح بتغيير AI جوهري بصمت

ضع change-notification clause: إضافة companion أو voice cloning أو automated decision أو training use جوهري يحتاج إشعارًا ومراجعة قبل تفعيله لطلاب المؤسسة. تحديث نموذج داخلي لتحسين دقة نفس الوظيفة ليس دائمًا تغييرًا جوهريًا، لذلك عرّف الفئات في العقد بدل طلب موافقة على كل patch.

الإعلانات والتسويق

اسأل هل تعرض الخدمة إعلانات للأطفال أو تستخدم البيانات للإعلانات أو cross-product profiling. المؤسسة التعليمية غالبًا تحتاج بيئة بلا ads أو على الأقل بلا behavioral advertising. لا تسمح للمورد باستخدام نشاط الطالب لبناء audience تجاري خارج الغرض التعليمي. افحص SDKs لا واجهة التطبيق فقط.

الموقع والكاميرا والميكروفون

راجع permissions واحدة واحدة. الفيديو التعليمي قد يحتاج كاميرا عند جلسة، لا access دائمًا. النقل قد يحتاج موقعًا أثناء الرحلة، لا history سنة. transcription قد يحتاج صوتًا، لكن هل يحتفظ vendor بالتسجيل؟ اطلب while-in-use وapproximate حيث يكفي، وتوثيق retention للميديا.

الإتاحة ليست بندًا تجميليًا

اختبر keyboard، screen reader، zoom، contrast، captions، transcripts، language simplicity، switch access ومسارات report/block. اطلب VPAT أو evidence مناسبًا عندما يتوفر، لكن لا تعتمد على وثيقة وحدها. الطالب الذي لا يستطيع استخدام control السلامة لديه ثغرة حماية. اكتب متطلبات الإتاحة في acceptance criteria والعقد.

اللغة والعربية

إذا الخدمة تستخدم moderation أو AI، اسأل عن العربية واللهجات. واجهة مترجمة لا تعني أن safety model يفهم العربية. اختبر report labels وerror messages وmoderation على عينات قانونية. إذا الدعم العربي أضعف، اطلب controls أو human escalation ولا تدّعِ تكافؤًا غير مثبت.

الأمن والحسابات

راجع MFA للمديرين والموظفين، SSO، role-based access، session management، audit logs، backup، vulnerability management، incident response، وتشفير النقل والتخزين. لا تحتاج المؤسسة إلى اختراع معيار أمن خاص إذا توجد شهادات وتقييمات مناسبة، لكنها يجب أن تفهم نطاقها. شهادة على جزء من الشركة لا تعني أن كل منتج أطفال داخل النطاق.

صلاحيات الإدارة

حدد أدوار super admin، safeguarding lead، teacher، support، analyst. لا تجعل المعلم يرى بيانات كل المدرسة أو support agent يرى location بلا حاجة. اختبر offboarding: ماذا يحدث عند مغادرة موظف؟ يجب أن تُلغى access بسرعة وتبقى سجلات التدقيق. الحسابات المشتركة تضعف المساءلة ويجب تجنبها.

الموردون الفرعيون Sub-processors

اطلب قائمة محدثة، الوظيفة، location/data region، ونوع البيانات لكل subprocessor. ضع آلية إشعار عند إضافة طرف مهم. لا يكفي اسم شركة cloud؛ قد توجد analytics وAI وemail وsupport vendors. المؤسسة تحتاج حق تقييم تغيير جوهري، لا بالضرورة veto غير واقعي على كل مزود بنية.

الاحتفاظ والحذف

اطلب جداول retention للحساب والرسائل والوسائط والlogs والbackups والAI artifacts. اختبر delete على tenant تجريبي: ما الذي يختفي ومتى؟ ماذا يبقى لأسباب قانونية؟ عند انتهاء الطالب أو العقد، يجب أن توجد export ثم deletion process. لا تقبل «نحذف عند الطلب» بلا مدة ونطاق.

خطة الخروج جزء من قرار الدخول

قبل التوقيع اسأل كيف تستخرج المؤسسة بياناتها بصيغة قابلة للاستخدام، وكيف تحذفها، وماذا يحدث للروابط والحسابات والتكاملات. vendor lock-in قد يجبر مؤسسة على إبقاء خدمة غير آمنة لأنها لا تستطيع المغادرة. ضع exit test في التجربة قبل شراء عقد طويل.

الحوادث والإخطار

العقد يحدد ماذا يُعد incident، من يتواصل، خلال أي مدة، وما المعلومات الأولية. حادث child-safety ليس فقط data breach؛ قد يكون feature يسمح بغرباء أو bug يكشف location أو moderation outage. اطلب cooperation في التحقيق وحفظ logs وعدم التواصل المباشر مع الطفل إلا عبر المسار المتفق عليه عندما تكون المؤسسة هي المسؤولة.

التغييرات بعد التعاقد

SaaS يتغير. راقب release notes والسياسات وsubprocessors وpricing. ضع review trigger لميزة اجتماعية أو AI أو location أو تغيير retention. لا تنتظر التجديد السنوي إذا التغيير جوهري. وفي المقابل لا تجعل كل تحديث أمني يحتاج لجنة؛ صنف changes حسب risk.

الاختبار قبل Go-Live

1. أنشئ حساب طفل وولي وموظف واختبر رحلة التسجيل.
2. اختبر من يستطيع DM أو إضافة لمجموعة.
3. اختبر report/block والحالة التي يكون المشرف فيها هو المبلّغ عنه.
4. اختبر privacy/location/camera/mic defaults.
5. اختبر delete/export/offboarding.
6. اختبر accessibility لمسارات رئيسية وسلامة.
7. اختبر AI باللغة العربية إن كانت الميزة مستخدمة.
8. راجع network/subprocessor flows المتاحة.
9. نفذ tabletop لحادث safeguarding وdata breach.
10. وثق failures كشرط قبول لا كملاحظة مؤجلة بلا owner.

قرار Go / Conditional / No-Go

لا تحول التقييم إلى مجموع نقاط يخفي عيبًا قاتلًا. No-Go قد يكون: لا يمكن منع غرباء من الاتصال بالأطفال في use case حساس، لا توجد طريقة حذف، المورد يرفض توضيح استخدام البيانات، أو feature أساسي غير قابل للوصول. Conditional يعني gaps قابلة للإصلاح قبل أو بعد الإطلاق بمواعيد وcontrols بديلة. Go يعني أن المتطلبات الحالية اجتازت الاختبار، لا أن الخدمة أصبحت آمنة للأبد.

الاستثناءات

قد تحتاج المؤسسة خدمة لا تحقق كل معيار بسبب ضرورة علاجية أو تعليمية. وثق السبب، الخطر، البديل غير المتاح، compensating controls، المدة، ومن وافق. لا تجعل exception دائمًا. راجعه في موعد محدد. هذا أكثر أمانًا من الالتفاف على المعيار أو الادعاء أن gap غير مهم.

الـRFP: أسئلة لا وعود تسويقية

اطلب إجابات وأدلة: diagram للبيانات، screenshots للإعدادات، sample incident process، retention table، subprocessor list، accessibility evidence، model cards أو summaries، security scope، deletion SLA. سؤال «هل أنتم متوافقون مع الخصوصية؟» ينتج نعم. سؤال «ما البيانات التي تبقى في backup بعد حذف طالب وكم مدة؟» ينتج معلومة قابلة للتقييم.

التحقق من المراجع

تحدث مع مؤسسات مشابهة، لكن لا تعتبر testimonial دليلًا كافيًا. اسأل عن incidents، support، حذف البيانات، changes، moderation، والأداء بالعربية. vendor قد يرشح أفضل عملائه؛ ابحث أيضًا عن تقارير تنظيمية أو breaches عامة بعقل نقدي. لا تعاقب المورد إلى الأبد على حادث قديم إذا أصلحه، لكن افحص كيفية الاستجابة.

المراجعة بعد 30 و90 يومًا

بعد الإطلاق راقب tickets، report outcomes، access issues، data flows الفعلية، AI behavior، وusage. عند 30 يومًا أصلح friction المبكر، وعند 90 يومًا قارن الحاجة والقيمة بالمخاطر. قد تكتشف أن feature لا يستخدم ويمكن تعطيله. اجمع رأي الأطفال بطريقة آمنة ولا تجعل رضا المعلم المعيار الوحيد.

التجديد السنوي ليس تلقائيًا

قبل التجديد راجع ما تغير: vendor ownership، subprocessors، AI، ratings، incidents، security reports، accessibility، حذف، الأسعار والبدائل. افحص هل الغرض ما زال قائمًا. خدمة اجتازت قبل سنة قد لا تجتاز الآن، والعكس. استخدم النسخة السابقة للمقارنة لا تبدأ من الصفر.

مشاركة الأطفال في تقييم المنتج

اختبر هل يفهم الطفل privacy settings وreport وAI labels، وهل يستطيع الخروج أو الحذف، وما الذي يربكه. لا تطلب منه اختبار محتوى مؤذٍ أو كشف تجارب شخصية. استخدم prototypes وحسابات آمنة، وعوّض المشاركة المناسبـة، وأظهر ما تغير. ملاحظة الطفل قد تكشف gap لا يظهر في vendor questionnaire.

المؤسسات الصغيرة

إذا لا تملك فريق قانون وأمن، استخدم نسخة مصغرة: الغرض، البيانات، الاتصال، report, delete, AI, accessibility, incident, exit. ركز على high-risk red flags واطلب وثائق جاهزة. لا تجمع عشرات الشهادات التي لا تستطيع تفسيرها. قد يكون اختيار منتج أبسط مع بيانات أقل أفضل من منصة قوية تحتاج حوكمة لا تستطيع توفيرها.

لوحة المورد بعد التعاقد

احتفظ بسجل لكل vendor: owner داخل المؤسسة، الغرض، data classes، عدد الأطفال، آخر review، incidents، subprocessors، contract end، deletion test، accessibility status، AI features، open actions. لا تضع بيانات أطفال في سجل المشتريات. dashboard يساعد على معرفة أي عقد يحتاج مراجعة بدل انتظار حادث.

نموذج روافد المفاهيمي: بوابات المورد الثماني

تقترح روافد إطارًا غير متحقق: الغرض، البيانات، الاتصال، الخوارزمية، الوصولية، الحادث، العقد، والخروج. لا يكفي مجموع نقاط؛ فشل بوابة حرجة قد يوقف التعاقد. الإطار conceptual وغير validated ويمكن اختباره بمقارنة جودة قرارات المشتريات والحوادث قبل وبعد استخدامه.

من ورقة المتطلبات إلى حزمة إثبات قابلة للمراجعة

ما الذي يجب أن يقدمه المورد قبل قرار الشراء؟

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

بوابة تغيير النطاق بعد توقيع العقد

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

اختبر الخروج قبل أن تصبح الخدمة ضرورية

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

مراجعة أول 90 يومًا: هل المنتج يعمل كما وُعد؟

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

يجب أن يكون قرار No-Go خيارًا مؤسسيًا حقيقيًا لا خانة شكلية في التقييم. إذا لم يستطع المورد توضيح موقع بيانات الأطفال أو حذفها أو التحكم في التواصل المباشر أو الإخطار بتغيير جوهري، فهذه ليست فجوات يمكن دائمًا تعويضها بتدريب الموظفين. وكذلك إذا تعارض نموذج العمل مع غرض المؤسسة، مثل اعتماد وظيفة أساسية على تتبع أو تسويق لا يحتاجه الطفل، فالتعديل التعاقدي قد لا يكفي. في المقابل يمكن استخدام Conditional Go عندما تكون الفجوة قابلة للإغلاق قبل الإطلاق، مثل إعداد افتراضي يحتاج تغييرًا أو اختبار وصولية محدد أو بند إخطار ناقص. القرار المشروط يجب أن يحدد الشرط والمالك والموعد ودليل الإغلاق وما يحدث إذا لم يُنفذ. بهذه الصيغة لا تتحول لجنة الشراء إلى جهة تجمع ملاحظات ثم تعتمد المنتج على أي حال، بل إلى بوابة قرار يمكنها حماية الطفل قبل نشوء اعتماد تقني يصعب التراجع عنه.

أسئلة شائعة

المصادر والمنهجية

بُني المعيار على eSafety Safety by Design، وOECD Safety by Design للأطفال، وUNICEF Keeping Children Safe Online وأفضل مصالح الطفل وإرشادات AI and Children، وICO Children’s Code، ومعايير وإرشادات حكومية للتقنية في التعليم حيث تنطبق، وتعليق لجنة حقوق الطفل رقم 25. هذه المصادر لا تقدم RFP موحدًا عالميًا؛ لذلك حولتها روافد إلى دورة شراء قابلة للتكيف مع القانون المحلي، مع فصل المتطلبات الأساسية عن الأدلة والاختبارات وخطة الخروج.