قائمة تحقق للمساءلة في الذكاء الاصطناعي: دروس من Timnit Gebru

لماذا تهم مساءلة الذكاء الاصطناعي عند الاقتراب من الإطلاق

كان بناء ميزة ذكاء اصطناعي سؤالًا تقنيًا في الغالب: هل نستطيع تشغيل النموذج؟ الآن السؤال الأصعب هو ما إذا كان يجب عليك نشرها، وما القيود التي تحتاجها.

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

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

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

قائمة تحقق بسيطة للمساءلة تجبر على أجوبة ملموسة:

• ما البيانات التي غذّت الميزة، وما الثغرات المعروفة؟
• ما الاستخدام المقصود، وما الذي هو خارج النطاق صراحة؟
• ما الأخطاء المتوقعة، ومن قد يتضرر؟
• ما الضوابط الموجودة (مراجعة بشرية، حلول بديلة، مراقبة)؟

الهدف ليس نظرية. هو توثيق الأساسيات (البيانات، الحدود، المخاطر)، ثم اتخاذ قرار يمكنك الدفاع عنه لاحقًا، حتى لو كنت تتحرك بسرعة.

Timnit Gebru في صفحة واحدة: ما الذي غيّرته أعمالها

تُعد Timnit Gebru من أبرز الأصوات في مساءلة الذكاء الاصطناعي لأنها دفعت بفكرة بسيطة غاب عنها الكثير من الفرق: ليس كافيًا أن تسأل "هل نستطيع بناؤه؟" بل عليك أيضًا أن تسأل "هل يجب أن ننشره، من قد يتضرر، وكيف سنعرف ذلك؟"

جزء كبير من هذا التحوّل هو جعل أنظمة الذكاء الاصطناعي قابلة للفهم من قبل الآخرين. ليس فقط للمهندسين الذين درّبوا النموذج، بل للمراجعين، ومديري المنتجات، وفرق الدعم، والمستخدمين. الفكرة هي كتابة ما يهدف النظام لفعله، ما البيانات التي شكلته، أين يفشل، وكيف تبدو المخاطر في الحياة الواقعية.

أصبح منشطان عمليان شائعين لأنهما يجعلانهذا الفهم ملموسًا:

• ملاحظات مجموعات البيانات (غالبًا تسمى datasheets for datasets): ما هي البيانات، من أين جاءت، من هو ممثل أو مفقود، وما الذي لا يجب استخدامها من أجله.
• ملاحظات النماذج (غالبًا تسمى model cards): ما غرض النموذج، كيف تم اختباره، الحدود المعروفة، وأنواع الأخطاء المتوقعة.

لفرق المنتج، هذا ليس مجرد أوراق. التوثيق هو دليل. عندما يسأل أحدهم، "لماذا أطلقنا هذه الميزة؟" أو "لماذا لم تكتشفوا وضع الفشل هذا؟" تحتاج لشيء تشير إليه: ما الذي قستوه، ما اخترتّ عدم دعمه، وما الضمانات التي أضفتها.

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

ما الذي يُعد ميزة ذكاء اصطناعي وما الذي قد يسوء

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

الأنواع الشائعة تشمل التلخيص، الترتيب، التوصيات، الإشراف، والتصنيف/التسجيل (مخاطر، احتيال، جودة، أهلية، أولوية).

عندما تسوء الأمور، يمكن أن يتعدى التأثير الشخص الذي نقر على الزر. الأشخاص الذين قد يتضررون يشملون المستخدمين النهائيين، غير المستخدمين (المذكورين أو الملفوفين)، موظفي الدعم والمشرفين، المتعاقدين والمراجعين، وموضوعات البيانات التي استُخدمت لتدريب أو تقييم الميزة.

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

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

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

الحد الأدنى من التوثيق الذي يجب أن تملكه قبل الإطلاق

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

المجموعة الدنيا للوجود كتابةً قبل الإصدار:

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

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

