Słownik, do którego wraca się przy każdym wdrożeniu.

Technologia zamieniająca mowę na tekst w czasie rzeczywistym. W voicebotach ASR jest pierwszym krokiem pętli, odbiera głos rozmówcy i podaje dialog engine'owi transkrypt.

W 2026 r. rynek ASR dla polskiego obejmuje trzy kategorie silników: specjalizowane modele AI-native (niskie latencje, wysoka jakość na współczesnej polszczyźnie), silniki chmurowe dużych platform (dobra dostępność, łatwa integracja z ekosystemami enterprise), silniki open-source do hostingu na własnej infrastrukturze (kontrola danych, EU-only residency). Jakość rozpoznawania polskiego zależy od: akcentu rozmówcy, hałasu w tle, długości zdań, nazw własnych (marka samochodu, nazwa leku). Dla poprawności nazw branżowych konfiguruje się „słownik”, czyli kontekstowe ważenie słów (ang. contextual biasing, lista terminów priorytetowanych przez silnik ASR w kontekście Twojej branży).

zobacz teżTTS·Voicebot·Dialog engine

Technologia zamieniająca tekst na mowę. W voicebotach TTS generuje głos, który słyszy rozmówca; jakość polskiego TTS-u determinuje, czy rozmowa brzmi naturalnie, czy „robotycznie”.

W 2026 r. rynek TTS dla polskiego dzieli się na dwie główne kategorie: silniki AI-native (wielojęzyczne modele generatywne, najwyższa naturalność brzmienia, szerszy wybór głosów, wyższy koszt per minuta) oraz silniki chmurowe dużych platform (dobra stabilność, łatwa integracja z ekosystemami enterprise, akceptowalna jakość polskiego przy dobrej kalibracji). Oddzielną architekturą jest speech-to-speech, gdzie model generuje audio bezpośrednio bez dedykowanego kroku TTS. Dobór silnika następuje per projekt, według wymagań jakości polskiego głosu, latencji, budżetu i zgodności RODO. Wybór silnika, kalibracja intonacji, pauz i wtrąceń to jeden z kluczowych elementów jakości wdrożenia, obok scenariusza i integracji.

zobacz teżASR·Voicebot·LLM

Architektura voicebota, w której model przyjmuje audio na wejściu i generuje audio na wyjściu bezpośrednio, bez pośredniego kroku transkrypcji (ASR) i syntezy (TTS). Skraca latencję pełnej pętli kosztem węższego wyboru głosów i wyższego kosztu per minuta.

Klasyczny pipeline voicebota to trzy oddzielne kroki: ASR (mowa na tekst) → LLM (rozumienie i odpowiedź w tekście) → TTS (tekst na mowę). Architektura speech-to-speech zastępuje te trzy kroki jednym modelem pracującym natywnie z audio w obu kierunkach. Główna zaleta: niższa latencja odpowiedzi (rząd kilkuset milisekund) wobec ~400–800 ms typowego pipeline'u klasycznego. Główne kompromisy: węższa paleta dostępnych głosów i wyższy koszt per minuta niż przy dedykowanym TTS. W praktyce 2026 r. architektura S2S jest stosowana selektywnie, tam, gdzie latencja jest krytyczna i klient akceptuje kompromisy głosowo-kosztowe. Dla większości scenariuszy biznesowych (umawianie wizyt, kwalifikacja leadów) klasyczny pipeline oferuje lepszy stosunek jakości głosu do kosztu.

zobacz teżLLM·TTS·Voicebot

Warstwa oprogramowania, która zarządza przepływem rozmowy: rozgałęzieniami, fallbackami, eskalacjami, integracjami. Nie jest to LLM, dialog engine korzysta z LLM-a, ale sam egzekwuje reguły scenariusza.

Dialog engine decyduje: czy wykonać function call do CRM (np. sprawdzić dostępność wizyty), czy eskalować rozmowę do człowieka (na frazę kluczową), czy zastosować fallback („nie wiem, połączę”). Jakość wdrożenia w 70% zależy od tego, jak dialog engine jest zaprojektowany, nie od tego, który LLM jest pod spodem.

