ملخص

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

أصبح توفر الذكاء الاصطناعي ملف عمليات

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

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

يجب قراءة السجل العام مع وضع سطح التشغيل هذا في الاعتبار. توفر صفحة حالة OpenAI علىhttps://status.openai.com/نقطة دخول عامة لسلامة الخدمة، وسجل الحوادث، وحالة المكونات، والتوفر الإجمالي. يقدم تغذية الحوادث علىhttps://status.openai.com/api/v2/incidents.jsonسجلات مؤرخة مع معرفات الحوادث، وطوابع زمنية للتحديثات، ومستويات التأثير، وتغييرات الحالة، ونصوص تحديث قصيرة. تقدم تغذية المكونات علىhttps://status.openai.com/api/v2/components.jsonطبقة أخرى من الأدلة من خلال إظهار المكونات العامة التي يختار المزود كشفها ككائنات حالة. هذه المصادر قيمة لأنها تحول حدث عمليات خاص إلى تسلسل زمني عام مؤرخ. كما أنها محدودة لأنها من تأليف المزود، وموجهة للتجميع، ومضغوطة بالضرورة.

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

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

توضح سجلات حالة عام 2026 لماذا يهم هذا التمييز. سجل 9 يوليو علىhttps://status.openai.com/incidents/01KX46HHYJ0YB8VPBZTB0KZ03Vوصف أخطاء مرتفعة عند اختيار النماذج وتضمن الرسالة المبلغ عنها بأن النموذج المحدد كان بكامل سعته. هذه ليست مجرد تسمية خطأ. بالنسبة للعميل، يمكن أن يقرر اختيار النموذج أي مسار تطبيق يعمل، ما إذا كان النموذج الاحتياطي مقبولاً، ما إذا تم الاحتفاظ بالاستجابة الآلية للمراجعة البشرية، ما إذا تمت إعادة محاولة الطلب، وما إذا كان تقرير مستوى الخدمة يعامل الحدث على أنه سعة، أو مصادقة، أو تطبيق، أو تدهور في الجودة. يساعد تحديث الحالة الذي يقول إن الخدمة قد استعادت، لكنه لا يجيب عن عدد سير عمل العملاء التي فشلت مغلقة، أو فشلت مفتوحة، أو أعيدت محاولتها، أو قبلت بصمت مسارًا أقل قيمة.

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

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

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

تُظهر التغذية العامة نمطًا من حالات التحديث القصيرة: قيد التحقيق، تم تحديدها، قيد المراقبة، وتم حلها. سجل 11 يوليو علىhttps://status.openai.com/incidents/01KX7Y6ETMKP3ATQ85Z33J0EHNيتعلق بأخطاء مرتفعة لخدمة API موجهة للفيديو وانتقل بسرعة من التحقيق إلى الاسترداد. سجل من 15 يونيو إلى 26 يونيو علىhttps://status.openai.com/incidents/01KV6NGBYE50GK3TRXHD2EMTXAيتعلق بأداء متدهور لمساحات العمل المرخصة فيدراليًا ومنظمات API. سجل 15 يونيو علىhttps://status.openai.com/incidents/01KV67B3HB2B6JKHAMHCCYS0KZيتعلق بإنشاء حساب أو تسجيل الدخول عبر مسار OAuth. سجل 11 يونيو علىhttps://status.openai.com/incidents/01KTWCER83NNKE698QXNXJG11Mيتعلق بأخطاء 431 مرتفعة. كل سجل صغير في الشكل العام. معًا تظهر مجموعة متنوعة من أنماط الفشل التي يجب على عملاء خدمات الذكاء الاصطناعي ترجمتها إلى قرارات محلية.

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

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

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

لذا فإن إرشادات حدود المعدل علىhttps://developers.openai.com/api/docs/guides/rate-limits، وإرشادات الإنتاج علىhttps://developers.openai.com/api/docs/guides/production-best-practices، وإرشادات رموز الأخطاء علىhttps://developers.openai.com/api/docs/guides/error-codesهي جزء من ملف المساءلة حتى عندما لا تكون تقارير حوادث. تصف المفردات وتوقعات التصميم من جانب العميل التي تجعل حدث الحالة قابلاً للتنفيذ. إذا كان من المتوقع أن يقوم العملاء ببناء إعادة المحاولة، والتراجع، والمراقبة، والصف، والتدهور اللطيف، والتنبيه، فإن هذه التوقعات تحتاج إلى أن تكون مرئية قبل الانقطاع. إذا قام المزود بتحديث حالة الحادث دون ربطها بضوابط العملاء هذه، يبقى السجل العام غير مكتمل لاتخاذ القرارات التشغيلية.

السعة هي سيطرة مشتركة مع رؤية غير متكافئة

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

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

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

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

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

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

استخدام القطاع العام والمؤسسات يغير عبء الإشعار

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

