PROPOSAL — Wersja Robocza

Platforma Agentów AI
dla AXI Immo

Koncepcja, Architektura i Plan Wdrożenia
Konwersacyjnych Agentów AI
dla Kluczowych Pracowników

Filip Krasiewicz — IT Po Twojemu
Digital Solutions Architect

Maj 2026  |  Dokument poufny

1 Streszczenie Wykonawcze

Niniejszy dokument przedstawia koncepcję wdrożenia platformy konwersacyjnych agentów AI dla AXI Immo — firmy działającej w branży Commercial Real Estate (CRE). Celem jest stworzenie rozwiązania, które pozwoli kluczowym pracownikom (3-5 osób) na szybki, naturalny dostęp do danych zgromadzonych w systemach CRM, bazie nieruchomości oraz dokumentach firmowych — poprzez prostą rozmowę w Microsoft Teams.

Platforma oparta jest na otwartym rozwiązaniu OpenClaw, uruchamianym na dedykowanym serwerze VPS z lokalnym modelem językowym (LLM) na sprzęcie NVIDIA DGX Spark / Dell Pro Max GB10. Dzięki temu ponad 90% zapytań obsługiwanych jest lokalnie — bez przesyłania danych firmowych do zewnętrznych dostawców chmurowych. To gwarantuje pełną sovereignty danych i zgodność z RODO.

