Кожному CTO, з яким я зараз розмовляю, борд ставить те саме запитання: «Яка в нас AI-стратегія?» І більшість стратегій, написаних у відповідь, мають спільний дефект — вони описують, що компанія хотіла б зробити, а не те, що вона здатна виконати. Розрив між цими двома речами вимірюваний, і вимірювання займає близько тижня. Стратегія, написана до вимірювання, — це фікція з бюджетом.
Цей пост — та оцінка, яку проводжу я. Вона свідомо майже без нарад: більша її частина — читання систем і короткі конкретні запитання окремим інженерам. Ви можете провести її самі за рубрикою нижче.
Що насправді означає «AI-ready»?
Організація готова до AI, коли справджуються чотири речі: її дані досяжні й достатньо чисті, щоб робити по них retrieval; хоча б кілька інженерів можуть побудувати й оцінити LLM-фічу end-to-end; її тулінг уміє деплоїти і спостерігати недетерміновану систему; і хтось може сказати «ні» AI-use-case’у з реальними повноваженнями. Готовність — це підлога під кожною ініціативою: стратегія вирішує, що будувати, готовність вирішує, чи переживе хоч щось контакт із продакшеном.
Зверніть увагу, чого в списку немає: вибору вендора, вибору моделі, платформи. Ці рішення лежать нижче за течією від готовності, і змінювати їх дешевше, ніж будь-яку з чотирьох підлог.
День 1–2: чи можна робити retrieval по ваших даних?
Візьміть три джерела даних, які знадобилися б вашому найбажанішому AI-use-case’у, і спробуйте відповісти на одне реальне запитання з кожного — вручну, з наявними доступами. Заміряйте, скільки це зайняло часу і скількох людей довелося спитати. Якщо інженеру з легітимним доступом потрібні два дні і три треди у Slack, щоб зібрати контекст, який фічі знадобиться за 200 мілісекунд, фіча заблокована сантехнікою даних, а не AI.
Оцінюйте прямо: зелений — якщо дані досяжні через API або warehouse із задокументованим смислом; жовтий — якщо досяжні, але смисл живе в чиїйсь голові; червоний — якщо сам доступ уже проєкт. З мого досвіду більшість компаній, які описують себе як «ті, що сидять на золотій жилі даних», отримують червоний по двох джерелах із трьох.
День 2–3: чи є у вас навички, і де вони?
Ви рахуєте не «інженерів, які користувалися ChatGPT». Ви рахуєте інженерів, які можуть спроєктувати retrieval-пайплайн, поставити межі інструментів довкола агента і написати eval, що ловить регресію. Попросіть п’ятьох сеньорних інженерів накидати — на дошці, за десять хвилин — як би вони побудували вашу найбажанішу фічу. Ви вслухаєтесь у retrieval, структуру контексту, evaluation і вартість; у словник контекст-інжинірингу, а не у словник демо.
Двох-трьох інженерів, що проходять цю планку, достатньо, щоб почати; нуль — це знахідка, яка перекроює стратегію: вашою першою ініціативою стає побудова спроможності, а не фічі. Це кращий результат, ніж виявити те саме посеред проєкту, і цей розрив закривається цілеспрямованим навчанням (курс із RAG і агентів існує саме для цього профілю: сильні інженери, у яких поки немає продакшен-LLM-пробігу).
День 3–4: чи витримує ваш процес недетермінізм?
Традиційна розробка припускає, що однаковий вхід дає однаковий вихід; LLM-фічі ламають це припущення, і саме в процесі цей злам видно. Запитання, на яке треба відповісти: коли AI-фіча поводиться неправильно в продакшені, на що саме подивиться ваша команда? Якщо відповідь — не якась форма «на трейси, а потім додамо цю відмову в eval-набір», у вас розрив у процесі, а не в тулінгу.
Тут же я шукаю звичку до специфікацій. Команди, які записують, що фіча мусить і не мусить робити, до того як її будувати, адаптуються до AI-розробки драматично швидше — спека майже механічно перетворюється на eval-набір, а це і є корінний цикл spec-driven development. Команди, які шиплять зі Slack-тредів, виявляють, що «модель іноді робить щось дивне» — це не баг-репорт, за яким можна діяти. Якщо цієї звички немає, побудувати її — передумова, а не приємний додаток.
День 5: хто може сказати «ні»?
Готовність governance — це одне запитання: назвіть людину, яка може накласти вето на AI-use-case з міркувань ризику і домогтися, щоб воно встояло. Якщо відповідь — комітет, який ще не збирався, або сам CTO вже після того, як проєкт набрав інерцію, ставте червоний. Усе інше в governance-фреймворку — політика використання, рев’ю-гейти, межі даних — працює лише тоді, коли вето реальне.
Наслідок із цього запитання не менш показовий: назвіть use case, якому ви вже сказали «ні». Організації, які не можуть назвати жодного, не займалися governance — вони сподівалися. Написана стратегія успадковує довіру від тих «ні», на які може вказати.
Рубрика на одній сторінці
Це вся оцінка у формі, яку можна взяти з собою на зустріч із керівництвом. Оцініть кожну підлогу чесно; корисна саме та колонка, яка незручна.
| Підлога | Зелений | Жовтий | Червоний |
|---|---|---|---|
| Досяжність даних | Досяжні через API або warehouse, і смисл полів задокументований | Досяжні, але смисл живе в голові однієї людини | Отримати доступ — сам по собі проєкт |
| Навички | Троє або більше інженерів довели LLM-фічу до продакшену й оцінили її end-to-end | Один інженер може, і за ним нікого | Ніхто не може за десять хвилин накидати retrieval, межі інструментів і evals |
| Процес | Traces є, і продакшен-відмови стають новими eval-кейсами | Логи є; ніхто їх не читає, доки щось не зламається | «Воно іноді робить щось дивне» вважається баг-репортом |
| Governance | Іменована людина може накласти вето на use case — і вже це робила | Комітет існує на папері й жодного разу не збирався | Ніхто ніколи не сказав «ні» жодній AI-ідеї |
Стратегія, написана до вимірювання, — це фікція з бюджетом. Саме оцінки вище перетворюють AI-стратегію зі слайда на послідовність.
Як перетворити оцінку на стратегію
Чотири підлоги, кожна оцінена зеленим, жовтим або червоним — і тепер стратегія майже пише себе сама. Червоні — перші ініціативи; фінансувати фічі поверх них немає сенсу. Жовті чесно формують таймлайн. Зелені — те, звідки мають прийти видимі перемоги в наступні два квартали, бо стратегія без видимих перемог втрачає аудиторію незалежно від того, наскільки вона здорова.
Документ, який із цього виходить — оцінки, докази, послідовність, власники і перші дев’яносто днів, — я робив як фасилітований engagement для компаній, яким потрібне зовнішнє сеньорне око і документ, якому повірить борд: це AI readiness & strategy. Але рубрика вище — це і є весь метод. Проведіть її до того, як писати стратегію. Тиждень вимірювань б’є квартал упевненої фікції.
