إخفاء البيانات في AI Gateway: ما الذي يعمل بالفعل

ما هو إخفاء البيانات بالفعل

يستبدل إخفاء البيانات (Data masking) القيمة الحساسة ببديل آمن للكشف، مع الحفاظ على إمكانية استخدام البيانات المحيطة. يأتي هذا من عالم قواعد البيانات: إعطاء فريق ضمان الجودة (QA) نسخة من الإنتاج حيث يكون كل رقم بطاقة 4111-****-****-1234 ويمكنهم اختبار أشكال واقعية دون الاحتفاظ بمعلومات تعريف شخصية (PII) حقيقية. توجيه ذلك إلى بوابة LLM يغير الأمر — فأنت تخفي نصًا حرًا، في طريقه إلى طرف ثالث، داخل محادثة يجب أن تظل منطقية.

تُستخدم هذه المصطلحات كمرادفات باستمرار. وهي ليست مرادفات.

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

إخفاء الهوية المستعار ليس إخفاءً كاملًا للهوية. بموجب GDPR، تعد البيانات المستعارة الهوية لا تزال بيانات شخصية ولا تزال ضمن النطاق؛ فقط البيانات المجهولة الهوية بحق هي التي تخرج عن نطاق اللائحة (الحيثية 26). استبدال كل اسم بـ User-8812 مستقر هو إخفاء هوية مستعار، وتسميته بالأخير لن يصمد أمام المراجعة.

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

ما الذي يتعطل عند إخفاء حركة مرور LLM

هذا هو الجزء الذي تتجاهله معظم المقالات، وهو يحدد ما إذا كان تصميمك سينجو أم لا.

تتدهور جودة مخرجات النموذج بشكل غير متساوٍ. تحويل Call our office at 312-555-1234 إلى Call our office at ************ يجعل النموذج لا يعرف بعد الآن أن ذلك كان رقم هاتف — فالنجمات لا تحمل معلومات النوع. تحافظ النواب المعلمة مثل [PHONE_NUMBER] على النوع، على حساب إخبار أي شخص يرى المطالبة بما كان موجودًا هناك. التلخيص يقاد يلاحظ ذلك؛ والاستخراج يفشل بصوت عالٍ؛ والربط بين كيانين يفشل بهدوء، وهو أمر أسوأ.

تستدعي الأدوات الحاجة إلى القيمة الحقيقية. الفشل الأكثر حدة. الوكيل الذي يخفي customer@acme.com في طريقه للداخل لا يمكنه بعد ذلك استدعاء lookup_account(email=...). يخلق إخفاء مسار النموذج وترج مسار الأداة مفتوحًا الثغرة المعاكسة: لم ير النموذج العنوان أبدًا، لكن وسائط الأداة تحمله إلى خادم MCP تابع لطرف ثالث. حدد، لكل أداة، أيها أكثر موثوقية.

تتعطل المخرجات المهيكلة ومخططات JSON. إذا كنت تقوم بإجراء مخرجات مهيكلة باستخدام JSON Schema، فقد ينتج عن الإخفاء قيمة لم تعد ترضي حقلها الخاص: لا يمكن لحقل format: email أن يحمل [REDACTED EMAIL]، ولا يمكن لحقل عدد صحيح أن يحمل نجمات. الإخفاء الحافظ للطول أكثر ملاءمة لأنه يحافظ على الشكل. إخفاء مرحلة المخرجات أسوأ — فقد أنتج النموذج JSON صالحًا، وأعاد برنامج الإخفاء كتابة قيمة بداخله، ويقوم المحلل البرمجي الخاص بك بالطرح على استجابة أصلحها النموذج بشكل صحيح.

الاتساق متعدد الجولات. الجولة الأولى: "Priya Raman هي مالكة الحساب." الجولة الرابعة: "هل ما زالت تملكه؟" إذا أصبحت الجولة الأولى نجمات، فلن يكون لدى النموذج خيط يتبعه. يحل إخفاء الهوية المستعار الحتمي هذا، ولكن فقط إذا كان برنامج الإخفاء يحافظ على الحالة عبر الجولات — وهو ما لا يفعله حاجز الحماية عديم الحالة (stateless).

