Якщо пояснювати, що таке API простими словами, то це двері між програмами: одна програма звертається до іншої і просить дані або дію за заздалегідь описаними правилами. У цих дверей є замок, тобто ключ і права доступу, які визначають, що саме дозволено, і є журнал, куди записується кожен запит і кожна відповідь. Тому фраза "агент підключений до CRM" сама по собі нічого не говорить про безпеку. CRM, тобто система, де компанія веде клієнтів, угоди й заявки, може дозволяти агенту лише читати, може дозволяти йому готувати чернетки, а може відкрити бойову дію, після якої щось реально змінюється в базі або йде клієнту. Агентом я називаю програму на основі штучного інтелекту, тобто моделі, яка розуміє людську мову і вміє виконувати кроки в інших системах. Після слова "підключений" я завжди ставлю два запитання: який рівень доступу і де лежить лог.
Ця сцена відбулася на демонстрації для інтернет-магазину. Магазин хотів ШІ-менеджера, який відповідає покупцям у чаті і сам оформлює доставку. На екрані агент прочитав повідомлення покупця, створив заявку в CRM, підтягнув місто й відділення і сформував чернетку ТТН, тобто товарно-транспортної накладної, за якою перевізник приймає посилку. Хтось спитав, як це працює, і інтегратор, людина, яка зʼєднує системи між собою, відповів двома словами: "через API". У кімнаті закивали, бо слово звучало солідно і ніби закривало всі питання. Я кивати не став, бо за цими двома словами ховалося головне: які саме двері відчинені, хто тримає ключ і що станеться, коли агент наступного разу помилиться з адресою або з сумою накладеного платежу.
Коротко
- API працює як двері між програмами, і в цих дверей завжди є замок і журнал.
- Слово "підключено" описує сам факт зʼєднання, а межі дозволеного описує список дозволів.
- Доступ агента має три рівні: читати, готувати чернетку і виконувати бойову дію.
- API Нової Пошти для агента відкриває довідник і чернетку ТТН, а відправку підтверджує людина.
- Мінімальний контроль тримається на пʼяти речах: окремий ключ, найменші права, журнал, тестове середовище і відкликання ключа.
Що насправді означає "підключений"
Коли я працюю з конекторами, тобто готовими зʼєднаннями між моделлю і сервісами на кшталт пошти, календаря чи сайту, я постійно бачу одну і ту саму плутанину. Статус "підключено" означає тільки те, що двері між програмами існують і ключ підходить до замка. Про ACL, тобто список дозволів, де записано, які дії відкриті для цього ключа, цей статус мовчить. Ці дві речі живуть окремо. Можна мати підключений конектор, який бачить одну папку, і можна мати конектор з таким самим статусом, який бачить усю пошту компанії і може писати від імені директора. В інтерфейсі вони виглядають однаково.
Друга пастка повʼязана з тестуванням. Read-only sandbox, тобто тестова пісочниця лише для читання, дає відчуття, що все під контролем: агент працює з копією даних і нічого в них змінити не може. Коли ж ту саму інтеграцію переносять у робочу систему, ключ там нерідко видають інший, ширший, бо так швидше налаштувати. Те, що перевірили в пісочниці, і те, що запустили в роботу, стають двома різними конструкціями, хоча на схемі в презентації вони намальовані однією стрілкою.
Третій ефект найменш очевидний, і його я пояснюю підприємцям найдовше. Модель може резюмувати документ, до якого людина, що поставила задачу, формально доступу не мала. Менеджер просить агента зібрати історію клієнта, а ключ агента бачить усю CRM разом з договорами інших відділів, і в коротке резюме потрапляють умови, яких менеджеру знати не належало. Ніхто нічого не зламував. Двері виявились ширшими за задачу, і модель сумлінно прочитала все, до чого дотягнулась.
Три рівні: прочитати, підготувати, змінити
Вісімнадцять років на фінансових ринках привчили мене дивитись на будь-який доступ так, як дивляться на брокерський рахунок. Доступ на перегляд показує позиції і виписки. Право подавати заявки дозволяє купувати і продавати. Право виводити кошти забирає гроші з рахунку. Жоден розсудливий інвестор не дасть аналітику третій рівень лише тому, що аналітику треба бачити портфель. З API логіка та сама, і рівнів теж три.
Перший рівень означає читати. Агент відкриває рахунок в обліковій системі або ERP, тобто в програмі, де компанія веде облік грошей, товарів і документів, бачить суму, дату й контрагента, порівнює з оплатою і показує, де розбіжність. У базі від цього нічого не змінюється. Найгірше, що може статись на цьому рівні, це хибний висновок, який людина перевірить перед тим, як на нього спертися.
Другий рівень означає чернетку. Агент складає лист клієнту, заповнює картку угоди, формує заявку, і все це лежить у статусі, який ще нічого не запускає. Людина відкриває чернетку, дивиться, виправляє і вирішує, що з нею робити далі. Помилка тут коштує кількох хвилин уваги.
Третій рівень означає бойову дію: провести оплату, змінити статус угоди на "оплачено", надіслати лист, створити запис, який побачить клієнт чи бухгалтерія. Тут помилка виходить за межі екрана і починає жити власним життям у чужій пошті, у звітності або на складі перевізника.
У себе я тримаю загальне правило: рахунки з облікової системи агент читає, договори аналізує, а бойовий запис для нього закритий без людської перевірки. Перехід з другого рівня на третій проходить через approve. Approve я розумію як явне підтвердження людини перед бойовою дією: конкретна людина бачить, що саме зараз станеться, натискає кнопку, і система записує, хто це зробив і коли. Галочка в налаштуваннях "дозволити агенту діяти самостійно" такою перевіркою не є, вона лише переносить відповідальність туди, де її ніхто не побачить.
Нова Пошта як приклад: довідник, чернетка ТТН, відправка
На доставці ці три рівні видно найкраще, і саме тому я люблю розбирати їх на прикладі, який знає кожен український підприємець. API Нової Пошти для агента відкриває кілька дуже різних речей.
Перша з них це довідник: список міст, відділень, поштоматів, тарифів і строків доставки. Читати довідник безпечно, і саме він дає агенту змогу відповісти покупцю в чаті, чи є відділення в його селищі і скільки коштуватиме доставка. Друга річ це чернетка ТТН: агент заповнює отримувача, телефон, номер відділення, вагу, оголошену вартість і суму накладеного платежу. Третя річ це відправка, коли накладна стає зобовʼязанням, посилку передають перевізнику, а з покупця потім візьмуть гроші при отриманні.
Ключ API власник генерує у своєму бізнес-кабінеті перевізника, і такий ключ зазвичай відкриває широкий набір можливостей одразу. Тобто сама наявність ключа в агента технічно може дозволяти йому створювати накладні одну за одною без жодної зупинки. Тому "агент підключений до Нової Пошти" для мене означає лише, що двері існують. Право відправити посилку це окреме рішення, яке власник ухвалює сам, і в розумній схемі воно проходить через approve.
Ціну помилки тут легко порахувати. Переплутаний номер телефону, сусіднє відділення з подібною назвою або зайвий нуль у сумі накладеного платежу означають повернення, оплату доставки в обидва боки і покупця, який більше до вас не прийде. На демо з початку статті агент зупинився на чернетці ТТН, і це була правильна зупинка. Запитання в кімнаті мало звучати так: що втримає його на чернетці наступного разу, якщо ключ той самий.
Мінімальний контроль, який я вимагаю
Перша вимога: окремий ключ для кожного конектора. Якщо чат-бот, CRM і доставка працюють на одному спільному ключі, ви не знаєте, хто з них що зробив, і відкликати доступ одному без зупинки всіх неможливо.
Друга вимога: найменші права. Ключ відкриває рівно ті дії, які потрібні для задачі. Агенту, який відповідає покупцям про строки, вистачає довідника, а право створювати накладні він отримує тоді, коли зʼявляється процес з людським підтвердженням.
Третя вимога: журнал запитів і результатів. У лозі видно, що агент запитав, що отримав у відповідь і що змінив. Я дивлюсь такий журнал раз на тиждень так само, як дивлюсь виписку з банку, і цього зазвичай досить, щоб помітити дивну активність задовго до того, як вона стане проблемою.
Четверта вимога: тестове середовище з тими самими правами, що й робоче. Пісочниця має сенс, коли в ній перевіряють саме ту конфігурацію, яку потім запустять на живих клієнтах.
Пʼята вимога: можливість відкликання ключа. Потрібно заздалегідь знати, хто в компанії це робить, де саме і скільки хвилин це займає. Відкликання ключа працює як заміна замка, коли ключ від дверей опинився не в тих руках.
Що питати інтегратора
Як ШІ підключається до CRM, інтегратор пояснює охоче, бо це приємна частина роботи. Мене більше цікавить інша частина, і запитання в мене завжди ті самі. Який рівень доступу отримує агент у кожній системі, окремо для читання, чернеток і бойових дій. Чиїм імʼям виданий ключ і скільки таких ключів. Де лежить лог, скільки часу він зберігається і хто його читає. Що агент робить, коли не впевнений або отримує помилку від іншої програми. Чи збігаються права в пісочниці і в робочій системі. Як відкликати ключ і хто це вміє робити без інтегратора.
Сумлінний інтегратор відповідає на все це за кілька хвилин і показує екран з налаштуваннями. Якщо відповідь знову звучить як "через API", розмову треба продовжувати, поки на столі не зʼявиться список дозволів.
Що робити далі
- Випишіть усі системи, до яких у вашій компанії вже підключені агенти, боти або автоматизації, разом з тим, хто їх налаштовував.
- Для кожного підключення позначте рівень: читати, чернетка або бойова дія, і перевірте, чи цей рівень відповідає задачі.
- Попросіть інтегратора показати список дозволів кожного ключа і лог запитів за останній тиждень.
- Для доставки розведіть рівні: довідник і чернетка ТТН для агента, відправка тільки після approve відповідальної людини.
- Відкличте один тестовий ключ і засічіть, скільки часу це забрало і хто в компанії зміг це зробити.
Про цей матеріал
Це навчальний матеріал для власників і керівників малого бізнесу, які тільки знайомляться з ШІ-агентами та інтеграціями. Він пояснює логіку доступів і рівнів контролю, а конкретну інтеграцію перед запуском варто перевірити разом із фахівцем, який відповідає за безпеку ваших систем. Можливості API у сервісах змінюються, тому актуальний перелік прав і методів звіряйте з документацією постачальника.