zobacz teżLLM·Voicebot·Fallback·Scenariusz rozmowy

Projektowanie instrukcji tekstowych (promptów), które sterują zachowaniem modelu językowego w voicebocie. W praktyce: określenie persony agenta, dozwolonych odpowiedzi, fallbacków, eskalacji, klauzuli RODO i AI Act.

Dobry prompt w 2026 r. dla polskiego voicebota SMB zajmuje zwykle 2–4 strony A4 i zawiera: persona (kim jest agent, w czyim imieniu dzwoni), zakres (co wolno, czego nie), słownik branżowy (produkty, usługi, terminy), fallbacks (odpowiedź, kiedy agent nie wie), eskalacje (kiedy przerwać i połączyć z człowiekiem), klauzule prawne. Jakość promptu odpowiada za 50–70% jakości rozmowy, obok jakości LLM-a i dialog engine.

zobacz teżLLM·Dialog engine·Voicebot

Zachowanie voicebota, gdy nie rozpoznaje wypowiedzi, nie zna odpowiedzi lub rozmowa wchodzi poza scenariusz. Dobry fallback: „Nie wiem, połączę z człowiekiem”, zamiast halucynacji lub improwizowanej odpowiedzi.

Fallback jest kluczowym bezpiecznikiem wdrożenia. Bez niego voicebot próbuje odpowiedzieć na wszystko, co dla medycyny, prawa, finansów jest ryzykowne (nieprawidłowa informacja = ryzyko prawne). Rekomendacja: agent ma jawny fallback w każdej gałęzi scenariusza, z jasnym progiem aktywacji (np. „rozpoznanie < 70% pewności”, „fraza poza słownikiem”, „sentyment spadł poniżej X”).

zobacz teżDialog engine·Scenariusz rozmowy·

Zaprojektowana struktura rozmowy voicebota: rozgałęzienia (np. zakup vs serwis), fallbacks, eskalacje, zakończenia. Scenariusz odzwierciedla jak dialog engine ma prowadzić rozmowę.

W polskich wdrożeniach SMB scenariusz jest typowo dokumentowany jako 2–4 strony A4 + diagram blokowy. Obejmuje: powitanie (z klauzulą AI Act + RODO), identyfikację celu rozmówcy, zbieranie danych potrzebnych do wyniku, function calls do CRM/kalendarza, zamknięcie (potwierdzenie, SMS). Scenariusz ewoluuje tygodniowo na podstawie realnych rozmów, „martwy” scenariusz po 3 miesiącach przestaje obsługiwać rzeczywiste przypadki.

zobacz teżDialog engine·Fallback·FCR

Umowa powierzenia przetwarzania danych osobowych zawarta między administratorem (klient) a procesorem (dostawca voicebota) na podstawie art. 28 RODO. Reguluje zakres danych, cele, zabezpieczenia, retencję, procedurę zgłaszania naruszeń.

Dla polskich wdrożeń DPA musi być po polsku, z polską jurysdykcją, i pokrywać minimum siedem obszarów: (1) kategorie danych i cele, (2) czas i retencja, (3) zabezpieczenia techniczne, (4) procedura zgłaszania naruszeń (w DPA ustalany termin powiadomienia, zwykle ≤ 24 h; RODO daje administratorowi 72 h na zgłoszenie do UODO), (5) prawo audytu, (6) lista podprocesorów, (7) usuwanie po zakończeniu współpracy. Dla sektorów z tajemnicą zawodową (lekarz, adwokat, doradca podatkowy), dodaje się klauzulę sektorową.

źródło · Rozporządzenie (UE) 2016/679 (RODO), art. 28↗

zobacz teżRODO·Art. 9 RODO·

Artykuł 9 RODO zakazuje przetwarzania szczególnych kategorii danych (pochodzenie rasowe / etniczne, poglądy polityczne / religijne, dane zdrowotne, biometryczne, genetyczne, życie seksualne / orientacja), z wyjątkami wymienionymi w ust. 2.