استرجاع RAG مقابل النص المخفي. إخفاء المستندات قبل الفهرسة يجعل التضمين لا يحتوي بعد الآن على الكيان، لذا لن يسترجع الاستعلام عنه الشريحة (chunk). قم بالفهرسة بدون إخفاء والإخفاء في وقت الاسترجاع، وستحتفظ مخزن المتجهات بالمتن غير المخفي — الشيء الذي كنت تتجنبه.

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

أين تخطئ الفرق في هذا

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

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

التعامل مع تنقيح السجلات كعنصر تحكم في تدفق البيانات. يحد تنقيح السجلات المخزنة من الأشخاص داخل شركتك الذين يقرؤون المطالبات. ولكن المزود لا يزال يتلقى النص الأصلي.

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

كيف يعمل الإخفاء في TrueFoundry

الإخفاء ليس منتجًا منفصلًا هنا. يحمل كل حاجز حماية إعدادين — Operation Mode و Enforcement Strategy — الإخفاء هو قيمة الإعداد الأول.

Mutate مقابل Validate

الأولوية هي نموذج الترتيب بأكمله للإخفاء. تعمل ثلاثة حواجز حماية للمحولات (mutate guardrails) على خطاف (hook) واحد بالترتيب، حيث يرى كل منها مخرجات الحاجز الذي قبله: يعني مخفي الأسرار عند الأولوية 1 ومخفي التعبيرات النمطية (regex) عند الأولوية 2 أن حاجز حماية regex يطابق النص الذي يقرأ بالفعل ***REDACTED***.

تحويل المدخلات (Input mutation) حاظر ويعمل أولاً — لا يمكن أن يبدأ طلب النموذج حتى تصبح المطالبة نهائية. ثم يعمل التحقق من صحة المدخلات (Input validation) في الخلفية جنبًا إلى جنب معه، وإذا فشل التحقق في منتصف الرحلة، تلغي البوابة طلب النموذج حتى لا تدفع ثمنه. يعمل تحويل المخرجات والتحقق من صحتها تزمنيًا بعد وصول الاستجابة، وفي هذه نقطة يكون قد تم تكبد تكلفة النموذج.

تضيف استدعاءات أدوات MCP خطافين متزامنين: ما قبل الاستدعاء (pre-invoke)، حيث يترتب على الفشل عدم تشغيل الأداة أبدًا، و ما بعد الاستدعاء (post-invoke)، حيث يترتب على الفشل حجب النتيجة. تعمل حواجز الحماية على كل استدعاء أداة بشكل منفصل — خمس أدوات تعني خمس مجموعات من الفحوصات.

Enforce مقابل Enforce But Ignore On Error

يفصل الإعداد الثاني بين عطلين: وجد حاجز الحماية شيئًا ما، مقابل تعطل حاجز الحماية نفسه.

الاستراتيجية

عند الانتهاك

عند خطأ حاجز الحماية

Enforce

حظر

حظر (فشل مغلق - fail-closed)

Enforce But Ignore On Error

حظر

السماح بالمرور (تدهور سلس - graceful degradation)

Audit

السماح بالمرور، وتسجيل فقط

السماح بالمرور

تسمي المستندات Enforce But Ignore On Error "الإعداد الافتراضي الأكثر أمانًا" وتوصي بالتدرج Audit ← Enforce But Ignore On Error ← Enforce.

أي من الميزات المدمجة يمكنها الإخفاء بالفعل

"لدينا حاجز حماية PII" لا يخبرك بأي شيء عما إذا كان يمكنه الإخفاء.

إن PII / PHI Detection هو الاستثناء: لا يمكنه الحظر، بل الإخفاء فقط. إذا كان الشرط هو "رفض أي طلب يحتوي على SSN"، فهذا ليس حاجز الحماية المطلوب.

خيارات استراتيجية الفرض الموثقة هي enforce و enforce_but_ignore_on_error فقط — خيار audit غير مدرج، على عكس Secrets و Regex و SQL Sanitizer. طرح Audit أولاً ليس موحدًا عبر الميزات المدمجة. [تحقق] مما إذا كان ذلك قيدًا حقيقيًا أم فجوة في المستندات.

يعطي Regex Pattern Matching تسميات نائبة بدلاً من النجمات. يأتي مع 46 إعدادًا مسبقًا — SSN، البطاقات الائتمانية، جوازات السفر لـ 10 دول، مفاتيح السحابة، رموز GitHub و Slack، وأنوين IP — بالإضافة إلى أنماط مخصصة، مثل EMP-\d{6} ← [REDACTED EMPLOYEE ID].

