الـ 9 أماكن اللي نظام AI تبعك بيسرّب بيانات منها (وكيف تسد كل وحدة)

ليش التشفير ما بيحل المشكلة

الرد الافتراضي على "نظام AI تبعنا بيتعامل مع بيانات حساسة" هو "رح نشفرها." التشفير بيحمي البيانات وقت التخزين ووقت النقل. ما بيعمل شي للبيانات وقت الاستخدام. لحظة التطبيق بيفك تشفير بيانات العميل لبناء برومبت، هالبيانات صارت مكشوفة لمزود الـ LLM، مدمجة بمخازن الـ vectors، مكتوبة بالسجلات، ممررة عبر استدعاءات الأدوات، مخزنة بالكاش، ومسجلة بتقارير الأخطاء.

أنظمة AI بتسرب بيانات بطرق التطبيقات التقليدية ما بتسربها. سطح الهجوم مش الشبكة أو قاعدة البيانات. هو الـ pipeline: كل خطوة بين استقبال مدخلات المستخدم وتسليم الرد بتخلق نقطة تسرب محتملة.

رسمنا خارطة لكل نقطة تسرب بأنظمة AI اللي بنيناها ونشرناها. هالمقال هو النتيجة. للحل المعماري (الترميز الدلالي، حدود الثقة، الاستعادة حسب السياسات)، شوف دليل التوافق مع GDPR. هالمقال بيركز تحديداً على وين التسربات بتصير وكيف تكشفها.

الـ 9 نقاط تسرب

User Input (contains PII)
    │
    ├──▶ 1. PROMPTS ────────────▶ LLM Provider sees raw data
    │
    ├──▶ 2. EMBEDDINGS ─────────▶ Vector DB stores PII permanently
    │
    ├──▶ 3. LOGS ───────────────▶ Log aggregator indexes PII
    │
    ├──▶ 4. TOOL CALLS ─────────▶ External APIs receive PII in parameters
    │
    ├──▶ 5. AGENT MEMORY ───────▶ Conversation history stores PII
    │
    ├──▶ 6. ERROR MESSAGES ─────▶ Error tracking captures PII in stack traces
    │
    ├──▶ 7. CACHE ──────────────▶ Response cache stores PII in cached answers
    │
    ├──▶ 8. FINE-TUNING DATA ───▶ Training data contains PII permanently
    │
    └──▶ 9. AGENT HANDOFFS ─────▶ PII crosses trust boundaries between agents

1. البرومبتات (Prompts)

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

وين بتتسرب:

• الـ API تبع مزود الـ LLM بيستقبل البرومبت الكامل
• المزود ممكن يسجل البرومبتات لكشف سوء الاستخدام
• المزود ممكن يستخدم البرومبتات لتحسين النموذج (حسب شروط الخدمة والفرق بين API والطبقة الاستهلاكية)

كيف تسدها: استبدل الـ PII الخام بتوكنات دلالية قبل ما البرومبت يوصل للـ LLM. النموذج بيستقبل {{person:p_001}} بدل الاسم الحقيقي. التوكن بيحمل metadata (الجنس، الرسمية، اللغة) فالنموذج يقدر ينتج مخرجات صحيحة.

// قبل: PII بالبرومبت
const prompt = `Write a reply to Sara Mustermann about order #12345`;

// بعد: برومبت مرمّز
const transformed = await guardai.transform(prompt);
// transformed.safe_text = "Write a reply to {{person:p_001}} about order {{order:o_001}}"
const response = await llm.generate(transformed.safe_text);
const final = await guardai.rehydrate(response, transformed.session_state);

2. الـ Embeddings

هاي نقطة التسرب اللي أغلب الفرق بتطنشها كلياً. لما تعمل embed لمستندات لـ RAG، الـ embedding vectors بتشفر معلومات دلالية عن المحتوى. إذا المحتوى فيه PII، الـ embeddings بتحمل تمثيل لهالـ PII بالـ vector store.

