Apple Just Shipped the First Autonomous Agent at Consumer Scale. Here's What Breaks When Enterprise Tries the Same Pattern.

لقد ظل التصفح الذاتي للويب مجرد عرض تجريبي بحثي لمدة عامين. أداة Claude Computer Use من Anthropic. أداة Operator من OpenAI. ومحاولات متنوعة مفتوحة المصدر للسماح للوكيل بتوجيه المتصفح بالطريقة التي يفعلها الإنسان. كانت العروض التجريبية تنجح دائماً، لكن عمليات النشر الإنتاجية على نطاق واسع لم تأتِ قط.

في مؤتمر WWDC 2026 الذي عُقد في 8 يونيو، أطلقت Apple واحدة منها. حيث سيستخدم تطبيق Passwords في نظام التشغيل iOS 27 ذكاء Apple (Apple Intelligence) ومتصفح Safari لـ "اتخاذ إجراءات نيابة عنك بشكل وكيل ذكي"، وذلك بلغة Apple الخاصة. فهو يكتشف كلمات المرور الضعيفة أو المخترقة، ويتنقل إلى كل موقع ويب، ويسجل الدخول باستخدام بيانات الاعتماد المخزنة، ويمر عبر خطوات تغيير كلمة المرور، ويولد بديلاً قوياً، ويُحدّث بيانات الاعتماد المخزنة. يضغط المستخدم مرة واحدة فقط للموافقة على التشغيل، ويحدث كل شيء آخر بشكل مستقل في الخلفية، عبر أي عدد من مواقع الويب.

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

ما أطلقته Apple بالفعل

لقد كان تطبيق Passwords قادراً على اكتشف بيانات الاعتماد المخترقة منذ فترة. وقد استخدم هذا الاكتشاف قواعد بيانات الخروقات الشبيهة بـ haveibeenpwned بالإضافة إلى خوارزميات Apple الخاصة لتقييم قوة كلمات المرور. القدرة الجديدة هي الحلقة المغلقة: فبعد الاكتشاف، يقوم الوكيل بتوجيه جلسة المتصفح المسجل الدخول للمستخدم إلى كل موقع ويب متأثر، ويتصفح واجهة مستخدم تغيير كلمة المرور، ويولد كلمة مرور بديلة تفي بقواعد الموقع، ويُحدّث سلسلة المفاتيح (keychain). يمنح المستخدم الإذن للتشغيل بنقرة واحدة ويمكنه مراجعة النتائج بعد ذلك.

البنية التحتية الأساسية هي Safari، وApple Intelligence، وتطبيق Passwords بالتنسيق من خلال واجهة برمجة تطبيقات (API) داخلية للامتداد لم تقم Apple بتوثيقها بعد للأطراف الخارجية. يرث الوكيل حالة المصادقة الحالية للمستخدم، وهو ما يتيح له تسجيل الدخول دون الحاجة لبيانات اعتماد منفصلة. كما أنه يعمل محلياً على الجهاز، لذا فإن قيم كلمات المرور لا تغادر أبداً جيب الحماية الآمن (secure enclave) الخاص بشركة Apple. والنموذج الذي يقود منطق التصفح هو Apple Intelligence على الجهاز لتحليل واجهة المستخدم الخاصة بكل موقع، مع توجيه سحابي للحالات الأكثر صعوبة عبر البنية التحتية لـ Siri المدعومة من Gemini الجديدة.

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

لماذا استطاعت Apple إطلاق هذا في حين لم يتمكن أحد غيرها

ثلاثة خيارات تصميم جعلت وكيل كلمات المرور (Passwords) قابلاً للإطلاق على نطاق واسع. وكل خيار منها هو ما لن تتمكن المؤسسات من تكراره.

الإجراء ضيق النطاق. تعد عمليات إعادة تعيين كلمات المرور سير عمل معروفاً ومُهيكلاً. فإما أن تطبق المواقع الخطوات القياسية (الإعدادات ← الأمان ← تغيير كلمة المرور) أو تطبق متغيراً يمكن التعرف عليه. هناك ما يقرب من اثني عشر نمطاً تغطي 95% من مواقع الويب الاستهلاكية. إن الوكيل الذي يتعامل مع عمليات إعادة تعيين كلمات المرور يحل مشكلة أبسط بكثير من وكيل يتعامل مع تسوية النزاعات أو الموافقات على النفقات، على سبيل المثال. نطاق العمل الضيق يجعل احتمالات الفشل قابلة للإدارة.

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

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

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

ما الذي ينهار عندما تنسخ المؤسسات هذا النمط

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

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

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

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

ما الذي يجب على المؤسسات أن تتعلمه فعلياً من إطلاق Apple

الدرس الصحيح من إطلاق Apple لوكيل Passwords ليس "أن التصفح الذاتي للويب أصبح الآن جاهزاً للإنتاج الفعلي". الدرس الصحيح هو ما اختارت Apple عدم القيام به.

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

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

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

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

النمط الذي يعمل فعلياً على نطاق المؤسسات

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

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

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

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