قرارات الذكاء الاصطناعي اللي تقدر تدافع عنها: التدقيق، التتبع والإثبات في الإنتاج

"شو سوى الذكاء الاصطناعي، وتقدر تثبته؟"

هالسؤال يطلع في كل نشر ذكاء اصطناعي للمؤسسات. مش من المهندسين. من القانوني، الامتثال، المشتريات ومجلس الإدارة. الجواب اللي يحتاجونه مش "استخدمنا GPT-4" أو "النموذج اتدرب على بياناتنا." يحتاجون تفاصيل دقيقة: شو البيانات اللي دخلت، أي نموذج عالجها، شو الأدوات اللي انطلبت، مين وافق على الإجراء، وهل السجل ممكن يتحقق منه بعد ما صار القرار.

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

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

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

شو يعني تتبع القرارات فعلياً

تتبع القرارات مش تسجيل. التسجيل يقولك شو صار. التتبع يقولك ليش صار، مين صرح فيه، وهل السجل موثوق.

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

مخطط حدث القرار

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

interface AiDecisionEvent {
    // الهوية
    event_id: string;              // UUID، فريد لكل حدث
    event_type: string;            // "transform", "rehydrate", "tool_call", "agent_action", "approval"
    timestamp: string;             // ISO 8601 UTC

    // الفاعل
    actor_type: string;            // "agent" | "human" | "system" | "scheduler"
    actor_id: string;              // معرف thread الوكيل، معرف المستخدم، أو اسم مكون النظام

    // السياق
    tenant_id: string;             // تحديد النطاق متعدد المستأجرين
    session_id: string;            // يجمع الأحداث ضمن جلسة
    correlation_id: string;        // يربط الأحداث المرتبطة عبر الخدمات
    channel_id?: string;           // أي قناة (web, api, widget)

    // النموذج
    model_provider?: string;       // "openai" | "anthropic" | "local"
    model_id?: string;             // "gpt-4o" | "claude-sonnet-4-20250514"
    model_version?: string;        // إصدار النشر أو checkpoint

    // القرار
    action: string;                // شو انسوى: "generate_response", "call_tool", "approve_order"
    input_summary: object;         // ملخص منظم (بدون PII خام، بس معرفات tokens والأنواع)
    output_summary: object;        // ملخص منظم للنتيجة
    decision_rationale?: string;   // ليش اتخذ هالإجراء (من تفكير الوكيل)

    // السياسة
    policy_id?: string;            // أي سياسة تم تقييمها
    policy_result?: string;        // "allowed" | "denied" | "escalated"
    policy_conditions?: object;    // أي شروط تم فحصها

    // الموافقة (إذا في إنسان في الحلقة)
    approval_required: boolean;
    approval_status?: string;      // "pending" | "approved" | "rejected"
    approved_by?: string;          // معرف المستخدم الموافق
    approved_at?: string;          // وقت الموافقة
    approval_context?: object;     // شو شاف الموافق لما قرر

    // السلامة
    receipt_hmac?: string;         // HMAC-SHA256 لمحتوى الحدث
    previous_event_id?: string;    // رابط السلسلة للحدث السابق في الجلسة
}

قرارات التصميم الأساسية:

ما في PII خام في الأحداث. الـ input_summary يحتوي معرفات tokens (p_001, e_001) وأنواع الكيانات، ما عمره يحتوي قيم خام. هالشي يعني إن مخزن التدقيق عندك ما يصير نظام خاضع لـ GDPR. شوف دليل امتثال GDPR للبنية الكاملة.

تعريف صريح للنموذج. مش بس "استخدمنا LLM." المزود المحدد، معرف النموذج والإصدار مسجلين. لما نموذج يتحدث أو يتبدل، تقدر تتبع أي قرارات استخدمت أي إصدار.

ربط السلسلة. حقل previous_event_id ينشئ سلسلة مرتبطة من الأحداث ضمن الجلسة. الحدث 3 يشير للحدث 2، اللي يشير للحدث 1. السلسلة تثبت تسلسل القرارات وإن ما في أحداث انضافت أو انحذفت بعد الواقعة.

سلاسل القرارات المحددة بالجلسة

