يصل سؤال أساسي مع هذه الأنظمة في اللحظة التي تلمس فيها أشخاصًا حقيقيين: هل نستطيع الاعتماد عليها لتتصرّف بإنصاف وأمان وعلى نحو مفهوم؟
يصل سؤال أساسي مع هذه الأنظمة في اللحظة التي تلمس فيها أشخاصًا حقيقيين: هل نستطيع الاعتماد عليها لتتصرّف بإنصاف وأمان وعلى نحو مفهوم؟
هذا الفصل ليس عن الشفرة البرمجية. هو عن المسؤولية. وسواء كنت مطوّرًا أو صاحب قرار أو قارئًا يدفعه الفضول، يستحقّ الأمر أن تفهم المخاطر التي تأتي مع وضع برمجيات أمام أشخاص لم يختاروها.
وأمر واحد يتغيّر حين يُقسَّم العمل بين عدة وكلاء، فلنقله من البداية: كل ما في هذا الفصل يصبح أصعب على الرؤية. خطوات أكثر، وعمليات تسليم مهمة أكثر، ومواضع أكثر يمكن أن يختلّ فيها شيء في صمت. وكل ما يأتي أدناه من مخاوف ينطبق على نظام من الجزء الخامس بقوة أكبر من انطباقه على وكيل واحد.
إنصاف النظام لا يزيد على إنصاف المادة التي تعلّم منها. وحيث تحمل تلك المادة تحيّزًا، يستطيع النموذج أن يعكسه، وأن يضخّمه أحيانًا.
هذه ليست أخطاءً برمجية بالمعنى المعتاد. هي مخاطر أخلاقية لها تبعات على أشخاص، ولن تظهر في اختبار يتحقّق فقط مما إذا كان النظام قد عمل.
ما يساعد: اختبر على بيانات تعكس الأشخاص الذين سيتأثّرون فعلًا؛ وطبّق مقاييس الإنصاف أثناء التطوير لا بعد النشر؛ وضع مراجعين بشريين في المسارات الحسّاسة؛ ووثّق مصادر بياناتك وحدودها، حتى يعرف مستخدمو النظام أين هو ضعيف.
مما يستحقّ الحفظ: النظام الدقيق ليس نظامًا منصفًا بالضرورة.
هل وصلتك إجابة يومًا فتساءلت: لماذا هذه الإجابة؟ تلك هي مشكلة الشفافية.
تستطيع هذه الأنظمة أن تتصرّف كصناديق مغلقة. تنتج مخرجات سليمة الصياغة دون أن تكشف بالضرورة ما أدّى إليها. وفي التمويل أو الرعاية الصحية أو القانون، هذا الغموض خطر حقيقي، لأن أحدًا سيضطرّ إلى تبرير القرار للشخص الذي تأثّر به.
كيف تبني التفسير في التصميم:
قاعدة عملية: إن كان وكيلك لا يستطيع تفسير إجابته للشخص المتأثّر بها، فأعد النظر في نشره في ذلك الدور.
تنتج هذه الأنظمة مخرجات سليمة الصياغة وواثقة. وأحيانًا تكون تلك المخرجات خاطئة، أو مؤلَّفة من العدم. والمصطلح المعتاد هو الهلوسة.
ما يقلّلها: استند بالإجابات إلى مصادر مسترجَعة قابلة للتحقّق؛ واعرض الإحالات ليتحقّق القارئ بدلًا من أن يثق؛ واشترط مراجعة بشرية لكل ما هو حسّاس أو موجَّه إلى الجمهور؛ واكتب التعليمات بحيث تكون «لا أعرف» إجابة مقبولة. فالنظام الملزَم بأن ينتج شيئًا دائمًا سينتج شيئًا دائمًا.
قاعدة تقريبية: الثقة ليست دليلًا. وكلما كانت النبرة أكثر يقينًا، كان التحقّق من المصدر أجدر.
يتعامل الوكلاء كثيرًا مع بيانات شخصية أو حسّاسة، وهذا يطرح أسئلة جدّية عن الموافقة والالتزام القانوني.
وخصيصتان في الأنظمة الوكيلية تجعلان هذا أحدّ مما كان مع نموذج محادثة مجرّد. الذاكرة تعني أنك تخزّن الآن معلومات عن أشخاص، عن قصد. ومنفذ الأدوات يعني أن النظام يستطيع الوصول إلى أنظمة تحمل أكثر من ذلك بكثير.
الجدول 15-1: المراجع التي ستقابلها على الأرجح
| النطاق | المرجع | محور التركيز |
|---|---|---|
| الاتحاد الأوروبي | GDPR | الموافقة، وتقليل ما تجمعه، والحق في محو البيانات |
| الولايات المتحدة | HIPAA، CCPA | البيانات الصحية؛ وحقوق المستهلك في كاليفورنيا |
| كندا | PIPEDA | استخدام محدود بغرض معلَن، وحقوق الوصول |
| البرازيل | LGPD | الشفافية وتحكّم المستخدم |
| معيار طوعي | ISO/IEC 27001 | إطار لإدارة أمن المعلومات — يُعتمد طوعًا، وليس تشريعًا لحماية البيانات |
كيف تبقى في الجانب الصحيح: أزِل ما يمكن إزالته من البيانات المعرِّفة؛ واطلب الموافقة بوضوح؛ وخزّن وانقل بصورة آمنة؛ وأتِح للأشخاص مراجعة ما تحفظه عنهم وحذفه؛ وحدّد مدد الاحتفاظ مسبقًا، لا سيما في الذاكرة طويلة المدى؛ وانتبه لما تحفظه سجلاتك، لأن سجلات تنقيح الأخطاء من وكيل قد تحتوي كل ما قرأه.
الخلاصة: إن كان وكيلك يلمس بيانات شخصية، فالخصوصية موضعها التصميم، لا مراجعة لاحقة.
مسألة واحدة تخصّ الوكلاء تحديدًا، ولا تنشأ مع نموذج ينتج نصًّا فقط: هذه الأنظمة تتصرّف. هي التي ترسل البريد، وتحوّل المال، وتغلق التذكرة.
وهذا يطرح سؤالًا ليس تقنيًا. حين يفعل وكيل شيئًا خاطئًا، من المسؤول؟
لا يمكن أن يكون الجواب هو الوكيل. لذا على التصميم أن يجعل الجواب واضحًا.
لاحظ أن أربعة من هذه الخمسة قرارات في الصلاحيات والإجراءات، لا في النموذج. وهذا هو الخبر الجيّد في هذا الفصل: أكثر ما يجعل الوكيل مسؤولًا هو انتظام هندسي عادي، متاح لكل من يقرّر تطبيقه.
وكل هذا متّفق عليه من حيث المبدأ عند الجميع تقريبًا، ثم يصطدم بحائط عملي. يبني فريق شيئًا مثيرًا للإعجاب، ويعرضه بنجاح، فيسأل من عليه أن يعتمده سؤالًا معقولًا تمامًا لم يستعدّ له أحد: كيف تعرف؟