Optima Voice: як влаштований HIPAA-сумісний голосовий агент від початку до кінця.
Зібрати платформу голосового AI відносно просто. Зібрати таку, що може безпечно обробляти захищену медичну інформацію, — зовсім інша задача.
Коли команда збирає перший прототип голосового AI, вона оптимізує швидкість. Обрати LLM. Підключити розпізнавання мовлення. Додати синтез. Задеплоїти. За вихідні виходить щось, що відповідає на телефонні дзвінки.
Проблема в тому, що стека, якого вистачає для демо, часто і близько недостатньо для охорони здоров'я.
Ми зрозуміли це рано, ще коли будували Optima Voice. Якщо ми хотіли працювати з лікарнями, медичними страховиками чи федеральними відомствами на кшталт CMS і VA, HIPAA не міг бути чимось другорядним. Він мав впливати на кожне архітектурне рішення з першого дня. Ось стек, до якого ми прийшли, і чому.
Чому більшості голосових AI-стеків недостатньо
Типовий голосовий AI-застосунок сьогодні може використовувати:
- OpenAI або Anthropic як мовну модель
- ElevenLabs для синтезу мовлення
- OpenRouter для маршрутизації моделей
- звичайну хмару для всього іншого
Для експериментів це чудовий набір. Але робота із захищеною медичною інформацією (PHI) приносить зовсім інший набір вимог. Щойно в розмові з'являються дані пацієнта, треба думати про угоди Business Associate Agreement (BAA), шифрування, журнали аудиту, контроль доступу, політики логування та терміни зберігання даних. Архітектура перестає бути суто технічною задачею — вона стає юридичною та операційною. Тому ми вирішили проєктувати платформу навколо вимог HIPAA, а не підганяти комплаєнс заднім числом.
Архітектура, яку ми обрали
Перебравши варіанти, ми стандартизували майже все на AWS. Один хмарний провайдер радикально спростив безпеку та комплаєнс. Замість того щоб зшивати півдюжини вендорів, ми отримали єдину модель ідентифікації, єдину стратегію шифрування, спільний моніторинг і контроль доступу.
Ключові компоненти стека та сервіси, що за ними стоять.
Як дзвінок проходить через систему
На верхньому рівні кожен телефонний дзвінок іде простим шляхом:
А ось рішення з безпеки, що за цим стоять, — зовсім не прості.
Чотири рішення, важливіші за вибір AI-моделі
Enterprise-готовність системи визначається не вибором між Claude і Llama. Значно важливіші ось ці рішення.
1. Не зберігайте PHI без крайньої потреби
Кожна зайва копія даних пацієнта — ще одна зона відповідальності за безпеку. Там, де можливо, транскрипти не повинні перетворюватися на постійні логи. Аудіозаписи мають бути зашифровані, закриті контролем доступу і зберігатися лише за реальної бізнес- чи регуляторної потреби. Що менше чутливих даних ви тримаєте, то нижчий ризик.
2. Давайте кожному сервісу мінімально необхідні права
Кожен компонент має працювати за принципом найменших привілеїв. Мовленнєвим сервісам не потрібен доступ до бази даних. LLM не повинна напряму ходити у сховище. Кожен сервіс робить одну роботу і нічого більше. Це зменшує і кількість операційних помилок, і поверхню атаки.
3. Ізолюйте дані клієнтів
Медичні організації очікують, що їхні дані повністю відокремлені від чужих. Що це означає на практиці — окремі префікси у сховищі, виділені бази даних чи навіть окремі AWS-акаунти — залежить від вашої архітектури. Важливо, щоб ізоляція орендарів була закладена від самого початку, а не додана потім.
4. Шифруйте все
Шифрування не має бути черговим пунктом у роадмапі. Воно має бути:
• Під час передачі
• Під час зберігання
• У бекапах
Сучасні хмарні провайдери роблять це досить простим, тож причин не ввімкнути шифрування всюди майже немає.
Чотири принципи архітектури, продиктовані HIPAA.
А що з FedRAMP?
Якщо ви плануєте працювати з федеральним урядом США, HIPAA — лише частина картини. Багато відомств вимагають, щоб рішення працювали у хмарних середовищах з авторизацією FedRAMP. Одна з причин, чому ми обрали AWS, — сервіси, на які ми спираємося, доступні у FedRAMP-авторизованій інфраструктурі AWS. Автоматично FedRAMP-сумісним ваш застосунок це не робить. Вам усе одно треба документувати заходи безпеки, підтримувати операційні процедури, проводити ревізії доступу, моніторити середовище і готуватися до незалежних перевірок. Хмарний провайдер відповідає за інфраструктуру. За застосунок відповідаєте ви.
Дорога частина — не комплаєнс
Одна хибна думка мене здивувала. Часто вважають, що HIPAA різко збільшує витрати на інфраструктуру. За нашим досвідом, витрати не там. Шифроване сховище, IAM, журнали аудиту та керовані сервіси AWS майже не змінюють місячний рахунок. Справжня інвестиція — це планування.
Писати політики безпеки. Проєктувати контроль доступу. Документувати процедури. Рев'юїти архітектуру. Перевіряти припущення.
Ця робота потребує часу, але якщо побудувати систему правильно від початку, це здебільшого разова інвестиція. Більшість команд переоцінюють вартість інфраструктури і недооцінюють вартість документації.
Чому це важливо для нас
Відомства, пов'язані з охороною здоров'я, — один із найбільших сегментів федеральних витрат на контакт-центри. Якщо ваша платформа не вміє безпечно обробляти медичні розмови, ви фактично виключаєте себе зі значної частини цього ринку ще до старту. Для нас HIPAA не був черговою фічею в роадмапі. Він став одним із проєктних обмежень, які сформували Optima Voice з першого дня.
Якби я починав сьогодні
Знаючи те, що знаю зараз, я б одразу ухвалив чотири рішення:
1. Обрати хмарного провайдера, який підтримує медичні навантаження.
2. Перевіряти кожен сторонній сервіс до того, як відправляти через нього PHI.
3. Побудувати шифрування, керування ідентифікацією та логування до бізнес-логіки.
4. Ставитися до комплаєнсу як до частини архітектури, а не як до сертифіката, яким займетеся потім.
Добудовувати безпеку заднім числом майже завжди складніше, ніж спроєктувати її з першого дня. В охороні здоров'я — ще й набагато дорожче.
Ця стаття відображає архітектуру та проєктні рішення, ухвалені під час створення Optima Voice. Це не юридична консультація і не рекомендації з комплаєнсу.
Oleksii Kocherev
CEO, Gravity PRO LLC
Будуємо Optima Voice — голосові AI-агенти для бізнесу та держави
Оригінал статті опубліковано на Medium.