تفاعل ذكاء اصطناعي واحد غالباً يتضمن قرارات متعددة. وكيل دعم عملاء ممكن: يقرأ التذكرة (حدث 1)، يبحث عن معلومات العميل (حدث 2)، يفحص الفوترة (حدث 3)، يكتب مسودة رد (حدث 4)، ويرسل الإيميل (حدث 5). كل خطوة هي حدث قرار. مع بعض، يشكلون سلسلة قرارات.

┌──────────────────────────────────────────────────────┐
│                  SESSION: sess_abc123                  │
│                                                       │
│  Event 1         Event 2         Event 3              │
│  ┌──────────┐   ┌──────────┐   ┌──────────┐         │
│  │ READ     │──▶│ LOOKUP   │──▶│ CHECK    │         │
│  │ TICKET   │   │ CUSTOMER │   │ BILLING  │         │
│  │          │   │          │   │          │         │
│  │ model:   │   │ tool:    │   │ tool:    │         │
│  │ claude   │   │ crm_api  │   │ billing  │         │
│  │          │   │          │   │ _api     │         │
│  │ tokens:  │   │ tokens:  │   │ tokens:  │         │
│  │ p_001    │   │ cid_001  │   │ o_001    │         │
│  └──────────┘   └──────────┘   └──────────┘         │
│       │              │              │                 │
│       ▼              ▼              ▼                 │
│  Event 4         Event 5                              │
│  ┌──────────┐   ┌──────────┐                         │
│  │ DRAFT    │──▶│ SEND     │                         │
│  │ RESPONSE │   │ EMAIL    │                         │
│  │          │   │          │                         │
│  │ model:   │   │ channel: │                         │
│  │ claude   │   │ email    │                         │
│  │          │   │          │                         │
│  │ policy:  │   │ restore: │                         │
│  │ support  │   │ formatted│                         │
│  └──────────┘   └──────────┘                         │
│                                                       │
└──────────────────────────────────────────────────────┘

كل حدث يشير للحدث السابق. السلسلة قابلة للتحقق: إذا أحد حذف الحدث 3، السلسلة من الحدث 4 رجوعاً للحدث 2 فيها فجوة. إذا أحد أدخل حدث مزيف بين 2 و 3، روابط السلسلة ما تتطابق.

الاستعلام عن السلسلة

لما مدقق يسأل "شو صار بجلسة X؟"، تستعلم بـ session_id وتعيد بناء السلسلة:

async function getDecisionChain(sessionId: string): Promise<AiDecisionEvent[]> {
    const events = await this.eventStore.findBySessionId(sessionId, {
        orderBy: 'timestamp',
        direction: 'ASC',
    });

    // التحقق من سلامة السلسلة
    for (let i = 1; i < events.length; i++) {
        if (events[i].previous_event_id !== events[i - 1].event_id) {
            throw new ChainIntegrityError(
                `Chain broken at event ${events[i].event_id}: ` +
                `expected previous ${events[i - 1].event_id}, ` +
                `got ${events[i].previous_event_id}`
            );
        }
    }

    return events;
}

لكيف نتعامل مع تحقق السلسلة المشابه في معاملات التجارة الإلكترونية، شوف دليل التجارة الوكيلية اللي يستخدم إيصالات HMAC لنفس الغرض.

إيصالات HMAC: إثبات مقاوم للتلاعب

أحداث القرارات المخزنة في قاعدة بيانات ممكن تتعدل. إيصال HMAC يثبت إن بيانات الحدث ما تغيرت من وقت ما انشأت.

function signDecisionEvent(event: AiDecisionEvent, tenantSecret: string): string {
    // الصيغة القياسية: مفاتيح مرتبة، JSON حتمي
    const canonical = JSON.stringify(event, Object.keys(event).sort());
    return crypto.createHmac('sha256', tenantSecret).update(canonical).digest('hex');
}

function verifyDecisionEvent(event: AiDecisionEvent, storedHmac: string, tenantSecret: string): boolean {
    const recomputed = signDecisionEvent(event, tenantSecret);
    return crypto.timingSafeEqual(
        Buffer.from(recomputed, 'hex'),
        Buffer.from(storedHmac, 'hex')
    );
}