سجل تدهور مساحة العمل الفيدرالية في يونيو علىhttps://status.openai.com/incidents/01KV6NGBYE50GK3TRXHD2EMTXAمهم لهذا السبب. كان شكله العام قصيرًا، لكن الفئة مهمة. مساحة العمل المرخصة فيدراليًا ليست مجرد شريحة عملاء أخرى. إنها إشارة إلى أن بعض المستخدمين يحتاجون إلى أدلة تتماشى مع توقعات المشتريات، والضمان، والاستمرارية في القطاع العام. عندما يكون لبيئة متخصصة أداء متدهور لفترة ممتدة، يجب أن يدعم سجل الحالة فئة مختلفة من القراء: المسؤولين الذين يحتاجون إلى تقرير ما إذا كانوا سيبلغون الوكالات، وفرق الأمن التي تحتاج إلى الحفاظ على السجلات، ومسؤولي المشتريات الذين يحتاجون إلى توثيق أداء البائع، وأصحاب البرامج الذين يحتاجون إلى شرح انقطاع الخدمة دون الكشف عن العمل الداخلي الحساس.

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

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

تنتمي شروط العقد ومواد الضمان أيضًا إلى ملف الأدلة. يوفر بوابة الثقة لـ OpenAI علىhttps://trust.openai.com/للعملاء موقعًا للعناية الواجبة لمواد الأمان والضمان. توفر اتفاقية الخدمات علىhttps://openai.com/policies/services-agreement/السياق التعاقدي للالتزامات والحدود. لا تحل هذه المصادر محل أدلة الحوادث. إنها تساعد في تحديد العلاقة التي تُستخدم فيها أدلة الحوادث. يجب أن يعرف المشتري أي الالتزامات تعاقدية، وأيها وثائق منتج، وأيها بيانات حالة عامة، وأيها افتراضات استمرارية داخلية أنشأها تصميم سير العمل الخاص بالمشتري.

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

وقت التشغيل الإجمالي ليس دليلاً خاصًا بالعميل

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

بالنسبة للعميل، السؤال ذو الصلة ليس فقط «هل كان المزود يعمل؟» بل «هل كانت الوظيفة التي اعتمدنا عليها متاحة مع كمون مقبول، ومعدل خطأ، وجودة، وسلوك سياسة عندما كنا بحاجة إليها؟» يمكن أن يفشل سير العمل الذي يعتمد على تحميل الملفات، أو الاسترجاع، أو استمرارية المحادثة، أو اختيار النموذج، أو المصادقة، أو نقطة نهاية معينة حتى عندما تبقى أجزاء أخرى من المنصة سليمة. حادثة 23 يونيو علىhttps://status.openai.com/incidents/01KVTDW6E1PXBTY2A9XEBT4MY4تتعلق بعمليات الملفات. حادثة 19 يونيو علىhttps://status.openai.com/incidents/01KVEZD06ZFM2CMDZQMQYDV9RKتتعلق بالوصول. حادثة 17 يونيو علىhttps://status.openai.com/incidents/01KVB9JAB1PP9GS4A6AZ52TT5Yتتعلق بأخطاء المحادثة على أنظمة تشغيل الهواتف المحمولة. حادثة 10 يوليو علىhttps://status.openai.com/incidents/01KX6Y1QMFX4NASV5DD591AD50تتعلق بتوفر المساعدة ومحتوى الموقع. هذه ليست أعطالاً قابلة للتبادل.

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

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

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

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

أدلة أفضل ستربط التسلسل الزمني للمزود بإجراء العميل

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

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

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

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

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

دفاتر التشغيل المحلية تقرر ما إذا كانت الحالة العامة تصبح أدلة قابلة للاستخدام

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

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

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

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

الأدلة السلبية مهمة لأنها تمنع المراجعات اللاحقة من توسيع حادث المزود إلى مطالبة غير مدعومة حول كل عمل الذكاء الاصطناعي.

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

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

يجب اختبار الاحتياطي ضد فشل النمط المشترك

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

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

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

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

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

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

يمكن للمعايير الخارجية أن تساعد في منع تلك المراجعة من أن تصبح ضيقة جدًا. إطار إدارة مخاطر الذكاء الاصطناعي NIST علىhttps://www.nist.gov/itl/ai-risk-management-frameworkمفيد لأنه يعامل مخاطر الذكاء الاصطناعي كنظام محكوم للقياس، والإدارة، والمساءلة بدلاً من كونه خيار نموذج لمرة واحدة. إطار الأمن السيبراني NIST علىhttps://www.nist.gov/cyberframeworkمفيد لأنه يعطي مفردات الاسترداد، والاستجابة، والحوكمة، والتحديد، والحماية التي يمكن تطبيقها على اعتمادية خدمات الذكاء الاصطناعي دون التظاهر بأن انقطاع الذكاء الاصطناعي هو نفسه اختراق. هذه المعايير لا تقرر ما حدث داخل OpenAI خلال أي حادث مدرج. إنها تعطي العملاء والمدققين لغة عامة للسؤال عما إذا كانت سير عمل الذكاء الاصطناعي قد تم تحديدها، ومراقبتها، وحمايتها، واستردادها، وتحسينها.

ملف أدلة القارئ

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

أسئلة مراجعة مجلس الإدارة

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

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

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