عيّن مالكًا واحدًا لتحديث المستندات (عادة مالك المنتج للميزة، وليس الشؤون القانونية). ضع وتيرة (مع كل إصدار أو كل شهر)، وبموجب تحديث فوري بعد أي حادث.

حافظ على النبرة صادقة وملموسة. تجنّب عبارات مثل "دقة عالية" ما لم تذكر مجموعة الاختبار والمقياس وحالات الفشل التي لم تُصلح.

توثيق البيانات: ما الذي تُسجّله ومدى التفصيل المطلوب

تقوم ملاحظات البيانات الجيدة بوظيفتين: تساعدك على التنبؤ بالأخطاء قبل أن يكتشفها المستخدمون، وتعطي الزملاء في المستقبل سببًا واضحًا للثقة (أو عدم الثقة) في النظام.

احفظ مستوى التفاصيل "الكافي للإجابة على الأسئلة الصعبة في 10 دقائق." لست تكتب أطروحة. تكتب حقائق سيحتاجها شخص ما خلال تقرير خطأ، مراجعة خصوصية، أو شكوى عميل.

ابدأ بمخزون بيانات بسيط. لكل مجموعة بيانات (بما في ذلك السجلات، الملاحظات، والمصادر الخارجية)، سجّل المصدر ومن يسيطر عليه، متى جُمعت وكيف تتحدّث، أي سلوك منتج تدعمه، حدود الخصوصية والموافقة، وكيف تم وسمها أو تنظيفها.

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

إذا استخدمت وسمًا بشريًا، وثّق سياق الوسم (خبراء مقابل جماهير)، التعليمات التي رآها الوسّمون، وأين اختلفوا. الاختلاف ليس عيبًا يجب إخفاؤه. إنه إشارة تحذير لتصميم حولها.

توثيق القيود: اجعل الحواف مرئية

قسم توثيق القيود هو المكان الذي تنتقل فيه من "عمل في العرض التجريبي" إلى "هذا ما يمكن لهذه الميزة التعامل معه بأمان." إذا كتبت مسار النجاح فقط، سيجد المستخدمون الحواف نيابة عنك.

ابدأ بتسمية مهمة النموذج في جملة واحدة، ثم سمّ ما ليس له. "صياغة ردود قصيرة للأسئلة الشائعة" تختلف كثيرًا عن "تقرير قرارات الاسترداد" أو "كشف الاحتيال." هذا الحد يجعل قرارات لاحقة (نص واجهة المستخدم، قواعد التصعيد، تدريب الدعم) أسهل بكثير.

سجّل أنماط الفشل المعروفة بلغة واضحة. عادة ما يغطي قسم الحدود الجيد المدخلات التي تربكه (طلبات غامضة، سياق مفقود، لغات مختلطة)، النغمات التي يسيء قراءتها (سخرية، نكات، غضب)، ما يفعله بشكل سيئ في الحالات النادرة (مصطلحات متخصصة، منتجات غير مألوفة)، وما يمكن أن يكسره عن قصد (حقن مطالبات، إغراء لكشف بيانات خاصة).

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

ثم أعد تحذيرًا واحدًا يمكنك إعادة استخدامه في المنتج:

"قد تكون الردود المولّدة بالذكاء الاصطناعي ناقصة أو خاطئة. لا تستخدمها لقرارات قانونية أو طبية أو مالية. إذا كان هذا يخص الفواتير أو الاسترداد أو وصول الحساب، فاتصل بالدعم."

حدّث هذه الملاحظة كلما تغيّر النموذج أو المطالبات أو السياسات.

تقييم ضرر المستخدم: حوّل المخاوف إلى خريطة مخاطر مكتوبة

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

ابدأ بفئات واسعة حتى لا تفوت الواضح: السلامة، التمييز، الخصوصية، الخداع، والموثوقية.

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

لأجل الأولوية، استخدم مقاييس بسيطة. لكل سيناريو، ضع علامة الشدة (منخفض، متوسط، عالي) والاحتمال (منخفض، متوسط، عالي). لست بحاجة لأرقام دقيقة. تحتاج إلى رؤية مشتركة لما يستحق العمل الآن.

