RAG ووكلاء آمنين للـ PII: الترميز القابل للعكس في بيئة الإنتاج

المشكلة: الـ RAG بيسرّب

خليني أحكي معك دغري: أول ما تبني RAG pipeline فوق مستندات شغل حقيقية، فأنت غالباً بنيت ماكينة تسريب بيانات. أسماء العملاء والـ IBANs والمعرّفات الصحية وأرقام الملفات بتطلع من مستنداتك لثلاث أماكن ما إلها ثقة: مزوّد الموديل، والـ vector store، والـ logs عندك. أغلب الفرق ما بتنتبه إلا لما مراجعة أمنية أو جهة تنظيمية تسأل: وين راحت البيانات الشخصية؟

الحل الساذج إنك تشيلها. بتستبدل كل اسم بـ [REDACTED] وبتكمل. هيك بتكسر شغلتين مع بعض. الموديل بيخسر السياق اللي بيحتاجه ليجاوب منيح، والاسترجاع بينهار لأن الاستعلام المقنّع ما عاد يطابق المستندات المقنّعة. أنت بدك البيانات الشخصية تختفي من الأنظمة غير الموثوقة، بس المعنى يضل محفوظ. هي مشكلة أصعب، وإلها حل.

الهدف مش إنك تمسح البيانات الشخصية من الـ AI pipeline عندك. الهدف إنك تضمن إن القيم الخام ما تعبر أبداً لنظام ما بتثق فيه، والموديل يضل معه اللي يكفي ليعمل شغله.

نحنا منبني هالانضباط بأنظمة عملائنا، وبنينا إله runtime خاص: OGuardAI، طبقة حماية بيانات مملوكة إلنا بتقعد بين تطبيقك والموديل. هالدليل هو معمارية عمل AI آمن للـ PII بالطريقة الصح. للزاوية التجارية، شوف دليلنا لمنع تسريب البيانات بالذكاء الاصطناعي، وهاد شغل أساسي ضمن خدمات الذكاء الاصطناعي عندنا.

مين بيهمه شو

حدود الثقة

كل شي بيبلش بخط واحد بترسمه بعرض معماريتك. عجهة، المنطقة الموثوقة: تطبيقك وruntime الحماية. وعالجهة التانية، المنطقة غير الموثوقة: مزوّد الموديل، والـ vector store، وأدوات الطرف الثالث، والـ logs عندك.

   TRUSTED                          │   UNTRUSTED
                                    │
  App ──▶ Protection runtime ──────▶│──▶ LLM provider
          (detect, tokenize)        │──▶ Vector store
          (restore on the way back) │──▶ Logs, tools
                                    │
  raw PII lives here, transiently   │   only tokens cross this line

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

الكشف: تلاقي الأجزاء الحساسة

ما فيك تحمي شي ما بتلاقيه. الكشف بيشتغل عطبقتين.

الأولى أرضية regex حتمية: عشرات الأنماط المبنية عالصيغة وما بتفرق معها اللغة. إيميلات، أرقام تلفونات، IBANs، أرقام ضريبة القيمة المضافة، بطاقات ائتمان متحقق منها بالـ checksum، عناوين IP، هويات وطنية، أرقام ضريبية. هدول سريعين، بحدود الميلي ثانية، وولا مرة بيفوتهم IBAN مكتوب صح لأنهم ما بيعتمدوا عمزاج موديل.

التانية هي التعرف عالكيانات المسماة (NER) للأشياء اللي الـ regex ما بيقدر يمسكها: أسماء أشخاص، منظمات، مواقع، عناوين. هاي بتمشي عبر كاشف مبني عموديل وبتغطي لغات كتير، بس بكلفة زمن استجابة أعلى.

الجزء المهم هو سياسة الفشل. بتختار وضع: builtin بس، أو both مع رجوع نظيف لأرضية الـ regex إذا الـ NER واقع، أو advanced اللي فيه NER إجباري والطلب بيفشل مسكّر إذا ما قدر يشتغل. نظام بينزل بصمت لوضع "بدون كشف PII" لأن sidecar عمل timeout أسوأ من نظام بيرفض الطلب. Fail closed.

