
# AI გადაწყვეტილების ძრავა რეალურ დროში vendor კითხვარის პრიორიტიზაციისა და რისკის შეფასებით

უსაფრთხოების კითხვარები, აკმაყოფილების აუდიტები და vendor‑შეამოწმებები აუცილებელი უევეთავენ ყველა B2B SaaS ტრანზაქციაში. თუმცა შემოდის მოთხოვნებთან მან્યુალურ ტრაიაჟს ხშირად ქმნის ფარული ღირებულება: დაყოვნებული ტრანსაქციები, გაფაცრებული რისკის ადრენა და ღია ღიზიანად გადატვირთული აკმაყოფილების გუნდები. **Procurize** უკვე შეთავსებულია ერთგული ჰაბი კითხვარების ორგანიზაციისთვის, მაგრამ შემდეგი ევოლუციული ნაბიჯია *გადაწყვეტილებების შრე*, რომელიც იცის **რომელი** კითხვა გადმოჰყავთ **როდესაც**, და **რამდენი** რისკია თითოეული vendor‑სგან.

ამ სტატიულად აგინებებთ **AI გადაწყვეტილების ძრავის** დიზაინს, იმპლემენტაციას და ბიზნესი‑ტაქტის გავლენას, რომელიც:

1. **შეამცირებს** vendor‑ის სიგნალებს რეალურ დროულში ([SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2) ანგარიშები, [ISO 27001](https://www.iso.org/standard/27001) სერტიფიკატები, [GDPR](https://gdpr.eu/) DPO დეკლარაციები).  
2. **განხორციელებს** რისკის ქულას ჰიბრიდული Graph Neural Network (GNN) + ბეეისევის მოდელის საშუალებით.  
3. **პრიორიტიზირავს** კითხვარის დავალებებს reinforcement‑learning‑ის დაგეგმვით.  
4. **ვრცელებს** გადაწყვეტილებებს Procurize‑ის კოლაბორატორიული სამუშაო სივრცეში უნახავი გამოსახულებით.

საბოლოოში გაგეთანხმებით, როგორ გადაიყვანოთ მოთხოვნების საზღვრები სახის‑მოყვანილი, მუდმივად ოპტიმიზებული სამუშაო ნაკადში, რომელიც იქცება პასუხის ციკლების შემცირებისით **70 %**‑ისგან, ხოლო პასუხის სიზუსტეს გაიზიარებს.

---

## რატომ მნიშვნელოვნად არის რეალურ‑დროული პრიორიტიზაცია

| ტვირთის პუნქტი | კონვენციული მიდგომა | AI‑მოყოლილი ტრანსფორმაცია |
|----------------|----------------------|---------------------------|
| **ტომის პარამეტრები** ფონდირებით საიდანი ან პროდუქტის გაშვებისას | პირველი შემოსული რიგი | დინამიკური დატვირთების‑იცნობადი განრიგება |
| **რისკის ბლინდული ადგილები** – გუნდები ყველა vendor‑ს თანასწორ სახით იღებენ | მანუალური რისკის დონის (ხოლო მოძველებული) | ცოცხალი რისკის ქულა ცოცხალი მონაცემებით |
| **რესურსის ზეგერებზე** – უაკანული ანალისტი პასუხის ქვედა‑ნიშნა კითხვარები | წეს‑ის‑დადგენის დანიშვნა | უნარ‑დამამზადებული დავალებების განაწილება |
| **გარანტიის ტრანზაქციის ასისტენცია** – დაყოვნებული პასუხები იწვევს დაკარგვას | რეაქტიული მიყვანა | პრაქტიკური გაფრთხილებები მაღალ‑ღირებულების vendor‑ებზე |

გადაწყვეტილებების იಂಜინი გადატარავს “ერთი‑ზომის‑ყველაზე‑თന്ന്” ფეფქვს განმეორებით, მუდმივად გადახვალის **vendor‑ის რისკის**ა და **გუნდის შესაძლებლობას**. შედეგია *ცოცხალი პრიორიტეტის სია*, რომელიც ერკვება როგორც ახალი მიგზავნელი – ზუსტად იმ, რასაც თანამედროვე უსაფრთხოების‑ჯერად ორგანიზაციების სჭირდებათ.

---

## არქიტექტურული განზომილება

ქვემოთაა მაღალი‑დონესა Mermaid გრაფიკი, რომელიც აჩვენებს AI გადაწყვეტილების ძრავის ძირითად კომპონენტებსა და მონაცემის ნაკადებს, მკვეთრად ინტեգრირებულ Procurize‑ის პლატფორმასთან.

```mermaid
graph LR
    subgraph Data Ingestion
        A["რეალურ დროში vendor‑სიგნალები"]
        B["პოლისიის რეპოზიტორია"]
        C["თავდაცვის intel ნაკადი"]
        A --> D["ივენთის ნაკადი (Kafka)"]
        B --> D
        C --> D
    end

    subgraph Risk Scoring
        D --> E["მახასიათებლების მაღაზია (Delta Lake)"]
        E --> F["ჰიბრიდული GNN + ბეეისევის მოდელი"]
        F --> G["რისკის ქული (0‑100)"]
    end

    subgraph Prioritization Scheduler
        G --> H["რინფორსმენტ ლერნინგის აგენტი"]
        H --> I["პრიორიტიული რიგი"]
        I --> J["ამოცანების დისპაჩერი (Procurize)"]
    end

    subgraph Feedback Loop
        J --> K["მომხმარებლის მოქმედება & უკუკავშირი"]
        K --> L["ჯილდოს სიგნალი (RL)"]
        L --> H
    end
```

*თქვენალივე ნოდების ლეიბლები (labels) დუბლირებულია როგორც კომენტარი Mermaid‑ისათვის.*

### ძირითადი ელემენტები

1. **ივენთის ნაკადი** – Apache Kafka (ან Pulsar) იღებს ყველა ცვალებელს: ახალი აუდიტის ანგარიშები, გამარჯობა საეჭვო, ხელშეკრულებების განახლება.  
2. **მახასიათებლების მაღაზია** – ცენტრალურ Delta Lake‑ში ინახება შექმნილი მასალები (მაგალითად, vendor‑ის ასაკი, კონტროლ‑მისამართი, ექსპოზურის დონე).  
3. **ჰიბრიდული GNN + ბეეისევის მოდელი** – GNN‑მა გადაექცევა რისკის მასისა შისტემის სირთულზე, ბეეისევის კომპონენტი დამატებით რეგულაციასთან დაბასიათებს.  
4. **RL გადამზიდავი** – მრავალ‑რიცხვიან ბანდიტის ალგორითმი იკვლევს, რომელ პრიორიტეტის ცვლილებებს აწამებს უამთ მისამართის *deal closure* ან *risk reduction* რეალურ სამყაროში, ინახებულია რეალური პროფლებით.  
5. **ამოცანების დისპაჩერი** – Procurize‑ის API‑ით, ძრავი მაღლა პრიორიტენტის კითხვარის ტრეკერები პირდაპირ შესაბამისი შეჭემიაზე გადაცენებს.

---

## რეალურ‑დროული მონაცემის შუჭება

### 1. Vendor‑ის სიგნალები

- **აკმაყოფილების მასალები**: [SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2) Type II, [ISO 27001](https://www.iso.org/standard/27001) სერტიფიკატები, [GDPR](https://gdpr.eu/) DPO დეკლარაციები.  
- **ოპერაციული ტელემეტრია**: CloudTrail‑ის ლოგები, SIEM‑ის გაფრთხილებები, ქონების ინვენტარი.  
- **გარეგნული intel**: CVE‑feeds, dark‑web‑ის ბრეცის მონიტორინგი, მესამე‑საიწერილი risk‑ქულები.

ყველა სიგნალი ნორმალიზებულია კანონიკური JSON‑სქემაზე და გამოითიექნება Kafka‑ის თემებზე `vendor.signals`, `policy.updates`, `threat.intel`.

### 2. მასალის შექმნა

Spark Structured Streaming‑ის სამუშაო შუქი უწყვეტია ცივი მოვლენების ღრუბელი:

```python
from pyspark.sql import functions as F

# Example: calculate days since last audit
df = spark.readStream.format("kafka").option("subscribe", "vendor.signals").load()
parsed = df.selectExpr("CAST(value AS STRING) as json").select(F.from_json("json", schema).alias("data"))
features = parsed.withColumn(
    "days_since_audit",
    F.datediff(F.current_date(), F.col("data.last_audit_date"))
)
features.writeStream.format("delta").option("checkpointLocation", "/tmp/checkpoints").start("/mnt/feature-store")
```

შედრილი **Delta Lake‑ის ცხრილი** განლაგდება რისკ‑მოდელს წყალს.

---

## AI რისკის ქულის იಂಜინი

### ჰიბრიდული გრაფიკული ნეირონული ქსელი

Vendor‑Control‑knowledge‑გრაფი აუკურთავს ელემენტებს:

- **Vendor → Controls** – “Vendor X განახორციელა Encryption‑at‑Rest”.  
- **Control → Regulation** – “Encryption‑at‑Rest აკმაყოფილებს GDPR Art. 32”.  
- **Control → Evidence** – “Evidence #1234”.

PyG (PyTorch Geometric)‑ში ორი‑შრება GCN‑ის გამოცნობა:

```python
import torch
from torch_geometric.nn import GCNConv

class RiskGNN(torch.nn.Module):
    def __init__(self, in_dim, hidden_dim, out_dim):
        super().__init__()
        self.conv1 = GCNConv(in_dim, hidden_dim)
        self.conv2 = GCNConv(hidden_dim, out_dim)

    def forward(self, x, edge_index):
        x = torch.relu(self.conv1(x, edge_index))
        x = torch.sigmoid(self.conv2(x, edge_index))
        return x
```

გამოსავალტების ვექტორთა `x` წარმოადგენს **ნორმალიზებულ რისკს** თითოეული vendor‑ის მასალაზე.

### ბეეისევის პრიორი ლაიერი

რეგულაციული ექსპერტები მიწოდებენ **პრიორებს** (მაგ. “ყველა PHI‑ს მქონარი vendor‑ის საბაზისო რისკი 0.65”). ბეეისევის განახლება შერწყდა GNN‑ის პოსტერი:

\[
P(Risk | Data) = \frac{P(Data | Risk) \cdot P(Risk)}{P(Data)}
\]

`pymc3`‑ით ხდება posterior‑ის გამოთვლა, რომელიც ბლანსირებს **ნაბიჯ‑სა‑სანდო ინტერვალს** ქულის პუნქტს.

---

## პრიორიტიზაციის განსახორციელებლობა reinforcement‑learning‑ის მიხედვით

### მრავალ‑რიცხვიანი ბანდიტის მოდელირება

ყოველი **ტველი** წარმოადგენს პრიორიტეტის კატეგორიას (Urgent, High, Medium, Low). აგენტი არჩენს კატეგორიას vendor‑ის კითხვარისთვის, იღებს **ჯილდოს** (deal closed, risk reduced, analyst satisfaction) და განახორციელებს თავისი პოლიტიკას.

```python
import numpy as np

class BanditAgent:
    def __init__(self, n_arms=4):
        self.n = n_arms
        self.counts = np.zeros(n_arms)
        self.values = np.zeros(n_arms)

    def select_arm(self):
        epsilon = 0.1
        if np.random.rand() > epsilon:
            return np.argmax(self.values)
        else:
            return np.random.randint(0, self.n)

    def update(self, chosen_arm, reward):
        self.counts[chosen_arm] += 1
        n = self.counts[chosen_arm]
        value = self.values[chosen_arm]
        self.values[chosen_arm] = ((n - 1) / n) * value + (1 / n) * reward
```

**ჯილდოს სიგნალი** აგრეგირებულია რამდენიმე KPI‑ში:

- **პასუხის დრო (TTA)** – შემცირება.  
- **Risk‑Score Alignment** – რამდენად ემსახურება პასუხი დაკონტროლებულ რისკს.  
- **User‑Feedback Score** – ანალისტის ღირებულება დავალების შესაბამისობაზე.

### მუდმივი სწავლის ციკლი

ყოველ 5  წუთში RL აგენტი გადატვირთავს უკანასკნელი ბალანსის საშუალებით, შენახული Delta Lake‑ის reward ცხრილში. განახლებული პოლიტიკა გაეგზავნება **პრიორიტიული რიგის** სერვისზე, რაც ანდახური მოქმედებს შემდეგის დავალებების გადაცემაზე.

---

## ინტეგრაცია Procurize‑ის მთელს

Procurize უკვე გთავაზოდი:

- **`/api/v1/questionnaires`** – სია, შექმნა, განახლება.  
- **`/api/v1/tasks/assign`** – კითხვარის დანიშვნა მომხმარებელზე/ტიმზე.  
- Webhooks დავალებების დასრულების მიზნით.

გადაწყვეტილებების იಂಜინი ითხოვს FastAPI‑ის ლაითაჟს:

```python
import httpx

async def dispatch_task(vendor_id, priority):
    payload = {
        "vendor_id": vendor_id,
        "priority": priority,
        "due_date": (datetime.utcnow() + timedelta(days=2)).isoformat()
    }
    async with httpx.AsyncClient() as client:
        await client.post("https://api.procurize.com/v1/tasks/assign", json=payload, headers=auth_header)
```

როდის, როდესაც შეკითხვა *დასრულებულია*, Procurize‑ის webhook‑ი აგზავნის ბადის უკან მოდელის reward‑ს ცხრილზე, ახლავე დასრულებულია უკუკავშირის ციკლი.

---

## ბიზნესის გამატკივრები

| მაკსიმ | წინვე | 30 დღის შემდეგ |
|--------|--------|-----------------|
| საშუალო TTA კითხვარისათვის | 4.3 დღე | **1.2 დღე** |
| % მაღალი‑რისკის vendor‑ების 48 საათში განსახილველია | 22 % | **68 %** |
| ანალიტიკის კმაყოფილება (1‑5) | 3.1 | **4.6** |
| გაკეთებული დილები (win‑rate) | 31 % | **45 %** |

**განსაზღვრული ეფექტი** – სწრაფი პასუხის დრო, უკეთესი რისკის ქულა, უფრო ბედნიერი ანალისტები – ფარგის მორგებული შემოსავალის ზრდა და აკმაყოფილება.

---

## იმპლემენტაციის რუკა (12‑კვირის სპრინტი)

| კვირა | ტრანსფორმაციის ეტაპი |
|------|------------------------|
| 1‑2 | Kafka‑ის თემების დაყენება, vendor‑სიგნალების სქემის დეფინირება |
| 3‑4 | Delta Lake‑ის მასალის მაღაზიის შექმნა, streaming jobs‑ის დაწერა |
| 5‑6 | GNN მოდელი, ტრენინგი ისტორიული მონაცემებით |
| 7 | ბეეისევის პრიორი ლაიერის დამატება, confidence thresholds‑ის კალიბრირება |
| 8‑9 | ბანდიტის შედგენა, reward‑ის კოლექციის ინტეგრაცია |
| 10 | Procurize‑ API‑ის დაკავშირება, end‑to‑end ტრანსლირაციის ტესტირება |
| 11 | A/B‑პილოტი ცალკეულ აკმაყოფილების ანალისტებზე |
| 12 | გლობალური rollout, მონიტორინგისა და ალერტის dashboard‑ის ერი |

Key success criteria: **model latency < 500 ms**, **scheduler convergence within 200 ინტერფეისის ურთიერთქმედება**, **≥ 80 % მონაცემის ხარისხი** mass store‑ში.

---

## მომავალის თვალსაჩინოება

1. **ფედერირებული ლერნინგის გაფართოება** – მრავალ SaaS‑პარტნიორს აკრძალება არასაღებადი მონაცემის გაცვლისა, თუმცა მოდელის ერთობლივი გაუმჯობესება.  
2. **მიურცელებელი AI შრე** – გენიალურ ენერგეტიკულ სახის ახსნა‑დოკუმენტაციაში (მაგ: “Vendor X‑ის ქულა მაღალი, ვინაიდან ახლახან CVE‑2024‑1234‑ის გამო”).  
3. **Zero‑Trust ინტეგრაცია** – გადამაწყვეტის იಂಜინი შიდა Zero‑Trust‑ქსელში ა­პროვოული მინიმალური პრივილეგიული წვდომა evidence‑ის თავზე.  
4. **Regulatory Digital Twin** – იმიტაცია მომავალ რეგულაციებზე, პრიორიტეტიზაციის პრეოქუტირება.

გადაწყვეტილებების იಂಜინი გახდება *გონება* პროქტერის შთაგონებული compliance-ეკოსისტემის, მოქნებულია გულამდე რეალურ‑დროის, რისკ‑დამააწყობის წინასწარი მართვისგან.

---

## დასკვნა

შეკითხვა‑პასუხის ავტომატიზაცია მხოლოდ ნახევარია. ნამდვილი კონკურენტული უპირატესობა – **ისია იცის, რომელი შეკითხვა მოვალება პირველ რიგში, და რატომ**. რეალურ‑დროში მონაცემის შუჭება, გრაფიკ‑მიმდევრული risk‑ქულა, reinforcement‑learning‑ით პრიორიტიზაცია, აქედან წარმოშობს AI გადაწყვეტილების იಂಜინი, რომელიც გადამყიდის compliance‑ფუნქციას ბოტლნეკიდან სტრატეგიული აკქმედურამდე.

Procurize‑ის კოლაბორატორული პლატფორმაზე ასეთი იంజინის დენება აძლევს უსაფრთხოების, იურიდიული, და გაყიდვების გუნდებს სინქრონურ მუშაობას, ტრანსაქციების მოხსნასა სწრაფს, და რეგულაციებთან პირდაპირ ერთნაირი დროის მიხედვით. სამყაროში, სადაც წამები მნიშვნელოვანი, AI‑მოყოლილი, რისკ‑მიმაგრებული პრიორიტეტების რიგი – moderne compliance‑automation‑ის შემდეგი დამოუკიდებელი გახდა.  

---

## განაცხადები

- [NIST SP 800‑53 Rev 5 – Risk Management Framework](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final)  
- [ISO/IEC 27001:2022 – Information Security Management](https://www.iso.org/standard/73906.html)  
- [Google Cloud Blog: Building Real‑Time ML Pipelines with Kafka and Vertex AI](https://cloud.google.com/blog/topics/inside-google-cloud/building-real-time-ml-pipelines)