العودة إلى المدونة

الذكاء الاصطناعي للمؤسسات مع وجود الإنسان في الحلقة: الامتثال، سجلات التدقيق، والنطاق

فريق HumanOps
١٠ فبراير ٢٠٢٦قراءة لمدة ١١ دقيقة

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

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

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

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

لماذا تحتاج المؤسسات إلى وجود الإنسان في الحلقة لوكلاء الذكاء الاصطناعي

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

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

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

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

سجلات التدقيق: ١٩ نوعاً من الأحداث لتتبع كامل

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

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

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

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

التحكم في الوصول القائم على الأدوار: ٤ أدوار، ٩ أذونات

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

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

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

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

رؤوس الأمان وتحصين البنية التحتية

لا تقيم تقييمات أمان المؤسسات الضوابط على مستوى التطبيق فحسب، بل تقيم أيضاً وضع الأمان على مستوى البنية التحتية. تطبق HumanOps مجموعة شاملة من رؤوس الأمان التي تلبي توقعات فرق أمان المؤسسات ومختبري الاختراق. يتضمن كل استجابة API رؤوس HTTP Strict Transport Security مع حد أقصى للعمر يبلغ عاماً واحداً، مما يضمن استخدام المتصفحات وعملاء API دائماً لاتصالات مشفرة. تقيد رؤوس Content Security Policy المصادر التي يمكن للتطبيق تحميل البرامج النصية والأنماط والموارد الأخرى منها، مما يمنع هجمات حقن البرامج النصية عبر المواقع حتى لو تم اكتشاف ثغرة في كود التطبيق.

تمنع رؤوس X-Frame-Options واجهة HumanOps من تضمينها في إطارات (iframes) على مواقع ضارة، مما يمنع هجمات اختطاف النقرات (clickjacking). تمنع رؤوس X-Content-Type-Options المتصفحات من تخمين نوع MIME لمحتوى الاستجابة، مما يغلق فئة من ثغرات حقن المحتوى. تتحكم رؤوس Referrer-Policy في مقدار معلومات الإحالة التي يتم تضمينها عند التنقل بعيداً عن صفحات HumanOps، مما يحمي معاملات URL الحساسة من التسرب إلى مواقع الطرف الثالث. تعطل رؤوس Permissions-Policy الوصول إلى ميزات الجهاز مثل الكاميرا والميكروفون وAPI الموقع الجغرافي من السياقات المضمنة، مما يقلل من سطح الهجوم للاستغلال المحتمل.

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

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

إدارة دورة حياة مفتاح API

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

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

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

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

أمان خطافات الويب (Webhooks): تسليم الأحداث بتوقيع HMAC

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

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

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

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

الامتثال المالي: دفتر أستاذ مزدوج القيد

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

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

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

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

لماذا تفشل منصات المستهلكين في تلبية متطلبات المؤسسات

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

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

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

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

البدء مع HITL للمؤسسات

إذا كانت مؤسستك تقيم منصات وجود الإنسان في الحلقة لنشر وكلاء الذكاء الاصطناعي، فإن وثائق HumanOps توفر مواصفات تقنية مفصلة لكل ميزة ذات صلة بالامتثال موصوفة في هذه المقالة. تتضمن وثائق API تعريفات كاملة للمخططات (schemas) لأحداث التدقيق، وأذونات RBAC، وحمولات خطافات الويب، وأنواع معاملات دفتر الأستاذ.

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

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

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