# Plan techniczny MVP — asystent AI dla agenta ubezpieczeniowego z integracją CRM
Wersja: 20.09.2026. Kierunek różnicowania: ten sam rdzeń funkcjonalny co OWU Pro (czat AI po OWU), ale zaprojektowany od zera z myślą o integracji z systemami, których agencje już używają (Insly, Berg System), zamiast być kolejnym osobnym narzędziem.

## 1. Cel MVP
Zweryfikować dwie rzeczy naraz: (a) czy nasz czat AI po OWU jest wystarczająco dobry, żeby agent chciał go używać codziennie, (b) czy realna integracja z istniejącym CRM agencji (zamiast osobnej bazy klientów) jest tym, czego agentom faktycznie brakuje — to nasza teza różnicująca względem OWU Pro.

## 2. Zakres funkcjonalny v1 (celowo wąski)
- Czat AI z pytaniami o OWU w naturalnym języku, z cytowaniem paragrafu i towarzystwa (jak w OWU Pro).
- Baza 15-20 dokumentów OWU dla 2 linii produktowych na start (np. OC/AC komunikacyjne + ubezpieczenie mieszkania) — publicznie dostępne dokumenty ze stron towarzystw.
- Prosty eksport/import: CSV z listą klientów i polis (do wczytania z tego, co agent ma już w swoim CRM) zamiast budowania własnej, równoległej bazy klientów od zera.
- Webhook/API do odbioru zdarzeń z zewnątrz (na start: ręczny import, docelowo integracja).
- Panel z historią zapytań AI (do analizy, o co pytają agenci — to dane do dalszego rozwoju).
- Bez CRM-owych "wszystkich dzwonków" OWU Pro (zadania zespołu, prowizje, wznowienia) w wersji 1 — to dodajemy po walidacji, jeśli w ogóle, bo to nie jest nasza przewaga.

## 3. Uwaga do tezy integracyjnej — do zweryfikowania przed budową
Nie znalazłem publicznie dostępnej dokumentacji API ani dla Insly, ani dla Berg System (sprawdzone 20.09.2026) — obie firmy prezentują się jako zamknięte platformy SaaS bez jawnie opisanego API dla zewnętrznych integratorów. To oznacza, że "głęboka integracja" może w praktyce wymagać: (a) kontaktu z tymi firmami i negocjacji dostępu do API/partnerstwa, (b) integracji przez eksport/import plików (CSV/XLS), które oba systemy zwykle wspierają, albo (c) budowy rozszerzenia przeglądarkowego, które czyta dane z ekranu ich aplikacji webowej (rozwiązanie tymczasowe, kruche, ale szybkie do zrobienia). Zanim zainwestujesz czas w "prawdziwe" API, warto to zweryfikować bezpośrednio z Insly/Berg System lub z agentami, którzy tych narzędzi używają — to pierwszy krok, nie założenie.

## 4. Architektura techniczna
- **Frontend**: Next.js (React), mobile-first (agenci pracują głównie z telefonu/tabletu w terenie — tak jak w OWU Pro).
- **Backend**: Next.js API routes lub osobny serwis FastAPI (Python), jeśli pipeline RAG ma być bardziej rozbudowany.
- **Baza danych**: PostgreSQL (Supabase lub Neon) — jedna baza dla danych aplikacji i wektorów (rozszerzenie pgvector), żeby nie utrzymywać osobnej bazy wektorowej na start.
- **Autentykacja**: Supabase Auth albo Clerk — gotowe rozwiązanie, nie budować własnego.
- **LLM / RAG**: Claude API (Anthropic) lub GPT — do wyboru na podstawie testów jakości odpowiedzi na polskich dokumentach prawnych; embeddingi (np. OpenAI text-embedding lub Voyage) do wyszukiwania fragmentów OWU.
- **Ingestion dokumentów**: parsowanie PDF (pdfplumber / unstructured.io), chunkowanie po paragrafach/sekcjach (nie po stałej liczbie znaków — ważne, żeby cytowanie "§12 ust. 1" było precyzyjne), tagowanie metadanymi (towarzystwo, produkt, data obowiązywania).
- **Integracja zewnętrzna**: warstwa importu CSV/XLS jako v1, z architekturą gotową pod webhooki/API (osobny moduł "connectors", żeby dodanie API Insly/Berg System w przyszłości nie wymagało przebudowy całości).
- **Hosting**: Vercel (frontend + API routes) + Supabase (baza + auth) — minimalny koszt startowy, szybkie wdrożenie solo.

