سجل تدقيق وكلاء الذكاء الاصطناعي: ما الحقول التي يجب أن يحتويها

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

لماذا تفشل حقول «المستخدم» الاعتيادية مع وكلاء الذكاء الاصطناعي

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

• عدم الحتمية: نفس المطالبة وتكوين النموذج يمكن أن يُنتجا مخرجات مختلفة ما لم تسجل مصدر العشوائية (seed، خوارزمية rand، temperature).
• سلاسل متعددة الخطوات: الوكلاء غالباً ما يستدعون أدوات، واجهات برمجة تطبيقات وعملاء آخرين؛ تحتاج إلى سلسلة سببية، وليس مجرد إدخال فعل واحد.
• تطور الشيفرة والنماذج: الوكيل هو شيفرة + نموذج + وقت تشغيل. اسم المستخدم لا يخبرك بنقطة تحقق النموذج، digest صورة الحاوية أو سياسة الوكيل المستخدمة.
• التفويض والموافقة: قد يتصرف الوكيل نيابة عن إنسان أو نظام آخر؛ يجب أن يُظهر أثر التدقيق من فوّض الوكيل وما القيود المطبقة.

باختصار: استبدل النموذج الذهني لـ «شخص ضغط زر» بـ «حساب قابل لإعادة الإنتاج حوّل المدخلات إلى مخرجات وأحدث آثارًا جانبية».

الحد الأدنى للحقول التي يجب أن يحتويها سجل تدقيق وكيان الذكاء الاصطناعي

• record_id — UUID ثابت لإدخال التدقيق (v4 أو v7) ورقم تسلسل للجلسة.
• timestamp — RFC3339 UTC؛ تضمّن أرقام تسلسلية أحادية الاتجاه لاكتشاف إعادة الترتيب.
• agent_id — معرّف منطقي لحالة الوكيل (ليس فقط مالك الإنسان).
• agent_version — هاش الالتزام، digest صورة الحاوية (مثال sha256:...)، أو إصدار الحزمة لشيفرة الوكيل.
• model_name & model_digest — معرّف النموذج بالإضافة إلى digest أو checksum للأوزان/نقطة التحقق المستخدمة (أو سلسلة إصدار النموذج المستضاف).
• runtime_config — معلمات النموذج: temperature، top_k/top_p، max_tokens، حدود التزامن، وخوارزمية RNG.
• prompt_template_id & prompt_hash — معرّف قالب المطالبة وهاش للمطالبة المحلولة لتجنب تخزين النص الصريح إذا كان ذلك حساسًا.
• input_artifacts — مراجع (URIs) للمرفقات، الملفات، أو البيانات الخارجية المستخدمة مع checksums.
• actions — قائمة مرتبة بالإجراءات التي نفذها الوكيل، مع طوابع زمنية، معرفات الأدوات والنتائج (اسم الأداة، الإصدار، رمز الخروج، هاش البيانات المعادة).
• external_calls — كل استدعاء API صادر مع الوجهة، مضيف URL، هاش الطلب، هاش الاستجابة، والكمون.
• human_principal — من أنشأ/وافق على الوكيل أو الطلب (معرّف المستخدم، الدور، وبيان التفويض).
• authorization_context — معرّف السياسة، النطاقات المسموح بها، الانتهاء، ورمز الموافقة أو معرّف التدقيق الذي يربط الفعل بتدفق الموافقة.
• outcome — الحالة النهائية أو الآثار الجانبية: ملفات مكتوبة، أوامر منفذة، تغييرات على الشبكة؛ تضمّن معرّفات الأشياء وchecksums.
• evidence_hash — digest للحمل الكامل للسجل يُستخدم للكشف عن التلاعب (خزّنها بشكل منفصل أو وقّعها؛ راجع التوقيع أدناه).
• p2p_or_relay — ما إذا كانت الجلسة نظيرًا لنظير أم عبر relay، وإذا كانت عبر relay: المنطقة ومعرّف relay.
• log_integrity — بيانات تعريف التوقيع (key id، خوارزمية التوقيع، التوقيع) إذا كنت توقع السجلات.

