
# AI‑Řízený engine pro směrování na základě záměru pro spolupráci v reálném čase při dotaznících dodavatelů

Bezpečnostní dotazníky dodavatelů se staly úzkým hrdlem pro rychle rostoucí SaaS společnosti. Každá nová žádost od zákazníka spustí řetězec manuálních předání: bezpečnostní analytik vytáhne nejnovější politiku, právní kontrolor ověří formulaci, produktový inženýr upřesní technické implementace a finální odpověď se sestaví v PDF. Tento roztříštěný pracovní postup vede k **dlouhým dobám zpracování, nekonzistentním odpovědím a riziku auditních zjištění**.

Co kdyby platforma sama pochopila *proč* je otázka položena, *kdo* je nejvhodnější pro její zodpovězení a *kdy* je odpověď potřeba, a poté automaticky směrovala požadavek správné osobě — *v reálném čase*? Představujeme **AI‑Řízený engine pro směrování na základě záměru (IBRE)**, klíčovou součást platformy Procurize AI, která spojuje **sémantiku znalostních grafů**, **generaci augmentovanou vyhledáváním (RAG)** a **kontinuální zpětnou vazbu** k orchestraci kolaborativních odpovědí na dotazníky rychlostí stroje.

> **Klíčové závěry**  
> - Detekce záměru proměňuje surový text dotazníku na strukturované obchodní záměry.  
> - Dynamický znalostní graf spojuje záměry s vlastníky, důkazními artefakty a verzemi politik.  
> - Směrování v reálném čase využívá LLM‑napájené scoringy důvěry a vyvažování pracovní zátěže.  
> - Kontinuální smyčky učení optimalizují záměry a směrovací politiky na základě auditů po odeslání.

---

## 1. Od textu ke záměru — vrstva sémantické analýzy

Prvním krokem IBRE je převést volně formulovanou otázku (např. *„Šifrujete data v klidu?“*) na **kanonický záměr**, se kterým může systém dále pracovat. To je dosaženo dvoustupňovým pipeline:

1. **Extrahování entit pomocí LLM** — Lehký LLM (např. Llama‑3‑8B) získá klíčové entity: *šifrování*, *data v klidu*, *rozsah*, *regulační rámec*.  
2. **Klasifikace záměru** — Extrahované entity jsou vstupem pro jemně vyladěný klasifikátor (na bázi BERT), který je mapuje na taxonomii **~250 záměrů** (např. `EncryptDataAtRest`, `MultiFactorAuth`, `IncidentResponsePlan`).