Dla wdrożeń voicebota w klinikach, gabinetach, aptekach, dentystach, stosuje się typowo art. 9 ust. 2 lit. h (niezbędność dla świadczenia opieki zdrowotnej). W DPA dla sektora medycznego dokłada się klauzulę wzmocnionej ochrony: hosting w EU, szyfrowanie w locie i spoczynku, audytowany dostęp, zero data retention lub retencja max 30 dni. DPIA (Data Protection Impact Assessment, art. 35 RODO) jest typowo wymagana.

źródło · RODO art. 9, EUR-Lex↗

zobacz teżRODO·DPA·DPIA

Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/1689 z 13 czerwca 2024 r., pierwszy kompleksowy akt prawny UE regulujący systemy sztucznej inteligencji. Wchodzi w życie etapami; transparencja (art. 50) stosowana od 2 sierpnia 2026 r.

Voiceboty konwersacyjne w standardowej obsłudze klienta zwykle podlegają obowiązkom transparentności, bez pełnego reżimu high-risk. Kluczowy obowiązek z AI Act dla voicebotów: art. 50, agent musi poinformować rozmówcę, że jest systemem AI, na początku rozmowy. Niezgodność naraża na kary administracyjne zgodnie z art. 99 AI Act.

źródło · Rozporządzenie (UE) 2024/1689, EUR-Lex↗

zobacz teżArt. 50 AI Act·Limited risk (AI Act)

Potoczne określenie systemów, które podlegają obowiązkom transparentności z AI Act, ale nie pełnej ocenie zgodności jak systemy wysokiego ryzyka. Dla voicebotów kluczowy jest art. 50.

Voiceboty do obsługi klienta, umawiania wizyt i kwalifikacji leadów zwykle są traktowane jako systemy objęte obowiązkami transparentności, a nie pełnym reżimem high-risk. Obowiązek praktyczny: jasna informacja o AI w interakcji, dowód działania komunikatu i procedura eskalacji. Systemy wysokiego ryzyka, np. AI używana w rekrutacji lub decyzjach kredytowych, mają znacznie szerszy zakres wymagań.

zobacz teżAI Act·Art. 50 AI Act

Ustawa z 12 lipca 2024 r., Prawo komunikacji elektronicznej (Dz.U. 2024 poz. 1221), która od 10 listopada 2024 r. zastąpiła Prawo telekomunikacyjne z 2004 r. Reguluje m.in. marketing bezpośredni telekomunikacyjnymi urządzeniami końcowymi (art. 398).

Dla voicebotów kluczowy jest art. 398 PKE, zakaz używania automatycznych systemów wywołujących do marketingu bezpośredniego bez uprzedniej zgody rozmówcy. Zastąpił dawny art. 172 Prawa telekomunikacyjnego. Zgody zebrane przed 10 listopada 2024 r. zachowują ważność, jeśli spełniają wymogi PKE (art. 100 przepisów wprowadzających).

źródło · Prawo komunikacji elektronicznej, ISAP↗

zobacz teżArt. 398 PKE·RODO·Cold calling

Kluczowy przepis PKE regulujący outbound marketingowy: zakazane jest używanie automatycznych systemów wywołujących (w tym voicebotów) do celów marketingu bezpośredniego, chyba że rozmówca uprzednio wyraził zgodę. Zastąpił art. 172 Prawa telekomunikacyjnego.

W praktyce wdrożeniowej art. 398 PKE oznacza: przed wykonaniem rozmowy wychodzącej z voicebota do nowego kontaktu trzeba mieć udokumentowaną zgodę na kontakt marketingowy, wyraźną, konkretną, dobrowolną, możliwą do wycofania. Cold calling automatyczny bez zgody narusza art. 398. Organ nadzorujący: Prezes UKE. Dodatkowo UODO (za naruszenie RODO) i UOKiK (za naruszenie zbiorowych interesów konsumentów).

źródło · PKE art. 398, ISAP↗

zobacz teżPKE·Cold calling·DNC

