Ukryte Koszty Budowania Voicebota na Własną Rękę – Dlaczego 'Tylko OpenAI API' to Ryzykowna Iluzja

"Mamy programistę i klucz do API OpenAI. Możemy to zbudować sami."

To zdanie pada w gabinetach dyrektorów i na spotkaniach zarządów kilka razy w roku. I brzmi rozsądnie — dopóki ktoś nie zada kolejnych pytań.

Kto wdroży integrację z Waszym HIS? Kto zbuduje obsługę PESEL i weryfikację sumy kontrolnej? Kto napisze polskie skrypty dialogowe dostosowane do medycyny? Kto zadba o RODO przy wysyłaniu danych zdrowotnych do serwerów w USA? Kto będzie utrzymywał system, gdy OpenAI zmieni swoje API — po raz trzeci w roku?

I najważniejsze: kto zadzwoni o 8:00 w poniedziałek rano, gdy bot przestanie działać i 40 pacjentów nie może się zarejestrować?

"To tylko klucz API" — anatomia mitu

Klucz do API OpenAI kosztuje grosze za token. To prawda. Ale klucz API to jeden komponent z kilkunastu, które składają się na działający voicebot medyczny:

Realna kalkulacja kosztów roku pierwszego — DIY vs. SaaS

Model DIY (budujemy sami lub z software housem):

• Senior developer / full-stack + AI: 15 000–25 000 PLN/miesiąc × 4 miesiące minimum = 60 000–100 000 PLN
• Infrastruktura cloud (hosting, API costs, monitoring): 500–2 000 PLN/miesiąc = 6 000–24 000 PLN/rok
• Konsultant RODO + DPIA dla systemu przetwarzającego dane zdrowotne art. 9: 8 000–15 000 PLN
• Integracja z jednym HIS (projekt osobny): 10 000–30 000 PLN
• Utrzymanie i poprawki (20–40 h/miesiąc developera): 5 000–10 000 PLN/miesiąc = 60 000–120 000 PLN/rok

Model SaaS (gotowe rozwiązanie medyczne):

• Abonament miesięczny z integracją HIS, wsparciem i RODO: 1 500–3 000 PLN/miesiąc = 18 000–36 000 PLN/rok
• Wdrożenie (jednorazowe): 3 000–8 000 PLN

Wartości orientacyjne dla polskiego rynku (2025). DIY: zakłada zespół zdolny do samodzielnego utrzymania. SaaS: zakłada dojrzałe rozwiązanie z integracją HIS w standardzie.

Ryzyko prawne: RODO i dane zdrowotne na serwerach OpenAI

To jest punkt, w którym "zróbmy to sami na OpenAI" przestaje być decyzją techniczną i staje się decyzją prawną — z potencjalnie poważnymi konsekwencjami.

Problem: Każda rozmowa pacjenta z botem zbudowanym na OpenAI API jest przesyłana do serwerów OpenAI w USA w celu przetworzenia przez model językowy. Jeśli w tej rozmowie padają informacje o stanie zdrowia ("chcę umówić się do onkologa", "mam cukrzycę", "szukam psychiatry") — to dane zdrowotne w rozumieniu art. 9 RODO.

Konsekwencje:

• Art. 9 RODO wymaga szczególnych podstaw prawnych dla przetwarzania danych zdrowotnych. Transfer tych danych do podmiotu trzeciego w USA wymaga albo standardowych klauzul umownych (SCC) albo innego mechanizmu z art. 46 RODO.
• Art. 28 RODO wymaga Umowy Powierzenia Przetwarzania Danych. OpenAI oferuje DPA w swoich warunkach — ale jest ona ogólna i nie zawiera specyficznych zabezpieczeń dla danych medycznych wymaganych przez UODO.
• EU-US Data Privacy Framework (lipiec 2023) ułatwia transfery danych ogólnych, ale dane zdrowotne (art. 9) pozostają kategorią wymagającą dodatkowych środków.
• UODO w swoich wytycznych konsekwentnie zaznacza, że dane szczególnych kategorii wymagają oceny skutków (DPIA) i wzmocnionych gwarancji przy transferach.

AI Act: budujesz własny system? Jesteś "dostawcą".

Rozporządzenie AI Act (UE) 2024/1689 wprowadza istotną zasadę: podmiot, który buduje i wdraża system AI w kontekście medycznym, staje się dostawcą w rozumieniu AI Act — z pełnymi obowiązkami compliance.

Oznacza to: klinika lub software house budujący bota na własne potrzeby medyczne musi przeprowadzić ocenę ryzyka, prowadzić dokumentację techniczną, zapewnić możliwość nadzoru człowieka i — jeśli system kwalifikuje się jako wysokiego ryzyka — przejść przez procedurę oceny zgodności.

Klinika kupująca gotowe SaaS od certyfikowanego dostawcy jest deployer, nie provider — z znacznie ograniczonymi obowiązkami compliance.

Degradacja jakości bez aktywnego utrzymania

Voicebot zbudowany przez software house i oddany "na produkcję" bez umowy na utrzymanie to system, który systematycznie się pogarsza:

• API HIS zmienia wersję → integracja przestaje działać lub zwraca błędy
• OpenAI wypuszcza nowy model → zachowanie bota zmienia się nieprzewidywalnie bez rekalibracji
• Zmiany prawne (AI Act nowe przepisy, UODO decyzja) → skrypty wymagają aktualizacji
• Rosnący fallback rate → bez aktywnej pracy nad modelem dialogowym bot coraz częściej nie rozumie pacjentów

FAQ — Ukryte koszty DIY voicebota medycznego

Czy open source jak Rasa lub Vosk jest alternatywą dla OpenAI w kontekście RODO? Rasa (framework dialogowy) i Vosk (ASR) działają lokalnie — co eliminuje problem transferu do USA. Ale wymagają zespołu ML do trenowania i utrzymania modeli. Polskiego modelu ASR dla terminologii medycznej w Vosk gotowego "z półki" nie ma — trzeba go zbudować na własnych danych. To projekt na kilka miesięcy dla doświadczonego zespołu ML.

Czy da się zbudować RODO-compliant bota na OpenAI API dla kliniki? Technicznie tak — ale wymaga: podpisania DPA z OpenAI z klauzulami specyficznymi dla danych art. 9, prowadzenia DPIA, weryfikacji SCC dla transferu do USA, anonimizacji lub pseudonimizacji danych przed wysłaniem do modelu (co ogranicza jakość odpowiedzi). W praktyce — koszt prawny i techniczny takiego zabezpieczenia zbliża się do kosztu gotowego SaaS.

Co jeśli mamy już zbudowanego bota DIY i chcemy przejść na SaaS? Migracja jest możliwa — historię rezerwacji i dane pacjentów eksportuje się z HIS (nie z bota). Sam bot jest zastępowany bez utraty danych medycznych. Jedynym nakładem jest czas wdrożenia nowego systemu.

Podsumowanie: "Sami zbudujemy" to nie oszczędność — to przeniesienie kosztów i ryzyk w inne miejsce

Klucz API to nie voicebot. Voicebot to produkt — z integracją, RODO, supportem, utrzymaniem i odpowiedzialnością prawną. DIY przenosi całą tę odpowiedzialność na klinikę. SaaS od wyspecjalizowanego dostawcy przenosi ją na dostawcę — który na tym właśnie się zna.

Sprawdź, ile kosztuje VoiceLink w porównaniu do Twojego szacunku DIY — i uwzględnij w kalkulacji RODO, AI Act i pierwszą awarię w poniedziałek rano. Umów rozmowę z naszym zespołem.