مع الانتشار السريع لأدوات الترميز المعتمدة على الذكاء الاصطناعي، مثل GitHub Copilot وAmazon CodeWhisperer وغيرها، تواجه المؤسسات الكبيرة معضلة حقيقية: كيف تمنح المطورين هذه الأدوات القوية دون أن تفتح الباب لثغرات أمنية أو انتهاكات للسياسات الداخلية؟ هذا السؤال كان محور حديث أنكيت ماثور (Ankit Mathur) من شركة Databricks في جلسة ضمن مؤتمر AI Dev 26 x SF. ماثور استعرض التجربة الفعلية لشركته التي تضم أكثر من 10,000 موظف، وكيف تمكنوا من تحقيق التوازن بين السرعة والابتكار من جهة، والحوكمة والأمان من جهة أخرى، عبر منتج أطلقوا عليه اسم Coding Tool Gateway.
لماذا تحتاج المؤسسات إلى بوابة لأدوات الترميز؟
عادةً ما يكون لكل فريق تطوير في الشركات الكبيرة تفضيلاته الخاصة من أدوات المساعدة البرمجية. بعض المطورين يريدون Copilot، وآخرون يفضلون Tabnine، وهناك من يجرب أدوات مفتوحة المصدر. لكن عندما يُترك الاختيار بالكامل للمطورين دون رقابة مركزية، تظهر مشاكل: تسرب الكود الحساس إلى خوادم خارجية، استخدام أدوات غير مرخصة، أو عدم الامتثال لسياسات حماية البيانات (مثل GDPR أو معايير الصناعة).
هنا يأتي دور Coding Tool Gateway. بحسب ماثور، هذا المنتج ليس أداة ترميز بحد ذاتها، بل طبقة وسيطة (middleware) تُوضع بين المطورين وأدوات الترميز الخارجية. تتيح البوابة للمطورين اختيار أي أداة يريدونها، بينما تمنح المسؤولين (Admins) تحكماً مركزياً في السياسات، مثل تصفية الأكواد الحساسة، تسجيل الاستخدام، ومنع رفع البيانات إلى خوادم غير معتمدة. بمعنى آخر، إنها تشبه “بوابة API” لكن لأدوات مساعدة الترميز.
كيف تعمل البوابة داخل Databricks؟
ماثور شرح أنهم طبقوا هذا النموذج على نطاق آلاف المطورين داخل الشركة. تسمح البوابة لكل مطور باستخدام أداة الترميز التي تناسبه، لكن جميع الطلبات (requests) تمر عبر البوابة أولاً. تقوم البوابة بفحص المحتوى، وتطبق قواعد الحوكمة (مثل منع إرسال أجزاء من كود الإنتاج الحساس إلى خدمات سحابية غير مصرح بها)، ثم توجّه الطلب إلى الأداة المناسبة. هذا التصميم يحقق أمرين: المطور يحافظ على تجربته المفضلة، والشركة تحافظ على السيطرة الأمنية.
الأثر العملي الذي أشار إليه ماثور هو أن التبني الداخلي لأدوات الترميز زاد بشكل كبير لأن المطورين لم يشعروا بأنهم مقيدون، وفي الوقت نفسه انخفضت حوادث تسرب البيانات المرتبطة بأدوات الترميز. هذا التوجه يتماشى مع احتياج المؤسسات الكبيرة إلى تحقيق “تمكين آمن” (Secure Enablement) بدلاً من المنع القاطع.
ماذا يعني هذا للمؤسسات العربية؟
هذه التجربة تقدم درساً عملياً لأي شركة أو هيئة في المنطقة العربية تتجه نحو اعتماد الذكاء الاصطناعي في التطوير. بدلاً من حظر أدوات الترميز خوفاً من المخاطر، أو ترك الأمور دون ضوابط، يمكن بناء طبقة حوكمة وسطى. الحل لا يحتاج بالضرورة إلى بناء منتج معقد مثل Coding Tool Gateway، بل يمكن تطوير سياسات داخلية واعتماد أدوات وسيطة جاهزة (مثل بعض حلول الحوكمة السحابية) لإدارة التدفق.
النقطة الأهم التي يجب ملاحظتها هي أن هذه البوابة لا تتعارض مع سرعة التطوير؛ على العكس فهي تعززها عبر إزالة الخوف لدى الإدارة. كما أن ماثور أكد أن الحوكمة يجب ألا تكون عائقاً، بل وسيلة لتمكين الابتكار بثقة. بالنسبة لمدراء تقنية المعلومات في المؤسسات العربية، فإن الاستثمار في حوكمة أدوات الترميز قد يكون أكثر جدوى من شراء تراخيص إضافية لمجرد ‘الاستكشاف’ دون رقابة.
خلاصة عملية
في عالم التطوير الحديث، لم يعد خيار “منع أو سماح” كافياً. نموذج البوابة المركزية الذي قدمته Databricks يُظهر أن المؤسسات يمكنها أن تأكل الكعكة وتدخرها: تمكين المطورين بأحدث أدوات الذكاء الاصطناعي، مع الحفاظ على الأمان والامتثال. إذا كانت مؤسستك تخطط لنشر أدوات الترميز على نطاق واسع، فكر أولاً في كيفية بناء طبقة حوكمة مرنة – فربما سرعة الابتكار تحتاج فقط إلى باب خلفي ذكي، لا إلى باب مغلق.
مصدر المقطع
نشر المقطع على قناة DeepLearningAI في YouTube، وتم اختياره لأنه حديث ومرتبط بموضوعات عليها طلب في الذكاء الاصطناعي.