النقاط الرئيسية
- البنية المحلية هي أقوى ضابط للخصوصية. حين يقع النموذج وخوادم الأدوات والبيانات داخل بنية تحتية المتحكم في البيانات مع صفر تسرّب خارجي، يختفي نموذج التهديد الخاص بنماذج اللغة السحابية: فلا ينطبق Schrems II ولا قوائم المعالِجين الفرعيين ولا تقييمات أثر نقل البيانات عبر الحدود.
- 5 قوالب لسير عمل تغطي معظم الطلب في الإنتاج: استيعاب المستندات وتصنيفها، وفرز البريد الإلكتروني مع مسودات الردود، وملخص الاجتماعات واستخراج الإجراءات، وإنشاء تقارير الامتثال، ومعالجة الفواتير ومطابقة أوامر الشراء. لكل منها تصنيف بيانات وأساس قانوني ومستوى في قانون الذكاء الاصطناعي وتنسيق سجل تدقيق محدد.
- تُحدد مستويات EU AI Act الالتزامات. معظم سير العمل المؤسسي محدود المخاطر (الشفافية للمستخدم بأن الذكاء الاصطناعي متورط). أعمال الموارد البشرية والقرارات الائتمانية والأهلية للمنافع عالية المخاطر وتستلزم تقييم مطابقة كاملاً. التعرف على المشاعر في بيئة العمل والتسجيل الاجتماعي محظوران.
- عمل GDPR لا يتغير عند التشغيل المحلي. الأساس القانوني (المادة 6)، وتقليل البيانات (المادة 5)، وأمن المعالجة (المادة 32)، وسجل التدقيق، وDPIA (المادة 35) لسير العمل عالي الأثر. المكدس المحلي يُيسّر إثبات هذه الضوابط لكنه لا يجعلها اختيارية.
- المكدس المرجعي: Ollama أو vLLM مع نموذج استدعاء أدوات (Gemma 4 27B، وGLM-4.7 32B، وQwen3 32B للعمل العام؛ وLlama 3.2 3B للفرز الخفيف للبريد الإلكتروني)، مع Cline أو Goose+MCP كبيئة تشغيل للوكيل، وسجل تدقيق غير قابل للتغيير (append-only)، وموافقة بشرية على كل إجراء كتابة أو إرسال.
- ثلاثة إخفاقات يجب تجنبها: نشر سير عمل يستلزم DPIA بدونها، وخلط البيانات الشخصية والتجارية في مساحة عمل واحدة للوكيل، وإغفال بوابات الموافقة على الإجراءات الصادرة (إرسال البريد الإلكتروني، وتوقيع العقود، وتفويض المدفوعات).
حقائق سريعة
- البنية: Ollama أو vLLM + نموذج استدعاء أدوات + بيئة تشغيل الوكيل (Cline أو Goose+MCP) + سجل تدقيق + مخزن RAG، كل ذلك داخل بنية تحتية المتحكم في البيانات.
- سير العمل المشمولة: استيعاب المستندات، وفرز البريد الإلكتروني، وملخص الاجتماعات، وتقارير الامتثال، ومعالجة الفواتير.
- التوزيع بموجب EU AI Act في القوالب الخمسة: 4 محدودة المخاطر، و1 عالية المخاطر (عند استخدامها لفرز الموارد البشرية)، و0 محظورة.
- حد DPIA: إلزامية للمخاطر العالية، وقائمة على المعايير لغيرها. يجب على معظم الفرق تشغيل DPIA لأي سير عمل يمس بيانات الفئات الخاصة.
- أحجام الأجهزة: Gemma 4 27B وQwen3 32B تتسعان في 24 جيجابايت VRAM بـQ4_K_M؛ GLM-4.7 32B وLlama 3.3 70B يحتاجان 48 جيجابايت+ للسياق غير المقيد.
- احتفاظ سجل التدقيق: متطلبات سجل أنشطة المعالجة في المادة 30 من GDPR تُحدد الحد الأدنى؛ المعايير القطاعية (الخدمات المالية والرعاية الصحية) تُوسّعها. 6 سنوات هو الافتراضي الآمن لمعظم البيئات المؤسسية.
- التكلفة: صفر إنفاق على API؛ يُستهلك الأجهزة في مقابل اشتراك SaaS للذكاء الاصطناعي المؤسسي في غضون 6 إلى 12 شهراً لفريق من 20 مستخدم أو أكثر.
ما تفعله وكلاء الذكاء الاصطناعي المحلي للفرق المؤسسية
وكيل الذكاء الاصطناعي المحلي هو نموذج لاستدعاء الأدوات يعمل داخل بنية تحتية المتحكم في البيانات مع بوابات موافقة صريحة بين إجراءات القراءة والكتابة. إنه ليس مساعد محادثة، ولا أداة أتمتة سير عمل (n8n أو Zapier)، ولا مصنّفاً دقيقاً: بل هو الطبقة التي تحوّل النموذج إلى شيء يعمل على أنظمتك.
📍 في جملة واحدة
وكيل الذكاء الاصطناعي المحلي هو نموذج استدعاء أدوات مضافاً إليه سطح أدوات وبوابة موافقة، يعمل بالكامل داخل بنية تحتية المتحكم في البيانات، محوّلاً الامتثال الأوروبي من تمرين توثيق إلى خاصية معمارية.
💬 بعبارات بسيطة
الوكيل هو نموذج يستطيع قراءة نظام الملفات واستعلام قاعدة البيانات وإرسال بريد إلكتروني أو استدعاء واجهة برمجية داخلية، مع موافقة إنسان على كل إجراء يكتب أو يُرسل. شغّل النموذج والأدوات وسجل التدقيق على أجهزتك الخاصة وتُستبدل كل مكدس امتثال نموذج اللغة السحابي (Schrems II، وقوائم المعالِجين الفرعيين، وتقييمات الأثر عبر الحدود) بحقيقة معمارية واحدة: لا شيء يغادر شبكتك. ما يبقى هو ضوابط GDPR على البيانات ذاتها التي تنطبق على أي نظام.
- التعريف: نموذج + سطح أدوات (نظام الملفات، وقاعدة البيانات، والبريد الإلكتروني، والتقويم، وAPI داخلية) + بوابة موافقة لكل كتابة = وكيل. النموذج يقترح؛ بيئة تشغيل الوكيل تنفّذ؛ الإنسان يوافق على كل ما يغيّر الحالة أو يخرج من الشبكة.
- التمييز عن أدوات الأتمتة. أدوات مثل n8n وZapier عبارة عن سير عمل حتمية: محفّزات صريحة، وفروع صريحة، وإجراءات صريحة. الوكيل غير حتمي: النموذج يقرر أي أداة يستدعي وبأي معطيات بناءً على المدخلات وحالة المحادثة. استخدم الأتمتة حين يكون المسار ثابتاً؛ استخدم الوكيل حين يتغير المسار بحسب المدخلات.
- لماذا "المحلي" مهم تحديداً لسير العمل المؤسسي: إقامة البيانات قابلة للإثبات (البايتات لا تغادر شبكتك قط)، وأثر التدقيق من طرف إلى طرف (نفس السجل يلتقط استدعاء النموذج واستدعاء الأداة والنتيجة)، ولا يوجد معالِج فرعي خارجي في السلسلة. حجة الامتثال تكتب نفسها حين تُزيل البنية فئات كاملة من المخاطر.
- أين تتناسب وكلاء الذكاء الاصطناعي المحلي في المؤسسة: في أي سير عمل يتعامل مع بيانات شخصية (GDPR)، أو بيانات موظفين، أو بيانات سرية لأطراف ثالثة (NDA)، أو بيانات تجارية منظّمة (مالية وصحية وقانونية). الوكلاء المحليون لا يُحسّنون سير العمل الذي لا يمس سوى البيانات العامة؛ هناك الوكلاء السحابيون عادةً أسرع وأقل تكلفةً.
- للطبقة البروتوكولية التي تجعل هذا عملياً، راجع ربط Ollama بقواعد البيانات وAPIs مع MCP: إعداد وكيل محلي 2026.
5 قوالب لسير العمل المؤسسي
تغطي هذه القوالب الخمسة معظم الطلب الإنتاجي على الوكلاء المحليين في الفرق المؤسسية. يُوصف كل منها كالتالي: المحفّز → الأدوات → توصية النموذج → نمط الموافقة → المستوى في قانون الذكاء الاصطناعي.
📍 في جملة واحدة
تختلف القوالب الخمسة في المحفّز والمخرجات لكنها تتشارك قاعدة واحدة: خطوات القراءة تُوافق عليها تلقائياً، والكتابة أو الإرسال يستلزمان موافقة بشرية، وكل إجراء يُسجَّل في سجل تدقيق غير قابل للتغيير.
💬 بعبارات بسيطة
اختر القالب الذي يطابق سير عمل تُنجزه حالياً يدوياً. وصّل الوكيل ليقرأ المدخلات (نظام الملفات، والبريد الوارد، ومجلد الملفات)، ويصنّف أو يضع مسودة، ثم ينتظر مراجعة إنسانية قبل الإرسال أو الكتابة على أي شيء. بوابة الموافقة هي الفارق بين وكيل مفيد وحادث تنظيمي.
- 1. استيعاب المستندات وتصنيفها. المحفّز: وصول PDF أو مسح ضوئي إلى مجلد مُراقب أو عبر البريد الإلكتروني. الأدوات: نظام الملفات (قراءة)، وOCR (عند الحاجة)، ونموذج التصنيف، وقاعدة البيانات (كتابة). النموذج: Gemma 4 27B أو Qwen3 32B لاستدعاء الأدوات والمخرجات المنظّمة. نمط الموافقة: تلقائي للقراءة والتصنيف، ويدوي للتوجيه إذا ذكر المستند شخصاً. المستوى في قانون الذكاء الاصطناعي: محدود المخاطر. DPIA: قائمة على المعايير.
- 2. فرز البريد الإلكتروني مع مسودات الردود. المحفّز: رسالة جديدة في بريد وارد مُراقَب. الأدوات: IMAP/Graph API (قراءة فقط)، ونموذج التصنيف، ومخزن المسودات (كتابة)، وإشعار. النموذج: Llama 3.2 3B كافٍ للفرز؛ Gemma 4 27B لإنشاء المسودات. نمط الموافقة: تلقائي للتصنيف والمسودة، ويدوي دائماً للإرسال. المستوى في قانون الذكاء الاصطناعي: محدود المخاطر. DPIA: قائمة على المعايير؛ إلزامية إذا كان البريد الوارد يتعامل مع بيانات الموظفين.
- 3. ملخص الاجتماعات واستخراج الإجراءات. المحفّز: وصول النص المكتوب إلى التخزين (عبر Whisper أو مزوّد). الأدوات: نظام الملفات (قراءة)، ونموذج التلخيص، ونموذج الاستخراج، ووجهة المخرجات (Notion/Jira/wiki داخلي عبر API). النموذج: Qwen3 32B للسياق الطويل (128K) في ملفات الاجتماعات الممتدة لساعة. نمط الموافقة: تلقائي للملخص، ويدوي لبنود الإجراءات المنشورة في الأنظمة الخارجية. المستوى في قانون الذكاء الاصطناعي: محدود المخاطر؛ تحقق من التقاط الموافقة قبل معالجة كل ملف.
- 4. إنشاء تقارير الامتثال. المحفّز: مجدوَل (شهري أو ربع سنوي). الأدوات: قاعدة البيانات (قراءة)، ومخزن قوالب التقارير، وعارض التقارير، وإشعار للمراجع. النموذج: GLM-4.7 32B أو Llama 3.3 70B: سياق طويل، ومخرجات منظّمة، وتلفيق منخفض. نمط الموافقة: تلقائي لاستخراج البيانات، ويدوي للتقرير المنشور. المستوى في قانون الذكاء الاصطناعي: محدود المخاطر؛ تحقق من وجود أساس قانوني موثّق لمصادر البيانات الأساسية.
- 5. معالجة الفواتير والتحقق منها. المحفّز: وصول الفاتورة إلى بريد المالية أو مجلد AP. الأدوات: نظام الملفات (قراءة)، وOCR، وتكامل ERP (قراءة أوامر الشراء والموردين)، وقائمة الاستثناءات (كتابة). النموذج: Gemma 4 27B لاستدعاء الأدوات؛ Qwen3 32B حين تحتوي الفواتير على تخطيطات غير قياسية. نمط الموافقة: تلقائي للاستخراج ومطابقة أوامر الشراء، ويدوي لأي استثناء (تباين، ومورّد جديد، ومبلغ كبير). المستوى في قانون الذكاء الاصطناعي: محدود المخاطر. DPIA: لا تُفعَّل عادةً.
- النمط المشترك في القوالب الخمسة: خطوات القراءة تُوافق عليها تلقائياً؛ خطوات الكتابة التي تؤثر على الأنظمة الخارجية أو حقوق الأشخاص تُوافق عليها يدوياً. سجل التدقيق يلتقط كل قرار.
💡Tip: ابدأ بقالب واحد لا بخمسة. استيعاب المستندات وفرز البريد الإلكتروني هما نقطتا الدخول الأقل خطورةً: كلتاهما محدودة المخاطر، وكلتاهما تحتويان على حدود موافقة واضحة (توجيه، إرسال)، وكلتاهما تبنيان بنية تحتية لسجل التدقيق ستعيد استخدامها في القوالب الثلاثة الأخرى.
التصنيف بموجب EU AI Act للوكلاء المؤسسيين
يُصنّف قانون الذكاء الاصطناعي الأوروبي أنظمة الذكاء الاصطناعي حسب المخاطر على الحقوق الأساسية لا حسب التعقيد التقني. النموذج والمكدس ذاتهما يخدمان سير عمل محدودة المخاطر وعالية المخاطر؛ الالتزامات تنطبق على الاستخدام لا على التقنية.
- محدود المخاطر (معظم القوالب): التزامات الشفافية. يجب أن يعلم المستخدم الذي يتلقى بريداً إلكترونياً أو ملخصاً مُنشأً بالذكاء الاصطناعي بمشاركة الذكاء الاصطناعي. علامة واضحة في الرسالة وسطر إفصاح في وثائق النظام للمستخدم النهائي كافيان في الغالب. لا يلزم تقييم مطابقة.
- عالي المخاطر (حالات استخدام محددة): تقييم مطابقة كامل، وتسجيل في قاعدة بيانات الاتحاد الأوروبي، ومراقبة ما بعد التسويق، وجهة إشعار في بعض الفئات الفرعية. الأنماط التي تصل إلى المخاطر العالية في الفرق المؤسسية هي: فرز الموارد البشرية (فرز السير الذاتية وتقييم المرشحين)، والقرارات الائتمانية، وأهلية المنافع، والوصول إلى الخدمات الأساسية. المرفق الثالث من القانون هو القائمة التشغيلية.
- محظور (لا تنشر): التعرف على الهوية البيومترية في الوقت الفعلي في الأماكن العامة (مع استثناءات ضيقة لجهات إنفاذ القانون)، والتسجيل الاجتماعي للأشخاص الطبيعيين، والتقنيات التلاعبية التي تستهدف نقاط الضعف، والتعرف على المشاعر في بيئة العمل (مع استثناءات طبية وأمنية محدودة)، والتنبؤ الأمني المبني على التصنيف.
- المقابلة العملية لسير العمل → المستوى في القوالب الخمسة: استيعاب المستندات (محدود المخاطر)، وفرز البريد الإلكتروني (محدود المخاطر)، وملخص الاجتماعات (محدود المخاطر؛ تحقق من الموافقة)، وتقارير الامتثال (محدود المخاطر)، ومعالجة الفواتير (محدود المخاطر). القوالب الخمسة الأساسية كلها محدودة المخاطر؛ نفس القوالب المُعادة توظيفها لفرز الموارد البشرية أو القرارات الائتمانية ترث التزامات المخاطر العالية بحسب الاستخدام.
📌Note: قائمة حالات المخاطر العالية في المرفق الثالث من EU AI Act هي المرجع التشغيلي: ارجع إليها مباشرةً عند تصنيف سير عمل. لا تعتمد على مقالات التلخيص؛ النص القانوني قصير ودقيق بما يكفي للاستخدام قائمة تحقق.
ضوابط GDPR لسير عمل الوكلاء
البنية المحلية تُزيل تهديداً واحداً (مشاركة البيانات مع نموذج اللغة السحابي)، لكنها لا تُزيل التزامات GDPR على البيانات ذاتها. ستة ضوابط تغطي معظم سير عمل الوكلاء؛ هذه الستة ذاتها تتوافق بشكل نظيف مع الملف التقني الذي يتوقعه EU AI Act للأنظمة عالية المخاطر.
📍 في جملة واحدة
البنية المحلية تُزيل نموذج التهديد الخاص بنماذج اللغة السحابية؛ ضوابط GDPR على البيانات ذاتها (الأساس القانوني، وتقليل البيانات، وأمن المعالجة، وسجل التدقيق، وDPIA) لا تزال سارية والملف التقني يوثّقها في تنسيق واحد.
💬 بعبارات بسيطة
الذهاب إلى المحلي لا يُعطّل GDPR. يُعطّل الجزء الذي يهتم بـSchrems II واتفاقيات المعالِج، ويُبقي الجزء الذي يهتم بما يراه الوكيل من بيانات ولماذا يراها وما تحتفظ به من دليل. المكدس المحلي يُيسّر إنتاج هذا الدليل: نفس سجل التدقيق يُغذّي كلاً من ملف GDPR والملف التقني لقانون الذكاء الاصطناعي.
- 1. الأساس القانوني (المادة 6). وثّق الأساس المنطبق قبل النشر: الموافقة، والعقد، والالتزام القانوني، والمصلحة المشروعة، والمصالح الحيوية، أو المهمة ذات الاهتمام العام. تعمل معظم سير عمل الوكلاء المؤسسية على أساس العقد (علاقة موظف/عميل) أو المصلحة المشروعة (مع اختبار توازن موثّق). بيانات الفئات الخاصة (الصحة، والمعطيات البيومترية، والرأي السياسي) تستلزم أيضاً شرطاً من المادة 9.
- 2. تقليل البيانات (المادة 5(1)(ج)). يجب ألا يرى الوكيل سوى البيانات الشخصية التي يحتاجها سير العمل. الآثار العملية: جزّئ وصفّي في طبقة RAG لا في النموذج. تجنّب نقل المستندات الكاملة إلى المحادثة حين لا يكون ذا صلة سوى قسم. تجنّب الاحتفاظ بالـprompts الوسيطة التي تحتوي على بيانات شخصية بعد اكتمال المهمة.
- 3. تحديد الغرض (المادة 5(1)(ب)). يجب ألا يُعاد توظيف الوكيل عبر المهام دون إعادة تقييم. سير عمل معتمد لمعالجة الفواتير لا يمكنه استيعاب وظائف تقييم أداء الموظفين بصمت: هذا غرض جديد وأساس قانوني جديد وقرار DPIA جديد.
- 4. أمن المعالجة (المادة 32). التشفير في حالة السكون، والتحكم في الوصول إلى مساحة العمل، وسجل تدقيق غير قابل للتغيير، وخطة استجابة للحوادث تشمل "أنتج النموذج مخرجات لا يجب أن ينتجها". البنية المحلية تغطي الكثير هنا؛ لا تفترض أنها تغطي كل شيء.
- 5. سجل التدقيق. الحقول الدنيا لكل إجراء وكيل: الطابع الزمني، والمستخدم/المبادر، ومعرّف النموذج ونسخته، وهاش المدخلات، واستدعاءات الأدوات والمعطيات، وهاش المخرجات، والمُوافِق (عند تطبيق الموافقة اليدوية). تخزين append-only مع حماية التكامل (تسلسل الهاش أو أسطر السجل الموقّعة).
- 6. DPIA (المادة 35). إلزامية حين يتضمن سير العمل معالجة منهجية للبيانات الشخصية بأثر كبير، أو بيانات فئات خاصة بنطاق واسع، أو مخاطر عالية بموجب قانون الذكاء الاصطناعي. قائمة على المعايير لغير ذلك. توثّق الـDPIA الضوابط والمخاطر المتبقية وتوقيع مسؤول حماية البيانات.
⚠️Warning: خطأ شائع: النشر أولاً وكتابة الـDPIA لاحقاً. السلطات الرقابية تتوقع الـDPIA قبل بدء المعالجة (المادة 35(1)). اكتب الـDPIA في مرحلة التصميم: فهي موجزة (4 إلى 8 صفحات) وتُجبر على اتخاذ قرارات يكون تعديلها مكلفاً لاحقاً.
متطلبات امتثال مؤسسي إضافية خاصة
سير العمل المؤسسي في مناطق ذات تشريعات عمالية صارمة تمتلك طبقتين إضافيتين كثيراً ما تتجاهلهما الأدلة باللغة الإنجليزية. كلتاهما تُفعَّلان مبكراً وكلتاهما تعوق القرار إن أُغفلتا.
- الموافقة المشتركة لمجالس العمال. يُفعّل أي نظام تقني يراقب سلوك الموظفين أو أداءهم هذه الموافقة. تُفسّر محاكم العمل الألمانية "المراقبة" على نطاق واسع: وكيل يصنّف بريد الموظفين أو يلخّص اجتماعاتهم يدخل في نطاقها. يجب إشراك مجلس العمال في مرحلة التصميم لا بعد النشر.
- السرية المهنية. المحامون والأطباء والمدققون والمستشارون الضريبيون وبعض المهن الأخرى تتحمل مسؤولية جنائية عن الإفصاح غير المأذون به عن معلومات العملاء. البنية المحلية المحضة — بدون تسرّب بيانات، وسجل تدقيق غير قابل للتغيير — هي المتطلب الافتراضي الذي يُجيز وجود سير العمل في المقام الأول للمهن المقيّدة بالسرية.
- التطبيق العملي: لأي مهنة مقيّدة بالسرية المهنية، البنية المحلية ليست تفضيلاً بل هي المتطلب الذي يُتيح وجود سير العمل. يجب أن يوثّق الملف التقني أن لا بيانات عملاء تغادر بنية تحتية المؤسسة.
⚠️Warning: أشرك أصحاب المصلحة في الامتثال في مرحلة التصميم لا في مرحلة النشر. تكلفة الإشراك المبكر ساعات؛ تكلفة الإشراك المتأخر نشر موقوف وإعادة تفاوض من موقع أضعف.
اختيار النموذج المناسب للوكلاء المؤسسيين
موثوقية استدعاء الأدوات خاصية تعتمد على النموذج لا على إطار التشغيل. نفس الإطار مع نموذج صغير للأغراض العامة يفشل؛ مع نموذج 27B+ مُضبوط دقيقاً لاستدعاء الأدوات ينجح. اختر النموذج أولاً.
- **Gemma 4 27B (
gemma4:27b).** أفضل نموذج استدعاء أدوات للأغراض العامة في مايو 2026. يتسع في 16 جيجابايت ذاكرة موحدة أو 24 جيجابايت VRAM بـQ4_K_M. موثوق في استيعاب المستندات وفرز البريد الإلكتروني ومعالجة الفواتير. - **GLM-4.7 32B (
glm5:32b).** سياق 128K أصلي. موثوقية قوية في استدعاء الأدوات. الخيار لتقارير الامتثال وملخصات الاجتماعات بالمدخلات الطويلة. يحتاج 24 جيجابايت+ VRAM بـQ4_K_M للسياق غير المقيد. - **Qwen3 32B (
qwen3:32b).** متوازن وموثوق جداً في الخطط متعددة الخطوات. بديل جيد حين يكون Gemma 4 محافظاً جداً. سياق 32K أصلي؛ كافٍ لمعظم المهام المؤسسية. - **Llama 3.3 70B (
llama3.3:70b).** السقف الأعلى، أجهزة أثقل. 48 جيجابايت+ VRAM أو 64 جيجابايت ذاكرة موحدة بـQ4_K_M. استخدمه لتقارير الامتثال وإدارة الاستثناءات حيث الموثوقية أهم من السرعة. - **Llama 3.2 3B (
llama3.2:3b).** خيار خفيف للفرز عالي الحجم. يعمل بشكل مريح بـ8 جيجابايت VRAM. كافٍ لـ"هل هذا البريد دعم عملاء / مبيعات / بريد مزعج؟"؛ ليس كافياً لصياغة الردود. - تجنّب في عمل استدعاء الأدوات: أي شيء أقل من 7B للعمل الإنتاجي، وأي نموذج للأغراض العامة بدون تدريب صريح على استدعاء الأدوات، والكميات الأكثر عدوانيةً من Q4_K_M للنماذج الصغيرة.
💡Tip: Q4_K_M هو الحد الأدنى في الإنتاج لموثوقية استدعاء الأدوات. Q3 وما دونه يُدهور دقة استدعاء الأدوات قبل تدهور جودة المحادثة — وهو أسلوب الإخفاق الخاطئ في سير عمل منظَّم. إذا كانت VRAM شحيحة، اخفض مستوى المعاملات (32B → 27B) قبل خفض مستوى الكمية (Q4 → Q3).
مقارنة مكدسات الوكلاء للاستخدام المؤسسي
أربعة بيئات تشغيل للوكلاء موثوقة لسير العمل المؤسسي في 2026. تختلف في تجربة المستخدم لبوابات الموافقة وثراء أثر التدقيق والكود المخصص الذي يستلزمه كل منها.
- اختر Cline + Ollama إذا كان الفريق من الملف التقني وسير العمل يتسع داخل VS Code. أقل احتكاك في التثبيت وأسرع مسار لوكيل يعمل.
- اختر Goose + MCP إذا كان سير العمل يعمل على خادم بلا واجهة رسومية (تقرير امتثال مجدوَل، أو مُستوعب يراقب المجلدات) حيث لا IDE.
- اختر n8n + Ollama إذا كان سير العمل له شكل حتمي بخطوة أو خطوتين للنموذج. عقد human-in-the-loop في n8n تعطيك بوابات موافقة بدون واجهة مستخدم مخصصة.
- اختر LangGraph المخصص فقط حين يكون شكل سير العمل غير متوافق فعلاً مع ما سبق. جهد البناء حقيقي؛ كود أثر التدقيق وبوابات الموافقة على عاتقك.
| بيئة التشغيل | الإعداد | بوابات الموافقة | أثر التدقيق | الأفضل لـ |
|---|---|---|---|---|
| Cline (VS Code) | تثبيت إضافة | لكل خطوة، في IDE؛ قائمة الموافقة التلقائية | سجل داخل الإضافة؛ يستلزم تصديراً للامتثال | سير العمل المرتكزة على الكود، تدقيق مطوّر واحد |
| Goose + MCP | تثبيت brew + mcp.json | مطالبات CLI؛ قابل للتهيئة لكل أداة | ملف سجل CLI؛ دوّره إلى تخزين غير قابل للتغيير | سير العمل CLI، الخوادم بلا واجهة رسومية |
| n8n ذاتي الاستضافة + Ollama | Docker + عقدة LLM في n8n | عقد human-in-the-loop على مستوى سير العمل | سجل التنفيذ الأصلي في n8n + قاعدة البيانات | سير العمل الحتمي ذات خطوة أو خطوتين للنموذج |
| LangGraph مخصص + Ollama | مشروع Python، مجموعة اختبار حقيقية | مبنية بواسطتك (API المقاطعات) | مبني بواسطتك | سير العمل الإنتاجي الذي يبرر الاستثمار الهندسي |
💡Tip: Cline هو نقطة البداية الأقل احتكاكاً حتى لسير العمل غير المرتكزة على الكود. وصّل خوادم MCP (نظام الملفات، وsqlite، وIMAP) وستحصل على استيعاب المستندات ومعالجة الفواتير وفرز البريد الإلكتروني في بيئة تشغيل واحدة دون كتابة منسّق.
الأخطاء الشائعة عند نشر وكلاء محليين في سير عمل مؤسسي
- الخطأ الأول: النشر بدون DPIA. أي سير عمل يمس بيانات فئات خاصة أو يتخذ قرارات بشأن أشخاص يستلزم DPIA. الـDPIA موجزة — 4 إلى 8 صفحات لمعظم سير عمل الوكلاء — لكنها إلزامية وهي أول ما تطلبه السلطة الرقابية. اكتبها قبل النشر لا بعده.
- الخطأ الثاني: استخدام وكيل متصل بالسحابة للمستندات السرية. النموذج المحلي ليس كافياً إذا كانت بيئة تشغيل الوكيل أو سجل التدقيق أو مخزن المتجهات يقع في سحابة طرف ثالث. البنية من طرف إلى طرف؛ تبعية واحدة للسحابة في السلسلة تكسر حجة المحلي المحض.
- الخطأ الثالث: غياب بوابة الموافقة على إجراءات الكتابة أو الإرسال. الوكيل يقرأ ويصنّف ويضع مسودة ويُرسل. خطوة الإرسال هي التي يجب على الإنسان دائماً الموافقة عليها بغض النظر عن مدى موثوقية النموذج.
- الخطأ الرابع: خلط البيانات الشخصية والتجارية في مساحة عمل واحدة. يجب أن يكون لدليل عمل الوكيل ومخزن المتجهات نطاق لكل سير عمل لا مشترك. التلوث المتبادل ينتهك تحديد الغرض.
- الخطأ الخامس: إغفال سجل التدقيق. "يمكننا إعادة بنائه من سجل محادثة النموذج" ليس سجل تدقيق. Append-only مع تسلسل الهاش، محتفظ به وفق فترة الاحتفاظ ذات الصلة، قابل للاستعلام لمسؤولي طلبات وصول أصحاب البيانات: هذا الحد الأدنى.
المصادر
- النص الموحّد لـEU AI Act (artificialintelligenceact.eu) — تجميع رسمي لمتابعة اللائحة؛ المرفق الثالث هو القائمة التشغيلية للمخاطر العالية.
- النص الكامل لـGDPR (gdpr-info.eu) — المواد 5 و6 و25 و32 و35 هي التشغيلية لتصميم الوكلاء.
- إطار إدارة مخاطر الذكاء الاصطناعي للـNIST — غير أوروبي وغير ملزم، لكن بنية GOVERN / MAP / MEASURE / MANAGE قائمة تحقق مفيدة للتحضير للتدقيق.
- توجيهات EDPB 03/2018 بشأن اتخاذ القرار الآلي الفردي — تشغيلية لأي سير عمل يتخذ قرارات بشأن أشخاص.
الأسئلة الشائعة
هل وكلاء الذكاء الاصطناعي المحلي ممتثلون لـGDPR بصورة افتراضية؟
لا: هم متوافقون مع GDPR بحكم البنية لكن ليسوا ممتثلين بصورة افتراضية. البنية المحلية المحضة تُزيل نموذج التهديد الخاص بنموذج اللغة السحابي (Schrems II، وقوائم المعالِجين الفرعيين، والنقل عبر الحدود)، لكن ضوابط GDPR على البيانات ذاتها لا تزال سارية: الأساس القانوني، وتقليل البيانات، وأمن المعالجة، وسجل التدقيق، وDPIA عند الاقتضاء.
ما سير العمل عالية المخاطر بموجب EU AI Act؟
يسرد المرفق الثالث حالات الاستخدام التشغيلية عالية المخاطر. الأنماط التي تؤثر في الغالب على الفرق المؤسسية هي: الموارد البشرية (فرز السير الذاتية وتصنيف المرشحين وتقييم الأداء)، والقرارات الائتمانية، وأهلية المنافع، والوصول إلى الخدمات الأساسية. معظم سير العمل المؤسسية العامة (استيعاب المستندات وفرز البريد الإلكتروني وملخص الاجتماعات ومعالجة الفواتير وتقارير الامتثال) محدودة المخاطر.
هل أحتاج إلى DPIA لوكيل فرز البريد الإلكتروني؟
يعتمد ذلك. الـDPIA إلزامية حين يتضمن سير العمل معالجة منهجية للبيانات الشخصية بأثر كبير (المادة 35(1)) أو تظهر في قوائم DPIA الإلزامية للسلطة الرقابية. وكيل فرز البريد الوارد العام لا يُفعَّل تلقائياً في الغالب؛ نفس الوكيل في بريد الموارد البشرية أو المرشحين يُفعَّل. يجب على معظم الفرق تشغيل DPIA موجزة لأي بريد وارد يحتوي على بيانات موظفين.
ما حجم النموذج الذي يتعامل مع سير العمل المؤسسي بشكل موثوق؟
Gemma 4 27B هو الافتراضي الموثوق لاستدعاء الأدوات للأغراض العامة. GLM-4.7 32B هو الخيار حين تكون المدخلات طويلة (تقارير الامتثال، ونصوص اجتماعات لساعة): سياق 128K أصلي. Qwen3 32B هو البديل المتوازن. Llama 3.3 70B له أعلى سقف لكنه يحتاج 48 جيجابايت+ VRAM. Llama 3.2 3B كافٍ للتصنيف عالي الحجم لا للصياغة.
كيف أُدقّق في ما فعله الوكيل؟
كل إجراء للوكيل يكتب إدخالاً في السجل: الطابع الزمني، والمستخدم/المبادر، ومعرّف النموذج ونسخته، وهاش المدخلات، واستدعاءات الأدوات بمعطياتها، وهاش المخرجات، والمُوافِق عند تطبيق الموافقة اليدوية. التخزين append-only مع حماية التكامل. الاحتفاظ يتبع متطلبات سجل أنشطة المعالجة في المادة 30 من GDPR كحد أدنى.
هل يمكنني مشاركة وكيل بين الأقسام؟
معمارياً نعم، قانونياً معقّد. لكل قسم غرضه وأساسه القانوني واحتفاظه وربما اتفاقيته مع مجلس العمال. النمط الأنظف: بيئة تشغيل وكيل واحدة، ومساحات عمل منفصلة لكل سير عمل، وسجلات تدقيق منفصلة لكل سير عمل، ونشر واحد للنموذج الأساسي. النموذج مورد مشترك؛ سير العمل ليست كذلك.
ما الحال مع الفروع عبر الحدود؟
إذا كان المتحكم في البيانات هو الكيان الأوروبي وبقيت البيانات في البنية التحتية الأوروبية، فإن البنية المحلية المحضة تغطي معظم المخاوف عبر الحدود افتراضياً. Mistral Large على Scaleway هو الخيار الهجين الشائع حين لا يكون المحلي المحض كافياً ولا يكون الخيار السحابي الأمريكي ممكناً.