Пропозиції з автоматизації зі штучним інтелектом обіцяють, що система прочитає вхідне повідомлення, витягне з нього суттєве і підготує відповідь. Але майже ніколи не договорюють другу половину фрази: куди це повідомлення під час читання піде, кому там належить сервер і як довго воно там у когось лежить.
При цьому на таке питання замовник відповідає собі сам за один вечір, якщо знає, про що питати. Цей текст описує, де текст можна зупинити до надсилання, і закінчується сімома питаннями, які працюють на будь-яку пропозицію, не лише на нашу.
Одна межа заздалегідь: нижче описана техніка, а не правова оцінка. Чи можна вам вести конкретну обробку даних, скаже юрист, а не підрядник з автоматизації.
Моделі не потрібно бачити все, що є в повідомленні
Поняття, якого в пропозиціях бракує найчастіше, - анонімізація перед надсиланням. Вона означає, що між вашою системою і моделлю стоїть крок, який замінює чутливі дані на підставні значення раніше, ніж повідомлення покине вашу інфраструктуру. Модель отримує структуру і зміст, а не особу.
На одному проєкті літа 2026 це було вимогою від самого початку. Всередині ми сформулювали це 31. 5. 2026, а клієнту описали 17. 6. 2026: між системою і моделлю працює власний анонімізатор, який замінює чутливі дані перед надсиланням, і до цього окрема інфраструктура.
Практичний сенс у тому, чого надсилати не треба. Моделі, яка має підготувати проєкт документа, потрібні тип документа, відносини між сторонами, строки і суми. Їй не потрібні ім'я, ідентифікаційний номер, адреса і номер рахунка - вони підставляються вже в готовий документ на вашому боці, після того як текст повернувся.
У заміни є одна умова, на якій усе ламається: вона має бути двосторонньою і послідовною. Коли двоє різних людей перетворюються в одному документі на одне підставне значення, модель поверне нісенітницю, яка виглядає добре.
Найкращий спосіб щось не надіслати - не надсилати взагалі
Анонімізація вирішує питання з даними, які модель бачити зобов'язана. Лишається друга група: запити, де модель не додає нічого, а ризик додає.
У нашого власного бота, який повідомляє клієнтам про стан їхньої справи, це вирішено з 10. 3. 2026 так: запит щодо конкретної справи обслуговує скриптована гілка, а не модель. Модель має право бачити назву справи і заголовки записів, але нічого, що ідентифікує людину. Бот від цього не перестав бути корисним - загальні питання, формулювання і стислі виклади так само робить модель, просто до неї не доходить та єдина частина, де помилка коштувала б найдорожче.
Це рішення ухвалюється один раз, на папері, і коштує дешево. Якщо його не ухвалити, воно ухвалиться саме: у модель потече все, бо так реалізувати простіше.
Шлюз замість прямого підключення до одного постачальника
Третє місце, де вирішується доля даних, - архітектура підключення.
У згаданому проєкті ядро спілкується з постачальниками моделей не напряму, а через один шлюз, який уміє формати кількох постачальників одразу. Вирішено 12. 6. 2026, і причина була названа вголос: не залежати від одного постачальника. Супутнє рішення від 9. 6. 2026: жодних коробкових рішень на кшталт plug-and-play; система перемикається між моделями за типом задачі.
Для замовника звідси випливають дві речі, які видно лише за рік. Коли постачальник підніме ціну, змінить умови або зніме модель, змінюється конфігурація, а не система. І коли з'ясується, що певна задача не має покидати певну територію чи певного постачальника, цю задачу можна перенаправити окремо, без перебудови решти.
На кого оформлений акаунт і де стоїть сервер
Найпрактичніше питання з усього переліку, і відповідь з'ясовується за хвилину.
На тому самому проєкті і сервер, і акаунт у постачальника моделей клієнт завів сам, на себе, 24. 6. 2026. Це не формальність: власник акаунта бачить історію викликів, платить напряму, може будь-коли змінити пароль і під час розставання з підрядником нічого не переймає, бо ніщо ніколи не покидало його імені.
Зворотна схема, коли все працює на акаунтах підрядника, сама по собі не погана і на невеликих автоматизаціях звична. Але вона має бути свідомою, і має бути написано, що станеться при припиненні співпраці. Про це є окремий текст про те, кому належать сценарії та акаунти.
Чим система живиться - те саме питання, що й те, що з неї йде
Останній шар стосується знань, а не експлуатації. Систему, яка має відповідати за вашими правилами, треба наповнити змістом. Тут два шляхи, і різняться вони залежністю.
Чужа закрита база - це швидко і приносить прив'язку до постачальника контенту: його прайс, його умови, його рішення про те, що в ній лишиться. Власне know-how плюс відкриті публічні реєстри - це повільніше на старті і майно, яке у вас лишиться. У проєкті літа 2026 ми 17. 6. 2026 обрали другий шлях і наповнювали систему внутрішніми матеріалами клієнта.
Із цим пов'язаний і спосіб навчання. Коли в системи кілька часткових агентів, кожен під свою задачу, кожен вчиться окремо на своїх даних. Один агент тим самим не знає матеріал, який до його задачі не належить, і це найдешевший спосіб обмежити масштаб можливої помилки.
Сім питань, які поставте кожному підряднику
Відповіді візьміть письмово, найкраще просто в пропозиції.
- Який конкретний постачальник моделі обробляє наші повідомлення і де фізично працює?
- Які дані з повідомлення підуть і які буде замінено перед надсиланням?
- Чи є гілка, яка до моделі не доходить взагалі, і що до неї входить?
- На кого оформлений акаунт у постачальника і хто за нього платить?
- Хто бачить історію запитів і відповідей, як довго вона зберігається і хто вміє її видалити?
- Чи будуть наші дані використані для навчання? Якщо ні, чим це підтверджено - налаштуванням акаунта, договором чи і тим і тим?
- Що станеться, якщо постачальник підніме ціну або зніме модель? Скільки роботи перемкнутися на іншого?
Сьоме питання розкриває архітектуру надійніше за перші шість. Підрядник, який відповість «це вбудовано, перемкнути не можна», відповів заразом і на питання, чия це система.
Хочете перевірити конкретну пропозицію
Надішліть нам пропозицію, яка лежить у вас на столі, навіть якщо вона від когось іншого. Повернемо перелік місць, де не сказано, що станеться з даними, і формулювання, якими це можна затребувати.
Системи, де модель працює лише з тим, що бачити зобов'язана, ми будуємо в межах автоматизації бізнес-процесів.
Напишіть на info@lamapixel.com або телефонуйте +420 775 599 009.