أخيرًا، عيّن مالكين. تَخفيف من دون اسم ليس تخفيفًا. لكل سيناريو، اكتب التخفيف قبل الإطلاق (حواجز، رسائل واجهة، مواضيع محظورة، تسجيل)، التخفيف بعد الإطلاق (دليل دعم، مراقبة، مشغل استرجاع)، ومن المسؤول.

خطوة بخطوة: كيف تؤمن بوابة ميزة ذكاء اصطناعي من النموذج الأولي إلى الإصدار

الترخيص هو كيف تنتقل من "نستطيع بناؤه" إلى "يجب أن نطرحه." عاملها كمجموعة مخارج: لا تمر للمخرج التالي حتى تُكتب الأساسيات، تُراجع، وتُختبر.

1. اكتب النية والقرار الذي سيؤثر فيه. كن محددًا بشأن من يستخدمه، ما القرار، وماذا يحدث إذا كانت المخرجات خاطئة.

2. اكتب ملاحظات البيانات والقيود مبكرًا. افعل ذلك قبل تلميع واجهة المستخدم، بينما لا تزال الميزة سهلة التعديل.

3. اختبر بحالات واقعية، حافة، وحساسة. استخدم نصوص فوضوية، عامية، لغات مختلفة، محادثات طويلة، وطلبات غامضة. أضف بعض الحالات عالية المخاطر (نزاعات فواتير، وصول الحساب، أسئلة طبية أو قانونية) حتى لو لم تكن الميزة مخصصة لها، لأن المستخدمين سيجرّبون.

4. أضف رسائل للمستخدم، حلول بديلة، وتصعيد. قرر ما يراه المستخدم عندما يرفض النموذج، أو يكون غير متأكد، أو يعمل بشكل سيء. قدّم بديلًا آمنًا (مثل "اطلب إنسانًا"), واجعل الإبلاغ عن إجابة سيئة سهلًا.

5. حدد المراقبة، الحوادث، والاسترجاع. اختر الإشارات التي ستراقبها (الشكاوى، معدل التراجع، المخرجات المعلّمة)، من يتلقى التنبيه، وكيف يبدو "إيقاف الميزة".

إذا بدا أي خطوة صعبة، فعادةً ما يخبرك ذلك بمكان المخاطرة.

الأخطاء الشائعة التي ترتكبها الفرق في مساءلة الذكاء الاصطناعي

أسرع طريقة لتقويض الثقة هي اعتبار نتيجة جيدة في المختبر دليلًا أنك آمن في العالم الحقيقي. تساعد المعايير، لكنها لا تُظهر كيف سيدفع الناس أو يسيئون الفهم أو يعتمدون على الميزة في العمل اليومي.

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

الفرق تميل أيضًا لاختبار بعاداتها الخاصة. المطالبات الداخلية مؤدبة ومتوقعة. المستخدمون الحقيقيون مرهقون، مستعجلون، ومبدعون. ينسخون نصوصًا فوضوية، يسألون متابعة، أو يحاولون كسر القواعد.

خمسة أخطاء تتكرر:

• اعتبار معيار أو تقييم غير متصل بالإنترنت قرار الإطلاق
• إجبار إجابة واثقة واحدة بدل السماح بـ "لا أعلم" أو "يحتاج مراجعة"
• الاختبار فقط بمطالبات الفريق وتجاهل المدخلات الحقيقية الفوضوية
• كتابة الوثائق بعد الإطلاق ثم عدم تحديثها مع تغير الميزة
• الإطلاق بدون مسار استرجاع

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

مثال واحد: إذا نشرت مساعدًا ذكيًا داخل منشئ تطبيقات، اختبره بطلبات غامضة ("اجعله مثل Airbnb"), متطلبات متضاربة، ومحتوى حساس. ثم ضع خطة استرجاع واضحة (لقطات، نسخ/إصدار، مفتاح تعطيل سريع) حتى تستطيع التصرف بسرعة عند ورود تقارير مستخدمين عن ضرر.

