ملخص

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

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

جعلت OpenAI من أدلة حالة 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 خلال حادث مدرج. إنها تعطي العملاء والمراجعين لغة عامة للسؤال عما إذا كان سير عمل الذكاء الاصطناعي قد تم تحديده ومراقبته وحمايته وتعافيه وتحسينه.

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

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

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

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

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

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