# AI poháněný řešič konfliktů v reálném čase pro soulad s protifaktuálními vysvětleními

## Úvod

Podniky působící v různých jurisdikcích čelí neustálému proudu regulačních aktualizací. Když nová pravidla o ochraně osobních údajů v EU kolidují s existujícím bezpečnostním standardem ve Spojených státech, týmy pro soulad se snaží konflikt vyřešit dříve, než budou ohroženy uvedení produktů na trh nebo smlouvy s dodavateli. Tradiční manuální revize jsou pomalé, náchylné k chybám a často postrádají transparentnost — zainteresované strany obdrží „opravenou“ politiku, aniž by rozuměly kompromisům, které k rozhodnutí vedly.

**AI poháněný řešič konfliktů v reálném čase pro soulad (CRR)** tuto mezeru zaplňuje. Nepřetržitě načítá dokumenty politik, specifikace produktů a smlouvy s dodavateli, vytváří sjednocený znalostní graf souhlasu a spouští engine pro řešení omezení, aby odhalil rozpory. Když je konflikt identifikován, systém generuje **protifaktuální vysvětlení** — jasné, narativní „co‑by‑bylo“ scénáře, které ukazují, jak by alternativní volby ovlivnily postoj k souhlasu. Toto spojení automatizace a vysvětlitelnosti proměňuje soulad z reaktivní úzké hrdlosti na proaktivní rozhodovací podporu.

V tomto článku se podíváme na:

1. Architektonické komponenty CRR.
2. Detekční pipeline konfliktů a roli grafových neuronových sítí (GNN).
3. Jak jsou generována protifaktuální vysvětlení pomocí Retrieval‑Augmented Generation (RAG) a kauzální inference.
4. Praktického průvodce implementací s ukázkami kódu a diagramem Mermaid.
5. Provozních úvah, bezpečnosti a budoucích rozšíření.

## 1. Architektonický přehled

CRR je postaven jako sada volně propojených mikro‑služeb, které komunikují přes událostmi řízenou zprávovou sběrnici (např. Kafka). Obrázek 1 ilustruje vysokou úroveň datového toku.

```mermaid
flowchart TD
    A["Služba pro ingestování politik"] --> B["Úložiště sjednoceného znalostního grafu"]
    C["Služba produktové roadmapy"] --> B
    D["Služba smluv s dodavateli"] --> B
    B --> E["Engine pro detekci konfliktů"]
    E --> F["Optimalizátor řešení"]
    F --> G["Generátor protifaktuálních vysvětlení"]
    G --> H["Dashboard souladu"]
    E --> I["Služba upozornění a ticketování"]
```

* **Služba pro ingestování politik** parsuje regulační texty (PDF, HTML, XML) pomocí Document AI, extrahuje klauzule a normalizuje je do kanonické ontologie.  
* **Úložiště sjednoceného znalostního grafu** (Neo4j nebo JanusGraph) uchovává entity jako *Regulace*, *Kontrola*, *ProduktováFunkce*, *KlauzuleDodavatele* a vztahy *vyžaduje*, *konfliktujeS*, *aplikujeNa*.  
* **Engine pro detekci konfliktů** spouští SAT/SMT solver (např. Z3) nad graf‑zakódovanými omezeními, aby odhalil rozpory.  
* **Optimalizátor řešení** hodnotí proveditelné nápravné akce pomocí multi‑objektivního nákladového modelu (riziko, čas, finanční dopad).  
* **Generátor protifaktuálních vysvětlení** využívá jemně doladěný LLM (např. Llama‑2‑70B) kombinovaný s kauzálním grafem k vytvoření lidsky čitelných „co‑by‑bylo“ narativů.  
* **Dashboard souladu** vizualizuje konflikty, navrhovaná řešení a související vysvětlení v reálném čase.  

## 2. Detekce konfliktů pomocí grafových neuronových sítí

Čistý SAT solver dokáže identifikovat logické nesrovnalosti, ale má problémy s nejednoznačnými klauzulemi v přirozeném jazyce. Pro zvýšení recall používáme **grafovou neuronovou síť**, která zakóduje každý uzel a hranu a je trénována na označeném datasetu známých konfliktů. GNN poskytuje pravděpodobnostní skóre konfliktu pro každý pár hran.

### 2.1 Pipeline pro vkládání uzlů

```python
import torch
from torch_geometric.nn import GraphSAGE
from transformers import AutoTokenizer, AutoModel

tokenizer = AutoTokenizer.from_pretrained("sentence-transformers/all-MiniLM-L6-v2")
text_encoder = AutoModel.from_pretrained("sentence-transformers/all-MiniLM-L6-v2")

def encode_clause(text):
    inputs = tokenizer(text, return_tensors="pt", truncation=True, max_length=128)
    with torch.no_grad():
        embedding = text_encoder(**inputs).last_hidden_state.mean(dim=1)
    return embedding.squeeze()

# Příklad: zakódovat regulační klauzuli
reg_clause = "Osobní údaje musí být smazány do 30 dnů od žádosti."
reg_vec = encode_clause(reg_clause)
```

