الأدوار والمسؤوليات في حوكمة الذكاء الاصطناعي: من يملك ماذا ومن يُساءل عن ماذا؟

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

ويزداد هذا التحدي مع AI لأن النظام الواحد قد يجمع بين إدارة الأعمال والتقنية والبيانات والأمن والخصوصية والقانون والمخاطر والمورد الخارجي والمستخدم النهائي.

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

لهذا فإن تصميم الأدوار ليس تمرينًا في كتابة المسميات الوظيفية، بل هو تصميم لبنية المساءلة والملكية والمسؤولية والسلطة عبر دورة حياة AI.

1. لماذا تحتاج حوكمة AI إلى بنية واضحة للأدوار؟

أنظمة AI لا تعيش عادة داخل إدارة واحدة.

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

وعندما تظهر مشكلة، يصبح السؤال:

من المسؤول؟

إذا كانت الإجابة «الفريق» أو «اللجنة» أو «تقنية المعلومات» أو «المورد»، فقد تكون المسؤولية غير محددة بما يكفي.

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

2. خمسة مفاهيم يجب عدم الخلط بينها

من أكثر أسباب ضعف حوكمة AI استخدام كلمات مثل المسؤول والمالك وصاحب القرار وكأنها مترادفات.

ليست كذلك.

المساءلة — Accountability

المساءلة تعني وجود طرف يمكن مطالبته بتفسير النتائج والقرارات وضمان التعامل معها ضمن نطاق دوره وقدرته على التصرف.

لا تعني المساءلة أن هذا الطرف ينفذ كل المهام بنفسه.

المسؤولية — Responsibility

المسؤولية ترتبط بالمهمة أو العمل الذي يجب تنفيذه.

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

الملكية — Ownership

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

وجود مالك لا يعني بالضرورة أنه يستطيع الموافقة على جميع القرارات المتعلقة بما يملكه.

سلطة اتخاذ القرار — Decision Authority

هي الصلاحية المؤسسية لاتخاذ قرار محدد مثل الموافقة أو الرفض أو قبول المخاطر أو منح استثناء أو تعليق النظام.

الصلاحية التقنية — Technical Permission

هي القدرة التقنية على تنفيذ إجراء داخل نظام أو منصة.

امتلاك صلاحية تقنية لا يمنح تلقائيًا سلطة مؤسسية.

Accountability ≠ Responsibility ≠ Ownership ≠ Decision Authority ≠ Technical Permission

وهذا الفصل من أهم أسس الحوكمة المؤسسية.

3. مجلس الإدارة

يعتمد دور مجلس الإدارة على طبيعة المؤسسة وحجم تعرضها للذكاء الاصطناعي وهيكل الحوكمة المعتمد لديها.

لا ينبغي افتراض أن المجلس سيوافق على كل نظام أو نموذج.

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

يجب ألا يتحول مجلس الإدارة إلى بوابة تشغيلية لكل قرار AI، كما يجب ألا يكون منفصلًا تمامًا عن التعرضات الجوهرية الناتجة عنه.

4. القيادة التنفيذية

تقع على القيادة التنفيذية مسؤولية محورية في جعل حوكمة AI قابلة للعمل.

يشمل ذلك، بحسب نموذج المؤسسة:

• تحديد التوجه المؤسسي.
• اعتماد السياسات الرئيسية.
• تحديد شهية المخاطر أو حدودها المناسبة.
• تخصيص الموارد.
• تحديد سلطات القرار.
• تمكين وظائف الحوكمة.
• معالجة النزاعات بين الجهات.
• متابعة المخاطر الجوهرية.
• ضمان دمج AI Governance في العمليات المؤسسية.

يمكن تفويض كثير من القرارات، لكن التفويض لا يعني اختفاء المساءلة التنفيذية.

5. وظيفة حوكمة الذكاء الاصطناعي

قد توجد وظيفة مركزية باسم AI Governance Office أو Responsible AI Office أو ضمن المخاطر أو البيانات أو التقنية أو التحول.

