بنية مرجعية لذكاء اصطناعي سيادي: خمس طبقات وتدفقات ونموذج تهديدات وتقييم مستمر

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

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

ماذا تعني "السيادة" حقاً

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

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

فخ الاستضافة المحلية

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

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

الطبقات الخمس لذكاء اصطناعي محكوم

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

1. البنية التحتية

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

Kubernetes أساساً. ليس Kubernetes إلزامياً، لكنه يقدّم هنا ثلاثة أمور مفيدة: نموذجاً تصريحياً قابلاً للتكرار (البيان نفسه في المقر وعند المستضيف)، ومجدوِلاً يفهم الموارد النادرة، ومنظومة للتحكم في الشبكة وهوية أحمال العمل. وكلفته حقيقية: فريق يعرف كيف يشغّله. فإذا كان لديك خادم GPU واحد ونموذج واحد، تكفي خدمة systemd وحاوية، ولا أنصح بتركيب عنقود لمجرد الشكل.

عقد GPU والمشغّل (Operator). تحتاج عقدة GPU إلى المشغّل (driver)، وبيئة تشغيل حاويات مناسبة، وملحق الأجهزة (device plugin) الذي يعرض وحدات GPU كمورد قابل للجدولة، ووسم خصائص العتاد، والمراقبة. بحسب وثائق NVIDIA، يؤتمت GPU Operator هذه البرمجيات على Kubernetes (مشغّل الجهاز، وملحق الأجهزة، وcontainer toolkit، والوسم، ومقاييس DCGM) ويُنشر عبر Helm. والغاية تجنّب الانحراف بين العقد، وهو مصدر كلاسيكي للأعطال. وتشكّل إصدارات المشغّل وCUDA ومحرك الاستدلال والنواة مصفوفة توافق: أثبّتها وأختبرها عند كل تحديث، ولا أجرّبها مباشرة في الإنتاج.

الجدولة. يطلب الـpod وحدات GPU كاملة عبر المورد الموسَّع nvidia.com/gpu؛ ولا يقاسم المجدوِل وحدة GPU بهذه الطريقة. ولمقاسمة وحدة GPU توجد آليات خاصة بالعتاد (التقسيم إلى نسخ معزولة، والتقاسم الزمني)، مع مفاضلات في العزل وزمن الاستجابة ينبغي التحقق منها لطراز GPU لديك. وردّ فعلي المعتاد: نموذج إنتاج واحد لكل وحدة GPU أو مجموعة مخصصة، وأوسمة taints على عقد GPU كي لا يُجدول عليها شيء آخر، وأولويات صريحة حتى لا تُزاح خدمة الاستدلال التفاعلية بسبب مهمة دفعية.

# Illustrative excerpt: an inference deployment that requests 2 GPUs
# and can only land on the reserved GPU nodes.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: llm-large-model
  namespace: inference
spec:
  replicas: 1
  selector:
    matchLabels: { app: llm-large-model }
  template:
    metadata:
      labels: { app: llm-large-model }
    spec:
      nodeSelector:
        pool: gpu-inference
      tolerations:
        - key: dedicated
          value: gpu
          effect: NoSchedule
      containers:
        - name: engine
          image: registry.internal/inference-engine@sha256:<digest>
          resources:
            limits:
              nvidia.com/gpu: 2

تُحدَّد الصورة بالبصمة (digest) لا بوسم قابل للتغيير: وهذه أولى حلقات سلسلة التوريد، وسأعود إليها لاحقاً.

