„Co się psuje, gdy AI voice agenty trafiają na produkcję, i dlaczego prawie nikt tego nie przewiduje?” Ilya Ostrovskiy, Chief Product Officer w Tenios i Apifonica, wystąpił na scenie CSVD 2026 w Hamburgu 8 września.
Branża AI dużo czasu poświęca na rozmowy o tym, jak uruchomić agenta – jakiego modelu użyć, jak zbudować rozmowę i jak doprowadzić pilotaż do działania. Ale produkcja zaczyna się tam, gdzie kończy się pilotaż. Oto pięć awarii, które zwykle ujawniają się dopiero wtedy, gdy zaczynają dzwonić prawdziwi klienci końcowi. Te awarie rzadko wynikają z samego modelu językowego. Dzieją się w systemach, procesach i infrastrukturze wokół niego.
Agent mówi, że coś zrobił. System mówi co innego.
-> Dzwoniący prosi agenta o aktualizację adresu. <- Agent odpowiada, że adres został zaktualizowany.
Transkrypcja wygląda idealnie, ale aktualizacja nigdy się nie wydarzyła. Rekord w CRM pozostaje niezmieniony. To jedna z najbardziej niebezpiecznych awarii produkcyjnych, ponieważ standardowe kontrole jakości mogą jej nie wychwycić. Rozmowa brzmi poprawnie, mimo że faktyczny proces biznesowy zakończył się niepowodzeniem.
Ten sam problem może wystąpić, gdy agent odczytuje niewłaściwe pole z systemu zewnętrznego. Jeden z przykładów dotyczy dealera BMW w Toronto, gdzie AI agent zinterpretował saldo kredytu jako cenę zakupu. Język był poprawny. Interpretacja danych – nie.
Wniosek jest prosty: udana interakcja nie powinna być mierzona tym, czy agent powiedział właściwą rzecz. Powinna być mierzona tym, czy zamierzona transakcja faktycznie się wydarzyła.
Uwierzytelnianie działa w środowisku testowym. Potem pojawiają się prawdziwi dzwoniący.
Voice AI ma trudny problem, który łatwo niedocenić – uwierzytelnianie. Numer klienta, IBAN lub inny identyfikator może zawierać wiele znaków. Jeden błędny znak może unieważnić całą transakcję.
Dokładność rozpoznawania może gwałtownie spadać wraz ze wzrostem złożoności danych wejściowych – od czystych cyfr po mieszane identyfikatory alfanumeryczne i pełne numery klienta.
Mikrofon studyjny to nie telefon komórkowy w samochodzie. Czyste nagranie testowe to nie dzwoniący mówiący przez kodek telekomunikacyjny 8 kHz, z szumem tła, utratą ramek czy stłumionym dźwiękiem. To, co w pokoju brzmi w miarę dobrze, staje się dużo trudniejsze dla systemu głosowego działającego przez prawdziwe połączenie telefoniczne.
Implikacja dla testowania jest istotna. Nie testuj agenta wyłącznie przez mikrofon laptopa w kontrolowanym środowisku. Testuj go na faktycznej ścieżce telefonicznej, na prawdziwych nagraniach i z rodzajami dzwoniących, których będzie obsługiwał.
Przekazanie połączenia działa. Kontekst klienta końcowego – nie.
Przekazanie klienta końcowego do konsultanta jest często traktowane jako funkcja Voice AI. W rzeczywistości to również problem telekomunikacyjny.
Gdy AI agent przekazuje połączenie konsultantowi, co dzieje się z kontekstem? Czy konsultant wie, dlaczego klient końcowy zadzwonił? Czy klient końcowy musi tłumaczyć wszystko od nowa? Czy przekazanie działa konsekwentnie, gdy AI działa na innej infrastrukturze telekomunikacyjnej?
Jednym z obszarów, w których infrastruktura leżąca pod warstwą AI staje się kluczowa, jest właśnie przekazanie połączenia. Badania pokazują, że wiele organizacji wciąż nie potrafi przenieść kontekstu między kanałami, podczas gdy klienci końcowi są mocno sfrustrowani koniecznością powtarzania się.
Eskalacja do konsultanta to zdolność telekomunikacyjna, nie kwestia promptu. To rozróżnienie ma znaczenie, ponieważ zmiana promptu nie naprawi architektury przekazania połączeń, która nie przenosi wymaganego kontekstu.
Nikt nie zauważa awarii.
Chyba najbardziej niewygodne są przypadki, w których system AI zawodził już od miesięcy, a nawet lat. Problemem nie było to, że awaria istniała – problemem było to, że organizacja obsługująca system jej nie znalazła.
Jeden z przypadków dotyczył usługi rządowej, gdzie dzwoniący wybierający opcję w języku hiszpańskim otrzymywali skrypt w języku angielskim. Problem pozostawał aktywny przez miesiące i ostatecznie został ujawniony przez klienta końcowego na TikToku. Próba naprawy stworzyła następnie kolejny problem dla dzwoniących po angielsku.
Jeśli klienci końcowi jako pierwsi odkrywają, że Twoje AI działa wadliwie, strategia monitoringu poniosła porażkę. Zero wycofań niekoniecznie jest pozytywnym sygnałem. Organizacje z bardziej dojrzałymi mechanizmami kontrolnymi mogą w rzeczywistości raportować więcej wycofań, bo wykrywają problemy wcześniej.
System, który nigdy nie został wycofany, może po prostu być systemem, którego nikt nie obserwuje wystarczająco uważnie.
Model to nie Twój bot.
Gdy firmy oceniają dostawców Voice AI, dyskusja często koncentruje się na modelu: jakiego modelu się używa? Jak szybki i dokładny jest? Jak wypada na tle najnowszego modelu?
Ale model to tylko jedna część systemu produkcyjnego. Dzwoniący doświadcza całego łańcucha – linii telefonicznej, operatora, sieci, integracji, narzędzi, API, logiki przekazania połączeń i samego modelu.
Opóźnienie sprawia, że jest to szczególnie widoczne. Dostępny budżet czasu odpowiedzi znika, gdy model zostaje połączony z resztą stacku produkcyjnego. Realistyczne testy w systemach czasu rzeczywistego pokazały czasy odpowiedzi sięgające około 900–1150 milisekund. W tym momencie model może działać dobrze, a mimo to cała interakcja wciąż wydaje się dzwoniącemu powolna.
To samo dotyczy odporności systemu. Jeśli dostawca modelu, na którym opiera się system, przestaje działać, co dzieje się z rozmową telefoniczną? Jeśli odpowiedź brzmi, że połączenie się urywa, to system produkcyjny ma zależność leżącą poza kontrolą organizacji. Stack Voice AI to łańcuch dostaw, a nie po prostu bot.
Pięć awarii ma jedną wspólną cechę
Pięć przypadków prowadzi do jednego wniosku – żaden z tych problemów nie jest przede wszystkim problemem modelu.
Transakcja może zakończyć się niepowodzeniem, nawet gdy język jest bez zarzutu. Uwierzytelnianie może zawieść z powodu środowiska telefonicznego. Przekazanie połączenia może zawieść, bo warstwa telekomunikacyjna nie potrafi przenieść kontekstu. Poważny problem może pozostać niewidoczny, bo nikt nie jest odpowiedzialny za monitoring. Model, który sam w sobie jest w pełni sprawny, może stać się niewiarygodny, gdy zawiedzie otaczający go łańcuch dostaw.
Trzech z tych pięciu awarii nie da się naprawić powyżej linii telefonicznej. To zmienia sposób, w jaki należy oceniać projekty Voice AI. Pytanie nie brzmi już tylko, czy model potrafi zrozumieć i odpowiedzieć – brzmi, czy cały system produkcyjny potrafi wykonać transakcję, uwierzytelnić, przekazać połączenie, obserwować i wrócić do sprawności po awarii.
Co zmieniło się po nieudanych pilotażach
Po pierwsze, zaczynamy od prawdziwych nagrań rozmów, a nie od dopracowanego demo. Analizujemy, jakie przypadki występują, jak często się pojawiają i gdzie AI Voice Agent może faktycznie przejąć obsługę.
Po drugie, testujemy transakcję, a nie zdanie. Akceptacja powinna oznaczać, że oczekiwany stan faktycznie zmienia się w CRM, systemie billingowym lub środowisku ticketowym.
Po trzecie, infrastruktura telekomunikacyjna jest częścią produktu Voice AI. Jesteśmy operatorem telekomunikacyjnym, a nie firmą AI, która po prostu wynajmuje linię telefoniczną. Nasze podejście produkcyjne obejmuje kontrolę nad bazową infrastrukturą telekomunikacyjną oraz failover na poziomie warstwy AI. To decyzje architektoniczne, nie poprawki promptów.
Pięć rzeczy do sprawdzenia w poniedziałek
- Wybierz jeden przepływ i sprawdź, czy rekord w Twoim systemie faktycznie się zmienił.
- Zadzwoń do własnego agenta z telefonu komórkowego i przetestuj uwierzytelnianie z prawdziwym identyfikatorem klienta.
- Poproś o rozmowę z konsultantem i zmierz, ile trwa przekazanie połączenia oraz ile informacji musisz powtórzyć.
- Znajdź osobę, która faktycznie odpowiada za proces AI i wie, jakie metryki produkcyjne są monitorowane.
- Zapytaj dostawcę, co dzieje się podczas poważnej awarii u dostawcy modelu, i poproś o wgląd w runbook.
System Voice AI nie działa w czystym środowisku demo. Działa wewnątrz sieci telekomunikacyjnej, połączony z systemami biznesowymi, używany przez prawdziwych ludzi i mający dostarczać prawdziwe rezultaty.
Tam właśnie awarie stają się widoczne. I tam właśnie gotowość produkcyjna naprawdę się liczy.