لا ينبغي الحكم على قوة هذه الوظيفة من اسمها.

قد تشمل مسؤولياتها:

• تطوير السياسات والمعايير.
• إدارة منهجية الحوكمة.
• إدارة سجل AI المؤسسي.
• تنسيق التصنيف والتقييم.
• إدارة مسارات المراجعة.
• تنسيق لجان الحوكمة.
• متابعة الاستثناءات.
• متابعة إجراءات المعالجة.
• تطوير التقارير والمؤشرات.
• دعم مالكي الحالات.
• تنسيق الأدلة.
• متابعة تطور نموذج الحوكمة.

لكن وجود وظيفة مركزية لا يجعلها مالكة لكل نظام أو كل خطر.

وظيفة الحوكمة تمكّن وتنسق وتراقب النظام الحوكمي، بينما تبقى الملكية التشغيلية موزعة على الجهات المناسبة.

6. مالك الأعمال

Business Owner يرتبط بالهدف أو النتيجة المؤسسية التي يسعى استخدام AI إلى تحقيقها.

يجب أن يستطيع الإجابة عن أسئلة مثل:

• لماذا نستخدم AI؟
• ما المشكلة التي نحاول حلها؟
• ما القيمة المتوقعة؟
• من يتأثر بالنتيجة؟
• ما مستوى الخطأ المقبول في السياق؟
• هل ما زال الاستخدام مبررًا؟

ولا ينبغي أن يتحول AI إلى مشروع تقني بلا مالك أعمال قادر على الدفاع عن الحاجة إليه وتحمل المسؤولية عن سياقه المؤسسي.

7. مالك حالة الاستخدام

Use Case Owner هو أحد أهم الأدوار في النموذج.

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

قد تشمل مسؤولياته:

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

يجب ألا توجد حالة استخدام تشغيلية لا يمكن تحديد مالكها.

8. مالك النظام

System Owner يرتبط بالنظام التقني الذي يتيح حالة الاستخدام.

قد تشمل مسؤولياته:

• إدارة النظام.
• التكوين.
• الإصدارات.
• الاعتماديات.
• التكاملات.
• الوصول التقني.
• التشغيل والصيانة.
• التغييرات التقنية.
• بعض عناصر الرصد.

وقد يخدم النظام نفسه حالات استخدام متعددة، ولذلك يجب عدم افتراض أن System Owner وUse Case Owner هما الشخص نفسه.

9. مالك النموذج أو مكوّن AI

عندما تستخدم المؤسسة نموذجًا أو مكون AI داخليًا يمكن تحديد Model Owner أو AI Component Owner.

قد تشمل مسؤولياته:

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

لكن هذا الدور يصبح أكثر تعقيدًا عند استخدام نموذج خارجي.

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

10. مالك البيانات

Data Owner لا يملك بالضرورة نموذج AI أو حالة الاستخدام، لكنه يؤدي دورًا حاسمًا عندما تعتمد الحالة على بيانات مؤسسية.

قد تشمل مسؤولياته تحديد شروط استخدام البيانات، والموافقة على الوصول بحسب نموذج الصلاحيات المعتمد، والمحافظة على متطلبات الجودة والتصنيف والاحتفاظ والاستخدام المناسب.

ويجب التفريق بين:

امتلاك البيانات → السماح باستخدام البيانات → تحمل المسؤولية عن قرار AI النهائي

هذه ليست بالضرورة مسؤولية واحدة.

11. مالك المخاطر

Risk Owner هو الطرف المخول بإدارة خطر محدد ضمن نظام إدارة المخاطر المؤسسي.

وجود Risk Owner لا يعني أن إدارة المخاطر نفسها يجب أن تصبح مالكة لكل خطر AI.

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

والقاعدة المهمة:

لا ينبغي إسناد ملكية الخطر إلى جهة لا تملك القدرة المناسبة على التأثير فيه.

12. مالك الضابط