قائمة تحقق سريعة يمكنك نسخها في المواصفة

انسخ هذا في مواصفة المنتج واملأه قبل الإطلاق. اجعلها قصيرة، لكن اجعل كل إجابة محددة. سمّ مالكًا لكل خطر.

### 1) Purpose and affected people
- Feature name:
- What decision or action does the AI support (one sentence):
- Who uses it:
- Who is affected even if they never use it (customers, employees, bystanders):
- What a “good” outcome looks like:

### 2) Data used (training, tuning, retrieval, logs)
- Data sources (where it came from and why it’s allowed):
- What you excluded (and why):
- Sensitive data involved (PII, health, finance, kids):
- Data retention period and deletion plan:
- Security and access controls:

### 3) Limits and “do not use” zones
- Known failure modes (give 3-5 concrete examples):
- Languages supported and not supported:
- Inputs it should refuse (or route to a human):
- Cases where it must not be used (legal, medical, hiring, etc.):

### 4) User harm assessment
- Top 5 harms (ranked):
- Mitigation for each harm:
- Who owns each mitigation (name + team):
- What you will tell users (warnings, confidence cues, citations):

### 5) Operations after launch
- Monitoring signals (quality, complaints, bias flags, cost spikes):
- Human review path (when and how escalation happens):
- Rollback trigger (exact threshold or condition):
- Snapshot/version you can revert to:

مثال: إذا كانت الميزة تصيغ ردود دعم العملاء، اذكر أضرارًا مثل "سياسة استرداد مختلقة بثقة" وضع قاعدة أن المسودات منخفضة الثقة تتطلب موافقة قبل الإرسال.

مثال: توثيق مساعد ذكي لخدمة العملاء

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

ملاحظات البيانات (ما تعلّم منه مقابل ما يراه الآن)

فصلوا مصدرين. الأول بيانات التدريب أو التخصيص (تذاكر دعم سابقة، مستندات مساعدة داخلية، سياسات المنتج). الثاني السياق الحي (رسالة العميل، خطة الحساب، حالة الطلب، وأي ملاحظات تظهر في وحدة وكيل الدعم).

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

القيود (اجعل الحواف مرئية)

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

أضافوا قاعدة: يجب على المساعد أن يستشهد بالمستند الداخلي أو مقطع السياسة الذي استخدمه، أو أن يقول "لم أجد مصدرًا."

خريطة الأضرار المحتملة: قد يضلل العملاء بسياسة استرداد مختلقة، قد تتسرب معلومات خاصة إلى الرد، أو قد يؤدي لغة متحيزة إلى معاملة غير عادلة.

أدخلوا التخفيفات كعوائق ملموسة في المواصفة:

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

هذا يحول سؤال "هل نشرناها؟" إلى فحوصات مكتوبة يمكن للفريق اختبارها قبل أن يشعر العملاء بالضرر.

الخطوات التالية: اجعل المساءلة عادة، لا مهمة لمرة واحدة

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

حوّل توثيقك إلى أحد النتائج الثلاث:

• نشر: الميزة تحقق الهدف، المخاطر مفهومة، والضوابط حقيقية.
• نشر محدود: قيد من يمكنه استخدامها، ماذا يمكن استخدامها لأجله، وكيف تُعرض النتائج.
• لا تنشر (بعد): البيانات ضعيفة جدًا، أنماط الفشل مكلفة، أو لا تستطيع شرحها بما يكفي.

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

بعد الإطلاق، عامل المساءلة كجزء من العمليات. اختر وتيرة (أسبوعية أو مع كل إصدار) واجعل التحديثات أمرًا عاديًا.

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

إذا كنت تصنع نموذجًا أوليًا بسرعة، فحافظ على نفس الانضباط. الأدوات التي تتحرك بسرعة لا تمنع أبواب الحماية. على سبيل المثال، إذا بنيت في Koder.ai (koder.ai), استخدم وضع التخطيط لتحديد الحدود مبكرًا، واعامل اللقطات والاسترجاع كجزء من خطة السلامة وليس مجرد وسيلة راحة.