من بين تكاملات حوامل الحماية الخارجية، تشمل الحواجز القادرة على التغيير (mutate) كل من Google Model Armor و CrowdStrike AIDR و F5 AI Security و TrojAI و Enkrypt AI و Pillar Security و Lasso (classifix) و HiddenLayer (/redact-*) و DeepKeep و Noma — والأخيران يتطلبان Mutate. أما الحواجز القائمة على Validate فقط فهي: Cisco AI Defense و Gray Swan Cygnal و Patronus و NVIDIA NeMo و Guardrails AI و Arthur AI. طلب الإخفاء من بائع يقدم validate-only هو طريق مسدود.

يحمل Google Model Armor فخ تكوين: يتطلب Mutate كلاً من قالب فحص SDP وقالب إزالة الهوية في Google Cloud، المرتبطين بقالب Model Armor، مع ضبط التحويل على "Replace with infoType name". بدون كلاهما، يفشل التغيير (mutate).

سؤال إلغاء الإخفاء، تمت الإجابة عليه بوضوح

حواجز حماية الإخفاء الخاصة بـ TrueFoundry هي ذات اتجاه واحد. يرى النموذج القيمة المخفية وكذلك المتصل. لا توثق PII / PHI Detection و Secrets Detection و Regex Pattern Matching أي طريقة لاستعادة الأصل، ولا توجد خزنة رموز على مستوى البوابة أو خطوة إعادة ترطيب في المستندات اعتبارًا من سبتمبر 2026.

توجد رحلة ذهاب وإعادة موثقة واحدة فقط، وهي تابعة لجهة خارجية. يدعم CrowdStrike AIDR التشفير الحافظ للشكل: عندما تكون Operation هي Mutate ومشفرة قيم مرحلة المدخلات بـ FPE، تُمرر البوابة سياق fpe_context الناتج إلى AIDR في مرحلة المخرجات كـ input_fpe_context وتستدعي POST {baseUrl}/v1/unredact، بحيث تُستخدم المفاتيح نفسها من البداية إلى النهاية. مسار حقيقي قابل للعكس — ولكنه يحتاج إلى CrowdStrike، ووضع Mutate، و fpe_context من مرحلة المدخلات.

لذا إذا كان تطبيقك يحتاج إلى القيمة الحقيقية مرة أخرى، فلا تخطط للحصول عليها من البوابة. احتفظ بها في تطبيقك، وأرسل النسخة المخفية، وأعد الانضمام بناءً على معرف تتحكم فيه. هناك سلوك واحد متعلق بـ AIDR يفاجئ الناس: بمجرد أن يثير انتهاكًا، فإن Mutate لا يخففه إلى تنقيح — بل يستمر الطلب برمز 400.

مثال عملي: مساعد الطيار للدعم الداخلي

يقوم مساعد طيار الدعم بقراءة نص التذكرة والبحث عن سجلات الحساب من خلال خادم MCP. تحتوي التذاكر بشكل روتيني على البريد الإلكتروني للعميل وأرقام الهواتف ومعرفات الموظفين الداخلية.

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

اختر الأوضاع والأولويات. PII / PHI Detection على مدخلات LLM، وضع Mutate (وضعه الوحيد)، الأولوية 1. Regex Pattern Matching على مدخلات LLM، وضع Mutate، الأولوية 2، نمط مخصص EMP-\d{6} ← [REDACTED EMPLOYEE ID]. Secrets Detection على مخرجات LLM، وضع Mutate. ابدأ كل منها في أكثر استراتيجية مرونة يدعمها.

حدد مسار الأداة بعناية. يحتاج البحث عن الحساب إلى البريد الإلكتروني الحقيقي، لذا تستهدف قاعدة الإخفاء النموذج، وليس خادم MCP؛ يعمل Secrets Detection على MCP Post-Invoke بدلاً من ذلك، لالتقاط الاعتمادات التي تعود في نتيجة الأداة. اكتب السبب: خادم MCP داخل VPC الخاص بك ومزود النموذج ليس كذلك. هذه الجملة هي عنصر التحكم الفعلي.

اربطه بسياسة. إن تسجيل حاجز حماية لا يطبقه على حركة المرور. انتقل إلى AI Gateway ← Policies ← Guardrails ← Add Rule ونطاقها حسب الأهداف (النماذج، وخوادم MCP، واختياريًا لكل أداة)، والموضوعات (المستخدمون، والفرق، والحسابات الافتراضية مع IN / NOT IN)، والبيانات الوصفية، والخطافات. يتم دمج القواعد المتطابقة لكل خطاف.