Control Owner مسؤول عن ضمان تصميم الضابط وتشغيله ومتابعته ضمن النطاق المحدد.

وهذا مختلف عن:

• من ينفذ نشاط الضابط.
• من يختبر فعاليته.
• من يقدم توكيدًا مستقلًا بشأنه.
• من يملك الخطر الذي يعالجه الضابط.

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

الفصل بين هذه الأدوار يساعد على منع تضارب المصالح.

13. الأمن السيبراني

الأمن السيبراني ليس مالكًا لكل AI في المؤسسة.

دوره يرتبط بالمخاطر والضوابط الأمنية ذات الصلة، مثل الوصول، وحماية البيانات والنماذج، وسلسلة التوريد، والواجهات، والبنية التحتية، والتسجيل، والاختبارات الأمنية، والاستجابة للحوادث.

ومع GenAI وRAG والوكلاء، تظهر أيضًا مخاطر مثل Prompt Injection والتلاعب بمصادر المعرفة وإساءة استخدام الأدوات والصلاحيات.

لكن وظيفة الأمن لا ينبغي أن تتحمل وحدها مسؤولية قرار الأعمال باستخدام AI.

14. الخصوصية وحماية البيانات

تدخل وظيفة الخصوصية عندما تتضمن الحالة بيانات شخصية أو معالجة ذات آثار متعلقة بالخصوصية وحماية البيانات.

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

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

15. القانون والامتثال

تساعد الوظائف القانونية ووظائف الامتثال في تحديد المتطلبات القانونية والتنظيمية والتعاقدية ذات الصلة.

وقد يشمل ذلك:

• استخدام البيانات.
• حقوق الملكية الفكرية.
• العقود.
• متطلبات القطاعات المنظمة.
• الإفصاح.
• حماية المستهلك.
• التوظيف.
• القرارات الآلية.
• الاحتفاظ بالسجلات.

لكن دورها لا ينبغي أن يتحول إلى «الموافقة القانونية على AI» بصورة عامة وغير محددة.

يجب تحديد السؤال القانوني أو التنظيمي الذي يحتاج إلى قرار أو رأي، ومن يملك القرار النهائي بعد أخذ ذلك الرأي في الاعتبار.

16. المشتريات وإدارة الموردين

عند شراء AI أو استخدام خدمة خارجية، تصبح المشتريات وإدارة الموردين جزءًا مهمًا من الحوكمة.

قد تشمل مسؤولياتهما:

• العناية الواجبة بالمورد.
• جمع المعلومات.
• تضمين المتطلبات التعاقدية.
• إدارة الالتزامات.
• متابعة التجديد.
• إدارة التغيير في الخدمة.
• دعم إدارة مخاطر الطرف الثالث.

لكن توقيع العقد لا ينقل المساءلة المؤسسية عن استخدام AI إلى المورد.

Outsourcing AI ≠ Outsourcing Accountability

17. التدقيق الداخلي والتوكيد المستقل

يجب المحافظة على استقلالية وظيفة التدقيق أو التوكيد المستقل.

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

لذلك يجب التمييز بين:

Design → Operate → Monitor → Test → Assure

وقد تنفذ هذه الوظائف جهات مختلفة بحسب حجم المؤسسة ونموذجها.

18. المستخدمون والموظفون

المستخدم النهائي ليس خارج نموذج الحوكمة.

قد تشمل مسؤوليات المستخدم:

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

ومع أدوات GenAI العامة، يصبح وضوح مسؤوليات المستخدم عنصرًا أساسيًا للحد من Shadow AI.

19. المورد لا يحل محل أدوار المؤسسة

قد يقدم المورد النموذج والمنصة والاستضافة والرصد والدعم الفني.

لكن المؤسسة لا تزال بحاجة إلى تحديد من يملك داخليًا:

• قرار الاستخدام.
• الغرض.
• تقييم ملاءمة الخدمة.
• المخاطر الناتجة عن السياق.
• بيانات المؤسسة.
• إدارة الوصول.
• قبول المخاطر المتبقية.
• التعامل مع المتأثرين.
• قرار الاستمرار أو الإيقاف.

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

