AWS Certified AI Practitioner
استراتيجيات حوكمة بيانات الذكاء الاصطناعي
كيف تحكم البيانات التي يقوم عليها نظام الذكاء الاصطناعي طوال عمرها: مدد احتفاظ تحذف فعلاً، وحدود جغرافية تصمد أمام الاستدلال عبر المناطق، وتسجيل ومراقبة تجعل الحوكمة قابلة للإثبات.
- التمييز بين حوكمة البيانات وأمان البيانات، وتسمية السؤال الذي يجيب عنه كل منهما
- تتبّع مراحل دورة حياة البيانات وتحديد المواضع التي ينشئ فيها الذكاء الاصطناعي نسخاً إضافية
- ضبط مدد الاحتفاظ عن قصد في S3 وCloudWatch Logs وAWS CloudTrail
- شرح أثر الاستدلال عبر المناطق في Amazon Bedrock على الموقع الجغرافي للبيانات
- المقارنة بين سجلات CloudTrail وسجلات استدعاء النماذج في Amazon Bedrock
- وصف ممارسات المراقبة والملاحظة التي تُبقي نظاماً منشوراً داخل حدود سياسته
يراسل عميل فريق الدعم طالباً حذف بياناته. تعرف مكانها بدقة: جدول customers في S3. تحذف الصفوف وترد عليه بأن الأمر تمّ.
بعد ستة أسابيع، تُعدّ مراجعة قانونية قائمة بالمواضع التي كانت بيانات ذلك العميل فيها فعلاً يوم وصول الطلب. التصدير الخام في منطقة الهبوط. الجدول المهيّأ الذي طالته عملية الحذف. مقاطع قاعدة المعرفة المبنية من تذاكر دعمه، ما زالت في مخزن المتجهات على شكل embeddings. مجموعة سجلات في CloudWatch تحمل كل مطالبة ورد من المساعد، وفيها ثلاث محادثات لصق فيها موظف سجل الحساب كاملاً داخل المطالبة. ملف CSV سحبه عالِم بيانات إلى دفتر ملاحظات في مارس. ونموذج مضبوط دقيقاً قرأ ذلك كله أثناء التدريب.
حذفت نسخة واحدة من ست، وأبلغت العميل بأن المهمة انتهت.
لا شيء هنا كان عطلاً أمنياً. كل حاوية مشفّرة، وكل دور محدود الصلاحية، وكل مسار شبكي خاص. الناقص هو النصف الآخر: مجموعة قواعد تقول كم يجوز أن تعيش كل نسخة، وأين يُسمح لها أن تقيم، وفيمَ يجوز استخدامها، ومن يقرر. هذه هي حوكمة البيانات، ويسمّيها دليل الاختبار بست كلمات مباشرة: دورات حياة البيانات، والتسجيل، والموقع الجغرافي، والمراقبة، والملاحظة، والاحتفاظ.
الحوكمة كتاب القواعد، والأمان قفل الباب
افصل بينهما، لأنهما يفشلان بطريقتين مختلفتين.
الأمان يسأل: هل يستطيع طرف غير مصرّح له الوصول إلى هذه البيانات؟ ويجيب بـ IAM والتشفير وعزل الشبكة وكشف التهديدات. والموضوع السابق كان أمناً في معظمه.
الحوكمة تسأل: تحت أي قواعد تعيش هذه البيانات، أياً كان من يصل إليها؟ كم يجوز أن نحتفظ بها، وأي دول يجوز أن تعالجها، ولأي أغراض هي معتمدة، ومن يوقّع على استخدام جديد، وكيف نثبت أياً من ذلك لاحقاً.
مجموعة بيانات مؤمّنة تماماً قد تظل إخفاقاً حوكمياً. لم يخترق أحد مجموعة السجلات في القصة أعلاه. كانت مصرّحاً بها ومشفّرة ومحفوظة إلى الأبد لأن أحداً لم يضبط رقماً. القفل عمل، وكتاب القواعد لم يكن موجوداً.
وهذا التمييز نفسه هو سبب اختلاف نبرة أسئلة الحوكمة عن أسئلة الأمان في الاختبار. أسئلة الأمان تقول "امنع الوصول". وأسئلة الحوكمة تقول "يجب ألا يُحتفظ بها أكثر من"، و"يجب أن تبقى داخل"، و"يجب أن نكون قادرين على إثبات".
دورة الحياة، وأين يضاعفها الذكاء الاصطناعي
كل مجموعة بيانات تمرّ بالمراحل نفسها: تُنشأ أو تُقتنى، ثم تُخزَّن، ثم تُستخدم، ثم تُؤرشَف، ثم تُتلَف. والتطبيقات التقليدية تُبقي هذا المسار ضيقاً: قاعدة بيانات واحدة، ونسخة احتياطية، وأرشيف.
أنظمة الذكاء الاصطناعي تنشره. تذكرة دعم واحدة تسلك هذا الطريق:
- تهبط نصاً خاماً في منطقة هبوط على S3.
- تُحجب بياناتها الحساسة وتُكتب في جدول مهيّأ داخل حاوية ثانية.
- تُقطَّع وتُحوَّل إلى embeddings في مخزن متجهات للاسترجاع.
- تدخل ضمن مجموعة الضبط الدقيق، فيؤثر محتواها في أوزان النموذج.
- تظهر داخل مطالبة وقت الاستدلال، فتهبط المطالبة والرد في سجل.
- تُسحب إلى مجموعة تقييم لمراجعة جودة.
ستة مواضع من سجل واحد، بمُلّاك مختلفين وخدمات تخزين مختلفة وأعمار طبيعية مختلفة. والسؤال الحوكمي ليس "هل لدينا سياسة احتفاظ"، بل "هل تسمّي السياسة المواضع الستة".
وواحد من هذه الستة يختلف عن البقية، وهو الذي يُنسى. المواضع 1 إلى 3 و5 و6 تحمل بيانات تستطيع حذفها. أما الموضع 4 فلا: ما تعلّمه النموذج أثناء الضبط الدقيق لا يُزال بحذف ملف. ولهذا فإن ضوابط ما قبل الابتلاع من الموضوع السابق هي ضوابط حوكمة أيضاً. كل ما ترفض التدريب عليه نسخة لن تضطر إلى تفسيرها لاحقاً.
الاحتفاظ: الإعداد الذي قيمته الافتراضية "إلى الأبد"
الاحتفاظ هو النقطة التي تلتقي فيها السياسة المكتوبة بقيمة إعداد حقيقية، والقيم الافتراضية قلّما تطابق ما تقوله سياستك.
| المخزن | الاحتفاظ الافتراضي | كيف تغيّره |
|---|---|---|
| كائنات Amazon S3 | تبقى حتى تُحذف | قاعدة S3 Lifecycle بإجراءات انتقال وانتهاء صلاحية |
| Amazon CloudWatch Logs | لا تنتهي صلاحيتها أبداً | إعداد الاحتفاظ على مجموعة السجلات |
| سجل أحداث CloudTrail | 90 يوماً من أحداث الإدارة، ثابتة | غير قابل للتعديل؛ أنشئ trail أو event data store لمدة أطول |
| trail من CloudTrail إلى S3 | يبقى حتى يُحذف | قاعدة S3 Lifecycle على حاوية الوجهة |
| CloudTrail Lake event data store | حتى نحو 10 سنوات بحسب خيار التسعير | مدة الاحتفاظ على الـ event data store |
أعد قراءة صف CloudWatch Logs. بيانات السجلات تُخزَّن افتراضياً إلى أجل غير مسمى. بالنسبة إلى سجل تطبيق عادي، هذه مشكلة تكلفة. أما تطبيق ذكاء اصطناعي فعّل تسجيل استدعاء النماذج، فمجموعة السجلات لديه تحوي نصوص الطلبات والردود كاملة، ما يعني أنها مخزن دائم لكل ما كتبه المستخدمون في النموذج وكل ما قاله النموذج لهم. حساسيتها حساسية المحادثة نفسها لا حساسية سجل عادي.
وخطة احتفاظ مطبَّقة على مساعد داخلي واحد تبدو هكذا:
| البيانات | السياسة | الآلية |
|---|---|---|
| تصديرات الدعم الخام | 90 يوماً في منطقة الهبوط | انتهاء صلاحية S3 Lifecycle عند 90 يوماً |
| مجموعة التدريب المهيّأة | 3 سنوات، غير قابلة للتعديل | حاوية بـ versioning وObject Lock، بلا انتهاء صلاحية |
| مقاطع مخزن المتجهات | يُعاد بناؤها أسبوعياً من المصدر المهيّأ | مهمة إعادة ابتلاع، لا قاعدة احتفاظ |
| سجلات المطالبات والردود | 30 يوماً | ضبط احتفاظ CloudWatch Logs على 30 يوماً لتلك المجموعة |
| نشاط الواجهات في CloudTrail | 7 سنوات | trail إلى S3، وانتقال إلى Glacier عند 90 يوماً، وانتهاء صلاحية عند 7 سنوات |
| مجموعات التقييم | سنة بعد تقاعد النموذج | مراجعة يدوية، متتبَّعة في فهرس البيانات |
لاحظ أن "احذف بعد N يوماً" و"احتفظ N سنوات" يستعملان الأداة نفسها من اتجاهين متعاكسين، وأن صفّين من الستة ليسا قاعدة دورة حياة أصلاً. الحوكمة ليست خاصية واحدة.
وتصحيح واحد يستحق التصريح لأنه افتراض شائع: ضبط مدة احتفاظ أقصر لا يزيل البيانات فوراً. يضع CloudWatch الأحداث المنتهية في قائمة الحذف ويكمل العملية عادة خلال 72 ساعة. فإن كانت السياسة تطلب حذفاً قابلاً للإثبات قبل موعد محدد، ابنِ الموعد على هذا الأساس.
الموقع الجغرافي: أين يُسمح للبيانات أن تكون
الموقع الجغرافي للبيانات (data residency) هو اشتراط تخزينها، ومعالجتها غالباً، داخل نطاق جغرافي مسمّى. يظهر في العمل المصرفي والرعاية الصحية والقطاع الحكومي، وتجيب عنه AWS أساساً باختيار المنطقة: تختار المنطقة، فتبقى بياناتك فيها ما لم تنقلها.
ويضيف الذكاء الاصطناعي التوليدي التواءة يحبها الاختبار، لأنها الموضع الوحيد الذي قد تعالج فيه خدمة من AWS طلبك في منطقة لم تسمّها أنت.
الاستدلال عبر المناطق في Amazon Bedrock يوجّه طلب الاستدلال إلى أي منطقة في المجموعة لديها سعة، فيرفع الإنتاجية ويستوعب موجات الطلب. وله نوعان من الملفات، واحد منهما فقط يحترم حداً جغرافياً:
| ملف استدلال جغرافي | ملف استدلال عالمي | |
|---|---|---|
| أين يجوز أن تُعالَج الطلبات | داخل النطاق المذكور، مثل US أو EU أو APAC | أي منطقة تجارية مدعومة في AWS حول العالم |
| الإنتاجية | أعلى من منطقة واحدة | الأعلى المتاحة |
| التكلفة | التسعير القياسي | أقل بنحو 10 بالمئة |
| يناسب | متطلبات الموقع الجغرافي للبيانات | أولويات التكلفة والأداء بلا قيد جغرافي |
وتقول AWS التوصية صراحة: اختر الجغرافي عند وجود متطلبات موقع جغرافي، والعالمي حين تريد أقصى إنتاجية وتوفيراً في التكلفة بلا قيود جغرافية.
وثلاث تفاصيل تُبقي هذا صادقاً. الاستدلال عبر المناطق قد يوجّه الطلبات إلى مناطق لم تفعّلها يدوياً في حسابك، فجملة "نحن لم نفعّل تلك المنطقة أصلاً" ليست ضابطاً. وكل حركة البيانات تبقى على شبكة AWS ومشفّرة أثناء النقل، فالمسألة مسألة ولاية قضائية لا مسألة انكشاف. وكل طلب عبر المناطق يُسجَّل في CloudTrail في منطقة المصدر، ومعه حقل additionalEventData.inferenceRegion يسمّي المنطقة التي عولج فيها فعلاً، وبه تدقّق الموقع الجغرافي لاحقاً بدل افتراضه.
وإن احتاجت مؤسستك أن يكون الحدّ مفروضاً لا مختاراً، فذلك service control policy على aws:RequestedRegion على مستوى AWS Organizations، فوق ما يضبطه أي فريق منفرد.
التسجيل: سجلّان لاستدعاء واحد
في خدمة عادية من AWS، "فعّل التسجيل" تعني شيئاً واحداً. وفي استدعاء ذكاء اصطناعي توليدي تعني شيئين يلتقطان نصفين مختلفين.
| AWS CloudTrail | تسجيل استدعاء النماذج في Bedrock | |
|---|---|---|
| يسجّل | الاستدعاء: من ومتى وأي إجراء ومن أين | المحتوى: نص الطلب والرد كاملاً، ومعرّف النموذج، وعدد الـ tokens |
| حالته | مفعّل افتراضياً لأحداث الإدارة في سجل الأحداث | معطّل افتراضياً؛ تفعّله لكل منطقة |
| الوجهة | سجل الأحداث، أو trail إلى S3، أو CloudTrail Lake | Amazon S3، أو CloudWatch Logs، أو كلاهما |
| يجيب عن | "أي هوية استدعت InvokeModel عند 02:14؟" | "ماذا قالت تلك المطالبة فعلاً؟" |
| الحساسية | بيانات وصفية عن النشاط | بحساسية المحادثة نفسها |
والنتيجة الحوكمية للصف الأخير هي ما تحتفظ به. تفعيل تسجيل الاستدعاء قرار صحيح للتدقيق والتحقيق في الحوادث، وهو في الوقت نفسه ينشئ مخزناً جديداً لأكثر نصوصك حساسية. يحتاج المعاملة نفسها التي تعطيها للبيانات المصدر: مفتاح KMS، وسياسة وصول ضيقة، وإعداد احتفاظ، وموضع في خريطة الحذف لديك. تفعّله فرق كثيرة لغرض الامتثال، ثم تسقط في فحص امتثال آخر بسبب السجلات التي أنشأتها.
المراقبة والملاحظة
يذكر دليل الاختبار المراقبة والملاحظة كلمتين منفصلتين، والفصل مفيد وإن كان الحدّ بينهما ليّناً.
المراقبة قائمة على عتبات وآلية. تعرّف شكل الخطأ رقماً، فينبّهك شيء عند حدوثه. وفي حمل عمل ذكاء اصطناعي: معدلات أخطاء الاستدعاء والتقييد في CloudWatch، وعدد تدخّلات الـ guardrails، والتكلفة لكل ألف استدعاء، وزمن الاستجابة عند المئين 99، وقاعدة Config تنتقل إلى حالة عدم امتثال حين يعطّل أحدهم تسجيل استدعاء النماذج.
الملاحظة نظر مستمر إلى ما يفعله النظام فعلاً، بما فيه أشياء لم تكتب لها عتبة أصلاً. انحراف البيانات وانحراف جودة النموذج عبر SageMaker Model Monitor، ومقاييس التحيّز محسوبة من جديد على حركة حقيقية عبر SageMaker Clarify، ومراجعة بشرية لعيّنة من المخرجات، وقراءة دورية للمطالبات التي يرسلها المستخدمون بالفعل. الملاحظة هي الطريق الذي تكتشف به أن المساعد يُستعمل لغرض لم يصممه أحد، وهو اكتشاف حوكمي لم يُضبط له أي تنبيه.
والاثنان مهمان لسبب خاص بالذكاء الاصطناعي: نظام الذكاء الاصطناعي لا يفشل فشلاً نظيفاً. خادم ويب معطوب يعيد رمز 500. والنموذج المنحرف يعيد إجابات فصيحة ومتماسكة ومقنعة تزداد سوءاً. ومراقبة التوافر لن تلاحظ ذلك.
الجزء الذي ليس خدمة
عنصران حوكميان لا كونسول لهما في AWS، وكلاهما يأتي أولاً.
التصنيف يضع كل مجموعة بيانات في فئة (عامة، داخلية، سرّية، مقيّدة مثلاً) ويعلّق القواعد على الفئة لا على الحاويات فرادى. متطلبات التشفير، والمناطق المعتمدة، ومدد الاحتفاظ، وجواز استخدام الفئة في تدريب النماذج، كلها تتدلى من ذلك الوسم الواحد. وبدونه، تبدأ كل مجموعة بيانات جديدة النقاش من الصفر.
الملكية تسمّي إنساناً مسؤولاً عن كل مجموعة بيانات. مالك البيانات يصنّفها، ويعتمد طلبات الوصول، ويعتمد الاستخدامات الجديدة، ومنها "هل يجوز أن نضبط النموذج دقيقاً على هذه؟". وتعطيك AWS الأدوات لتسجيل تلك القرارات وفرضها، عبر الوسوم وGlue Data Catalog وصلاحيات Lake Formation. ولا تستطيع أن تتخذها عنك.
والوسم هو موضع لقاء الاثنين بالآلية. وسم متسق مثل DataClassification=Restricted على الحاويات ومجموعات السجلات ومهام التدريب هو ما يتيح لقاعدة Config أن تفحص الامتثال بحسب فئة السياسة بدل اسم المورد، وما يتيح لتقارير التكلفة والوصول أن تُفصَّل بحسب درجة الحساسية.
نصائح للاختبار
- "حوكمة البيانات" في نص السؤال تشير إلى قواعد فوق البيانات (احتفاظ، موقع جغرافي، غرض، ملكية) لا إلى ضوابط الوصول. وإن قال السيناريو "امنع الوصول غير المصرّح به" فأنت في الأمان.
- احتفاظ CloudWatch Logs الافتراضي هو "لا ينتهي أبداً". هذه الحقيقة وحدها تجيب عن عدة أشكال من الأسئلة عن سجلات تنمو بلا حدّ أو تتجاوز موعد سياسة.
- سجل أحداث CloudTrail هو 90 يوماً من أحداث الإدارة وغير قابل للتعديل. والمدة الأطول تعني trail إلى S3 أو CloudTrail Lake event data store.
- قواعد S3 Lifecycle هي آلية نقل البيانات إلى تخزين أرخص وحذفها وفق جدول معاً.
- "يجب أن تبقى البيانات داخل الاتحاد الأوروبي" مع Amazon Bedrock تعني ملف استدلال جغرافياً عبر المناطق، لا عالمياً.
- CloudTrail يسجّل الاستدعاء، وتسجيل استدعاء النماذج في Bedrock يسجّل المحتوى. والسؤال عمّا ورد داخل مطالبة يحتاج الثاني، وهو معطّل افتراضياً.
- الانحراف وإعادة حساب التحيّز والمراجعة البشرية للعيّنات ملاحظة. والتنبيهات والعتبات مراقبة.
القاعدة التي تحتفظ بها: الحوكمة هي مجموعة القرارات التي يجب أن توجد قبل أن يكون لدى الضابط ما يفرضه. مدد الاحتفاظ والحدود الجغرافية والتصنيفات والمُلّاك مدخلات، وكل خدمة في الدرس الأخير من هذا الموضوع لا تفعل سوى فحص مطابقة الواقع لها. والدرس التالي يتناول من أين تأتي تلك القرارات أصلاً، بدءاً من الإطار الذي تسمّيه AWS لتحديد نطاق حالة استخدام توليدية.
