هذا سيناريو توضيحي، وليس قصة عميل. لا يستخدم أي مؤسسة حقيقية، ولا أي أشخاص حقيقيين، ولا أي نتائج مُدَّعاة. الغرض منه هو إظهار كيف ستحمل حزمة Vendor Security القابلة للتنفيذ من Threada مراجعة أمنية روتينية من الطلب حتى قرار مُسجَّل. كل واجهة موصوفة أدناه هي قدرة منتج حقيقية؛ والموقف مُختلق لأغراض التوضيح.
تقضي فرق الأمن جزءًا مفاجئًا من أسبوعها على مراجعات معظمها روتيني وبعضها جاد أحيانًا. أداة SaaS جديدة تحتاج إلى موافقة. مورّد يريد معالجة بيانات العملاء. يُطلب استثناء مقابل سياسة قائمة. معظمها يتبع شكلًا معروفًا؛ وقليل منها يتطلب تدقيقًا حقيقيًا. الجزء الصعب نادرًا ما يكون التحليل — بل هو إبقاء كل مراجعة متسقة، ومستندة إلى أدلة، ومُسجَّلة.
إليك كيف سيجري هذا العمل عبر حزمة Vendor Security من Threada.
شكل العمل
Vendor Security هي حزمة workspace ذات نموذج case وثلاث نوايا مُعرَّفة:
- مراجعة المورّد — تقييم مورّد جديد أو قيد التجديد مقابل السياسة.
- مراجعة معالجة البيانات — تقييم ما إذا كان يجوز للمورّد معالجة بيانات محددة.
- استثناء الأمن — التعامل مع طلب الانحراف عن ضابط قائم.
ليس على المراجع أن يقرر أي نموذج يفتح. فهو يعلن النية، ويحوّلها وقت التشغيل إلى WorkItem مُهيكل في طابور الأمن.
جولة
تخيّل أن طلبًا يصل: فريق يريد اعتماد مورّد تحليلات جديد سيستقبل بيانات استخدام المنتج. في هذا السيناريو يصل عبر قناة استلام مُهيّأة ويصبح WorkItem.
النية. يصف المراجع (أو مقدم الطلب، عبر قناة) النتيجة التي يحتاجها — “راجِع مورّد التحليلات هذا للموافقة على معالجة البيانات.” يستخرج وقت التشغيل المورّد، وفئات البيانات المعنية، وعلامة خطر أولية، ويودعه في طابور Vendor Security.
Canvas. يُفتح WorkItem على canvas تكيُّفي. وبدلًا من نموذج فارغ، يجمّع الـ workspace الحقول التي يحتاجها هذا النوع من المراجعة: فئات البيانات، وموقع المعالجة، والمعالِجون الفرعيون، وملف السياسة ذو الصلة. وحيث تنقص المعلومات، يطلب ذلك بالضبط، بدلًا من تقديم استبيان غير متمايز.
الأدلة. يحمل درج الأدلة ما يستند إليه التقييم — الوثائق المُقدَّمة من المورّد، والمراجعات السابقة للمورّد نفسه، والاقتباسات إلى السياسة المنطبقة. وإذا تعذّر على النظام تأسيس ادّعاء بعينه، فإنه يسجّل سبب التراجع بدلًا من تأكيد ثقة لا يملكها. ويستطيع المراجع أن يرى بنظرة واحدة مدى حداثة كل مصدر.
الضوابط. هنا تتحوّل المراجعة إلى قرار. الموافقة على معالجة البيانات لمورّد جديد فعلٌ ذو عواقب، لذا يمر عبر واجهة الضوابط المحكومة: اقتراح، ثم موافقة صريحة مقابل نسخة السياسة النشطة. وإذا كانت السياسة تتطلب موافِقًا ثانيًا لفئة البيانات هذه، فإن البوابة تفرضه. لا شيء يُنفَّذ بصمت.
سجل التشغيل. تتراكم كل خطوة على سجل التشغيل — الاستلام، وطلبات المعلومات الناقصة، والأدلة التي جرى الرجوع إليها، والموافقة ومن منحها، والنتيجة النهائية المُسجَّلة. ولأن أفعال المشاركين من الذكاء الاصطناعي تظهر كأحداث فاعل مميزة، فإن السجل يُظهر بوضوح أي الخطوات تولّاها النظام وأيها قرّره إنسان.
ما يتبقى للفريق
في النهاية، يملك فريق الأمن ثلاثة أشياء كان عليه لولا ذلك تجميعها يدويًا:
- مراجعة متسقة. النية نفسها تنتج دائمًا شكل الـ workspace نفسه، بحيث لا تنحرف المراجعات في صرامتها بين أسبوع مزدحم وأسبوع هادئ.
- قرار مُؤسَّس. الموافقة مرتبطة بأدلة محددة وبنسخة سياسة مُسمّاة، وليس بذاكرة المراجع.
- إيصال. المراجعة بأكملها مُسجَّلة — قابلة للدفاع أمام مدقق، ومقروءة للمراجع التالي الذي يتولّى حالة مشابهة.
تمضي المراجعات الروتينية بسرعة لأن الـ workspace يقوم بالتجميع. وتنال المراجعات الجادة تدقيقًا بشريًا كاملًا لأن واجهة الضوابط تُصرّ على ذلك. هذا التقسيم — أتمتة الروتيني، وتوجيه الحالات الصعبة فعلًا إلى البشر — هو الغاية بأكملها.
لماذا ننشر هذا كسيناريو
كان بإمكاننا تزيين هذا كقصة نجاح عميل مع نسبة مئوية مبهرة مرفقة. لن نفعل. وحتى يشارك عميل حقيقي موافِق نتائج حقيقية، فإن أي شيء نطبعه هنا هو توضيح، ونحن نفضّل وسمه بأمانة على أن نلمّح إلى دليل لا نملكه.
ما هو حقيقي هو الحزمة. Vendor Security هي سير عمل قابل للتثبيت على نفس وقت التشغيل المحكوم مثل كل حزمة Threada أخرى، بالنوايا والواجهات الخمس الموصوفة أعلاه. وإذا أردت رؤية النسخة القابلة للتنفيذ بدلًا من الجولة، فإن كتالوج الحزم هو المكان الذي تبدأ منه.