وين بتتسرب:

• قاعدة بيانات الـ vectors بتخزن embeddings مشتقة من مستندات فيها PII
• استرجاع المستندات المشابهة ممكن يطلّع PII من استعلامات ما إلها علاقة
• نسخ احتياطية لقاعدة الـ vectors فيها تمثيلات PII

كيف تسدها:

الخيار أ: رمّز المستندات قبل الـ embedding. الـ embeddings بتنبني على نص مرمّز. الـ vector store ما بيحتوي أبداً على vectors مشتقة من PII.

الخيار ب: اعمل embed للمستندات الخام بس رمّز وقت الاستعلام. الـ vector store جوا المنطقة الموثوقة. بس الـ chunks المسترجعة بتعبر للـ LLM، وهاي بتترمّز قبل ما تعبر.

// الخيار أ: embed محتوى مرمّز (أأمن، جودة استرجاع أقل بشوي)
const tokenized = await guardai.transform(documentText);
const embedding = await embedder.embed(tokenized.safe_text);
await vectorStore.upsert({ id: docId, embedding, metadata: { tokenized: true } });

// الخيار ب: embed خام، ترميز وقت الاستعلام (استرجاع أفضل، أعقد)
const embedding = await embedder.embed(documentText); // raw embedding
await vectorStore.upsert({ id: docId, embedding });
// وقت الاستعلام: استرجع chunks، بعدين رمّز قبل الإرسال للـ LLM

لتفاصيل أكثر عن بنية pipeline الـ RAG، شوف دليل موثوقية RAG ودليل بحث الـ vectors.

3. السجلات (Logs)

البنية التحتية لتسجيل البيانات بتصير مخزن PII لحظة ما تسجل البرومبتات أو الردود الخام. كلستر Datadog، CloudWatch، Elasticsearch، أو Grafana Loki تبعك هلق بيعالج بيانات شخصية، كل واحد بيحتاج توثيق GDPR، سياسات احتفاظ، وإجراءات وصول لأصحاب البيانات.

وين بتتسرب:

• سجلات منظمة فيها نص البرومبت
• middleware لتسجيل الطلبات والردود
• سجلات debug وقت التطوير اللي بتوصل للإنتاج
• SDKs تسجيل خارجية بتلتقط أجسام الطلبات

كيف تسدها: سجل IDs التوكنات، مش القيم. سجل أنواع الأحداث، عدد الكيانات، نقاط الثقة، وأسماء السياسات. ما تسجل أبداً النص الخام.

// صح: سجل منظم بدون PII
logger.info('transform_complete', {
    session_id: 'ses_abc',
    entities_detected: 3,
    entity_types: ['person', 'email', 'phone'],
    policy: 'german-support',
    duration_ms: 12,
});

// غلط: PII بالسجلات
logger.info('Processing request', {
    input: 'Sara Mustermann wants to cancel order 12345...',
    // هاي هلق PII بمجمّع السجلات تبعك
});

4. استدعاءات الأدوات (Tool Calls)

بالأنظمة الوكيلية (agentic systems)، الـ AI agent بينادي أدوات خارجية (APIs، قواعد بيانات، خدمات). باراميترات استدعاء الأداة غالباً فيها PII مستخرجة من المحادثة. أداة CRM lookup بتستقبل اسم العميل. أداة فوترة بتستقبل رقم الحساب. أداة إيميل بتستقبل عنوان المستلم.

وين بتتسرب:

• باراميترات استدعاء الأداة المرسلة لخدمات خارجية
• تسجيل استدعاءات الأدوات (أطر عمل الـ agent غالباً بتسجل كل استدعاء)
• بيانات رد الأداة المخزنة بذاكرة الـ agent

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

Agent: "Look up customer {{person:p_001}}"
  │
  ▼ (trust boundary)