Výsledný vektor `reg_vec` se stane počáteční vlastností uzlu pro GNN. Po několika vrstvách předávání zpráv se model naučí kontextové reprezentace, které zachycují sémantické překrytí mezi klauzulemi.

### 2.2 Hodnocení konfliktu

```python
class ConflictScorer(torch.nn.Module):
    def __init__(self, hidden_dim=128):
        super().__init__()
        self.sage = GraphSAGE(in_channels=768, hidden_channels=hidden_dim, num_layers=2)
        self.classifier = torch.nn.Linear(hidden_dim, 1)

    def forward(self, x, edge_index):
        h = self.sage(x, edge_index)
        # Paretové skalární součiny pro kandidátní hrany
        scores = torch.sigmoid(self.classifier(h))
        return scores
```

Během inference jsou hrany se skóre > 0,85 označeny pro podrobnější SAT analýzu. Tento hybridní přístup snižuje počet falešně pozitivních výsledků a zároveň zachovává šíři pokrytí.

## 3. Generování protifaktuálních vysvětlení

Po potvrzení konfliktu systém musí odpovědět na dvě otázky:

1. **Jaká je kořenová příčina?** — identifikovat minimální množinu klauzulí, které společně způsobují nesoulad.  
2. **Co by se stalo, kdybychom změnili X?** — poskytnout narativ popisující dopad alternativních nápravných akcí.

### 3.1 Konstrukce kauzálního grafu

Vytvoříme **kauzální graf**, kde uzly představují klauzule politik a hrany logické závislosti (např. *vyžaduje*, *vylučuje*). Pomocí Pearlova do‑kalkulu můžeme simulovat intervence.

```mermaid
graph LR
    A["\"EU GDPR Art.17\""] -->|vyžaduje| B["\"Uchování ≤ 30 dní\""]
    C["\"US CCPA\""] -->|vylučuje| B
    D["\"Navrhovaná politika uchování\""] -->|konfliktujeS| C
```

V tomto příkladu odstranění požadavku *Uchování ≤ 30 dní* (operace **do**) eliminuje konflikt s CCPA.

### 3.2 Retrieval‑Augmented Generation (RAG)

Načteme relevantní úryvky politik z grafu a předáme je jemně doladěnému LLM, který byl trénován na šablonách pro vysvětlení souhlasu.

```python
from langchain.chains import RetrievalQA
from langchain.vectorstores import FAISS
from langchain.llms import LlamaCpp

vector_store = FAISS.from_documents(policy_documents, embedding_function=encode_clause)
retriever = vector_store.as_retriever(search_kwargs={"k": 5})

llm = LlamaCpp(model_path="llama-2-70b.ggmlv3.q4_0.bin", temperature=0.2)
qa_chain = RetrievalQA.from_chain_type(llm=llm, retriever=retriever)

question = "Vysvětli, proč požadavek GDPR na smazání do 30 dní koliduje s navrhovanou politikou uchování 45 dní a navrhni souladnou alternativu."
explanation = qa_chain.run(question)
print(explanation)
```

Výstup je stručný, bodovaný narativ:

```
- GDPR (Art.17) vyžaduje smazání do 30 dní.
- Navrhovaná politika prodlužuje lhůtu na 45 dní, čímž porušuje Art.17.
- Protifaktuální scénář: Pokud by se lhůta snížila na 30 dní, konflikt zmizí.
- Doporučená náprava: Zavést vrstvený model uchování, kde citlivé osobní údaje podléhají 30‑dennímu pravidlu, zatímco ne‑osobní logy mohou zůstat 45 dní pod samostatnou klasifikací.
```

### 3.3 Multi‑objektivní nákladové modelování

Optimalizátor hodnotí každou nápravu podle vektoru nákladů **C = (riziko, úsilí, finanční, čas‑na‑trh)**. Na uživateli se zobrazí Pareto‑fronta, ze které si může tým souhlasu vybrat nejvhodnější kompromis.

```python
import numpy as np

actions = ["SnížitUchování", "PřidatAnonymizaci", "VytvořitOddělenýDataset"]
costs = np.array([
    [0.2, 0.1, 0.05, 0.1],   # SnížitUchování
    [0.1, 0.3, 0.2, 0.2],    # PřidatAnonymizaci
    [0.15, 0.2, 0.1, 0.05]   # VytvořitOddělenýDataset
])

# Jednoduchý vážený součet (váhy lze přizpůsobit organizaci)
weights = np.array([0.4, 0.3, 0.2, 0.1])
scores = costs @ weights
best_action = actions[np.argmin(scores)]
print(f"Nejlepší náprava: {best_action}")
```

