اليوم، وبالمصادفة، تحدثت عن خصوصية محطات وسيطة للـ AI، وكلما تعمّق الحديث شعرت أن هذا ليس مجرد ميزة صغيرة، بل فراغ منتجي كبير: قد لا تكون الطبقة التالية من البنية التحتية لـ AI API هي “وسيطًا أرخص”، بل “بوابة موثوقة لتسوية الخصوصية”.
حاليًا، عندما يقول معظم الناس إن “المحطة الوسيطة غير آمنة”، فمن السهل أن يُفهم الأمر على أنه نقل نصّي مكشوف عبر الشبكة، لكنه ليس كذلك. الاتصال من المستخدم إلى المحطة الوسيطة، ومن المحطة الوسيطة إلى OpenAI، يكون عادةً عبر HTTPS. المشكلة الحقيقية هي: TLS يشفّر فقط حتى نقطة النهاية الحالية. عندما توجه base_url إلى المحطة الوسيطة، تصبح المحطة الوسيطة هي نقطة نهاية TLS، وبطبيعتها تستطيع رؤية prompt وresponse وtool calls وسياق الكود.
وهذا يخلق تناقضًا مثيرًا للاهتمام:
- المستخدم يريد المحطة الوسيطة: تكلفة أقل، واجهة موحدة، توجيه النماذج، مجمع حسابات، إدارة الحصص، وإمكانية الاستخدام داخل الصين.
- والمستخدم في الوقت نفسه لا يريد أن يثق بالمحطة الوسيطة: فالكود، والملفات التجارية، والمحادثات الخاصة، وبيانات العملاء قد تمر كلها من هنا.
- المحطة الوسيطة تريد تنفيذ وظائف كثيرة: السجلات، الفوترة، تحويل البروتوكولات، إعادة المحاولة، استبدال النماذج، والتحكم في المخاطر.
- لكن هذه الوظائف بالذات تتطلب أن تكون قادرة على رؤية النص الصريح.
لذلك يوجد في معماريات البرمجيات العادية حدّ صارم: “أن تكون المحطة الوسيطة قادرة على إرسال النص الصريح الصحيح إلى OpenAI، وفي الوقت نفسه لا تستطيع تقنيًا رؤية النص الصريح إطلاقًا” أمر متناقض. إلا إذا دعمت OpenAI رسميًا تشفير جسم الطلب من طرف إلى طرف، أو وضعت المحطة الوسيطة عملية فك التشفير وإعادة التوجيه داخل TEE قابل للإثبات عن بُعد.
وهنا، على العكس، تظهر عدة اتجاهات منتجية.
الطبقة الأولى هي وسيط كبير من النوع التعاقدي. بدلًا من مجموعة مواقع صغيرة يعد كل منها منفردًا بأنه “لا يطّلع”، تكون هناك AI Gateway كبيرة بما يكفي تتولى التسوية الموحدة: توقيع DPA، وإجراء SOC 2/ISO، وتوضيح عدم حفظ prompt/response، وحفظ metadata فقط، وتعويضات عن التسريب، وشفافية المعالِجين الفرعيين، وSLA للإبلاغ عن الحوادث. ما تحله ليس “عدم القدرة التقنية على الرؤية”، بل “إمكانية المحاسبة إذا حدث شيء”.
الطبقة الثانية هي بوابة توجيه من نوع ZDR. قد لا تكون البوابة غير قادرة على الرؤية، لكنها افتراضيًا لا تسجل سجلات محتوى، وترسل الطلبات فقط إلى مزودين علويين يدعمون Zero Data Retention أو سياسات مؤسسية لعدم التدريب؛ وإذا كان نموذج أو مزود معيّن لا يفي بسياسة البيانات، فلا يتم توجيه الطلب إليه. هذا أقوى بكثير من الصناديق السوداء لدى الكثير من الوسطاء منخفضي السعر اليوم.
الطبقة الثالثة هي بوابة خاصة ذاتية الإنشاء أو مُدارة. تشغّل الشركة أو الفريق بنفسه LiteLLM/Portkey/proxy مكتوبًا داخليًا، مع إيقاف سجلات المحتوى، ووضع المفاتيح في KMS، وتنقيح سجلات الأخطاء، ومنع APM من جمع جسم الطلب. بهذه الطريقة لا يظهر النص الصريح إلا بينك وبين المزودين الرسميين.الطبقة الرابعة هي الشكل الأقرب تقنيًا إلى الحالة المثالية: بوابة تنفيذ موثوق TEE. يجري عميل المستخدم أولًا تصديقًا عن بُعد (remote attestation) للتأكد من أنه متصل بالكود المحدد الذي يعمل داخل عتاد موثوق، ثم يرسل المفتاح/النص الصريح إليه. لا تستطيع خوادم الوساطة العادية، ولا فرق التشغيل والصيانة، ولا أنظمة السجلات رؤية المحتوى؛ وحده الكود داخل enclave يستطيع رؤيته. هذا ليس سحرًا، لكنه يضيّق نطاق الثقة من «محطة الوساطة بأكملها» إلى «عتاد وكود يمكن التحقق منهما».
الطبقة الخامسة هي SDK محلية لإخفاء البيانات الحساسة. تُستبدل الحقول الحساسة على الجهاز نفسه بعناصر نائبة، فيعالج النموذج البنية والمنطق، وبعد عودة النتيجة تُستعاد محليًا. هذا ليس مثاليًا، لكنه عملي جدًا في سيناريوهات مثل العقود وخدمة العملاء والكود والجداول.
أعتقد أن المنتج ذي القيمة الحقيقية قد يبدو هكذا:
بوابة على غرار Cloudflare/Visa موجهة إلى AI API: وصول موحّد إلى النماذج العليا، وتوفير توجيه ZDR، وفوترة metadata-only، وإثباتات استخدام موقّعة، وتدقيق سجلات بلا محتوى، وبنود تعويض، وبوابة خاصة للمؤسسات، وقناة عالية الخصوصية اختيارية عبر TEE، إلى جانب SDK محلية لإخفاء البيانات الحساسة.
اليوم، لا يزال كثير من الوسطاء في السوق يتنافسون على السعر وعدد النماذج، لكن ما قد يكون مكلفًا حقًا في المستقبل ليس token، بل حدود الثقة: من يستطيع رؤية مطالَباتي؟ من يستطيع إثبات أنه لم يحفظها؟ من يتحمل المسؤولية عند حدوث تسريب؟ من يستطيع تحويل «أنا أثق بك» إلى «أستطيع التحقق منك»؟
هذا الأمر يشبه إلى حد كبير بنية تسوية المدفوعات/الأمن السيبراني التحتية في عصر الذكاء الاصطناعي. مزوّدو النماذج في المنبع، والوسطاء والبوابات في المنتصف، والمستخدمون والتطبيقات في المصب. الآن يتسابق الجميع على قدرات النماذج، لكن الخصوصية والتدقيق والتعويض والمفاتيح والسجلات والامتثال في سلسلة استدعاء النماذج نفسها قد تنشئ أيضًا سوقًا كبيرة.