Runtime: resolves p_001 to "Sara Mustermann"
Runtime: calls CRM API with real name
Runtime: gets response with real data
Runtime: tokenizes response
  │
  ▼
Agent receives: "Customer {{person:p_001}}, account {{customer_id:cid_001}}"

الـ agent ما بيشوف أو يخزن القيم الخام أبداً. الخدمة الخارجية بتشتغل جوا المنطقة الموثوقة. لكيف ننفذ هالشي بالتجارة الوكيلية، شوف دليل بروتوكول التجارة الوكيلية.

5. ذاكرة الـ Agent

أنظمة AI الوكيلية بتحافظ على ذاكرة المحادثة عبر الأدوار. هالذاكرة بتخزن كل تاريخ المحادثة، بما فيها أي PII شاركها المستخدم. إذا الذاكرة محفوظة (Redis، قاعدة بيانات)، الـ PII بتتراكم مع الوقت.

وين بتتسرب:

• تاريخ المحادثة بالذاكرة خلال الجلسة
• ذاكرة محفوظة بقواعد بيانات أو مخازن key-value
• ذاكرة طويلة الأمد مستخدمة للتخصيص عبر الجلسات
• ذاكرة مشتركة بين agents بأنظمة multi-agent

كيف تسدها: حدد نطاق الذاكرة حسب المستأجر، الجلسة، والخيط. رمّز PII بالذاكرة نفس ما بترمّز البرومبتات. حط TTLs على الذاكرة المحفوظة. ما تشارك الذاكرة أبداً عبر حدود المستأجرين.

// نطاق الذاكرة: مستأجر + جلسة + خيط
const memoryKey = `${tenantId}:${sessionId}:${threadId}`;

// محتوى الذاكرة مرمّز
const memory = [
    { role: 'user', content: 'I am {{person:p_001}}, my order is {{order:o_001}}' },
    { role: 'assistant', content: 'Let me check order {{order:o_001}} for you, {{person:p_001}}.' },
];

// TTL: الذاكرة بتنتهي بعد نهاية الجلسة
await memoryStore.set(memoryKey, memory, { ttl: SESSION_TTL });

لأنماط عزل الذاكرة بأنظمة multi-tenant، شوف دليل تصميم الأنظمة متعددة المستأجرين.

6. رسائل الأخطاء (Error Messages)

لما شي يفشل، رسائل الأخطاء والـ stack traces غالباً فيها البيانات اللي سببت الفشل. خطأ JSON parse بيتضمن الـ JSON الخام. خطأ validation بيتضمن قيمة الحقل غير الصالحة. خطأ API timeout بيتضمن payload الطلب.

وين بتتسرب:

• خدمات تتبع الأخطاء (Sentry، Bugsnag، Datadog APM)
• Stack traces بردود السيرفر
• سجلات أخطاء مع سياق الطلب
• مراسلات الاستثناءات غير المعالجة

كيف تسدها: نظف payloads الأخطاء قبل إرسالها لخدمة تتبع الأخطاء. شيل أجسام الطلبات من سياق الخطأ. اعمل mask للـ PII برسائل الأخطاء. ما ترجع أبداً تفاصيل الخطأ الخام للعملاء.

// middleware تنظيف الأخطاء
function sanitizeError(error: Error, context: any): SanitizedError {
    return {
        message: error.message,
        code: error.code,
        // شيل PII من السياق
        context: {
            session_id: context.session_id,
            entity_types: context.entity_types,
            // ما تحط: context.input, context.prompt, context.customerData
        },
    };
}

7. الكاش (Cache)

تخزين الردود بالكاش بيحفظ الرد الكامل، بما فيه أي PII بالجواب المُنشأ. إذا رد مخزن بالكاش فيه "طلب Sara Mustermann انشحن مبارح"، كل مستخدم تاني بيطلع نفس مفتاح الكاش بيشوف بيانات Sara.

وين بتتسرب:

