Yuri Gubin، الرئيس التقني في DataArt – سلسلة المقابلات

Yuri Gubin، الرئيس التقني في DataArt هو مدير تنفيذي مخضرم في مجال التكنولوجيا ومهندس برمجيات قضى أكثر من 18 عامًا مع DataArt، وتدرج في أدوار تشمل هندسة البرمجيات، هندسة الحلول، تكنولوجيا السحابة، الابتكار، والقيادة التنفيذية قبل أن يصبح الرئيس التقني في مارس 2026. ركز عمله على حل تحديات تقنية معقدة عبر صناعات تشمل الخدمات المالية، الرعاية الصحية، السفر، وإنترنت الأشياء، مع خبرة خاصة في الحوسبة السحابية، الذكاء الاصطناعي، منصات البيانات، وهندسة برمجيات المؤسسات. قبل توليه منصب الرئيس التقني، شغل غوبين أكثر من خمس سنوات منصب كبير موظفي الابتكار في DataArt وكان عضوًا في مجلس الشركاء بالشركة منذ عام 2021. وهو أيضًا عضو محترف في مجلس Forbes Technology Council، مشاركًا في مجموعات الخبراء للذكاء الاصطناعي والحوسبة السحابية، ويعمل كمستشار تقني لمنظمة Girls Who Code، حيث يقدم المشورة بشأن الهندسة، حماية البيانات، حوكمة المنصات، وسياسة التكنولوجيا. تُدرج DataArt حاليًا اسمه كرئيس تقني مقره في نيويورك.

DataArt هي شركة عالمية لهندسة البرمجيات وتحويل البيانات والذكاء الاصطناعي تأسست في نيويورك عام 1997. نمت الشركة لتضم أكثر من 6,000 محترف تقني يعملون عبر أكثر من 20 دولة وتتعامل مع أكثر من 400 عميل، مقدمة خدمات في مجالات تشمل الذكاء الاصطناعي وتعلم الآلة، البيانات والتحليلات، التحول السحابي، هندسة البرمجيات المخصصة، الأمن السيبراني، وتحديث الأنظمة القديمة. تعمل DataArt عبر قطاعات مثل الخدمات المالية، الرعاية الصحية وعلوم الحياة، السفر، الإعلام والترفيه، والتجزئة، وتحافظ على شراكات تقنية مع منصات تشمل AWS، Google Cloud، Microsoft Azure، Snowflake، وDatabricks. في عام 2025، أعلنت الشركة عن استثمار بقيمة $100 million على مدى ثلاث سنوات في قدراتها في البيانات والذكاء الاصطناعي، وتلت ذلك في عام 2026 إطلاق Artisyn، نموذج تشغيل مدعوم بالذكاء الاصطناعي صُمم لدمج وكلاء الذكاء الاصطناعي، مسرعات قابلة لإعادة الاستخدام، الحوكمة، الأمن، والامتثال في تطوير برمجيات المؤسسات.

قضيت ما يقرب من عقدين من الزمن في DataArt، وتدرجت من مهندس برمجيات ومهندس حلول إلى كبير موظفي الابتكار والآن الرئيس التقني. كيف شكلت هذه الرحلة طريقتك في التمييز بين التقنيات التحويلية الحقيقية ودورات الضجيج، وكيف تؤثر على “التفاؤل المتشائم” تجاه الذكاء الاصطناعي اليوم؟

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

لذا أعتقد أنه يجب أن يكون جهدًا متزامنًا على مستوى المشروع، وربما على مستوى البرنامج، ثم على مستوى الأقسام والمؤسسات أيضًا.

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

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

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

إذن نعم، أعتقد أن FinOps للذكاء الاصطناعي هو موضوع جيد لفريق SWAT مكافئ للذكاء الاصطناعي لمناقشته: كم تنفق، ومقدار ما تستعيده، وكيف تتحكم فيه، وأين الفرص.

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

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

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

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

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

قامت DataArt بدمج الذكاء الاصطناعي عبر دورة حياة تسليم البرمجيات من خلال مبادرات مثل Artisyn. مع تولي الذكاء الاصطناعي المزيد من مهام التنفيذ والاختبار وسير العمل، أي أجزاء من هندسة البرمجيات تصبح أكثر قيمة للبشر، وأي مهارات قد تصبح أقل أهمية؟

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

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

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

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

لقد رأيت مطوري .NET يتحولون إلى مطوري Java بسرعة كبيرة، ومنذ خمس أو عشر سنوات كنت سأقول إن القيام بذلك على نطاق واسع كان شبه مستحيل. اليوم، يمكنك ذلك. يمكن للمطور الكبير القوي أن ينتقل بين اللغات بشكل متزايد لأن ما يهم حقًا هو فهمه للتقنية، والهندسة، وممارسات الحل المثلى، وSDLC وADLC.

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

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

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

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

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

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

شكرًا على المقابلة الرائعة، القراء الذين يرغبون في معرفة المزيد يجب أن يزوروا DataArt.