المحتويات

«هل يمكنني تسليم تشغيل AWS وإدارته إلى الذكاء الاصطناعي؟» — إن كنت تدير بنية تحتية، فقد تساءلت عن ذلك على الأرجح. الجواب المختصر: في عام 2026 دخلنا مرحلة «يمكنك تفويض الكثير». فأصبحت AWS نفسها تقدّم الآن Amazon Q Developer وأساسًا رسميًا لوكلاء الذكاء الاصطناعي لتشغيل AWS — «Agent Toolkit for AWS» (مايو 2026) — بحيث بات بإمكان الذكاء الاصطناعي أن يمتد من توليد الشيفرة وصولًا إلى تشغيل الموارد.

لكن السؤال الحقيقي ليس «هل يستطيع؟»، بل «كيف تفوّض دون انفلات، أو انفجار في الفاتورة، أو تسريب للبيانات؟» يعرض هذا المقال ما الذي يمكنك تسليمه للذكاء الاصطناعي وإلى أي حد (المزايا)، وما الذي يصبح خطيرًا حين تفعل ذلك (العيوب)، اعتمادًا على مصادر AWS الرسمية وشركات الأمن — ويختم بمبادئ التفويض الآمن.

الخلاصة في 30 ثانية

إن كنت مستعجلًا، فهذا فقط

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

1. المستويات الثلاثة لـ«ترك الذكاء الاصطناعي يدير AWS»

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

المستوى ① التوليد

اجعله يكتب الكود / البنية التحتية ككود

اجعل الذكاء الاصطناعي يصوغ مسودة البنية التحتية ككود (IaC) (CloudFormation/Terraform) والنصوص البرمجية؛ ويراجعها إنسان ويطبّقها. مخاطرة منخفضة.

المستوى ② التشغيل / الاستقصاء

دعم تشغيلي قائم على القراءة

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

المستوى ③ التشغيل الذاتي

دعه يشغّل AWS فعليًا

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

في معظم الفرق، يؤتي ① و② ثمارهما أولًا. أما ③ (التشغيل الذاتي) فقوي لكنه يفترض تصميمًا يراعي المخاطر أدناه. وقراءة إلى أي مدى يستطيع الذكاء الاصطناعي التعامل مع إعداد البنية التحتية وهل يمكن للذكاء الاصطناعي أن يحلّ محل مهندسي البنية التحتية/الشبكات معًا تمنحك إحساسًا بما يمكن تفويضه.

2. كيف؟ — الأدوات الرئيسية

بحلول عام 2026، نضجت الطرق الرسمية وشبه الرسمية لجعل الذكاء الاصطناعي يلمس AWS.

الأداةالدورمدى الوصول
Amazon Q Developerمساعد الذكاء الاصطناعي الرسمي من AWS. يدعم دورة حياة التطوير بأكملها — الترميز والاختبار والنشر ومعالجة الأعطال وفحص الأمان وتحسين موارد AWS.①② (③ مع MCP)
Agent Toolkit for AWS (مايو 2026)الأساس الرسمي لوكلاء الذكاء الاصطناعي لتشغيل AWS. أكثر من 40 مهارة للوكلاء (agent skills) (البنية التحتية ككود، والتخزين، والتحليلات، وعديم الخوادم، والحاويات، والذكاء الاصطناعي) + خادم AWS MCP Server مُدار + إضافات.①②③
AWS MCP Server (ضمن Agent Toolkit)يتيح للوكيل تشغيل أي خدمة من خدمات AWS. يتضمن حواجز حماية قائمة على IAM، وقابلية للمراقبة عبر CloudWatch/CloudTrail، وتنفيذًا معزولًا (sandbox) للعمليات متعددة الخطوات.③
تكاملات MCP (Terraform وغيره)اربط HashiCorp Terraform MCP وما شابهه بـ Q Developer لتعزيز توليد البنية التحتية ككود والتحقق منها.①
Amazon Bedrock AgentCoreأساس لبناء وتشغيل وكلاء الذكاء الاصطناعي الإنتاجيين أنفسهم.③ (اصنعه بنفسك)
Claude Code / Codex + AWS CLIالمسار باستخدام أدواتك الخاصة: امنح وكيل الترميز الذي تستخدمه أصلًا واجهة AWS CLI واجعله يشغّل AWS من الصدفة (shell) عبر أمر «aws». ويمكن دمجه مع AWS MCP Server.①②③

* أُعلن عن Agent Toolkit for AWS في 6 مايو 2026. متوفر في US East (شمال فرجينيا) وأوروبا (فرانكفورت)؛ والأداة نفسها بلا رسوم إضافية (تدفع مقابل موارد AWS التي يستهلكها وكلاؤك). المصدر: إعلان AWS الرسمي. قد تتغير المواصفات — راجع الصفحة الرسمية لأحدث المعلومات.

منح Claude Code / Codex واجهة AWS CLI (المسار باستخدام أدواتك الخاصة)