Obowiązek zachowania w tajemnicy informacji uzyskanych w związku z wykonywaniem zawodu farmaceuty, wynikający z art. 34 ustawy z 10 grudnia 2020 r. o zawodzie farmaceuty. Kluczowy dla wdrożeń voicebotów w aptekach.

W DPA z apteką rozszerzamy umownie obowiązek tajemnicy na procesora (dostawcę voicebota) i wszystkich podprocesorów. Standardowa konfiguracja: szyfrowanie w locie i spoczynku, ograniczona retencja transkryptów i nagrań, audytowany dostęp, zero data retention jako opcja. Kary za naruszenie tajemnicy zawodowej mogą być zarówno dyscyplinarne (izba aptekarska), jak i karne (art. 266 Kodeksu karnego, do 2 lat pozbawienia wolności), a dodatkowo administracyjne z RODO.

źródło · Ustawa o zawodzie farmaceuty, ISAP↗

zobacz teżDPA·RODO·Art. 9 RODO

Ocena skutków dla ochrony danych osobowych, dokument wymagany z art. 35 RODO, gdy przetwarzanie może powodować wysokie ryzyko dla praw i wolności osób (np. przetwarzanie szczególnych kategorii danych na dużą skalę).

Dla voicebota w klinice medycznej DPIA jest zwykle wymagana, przetwarzanie danych zdrowotnych na dużą skalę + nowa technologia. W DPIA opisuje się: cel i zakres przetwarzania, konieczność i proporcjonalność, ryzyka dla osób i środki je minimalizujące. DPIA nie jest publikowana, ale musi być dostępna na żądanie UODO. Przygotowuje ją administrator (klient) przy wsparciu procesora (dostawca voicebota).

źródło · RODO art. 35, EUR-Lex↗

zobacz teżRODO·Art. 9 RODO·UODO

Prezes Urzędu Ochrony Danych Osobowych, polski organ nadzorczy właściwy dla ochrony danych osobowych w rozumieniu RODO. Rozpatruje skargi, prowadzi kontrole, nakłada kary administracyjne.

Dla wdrożeń voicebota UODO jest kluczowym interesariuszem regulacyjnym. Skargi rozmówców na nieprawidłowe przetwarzanie danych (brak obowiązku informacyjnego, niewykonanie prawa do usunięcia, brak DPA) trafiają do UODO. Maksymalne kary z RODO: 20 mln EUR lub 4% globalnego obrotu (którakolwiek wyższa). Realne polskie kary 2023–2025: od kilkudziesięciu tys. do kilku mln PLN.

źródło · Urząd Ochrony Danych Osobowych↗

zobacz teżRODO·DPA·DPIA

Bezpośredni numer telefonu przypisany do konkretnego endpointu (np. voicebota, pracownika, działu). Każde wdrożenie voicebota dostaje własny DID lub pool DID-ów.

W Polsce DID-y pochodzą od międzynarodowych operatorów VoIP i polskich/europejskich dostawców SIP, lub od tradycyjnych operatorów (Orange Business, Netia). W odbierze.ai jesteśmy provider-agnostic, dobór operatora następuje per projekt, zależnie od wymogów zgodności (residency EU), regionu numeracji, funkcji SIP/WebRTC, cennika per minuta i istniejących kontraktów klienta. Wspieramy dowolnego dostawcę telefonii, jeśli klient preferuje istniejącą infrastrukturę (Orange Business, Netia, własny SIP trunk albo inny VoIP), integrujemy voicebota z jej końcówką bez zmiany operatora. Koszt DID-u w 2026 r. to orientacyjnie 5–30 zł netto/mies. Przy migracji klient może portować istniejący numer (proces 7–14 dni roboczych) lub dostać nowy DID. Porting jest bezpłatny z mocy ustawy, ale operatorzy mogą pobierać opłatę za nową usługę na przyjmującej infrastrukturze.

zobacz teżPorting numeru

Przeniesienie istniejącego numeru telefonu od dotychczasowego operatora do infrastruktury voicebota. Umożliwia zachowanie znanego klientom numeru bez zmian.

