Каждому 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. Но рубрика выше — это и есть весь метод. Проведите её до того, как писать стратегию. Неделя измерений бьёт квартал уверенной фикции.