تشكل هذه الحقول الجوهر. اعتمادًا على مستوى المخاطرة والتنظيم، أضف بعض العناصر الأخرى: معرّف وقت تشغيل الحاوية، إصدارات النواة/المُحاكٍ، معرّف إثبات TPM للأجهزة، أرقام تسلسلية للشهادات المستخدمة لـ TLS، وأي مراجع لأصل مجموعات البيانات.

مثال على سجل تدقيقي

{
  "record_id": "b3f8a1d2-2e8f-4a5b-9a0f-7c6d2f3a1b2c",
  "timestamp": "2026-09-11T14:23:05Z",
  "session_seq": 42,
  "agent_id": "invoice_processor_v2",
  "agent_version": "git+sha:8b7f3c2",
  "model_name": "gpt-like-3b",
  "model_digest": "sha256:0f3a...",
  "runtime_config": {"temperature":0.2,"top_p":0.9,"seed":123456789},
  "prompt_template_id": "tmpl-invoice-2026-v3",
  "prompt_hash": "sha256:abcd...",
  "human_principal": {"user_id":"alice@corp.example","approval_id":"apr-2026-019"},
  "actions": [
    {"t":"2026-09-11T14:23:06Z","tool":"ocr:1.4.0","result_hash":"sha256:1111..."},
    {"t":"2026-09-11T14:23:10Z","tool":"bank_api:2.0","endpoint":"payments/verify","response_hash":"sha256:2222..."}
  ],
  "outcome": {"invoices_processed":3,"files_created":["s3://legal/inv-345.pdf"]},
  "p2p_or_relay": "relay",
  "relay_id": "relay-eu-2",
  "evidence_hash": "sha256:ffff...",
  "log_integrity": {"sig_kid":"logs-prod-2026","sig":"MEUCIQD..."}
}

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

ثبات السجلات، التوقيع وسياسات الاحتفاظ

يحتاج المدققون ومستجيبون الحوادث إلى ثقة بأن السجلات لم تُعبث بها. إجراءان عمليان:

• تخزين قابل للإلحاق فقط مع لقطات غير قابلة للتغيير (تخزين كائنات مع إصدار/WORM أو أنظمة ملفات للكتابة مرة واحدة). احتفظ بنسخة احتياطية باردة منفصلة في منطقة مختلفة.
• توقيع السجلات: احسب evidence_hash لكل سجل ووقّعه بمفتاح توقيع مخصص للسجلات. دوّر المفاتيح وفق جدول وخزّن المفاتيح العامة القديمة للتحقق. تضمّن بيانات تعريف التوقيع (معرّف المفتاح، الخوارزمية، وتاريخ الانتهاء) داخل السجل.

الاحتفاظ: عادة تحتفظ فرق التشغيل بسجلات تدقيق عالية الدقة متصلة عبر الإنترنت لمدة 90 يومًا للتشخيص، وتحتفظ بالبيانات الوصفية المفهرسة لمدة سنة للامتثال، وتبقي أرشيفًا موقّعًا وغير قابل للتغيير من 1–7 سنوات اعتمادًا على التنظيم. حدّد مدة الاحتفاظ مع المستشار القانوني — المدة المناسبة تختلف حسب الصناعة: القطاع المالي والصحي غالبًا ما تمتد لسنوات متعددة.

الخصوصية، التنقيح وضوابط الوصول

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

• سياسة التنقيح: خزّن هاشات المدخلات الحساسة (prompt_hash، file_hash) وانقل النصوص الصريحة إلى خزنة محمية يمكن الوصول إليها فقط أثناء الحوادث وبإجراءات موافقة قابلة للتدقيق.
• أدنى امتياز: فصل الأدوار لكتابة السجلات، وقراءة السجلات الخام، والتحقق من التواقيع. كل قراءة للسجلات الخام يجب أن تُسجّل هي نفسها.
• الموافقة والربط: إذا تصرف الوكيل نيابة عن مستخدم، احتفظ بربط واضح (رمز تفويض، موافقة مؤرخة) بحيث يمكنك نسب الأفعال إلى المبدأ البشري لأغراض قانونية و GDPR.

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

لماذا تسجيل تفاصيل النموذج ووقت التشغيل (ليست بيانات وصفية اختيارية)

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