Vybraná akce je následně předána generátoru vysvětlení, aby vytvořil finální, akční report.

## 4. Průvodce implementací

Níže je krok‑za‑krokem kontrolní seznam pro vybudování CRR v cloud‑native prostředí.

| Krok | Popis | Doporučená technologie |
|------|------|------------------------|
| 1 | **Ingestování dokumentů** – OCR, NLP, extrakce klauzulí | Azure Form Recognizer, spaCy |
| 2 | **Definice ontologie** – vytvoření schématu souhlasu | OWL/RDF, Protégé |
| 3 | **Uložení grafu** – perzistence entit a vztahů | Neo4j Aura, Amazon Neptune |
| 4 | **Generování embeddingů** – větné transformátory | `sentence-transformers/all-MiniLM-L6-v2` |
| 5 | **Trénink GNN** – model pravděpodobnosti konfliktu | PyTorch Geometric |
| 6 | **Řešení omezení** – detekce logických rozporů | Z3 SMT Solver |
| 7 | **Kauzální graf a do‑kalkulus** – simulace protifaktuálů | DoWhy, CausalNex |
| 8 | **RAG pipeline** – Retrieval + LLM generování | LangChain + Llama‑2 |
| 9 | **Optimalizace nákladů** – multi‑objektivní skórování | SciPy, PuLP |
|10| **Dashboard a upozornění** – UI v reálném čase | React + D3, Grafana, Slack webhook |

### Ukázka Docker Compose

```yaml
version: "3.9"
services:
  neo4j:
    image: neo4j:5
    environment:
      - NEO4J_AUTH=neo4j/password
    ports: ["7474:7474", "7687:7687"]
  z3:
    image: z3prover/z3
    command: ["--solver"]
  rag:
    build: ./rag-service
    ports: ["8000:8000"]
  dashboard:
    build: ./dashboard
    ports: ["3000:3000"]
```

Nasazení provede `docker compose up -d`. Každá služba loguje do centralizovaného ELK stacku pro observabilitu.

## 5. Provozní úvahy

### 5.1 Ochrana dat

Všechny dokumenty politik jsou považovány za **důvěrné**. Systém šifruje data v klidu (AES‑256) i během přenosu (TLS 1.3). Embeddingy jsou uloženy v **privacy‑preserving vektorovém úložišti**, které podporuje injekci šumu pro diferencovanou ochranu soukromí.

### 5.2 Audity vysvětlitelnosti

Regulátoři stále častěji požadují **explainable AI**. CRR zaznamenává každý inferenční krok, včetně:

* ID původních klauzulí.
* Důkazového trace SAT solveru.
* Detailů protifaktuální intervence.
* Prompt‑response párů LLM.

Tyto logy lze exportovat jako neměnné JSON záznamy do auditního ledgeru (např. blockchain‑based Hyperledger Fabric).

### 5.3 Kontinuální učení

GNN i LLM jsou periodicky pře‑trénovány na **lidsky validovaných řešeních konfliktů**. Zpětná smyčka zachytává signály přijetí/odmítnutí od týmů pro soulad a vrací je do tréninkového pipeline pomocí **reinforcement learning from human feedback (RLHF)**.

## 6. Budoucí rozšíření

1. **Multimodální důkazy** — přidání screenshotů, diagramů a úryvků kódu jako dalších uzlů důkazu.  
2. **Edge AI** — nasazení lehkého detektoru konfliktů na edge zařízení pro on‑premise kontroly souhlasu.  
3. **Forecasting regulací** — kombinace řešiče konfliktů s Monte‑Carlo modelem dopadu regulací, aby se předvídaly budoucí rozpory.  
4. **Federované výměna znalostí** — umožnit partnerům sdílet modely přes federované učení při zachování suverenity dat.

## Závěr

AI poháněný řešič konfliktů v reálném čase pro soulad transformuje tradičně reaktivní, manuální proces na automatizovaný, transparentní systém rozhodovací podpory. Spojením řešení omezení, grafových neuronových sítí a protifaktuálních vysvětlení engine nejen okamžitě identifikuje rozpory, ale také poskytuje jasné, akční narativy, které posilují zainteresované strany. Organizace, které tuto technologii adoptují, mohou snížit latenci souhlasu, omezit auditní rizika a udržet si konkurenční výhodu v silně regulovaných trzích.

---

## Viz také

- [Z3 Theorem Prover: Efektivní řešení omezení pro konflikty politik](https://github.com/Z3Prover/z3)  
- [DoWhy – Kauzální inference pro protifaktuální vysvětlení](https://github.com/microsoft/dowhy)  
- [LangChain Retrieval‑Augmented Generation Documentation](https://python.langchain.com/docs/use_cases/question_answering/)