التخزين. ثلاثة استخدامات لا ينبغي الخلط بينها: أوزان النماذج (ملفات كبيرة للقراءة فقط تُحمَّل عند البدء)، وبيانات الحالة (قاعدة المتجهات، وPostgreSQL، والسجلات)، وذاكرات المحرك المؤقتة. تُحفظ الأوزان في سجل داخلي أو مخزن كائنات داخلي، مع نسخة محلية على أقراص NVMe في العقد كي لا يعتمد الإقلاع على الشبكة. وتوضع بيانات الحالة على تخزين مكرَّر ومشفَّر. ونموذج من 70 مليار معامل بدقة 16 بت يزن نحو 140 غيغابايت (70e9 × 2 بايت): فزمن التحميل ليس هيّناً، وهو يحدد زمن التعافي بعد الحادث.

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

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: inference
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: engine-from-gateway-only
  namespace: inference
spec:
  podSelector:
    matchLabels: { app: llm-large-model }
  policyTypes: [Ingress]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels: { kubernetes.io/metadata.name: gateway }
      ports:
        - port: 8000

التحكم في الحركة الخارجة. هذه أكثر النقاط استهانةً. فالذكاء الاصطناعي المحلي الذي يستطيع الوصول إلى أي عنوان على الإنترنت ليس معزولاً: pod مخترَق، أو حاوية مفخّخة، أو حقن أوامر يطلق استدعاء أداة، سيجد أي منها طريقاً للخروج. أرشّح الحركة الخارجة عبر وكيل أو بوابة خروج بقائمة بيضاء لأسماء النطاقات، وأمنع حلّ DNS الخارجي المباشر من المناطق الحساسة (فالـDNS قناة تسريب كلاسيكية)، وأسجّل كل محاولة مرفوضة. أما NetworkPolicy القياسية فتفكّر بعناوين IP ومنافذ؛ والقائمة البيضاء لأسماء النطاقات تحتاج مكوّناً إضافياً بحسب ملحق الشبكة أو شبكة الخدمات المعتمدة. وفي المنطقة المنفصلة تماماً لا توجد حركة خارجة إطلاقاً، وتدخل التحديثات عبر عملية نقل مضبوطة (انظر سلسلة التوريد أدناه).

2. النماذج وبوابة الاستدلال

النموذج هو العقل: نموذج مفتوح يُقيَّم على حالاتك أنت. ومحرك الاستدلال (Inference Engine) يحمّل الأوزان على وحدات GPU ويخدم مستخدمين كثيرين في آن واحد؛ وvLLM وSGLang مثالان شائعان. وبحسب وثائقهما، يوفّر كلاهما خادم HTTP متوافقاً مع واجهة OpenAI (chat completions وcompletions ومسارات أخرى بحسب الإصدار)، مع إضافات خاصة لا تعرفها الواجهة الأصلية. وهذا التوافق حجر الزاوية في قابلية التراجع، بتحفظ واحد: فهو يغطي معظم العقد لا كل المعاملات. فالمخرجات المنظَّمة واستدعاء الأدوات وأنماط الاستدلال تختلف من محرك إلى آخر، وأختبرها صراحةً قبل أن أقول إن محركاً يحلّ محل آخر.

تحديد الحجم: ذاكرة الـKV cache. العامل المحدِّد ليس وزن النموذج وحده، بل ذاكرة المفتاح والقيمة (KV cache) لكل طلب جارٍ. ويُحسب حجمها لكل رمز هكذا:

bytes per token = 2 (K and V) x layers x KV heads x head dimension x bytes per value

مثال توضيحي لبنية افتراضية من 32 طبقة و8 رؤوس KV وبُعد رأس 128 وقيم بدقة 16 بت: 2 × 32 × 8 × 128 × 2 = 131072 بايت، أي 128 كيبيبايت لكل رمز. فسياق من 8192 رمزاً يشغل 1 غيبيبايت لكل تسلسل، و32 تسلسلاً متزامناً تشغل 32 غيبيبايت، فوق الأوزان. وهذا الحساب، إذا أعيد بمعاملات نموذجك الحقيقية، يخبرك كم طلباً متزامناً تحتمل وحدة GPU، قبل قدرة الحوسبة بوقت طويل. وتدير المحركات الحديثة هذه الذاكرة على شكل كتل وتتقاسمها بين الطلبات ذات البادئة المشتركة، لكن رتبة المقدار تبقى نقطة البداية الصحيحة.