Każdy użytkownik posiada osobnego agenta z izolowaną pamięcią i kontekstem, a dostęp do danych CRM jest ograniczony do faktycznych uprawnień danego pracownika — dzięki natywnym mechanizmom API systemu Berg System. Architektura zapewnia pełną separację między użytkownikami na poziomie fizycznym (osobne workspace'y), a nie tylko logicznym.

Oczekiwana wartość biznesowa Szacunkowo 30-60 minut oszczędności dziennie na pracownika, co przy 5 użytkownikach przekłada się na ~165 godzin odzyskanego czasu miesięcznie. Koszty operacyjne utrzymania platformy pozostają na poziomie kilkuset złotych miesięcznie dzięki lokalnemu modelowi LLM.

2 Kontekst Biznesowy

Dlaczego agenty AI w CRE?

Branża Commercial Real Estate opiera się na informacji. Pracownicy spędzają znaczną część dnia na wyszukiwaniu danych w systemach CRM, sprawdzaniu dostępności powierzchni, przeglądaniu umów i raportów, oraz przygotowywaniu zestawień dla klientów. Te zadania są powtarzalne, ale wymagają dostępu do wielu źródeł danych jednocześnie.

Problem

🔍

Fragmentacja danych

Dane rozsiane po CRM (Berg System), własnej bazie nieruchomości (AxiBaza), dokumentach na serwerach plików i SharePoint. Szukanie = klikać, czekać, klikać.

⏱️

Strata czasu

Każde proste pytanie ("Jakie mamy wolne biura 200-500m2 w centrum?") wymaga otwarcia kilku systemów i ręcznego filtrowania. 30-60 minut dziennie na operacje informacyjne.

🚫

Brak dostępu mobilnego

W terenie, na spotkaniu — szybkie pytanie wymaga otwarcia laptopa, VPN, logowania. Konwersacyjny agent w Teams rozwiązuje ten problem.

Szansa

Konwersacyjny interfejs AI, który integruje wszystkie źródła danych w jednym punkcie kontaktowym. Pracownik pyta naturalnym językiem — agent znajduje odpowiedź, filtruje, formatuje. Bez nowego UI do nauki, bez kolejnej aplikacji. Rozmowa w Teams, tak jak dotychczas.

3 Zakres Projektu

W Scope (Faza 1)

  • Konwersacyjny agent AI dostępny przez Microsoft Teams (główny kanał) i Telegram (fallback)
  • Integracja z Berg System CRM (REST API, OAuth2 machine-to-machine)
  • Integracja z AxiBaza (własna baza nieruchomości)
  • Wyszukiwanie dokumentów (RAG) — serwery plików on-premise + SharePoint
  • Osobne instancje agenta per-user z izolowaną pamięcią i kontekstem
  • RBAC — dostęp zgodny z uprawnieniami CRM pracownika
  • 3-5 kluczowych pracowników (brokerzy wyłączeni z Fazy 1)
  • Pełne zarządzanie konfiguracją przez IT Po Twojemu
⏭️

Poza Scope (Faza 1)

  • Dostęp dla brokerów (planowane w Fazie 2)
  • Dedykowany UI / dashboard
  • Aplikacja mobilna
  • Interakcje głosowe
  • Chatbot publiczny (dla klientów zewnętrznych)
  • Modyfikacja danych w CRM (Faza 1 = tylko odczyt)
  • Integracja z systemami zewnętrznymi poza wymienionymi
  • Automatyczne generowanie raportów finansowych
Zasada działania Agent odpowiada na pytania, wyszukuje informacje, podsumowuje dokumenty. Nie podejmuje akcji modyfikujących dane bez potwierdzenia. W Fazie 1 — strictly read-only do systemów źródłowych.

4 Architektura Systemu

WARSTWA UŻYTKOWNIKÓW WARSTWA KOMUNIKACJI WARSTWA AGENTÓW (OpenClaw) WARSTWA SKILLI ŹRÓDŁA DANYCH + LLM Administrator Manager Specjalista Microsoft Teams Telegram (fallback) OpenClaw Gateway (Docker) Agent: User 1 workspace / memory / skills Agent: User 2 workspace / memory / skills Agent: User 3 workspace / memory / skills Berg CRM REST API + RBAC AxiBaza Nieruchomości Dokumenty RAG / Vector Store Automatyzacja Kalendarz, szablony Berg System CRM AxiBaza Dokumenty / SharePoint M365 / Kalendarz DGX Spark (On-Premise) Qwen 34B (~61 tok/s) · Llama 70B FP8 · Embeddings Cloud (Fallback) Z.AI GLM-5.1 · OpenAI GPT-4o Dedykowany VPS · Docker Compose · Traefik Reverse Proxy · Ansible Automation · Prometheus + Grafana Monitoring
Rys. 1 — Architektura wysokiego poziomu platformy agentów AI dla AXI Immo

Kluczowe komponenty

🤖

OpenClaw Gateway

Otwarty silnik agentów AI. Zarządza sesjami, routingiem, skillami i komunikacją z LLM. Uruchamiany w kontenerze Docker. Każdy użytkownik ma osobny agent config z własnym workspace'em.

💬

Warstwa Komunikacji

Microsoft Teams Bot Framework jako główny kanał (integracja z M365 tenanta AXI). Telegram jako fallback i narzędzie testowe. Użytkownik pisze wiadomość — agent odpowiada w tym samym oknie.

🧠

DGX Spark (LLM On-Premise)

NVIDIA DGX Spark / Dell Pro Max GB10 z 128GB zunifikowanej pamięci. Uruchamia modele lokalnie — dane nigdy nie opuszczają firmy. Cloud tylko jako fallback.

🔧

Skille (Moduły)

Każda integracja to osobny skill — CRM, AxiBaza, dokumenty, automatyzacja. Modułowa architektura: dodawanie nowej integracji nie wpływa na istniejące.

5 Warstwa LLM — Strategia Hybrydowa

Strategia LLM opiera się na priorytecie lokalnym: jak najwięcej zapytań obsługujemy na sprzęcie on-premise (DGX Spark), minimalizując koszty API i zapewniając pełną kontrolę nad danymi. Cloud służy jako fallback dla zapytań przekraczających możliwości modeli lokalnych.

Modele On-Premise (DGX Spark / Dell Pro Max GB10)

Sprzęt: NVIDIA Grace Blackwell GB10, 128GB LPDDR5X, 273 GB/s bandwidth, 20 ARM v9.2 core, ~100W pod obciążeniem.

ModelFormatPamięćPrędkośćPrzeznaczenie
Qwen 34BKwantyzowany (Q4)~40 GB~61 tok/sCodzienne zapytania, CRM, wyszukiwanie nieruchomości, szybkie odpowiedzi
Llama 3.3 70BFP8~70 GB~2.7 tok/sZłożone analizy, raporty rynkowe, wieloetapowe rozumowanie
Embedding modelFP16~2-4 GBSzybkiRAG — indeksowanie i wyszukiwanie dokumentów
Multilingual E5 / NomicFP16~2 GBSzybkiEmbeddings dla języka polskiego (dokumenty, umowy)
Qwen 34B @ 61 tok/s — codzienny workhorse Przy 61 tokenach na sekundzie jest to komfortowa prędkość do interaktywnej konwersacji. Model 34B wkwantyzowany oferuje jakość wystarczającą do 90%+ codziennych zapytań CRE — od "pokaż wolne biura" po "podsumuj historię kontaktów z klientem X".
Llama 70B @ 2.7 tok/s — use case złożony 2.7 tok/s jest wolne do interaktywnej rozmowy, ale wystarczające do zadań batch — generowanie raportów, analiza trendów rynkowych, złożone reasoning. Agent może informować użytkownika: "Przygotowuję analizę, zajmie to chwilę."

Modele Cloud (Fallback / Overflow)

DostawcaModelSzacowany kosztPrzeznaczenie
Z.AIGLM-5.1Niski (polski dostawca, dane w EU)Domyślny fallback chmurowy, dobre wsparcie dla j. polskiego
OpenAIGPT-4oŚredniZłożone rozumowanie, gdy modele lokalne niewystarczające

Strategia routingu

Zapytanie Router LLM complexity + load assessment Qwen 34B 61 tok/s · codzienne Llama 70B FP8 2.7 tok/s · złożone Cloud API overflow / fallback 90%+ <10% Embedding models (lokalne) → RAG · Document indexing · Semantic search
Rys. 2 — Strategia routingu LLM: on-premise priorytet, cloud fallback
90%+
Zapytań lokalnie
0 PLN
Koszt API (lokalne)
61
tok/s (Qwen 34B)
128 GB
Pamięć DGX Spark

6 Integracje — Szczegóły Techniczne

6.1 Berg System CRM

Berg System to CRM wykorzystywany przez AXI Immo, wyposażony w otwarte API REST z dokumentacją Swagger (docs.bergsystem.pl).

ParametrSzczegóły
Typ APIREST (Swagger UI dostępny)
AutoryzacjaOAuth2 machine-to-machine (client_credentials)
Per-user scopeTAK — "Ogranicz do uprawnień współpracownika" — kluczowa funkcjonalność
Endpointy/api/customers, /api/deals, /api/activities, inne (do zmapowania)
Autoryzacja nagłówkaBearer Token + X-Tenant header (wymagany dla wersji cloud)
Token lifecycleToken z POST /api/token → Bearer w kolejnych żądaniach
Kluczowa funkcja: Per-user API token scope Berg System pozwala utworzyć osobnego klienta API per użytkownika, dziedziczącego jego uprawnienia w CRM. Oznacza to, że agent działający w imieniu Managera automatycznie widzi tylko swoje kontakty i podwładnych — nie ma dostępu do danych innych zespołów. To rozwiązuje problem RBAC na poziomie źródłowym, bez konieczności budowania własnej warstwy filtrującej.

Dwuwarstwowa kontrola dostępu:

  1. Warstwa API (Berg System natywna) — token scope ogranicza dane zwracane przez API do uprawnień danego użytkownika
  2. Warstwa skilla (dodatkowa) — agent dodatkowo filtruje i waliduje wyniki przed zaprezentowaniem użytkownikowi

6.2 AxiBaza — Baza Nieruchomości

Wymaga assessmentu AxiBaza to system własnościowy (proprietary). Przed implementacją konieczna jest analiza: czy system posiada API? Czy dostępna jest bezpośrednia access do bazy danych? Czy jedynym interfejsem jest web application? Złożoność integracji: ŚREDNIA-WYSOKA (nieznana).

Możliwe scenariusze integracji, od najprostszego:

  1. REST API dostępne — bezpośrednia integracja, analogiczna do Berg CRM
  2. Bezpośredni dostęp do bazy danych — wrapper API (FastAPI/Flask) wystawiający endpointy
  3. Tylko web interface — web scraping z cache'owaniem (najmniej stabilne, najwięcej maintenance'u)