كل حدث قرار يتوقع وقت الإنشاء. الـ HMAC يتخزن جنب الحدث. للتحقق، أعد حساب الـ HMAC من بيانات الحدث الحالية وقارن. إذا حقل واحد تعدل بعد التوقيع، الـ HMAC ما يتطابق.

السر الخاص بكل مستأجر يعني إن إيصالات مستأجر ما يمكن التحقق منها باستخدام مفتاح مستأجر ثاني. تدوير المفاتيح يتضمن فترة تداخل 24 ساعة يتقبل فيها المفتاح القديم والجديد للتحقق.

سجلات الموافقة البشرية

لما قرار يتطلب موافقة بشرية (معاملات عالية القيمة، وصول لبيانات حساسة، استثناءات سياسات)، الموافقة نفسها هي حدث قرار بحقول محددة:

interface ApprovalEvent extends AiDecisionEvent {
    event_type: 'approval';
    approval_required: true;

    // شو شاف الإنسان لما قرر
    approval_context: {
        original_request: string;      // ملخص شو انطلب
        estimated_impact: string;      // "طلب بقيمة 2,500 يورو من المورد Alpha"
        policy_triggered: string;      // "require_human_approval_above: 500"
        agent_recommendation: string;  // شو اقترح الوكيل
        risk_flags: string[];          // أي تحذيرات ظهرت للموافق
    };

    // شو قرر الإنسان
    approved_by: string;               // معرف المستخدم
    approved_at: string;               // ISO 8601
    approval_status: 'approved' | 'rejected';
    rejection_reason?: string;         // إذا رفض، ليش
    approval_duration_ms: number;      // قديش أخذ الإنسان يقرر
}

حقل approval_context حرج. يسجل شو المعلومات اللي انعرضت على الإنسان لما اتخذ قراره. هالشي يمنع حجة "أنا وافقت بس ما كنت أعرف X." السجل يوضح بالضبط شو شاف الموافق.

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

شو ما تسجله

تتبع القرارات يتطلب انضباط بخصوص شو يدخل مسار التدقيق.

سجل:

• معرفات tokens وأنواع الكيانات (مثلاً، "الكيان p_001 من نوع person تم اكتشافه")
• معرفات النماذج والإصدارات
• أسماء استدعاءات الأدوات والمعاملات المنظمة
• نتائج تقييم السياسات
• سجلات الموافقة مع السياق
• معلومات التوقيت (أوقات الاستجابة، المدد)
• أكواد الأخطاء وأسباب الفشل

ما تسجل:

• PII خام (أسماء، إيميلات، أرقام تلفونات، عناوين)
• نص الطلب الكامل (يحتوي PII وحجمه ضخم)
• ردود النموذج الكاملة (نفس المشاكل)
• بيانات اعتماد المصادقة أو مفاتيح API
• كلمات مرور النظام الداخلية أو سلاسل الاتصال

// جيد: منظم، خالي من PII
{
    event_type: "transform",
    action: "detect_and_tokenize",
    input_summary: {
        entities_detected: 3,
        entity_types: ["person", "email", "customer_id"],
        token_ids: ["p_001", "e_001", "cid_001"],
        detection_confidence: [0.95, 1.0, 0.99],
    },
    policy_id: "german-support",
    model_id: "ner-spacy-de",
    duration_ms: 12,
}

// سيء: يحتوي PII، ما ينفع للاستعلامات المنظمة
{
    event_type: "transform",
    action: "process_input",
    input: "Hallo, ich bin Sara Mustermann, meine Kundennummer ist 948221...",
    output: "Hallo, ich bin {{person:p_001}}...",
}

المثال الجيد قابل للاستعلام ("وريني كل الأحداث اللي ثقة الاكتشاف فيها أقل من 0.8")، قابل للتصفية ("وريني كل الأحداث لسياسة german-support")، وخالي من PII. المثال السيء كتلة نص تصير مسؤولية GDPR.

للبنية الكاملة للتسجيل الآمن من PII في أنظمة الذكاء الاصطناعي، شوف دليل مراقبة الذكاء الاصطناعي.

بنية الاحتفاظ

أحداث القرارات لها متطلبات احتفاظ مختلفة حسب سياقها التنظيمي:

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