Tokens دلالية، مش حجب

هي الفكرة الأساسية اللي بتخلي الموديل يضل مفيد. بدل ما تمسح الكيان المكتشف، بتستبدله بـ token مهيكل بيحمل نوعه وهوية فريدة، بس مش قيمته.

Input:  "Email the invoice to Max Mustermann at max.mustermann@beispiel.de"
Masked: "Email the invoice to {{person:p_001:ad4f97}} at {{email:e_002:5873cc}}"

الـ token بيقول للموديل "في شخص هون" و"في إيميل هون"، وبيخليهم مميزين وقابلين للإشارة، فالموديل بيقدر يكتب رد متماسك عنهم. الاسم الحقيقي والعنوان الحقيقي ولا مرة بيطلعوا برا حدود الثقة عندك. وبطريق الرجعة، الـ runtime بيرجّع القيم الحقيقية بالمخرجات النهائية.

هاد بيتفوق على [REDACTED] بكل شي بيهم. الموديل بيحافظ عالبنية والعلاقات. القيم المتطابقة بتنطبق عنفس الـ token، فالموديل بيفهم إن الذكرين هنّ نفس الشخص. الكيانات القريبة من بعض بتنربط، فالاسم وإيميله بينرجعوا بشكل متماسك. الحجب بيرمي كل هاد.

أوضاع الاسترجاع الستة

مش كل شي لازم يرجع كامل. الاسترجاع بينحكم لكل كيان ولكل قناة إخراج، بست أوضاع.

فرد الدعم للعميل بيقدر يرجّع اسمه كامل، بينما نفس التفاعل لما ينكتب بـ log داخلي بيرجع بس بشكل مقنّع. القناة هي اللي بتقرر. هيك بتقدم جواب مفيد للشخص وبنفس الوقت بتخلي الـ logs عندك نظيفة.

مشكلة الـ RAG: الاسترجاع لازم يضل شغال

هاد الجزء اللي بيوقّع كل فريق بيجرب يبنيها لحاله. إذا قنّعت مستند بـ tokens عشوائية وقت الـ ingestion، وبعدين قنّعت استعلام المستخدم بـ tokens عشوائية مختلفة وقت البحث، الاسترجاع بينكسر. الـ token تبع الاستعلام لـ "Mustermann" ما بيطابق الـ token تبع المستند لـ "Mustermann"، لأنهم انسكّوا بشكل مستقل عن بعض.

الحل هو tokens حتمية محصورة بالـ corpus. جوّا الـ corpus الواحد، القيمة بتترمّز عبر keyed hash بحيث نفس القيمة دايماً تطلّع نفس الـ token، بكل مستند وبالاستعلام. هلق الاستعلام المقنّع بيطابق الـ chunks المقنّعة، لأن "Mustermann" بيترمّز بنفس الشكل عالجهتين.

Ingestion:  doc chunk  "...contract with Mustermann..."  ──▶  "...contract with {{person:h_9f3a...}}..."
Query:      "what did Mustermann sign"                    ──▶  "what did {{person:h_9f3a...}} sign"
                                                                       │
                                        same value ──▶ same token ──▶ retrieval matches

الـ tokens بتشتق لكل corpus من secret، فنفس القيمة بـ corpus تاني هي token ما إله علاقة، وتصادم الـ hash بيفشل مسكّر بدل ما يدمج شخصين مختلفين. هاد اللي بيخليك تشغّل استرجاع فوق مستندات مقنّعة باستعلامات مقنّعة وتضل تجيب نتائج صحيحة. جانب الاسترجاع عموماً منغطيه بـ دليل أنظمة RAG للمؤسسات ودليل معمارية البحث المتجهي. ومع أنماط ذاكرة الوكلاء من دليل ذاكرة الوكلاء، هيك بتبني وكلاء بيتذكروا وبيسترجعوا بدون ما يكنزوا بيانات شخصية.

الجلسات: وين بيعيش الـ mapping