البوابة. بين التطبيقات والمحركات أضع بوابة تعرض واجهة متوافقة مع OpenAI وتحمل كل ما لا ينبغي إعادة تنفيذه في كل تطبيق:

• المصادقة (رمز OIDC للمستخدم أو التطبيق) والحصص لكل هوية؛
• التوجيه بين النماذج عبر أسماء مستعارة منطقية (general-assistant وfast-summary وembeddings) لا عبر اسم النموذج الفعلي؛
• تطبيق السياسات (المنطقة المسموحة لهذه البيانات، والأدوات المسموحة)؛
• كتابة سجل التدقيق والمقاييس؛
• البديل الاحتياطي: إذا امتلأ نموذج أو تعذّر، يُحوَّل الطلب إلى آخر إن سمحت السياسة.

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

# Illustrative gateway configuration (generic schema, not a specific product)
models:
  general-assistant:
    target: large-model-engine.inference.svc:8000
    engine_name: large-model-v3
    allowed_zones: [confidential, internal]
    fallback: fast-summary
  fast-summary:
    target: small-model-engine.inference.svc:8000
    engine_name: small-model-v2
    allowed_zones: [confidential, internal, public]
  embeddings:
    target: embeddings-engine.inference.svc:8000
    engine_name: embeddings-v1
quotas:
  per_user: { requests_per_minute: 30, max_output_tokens: 2048 }

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

التقييم قبل التحويل. لا يدخل الإنتاج أي تغيير في النموذج أو التكميم أو القالب أو إصدار المحرك دون إعادة تشغيل المجموعة المرجعية (انظر قسم التقييم المستمر). فالتكميم (Quantization) مثلاً يقلل الذاكرة ويسرّع الإنتاجية غالباً، لكنه قد يضعف الجودة بتفاوت بين اللغات: والعربية والنصوص القانونية كاشفان جيدان، ولا أثق إلا بقياسي أنا.

3. المعرفة والبيانات

هذه الطبقة تمنح الذكاء الاصطناعي سياقك: تقنية الاسترجاع المعزز بالتوليد (RAG) التي شرحتُها في مقال الذكاء الاصطناعي ووثائقك. وتشمل الاستيعاب (قراءة الوثائق وتقطيعها وتحويلها إلى متجهات)، وقاعدة متجهات (مثل pgvector أو Qdrant)، وفوق ذلك كله صلاحيات الوصول.

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

# Principle: the rights filter is part of the vector query.
def search(question, user, k=8):
    vector = embeddings(question)
    filter_ = {
        "read_groups": {"any_of": user.groups},
        "classification": {"max": user.clearance},
        "zone": {"in": allowed_zones(user)},
    }
    return vector_store.search(vector, filter=filter_, limit=k)

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

4. التنسيق والوكلاء

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

قواعد التصميم لدي، دون استثناء:

1. قائمة بيضاء للأدوات لكل دور. الأداة غير المصرَّح بها لهذا الدور غير موجودة بالنسبة إلى الوكيل. ولكل أداة مخطط معاملات صارم، يُتحقق منه في الخادم لا عند النموذج.
2. صلاحيات المستخدم لا صلاحيات الوكيل. تعمل الأداة بهوية من طرح السؤال (أو برمز مفوَّض مقيَّد)، لا بحساب خدمة كلي الصلاحيات. وإلا التفّ الوكيل على قوائم الصلاحيات في طبقة المعرفة.
3. موافقة بشرية لما لا رجعة فيه. الإرسال إلى الخارج، والكتابة في نظام مرجعي، والحذف، والدفع: يُعدّ الوكيل ويؤكد الإنسان، وتعرض شاشة التأكيد ما سيُنفَّذ فعلاً (بمعاملاته)، لا وصف النموذج له.
4. ميزانيات. حد أقصى لعدد الخطوات والرموز واستدعاءات الأدوات في كل مهمة، مع توقف حازم. فالوكيل الذي يدور في حلقة يستهلك وحدات GPU وقد يضاعف الإجراءات.
5. تسجيل استدعاءات الأدوات: الأداة، والمعاملات، والهوية، وقرار الموافقة، والنتيجة (مقتطعة ومُخفاة). وبدون هذا السجل لا يمكن إعادة بناء حادث.