20. ماذا يتغير مع الوكلاء AI Agents؟

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

هنا يجب التمييز بين:

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

الوكيل نفسه لا يحل محل بنية المساءلة المؤسسية.

منح Agent قدرة تقنية على تنفيذ إجراء لا يعني منحه سلطة مؤسسية غير محدودة لاتخاذ القرار الذي يقف خلف ذلك الإجراء.

21. RACI مفيد، لكنه غير كافٍ

RACI يمكن أن يساعد في تحديد:

• Responsible
• Accountable
• Consulted
• Informed

لكنه لا يجيب دائمًا بدقة عن:

• من يستطيع الموافقة؟
• من يستطيع الرفض؟
• من يستطيع قبول المخاطر؟
• من يستطيع منح استثناء؟
• من يستطيع تعليق النظام؟
• ما حدود التفويض؟
• متى يجب التصعيد؟
• ما الأدلة اللازمة للقرار؟

لذلك تحتاج حوكمة AI إلى ما هو أكثر من RACI.

تحتاج إلى Decision Rights Matrix أو آلية مكافئة تربط نوع القرار بصاحب السلطة وحدودها وشروطها ومسار التصعيد.

22. الفصل بين المهام وتعارض المصالح

ليس الهدف من الفصل بين المهام زيادة البيروقراطية، بل منع حالات يستطيع فيها طرف واحد إنشاء الخطر والموافقة عليه واختبار نفسه وقبول النتيجة دون تحدٍ مناسب.

تزداد أهمية الفصل عندما تكون القرارات عالية الأثر.

وقد يشمل الفصل بين:

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

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

23. ماذا يحدث في النموذج المركزي والاتحادي والهجين؟

في النموذج المركزي قد تكون وظيفة AI Governance المركزية أكثر مشاركة في المراجعات والقرارات.

في النموذج الاتحادي قد تحتفظ الجهة المركزية بالسياسات والمنهجيات بينما تتولى وحدات الأعمال مسؤوليات أكبر.

أما النموذج الهجين فقد يوزع الأدوار بحسب مستوى المخاطر.

لكن المبدأ لا يتغير:

تفويض العمل أو القرار لا يجوز أن ينتج غموضًا في المساءلة.

يجب أن يكون واضحًا ما تم تفويضه، ولمن، وتحت أي حدود، ومتى ينتهي التفويض، ومتى يجب التصعيد.

24. كيف تتغير الأدوار عبر دورة الحياة؟

الأدوار ليست ثابتة في كل مرحلة.

في مرحلة الفكرة يكون Business Owner وUse Case Owner في المقدمة.

أثناء التصميم والتطوير تزداد أدوار البيانات والتقنية والأمن والنموذج.

قبل التشغيل تصبح المراجعات وسلطات القرار أكثر أهمية.

أثناء التشغيل تصبح المراقبة والرصد وإدارة الحوادث والتغيير أكثر حضورًا.

وعند التقاعد تظهر مسؤوليات الإيقاف والبيانات والسجلات والاعتماديات.

لذلك يجب تصميم Role Architecture عبر دورة الحياة، لا مصفوفة ثابتة منفصلة عن مراحل النظام.

25. الأدلة المرتبطة بالأدوار والقرارات

وجود اسم داخل RACI لا يثبت أن الحوكمة حدثت.

يجب أن تترك الأدوار والقرارات الجوهرية أثرًا قابلًا للإثبات.

قد يشمل ذلك:

• تعيين المالك.
• سجل الموافقة.
• سجل قبول المخاطر.
• رأي المراجع المختص.
• شروط الموافقة.
• الاستثناء.
• نتيجة الاختبار.
• قرار التصعيد.
• قرار التغيير.
• قرار تعليق النظام أو استئنافه.

السؤال ليس فقط:

من كان مسؤولًا؟

بل أيضًا:

هل نستطيع إثبات من قام بماذا، ومن قرر ماذا، وعلى أي أساس؟

26. أخطاء شائعة في تصميم الأدوار

جعل الجميع مسؤولين

إذا كان الجميع مسؤولًا دون تحديد، فقد لا يكون أحد مساءلًا بوضوح.

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

Ownership بلا قدرة مناسبة على التأثير ينتج ملكية شكلية.

الخلط بين المنفذ وصاحب القرار

من ينفذ التقييم ليس بالضرورة من يقبل المخاطر.

الخلط بين صلاحية النظام والسلطة المؤسسية

وجود زر Deploy لا يعني امتلاك سلطة اعتماد الإنتاج.

تحميل وظيفة AI Governance كل المسؤولية

هذا يفصل الأعمال والتقنية عن نتائج الأنظمة التي يستخدمونها.

اعتبار المورد مسؤولًا عن كل شيء

المورد لا يعرف دائمًا السياق المؤسسي الذي تستخدم فيه خدمته.

استخدام RACI باعتباره الحل الكامل

RACI لا يحل وحده مشكلة سلطات القرار والتفويض والتصعيد.

غياب إعادة تعيين الأدوار

تغيير الهيكل أو الموظفين أو المورد أو النظام قد يجعل سجل الملكية قديمًا.

27. كيف تبني المؤسسة Role Architecture عملية؟

ابدأ بالأصول والقرارات، وليس بالمسميات.

حدد أولًا:

1. ما الذي يحتاج مالكًا؟
2. ما القرارات الجوهرية؟
3. ما المهام المطلوبة؟
4. ما المخاطر التي تحتاج مالكًا؟
5. ما الضوابط التي تحتاج مالكًا؟
6. أين نحتاج تحديًا أو مراجعة مستقلة؟
7. ما الذي يمكن تفويضه؟
8. ما حدود التفويض؟
9. ما مسارات التصعيد؟
10. ما الأدلة التي تثبت تنفيذ الدور أو القرار؟

بعد ذلك اربط هذه المتطلبات بالوظائف والأشخاص الفعليين داخل المؤسسة.

هذه الطريقة أفضل من البدء بقائمة مسميات ثم محاولة اختراع مهام لكل مسمى.

اختبار سيادة لوضوح الأدوار

اختر أي نظام AI يعمل اليوم واسأل:

• من يملك حالة الاستخدام؟
• من يملك النظام؟
• من يملك بياناته؟
• من يملك مخاطره الرئيسية؟
• من يملك ضوابطه الحرجة؟
• من يستطيع الموافقة على تشغيله؟
• من يستطيع قبول مخاطره المتبقية؟
• من يستطيع منحه استثناء؟
• من يستطيع إيقافه؟
• من يراجع التغيير الجوهري؟
• من يتعامل مع الحادث؟
• من يقدم التوكيد؟
• من يُساءل إذا لم تعمل الحوكمة كما هو مطلوب؟

إذا احتاجت المؤسسة وقتًا طويلًا لمعرفة الإجابات، فالمشكلة ليست مجرد نقص في التوثيق؛ قد تكون هناك فجوة حقيقية في بنية المساءلة.

الخلاصة

حوكمة AI لا تحتاج فقط إلى أشخاص يقومون بالعمل، بل إلى بنية واضحة للمساءلة والملكية والمسؤولية والسلطة.

ويجب أن تستطيع المؤسسة الانتقال من السؤال العام:

من المسؤول عن AI؟

إلى أسئلة أكثر دقة:

من يملك هذا النظام؟ من ينفذ هذا النشاط؟ من يملك هذا الخطر؟ من يملك هذا الضابط؟ من يستطيع اتخاذ هذا القرار؟ ومن يُساءل عن النتيجة؟

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

أما النموذج الذي يعتمد على «الجميع مسؤول» أو «اللجنة مسؤولة» أو «المورد مسؤول»، فقد يبدو منظمًا على الورق بينما تظل أهم قراراته بلا مالك حقيقي.