Технічний контекст
Я все частіше бачу ту саму картину: компанія оголошує «AI-трансформацію», запускає кілька пілотів, купує доступ до моделі, збирає внутрішній чат-бот, а за пів року все це обростає погодженнями й тихо тоне в legacy. На цьому тлі підхід Block чіпляє не хайпом, а жорсткістю виконання.
Якщо дивитися на відкриті факти, у Block це не виглядало як разова ініціатива «давайте прикрутимо LLM». Вони йшли через повну перебудову: інфраструктура, хмара, аналітика, MLOps, внутрішні AI-агенти та новий режим роботи для інженерної команди. Тобто не косметика, а зміна операційної моделі.
Я переглянув доступні матеріали по кейсу Block, і там найцікавіше не в одному агенті Goose і не в красивому AI-маніфесті. Зачепило інше: вони не намагалися подружити ШІ з безладом. Вони спочатку створювали середовище, в якому AI-архітектура взагалі може жити без милиць.
Ось де зазвичай все ламається:
- дані розмазані по системах і нікому по-справжньому не належать;
- доступи, комплаєнс і безпека вбивають швидкість ще до продакшену;
- команди створюють десять непов'язаних AI-продуктів без спільної архітектури ШІ-рішень;
- керівництво чекає магії від моделі, хоча проблема в процесі та відповідальності.
На цьому тлі розмови в дусі «треба просто поступово адаптуватися» звучать приємно, але в enterprise це часто самозаспокоєння. Поступовість працює, коли в компанії вже є нормальний фундамент. Коли фундаменту немає, поступовість просто розтягує хаос у часі.
З Klarna, до речі, якраз показовий контраст. Навколо неї було багато розмов про різкі кроки, скорочення та ставку на ШІ, але публічний галас і стійка трансформація бізнесу — це не одне й те саме. Якщо людей потім доводиться повертати або перезбирати процеси заново, значить проблема була не в темпі, а в неправильній моделі змін.
Вплив на бізнес та автоматизацію
Я б узагалі перестав дивитися на AI-трансформацію як на проєкт із датою закінчення. Ця рамка вже застаріла. Зараз перемагає не той, хто «трансформувався», а той, хто навчився жити в режимі постійної адаптації (endless adoption), коли автоматизація за допомогою ШІ стає постійною здатністю компанії, а не спецоперацією на один фінансовий рік.
Для бізнесу це змінює все: бюджетування, ролі команд, стек, пріоритети IT і навіть найм. Потрібні не просто аналітики та розробники, а люди, які можуть збирати AI-архітектуру під конкретний контур: де залишити людину, де дати агенту автономність, де закрити ризик правилами та аудитом.
Виграють компанії, які готові різати зайві погодження, об'єднувати дані та швидко відправляти робочі сценарії в прод. Програють ті, хто робить вигляд, що впровадження штучного інтелекту можна провести як звичайний ERP-апгрейд. Не можна. Занадто висока турбулентність, занадто швидко змінюється сам інструментарій.
Я це бачу і в клієнтських кейсах Nahornyi AI Lab. Там, де бізнес приходить із запитом «зробіть нам одного AI-агента», майже завжди розкривається глибше завдання: переробити маршрут даних, перезібрати ownership, пов'язати CRM, helpdesk, документи, внутрішні бази й тільки потім робити ШІ інтеграцію. Інакше агент просто автоматизує безлад.
Тому «метод Block» я б сформулював простіше. Не обов'язково звільняти всіх саботерів, як це люблять писати в обговореннях. Але точно потрібно перестати вмовляти систему, яка структурно чинить опір змінам. Іноді дешевше радикально перезібрати контур, ніж роками латати старий.
Якщо вам потрібно не поговорити про хайп, а реально зробити ШІ автоматизацію, створити ШІ агента під ваш процес або зібрати робочу архітектуру ШІ-рішень, я з цим працюю руками. Я Вадим Нагорний, Nahornyi AI Lab. Якщо хочете обговорити ваш кейс, замовити ШІ автоматизацію або n8n автоматизацію під бізнес-завдання, пишіть мені, розберемо предметно.