6.3 Dokumenty — RAG (Retrieval Augmented Generation)

Dokumenty AXI są rozłożone pomiędzy serwery plików on-premise a SharePoint (M365). Agent musi przeszukiwać oba źródła semantycznie — nie po słowach kluczowych, ale po znaczeniu.

On-prem docs SharePoint Ingest Chunk Embed Vector Store ChromaDB / Qdrant Query → Agent → Odpowiedź
Rys. 3 — Pipeline RAG: ingest → chunk → embed → index → query

Embedding models działają lokalnie na DGX Spark. Obsługiwane formaty: PDF, DOCX, XLSX, wiadomości email. Pipeline dokumentów uruchamiany cyklicznie (cron) — nowe dokumenty automatycznie indeksowane.

7 Separacja Użytkowników i Bezpieczeństwo

Model izolacji: Pełna separacja per-user

Każdy użytkownik posiada osobną, fizycznie odseparowaną instancję agenta. Nie jest to podział logiczny w ramach jednego procesu — każdy agent ma własny katalog workspace, własną pamięć i własny kontekst sesji.

Agent: Administrator Workspace: /agents/axi-admin/ Pamięć: MEMORY.md (izolowana) CRM Token: Scope: pełny dostęp Sesje: Własna historia rozmów BRAK dostępu do innych agentów Agent: Manager Workspace: /agents/axi-manager/ Pamięć: MEMORY.md (izolowana) CRM Token: Scope: zespół (własny + podwładni) Sesje: Własna historia rozmów BRAK dostępu do innych agentów Agent: Specjalista Workspace: /agents/axi-specjalista/ Pamięć: MEMORY.md (izolowana) CRM Token: Scope: własne dane Sesje: Własna historia rozmów BRAK dostępu do innych agentów IZOLACJA — brak shared state między agentami
Rys. 4 — Pełna separacja per-user: każdy agent to niezależna instancja