## 5. Pipeline RAG — kluczowe zasady (na podstawie tego, co dobrze działa w OWU Pro)
1. Chunking zachowujący strukturę prawną dokumentu (numer paragrafu/ustępu w metadanych każdego fragmentu).
2. Odpowiedź AI zawsze z: (a) dosłownym cytatem z OWU, (b) numerem paragrafu i nazwą towarzystwa, (c) wskaźnikiem pewności, (d) stałym zastrzeżeniem "AI może się mylić — zweryfikuj z oryginałem OWU".
3. Brak automatycznych decyzji — AI tylko wspiera agenta, nie podejmuje decyzji o zakresie ochrony ani cenie (ważne też pod kątem unijnego AI Act — patrz notatka z wcześniejszej analizy dokumentu).
4. Test jakości: zestaw 20-30 pytań referencyjnych (z realnych OWU) do sprawdzania trafności odpowiedzi przy każdej zmianie pipeline'u.

## 6. Harmonogram (6 tygodni, praca solo/mały zespół)
| Tydzień | Zadanie |
|---|---|
| 1 | Zbiórka 15-20 dokumentów OWU (2 linie produktowe), setup repo/hosting/bazy, kontakt z Insly i Berg System w sprawie API |
| 2 | Pipeline ingestion (parsing, chunking, embeddingi) + testy jakości odpowiedzi na 20-30 pytaniach referencyjnych |
| 3 | UI czatu (frontend) + cytowanie źródeł + historia zapytań |
| 4 | Import CSV klientów/polis + prosty widok listy klientów |
| 5 | Logowanie, pierwsze testy z 3-5 realnymi agentami (z listy z wcześniejszego planu walidacji) |
| 6 | Poprawki na podstawie feedbacku, decyzja: kontynuować / pivot / zamknąć |

## 7. Budżet startowy (rząd wielkości)
- Hosting (Vercel + Supabase): darmowe tiery wystarczą na MVP i pierwsze testy.
- LLM API: kilkadziesiąt-kilkaset zł/miesiąc przy niskim wolumenie testowym.
- Domena: ~50-100 zł/rok.
- Brak potrzeby zewnętrznego finansowania na start — to ma być bootstrapowalne.

## 8. Kwestie prawne do domknięcia równolegle (nie blokują budowy MVP, ale przed pierwszymi płacącymi klientami)
- Regulamin/polityka prywatności z jasnym zapisem: narzędzie wspiera agenta, nie jest pośrednikiem ubezpieczeniowym, nie podejmuje decyzji za klienta.
- RODO: nie przechowywać w v1 żadnych danych zdrowotnych klientów (to ograniczenie zakresu MVP, nie tylko formalność).
- Rozważyć konsultację prawną nt. klasyfikacji pod AI Act, jeśli w przyszłości dojdzie funkcja rekomendacji konkretnej polisy/sumy ubezpieczenia dla konkretnego klienta.

## 9. Metryki sukcesu MVP
- Liczba pytań zadanych do AI tygodniowo przez testowych agentów.
- Subiektywna trafność odpowiedzi oceniana przez agentów (np. kciuk w górę/w dół przy każdej odpowiedzi).
- Czy agent woli importować dane z istniejącego CRM, czy woli wpisywać ręcznie (test tezy integracyjnej).

## 10. Źródła / kontekst
- Analiza konkurencji: owu-pro-analiza-konkurencji.md (ten sam folder)
- Mapa strony OWU Pro: owu-pro-mapa-strony.txt (ten sam folder)