شون بلانشفيلد، المؤسس المشارك والرئيس التنفيذي لشركة جينتيك - سلسلة مقابلات

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

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

لقد أسستَ وقُدتَ العديد من شركات التكنولوجيا، بدءًا من DemonWare (التي استحوذت عليها Activision Blizzard) ووصولًا إلى PageFair والآن Jentic، كما أنك عضو في المجلس الاستشاري للذكاء الاصطناعي في أيرلندا. ما الذي دفعك للعودة إلى بناء البنية التحتية مع Jentic، وما هي الثغرة التي لاحظتها في بيئة الذكاء الاصطناعي الناشئة والتي أغفلها الآخرون؟

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

عندما بدأت شركة Jentic في عام 2024، هل كان أمن الوكلاء هو الفكرة الأساسية منذ اليوم الأول، أم أن التركيز ازداد حدة عندما لاحظت كيف كانت المؤسسات تقوم بالفعل بنشر الوكلاء المستقلين في بيئة الإنتاج؟

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

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

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

لقد تحدثتَ عن فصل التنسيق عن التنفيذ للحد من نطاق التأثير. هل يمكنك شرح ذلك عمليًا وكيف يُغيّر هذا الفصل مستوى المخاطر عند اختراق النظام؟

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

في عمليات النشر المؤسسية الواقعية، كيف تبدو إدارة بيانات الاعتماد المركزية والإلغاء الفوري في الواقع، وكيف تختلف عن الطريقة التي تتعامل بها معظم الفرق حاليًا مع مفاتيح API والرموز المميزة للوكلاء؟

اليوم، لدى معظم الفرق مطوّر يقوم بتوفير مفاتيح واجهة برمجة التطبيقات (API)، وتخزينها في ملف ‎.env، وتحميلها عند بدء تشغيل الوكيل - غالبًا مباشرةً في نافذة سياق LLM. لا أحد لديه صورة كاملة عن الوكلاء الذين يمتلكون بيانات الاعتماد. عند مغادرة أحد الوكلاء، لا يتم استبدال المفاتيح التي قام بتوفيرها. وعندما يتصرف وكيل بشكل غريب، لا يوجد سجل تدقيق لإعادة بناء ما حدث. مع Jentic، لا يتعامل المطوّر أبدًا مع بيانات الاعتماد الخام. فهو يُحدد الوصول الذي يحتاجه الوكيل، وتُوفر المنصة وصولًا مُحدد النطاق، ويستدعي الوكيل من خلال طبقة التنفيذ الخاصة بنا دون رؤية المفتاح الأساسي. هذا يعني أنك تحصل على إلغاء فوري لكل وكيل، والقدرة على إيقاف الوصول مؤقتًا أثناء التحقيق، وسجل تدقيق مُؤرخ لكل استدعاء لواجهة برمجة التطبيقات. الفرق بين ذلك و"مفتاح واجهة برمجة التطبيقات في .ملف البيئة "env file" كبير.

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

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

تُقدّم جينتيك نفسها كطبقة تنفيذ مُدارة تتوسط بين أُطر عمل الوكلاء والأنظمة الخارجية. كيف تُطبّق هذه الطبقة الوسيطة الحوكمة دون إبطاء عمل المُطورين أو تقليل مرونة الوكلاء؟

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

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

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

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

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

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