Výsledný objekt záměru obsahuje:
- `intent_id`
- `confidence_score`
- `linked_policy_refs` (**[SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2)**, **[ISO 27001](https://www.iso.org/standard/27001)**, interní ID politik)
- `required_evidence_types` (konfigurační soubor, auditní log, externí osvědčení)

**Proč je záměr důležitý:**  
Záměry fungují jako *stabilní smlouva* mezi obsahem dotazníku a následným pracovním postupem. I když se formulace změní („Je vaše data šifrována při ukládání?“ vs. „Používáte šifrování pro data v klidu?“) je rozpoznán stejný záměr, což zajišťuje konzistentní směrování.

---

## 2. Znalostní graf jako kontextová páteř

**Property‑graph databáze** (Neo4j nebo Amazon Neptune) uchovává vztahy mezi:

- **Záměry** ↔ **Vlastníci** (bezpečnostní inženýři, právní poradci, produktoví vedoucí)  
- **Záměry** ↔ **Důkazní artefakty** (politiky, konfigurace)  
- **Záměry** ↔ **Regulační rámce** (**SOC 2**, **ISO 27001**, **[GDPR](https://gdpr.eu/)**)  
- **Vlastníci** ↔ **Pracovní zátěž & Dostupnost** (aktuální fronta úkolů, časové pásmo)

Každý uzel má popisek v uvozovkách, aby splňoval syntaxi Mermaid pro pozdější vizualizace.

```mermaid
graph LR
    "Záměr: EncryptDataAtRest" -->|"vlastní"| "Vlastník: Security Engineer"
    "Záměr: EncryptDataAtRest" -->|"vyžaduje"| "Důkaz: Encryption Policy"
    "Záměr: EncryptDataAtRest" -->|"splňuje"| "Regulace: ISO 27001"
    "Vlastník: Security Engineer" -->|"dostupný"| "Status: Online"
    "Vlastník: Security Engineer" -->|"pracovní zátěž"| "Tasks: 3"
```

Graf je **dynamický** — každý nový dotazník buď přiřadí k existujícímu uzlu, nebo během nahrávání vytvoří nový. Hrany vlastnictví se přepočítávají pomocí **bipartitního algoritmu párování**, který vyvažuje odborné znalosti, aktuální zátěž a **[SLA](https://www.ibm.com/think/topics/service-level-agreement)** termíny.

---

## 3. Mechanika směrování v reálném čase

Když přijde položka dotazníku:

1. **Detekce záměru** poskytne záměr s confidence score.  
2. **Vyhledání v grafu** získá všechny kandidátní vlastníky a související důkazy.  
3. **Scoring engine** vyhodnotí:
   - **Shoda odbornosti** (`expertise_score`) — na základě historické kvality odpovědí.  
   - **Dostupnost** (`availability_score`) — reálný stav z API přítomnosti Slack/Teams.  
   - **Naléhavost SLA** (`urgency_score`) — odvozená od termínu dotazníku.  
4. **Kompozitní směrovací skóre** = vážený součet (nastavitelné politikou‑as‑code).

Vlastník s nejvyšším skórem dostane **automaticky vygenerovaný úkol** v Procurize, předvyplněný:
- původní otázkou,
- detekovaným záměrem,
- odkazy na relevantní důkazy,
- navrženými úryvky odpovědí z RAG.

Pokud confidence score klesne pod práh (např. 0,65), úkol je směrován do fronty **human‑in‑the‑loop review**, kde compliance lead ověří záměr před přiřazením.

### Příklad rozhodnutí směrování

| Vlastník | Expertíza (0‑1) | Dostupnost (0‑1) | Naléhavost (0‑1) | Kompozit |
|----------|-----------------|------------------|-----------------|----------|
| Alice (Sec Eng) | 0.92 | 0.78 | 0.85 | **0.85** |
| Bob (Legal) | 0.68 | 0.95 | 0.85 | 0.79 |
| Carol (Prod) | 0.55 | 0.88 | 0.85 | 0.73 |

Alice okamžitě obdrží úkol a systém zaznamená rozhodnutí pro auditní potřeby.

---

## 4. Kontinuální smyčky učení

IBRE není statický. Po dokončení dotazníku platforma vstřebá **zpětnou vazbu po odeslání**:

- **Revize přesnosti odpovědí** — Auditoři hodnotí relevanci odpovědi.  
- **Detekce mezer v důkazech** — Pokud je odkazovaný důkaz zastaralý, systém označí uzel politiky.  
- **Metričky výkonu vlastníků** — Míra úspěšnosti, průměrná reakční doba, četnost přerozdělení.

Tyto signály se vrací do dvou učebních pipeline:

1. **Zdokonalování záměrů** — Chybná klasifikace spustí semi‑supervised retraining klasifikátoru.  
2. **Optimalizace směrovacích politik** — Reinforcement Learning (RL) aktualizuje váhy pro odbornost, dostupnost a naléhavost s cílem maximalizovat soulad s SLA a kvalitu odpovědí.

Výsledkem je **samo‑optimalizující engine**, který se s každým cyklem dotazníku zlepšuje.

---

## 5. Integrační ekosystém

IBRE je navržen jako **mikro‑servis**, který se bez problémů propojí s existujícími nástroji:

| Integrace | Účel | Příklad |
|-----------|------|---------|
| Slack / Microsoft Teams | Notifikace v reálném čase & přijetí úkolu | `/procure assign @alice` |
| Jira / Asana | Vytvoření ticketu pro složitější shromažďování důkazů | Automaticky vytvoří ticket *Evidence Collection* |
| Správa dokumentů (SharePoint, Confluence) | Načtení aktuálních politik | Stažení poslední verze šifrovací politiky |
| CI/CD pipeline (GitHub Actions) | Spuštění compliance kontrol při nových vydáních | Spustit policy‑as‑code test po každém buildu |

Veškerá komunikace probíhá přes **mutual TLS** a **OAuth 2.0**, čímž se zajišťuje, že citlivá data z dotazníků neopustí zabezpečený perimetr.

---

## 6. Auditovatelná stopa a výhody souladnosti

Každé rozhodnutí o směrování vytvoří neměnný log‑záznam:

```json
{
  "question_id": "Q-2025-437",
  "intent_id": "EncryptDataAtRest",
  "assigned_owner": "alice@example.com",
  "routing_score": 0.85,
  "timestamp": "2025-12-11T14:23:07Z",
  "evidence_links": [
    "policy://encryption/2025-09",
    "artifact://config/production/db"
  ],
  "confidence": 0.93
}
```

Uložení tohoto JSON do **append‑only ledger** (např. Amazon QLDB nebo blockchain‑backed ledger) splňuje požadavky **SOX** i **GDPR** na sledovatelnost. Auditoři tak mohou přesně rekonstruovat důvody každé odpovědi, což dramaticky zkracuje **[SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2)** auditní cyklus.

---

## 7. Reálný dopad — rychlé případové studie

**Společnost:** FinTech SaaS „SecurePay“ (Series C, 200 zaměstnanců)  
**Problém:** Průměrná doba zpracování dotazníku — 14 dní, 30 % nedodržení SLA.  
**Implementace:** Nasazení IBRE s 200‑uzlovým znalostním grafem, integrace se Slack a Jira.  
**Výsledky (90‑denní pilot):**

| Metrika | Před | Po |
|---------|------|----|
| Průměrná doba odezvy | 14 dní | 2,3 dne |
| Soulad s SLA | 68 % | 97 % |
| Manuální úsilí při směrování (hod/ týden) | 12 h | 1,5 h |
| Nálezy auditu v oblasti mezer důkazů | 5 na audit | 0,8 na audit |

ROI byl v první půlce roku vypočten na **6,2‑násobek**, primárně díky snížení ztrát z prodlev v uzavírání obchodů a nižším nákladům na auditní opravy.

---

## 8. Budoucí směrování

1. **Cross‑Tenant federace záměrů** — umožnit sdílení definic záměrů mezi různými zákazníky při zachování izolace dat, využitím federovaného učení.  
2. **Zero‑Trust verifikace** — kombinovat homomorfní šifrování se směrováním záměrů tak, aby i samotný engine neměl přístup k citlivému obsahu otázek.  
3. **Prediktivní modelování SLA** — časové řady pro předvídání špiček v příchozích dotaznících (např. po uvedení nového produktu) a předběžné škálování kapacity směrování.

---

## 9. První kroky s IBRE

1. **Aktivujte Intent Engine** v Procurize → Settings → AI Modules.  
2. **Definujte svou taxonomii záměrů** (nebo importujte výchozí).  
3. **Namapujte vlastníky** propojením uživatelských účtů se štítky záměrů.  
4. **Propojte zdroje důkazů** (úložiště dokumentů, artefakty CI/CD).  
5. **Spusťte pilotní dotazník** a sledujte dashboard směrování.

Podrobný návod je k dispozici v **Procurize Help Center** pod sekcí *AI‑Driven Routing*.

---

## <span class='highlight-content'>Viz také</span>
- [Zero‑Trust Architecture for AI‑Driven Automation – NIST SP 800‑207](https://csrc.nist.gov/publications/detail/sp/800-207/final)