Macierz RBAC (Role-Based Access Control)

RolaCRM — DostępBaza NieruchomościDokumenty
AdministratorPełny (wszyscy pracownicy, wszystkie deale)Pełny (odczyt + wyszukiwanie)Pełny (wszystkie dokumenty)
ManagerZespół (własny profil + podwładni)Pełny (odczyt + wyszukiwanie)Zespół (własne + zespołu)
SpecjalistaWłasny (tylko własne kontakty i deale)Tylko odczytWłasne (osobiste dokumenty)

Warstwy bezpieczeństwa

L5 · Audit — Wszystkie zapytania logowane per user, traceability pełne
L4 · Dane — Szyfrowanie at rest, brak shared memory między agentami
L3 · Aplikacja — Per-user API tokeny, session isolation, RBAC skill filter
L2 · Transport — TLS wszędzie (Traefik reverse proxy, HTTPS)
L1 · Sieć — Dedykowany VPS, VPN, brak publicznej ekspozycji

8 Zarządzanie i Utrzymanie

Infrastructure as Code

Cała infrastruktura zarządzana deklaratywnie poprzez Ansible playbooks. Jedna komenda wdraża lub aktualizuje konfigurację wszystkich agentów. Brak ręcznych zmian na serwerze — wszystko jest wersjonowane w repozytorium Git.

📦

Ansible

Playbook per-deployment. Templates → render per-user config. Dodanie nowego usera = nowy wpis w inventory, reszta automatyczna.

🐳

Docker Compose

Wszystkie usługi w kontenerach. OpenClaw, Traefik, ChromaDB, monitoring. Reprodukowalne środowisko, łatwy rollback.

🔄

Traefik