الـ mapping من الـ tokens للقيم الحقيقية لازم يعيش بمكان آمن ويكون قابل للاستخدام عبر الـ replicas. الوضع الافتراضي جلسة مختومة: الـ mapping بينشفّر بـ AES-256-GCM جوّا blob بيسافر مع الطلب، فالسيرفر ما بيمسك أي حالة وأي replica فيها تعالج أي طلب. وللإعدادات المشتركة، في مخزن مشفّر بيحتفظ بس بالـ ciphertext مع بيانات توجيه وصفية غير شخصية.

كل تحميل جلسة بيعيد التحقق من الـ tenant اللي بتتبعه وبيفشل مسكّر عند أي عدم تطابق، فما في tenant بيقدر يفك ختم mapping تبع غيره. الجلسات بتنتهي بـ TTL، والـ blob المعبوث فيه أو المنتهي بينرفض عن طريق authentication tag تبعه. هاي السباكة التشفيرية المملة اللي بتخلي كل الموضوع موثوق، وغلطها هو الطريق اللي بيحوّل "نحنا منرمّز PII" لـ "عنا تسريب secret مشترك". دليل تصميم الأنظمة للفشل عندنا بيغطي هالعقلية الدفاعية.

الـ Policy: بتعلن شو بيصير

ما بتكتب قرارات الحماية جوّا الكود. بتعلنها بـ policy، ليقدر مسؤول أمان أو امتثال يقراها ويغيرها بدون ما يلمس كود التطبيق.

name: support-desk
version: 1.0.0
defaults:
  restore_mode: masked
rules:
  - entity_type: credit_card
    action: redact          # مش قابل للعكس أبداً، وولا مرة بيوصل للموديل
  - entity_type: person
    action: tokenize        # قابل للعكس، بينرجع للعميل
    restore_mode: full
  - entity_type: email
    action: tokenize
    restore_mode: masked    # مقنّع بالـ logs، وكامل للمستخدم حسب القناة

الأفعال صريحة: tokenize للحماية القابلة للعكس، redact للإزالة النهائية، abstract لتسمية عامة. اسم policy مش معروف بيفشّل الطلب بدل ما يرجع لشي متساهل. الأرضية ما فيها تنضعف بالـ policy، بس تتشدد. هاد نمط التفويض عن طريق الإعدادات، وبيطلّع قرار الأمان من الكود المبعثر لمكان واحد قابل للمراجعة. دليل حوكمة الذكاء الاصطناعي بيشرح ليش هالفصل مهم.

الـ Proxy الجاهز للتركيب

أسرع طريقة لحماية تطبيق موجود إنك ما تغيّر فيه شي. proxy شفاف بيحكي نفس الـ API تبع مزوّد الموديل، فبتوجّه الـ SDK عندك لعنوان الـ proxy وهو بيقنّع بطريق الرايح وبيرجّع القيم بطريق الجاي. بدون إعادة كتابة للتطبيق.

Your app ──▶ proxy (mask) ──▶ OpenAI / Anthropic ──▶ proxy (restore) ──▶ your app

الـ proxy بيمسك الجلسة، فتطبيقك ولا مرة بيتعامل مع mapping الـ tokens أصلاً. وللفرق اللي بدها تحكم أدق، في SDKs خفيفة بعدة لغات برمجة بتعطيك نفس الأساسيات مع تكاملات جاهزة لأشهر agent وRAG stacks. بالحالتين، التكامل درزة، مش إعادة كتابة، وهاد اللي بيخلي التبني عملي. فرقنا بـ البرمجيات المخصصة والاستشارات بيركّبوا هالشي بالأنظمة الموجودة.

GDPR: المحو بالإبطال

طلب الحق بالمحو إله جواب نظيف بهالنموذج. بما إن الـ mapping من token لقيمة هو الرابط الوحيد للبيانات الحقيقية بالـ pipeline عندك، بتبطله. الـ mapping المخزن بيحتفظ بس بـ keyed hashes للقيم، ولا مرة بالقيم الخام، وأول ما تنبطل قيمة بترجع كعلامة حذف مهما قال أي blob جلسة. جلسة معاد تشغيلها أو مرجوعة لورا ما فيها تلغي الإبطال.

