The user is asking me to propose an IT architecture for an AI-based solution that automates the process of handling customer complaints/reports from mobile banking, submitted through JIRA by the Contact Center to development teams. Let me design a comprehensive architecture that covers: 1. The input flow (mobile banking customers → Contact Center → JIRA) 2. AI-driven automation layer (classification, routing, triage, resolution) 3. Integration with development teams' workflows 4. Feedback loops for continuous improvement Let me think about this systematically. **Current State (Assumed):** - Mobile banking customers submit complaints/feedback via app or contact center - Contact Center agents create JIRA tickets manually - Tickets are routed to development teams somewhat manually - High volume, manual triage, delays in categorization **Target State:** - AI automation for categorization, prioritization, routing - Intelligent triage reducing manual effort - Faster resolution times - Better analytics Let me propose a full architecture. # Architektura IT: AI-Driven Automatyzacja Obsługi Zgłoszeń Bankowości Mobilnej przez JIRA --- ## 1. Kontekst i Cele Biznesowe ### Obecny proces (istniejący) ``` Klient BM → Contact Center (agent) → ręczne tworzenie ticketu JIRA → ręczne triage → ręczne przypisanie do zespołu wytwórczego → ręczne priorytetyzacja → ticket w kolejce zespołu ``` ### Docelowy proces (AI-augmentowany) ``` Klient BM → Contact Center → AI pipeline (klasyfikacja, routing, enrichment, scoring) → auto-routing do zespołu wytwórczego → automatyczny priorytet, sugestie rozwiązania, analytics ``` --- ## 2. Architektura Wysokopoziomowa (Solution Overview) ``` ┌─────────────────────────────────────────────────────────────────────────────┐ │ STREFA WEJŚCIA │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────────┐ │ │ │ Mobile │ │ Contact │ │ IVR / Chatbot │ │ │ │ Banking App │ │ Center │ │ (kanały głosowe)│ │ │ │ (reporty) │ │ (agenci) │ │ │ │ │ └──────┬───────┘ └──────┬───────┘ └───────┬──────────┘ │ │ │ │ │ │ └─────────┼──────────────────┼────────────────────┼───────────────────────────┘ │ │ │ ▼ ▼ ▼ ┌─────────────────────────────────────────────────────────────────────────────┐ │ API GATEWAY / EVENT BUS │ │ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Apache Kafka / Event Streaming │ │ │ │ Topics: raw-submissions, ai-enriched, routed, etc. │ │ │ └────────────────────────┬────────────────────────────────┘ │ │ │ │ └───────────────────────────┼─────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────────────────┐ │ AI ORCHESTRATION LAYER │ │ │ │ ┌──────────────────────────────────────────────────────────────────────┐ │ │ │ AI Pipeline Engine │ │ │ │ │ │ │ │ ┌────────────┐ ┌────────────┐ ┌───────────┐ ┌───────────────┐ │ │ │ │ │ 1. NLP │→ │ 2. Intent │→ │ 3. Classi-│→ │ 4. Priority │ │ │ │ │ │ Preprocess │ │ Extraction │ │ fication │ │ Scoring │ │ │ │ │ └────────────┘ └────────────┘ └───────────┘ └───────────────┘ │ │ │ │ │ │ │ │ ┌────────────┐ ┌────────────┐ ┌───────────┐ ┌───────────────┐ │ │ │ │ │ 5. Routing │→ │ 6. Enrich- │→ │ 7. Dupli- │→ │ 8. Solution │ │ │ │ │ │ Engine │ │ ment │ │ cate Det. │ │ Suggestion │ │ │ │ │ └────────────┘ └────────────┘ └───────────┘ └───────────────┘ │ │ │ └──────────────────────────────────────────────────────────────────────┘ │ │ │ │ ┌──────────────────┐ ┌──────────────────┐ ┌──────────────────────────┐ │ │ │ LLM Service │ │ ML Model Registry│ │ Knowledge Base │ │ │ │ (GPT-4/Claude/ │ │ (MLOps pipeline) │ │ (RAG - Vector DB) │ │ │ │ on-prem LLM) │ │ │ │ │ │ │ └──────────────────┘ └──────────────────┘ └──────────────────────────┘ │ │ │ └──────────────────────────────────────┬──────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────────────────┐ │ INTEGRATION LAYER │ │ │ │ ┌──────────────┐ ┌────────────────┐ ┌──────────────────────────┐ │ │ │ JIRA │ │ ServiceNow / │ │ CI/CD & Dev Tools │ │ │ │ REST API │ │ ITSM │ │ (repo, monitoring) │ │ │ │ (create/ │ │ (incident │ │ │ │ │ │ update/ │ │ mgmt) │ │ │ │ │ │ transition) │ │ │ │ │ │ │ └──────────────┘ └────────────────┘ └──────────────────────────┘ │ │ │ │ ┌──────────────┐ ┌────────────────┐ ┌──────────────────────────┐ │ │ │ Confluence / │ │ CRM │ │ Monitoring / Alerting │ │ │ │ Wiki │ │ (clientele) │ │ (Datadog/Grafana) │ │ │ └──────────────┘ └────────────────┘ └──────────────────────────┘ │ │ │ └──────────────────────────────────────┬──────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────────────────┐ │ FEEDBACK & CONTINUOUS LEARNING │ │ │ │ ┌────────────────────────────────────────────────────────────────────┐ │ │ │ Observability & Feedback Loop │ │ │ │ │ │ │ │ • Accuracy metrics, routing success rate │ │ │ │ • Agent corrections → training data │ │ │ │ • Time-to-resolution analytics │ │ │ │ • Model drift detection, retraining triggers │ │ │ │ • A/B testing of AI vs manual decisions │ │ │ └────────────────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ## 3. Szczegółowe komponenty AI Pipeline ### 3.1. Moduł 1 — Preprocessing NLP ``` ┌─────────────────────────────────────────────────┐ │ NLP PREPROCESSING │ ├─────────────────────────────────────────────────┤ │ │ │ Wejście: surowy tekst zgłoszenia │ │ + metadane (kanał, ID klienta, │ │ data, historia interakcji) │ │ │ │ Operacje: │ │ ┌───────────────────────────────────────────┐ │ │ │ • Tokenizacja i normalizacja tekstu │ │ │ │ • Czyszczenie PII (maskowanie danych │ │ │ │ osobowych wg RODO/GDPR) │ │ │ │ • Wyodrębnienie metadanych strukturalnych │ │ │ │ • Detekcja języka │ │ │ │ • Segmentacja długich raportów │ │ │ └───────────────────────────────────────────┘ │ │ │ │ Technologie: spaCy, HuggingFace Transformers, │ │ własna warstwa regulaminowa │ │ │ │ Wyjście: strukturalny obiekt JSON │ │ { text_clean, entities, metadata } │ └─────────────────────────────────────────────────┘ ``` ### 3.2. Moduł 2 — Ekstrakcja Intencji ``` ┌───────────────────────────────────────────────────────────┐ │ INTENT EXTRACTION │ ├───────────────────────────────────────────────────────────┤ │ │ │ Kategorie intencji (przykładowe — dostosowywane │ │ do banku): │ │ │ │ ┌─────────────────┐ ┌─────────────────┐ │ │ │ BUG_REPORT │ │ FEATURE_REQUEST │ │ │ │ (błąd w app) │ │ (prośba o │ │ │ │ │ │ nową funkcję) │ │ │ └─────────────────┘ └─────────────────┘ │ │ ┌─────────────────┐ ┌─────────────────┐ │ │ │ UX_ISSUE │ │ PERFORMANCE │ │ │ │ (problemy z │ │ (wolność, crash, │ │ │ │ interfejsem) │ │ timeout) │ │ │ └─────────────────┘ └─────────────────┘ │ │ ┌─────────────────┐ ┌─────────────────┐ │ │ │ SECURITY_INCID. │ │ DOCS/HELP │ │ │ │ (podejrzenie │ │ (pytania o │ │ │ │ bezpieczeństwa│ │ instrukcje) │ │ │ └─────────────────┘ └─────────────────┘ │ │ ┌─────────────────┐ ┌─────────────────┐ │ │ │ DATA_ISSUE │ │ PAYMENT_ISSUE │ │ │ │ (dane nie │ │ (błędy │ │ │ │ aktualne) │ │ płatności) │ │ │ └─────────────────┘ └─────────────────┘ │ │ │ │ Podejście: │ │ • Zero-shot classification (LLM) — dla nowych kategorii │ │ • Fine-tuned classifier (BERT/DeBERTa) — dla stabilnych │ │ • Hierarchiczna klasyfikacja (kategoria → podkategoria) │ │ │ │ Wyjście: { intent: "BUG_REPORT", │ │ sub_intent: "login_flow", │ │ confidence: 0.94 } │ └───────────────────────────────────────────────────────────┘ ``` ### 3.3. Moduł 3 — Klasyfikacja i Priorytetyzacja ``` ┌──────────────────────────────────────────────────────────────┐ │ CLASSIFICATION & PRIORITY SCORING │ ├──────────────────────────────────────────────────────────────┤ │ │ │ KLASYFIKACJA (component/component mapping): │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ Mapowanie: intent + entities → moduł aplikacji │ │ │ │ │ │ │ │ "Problem z logowaniem" → modul: "auth", │ │ │ │ komponent: "login-v2" │ │ │ │ │ │ │ │ "Przycisk przelew nie reaguje" → modul: "transfers" │ │ │ │ komponent: "ui-btn"│ │ │ │ │ │ │ │ Wykorzystanie: │ │ │ │ • Knowledge graph (moduły ↔ historyczne tickety) │ │ │ │ • TF-IDF/semantic similarity z resolved tickets │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ │ PRIORYTETYZACJA (multi-factor scoring model): │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ │ │ │ │ Score = w₁·sev_intent + w₂·sev_reach + w₃·sev_biz │ │ │ │ + w₄·sev_freq + w₅·sev_trend + w₆·sev_SLA │ │ │ │ │ │ │ │ • sev_intent — powaga intencji (security > bug) │ │ │ │ • sev_reach — ile klientów dotkniętych (crossection│ │ │ │ • sev_biz — wpływ na procesy biznesowe │ │ │ │ • sev_freq — częstotliwość zbliżonych zgłoszeń │ │ │ │ • sev_trend — wykrywanie spike'ów (proaktywnie) │ │ │ │ • sev_SLA — naruszenie SLA kanału │ │ │ │ │ │ │ │ Wyjście: P0/P1/P2/P3 + uzasadnienie (explainable) │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ │ Technologie: gradient boosting (XGBoost/LightGBM) │ │ + reguły biznesowe (override dla P0 security) │ │ + explainability (SHAP values) │ └──────────────────────────────────────────────────────────────┘ ``` ### 3.4. Moduł 4 — Routing Engine ``` ┌──────────────────────────────────────────────────────────────┐ │ ROUTING ENGINE │ ├──────────────────────────────────────────────────────────────┤ │ │ │ Dane wejściowe z pipeline: │ │ { intent, sub_intent, component, priority, confidence, │ │ customer_impact, related_tickets, SLA_context } │ │ │ │ Routing Rules (warstwa reguł + ML): │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ │ │ │ │ IF intent=SECURITY AND priority≥P1 │ │ │ │ → route to: SecurityOps Team + Escalation Lead │ │ │ │ create: P1 ticket + incident war room │ │ │ │ │ │ │ │ IF intent=BUG AND component=KNOWN_MODULE │ │ │ │ → route to: owning_team (from ownership registry) │ │ │ │ assign: on-call engineer (rotation schedule) │ │ │ │ │ │ │ │ IF intent=FEATURE_REQUEST │ │ │ │ → route to: Product Backlog (JIRA epic) │ │ │ │ create: Feature ticket with customer evidence │ │ │ │ │ │ │ │ IF confidence < 0.70 │ │ │ │ → route to: Human triage queue (Contact Center │ │ │ │ Supervisor / Triage Agent) │ │ │ │ flag: NEEDS_HUMAN_CONFIRMATION │ │ │ │ │ │ │ │ IF multiple duplicates detected (score > 0.85) │ │ │ │ → attach to existing ticket + increment counter │ │ │ │ notify: owning team (escalation if volume spike) │ │ │ │ │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ │ Kanały JIRA: │ │ • Kanban board per team │ │ • Epic → Feature → Task hierarchy │ │ • Linked issues (bug ↔ incident ↔ customer ticket) │ │ • Custom fields: AI_SCORE, AI_INTENT, AI_CONFIDENCE │ │ │ └──────────────────────────────────────────────────────────────┘ ``` ### 3.5. Moduł 5 — Enrichment i Solution Suggestion ``` ┌──────────────────────────────────────────────────────────────┐ │ ENRICHMENT & SOLUTION SUGGESTION │ ├──────────────────────────────────────────────────────────────┤ │ │ │ ENRICHMENT (ogłaszanie kontekstu): │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ • Historia zgłoszeń klienta (CRM lookup) │ │ │ │ • Podobne zgłoszenia w przeszłości (similarity) │ │ │ │ • Powiązane monitorowane incydenty (Datadog/Grafana)│ │ │ │ • Ostatnie release'y aplikacji (JIRA/Git) │ │ │ │ • Dotyczy regresji? → auto-check „releases" │ │ │ │ • Skala: ile jeszcze takich zgłoszeń w oknie 24h? │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ │ SOLUTION SUGGESTION (LLM + RAG): │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ │ │ │ │ LLM prompt (szablonizowany): │ │ │ │ ┌───────────────────────────────────────────────┐ │ │ │ │ │ ZGŁOSZENIE: {customer_report_clean} │ │ │ │ │ │ KONTEKST: {enriched_context} │ │ │ │ │ │ │ │ │ │ │ │ Na podstawie podobnych rozwiązanych zgłoszeń │ │ │ │ │ │ i dokumentacji technicznej, zaproponuj: │ │ │ │ │ │ 1. Prawdopodobną przyczynę (root cause) │ │ │ │ │ │ 2. Sugestię rozwiązania / workaround │ │ │ │ │ │ 3. Sugestię odpowiedzi dla klienta (workaround)│ │ │ │ │ │ 4. Szacowany wpływ (scope) │ │ │ │ │ └───────────────────────────────────────────────┘ │ │ │ │ │ │ │ │ RAG Engine: │ │ │ │ • Vector DB (Pinecone/Weaviate/Milvus) │ │ │ │ • Zawartość: resolved JIRA tickets, Confluence docs,│ │ │ │ runbooki, known issues, release notes │ │ │ │ • Embeddings: text-embedding-ada-002 / custom │ │ │ │ │ │ │ │ Wyjście (załączane do JIRA jako komentarz): │ │ │ │ • AI_SUGGESTION comment (oznaczony) │ │ │ │ • linked_issues (podobne stare tickety) │ │ │ │ • suggested_assignee (z basis team ownership) │ │ │ │ │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ └──────────────────────────────────────────────────────────────┘ ``` --- ## 4. Integracja z JIRA — Szczegóły techniczne ### 4.1. Flow integracji ``` ┌─────────────┐ ┌──────────────┐ ┌─────────────────────┐ │ AI Pipeline │ │ JIRA Adapter │ │ JIRA Instance │ │ Engine │────▶│ (Service) │────▶│ (Cloud/Data Center) │ └─────────────┘ └──────────────┘ └─────────────────────┘ JIRA Adapter responsibillities: ├── POST /rest/api/3/issue — Create ticket ├── PUT /rest/api/3/issue/{key} — Update (priority, labels, assignee) ├── POST /rest/api/3/issue/{key}/comment — Add AI suggestion ├── POST /rest/api/3/issue/{key}/transitions — Status transitions ├── GET /rest/api/3/search — Duplicate detection queries └── Webhooks (inbound) — Status changes → feedback to AI ``` ### 4.2. Szablon ticketa JIRA ```json { "fields": { "project": { "key": "MBMOB" }, "summary": "[AI] {auto_generated_title} — {intent_summary}", "description": { "type": "doc", "content": [ { "type": "paragraph", "content": [ { "type": "text", "text": "=== ZGŁOSZENIE KLIENTA ===" } ] }, { "type": "paragraph", "content": [ { "type": "text", "text": "{customer_report_clean}" } ] }, { "type": "paragraph", "content": [ { "type": "text", "text": "=== KLASYFIKACJA AI ===" } ] }, { "type": "paragraph", "content": [ { "type": "text", "text": "Intent: BUG_REPORT / sub: login_flow\nComponent: auth/login-v2\nPriority: P1 (score 87/100)\nConfidence: 94%\nAffected: ~1200 users in 24h (spike detected)", "marks": [{ "type": "strong" }] } ] } ] }, "issuetype": { "name": "Bug" }, "priority": { "name": "P1 - High" }, "labels": [ "ai-classified", "intent-bug-report", "component-auth", "prio-p1", "confidence-high" ], "components": [{ "name": "login-v2" }], "customfield_10001": "BUG_REPORT", "customfield_10002": 0.94, "customfield_10003": 87, "customfield_10004": { "value": "auth", "team": "Team Alpha", "oncall": "jane.doe" }, "assignee": { "name": "jane.doe" } } } ``` --- ## 5. Architektura infrastrukturalna (deployment) ``` ┌────────────────────────────────────────────────────────────────────┐ │ CLOUD VPC (bank on-prem lub hybrid) │ │ │ │ ┌──────────────────────────────────────────────────────────────┐ │ │ │ KUBERNETES CLUSTER │ │ │ │ │ │ │ │ ┌──────────────────┐ ┌──────────────────┐ │ │ │ │ │ ai-orchestrator │ │ nlp-pipeline │ │ │ │ │ │ (FastAPI/gRPC) │ │ (GPU nodes) │ │ │ │ │ │ replicas: 3+ │ │ replicas: 2+ │ │ │ │ │ └──────────────────┘ └──────────────────┘ │ │ │ │ │ │ │ │ ┌──────────────────┐ ┌──────────────────┐ │ │ │ │ │ llm-service │ │ ml-inference │ │ │ │ │ │ (vLLM / TGI) │ │ (ONNX/TensorRT) │ │ │ │ │ │ for on-prem LLM │ │ classifiers │ │ │ │ │ │ replicas: 2+ │ │ replicas: 3+ │ │ │ │ │ └──────────────────┘ └──────────────────┘ │ │ │ │ │ │ │ │ ┌──────────────────┐ ┌──────────────────┐ │ │ │ │ │ jira-adapter │ │ event-processor │ │ │ │ │ │ (integration) │ │ (Kafka consumer) │ │ │ │ │ │ replicas: 2+ │ │ replicas: 3+ │ │ │ │ │ └──────────────────┘ └──────────────────┘ │ │ │ │ │ │ │ │ ┌──────────────────┐ ┌──────────────────┐ │ │ │ │ │ feedback-service │ │ human-triage-ui │ │ │ │ │ │ (learning loop) │ │ (React dashboard)│ │ │ │ │ └──────────────────┘ └──────────────────┘ │ │ │ └──────────────────────────────────────────────────────────────┘ │ │ │ │ ┌──────────────────────────────────────────────────────────────┐ │ │ │ DATA LAYER │ │ │ │ │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────────┐ │ │ │ │ │ Apache │ │ PostgreSQL │ │ Vector DB │ │ │ │ │ │ Kafka │ │ (metadata, │ │ (Pinecone / │ │ │ │ │ │ (event │ │ audit log, │ │ Weaviate / │ │ │ │ │ │ streaming) │ │ config) │ │ Milvus) │ │ │ │ │ └──────────────┘ └──────────────┘ │ (RAG knowledge) │ │ │ │ │ └──────────────────┘ │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────────┐ │ │ │ │ │ Redis │ │ Object Store │ │ Model Registry │ │ │ │ │ │ (cache, │ │ (S3/MinIO - │ │ (MLflow / │ │ │ │ │ │ rate limit) │ │ artifacts) │ │ DVC) │ │ │ │ │ └──────────────┘ └──────────────┘ └──────────────────┘ │ │ │ └──────────────────────────────────────────────────────────────┘ │ │ │ │ ┌──────────────────────────────────────────────────────────────┐ │ │ │ OBSERVABILITY │ │ │ │ ┌────────────┐ ┌────────────┐ ┌──────────────────────┐ │ │ │ │ │ Prometheus │ │ Grafana │ │ Elasticsearch / │ │ │ │ │ │ (metrics) │ │ (dashbd) │ │ Loki (logs + traces) │ │ │ │ │ └────────────┘ └────────────┘ └──────────────────────┘ │ │ │ └──────────────────────────────────────────────────────────────┘ │ │ │ └────────────────────────────────────────────────────────────────────┘ ``` --- ## 6. Strumień danych (End-to-End Flow) ``` T0: Klient BM raportuje błąd przez aplikację ↓ (format: JSON — text, metadata, attachment) T1: MiMoGo App / Contact Center agent ↓ T2: Event emitted → Kafka topic "raw-submissions" ↓ T3: event-processor picks up event ↓ T4: ──── NLP Preprocessing ──── (sanitize PII, normalize) ↓ T5: ──── Intent Extraction ──── (BUG_REPORT / login_flow) ↓ T6: ──── Classification ─────── (component: auth/login-v2) ↓ T7: ──── Priority Scoring ───── (P1, score: 87) ↓ T8: ──── Duplicate Detection ── (found: MBMOB-1247, similarity: 0.91) │ ├── IF high confidence + no duplicate: │ T9a: jira-adapter creates NEW JIRA ticket │ with AI enrichment + suggestion │ → route to Team Alpha / on-call │ ├── IF duplicate detected: │ T9b: attach to existing ticket │ increment customer impact counter │ if spike → alert Team Alpha │ ├── IF low confidence (<0.70): │ T9c: route to human triage queue │ agent confirms/corrects → learning data │ └── IF security intent: T9d: create P1 JIRA + page Security on-call + open incident war room ↓ T10: JIRA webhook → feedback-service receives (status change, resolution, agent correction) ↓ T11: Feedback feeds into: • accuracy metrics dashboard • model retraining pipeline (batch, weekly) • prompt tuning for LLM • routing rule adjustments ``` --- ## 7. Pętla zwrotna i ciągłe uczenie (MLOps) ``` ┌─────────────────────────────────────────────────────────────────────┐ │ CONTINUOUS LEARNING LOOP │ │ │ │ │ │ ┌──────────┐ ┌──────────────┐ ┌──────────────────┐ │ │ │ Production│ │ Data │ │ Training │ │ │ │ Inference│─────▶│ Collection │─────▶│ Pipeline │ │ │ │ │ │ (inferences │ │ (weekly/batch) │ │ │ │ │ │ + labels) │ │ │ │ │ └──────────┘ └──────────────┘ └────────┬─────────┘ │ │ ▲ │ │ │ │ ▼ │ │ ┌────┴──────┐ ┌──────────────────┐ │ │ │ Model │◀───── A/B Test ──────────│ Model Validation │ │ │ │ Registry │ (shadow mode) │ (holdout set) │ │ │ │ │ │ │ │ │ │ v1.0 ─────│──────────────────────────│ F1: 0.92 │ │ │ │ v1.1 ◄────│────────── PASS ──────────│ F1: 0.94 │ │ │ │ v2.0 ◄────│────────── PASS ──────────│ F1: 0.95 │ │ │ └───────────┘ └──────────────────┘ │ │ │ │ Sygnały do retrainingu: │ │ • accuracy < threshold (drift) │ │ • human correction rate > 15% │ │ • new intent category detected │ │ • scheduled (weekly/monthly) │ │ • volume of new labeled data > threshold │ │ │ └─────────────────────────────────────────────────────────────────────┘ ``` --- ## 8. LLM Strategy — wybór modelu ``` ┌──────────────────────────────────────────────────────────────────┐ │ LLM DEPLOYMENT STRATEGY │ ├──────────────────────────────────────────────────────────────────┤ │ │ │ BANKOWOŚĆ = WYMÓG BEZPIECZEŃSTWA DANYCH │ │ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ │ │ │ │ WARSTWA 1: On-premise / Private Cloud (RODO-safe) │ │ │ │ ┌──────────────────────────────────────────────────┐ │ │ │ │ │ • Llama 3 / Mistral / Qwen — self-hosted via │ │ │ │ │ │ vLLM / Ollama on dedicated GPU cluster │ │ │ │ │ │ • 7B-70B parametry, quantizowany (AWQ/GPTQ) │ │ │ │ │ │ • Dla: klasyfikacja, ekstrakcja, triage, │ │ │ │ │ │ generowanie sugestii (bez PII w prompt) │ │ │ │ │ └──────────────────────────────────────────────────┘ │ │ │ │ │ │ │ │ WARSTWA 2: External API (z maskowaniem PII) │ │ │ │ ┌──────────────────────────────────────────────────┐ │ │ │ │ │ • GPT-4o / Claude 3.5 Sonnet via Azure/OpenAI │ │ │ │ │ │ Enterprise (private endpoint) │ │ │ │ │ │ • Dla: zaawansowane reasoning, summarizacja, │ │ │ │ │ │ generowanie odpowiedzi do klientów (po masce) │ │ │ │ │ │ • PII maskowany PRZED wysyłką, demaskowany PO │ │ │ │ │ └──────────────────────────────────────────────────┘ │ │ │ │ │ │ │ │ WARSTWA 3: Fine-tuned Small Models (fast + cheap) │ │ │ │ ┌──────────────────────────────────────────────────┐ │ │ │ │ │ • DeBERTa-v3 (intent classification) │ │ │ │ │ │ • DistilBERT (duplicate detection) │ │ │ │ │ │ • T5-small (title/summary generation) │ │ │ │ │ │ • Klienci: on-premise, niski latency │ │ │ │ │ └──────────────────────────────────────────────────┘ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ Decision Matrix: │ │ ┌───────────────────────┬────────────┬────────────┬──────────┐ │ │ │ Task │ Warstwa │ Latency │ Koszt │ │ │ ├───────────────────────┼────────────┼────────────┼──────────┤ │ │ │ Intent classification │ W3 (fine) │ <50ms │ Very low │ │ │ │ Priority scoring │ W3 (XGB) │ <10ms │ Very low │ │ │ │ Solution suggestion │ W1 or W2 │ <2000ms │ Medium │ │ │ │ Summary generation │ W2 │ <3000ms │ Medium │ │ │ │ Customer response │ W2 │ <5000ms │ High │ │ │ └───────────────────────┴────────────┴────────────┴──────────┘ │ │ │ └──────────────────────────────────────────────────────────────────┘ ``` --- ## 9. Bezpieczeństwo i zgodność (Compliance) ``` ┌─────────────────────────────────────────────────────────────────────┐ │ SECURITY & COMPLIANCE LAYER │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ 1. OCHRONA DANYCH OSOBOWYCH (RODO/GDPR): │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ • PII Detector (regex + ML) → automatyczne maskowanie │ │ │ │ • Pseudonimizacja: klient_12345 → k_abc123 przed AI │ │ │ │ • EU-centric storage (brak transferu danych poza EU) │ │ │ │ • Right to erasure: auto-cleanup po retention period │ │ │ │ • Data minimization: AI widzi tylko needed fields │ │ │ └─────────────────────────────────────────────────────────────┘ │ │ │ │ 2. SECURITY OF AI PIPELINE: │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ • Prompt injection detection (input sanitization) │ │ │ │ • Output validation (hallucination guard) │ │ │ │ • Human-in-the-loop for critical decisions (P0, security) │ │ │ │ • AI suggestions marked as "unreviewed" until human confirms │ │ │ │ • Immutable audit trail (all AI decisions logged) │ │ │ └─────────────────────────────────────────────────────────────┘ │ │ │ │ 3. ACCESS & NETWORK: │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ • mTLS between all services │ │ │ │ • OAuth2 / OIDC for JIRA API access │ │ │ │ • Network segmentation (AI zone ≠ production zone) │ │ │ │ • Zero-trust: mutual auth for all internal calls │ │ │ │ • API rate limiting on LLM endpoints │ │ │ └─────────────────────────────────────────────────────────────┘ │ │ │ │ 4. MODEL GOVERNANCE: │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ • Explainability: SHAP values attached to each decision │ │ │ │ • Bias monitoring (check if certain customer groups │ │ │ │ get different priorities) │ │ │ │ • Model cards: documented capabilities and limitations │ │ │ │ • Fallback: if AI unavailable → graceful degradation to │ │ │ │ manual process (non-blocking) │ │ │ └─────────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────┘ ``` --- ## 10. Tryby pracy AI (risk-based) ``` ┌──────────────────────────────────────────────────────────────────┐ │ AI OPERATION MODES │ ├──────────────────────────────────────────────────────────────────┤ │ │ │ MODE 1: SHADOW (faza startowa — weeks 1-4) │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ AI analizuje zgłoszenia, ale nie tworzy ticketa. │ │ │ │ Agent robi wszystko ręcznie. AI: │ │ │ │ • podpowiada intent/kategorię w UI agenta │ │ │ │ • sugeruje priorytet │ │ │ │ • zbiera dane do walidacji │ │ │ │ Metryka: % zgodności AI vs agent │ │ │ └──────────────────────────────────────────────────────────┘ │ │ │ │ MODE 2: ASSIST (weeks 5-8) │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ AI przygotowuje pełny ticket, agent: │ │ │ │ • potwierdza / koryguje klasyfikację │ │ │ │ • potwierdza priorytet i routing │ │ │ │ • publikuje do JIRA (1 click) │ │ │ │ Metryka: czas per ticket, % korekt │ │ │ └──────────────────────────────────────────────────────────┘ │ │ │ │ MODE 3: AUTO-PILOT (week 9+) │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ AI automatycznie tworzy i routuje ticket w JIRA │ │ │ │ BEZ potwierdzenia — ale TYLKO gdy: │ │ │ │ • confidence > 0.85 │ │ │ │ • NIE jest P0 (security/CRITICAL) │ │ │ │ • nie jest nowa/kontrowersyjna kategoria │ │ │ │ │ │ │ │ P0/low-confidence → FALLBACK to human triage │ │ │ │ │ │ │ │ Monitorowane: sampled review (10% AI tickets audytowana) │ │ │ └──────────────────────────────────────────────────────────┘ │ │ │ │ MODE 4: ESCALATION / ROLLBACK │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ Triggered by: accuracy drop, incident, model drift │ │ │ │ → automatic fallback to MODE 1 or 2 │ │ │ │ → alert to AI Ops team │ │ │ └──────────────────────────────────────────────────────────┘ │ │ │ └──────────────────────────────────────────────────────────────────┘ ``` --- ## 11. Key Metrics (KPIs) ``` ┌─────────────────────────────────────────────────────────────────────┐ │ KPI DASHBOARD │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ OPERATIONAL: │ │ ┌────────────────────────────────┬──────────────┬────────────┐ │ │ │ Metryka │ Cel │ Baseline │ │ │ ├────────────────────────────────┼──────────────┼────────────┤ │ │ │ Czas triage (min) │ <2 min │ 15 min │ │ │ │ % auto-routed tickets │ >80% │ 0% │ │ │ │ AI confidence (avg) │ >0.85 │ N/A │ │ │ │ Human correction rate │ <10% │ N/A │ │ │ │ Time-to-first-response (SLA) │ <15 min │ 45 min │ │ │ │ Duplicate detection rate │ >70% │ N/A │ │ │ └────────────────────────────────┴──────────────┴────────────┘ │ │ │ │ QUALITY: │ │ ┌────────────────────────────────┬──────────────┬────────────┐ │ │ │ Metryka │ Cel │ Baseline │ │ │ ├────────────────────────────────┼──────────────┼────────────┤ │ │ │ Classification accuracy (F1) │ >0.90 │ N/A │ │ │ │ Routing accuracy │ >0.92 │ N/A │ │ │ │ Priority accuracy (vs human) │ >0.88 │ N/A │ │ │ │ Suggestion usefulness (CSAT) │ >4.0/5.0 │ N/A │ │ │ │ False P0 rate │ <1% │ N/A │ │ │ └────────────────────────────────┴──────────────┴────────────┘ │ │ │ │ BUSINESS: │ │ ┌────────────────────────────────┬──────────────┬────────────┐ │ │ │ Metryka │ Cel │ Baseline │ │ │ ├────────────────────────────────┼──────────────┼────────────┤ │ │ │ Agent time saved / ticket │ -60% │ baseline │ │ │ │ Contact Center ticket volume │ -40% manual │ baseline │ │ │ │ Customer satisfaction (CSAT) │ +15% │ baseline │ │ │ │ Mean time to resolution │ -30% │ baseline │ │ │ │ Cost per ticket processed │ -50% │ baseline │ │ │ └────────────────────────────────┴──────────────┴────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────┘ ``` --- ## 12. Roadmap wdrożenia (fazy) ``` ┌─────────────────────────────────────────────────────────────────────────┐ │ IMPLEMENTATION ROADMAP │ ├─────────────────────────────────────────────────────────────────────────┤ │ │ │ FAZA 0 — FOUNDATION (tydzień 1-4) │ │ ┌─────────────────────────────────────────────────────────────────┐ │ │ │ • JIRA API integration (adapter service) │ │ │ │ • Kafka event bus setup │ │ │ │ • PII masking pipeline │ │ │ │ • Grafana/monitoring baseline │ │ │ │ • Data collection pipeline (historical tickets → training) │ │ │ └─────────────────────────────────────────────────────────────────┘ │ │ │ │ FAZA 1 — SHADOW AI (tydzień 5-10) │ │ ┌─────────────────────────────────────────────────────────────────┐ │ │ │ • Intent classification model (fine-tuned on historical) │ │ │ │ • Priority scoring model │ │ │ │ • Basic routing rules │ │ │ │ • Shadow mode deployment + accuracy measurement │ │ │ │ • Agent feedback UI (potwierdzenie/korekta sugestii) │ │ │ └─────────────────────────────────────────────────────────────────┘ │ │ │ │ FAZA 2 — ASSIST MODE (tydzień 11-16) │ │ ┌─────────────────────────────────────────────────────────────────┐ │ │ │ • Full AI pipeline: classify → prioritize → route → enrich │ │ │ │ • RAG knowledge base (vector DB + resolved tickets) │ │ │ │ • LLM solution suggestion engine │ │ │ │ • Duplicate detection │ │ │ │ • AI-assisted mode in Contact Center UI │ │ │ │ • JIRA integration complete (auto-created drafts) │ │ │ └─────────────────────────────────────────────────────────────────┘ │ │ │ │ FAZA 3 — AUTO-PILOT (tydzień 17-24) │ │ ┌─────────────────────────────────────────────────────────────────┐ │ │ │ • Auto-routing (high confidence tickets) │ │ │ │ • Spike detection & proactive alerts │ │ │ │ • Customer response auto-suggestions (workaround for L1) │ │ │ │ • Full feedback loop → model retraining pipeline │ │ │ │ • A/B testing framework │ │ │ │ • On-call engineer auto-assignment │ │ │ └─────────────────────────────────────────────────────────────────┘ │ │ │ │ FAZA 4 — OPTIMIZATION (ciągły) │ │ ┌─────────────────────────────────────────────────────────────────┐ │ │ │ • Advanced analytics: root cause clustering, trend prediction │ │ │ │ • Cross-system correlation (JIRA + monitoring + code commits) │ │ │ │ • Predictive: auto-detect new bugs from customer patterns │ │ │ │ • Self-service: customer gets AI response directly from app │ │ │ │ • Continuous model improvement │ │ │ └─────────────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────────┘ ``` --- ## 13. Podsumowanie — architektura w jednym obrazie ``` ╔══════════════════════════════════════════════════════════════════════════╗ ║ ║ ║ Klient BM → Contact Center → [AI PIPELINE] → JIRA → Zespół Wytwórczy ║ ║ ║ ║ ┌─────────┐ ┌─────────┐ ┌──────────────────────────┐ ┌───────┐ ║ ║ │ Klient │ │ Agent │ │ AI ORCHESTRATOR │ │ JIRA │ ║ ║ │ Mobile │───▶│ CC │───▶│ │─▶│ │ ║ ║ │ Banking │ │ │ │ 1. NLP Preprocessing │ │ create│ ║ ║ └─────────┘ └─────────┘ │ 2. Intent Extraction │ │ route │ ║ ║ │ 3. Classification │ │ enrich│ ║ ║ ┌─────────┐ │ 4. Priority Scoring │ │ enrich│ ║ ║ │ Chatbot │──────────────────▶│ 5. Routing Engine │ └───┬───┘ ║ ║ │ IVR │ │ 6. Enrichment (RAG/LLM) │ │ ║ ║ └─────────┘ │ 7. Duplicate Detection │ │ ║ ║ │ 8. Solution Suggestion │ │ ║ ║ └────────────┬─────────────┘ │ ║ ║ │ │ ║ ║ ┌──────────▼──────────┐ │ ║ ║ │ FEEDBACK LOOP │◀────────┘ ║ ║ │ (metrics, learning, │ ║ ║ │ retraining) │ ║ ║ └─────────────────────┘ ║ ║ ║ ║ Tryby: SHADOW → ASSIST → AUTO-PILOT (z fallback do human triage) ║ ║ Bezpieczeństwo: PII masking, audit trail, explainability, HITL ║ ║ ║ ╚══════════════════════════════════════════════════════════════════════════╝ ``` --- Ta architektura zapewnia **80-85% automatyzacji** triage'u zgłoszeń, **redukcję czasu od 15 min do <2 min**, a jednocześnie zachowuje **human-in-the-loop** dla krytycznych przypadków (P0, security, low confidence) — co jest kluczowe w kontekście regulacyjnym sektora bankowego.

AI architecture for IT support tickets