• كاش ردود على مستوى التطبيق (Redis، Memcached)
• كاش CDN (إذا ردود AI مخزنة على الحافة)
• كاش دلالي (أسئلة مشابهة بترجع أجوبة مخزنة فيها PII)

كيف تسدها: خزّن ردود مرمّزة بالكاش، مش ردود معاد ترطيبها. الكاش بيخزن {{person:p_001}}'s order was shipped yesterday. كل طلب مستخدم بيعيد الترطيب بخارطة الجلسة الخاصة فيه.

بديل تاني: حط ID الجلسة أو المستأجر بمفتاح الكاش فالردود المخصصة ما بتنعرض أبداً للمستخدم الغلط.

8. بيانات التدريب الدقيق (Fine-Tuning Data)

إذا عملت fine-tune لنموذج على بيانات العملاء، هالبيانات مدمجة بشكل دائم بأوزان النموذج. ما فيك تستخرج سجلات محددة من نموذج متدرب. ما فيك تلتزم بطلب حذف GDPR لبيانات استُخدمت بالتدريب.

وين بتتسرب:

• مجموعات بيانات التدريب اللي فيها PII
• أوزان النموذج (البيانات مشفرة، مش قابلة للاستخراج بس بتأثر على المخرجات)
• بيانات التدريب المخزنة عند مزود النموذج وقت الـ fine-tuning

كيف تسدها: رمّز بيانات التدريب قبل الـ fine-tuning. النموذج بيتعلم أنماط من نص مرمّز، مش من PII حقيقية. إذا لازم تستخدم بيانات حقيقية لجودة الـ fine-tuning، وثّق الأساس القانوني، طبّق سياسات احتفاظ بالبيانات، وكون مستعد تعيد تدريب النموذج إذا طلب حذف تطلّب هالشي.

9. تسليمات الـ Agents (Agent Handoffs)

بأنظمة multi-agent، agent ممكن يسلم محادثة لـ agent تاني. التسليم عادةً بيتضمن سياق المحادثة، اللي فيه PII من التفاعل. إذا الـ agents بيشتغلوا عبر حدود ثقة مختلفة (خدمات مختلفة، مزودين مختلفين)، الـ PII بتعبر هالحدود وقت التسليم.

وين بتتسرب:

• رسائل التسليم بين الـ agents
• مخازن سياق مشتركة بتستخدمها عدة agents
• استدعاءات API بين الـ agents اللي بتحمل حالة المحادثة
• خدمات orchestrator اللي بتوجه بين الـ agents

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

لكيف نصمم بنيات multi-agent مع عزل صحيح، هداك الدليل بيغطي الأنماط.

حارس المخرجات: كشف اللي النموذج بيخترعه

بعد الـ 9 نقاط تسرب على جهة المدخلات، في مشكلة عاشرة: النموذج ممكن يهلوس PII ما كانت بالمدخلات الأصلية. إذا طلبت من النموذج يكتب رد لـ {{person:p_001}}، ممكن يخترع رقم تلفون، عنوان، أو اسم شركة من بيانات التدريب.

هالـ PII المُختلقة مش محمية بالترميز لأنها ما ترمّزت أصلاً. الحل هو كشف بمرحلة ثانية على مخرجات النموذج:

async function outputGuard(response: string, sessionTokens: Set<string>): GuardResult {
    // شغّل كشف PII على رد النموذج
    const detected = await detector.detect(response);

    // تحقق من كل كيان مكشوف مقابل توكنات الجلسة المعروفة
    const unknown = detected.filter(entity => !sessionTokens.has(entity.tokenId));

    if (unknown.length > 0) {
        return {
            safe: false,
            flagged: unknown,
            action: 'remove_or_flag', // شيل PII غير المعروفة أو علّمها للمراجعة
        };
    }

    return { safe: true };
}