إلى جانب أدوات AWS الأصلية، يمكنك أيضًا منح وكيل الترميز الذي تستخدمه أصلًا واجهة AWS CLI وتركه يشغّل AWS. فبإمكان Claude Code وCodex تنفيذ الأوامر في صدفة (bash)، لذا بمجرد إعداد AWS CLI يمكنهما تركيب أوامر «aws ...» وتشغيلها انطلاقًا من تعليمة بلغة طبيعية — مع تعلّم الخيارات عند الحاجة عبر «aws ... help».

ويمكنك هنا أيضًا ربط AWS MCP Server. تصوّره لا على أنه «بديل عن CLI» بل كغلاف يولّد الأوامر وينفّذها في الخلفية مع فرض حواجز حماية IAM والتدقيق (CloudTrail). وكلٌّ من Claude Code وCodex يدعم MCP، فيمكنهما استخدام خادم MCP الرسمي من AWS مباشرة.

⚠️ الأهم في المسار باستخدام أدواتك الخاصة: هنا، ما يستطيع الوكيل فعله == صلاحيات IAM لبيانات اعتماد AWS التي أعددتها. بعبارة أخرى، صلاحيات IAM الأقل امتيازًا هي بذاتها ضابط الأمان. وفوق ذلك، لا تسمح بشكل شامل لأمر «aws» في أوضاع الصلاحيات / قواعد الصلاحيات في Claude Code. والممارسة المعيارية هي ملف تعريف للقراءة فقط للاستقصاء، وملف تعريف منفصل + موافقة للتغييرات.

3. المزايا — ما الرائع في الأمر

🏗️ بنية تحتية ككود سريعة

يصوغ الذكاء الاصطناعي مسودات قوالب CloudFormation/Terraform — أسرع بكثير من الكتابة من الصفر.

🔎 فرز آلي للحوادث

يقرأ السجلات والمقاييس لتضييق نطاق الحوادث — حتى للاستجابة الأولية خارج ساعات العمل.

💰 أفكار لتحسين التكلفة

يكشف الموارد غير المستخدمة والنسخ المفرطة في الحجم ويقترح تعديلات.

📚 دمقرطة المعرفة

يجعل خدمات AWS الهائلة وأفضل ممارساتها في متناول اليد حتى لغير الخبراء.

باختصار: السرعة والاتساع. فهو يجتاز بسرعة أعمال البنية التحتية ككود الروتينية والاستقصاء وأفكار التحسين، ويخفض حاجز المعرفة المتخصصة. كما أن مهارات الوكلاء (agent skills) في Agent Toolkit — التي تمنح الوكيل إجراءات مُتحقَّقًا منها لأمور مثل «كيفية تأليف CloudFormation» — ترفع الدقة أيضًا (المصدر: AWS).

4. العيوب والمخاطر — هنا صلب الموضوع

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

🚨 يحدث فعلًا: في 2025–2026، قامت وكلاء الترميز/التشغيل بالذكاء الاصطناعي بـحذف قواعد بيانات إنتاجية، ومسح أدلة المنزل (home directories)، وتدمير بيانات حيوية للأعمال باستدعاء أداة واحد.

① تضخّم الصلاحيات

يميل دور IAM الخاص بالوكيل إلى امتلاك صلاحيات أكثر مما يلزم. وإن تُرك دون ضبط، تتراكم الصلاحيات (permission sprawl).

② مضخِّم لنطاق تأثير الأخطاء

كلما اتسعت الصلاحية، اتسع في لحظة واحدة أثر زلّة، أو حقن التعليمات (prompt injection)، أو استدعاء أداة غير مقصود.

③ الصلاحيات تعمّر بعد انتهاء المهمة

قد تواصل الوكلاء الذاتية التصرف بعد أن يخفت القصد الأصلي. والصلاحيات المتروكة ممنوحة تصبح بيئة خصبة للحوادث.

④ انفلات التكلفة

حين يسلسل الوكيل استدعاءات الأدوات ويشغّل موردًا تلو الآخر، تنتفخ الفاتورة إلى ما يفوق التوقعات.

تحذّر شركات الأمن من أنه في مواجهة سرعة تبنّي المؤسسات لوكلاء الذكاء الاصطناعي (تتوقع Gartner أن نحو 40% من تطبيقات المؤسسات ستدمج وكلاء ذكاء اصطناعي متخصصين بالمهام بحلول نهاية 2026)، لا تستطيع حوكمة الصلاحيات مجاراتها، مما يجعل «تضخّم الصلاحيات» مشكلة بنيوية. والخطر ليس فقط في «الصلاحية المفرطة الاتساع» — بل في «الصلاحية التي تبقى بعد انتهاء المهمة».

5. خمسة مبادئ للتفويض الآمن