حدث قرار ينشأ
  │
  ├──▶ المستوى الساخن (قاعدة بيانات): كتابة فورية، قابل للاستعلام
  │
  ├──▶ المستوى الدافئ (تخزين كائنات): تصدير يومي بالدفعات
  │
  └──▶ المستوى البارد (تخزين كائنات مقفل): تدفق من قاعدة البيانات
       عبر change data capture، كتابة لمرة واحدة، قفل 7 سنين

التدفق من قاعدة البيانات للتخزين البارد يصير عبر change data capture (تدفقات قاعدة البيانات أو شحن WAL). الأحداث تنكتب في الأرشيف الثابت خلال دقائق من الإنشاء. ما في مهمة دفعات تشتغل يومياً وممكن تفوت أحداث. التدفق مستمر.

هالنمط يعتبر جزء أساسي من بنية خدمات السحابة الحديثة، واللي ممكن تتكامل مع خطوط هندسة البيانات الموجودة عندك.

الربط عبر الخدمات

في نظام ذكاء اصطناعي موزع، طلب مستخدم واحد ممكن يمر على عدة خدمات: بوابة API، وقت تشغيل حماية البيانات، مزود LLM، خادم أدوات وخدمة تدقيق. الـ correlation_id يربط كل أحداث القرارات من كل الخدمات مع بعض.

// بوابة API تنشئ correlation_id
const correlationId = generateUUID();

// كل خدمة بعدها تستلمه
const response = await dataProtection.transform(input, {
    headers: { 'X-Correlation-Id': correlationId },
});

// كل حدث قرار يتضمنه
const event: AiDecisionEvent = {
    correlation_id: correlationId,
    // ...
};

لما تصحح أخطاء أو تدقق، استعلم بـ correlation_id تحصل الصورة الكاملة عبر كل الخدمات. هالنمط نفسه المستخدم في التتبع الموزع، بس مطبق تحديداً على أحداث القرارات بدل تتبعات الأداء.

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

التنفيذ العملي

اختيار التخزين

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

هالقرارات المعمارية هي اللي ممارستنا الاستشارية تساعد العملاء فيها. اختيار التخزين الغلط ممكن يكلفك شهور من إعادة العمل.

أنماط الاستعلام

أكثر الاستعلامات شيوعاً على مخزن أحداث القرارات:

-- كل القرارات في جلسة (إعادة بناء السلسلة)
SELECT * FROM ai_decision_events
WHERE session_id = $1
ORDER BY timestamp ASC;

-- كل القرارات من وكيل محدد في آخر 24 ساعة
SELECT * FROM ai_decision_events
WHERE actor_type = 'agent' AND actor_id = $1
AND timestamp > NOW() - INTERVAL '24 hours'
ORDER BY timestamp DESC;

-- كل تقييمات السياسات المرفوضة (إيجاد سياسات خاطئة التكوين)
SELECT * FROM ai_decision_events
WHERE policy_result = 'denied'
AND timestamp > NOW() - INTERVAL '7 days'
ORDER BY timestamp DESC;

-- كل الموافقات البشرية بوقت مراجعة قصير (اكتشاف الموافقة العمياء)
SELECT * FROM ai_decision_events
WHERE event_type = 'approval'
AND approval_status = 'approved'
AND approval_duration_ms < 3000
AND timestamp > NOW() - INTERVAL '30 days';

-- التحقق من سلامة السلسلة لجلسة
SELECT e1.event_id, e1.previous_event_id,
       CASE WHEN e2.event_id IS NULL AND e1.previous_event_id IS NOT NULL
            THEN 'BROKEN' ELSE 'OK' END as chain_status
FROM ai_decision_events e1
LEFT JOIN ai_decision_events e2 ON e1.previous_event_id = e2.event_id
WHERE e1.session_id = $1;

الفهرسة

CREATE INDEX idx_session ON ai_decision_events (session_id, timestamp);
CREATE INDEX idx_actor ON ai_decision_events (actor_type, actor_id, timestamp);
CREATE INDEX idx_correlation ON ai_decision_events (correlation_id);
CREATE INDEX idx_policy_result ON ai_decision_events (policy_result, timestamp);
CREATE INDEX idx_approval ON ai_decision_events (event_type, approval_status, timestamp)
    WHERE event_type = 'approval';

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