حارس المخرجات بيلتقط: أرقام تلفون مُختلقة، عناوين مُهلوسة، أسماء شركات حقيقية من بيانات التدريب، وأي PII تانية النموذج بينتجها وما كانت بالمدخلات الأصلية.

لتفاصيل أكثر عن أنماط فشل AI بما فيها الهلوسة، هداك الدليل بيغطي الأنماط الأوسع.

أولوية الكشف

مش كل نقاط التسرب بنفس الخطورة. رتّب الأولويات حسب سطح التعرض وحساسية البيانات:

ابدأ بـ P0 (البرومبتات والسجلات). هاي الأعلى حجماً والأسهل بالإصلاح. بعدين عالج P1 (استدعاءات الأدوات، الذاكرة، الأخطاء). P2 وP3 مهمين بس أقل إلحاحاً.

أخطاء شائعة

1. التفكير إنو التشفير بيحل المشكلة. التشفير بيحمي النقل والتخزين. ما بيعمل شي لما البيانات بتنفك لأجل المعالجة، وهاد بالضبط اللي الـ LLM بيعمله.

2. حماية بس استدعاء الـ LLM النهائي. سير عمل agent من 5 خطوات عنده 5 سطوح تسرب. حماية بس خطوة التوليد بتخلي 4 بدون حماية.

3. تسجيل البرومبتات لأغراض الـ debugging. كل برومبت بتسجله هو PII بمجمّع السجلات تبعك. سجل IDs التوكنات، أنواع الكيانات، والـ metadata بدله.

4. بدون حارس مخرجات. النموذج بيهلوس PII من بيانات التدريب. بدون كشف بمرحلة ثانية على المخرجات، PII مُختلقة بتوصل للمستخدم النهائي.

5. تخزين ردود معاد ترطيبها بالكاش. إذا الكاش بيخزن "طلب Sara Mustermann انشحن"، أي مستخدم بيطلع نفس مفتاح الكاش بيشوف بيانات Sara.

6. التدريب الدقيق على بيانات عملاء خام. بمجرد ما الـ PII تصير بأوزان النموذج، ما بتنستخرج أو تنحذف. رمّز بيانات التدريب.

7. تجاهل تتبع الأخطاء. Sentry وBugsnag بيلتقطوا سياق الطلب بشكل افتراضي. هالسياق فيه PII إذا طلباتك فيها PII.

8. ذاكرة agent مشتركة عبر المستأجرين. Agent A بمستأجر لازم ما يكون عنده وصول لمحادثة Agent B بمستأجر تاني.

النقاط الأساسية

• أنظمة AI عندها 9 نقاط تسرب مميزة. البرومبتات، الـ embeddings، السجلات، استدعاءات الأدوات، ذاكرة الـ agent، رسائل الأخطاء، الكاش، بيانات التدريب الدقيق، وتسليمات الـ agents. كل وحدة بتحتاج استراتيجية حماية خاصة.

• التشفير ما بيساعد وقت المعالجة. البيانات لازم تنفك قبل ما الـ LLM يقدر يعالجها. الحماية لازم تصير على طبقة التطبيق، مش طبقة النقل.

• الترميز الدلالي هو الحل المعماري. استبدل القيم الخام بتوكنات بتحمل metadata. الـ LLM بيعالج توكنات. القيم الحقيقية بتبقى جوا المنطقة الموثوقة.

• حارس المخرجات بيلتقط PII المُهلوسة. النموذج بيخترع بيانات من مجموعة التدريب. كشف بمرحلة ثانية على المخرجات بيلتقط كيانات ما كانت بخارطة توكنات الجلسة.

• ابدأ بالبرومبتات والسجلات (P0). هاي الأعلى حجماً والأسهل بالإصلاح. بعدين عالج استدعاءات الأدوات، الذاكرة، والأخطاء (P1).

• كل نقطة تسرب بتحتاج مراقبة. تتبع كم كيان PII انكشف، كم ترمّز، كم فلت. نبّه على الشذوذات.

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