الذكاء الاصطناعي الوكيلي يلتقي بتطوير قواعد البيانات: ما الذي يتغير عندما يصبح الذكاء الاصطناعي قادرًا فعلًا على تنفيذ الاستعلامات؟

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

حافظ سير العمل هذا على حدٍّ فاصل مهم: يمكن للذكاء الاصطناعي اقتراح إجراء، لكن الإنسان هو من يقرر ما إذا كان سيُنفّذ على قاعدة البيانات.

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

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

من الاقتراحات إلى الإجراءات

يوضح قرار بسيط بشأن الفهرسة سبب أهمية هذا التحول.

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

قد ينفّذ أمرًا عاديًا مثل:

CREATE INDEX IX_Orders_CustomerId
ON Orders(CustomerId);

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

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

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

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

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

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

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

ما المهام التي يمكن تفويضها بأمان؟

تكون بعض مهام قواعد البيانات أكثر أمانًا بكثير من غيرها عند إسنادها إلى وكيل.

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

قد يلاحظ مرارًا استعلامًا كهذا يفحص جدولًا كبيرًا Orders جدولًا:

SELECT OrderId, OrderDate, Total
FROM Orders
WHERE CustomerId = @CustomerId
ORDER BY OrderDate DESC;

ومن هناك، يمكنه شرح سبب الفحص، واقتراح فهرس، وإنشاء DDL. ولا يحتاج إلى إذن لتنفيذ CREATE INDEX كي يكون مفيدًا.

وينطبق الأمر نفسه على مهام مثل:

• وصف خطط التنفيذ؛
• تحديد الفهارس المفقودة أو غير الضرورية؛
• رصد SELECT * الاستعلامات أو شروط التصفية غير القابلة للاستفادة من الفهارس؛
• مراجعة دفع عمليات الربط والتصفية إلى مراحل مبكرة؛
• مراجعة التبعيات والمخططات؛
• استكشاف أخطاء SQL وإصلاحها؛
• تحسين نصوص SQL البرمجية.

التقسيم العملي بسيط: امنح الوكيل صلاحية كافية لفهم المشكلة، لكن لا تمنحه تلقائيًا صلاحية كافية لتغيير قاعدة البيانات. قد يكون الاطلاع الواسع مفيدًا، لكن منح صلاحيات تنفيذ واسعة قرار مختلف.

متى تظل الرقابة البشرية مهمة؟

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

DELETE FROM AuditLog
WHERE CreatedAt < DATEADD(year, -2, GETDATE());

قد تكون صيغة SQL صحيحة تمامًا، ومع ذلك يظل القرار سيئًا للغاية.

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

ولا يلزم أن تكون أي من هذه المتطلبات موجودة في المخطط.

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

• DROP والتدميرية ALTER العبارات؛
• الإنتاج UPDATE و DELETE العمليات؛
• عمليات ترحيل البيانات الكبيرة؛
• تغييرات الأدوار والأذونات؛
• تعديلات القيود؛
• التغييرات التي تؤثر في النسخ المتماثل أو التوافر؛
• نشر الإجراءات المخزنة التي تتضمن منطقًا تجاريًا.

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

يحتاج وكلاء الذكاء الاصطناعي أيضًا إلى مبدأ أقل قدر من الامتيازات

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

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

قد يحتاج وكيل تحليل الأداء، على سبيل المثال، إلى:

CONNECT
SELECT
VIEW DATABASE STATE
VIEW DEFINITION

ومن المرجح ألا يحتاج إلى:

ALTER ANY TABLE
CONTROL DATABASE
db_owner
sysadmin

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

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

القاعدة بسيطة: امنح الوكيل الأذونات التي تتطلبها مهمته، لا الأذونات الممنوحة للشخص الذي أطلقه.

أشرك الإنسان في سير العمل

النموذج الأفضل للعمل الوكلي في قواعد البيانات هو سير عمل مضبوط:

المراقبة ← التحليل ← الاقتراح ← المراجعة ← التنفيذ ← التحقق ← التوثيق

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

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

ثم يتوقف.

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

لا يزال بإمكان الوكيل تولي كثير من الأعمال المتكررة. أما ما يبقى من مسؤولية نهائية عن التغيير ذي الأثر الكبير، فيتحمله الإنسان.

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

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

الهدف هو أتمتة الأعمال الروتينية مع إبقاء القرارات المهمة بيد الإنسان.

الهدف الحقيقي هو الاستقلالية المنضبطة

لا يعني الذكاء الاصطناعي الوكلي بالضرورة الاختيار بين «الذكاء الاصطناعي يكتفي بالاقتراح» و«الذكاء الاصطناعي يشغّل قاعدة البيانات». فهناك مساحة واسعة بين الخيارين.

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

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

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

ليس المقصود تحقيق استقلالية مطلقة، بل منح الوكيل حرية كافية للمساعدة من دون منحه صلاحيات تتجاوز حاجته.

الخلاصة: لا يزال تطوير قواعد البيانات يتطلب حسن التقدير

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

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

ولهذا، فمن بين 88% من المؤسسات التي استخدمت الذكاء الاصطناعي في عام 2025، قالت 7% فقط إنه وُسّع نطاق استخدامه بالكامل في المؤسسة. وتتمثل المشكلة الأصعب في جعل الذكاء الاصطناعي موثوقًا بما يكفي للتشغيل على نطاق واسع.

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

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