Интеграции
Права доступа: что ИИ-агент может и чего не может делать в каждой системе
Как доступ к каждой из ваших систем предоставляется, ограничивается, утверждается и регистрируется в журнале, с примерами наборов прав доступа для недвижимости, туризма и страхования.
На этой странице
- У каждой системы своя учётная запись для интеграции
- Чтение и запись разрешаются отдельно, для каждого действия
- Решения, которые остаются за вашей командой, никогда не подключаются
- Действия, требующие утверждения, ждут, пока их утвердит сотрудник
- Примеры наборов прав доступа
- Как хранятся и ротируются учётные данные
- Каждое обращение регистрируется в журнале
- На практике
- Что контролирует ваша команда
- См. также
В ваших системах ИИ-агент может делать ровно то, что разрешила ваша команда, и ничего больше. Доступ задаётся отдельно для каждой системы и каждого действия через учётные записи, которые создают и контролируют ваши администраторы. Решения, которые остаются за вашими сотрудниками, никогда не подключаются; действия, требующие утверждения, ждут, пока их утвердит сотрудник; каждое обращение агента регистрируется в журнале. На этой странице объясняется, как это работает, и показано, как выглядит типичный набор прав доступа в сфере недвижимости, туризма и страхования.
У каждой системы своя учётная запись для интеграции
Агент подключается к каждой из ваших систем через выделенную учётную запись для интеграции: учётную запись, созданную только для этого подключения и отдельную от учётных записей сотрудников. Ваши администраторы создают её в вашей собственной системе так же, как для любого другого сервиса, который к ней подключается.
Поскольку учётная запись принадлежит вам, ваша команда может видеть, что ей разрешено, просматривать её действия в журналах самой системы и в любой момент приостановить её. Приостановка учётной записи сразу прекращает работу подключения, без каких-либо изменений на стороне Telonic. После этого агент сообщает клиентам, что не может выполнить запрос такого рода, и предлагает связаться с сотрудником.
Чтение и запись разрешаются отдельно, для каждого действия
Доступ строится по принципу минимальных привилегий: у учётной записи для интеграции есть только тот доступ, который нужен для роли агента. Доступ на чтение и доступ на запись предоставляются отдельно для каждой системы. В рамках доступа на запись каждое действие разрешается по отдельности, поэтому агент, который может создать заявку на ремонт, не получает тем самым возможности изменить цену объекта.
Действие, которое не разрешено, невозможно вызвать. Агента не просят избегать его: вызывать просто нечего, как бы клиент ни сформулировал запрос. Там, где агент может действовать, допустимые значения берутся из ваших правил.
Он может предложить варианты перебронирования, которые допускает тариф, или ваучер в пределах вашего лимита, и ничего сверх этого. См. раздел Политики как ограничения.
Решения, которые остаются за вашей командой, никогда не подключаются
Некоторые действия существуют в ваших системах, но агенту никогда не предоставляются. В страховании функции, которые определяют ответственность, устанавливают сумму страхового возмещения или утверждают либо отклоняют выплату по убытку, не открываются агенту ни в одном развёртывании. Тот же подход применяется к решениям, которые вы оставляете за вашей командой в сфере недвижимости и туризма, например к возврату средств вне рамок политики или изменению плана платежей.
Эта разница важна для всех, кто оценивает риски. Правило «не утверждать выплаты по убыткам» зависит от того, соблюдает ли его система. Интеграция, к которой не подключена функция утверждения, не может утвердить выплату по убытку. См. раздел Границы принятия решений.
Действия, требующие утверждения, ждут, пока их утвердит сотрудник
Между тем, что агент делает самостоятельно, и тем, к чему он никогда не прикасается, есть действия, которые вы хотите сначала передать на проверку сотруднику. Для таких действий агент подготавливает всё необходимое для утверждения и не выполняет действие, пока назначенный сотрудник вашей команды не утвердит или не отклонит его. Клиенту сообщают, что будет дальше и когда.
Вы решаете, какие действия требуют утверждения и кто их утверждает. Часто начинают с того, что требуют утверждения для большего числа действий, а затем отменяют это требование, когда у вашей команды появится уверенность в том, как они выполняются.
Примеры наборов прав доступа
Права доступа для каждого развёртывания согласуются с вашей ИТ-службой при внедрении. В примерах ниже показаны типичные исходные настройки. CRM в каждом примере означает систему, в которой хранятся записи о клиентах этой организации.
Недвижимость: CRM застройщика, календарь передачи объектов и система технического обслуживания
| Система | Чтение | Разрешённые действия | Требует утверждения | Не подключено |
|---|---|---|---|---|
| CRM | Контакты, объекты, графики платежей | Создание и обновление лидов, добавление заметок о диалогах | Нет | Изменение цен объектов, изменение планов платежей |
| Календарь передачи объектов | Свободные слоты | Запись на передачу объекта и перенос записи | Нет | Удаление других записей |
| Система технического обслуживания | Заявки по объекту клиента | Создание заявки на ремонт, добавление примечания | Нет | Закрытие или переназначение заявок |
| Платёжный провайдер | Статус платежа | Отправка ссылки на оплату причитающейся суммы | Ссылки на суммы, которых нет в графике | Возвраты средств |
Туризм и гостеприимство: система бронирования и сервис-деск гостиничной сети
| Система | Чтение | Разрешённые действия | Требует утверждения | Не подключено |
|---|---|---|---|---|
| Система бронирования | Бронирования, тарифы, наличие номеров, условия тарифов | Изменение дат в пределах условий тарифа, добавление пожеланий гостя к проживанию | Повышение категории номера, освобождение от сборов | Возвраты вне рамок политики, ручное изменение тарифов |
| Сервис-деск | Заявки гостя | Создание заявки, добавление комментария | Нет | Закрытие заявок |
| CRM | Профиль гостя и уровень в программе лояльности | Добавление заметок о диалогах | Нет | Изменение баллов программы лояльности |
Страхование: системы полисов и урегулирования убытков автостраховщика
| Система | Чтение | Разрешённые действия | Требует утверждения | Не подключено |
|---|---|---|---|---|
| Система администрирования полисов | Полис, покрытие, франшиза, утверждённые формулировки | Нет | Нет | Изменение покрытия, оформление дополнений к полису |
| Система урегулирования убытков | Статус убытка и недостающие документы | Регистрация убытка (первичное уведомление о страховом случае, то есть первое сообщение об убытке), прикрепление документов, добавление примечания | Нет | Оценка ответственности, установление суммы страхового возмещения или резерва, утверждение или отклонение выплаты по убытку |
| CRM | Контактные данные страхователя | Добавление заметок о диалогах | Нет | Объединение или удаление записей о клиентах |
Как хранятся и ротируются учётные данные
Учётные данные каждой учётной записи для интеграции хранятся в вашем развёртывании в зашифрованном виде с использованием AES-256 (Advanced Encryption Standard с 256-битными ключами), никогда не включаются в инструкции агента и не видны языковой модели. Если система поддерживает OAuth (стандарт, который позволяет одной системе предоставить другой ограниченный доступ без передачи пароля), он используется вместо хранимого пароля.
Учётные данные ротируются (заменяются новыми) в соответствии с вашей политикой безопасности, а также немедленно, если любая из сторон подозревает, что они были скомпрометированы. При размещении в вашем собственном облачном аккаунте или на вашей собственной инфраструктуре учётные данные остаются внутри вашей среды и защищены ключами, которые контролируете вы. Каждое соединение с вашими системами использует TLS (Transport Layer Security, стандартное шифрование данных при передаче) версии 1.2 или выше.
Каждое обращение регистрируется в журнале
Каждое обращение агента к вашим системам фиксируется в журнале аудита: какая система, какое действие, какая запись, когда, для какого диалога и с каким результатом. Ваша служба комплаенса может открыть любой диалог и увидеть, что именно агент прочитал и что изменил. Журналы вашей собственной системы показывают те же действия под учётной записью для интеграции, поэтому эти данные можно сверить. См. раздел Журнал аудита и записи о решениях.
На практике
Страховая компания Wadi Assurance, которая занимается автострахованием и страхованием жилья, настраивает права доступа для своего развёртывания по урегулированию убытков.
- Отдел урегулирования убытков, служба комплаенса и ИТ-служба встречаются с Telonic, чтобы согласовать, чем будет заниматься агент: первичными уведомлениями о страховых случаях, статусом убытков и сбором документов.
- ИТ-служба создаёт в системе урегулирования убытков учётную запись для интеграции с тремя действиями: регистрация убытка, прикрепление документа и добавление примечания. Действия, которые меняют статус убытка или резерв (сумму, отложенную для выплаты по убытку), не предоставляются.
- Служба комплаенса просит ввести утверждение для одного действия: любого сообщения страхователю о том, что убыток закрыт.
- В 21:00 Tariq сообщает о столкновении. Агент регистрирует убыток и прикрепляет к нему фотографии, которые прислал страхователь. Когда Tariq спрашивает, заплатит ли страховщик другого водителя, агент объясняет, что это решит специалист по урегулированию убытков, который ведёт его дело, и сообщает, когда с ним свяжутся.
- Во время ежеквартальной проверки доступа ИТ-служба сравнивает действия учётной записи для интеграции в системе урегулирования убытков с журналом аудита Telonic. Данные совпадают.
Что контролирует ваша команда
- Учётная запись для интеграции с каждой системой, включая её приостановку.
- Что агент может читать и записывать в каждой системе и какие действия может выполнять.
- Какие действия ждут утверждения и кто их утверждает.
- Когда ротируются учётные данные.