Приховані витрати ШІ у масштабі

У 1 червня 2026, GitHub назавжди скасував фіксовану тарифу “premium requests” для Copilot і замінив її кредитами ШІ, що нараховуються за використання. Коли через місяць після цього надійшли перші рахунки за новою моделлю, деякі користувачі‑агенти побачили рахунки, до яких не були готові: Один розробник повідомив щомісячні витрати підскочили з $29 до $750 для найважчих агентних робочих процесів.

Це був один помітний приклад ширшого зрушення на ринку інструментів ШІ протягом 2026 року — і той, який може чекати організації, які й досі сплачують фіксовану ставку.

Організації рахує час, який вони заощаджують. Багато з них не враховують те, що фіксована ставка залишає невидимим: споживання контексту та повторні спроби після збою. Інші витрати зовсім не з’являються у рахунку постачальника, включаючи час, витрачений на перевірку результатів та підтримку підказок. Коли білінг переходить на фактичне споживання, організації без дисципліни у витратах ризикують отримати рахунок, який здивує їх так само, як нова модель Copilot здивувала деяких користувачів.

Контекст, який ніхто не включив у вартість

ШІ, очевидно, потребує контексту; це не підлягає сумніву. Питання в тому, чи є надісланий контекст релевантним, чи просто зручним. Надсилання цілого документа — найшвидший спосіб надати моделі інформацію. Це не обов’язково найдешевший або найкращий спосіб.

У травні 2026 року Digital Economy Lab Стенфорда опублікувало аналіз агентних завдань кодування на восьми передових моделях і виявило, що ці завдання споживає до тисячі разів більше токенів, ніж простий чат коду, причому головним драйвером є не вихід моделі, а вхідний контекст, який вона повторно надсилає знову і знову. Агент перечитує всю свою історію на кожному наступному кроці. Той самий завдання, виконане кілька разів, різниця у споживанні токенів сягала до тридцяти разів.

Точність також не масштабується лінійно зі збільшенням обсягу контексту: часто вона досягає піку при помірному обсязі, а далі лише додає витрати без доданої цінності.

Отже, сліпість до токенів не стосується того, що ШІ не потребує контексту. Це про те, що без вимірювання ніхто не запитує, чи дійсно весь цей контекст необхідний. За фіксованою ставкою питання легко ігнорувати. За тарифом, що базується на споживанні, воно стає частиною витрат.

Коли ви платите за провал удвічі

Агентні робочі процеси несуть інший витрат, який майже ніколи не з’являється у розрахунках ROI. Уявіть спрощений ланцюжок із десяти кроків, кожен з яких має 95‑відсоткову ймовірність успішного виконання. Це звучить досить надійно, але коли їх з’єднати, у цьому ланцюжку лише близько 60 відсотків шансів пройти весь процес без жодної помилки.

У робочому процесі, який надсилає накопичений контекст знову при кожному виклику, кожен збій і наступна повторна спроба коштують не лише повтореного кроку: ви також сплачуєте знову за все, що було надіслано раніше.

Це поширений біль, який майже кожен переживає, створюючи свою першу агентну конвеєрну лінію. Я пройшов це сам. На початку, коли було лише кілька агентів, це не мало великого значення. Але коли конвеєр зростав, кожен невдалий запуск став дорожчим, і саме це змусило мене почати запитувати, який контекст потрібен кожному агенту і як його кешувати, а не лише чи пройшов запуск.

Той самий аналіз розраховує, що агент з десятьма кроками і 95‑відсотковою надійністю на крок споживає приблизно на 40 відсотків більше токенів на повторні спроби, ніж система з ідеальною надійністю. Це витрата, яку ви побачите у рахунку, але, ймовірно, її не буде в жодній таблиці ROI.

Контроль — це не помилка. Він має бути в бюджеті

Цей момент потрібно сформулювати точно, бо його легко зрозуміти неправильно. Перегляд результатів ШІ не є збоям системи; це законна, очікувана частина роботи з ШІ, так само як рев’ю коду є законною частиною роботи з розробниками. Проблема не в тому, що результати переглядаються. Проблема в тому, що ця робота майже ніколи не враховується у розрахунку того, скільки ШІ насправді заощадило.