الأخطاء الشائعة

1. تسجيل الطلبات الخام كمسار تدقيق. الطلبات تحتوي PII. مخزن التدقيق عندك يصير خاضع لـ GDPR. استخدم أحداث منظمة بمعرفات tokens بدلها.

2. ما في ربط سلسلة بين الأحداث. بدون previous_event_id، ما تقدر تثبت تسلسل القرارات. الأحداث ممكن تنضاف، تنحذف أو تعاد ترتيبها بدون ما ينكشف الأمر.

3. ما في توقيع HMAC. سجلات قاعدة البيانات ممكن تتعدل. بدون إيصالات تشفيرية، مسار التدقيق مش مقاوم للتلاعب. "ثقوا فينا، ما عدلنا السجلات" مش جواب مقبول.

4. نفس فترة الاحتفاظ لكل شي. بيانات التصحيح تحتاج 90 يوم. بيانات الامتثال تحتاج 7 سنين. خلطها يضيع فلوس (حفظ بيانات التصحيح فترة طويلة) أو ينشئ مخاطر (حذف بيانات الامتثال بدري).

5. ما في سياق موافقة. تسجيل إن "المستخدم X وافق على الإجراء Y" مش كافي. سجل شو المعلومات اللي شافها الموافق لما قرر. بدون سياق، الموافقة ما لها معنى للتدقيق.

6. ما في اكتشاف الموافقة العمياء. إذا الرقابة البشرية متطلب امتثال، لازم تتحقق إن البشر فعلاً يراجعون، مش بس يضغطون "موافق" بشكل انعكاسي. تتبع approval_duration_ms.

7. ما في ربط عبر الخدمات. إذا نظام الذكاء الاصطناعي عندك يمتد عبر عدة خدمات، الأحداث من كل خدمة معزولة. بدون correlation_id، ما تقدر تعيد بناء سلسلة القرارات الكاملة.

8. تخزين بارد قابل للتعديل. إذا الأرشيف طويل المدى عندك ممكن يتعدل أو ينحذف من المسؤولين، هذا مش مسار تدقيق. استخدم تخزين كتابة لمرة واحدة بأقفال وضع الامتثال.

لمزيد من الأنماط حول كيف نتجنب أخطاء مشابهة في أنظمة الإنتاج، شوف دليل أنماط فشل الذكاء الاصطناعي ودليل حوكمة الذكاء الاصطناعي.

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

• "استخدمنا GPT-4" مش جواب مقبول. سجل النموذج المحدد، الإصدار، المزود، tokens المدخلة، tokens المخرجة، الأدوات اللي انطلبت، السياسات اللي اتقيمت والبشر اللي وافقوا. كل بعد من أبعاد القرار.

• أحداث منظمة، مش أسطر سجلات. الحقول المحددة الأنواع تمكن الاستعلامات المنظمة، لوحات المعلومات، اكتشاف الشذوذ وتقارير الامتثال. سجلات النص الحر ما تمكن شي غير grep.

• ما في PII في أحداث القرارات. استخدم معرفات tokens من طبقة حماية البيانات عندك. مسار التدقيق نفسه ما لازم يصير مسؤولية حماية بيانات.

• ربط السلسلة يثبت التسلسل. كل حدث يشير لسابقه. الفجوات والإضافات قابلة للاكتشاف. مع توقيع HMAC، السلسلة تصير مقاومة للتلاعب.

• إيصالات HMAC تقدم إثبات تشفيري. مفاتيح توقيع لكل مستأجر، ترتيب JSON قياسي، مقارنة آمنة التوقيت. أي تعديل على أي حقل يبطل الإيصال.

• سجلات الموافقة البشرية لازم تتضمن السياق. شو شاف الموافق؟ قديش أخذ يقرر؟ بدون هالشي، "الرقابة البشرية" مجرد خانة تأشير، مش ضابط حقيقي.

• الاحتفاظ بثلاث مستويات يطابق الواقع التنظيمي. ساخن للتصحيح (90 يوم)، دافئ للتدقيقات (سنتين)، بارد بأقفال كتابة لمرة واحدة للجهات التنظيمية (7 سنين).

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