Reverse proxy + automatyczny SSL (Let's Encrypt). Routing zewnętrznych kanałów (Teams webhooki) do odpowiednich agentów.

📊

Prometheus + Grafana

Monitoring sprawdzony w produkcji (site2). Metryki: token usage per user, API response times, uptime, koszty.

Zarządzanie codzienne

Skalowalność

EtapUżytkownicyInfrastruktura
Faza 13-5 kluczowychJeden VPS + DGX Spark
Faza 210-15 (w tym brokerzy)VPS + DGX Spark + load balancer, lighter agent config dla brokerów
Faza 3+15+ użytkownikówKlaster GPU, dedykowane instancje modelu per grupę

9 Harmonogram Wdrożenia

T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 Faza 1: Fundament Faza 2: Integracje Faza 3: Dokumenty / RAG Faza 4: Komunikacja Faza 5: Pilot + Wdrożenie Fazy 3-4 mogą częściowo nakładać się w czasie
Rys. 5 — Harmonogram wdrożenia (10 tygodni)
Tydzień 1-2

Faza 1: Fundament

  • Provisioning dedykowanego VPS
  • Setup DGX Spark — modele LLM, embedding models
  • Deployment OpenClaw (Docker Compose)
  • Framework Ansible — automatyzacja deployment'u
  • Podstawowy config agenta (1 użytkownik testowy)
Tydzień 3-5

Faza 2: Integracje

  • Integracja Berg CRM API — autoryzacja, mapowanie endpointów
  • Konfiguracja per-user API tokenów z odpowiednimi scope'ami
  • Assessment AxiBaza — analiza możliwości integracji
  • Implementacja AxiBaza skill (zależna od wyniku assessmentu)
  • Implementacja RBAC — testy per rola
Tydzień 5-7

Faza 3: Dokumenty i RAG

  • Pipeline dokumentów — ingest, chunkowanie, embedding
  • Setup Vector Store (ChromaDB / Qdrant)
  • Connector SharePoint — indeksowanie istniejących dokumentów
  • Optymalizacja embeddings dla języka polskiego
Tydzień 7-8

Faza 4: Komunikacja

  • Rejestracja Teams Bot w Azure AD (wymaga dostępu admin)
  • Konfiguracja Telegram fallback
  • Routing wiadomości → odpowiedni agent per user
  • Testy end-to-end z użytkownikami
Tydzień 8-10

Faza 5: Pilot i Wdrożenie

  • Pilot z 2 użytkownikami — 2 tygodnie rzeczywistego użytkowania
  • Zbieranie feedbacku, iteracyjne poprawki promptów i skilli
  • Rozszerzenie na pełne 3-5 użytkowników
  • Dokumentacja użytkowa + szkolenie zespołu
  • Decyzja go/no-go dla Faz kolejnych

10 Analiza SWOT

💪 Mocne strony

  • Dane pozostają on-premise — pełna sovereignty, zgodność z RODO
  • Berg CRM posiada natywne per-user API scopes — RBAC out of the box
  • DGX Spark = zero kosztów API dla 90%+ zapytań, przewidywalny OpEx
  • OpenClaw — open-source, aktywnie rozwijany, sprawdzone podstawy
  • Pełna kontrola nad konfiguracją — bez zależności od zewnętrznego dostawcy SaaS
  • Modułowa architektura skilli — łatwe rozszerzanie o nowe integracje

⚠️ Słabe strony

  • AxiBaza — nieznane API, integracja wymaga assessmentu
  • Teams connector wymaga dostępu admin do Azure AD tenanta AXI
  • Jedna osoba utrzymująca infrastrukturę (IT Po Twojemu) — single point of failure
  • DGX Spark: 2.7 tok/s na modelu 70B — wolne odpowiedzi na złożone zapytania
  • Brak UI do zarządzania — zmiany wymagają ingerencji technicznej
  • Model 34B może nie poradzić sobie z bardzo złożonym rozumowaniem

🚀 Szanse

  • Rozszerzenie na brokerów (Faza 2) — drastyczny wzrost ROI
  • Template / playbook gotowy do replikacji u innych klientów CRE
  • Automatyzacja raportów rynkowych, follow-upów, analiz — nowe możliwości biznesowe
  • Competitive advantage — wczesny adopter AI w polskim CRE
  • Faza 3+: zapis do CRM (nie tylko odczyt) — pełna automatyzacja procesów

🛡️ Zagrożenia

  • Berg System API może ulec zmianie bez wcześniejszego powiadomienia
  • Hallucination — błędne ceny, dostępność, dane klientów = reputational risk
  • Over-reliance — pracownicy mogą ufać agentowi bez weryfikacji
  • Regulacje AI w doradztwie nieruchomości — potencjalne zmiany prawne
  • OpenClaw — open-source ale deep integration = koszty migracji przy zmianie
Mitigation: Hallucination Agent nigdy nie podaje danych liczbowych (ceny, metraże, dostępność) bez wskazania źródła. Każda odpowiedź zawiera referencję do rekordu CRM lub dokumentu. Przy braku pewności — agent wyraźnie komunikuje niepewność i sugeruje weryfikację.

11 Koszty i ROI

Koszty inwestycyjne (CapEx)

PozycjaKosztUwagi
DGX Spark / Dell Pro Max GB10~16,000-18,000 PLNSprzęt już dostępny, jednorazowy zakup
Setup VPS0 PLNStandard provisioning, brak kosztów setup
Razem CapEx~16,000-18,000 PLN

Koszty operacyjne (OpEx, miesięcznie)

PozycjaKoszt/mies.Uwagi
VPS hosting (Hetzner/OVH)200-400 PLNZależnie od konfiguracji
Cloud LLM API (backup)50-200 PLNTylko gdy local insufficient; przeważnie ~0
Prąd (DGX Spark, ~100W)~50-70 PLNPrzy ciągłej pracy 24/7
Utrzymanie IT Po TwojemuWg umowyOsobna umowa serwisowa
Razem OpEx (bez utrzymania)~300-670 PLN/mies.Przewidywalne, niskie koszty

Szacowany zwrot z inwestycji (ROI)

45 min
Oszczędność/dzień/user
165 h
Odzyskane godziny/miesiąc
8-12k
PLN odzyskane/miesiąc
<2 mies.
Zwrot CapEx
Kalkulacja ROI 5 użytkowników × 45 min oszczędności dziennie × 22 dni robocze = ~165 godzin odzyskanego czasu miesięcznie. Przy średnim koszcie pracownika CRE (pensja + overhead), przekłada się to na ~8,000-12,000 PLN miesięcznie wartości wygenerowanej przez oszczędność czasu. Przy CapEx ~17,000 PLN i OpEx ~500 PLN/mies., zwrot z inwestycji następuje w ciągu 2 miesięcy.

12 Szkolenia i Wdrożenie Organizacyjne

📖

Session 1: Wprowadzenie

"Czym jest AI Agent i jak z nim rozmawiać"

Czas: 60 minut | Uczestnicy: wszyscy użytkownicy

Co to jest agent, jak formułować pytania, czego można oczekiwać, a gdzie agent może się mylić. Live demo z rzeczywistymi scenariuszami CRE.

🧪

Session 2: Onboarding per-user

Testowe scenariusze indywidualne

Czas: 30 minut per user | Uczestnicy: indywidualnie

Konfiguracja na urządzeniu użytkownika, testowe zapytania do CRM, AxiBaza, dokumentów. Omówienie scope'u — co agent widzi, czego nie.

🚀

Session 3: Advanced

Zaawansowane przypadki użycia

Czas: 60 minut | Uczestnicy: wszyscy użytkownicy

Raporty, analiza trendów, złożone zapytania wieloźródłowe. Tips & tricks. Jak omijać ograniczenia.

📅

Ciągłe wsparcie

Monthly review + documentation

Czas: 30 min/miesiąc | Uczestnicy: wszyscy

Review: co działa, co nie, co poprawić. Krótki guide "Jak rozmawiać z agentem" — 1 strona A4, drukowany dla każdego usera.

Zasada szkolenia Agent ma być naturalnym narzędziem, nie "nowym systemem do nauki". Szkolenia są krótkie, praktyczne i oparte na rzeczywistych scenariuszach pracy. Użytkownik nie musi rozumieć jak działa LLM — musi wiedzieć jak zadawać pytania i jak interpretować odpowiedzi.

13 Rekomendacje i Następne Kroki

Poniższe kroki stanowią sekwencję decyzji i akcji wymaganych do rozpoczęcia wdrożenia. Każdy punkt wymaga potwierdzenia przed przejściem do następnego.

  1. Dostęp admin do Azure AD — Potwierdzenie, czy AXI Immo posiada dostęp administracyjny do tenanta Microsoft 365 (wymagane do rejestracji Teams Bota). Alternatywa: Telegram jako kanał początkowy.
  2. Assessment AxiBaza — Techniczna analiza możliwości integracji: API, dostęp do bazy, lub web interface. Określenie złożoności i czasu implementacji.
  3. Potwierdzenie scope'u — Decyzja: którzy dokładnie pracownicy (3-5) uczestniczą w Fazie 1. Określenie ról (admin/manager/specjalista).
  4. Provisioning infrastruktury — Zakup / provisioning dedykowanego VPS. Przygotowanie DGX Spark do pracy produkcyjnej.
  5. Sprint 1 — Start — Deployment infrastruktury + podstawowy agent z jednym skill (CRM) + 1 użytkownik testowy.
  6. Pilot (2 tygodnie) — Rzeczywiste użytkowanie z 2 pracownikami. Zbieranie feedbacku, iteracyjne poprawki.
  7. Decyzja go/no-go — Na podstawie wyników pilota — decyzja o pełnym wdrożeniu (3-5 users) lub korekcie kierunku.
Bloker krytyczny: Krok 1 (Azure AD) Bez dostępu admin do tenanta M365 niemożliwa jest rejestracja Teams Bota. Jest to wymagane dla głównego kanału komunikacji. Jeśli dostęp nie jest możliwy — proponuję Telegram jako kanał początkowy z migracją do Teams w późniejszym terminie.

14 Appendix

A. Berg System CRM — Przegląd API

ElementSzczegóły
DokumentacjaSwagger UI: docs.bergsystem.pl
AutoryzacjaOAuth2 client_credentials (machine-to-machine)
Token endpointPOST /api/token (client_id, client_secret, scope, grant_type)
Tenant headerX-Tenant wymagany dla wersji cloud w każdym żądaniu
Per-user scoping"Ogranicz do uprawnień współpracownika" przy tworzeniu klienta API
Zarządzanie klientami APIUstawienia systemu → Klienci API
Integracje gotoweZapier, WordPress, Kafka, Active Directory
Wersja on-premiseDostępna (indywidualny plan licencji)

B. DGX Spark / Dell Pro Max GB10 — Specyfikacja

ParametrWartość
ChipNVIDIA Grace Blackwell GB10 superchip
CPU20 ARM v9.2 core (10P + 10E)
GPUBlackwell, 48 SM, 6144 CUDA cores, 192 Tensor Cores
Pamięć128 GB LPDDR5X unified (shared CPU+GPU)
Bandwidth273 GB/s
Compute1 PFLOP sparse FP4, ~100 TFLOPS FP16
TDP140W (obserwowane ~100W pod obciążeniem)
NetworkingConnectX-7 200GbE SmartNIC
OSDGXOS (Ubuntu-based)
Qwen 34B (quantized)~61 tok/s
Llama 70B (FP8)~2.7 tok/s
Możliwość łączenia2 jednostki → 256GB combined memory

C. Słowniczek pojęć

LLM (Large Language Model) Model sztucznej inteligencji przetwarzający i generujący tekst. Przykłady: GPT-4, Llama, Qwen, GLM.
RAG (Retrieval Augmented Generation) Technika łącząca LLM z zewnętrznymi danymi — agent najpierw wyszukuje relevant dokumenty, potem generuje odpowiedź na ich podstawie.
RBAC (Role-Based Access Control) Kontrola dostępu oparta na rolach — użytkownik z rolą Manager widzi inne dane niż Specjalista.
CRM (Customer Relationship Management) System zarządzania relacjami z klientami. W AXI Immo: Berg System.
CRE (Commercial Real Estate) Nieruchomości komercyjne — biura, magazyny, powierzchnie handlowe.
Vector Store / Vector Database Baza danych przechowująca reprezentacje wektorowe tekstu. Umożliwia wyszukiwanie semantyczne (po znaczeniu, nie po słowach kluczowych).
Embeddings Reprezentacja tekstu jako wektora liczb. Podstawa wyszukiwania semantycznego w RAG.
Token (w kontekście LLM) Jednostka tekstu przetwarzana przez model (~0.75 słowa po polsku). Prędkość modelu mierzona w tokenach/sekundę (tok/s).
On-premise Rozwiązanie uruchamiane na własnym sprzęcie, bez przesyłania danych do chmury zewnętrznej.
OpenClaw Otwarta platforma (open-source) do orkiestracji agentów AI. Zarządza sesjami, komunikacją, skillami i integracjami.