وهذه ترجمة مباشرة لفئة "الوكالة المفرطة" (excessive agency) في قائمة OWASP لمخاطر تطبيقات النماذج اللغوية: وظائف أكثر من اللازم، وصلاحيات أكثر من اللازم، واستقلالية أكثر من اللازم. وأبدأ دائماً بالقراءة فقط، ثم أضيف الإجراءات واحداً تلو الآخر.

5. التطبيقات والواجهات

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

وفي كل مكان: الهوية والسياسات والأسرار والتدقيق

الشريط العمودي في المخطط ليس للزينة. وبدونه، لديك عرض تجريبي، لا نظام. وأقسّمه إلى ستة أوراش.

الهوية. تسجيل دخول موحّد (SSO) عبر OpenID Connect مدعوم بدليل المستخدمين في المؤسسة: يقدّم المستخدم رمزاً موقَّعاً، وتتحقق منه البوابة وتستخرج منه أدواراً (عائلات كبرى: محلل، ومحامٍ) و*سمات* (البلد، والإدارة، والتصريح الأمني). تكفي الأدوار للأدوات؛ أما الوثائق فتلزمها السمات ("ملفات البلد X"). وتصادق الخدمات بعضها على بعض عبر هوية أحمال العمل وTLS المتبادل، لا عبر أسرار مشتركة.

نقطة تطبيق السياسات. تُقيَّم القرارات (هذا الشخص، وهذه البيانات، وهذه المنطقة، وهذه الأداة) في مكان واحد، قابل للاستعلام والاختبار، بدل تبعثرها في شيفرة كل تطبيق. والبوابة هي نقطة التطبيق؛ أما السياسة نفسها فقد تكون محركاً مخصصاً أو وحدة بسيطة بإصدارات. والمهم أنها مكتوبة بوضوح، ومراجَعة، ومختبَرة، ومنشورة كما تُنشر الشيفرة.

# Illustrative policy rules
rules:
  - name: confidential-stays-local
    if: { document_classification: confidential }
    then: { model_zones: [on-premise], network_egress: denied }
  - name: write-tools-need-approval
    if: { tool.type: write }
    then: { human_approval: required }
  - name: countries-isolated
    if: { document.country: "!= user.country" }
    then: { access: deny }

الأسرار والمفاتيح. لا أسرار في الصور ولا في المستودعات: مدير أسرار (أو مخزن أسرار المنسّق مشفَّراً عند التخزين بمفتاح تتحكم فيه)، ورموز قصيرة العمر، وتدوير مجدول، وفوق ذلك مفتاح تشفير تكون حيازته واضحة. فإذا كان المفتاح لدى المزوّد الذي يستضيفك، فالتشفير لا يحميك منه.

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

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

{
  "ts": "2026-03-04T09:12:41Z",
  "user": "u-5821",
  "role": "compliance",
  "alias": "general-assistant",
  "model": "large-model-v3",
  "zone": "on-premise",
  "documents": ["doc-1182#p4", "doc-0457#p2"],
  "tools": [],
  "policy": ["confidential-stays-local:ok"],
  "tokens": { "input": 1840, "output": 312 },
  "prompt_sha256": "<digest>",
  "masked_content": "What are the conditions of [PRODUCT] for [CLIENT_1]?",
  "chain": "<digest of the previous record>"
}

