> For the complete documentation index, see [llms.txt](https://docs.solcis.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.solcis.ai/why-solcis/why-solcis-ar/mbade-altsmym/tudar-alhwkmh-aftradhyana.md).

# تُدار الحوكمة افتراضيًا

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

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

توضح هذه الصفحة ما يعنيه ذلك عمليًا، ولماذا صُمِّم بهذه الطريقة.

## كل إجراء، قبل أن يحدث

يُقيَّم إجراء الوكيل المتصل قبل أن يستمر. يُرجع محرك سياسات سولسيس `سماح`, `رفض` أو `تصعيد`، وكل منها مرفق بدرجة خطورة. يُرفض الإجراء المرفوض. ويُحتجز الإجراء المُصعَّد حتى يقرر شخص مخوَّل. ويستمر الإجراء المُقيَّم مع إرفاق تصنيف به. ويستمر الإجراء المسموح به، وتُسجَّل حقيقة أنه سُمِح به.

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

## الضوابط التي لديك بالفعل

الحوكمة افتراضيًا لا تعني أن سولسيس يقرر ما ينبغي أن تكون عليه ضوابطك. بل تعني أن الضوابط التي تعمل بها بالفعل تنطبق على الوكلاء منذ لحظة اتصالهم.

لدى معظم المؤسسات المواد بالفعل. فبرنامج الحوكمة والمخاطر والامتثال (GRC) لديها يحتفظ بمكتبة ضوابط مرتبطة بالأطر التي تخضع لها. يستورد Compliance Studio تلك الضوابط عبر تكاملات GRC الخاصة به ويحوّلها إلى سياسات ينفذها محرك سياسات سولسيس. ويحتفظ الضابط بمعرّفه. وتسجل السياسة أي متطلب من متطلبات الإطار تستوفيه. وعندما يُرفض إجراء وكيل، يذكر إيصال الامتثال الضابط الذي رفضه والمتطلب الكامن وراءه. *كيف يعمل › من الضوابط إلى السياسة* يصف المسار من الضابط إلى السياسة.

## ما من شيء يُنفَّذ بالصدفة

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

<figure><img src="https://3885553061-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFwpyjzyaYY4oV7LJBr4N%2Fuploads%2FdBuGfbbm38YuWU9ggzZq%2Fpolicy-lifecycle.svg?alt=media&amp;token=d9ac6f70-cb5c-4caf-b64b-914879889768" alt=""><figcaption></figcaption></figure>

يُسجَّل كل انتقال: من وافق، ومن رقّى، ومتى.

## الوضع الافتراضي عندما يفشل شيء ما

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

يطبّق محرك سياسات سولسيس بديلاً احتياطيًا، مُهيَّأً في Compliance Studio، لكلٍ من هذه الحالات، وتوضح الوثائق ذلك بدلًا من تركك تكتشفه. ويذكر إيصال الامتثال للإجراء الذي حُسم ببديل احتياطي ذلك صراحةً.

## لماذا يهمّ الوضع الافتراضي

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

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


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.solcis.ai/why-solcis/why-solcis-ar/mbade-altsmym/tudar-alhwkmh-aftradhyana.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