هاد بيعطيك محو مستهدف وقابل للإثبات عبر كامل الـ AI pipeline، مع إيصال تدقيق وبدون أي بيانات شخصية خام بسجل التدقيق نفسه. الصورة الأوسع للامتثال منغطيها بـ دليل GDPR والذكاء الاصطناعي، وكيف منتعامل معها بالتسليم بصفحات الثقة وGDPR عندنا.

من وين تبلش

1. ارسم خريطة تدفق بياناتك. لاقي كل نقطة بتوصل فيها المستندات أو الرسائل للموديل أو الـ vector store أو الـ logs.
2. ابلش بأرضية الـ regex. الـ PII المهيكلة، IBANs وبطاقات وإيميلات، هي أسرع مكسب وأعلاه يقيناً.
3. ضيف NER وين الأسماء والعناوين مهمة. اختار وضع الفشل عن قصد.
4. استعمل tokens محصورة بالـ corpus للـ RAG. هاد اللي بيخلي الاسترجاع شغال فوق بيانات مقنّعة.
5. أعلن policy، مش كود. حط قرارات الحماية بمكان يقدر مسؤول الامتثال يقراه.

هاد شغل عمراحل وقليل المخاطر، وبيركب عالتسليم المرحلي بـ منهجيتنا. ابلش من التواصل أو خود عرض سعر محدد النطاق.

الطرق الشائعة اللي بيغلط فيها هالشي

1. الحجب بدل الترميز. بتخسر سياق الموديل وبتكسر الاسترجاع. استعمل tokens دلالية قابلة للعكس.
2. Tokens مستقلة للاستعلام والمستندات. الاسترجاع بينكسر. استعمل tokens حتمية محصورة بالـ corpus.
3. تدهور صامت لما يقع الكاشف. "بدون كشف" هو تسريب. Fail closed.
4. منطق الحماية مبعثر بالكود. ما حدا بيقدر يدققه. أعلنه بالـ policy.
5. ما في مسار محو. إذا ما فيك تبطل mapping، ما فيك تلبي طلب GDPR. صمم الحذف من البداية.

مين بيبني هالشي

Oronts شركة برمجيات بميونخ بيقودها مؤسسها. Refaat Al Ktifan، مؤسسنا ومهندس الحلول عندنا، بيقود فريق senior بيغطي الـ backend والأمان والـ AI. OGuardAI هو runtime حماية البيانات تبعنا، بنيناه لأنا احتجنا هالانضباط بشغلنا بالـ AI قبل ما نقدر ننصح فيه عملاءنا. منرسم خريطة تدفق بياناتك، منضيف طبقة الحماية كدرزة، ومنسلمك pipeline فيك تدافع عنه تحت الـ GDPR وقانون الذكاء الاصطناعي الأوروبي. شوف صفحات الخدمات والحلول عندنا.

الخلاصات

• أي RAG pipeline فوق مستندات حقيقية بيسرّب PII للموديل والـ vector store والـ logs عندك بشكل افتراضي.
• رمّز، لا تحجب، ليحافظ الموديل عالسياق وتضل القيم المتطابقة مربوطة ببعضها.
• استعمل tokens حتمية محصورة بالـ corpus ليضل الاسترجاع شغال فوق البيانات المقنّعة.
• خلي mapping الـ tokens بجلسات مشفرة ومربوطة بالـ tenant، وافشل مسكّر عند أي خطأ.
• أعلن الحماية بـ policy، ولبّي المحو بإبطال الـ mapping.

جملة "نحنا منرمّز PII" سهلة الحكي وصعبة التنفيذ الصح. التفاصيل، tokens محصورة بالـ corpus، كشف fail-closed، جلسات مربوطة بالـ tenant، هي اللي بتفرق طبقة حماية حقيقية عن إحساس زائف بالأمان.

إذا الـ AI pipeline عندك بيلمس بيانات شخصية، خبرنا كيف بتتدفق اليوم. ابلش من التواصل أو خود عرض سعر محدد النطاق.