المراقبة (Observability). المقاييس المهمة لخدمة استدلال: زمن أول رمز (TTFT)، والإنتاجية بالرموز في الثانية (لكل طلب وإجمالاً)، وعمق طوابير الانتظار، ومعدل الأخطاء وتجاوز المهل، وإشغال ذاكرة KV cache، واستخدام وحدات GPU، وتكلفة الطلب الواحد. وتُقدَّر الأخيرة ببساطة: التكلفة الساعية الكاملة للعقدة (الإهلاك والطاقة والتشغيل) مقسومة على عدد الطلبات المخدومة في الساعة عند زمن الاستجابة المستهدف. ويتدهور TTFT أولاً تحت الحمل (يطول الطابور)، ثم إنتاجية الطلب الواحد (تتقاسم التسلسلات وحدة GPU): أتابع الاثنين بالنسب المئوية لا بالمتوسطات. والمبادئ نفسها لمقاييس RAG: معدل الاسترجاعات الفارغة، وعدد الاستشهادات في كل إجابة.

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

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

رحلة سؤال

لتصبح هذه الطبقات ملموسة، لنتتبع سؤالاً يطرحه موظف: "ما شروط السداد المبكر في عقودنا مع الشركات؟"

1. التعرّف. يُتعرَّف على المستخدم عبر دليل المستخدمين في المؤسسة. ويحدد دوره وسماته مجموعات الوثائق التي يحق له الوصول إليها.
2. الاسترجاع. يُحوَّل السؤال إلى متجه، ولا يشمل البحث إلا الوثائق المسموح بها. ثم تُنتقى المقاطع الأكثر صلة.
3. التوليد. يتلقى النموذج، المستضاف لديك، السؤال والمقاطع، ثم يكتب إجابة مع ذكر مصادرها.
4. التحقق والتتبع. تفحص مرشِّحات الإجابة (البيانات الشخصية، والمحتوى الممنوع، ووجود الاستشهادات)، ويُسجَّل التبادل في سجل تدقيق محمي.

المخطط أعلاه هو المسار كما يراه المستخدم عن قصد. وهذا هو المسار نفسه كما تراه المكوّنات، مع تسلسل التبادلات والموضع الذي يُتخذ فيه كل قرار.

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

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

نموذج التهديدات

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

ملاحظتان بصراحة. فحقن الأوامر ليس له، بحسب علمي، دفاع كامل على مستوى النموذج: بل يُعالج بالبنية (تقييد ما يستطيع الوكيل فعله وما يستطيع قراءته)، لا بمرشِّح سحري. والإخفاء بالتعابير النمطية أو المصنِّفات يترك بعض الحالات تمر: فهو تقليل للمخاطر لا ضمان، والاحتفاظ القصير يعوّض حدوده.

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

أين يعمل ماذا: الفرز بحسب الحساسية

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

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

والتدفقات بين المناطق هي نفسها قرار معماري. وهذه التي أسمح بها وما أغلقه.

ولكل نمط من أنماط النشر الثلاثة منطقه، ولا أفضلية مطلقة لأحدها.

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

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

التقييم المستمر

أعدّ التقييم مكوّناً من مكوّنات البنية، في مرتبة البوابة نفسها. فبدونه لا يمكن التحقق لا من قابلية التراجع (لا نعرف هل البديل جيد) ولا من الأمان (لا نكتشف تراجعاً في السلوك).

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

ما يُقاس. للاسترجاع: استدعاء المقاطع الصحيحة ضمن أول k. وللتوليد: الدقة كما يحكم بها الخبراء (عيّنة منتظمة)، ونسبة الإجابات ذات الاستشهادات الصحيحة، ومعدل حالات الرفض المبرَّرة. ونموذج يعمل حَكَماً آلياً مفيد للفرز، لكن له انحيازاته؛ أعايره على أحكام بشرية ولا أفوّضه القرار النهائي.