وبالمقابل، تكون التدابير المضادة واضحة. في الواقع، بنت AWS نفسها «حواجز حماية IAM، وتدقيق CloudTrail، وتنفيذًا معزولًا» ضمن Agent Toolkit — وهو ما يبيّن شكل الإجابة الصحيحة.

  1. صلاحيات IAM الأقل امتيازًا: امنح الوكيل الصلاحيات التي تحتاجها تلك المهمة فقط. لا تعِد استخدام دور واسع.
  2. موافقة بشرية على العمليات المدمّرة: للإجراءات غير القابلة للتراجع — عمليات الحذف، والتغييرات الإنتاجية، والإنشاء واسع النطاق — أدرِج دائمًا موافقة بشرية (إنسان ضمن الحلقة، human-in-the-loop).
  3. قابلية المراقبة (سجلات التدقيق): سجّل مَن فعل ماذا ومتى عبر CloudTrail / CloudWatch. أبقِ أفعال الوكيل قابلة للتتبع لاحقًا.
  4. بيانات اعتماد قصيرة العمر تُصدر عند الحاجة (JIT، just-in-time): بدلًا من صلاحيات واسعة دائمة، أصدِر بيانات اعتماد قصيرة المدة (TTL) لكل مهمة وأبطلها عند اكتمالها.
  5. العزل (sandbox) وفرض الصلاحية خارج النموذج: نفّذ العمليات متعددة الخطوات في بيئة معزولة، وافرض «ما هو مسموح» عبر الآلية (IAM وغيرها) — لا عبر حكم النموذج.

💡 حدس التصميم: حواجز الحماية التي «تسيّج ماديًا بالصلاحيات والموافقات» أوثق من «تدريب الذكاء الاصطناعي على حسن التصرف». وفكّر أيضًا في منصة وكلاء مُدارة وفي تصميم يتجنب الاعتماد على مورّد وحيد.

الخلاصة

  • اتسع النطاق القابل للتفويض: يتيح Amazon Q Developer وAgent Toolkit for AWS (مايو 2026) للذكاء الاصطناعي أن يمتد من توليد البنية التحتية ككود إلى تشغيل الموارد.
  • الأسهل تفويضًا: ① التوليد و② التشغيل القائم على القراءة. أما ③ التشغيل الذاتي فقوي لكنه يحتاج إلى حواجز حماية.
  • صلب الموضوع هو المخاطر: تضخّم الصلاحيات، وتضخيم الأخطاء، والصلاحيات التي تعمّر بعد المهمة، وانفلات التكلفة. وهناك حوادث فعلية لحذف قواعد بيانات إنتاجية.
  • الحل واضح: صلاحيات IAM الأقل امتيازًا + موافقة بشرية على العمليات المدمّرة + تدقيق CloudTrail + بيانات اعتماد قصيرة العمر تُصدر عند الحاجة (JIT) + العزل. وAgent Toolkit من AWS نفسه يتخذ هذا الشكل.

الجواب عن «هل يستطيع الذكاء الاصطناعي إدارة AWS؟» هو «الكثير جدًا — ما دمت تسيّجه بالصلاحيات والموافقات». قبل الانقضاض على الراحة، أرسِ الأقل امتيازًا وبوابة الموافقة البشرية أولًا — تلك هي قاعدة تشغيل AWS × الذكاء الاصطناعي في 2026.

الأسئلة الشائعة

س. هل سيحل الذكاء الاصطناعي محل موظفي تشغيل AWS؟

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

س. من أين أبدأ؟

بالبدء من ① التوليد منخفض المخاطر (صياغة مسودة البنية التحتية ككود) و② التشغيل القائم على القراءة (فحص السجلات، وتحليل التكلفة). وربط MCP بـ Amazon Q Developer نقطة دخول شائعة. لا تنتقل إلى التغييرات الفعلية على الموارد (③) إلا بعد أن تُرسي الأقل امتيازًا وبوابة موافقة، خطوة بخطوة.

س. ما أخطر الحوادث؟

العمليات المدمّرة التي يقوم بها وكيل مفرط الصلاحيات. في 2025–2026 وردت حالات لحذف قواعد بيانات إنتاجية وما شابه. اجعل عمليات الحذف والتغييرات الإنتاجية دائمًا خلف موافقة بشرية، وأبقِ الصلاحيات في حدّها الأدنى.

س. أنا قلق من انفلات التكلفة.

الوكيل الذي يشغّل موردًا تلو الآخر ينفخ الفاتورة. اجمع بين تنبيهات الميزانية (AWS Budgets)، وقيود IAM على أنواع الموارد التي يمكن إنشاؤها وأعدادها، وتدقيق الأفعال عبر CloudTrail. وAgent Toolkit نفسه مجاني، لكن تُحاسَب على موارد AWS التي يستهلكها الوكيل.

س. كيف أحدّد نطاق الصلاحيات؟

الأساس هو الأقل امتيازًا على مستوى المهمة. لا تعِد استخدام أدوار واسعة دائمة؛ بل أصدِر بيانات اعتماد قصيرة المدة (TTL) عند الحاجة (JIT) وأبطلها عند اكتمالها. والمفتاح هو فرض «ما هو مسموح» عبر الآلية (IAM وغيرها)، لا تركه لحكم النموذج.