Інститут Work AI компанії Glean опитав 6 000 працівників і виявив, що автоматизація заощаджує їм приблизно 11 годин на тиждень, але майже шість з половиною цих годин йдуть на завдання з обслуговування: надання ШІ контексту, перевірка їхньої роботи та виправлення помилок. Чистий ефект, отже, ближче до чотирьох з половиною годин — менше половини початкового показника. ШІ все ще заощаджує час, просто не стільки, як вказує перше число.

Підказки потребують обслуговування, а не лише автора

Сьогодні підказки поводяться більше як виробничий код: оновлення моделі, зміна контексту або, здавалося б, незначне редагування можуть змінити їхню продуктивність. Без версіонування та тестування ці зміни можуть тихо вносити проблеми. Регресійні тести, які є стандартною практикою для коду, все ще часто пропускаються при верифікації підказок. Зміна, що виглядає як незначне редагування однієї фрази, може потрапити у продакшн і знизити точність, і ніхто цього не помітить, доки проблема не накопичиться до видимого рівня.

Створення належної системи оцінки — включаючи тестовий набір та автоматичні регресійні тести для кожної зміни — це додаткова робота, яка майже ніколи не з’являється у розрахунку “AI saves time”.

Дешевші токени, вищі рахунки

GitHub Copilot не став винятком. За даними опитування, на яке посилається CFO Dive, майже сім із десяти компаній США повідомили про принаймні часткові перевищення бюджету на ШІ за минулий рік, здебільшого до повного переходу на оплату за споживання, а не після нього.

Bain & Company у своєму червневому аналізі токенної економіки додає парадокс, який найкраще відображає всю ситуацію: ціна за токен впала вдвічі за рік, тоді як споживання за той же період зросло в 4,5 рази.

Модель стала дешевшою, але рахунок залишився уперто високим. Компанії перейшли на новіші моделі, надали агентам складніші завдання та знайшли більше робочих процесів для них. Дешевший токен не означав менші витрати; це означало, що з’явилося більше підстав його споживати.

Як підготуватися до отримання рахунку

Запропонована структура не стосується використання меншої кількості ШІ. Йдеться про те, щоб знати, скільки коштує ШІ, перш ніж ви вирішите масштабувати його далі.

1. Спочатку отримайте прозорість

Поки ви не розподілите споживання за командами, робочими процесами, застосунками та завершеними завданнями, кожне розширення є сліпою ставкою. Така прозорість також не безкоштовна: особливо для агентних робочих процесів, відстеження кожного кроку, реєстрація того, що сталося і чому, а також моніторинг неконтрольованих циклів вимагає окремого інженерного часу та інструментів. Заплануйте це як частину вартості експлуатації ШІ, а не як додаткову думку після цього.

2. Перерахувати ROI за чистим підходом

Відніміть час, витрачений на перегляд, виправлення та підтримку підказок, від заявлених заощаджених годин. Якщо економія часу є метою випадку використання і чистий результат негативний або не піддається перевірці, його не готово до масштабування. Якщо ж передбачена вигода — це якість, потужність, зниження ризику або дохід, вимірюйте цей результат безпосередньо.

3. Застосовувати дисципліну витрат, але не однорідно

Жорстка межа витрат має сенс там, де провал недорогий: внутрішні інструменти, експериментальні агенти, середовища розробки. Для критичної функціональності, орієнтованої на клієнтів — наприклад, асистент служби підтримки — жорстка межа не працює, оскільки створює ризик відключення. У такому випадку потрібні багаторівневі резерви до дешевшої моделі та попереджувальні сигнали, а не повне вимкнення.

4. Розглядати підказки та оцінки як інженерні активи

Версіюйте їх, тестуйте та переглядайте зміни перед розгортанням, так само, як ви керуєте продукційним кодом.

Підходьте до продовжень з власними даними

Оцінити ціни постачальника важко без ваших власних даних про використання. Перед продовженням або зміною моделі розрахуйте, скільки ваші існуючі робочі процеси коштуватимуть за запропонованими умовами. Мета полягає не лише в переговорі про нижчу ціну. Це знати, як ця ціна буде поводитися при вашому реальному рівні споживання, а не дізнаватися про це з рахунку.

Три дії, які ви можете виконати цього тижня: перевірте, чи можете розбити споживання ШІ за командами та робочими процесами; оберіть один випадок використання і порівняйте час, витрачений на перегляд, з заявленими заощадженими годинами; і з’ясуйте, де жорстка межа витрат може спричинити відключення замість контролю витрат.

Витрати на ШІ можна керувати. Просто не тоді, коли ви вперше дізнаєтеся про них з рахунку.