الذكاء الاصطناعي وانعدام الثقة (Zero-Trust AI): كيف تمنح نماذجك إمكانية الوصول دون كشف بنيتك التحتية
تمنح معظم فرق الهندسة الداخلية نماذج الذكاء الاصطناعي الخاصة بها وصولاً هائلاً وغير ضروري إلى قواعد بيانات الإنتاج (production databases) وواجهات برمجة التطبيقات (APIs) الداخلية. نحن نرى باستمرار عمليات نشر مؤسسية غير منظمة حيث يمكن لحقن توجيه (prompt injection) واحد أن يتجاوز المصادقة (authentication) ويقرأ بيانات مالية حساسة.
يحدث هذا لأن أطر عمل الذكاء الاصطناعي القياسية تعطي الأولوية لسرعة المطور على حساب الأمان. عندما يربط فريق هندسي نموذج لغة كبير (LLM) بقاعدة بيانات، فإنهم عادةً ما يقدمون له حساب خدمة بصلاحيات مسؤول (admin-level service account). هذا الخلل المعماري الأساسي يهدد محيط نظامك بالكامل (perimeter).
إذا كنت تعمل في مجال التكنولوجيا المالية (fintech)، أو البنوك، أو الأسواق الخاضعة للرقابة، فإن هذا النهج يضمن الفشل أثناء تدقيق SOC 2 القادم. يجب أن تتعامل مع نموذج الذكاء الاصطناعي كمستخدم معادٍ وغير موثوق.
إليك كيف نصمم معماريات انعدام الثقة في الذكاء الاصطناعي لعملاء الشركات الذين لا يستطيعون تحمل مخاطر انكشاف (exposure) البنية التحتية.
نقطة الفشل: نماذج بصلاحيات مفرطة (Over-Privileged Models)
يكمن جذر المشكلة في كيفية تصور المطورين لأدوات الذكاء الاصطناعي. فهم ينظرون إلى الـ LLM كمكون تطبيق داخلي، على غرار العامل في الخلفية (background worker) أو الخدمة المصغرة (microservice).
وبما أنهم يثقون برمز التطبيق، فإنهم يمدون تلك الثقة لتشمل الـ LLM. يقومون بتكوين بيئة النموذج باستخدام مفاتيح API خام، واتصالات قاعدة بيانات مباشرة، وخروج غير مقيد للشبكة (unrestricted network egress). هذا يعني أن النموذج يعمل بأقصى امتيازات النظام.
تعتبر هذه ثغرة أمنية حرجة. نموذج LLM ليس شيفرة برمجية يمكن التنبؤ بها؛ بل هو محرك تنفيذ (execution engine) يُدار بواسطة اللغة الطبيعية (natural language). إذا أدخل مستخدم توجيهاً خبيثاً، فسيقوم النموذج بتنفيذه بدقة باستخدام الصلاحيات التي يمتلكها.
إذا كان النموذج يتمتع بصلاحية الكتابة (write access) في قاعدة بيانات PostgreSQL الرئيسية لديك، فيمكن لحقن التوجيه إسقاط الجداول (drop tables). وإذا كان لديه وصول إلى واجهة برمجة تطبيقات (API) داخلية للموارد البشرية، فيمكن لتوجيه مخترق أن يسرب بيانات الرواتب. نحن نرى بشكل روتيني نماذج إثبات مفهوم (proof-of-concepts) حيث يقوم المطورون بتوصيل وكلاء LangChain (LangChain agents) بأذونات الجذر (root credentials) فقط لتشغيل العرض التوضيحي.
لا تنجو هذه الإعدادات أبداً من المراجعات الأمنية للمؤسسات. يجب أن تقيد بنيتك التحتية بدقة ما يمكن للنموذج فعله، بغض النظر عما يطلبه المستخدم منه.
تحديد مبدأ انعدام الثقة (Zero-Trust AI) لأنظمة الإنتاج
يتطلب الذكاء الاصطناعي القائم على انعدام الثقة (Zero-Trust AI) تطبيق مبادئ أمان الشبكات القياسية على بيئة تنفيذ النموذج. الافتراض الأساسي بسيط: النموذج سيتم اختراقه في النهاية.
عندما تتبنى هذا الموقف، تتغير البنية المعمارية بالكامل. أنت لم تعد تمرر أوراق الاعتماد (credentials) إلى بيئة LLM. أنت لا تسمح للنموذج بتنفيذ استعلامات SQL خام (raw SQL queries). وأنت تمنع كافة اتصالات الإنترنت الصادرة (outbound internet access) من الحاوية (container) التي تُشغل النموذج.
بدلاً من ذلك، يجب على النموذج إثبات تفويضه لكل إجراء (single action). يجب أن يرث الصلاحيات الدقيقة للمستخدم البشري الذي يتفاعل معه، ولا شيء أكثر من ذلك على الإطلاق.
إذا طلب مدير حسابات من مساعد الذكاء الاصطناعي الداخلي بيانات عميل، يجب على النظام التحقق من رمز JWT (JSON Web Token) الخاص بمدير الحسابات قبل استرداد البيانات. النموذج نفسه لا يمتلك أي حقوق وصول متأصلة للبيانات. إذا كان المستخدم البشري يفتقر إلى التصريح (permission)، يفشل النموذج في تنفيذ الطلب.
البنية التحتية للتكنولوجيا المالية المنظمة
لقد أعدنا مؤخراً بناء بنية ذكاء اصطناعي لمؤسسة مالية مقرها الإمارات. كان فريقهم الداخلي قد أمضى ستة أشهر في معاناة لنشر مساعد يواجه العملاء. تم حظرهم من قبل قسم الامتثال الخاص بهم لأن تصميمهم المقترح انتهك ضوابط الوصول الأساسية وإقامة البيانات (data residency).
يمكنك قراءة التفاصيل الفنية الكاملة لكيفية حلنا لهذه المشكلة في دراسة حالة اختبار الاختراق. اعتمد الحل الأساسي على الفصل المادي والمنطقي للنموذج عن طبقة التنفيذ.
قمنا بنشر نموذج مفتوح المصدر (open-source model) داخل شبكة فرعية (subnet) لسحابة افتراضية خاصة (VPC) معزولة تماماً (strictly air-gapped). لم يكن للنموذج أي وصول صادر إلى الإنترنت ولا اتصالات مباشرة بقواعد البيانات. لم يكن بإمكانه بدء الطلبات؛ كان بإمكانه فقط الاستجابة لبوابة تنسيق مركزية (centralized orchestration gateway).
عندما يتفاعل مستخدم مع النظام، تتولى بوابة التنسيق عملية المصادقة. ثم تمرر التوجيه المُنظف (sanitized prompt) إلى الـ LLM. يعالج الـ LLM النص ويعيد نية مهيكلة (structured intent). يقوم المنسق (orchestrator)، الموجود خارج البيئة المعزولة، بتنفيذ النية (intent) على قاعدة البيانات باستخدام التحكم في الوصول القائم على الدور (RBAC).
لم يرَ نموذج LLM قط مخطط (schema) قاعدة البيانات. ولم يحمل قط مفتاح API. كان معزولاً تماماً عن البنية التحتية المصرفية الأساسية.
إذا كان فريقك يواجه صعوبة في اجتياز عمليات التدقيق الأمني لنشر نماذج LLMs الداخلية، فهنا عادة ما توفر مكالمة تحديد النطاق معنا 3-4 أشهر من وقت الهندسة الضائع.
التنفيذ مقابل التنسيق: النموذج العقلي
لبناء ذكاء اصطناعي آمن، يجب أن يتبنى فريقك الهندسي نمط النية-التنفيذ (Intent-Execution pattern). يفصل هذا النموذج العقلي بين عملية اتخاذ القرار وبين التنفيذ الفعلي على البنية التحتية.
في الإعداد المعيب، يقرر النموذج ما يجب فعله وينفذه فوراً. على سبيل المثال، يقرر الاستعلام عن رصيد مستخدم وينفذ استدعاء API باستخدام رمز (token) مبرمج بشكل صلب.
في نمط النية-التنفيذ، يقوم النموذج فقط بإنشاء النوايا (intents). فإنه يُخرج كائن JSON مهيكل (structured JSON object) يفصل ما يريد القيام به، مثل {"action": "query_balance", "account_id": "98765"}.
يسلم النموذج هذه النية مرة أخرى إلى طبقة التنسيق (orchestration layer). يعترض المنسق الطلب ويمرره عبر محرك سياسة إدارة الهوية والوصول (IAM). ويتحقق مما إذا كان المستخدم المصادق عليه حالياً لديه الحق في قراءة الحساب 98765.
إذا وافق محرك السياسة، يقوم المنسق بإجراء استدعاء الـ API، ويسترجع البيانات، ويمرر النص الخام مرة أخرى إلى النموذج لتنسيقه. النموذج ينسق الاستجابة فقط؛ ولا يلمس مصدر البيانات على الإطلاق.
يسمح هذا الإطار لفرق الأمن بتدقيق وفرض القواعد عند بوابة الـ API، وهو المكان الدقيق الذي اعتادوا القيام بذلك فيه. لست بحاجة إلى اختراع نماذج أمنية جديدة للذكاء الاصطناعي. تحتاج فقط إلى قصر دور النموذج على توليد النوايا (generating intents).
تأمين خطوط أنابيب البيانات في منصات الذكاء الاصطناعي
تتطلب أنظمة المؤسسات عزلاً للبيانات متعدد المستأجرين (multi-tenant data isolation). عندما تبني منصات الذكاء الاصطناعي من أجل B2B SaaS أو للاستخدام الداخلي عبر إدارات متعددة، فإن تسرب البيانات هو الخطر الأساسي.
تُعرف خطوط أنابيب RAG (التوليد المعزز بالاسترجاع) بكونها سيئة السمعة في كشف بيانات عبر المستأجرين (cross-tenant data). إذا قمت بتفريغ جميع مستندات مؤسستك في قاعدة بيانات موجهة (vector database) واحدة دون ضوابط وصول صارمة، سيسترد النموذج حتماً مستندات مقيدة للإجابة على أسئلة عامة.
نحن نفرض حدود البيانات في طبقة الإدخال (ingestion layer). عندما يتم تضمين (embedded) مستند وتخزينه في قاعدة البيانات الموجهة، نرفق علامات بيانات وصفية (metadata tags) صارمة تتوافق مع معرفات المستأجرين (tenant IDs)، وأدوار المستخدمين (user roles)، ومستويات التصريح الأمني.
أثناء مرحلة الاسترجاع (retrieval phase)، يتم تصفية الاستعلام (query) بشدة. قبل أن يبدأ بحث التشابه (similarity search) حتى، يفرض النظام مرشح بيانات وصفية (metadata filter) استناداً إلى الرمز المميز لجلسة المستخدم (session token) الحالي. تتجاهل قاعدة البيانات الموجهة ببساطة أي سجلات غير مصرح للمستخدم برؤيتها.
يضمن هذا أن نافذة السياق (context window) المحقونة في الـ LLM تحتوي فقط على البيانات التي يمكن للمستخدم بالفعل الوصول إليها. حتى إذا وجه المستخدم النموذج تحديداً لتجاهل القيود الأمنية، فإن نظام الاسترجاع رياضياً لا يمكنه إرجاع البيانات المحظورة.
يلبي هذا النهج القوانين الصارمة لإقامة البيانات في الإمارات ويمتثل لمتطلبات السرية في التمويل الإسلامي، حيث يُفرض فصل البيانات بصرامة.
تجاوز نماذج إثبات المفهوم (Proof-of-Concepts)
تتحرك شركات الخليج بسرعة وتمتلك الميزانية لنشر أنظمة متطورة، ولكن غالباً ما تصطدم الفرق الداخلية بحائط مسدود عند الانتقال من عرض توضيحي (demo) محلي إلى بيئة الإنتاج. يكتشفون أن المعماريات التي يتم تدريسها في البرامج التعليمية غير متوافقة بشكل أساسي مع معايير الأمان المؤسسية.
لا يمكنك ترقيع (duct-tape) الأمان على نموذج ذو صلاحيات مفرطة (over-privileged model). يجب أن تصمم النظام وفقاً لمبادئ انعدام الثقة (zero-trust principles) منذ أول عملية تثبيت (commit).
إذا كنت تقيم شركاء الذكاء الاصطناعي في الإمارات أو باكستان، احجز مكالمة تحديد نطاق مدتها 30 دقيقة مع Seven Labs: https://calendly.com/seven-labs-intro