# Non-regression check before switching (principle)
def can_switch(candidate, reference, dataset, thresholds):
    r_ref = evaluate(reference, dataset)
    r_new = evaluate(candidate, dataset)
    for metric, threshold in thresholds.items():
        if r_new[metric] < r_ref[metric] - threshold:
            return False, metric
    # security cases: zero tolerance
    if r_new["acl_leaks"] > 0 or r_new["successful_injections"] > r_ref["successful_injections"]:
        return False, "security"
    return True, None

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

اختبار الأسئلة الخمسة

قبل أن توقّع مع أي مزوّد لذكاء اصطناعي "سيادي"، بمن فيهم أنا، اطرح هذه الأسئلة الخمسة:

1. أين تُخزَّن وثائقي وأسئلتي والإجابات، وإلى أي ولاية قضائية يخضع المزوّد؟
2. من لديكم يستطيع الوصول إلى بياناتي، وهل يُسجَّل هذا الوصول؟
3. هل تُستخدم بياناتي لتدريب نموذج آخر؟
4. هل أستطيع استبدال النموذج أو المستضيف دون إعادة كتابة التطبيق؟
5. إذا أنهينا تعاوننا، ماذا أستعيد، وبأي صيغة، وخلال أي مدة؟

المزوّد الواثق من بنيته يجيب عن هذه الأسئلة الخمسة بوضوح، وكتابةً. ولجمهور تقني أضيف ثلاثة فحوص: السؤال 4 يمكن اختباره (اطلب عرضاً لتغيير نموذج)، والسؤال 2 يُتحقق منه في سجل التدقيق (اطلب مثالاً على سجل)، والسؤال 5 يُثبَت بتصدير فعلي لبيانات اختبار.

حالة مؤسسة: بنك إقليمي

سيناريو توضيحي

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

السياق

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

البنية المعتمدة

• البيانات السرية (ملفات العملاء، والعقود): عنقود Kubernetes بعقد GPU في مركز بيانات البنك في كل بلد، ونموذج مفتوح متوسط الحجم، مكمَّم ربما بعد التقييم، وقاعدة متجهات محلية. ولا خروج مباشر إلى الإنترنت، والاستيراد بنقل مضبوط.
• البيانات الداخلية (الإجراءات، والتعاميم، والمذكرات): سحابة سيادية لدى مستضيف محلي، مرتبطة بنظام الهويات نفسه عبر اتحاد OIDC، بمفاتيح تشفير يديرها البنك.
• المحتوى العام (الكتيّبات، والأسئلة الشائعة، والتواصل): نموذج سحابي متقدم، دون أي وصول إلى المجموعات الداخلية، يُستدعى عبر البوابة كغيره.
• بوابة لكل بلد، بأسماء مستعارة منطقية مشتركة، توجّه كل طلب إلى المنطقة المناسبة بحسب صلاحيات المستخدم وتصنيف الوثائق. ويُحفظ الفصل بين البلدان بالهوية (سمة country) وبالشبكة.
• سجل تدقيق بالإلحاق فقط لأغراض الامتثال، مع إخفاء البيانات الشخصية في الآثار المسجلة، وإجراء للوصول الاستثنائي إلى المحتوى الكامل، يُسجَّل هو أيضاً.
• سلسلة تقييم: مجموعة مرجعية بثلاث لغات أُعدّت مع فرق العمل، وتُعاد عند كل تغيير.

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

النشر خطوة بخطوة

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

ما الذي يُقاس

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

الأخطاء الأكثر شيوعاً

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

ما يجب تذكّره

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

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

المراجع

• vLLM: الخادم المتوافق مع OpenAI (الوثائق الرسمية، والإصدار كما في الرابط)
• SGLang: واجهات متوافقة مع OpenAI (الوثائق الرسمية)
• NVIDIA GPU Operator (الوثائق الرسمية، الإصدار 25.10)
• Kubernetes: Network Policies (الوثائق الرسمية)
• OWASP Top 10 for LLM Applications (إصدار 2025)