W Polsce porting jest regulowany przez Prawo komunikacji elektronicznej (PKE), w przepisach o przeniesieniu numeru przy zmianie dostawcy usługi komunikacji głosowej. Proces trwa typowo 7–14 dni roboczych; wymaga zgody abonenta i wypełnienia formularza u nowego operatora. Koszt: bezpłatny w zakresie samej zmiany operatora (z mocy ustawy), ale nowy operator może pobierać standardową opłatę za usługę, numer lub utrzymanie wirtualnej centrali. Przy niedotrzymaniu terminu przeniesienia abonentowi przysługuje odszkodowanie ustawowe (PKE art. 326).

zobacz teżDID·PKE

Rozmowa wychodząca do osoby, z którą dzwoniący nie miał wcześniejszej relacji i która nie wyraziła zgody marketingowej. W Polsce cold calling automatyczny (wykonywany przez voicebota) narusza art. 398 PKE.

Różnica ważna: cold calling „ręczny” (przez człowieka-handlowca) w Polsce jest bardziej rozmyty prawnie, ale cold calling automatycznym systemem wywołującym (voicebotem) jest jasno zakazany bez uprzedniej zgody. Rekomendacja: w outbound przez voicebota operuje się wyłącznie na bazach z udokumentowaną zgodą marketingową lub w ramach realizacji umowy z istniejącym klientem (art. 6 ust. 1 lit. b RODO).

zobacz teżArt. 398 PKE·PKE·DNC

Lista numerów telefonicznych, do których nie wykonuje się rozmów marketingowych, z uwagi na wycofanie zgody, żądanie rozmówcy lub wewnętrzną politykę firmy. Integralna część zgodnego outbound.

W wdrożeniach voicebot-outbound DNC działa na dwóch poziomach. Po pierwsze, lista wewnętrzna firmy: klienci, którzy wcześniej powiedzieli „proszę więcej nie dzwonić”, plus dobrze udokumentowane rezygnacje per kontakt zapisane w CRM. Po drugie, listy zewnętrzne, w praktyce polskiej najczęściej Lista Robinsona prowadzona przez Stowarzyszenie Marketingu Bezpośredniego (SMB) od 1996 r. Po każdej rozmowie, w której padnie prośba o DNC, numer zostaje dodany do listy natychmiast. Niewykonanie tego to naruszenie standardu i prawdopodobne naruszenie art. 21 RODO (prawo sprzeciwu).

zobacz teżCold calling·Art. 398 PKE

Inbound = rozmowa przychodząca (klient dzwoni do Twojej firmy). Outbound = rozmowa wychodząca (voicebot dzwoni do klienta). Oba scenariusze mają różne uwarunkowania prawne i projektowe.

Inbound jest w Polsce mniej regulowany, klient dzwoni z własnej woli, zgoda na rozmowę jest dorozumiana. Outbound jest silnie regulowany (art. 398 PKE, art. 6 RODO): wymaga podstawy prawnej. Typowe inbound: odbiór, rezerwacja, pytanie o cennik. Typowe outbound zgodne: potwierdzenie wizyty, odnowienie umowy istniejącego klienta, reaktywacja z bazy zgód, przypomnienie o płatności.

zobacz teżVoicebot·Cold calling·Art. 398 PKE

Fragment struktury danych Schema.org, który oznacza elementy strony przeznaczone do odczytu przez asystentów głosowych (Google Assistant). W 2026 r. wciąż w wersji beta, głównie dla publikacji wiadomości w języku angielskim.

Dla polskich stron B2B speakable nie uruchamia rich results w wyszukiwarce, Google wspiera je obecnie tylko dla US English news. Jednak jako infrastruktura przyszłościowa (AI voice delivery, konwersacyjne silniki wyszukiwania, asystenty głosowe nowej generacji) speakable jest niskokosztowym sygnałem. SpeakableSpecification stosuje się na H1, H2, akapitach kluczowych i sekcjach FAQ.

zobacz teżGEO·