راقبه قبل أن تثق به. كل حاجز حماية هو نطاق (span) خاص به في Monitor ← Request Traces، مع وقت التنفيذ والنتيجة والنطاق والمدخلات والمخرجات والتغييرات. معدل تغيير يقارب الصفر على خطاف مزدحم يعني أن أنماطك خاطئة؛ ومعدل يقارب 100% يعني أنك على وشك معرفة ما يفعله الإخفاء بجودة الإجابة.

هل أنت مستعد لتجربته على مسار واحد؟

قم بتسجيل حاجز حماية PII، واربط سياسة بنموذج واحد، واقرأ نطاقات التغيير.

ابدأ مجانًا

مشاكل غير متوقعة تستحق المعرفة

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

لا يتم إخفاء المطالبات النظامية (System prompts) أبدًا. تجرد البوابة المطالبات قبل إرسال المحتوى إلى أي حاجز حماية، لذا لا يتم فحصها أو حظرها أو تنقيحها أبدًا. الاستثناء الوحيد هو CrowdStrike AIDR، الذي يرى مطالبة النظام ولكنه لا يعدلها أبدًا. إن وضع مفتاح في مطالبة النظام لن ينقذك معه أي حاجز حماية للإخفاء.

تنقيح السجلات هو عنصر تحكم مختلف عن Mutate. ينقح تكوين تسجيل القواعد الخاص بـ TrueFoundry الأنماط من الهيئات المخزنة بدلالات القواعد الرافضة (deny-wins) — حيث تقوم قاعدة متطابقة واحدة مع إيقاف تشغيل Log بحجب الهيئة تمامًا. لكن المستندات صريحة: "يتم تطبيق التنقيح فقط على النسخة المسجلة... لا يتم تعديل الطلب المباشر المحول إلى مزود النموذج أبدًا." فهو يحكم من داخل شركتك يقرأ المطالبات، وليس ما يغادرها. منشورنا المصاحب حول منع فقدان البيانات لحركة مرور LLM يغطي الخروج.

يمكن أن يحول الترتيب الحظر إلى مرور. يوثق DeepKeep هذا بشكل ملموس: فهو يطبق الأسبقية المدرجة أولاً بين القواعد التي تم إطلاقها، وليس الإجراء الأشد خطورة. "إذا تم إدراج PII قبل Adversarial، فإن كسر الحماية (jailbreak) الذي يتعثر أيضًا في PII يتم تنقيحه والسماح به بدلاً من حظره." ينطبق ذلك على أي سلسلة تغيير (mutate) — ضع القواعد التي يجب أن تحظر قبل القواعد التي تخفي.

إن PII / PHI Detection مستضاف على TrueFoundry فقط. يعمل على Azure AI Language وهو غير متوفر في عمليات النشر المستضافة ذاتيًا أو الهجينة ("Gateway Plane only"). استخدم Azure PII بمفتاحك الخاص، أو CrowdStrike.

قراءات ذات صلة

• منع فقدان البيانات لحركة مرور LLM — جانب الاكتشاف والخروج
• تنقيح PII: البوابة مقابل التطبيق — أين يجب أن يعيش عنصر التحكم
• شرح حواجز حماية TrueFoundry AI Gateway — نموذج حاجز الحماية الكامل
• مخرجات LLM المهيكلة ومخطط JSON — لماذا يتصادم الإخفاء والمخططات
• بناء إطار عمل حوكمة الذكاء الاصطناعي — طبقة السياسة في الأعلى

الخلاصة

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

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

ثم ابنه بشكل ضيق: ابدأ في Audit حيث يسمح حاجز الحماية بذلك، واقرأ أسبوعًا من الآثار (traces)، وقم بالترقية إلى Enforce But Ignore On Error، واحتفظ بـ Enforce الكامل للمسارات التي يكون فيها الفشل المغلق صحيحًا. البوابة هي المكان المناسب لهذا العمل — النقطة الوحيدة التي يمر من خلالها كل نموذج وفريق ووكيل. لكن قاعدة الإخفاء التي لم تشاهدها هي قاعدة لا تفهمها.

ضع الإخفاء على مسار واحد واقرأ الآثار

ابدأ مجانًا