• معرّف النموذج وdigest — سلسلة إصدار النموذج المستضاف وحدها هشة؛ checksum أو إصدار موفر غير قابل للتغيير أفضل.
• التزام شيفرة الوكيل أو digest الصورة — قد يغيّر خطأ في شيفرة الوكيل السلوك أكثر من المطالبة نفسها.
• معاملات وقت التشغيل والseed — لإعادة إنتاج مخرج محدد أو لمعرفة ما إذا كان يمكن إعادة الإنتاج في وضع حتمي.
• إصدارات الأدوات والاستجابات — أداة تعيد بيانات مختلفة تغير النتائج؛ خزّن هاشات الاستجابة والنقاط النهائية.

بدون تلك الحقول، لا يمكنك القول بثقة ماذا فعل الوكيل أو لماذا فعله.

ضوابط التشغيل: التنبيه، العيّنة ووضع الطب الشرعي

تسجيل كل شيء بدقة كاملة قد يكون مكلفًا ومحفوفًا بالمخاطر. اتبع استراتيجية طبقية:

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

خيارات البنية التحتية: managed relay vs self-hosting

مكان تخزين ونقل سجلات التدقيق ذو أهمية. بالنسبة للوصول عن بعد وأدوات الوكلاء، managed relay الخاص بـ Tenvo هو التوصية الافتراضية لمعظم الفرق: يوفر عملاء أصلية لنظامي Windows/macOS/Linux، عميل متصفح في بيتا عامة، و relay مُدار متعدد المناطق مع تسجيل وطبقات احتفاظ مدمجة (Free $0 / Lite $2.99/mo / Pro $7.99/mo). استخدام managed relay يتيح تفويض تجديد الشهادات، توسيع Relay، تصحيحات الاستجابة الفورية والنسخ الاحتياطي عبر المناطق.

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

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

نموذج الوصول إلى سجلات التدقيق واستجابة الحوادث

صمّم من يمكنه فعل ماذا مع السجلات قبل أن تحتاج إليها. الحد الأدنى من الضوابط:

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

أثناء الحادث، ستحتاج إلى إعادة بناء السلسلة السببية بسرعة. إذا كانت سجلاتك تتضمن model_digest، agent_version، prompt_hash، قائمة الإجراءات وهاشات الاستدعاءات الخارجية، فعادة يمكنك تحديد السبب الجذري خلال ساعات بدلًا من أيام.

قائمة تحقق للبدء (خطوات عملية)

• عرّف مخطط JSON لسجل تدقيق الوكيل وطبقه عند الكتابة. تضمّن الحقول المذكورة أعلاه.
• نفّذ evidence_hash ووقّع كل سجل بمفتاح توقيع سجلات؛ خزّن المفاتيح العامة في مجموعة مفاتيح قابلة للاكتشاف للمدققين.
• قرر مدة الاحتفاظ: 90 يومًا متصلاً للسجلات الكاملة؛ 1–7 سنوات مؤرشفًا حسب التنظيم.
• أنشئ قواعد تنقيح: ما الذي يُهاش مقابل ما يخزن نصًا صريحًا ومن يمكنه الوصول للنص الصريح.
• أضف فحوص سياسة في الوقت الحقيقي وموافقات آلية للأفعال عالية المخاطر.
• شغّل اختبارات قابلية إعادة الإنتاج أسبوعيًا: اختر إدخالًا نموذجيًا وتحقق من أنك تستطيع إعادة نواتج الوكيل اعتمادًا على النموذج المسجل، seed والتكوين.

إذا كنت تستخدم بالفعل الوصول البعيد أو أدوات الوكلاء مع Tenvo، راجع تصميم أثر سجلات تدقيق لجلسات سطح المكتب البعيد المتوافق لأنماط التسجيل التي تنطبق على الجلسات التفاعلية، واستشر ai agent remote desktop: السياسات، الموافقات، التدقيق لتدفقات موافقة مخصصة للوكلاء. لمحة أوسع عن كيفية تناسب الوكلاء مع أدوات التحكم عن بعد، انظر AI and remote desktop: how agents use remote tooling.

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

حمّل Tenvo لاختبار سلوك التسجيل وmanaged relay محليًا وشاهد كيف تبسط relays المتعددة المناطق، طبقات التسعير (Free $0 / Lite $2.99/mo / Pro $7.99/mo) وعمليات Relay الإدارة العمليات: تنزيل.