Урок 4: One-pager для руководства — защитить AI-проект за 5 минут

Чему вы научитесь

• Собирать one-pager для AI-проекта так, чтобы руководитель понял проблему, решение и бюджет за один проход
• Укладывать проект в 7 обязательных блоков: деньги, решение, цифры, риски, сроки, команда, следующий шаг
• Переписывать один и тот же проект под CEO, CFO и ИБ без смены сути и без потери доверия
• Отсекать слабые защиты: «у нас будет AI», неподтверждённый ROI, пустой блок рисков и отсутствие TCO
• Проверять одностраничник перед встречей по чек-листу и не заходить на защиту с сырым документом

На совещании руководству не нужен рассказ о том, что такое LLM, CV или цифровой двойник. Нужен ответ на три вопроса: где теряются деньги, сколько стоит исправление и что мешает внедрить проект. Это особенно важно в промышленности, где эффекты уже измеряются не в процентах на слайде, а в больших суммах: ЕВРАЗ сообщал об экономическом эффекте 5,8 млрд ₽ за 2024 год, Северсталь — более 1 млрд ₽, Норникель — о диапазоне $70–100 млн EBITDA-эффекта в отдельных AI-сценариях.

Поэтому one-pager — не «маленькая презентация». Это управленческий документ, который сжимает расчёт ROI из урока 1, TCO из урока 6 модуля p.2 и ограничения по КИИ из урока 2 модуля p.3 в один лист. Если этот лист слабый, проект не дойдёт до пилота, даже если технически решение сильное.

Семь блоков, без которых one-pager не работает

flowchart TD
    A[7 обязательных блоков] --> B[Проблема в деньгах]
    A --> C[Что делаем]
    A --> D[Цифры проекта]
    A --> E[Риски]
    A --> F[Сроки]
    A --> G[Команда]
    A --> H[Следующий шаг]
    B --> I{Адаптация под роль}
    C --> I
    D --> I
    E --> I
    F --> I
    G --> I
    H --> I
    I --> J[CEO]
    I --> K[CFO]
    I --> L[ИБ]
    J --> M[Финальный one-pager]
    K --> M
    L --> M

Это жёсткая рамка. Не добавляйте в неё историю компании, обзор рынка и десять логотипов вендоров. Одностраничник должен отвечать на вопрос: «Почему я должен разрешить это сейчас, а не когда-нибудь потом?»

Как выглядит сильная первая строка

Сильная первая строка всегда привязана к потерям или к нереализованной выручке. Слабая — к технологии.

• Слабо: «Предлагаем внедрить AI-решение для интеллектуального анализа качества продукции».
• Сильно: «На линии холодного проката предприятие теряет [X млн ₽ в год] на повторной переработке и списаниях; предлагаем сократить эти потери за счёт CV-контроля на всём потоке продукции, а не на выборочной инспекции». Для метрики проекта используйте расчёт из урока 1.

Та же логика работает для LLM-сценариев. Не пишите «внедрим корпоративного AI-ассистента». Пишите: «Инженеры тратят [X часов в месяц] на поиск регламентов и подготовку ответов по типовым инцидентам; предлагаем сократить это время за счёт RAG-ассистента в допустимом контуре». Если контур попадает в КИИ, внешнее иностранное SaaS-решение для значимого объекта надо считать запрещённым по закону, а не просто неудобным по санкциям (Указ № 166 от 30.03.2022; Указ № 250 от 01.05.2022; ПП № 1912 от 14.11.2023; также урок p.3/02).

Текстовый мокап одностраничника

Ниже — не «красивый шаблон», а рабочий каркас. Его можно вставить в Word, Confluence или на первый слайд записки. Подставляйте свои значения только после расчёта.

НАЗВАНИЕ ПРОЕКТА
AI-контроль [процесса / документа / оборудования] на [площадка / линия / функция]

1. ПРОБЛЕМА В ДЕНЬГАХ
Сейчас мы теряем [X ₽ в год] из-за [брака / простоев / ручной обработки / перерасхода].
Текущая метрика: [AS-IS]. Целевая метрика: [TO-BE].

2. ЧТО ПРЕДЛАГАЕМ СДЕЛАТЬ
Запустить [CV / RAG / прогнозную модель / оптимизатор режимов] для [конкретный процесс].
Контур: [public API / private VPC / on-prem / air-gap] — выбрать по правилам из p.2 и p.3.
Человек в контуре: [где оператор подтверждает решение / где автоматизация запрещена].

3. ЦИФРЫ
CapEx: [сумма]
OpEx в год: [сумма]
Годовая экономия: [сумма]
Payback: [месяцы]
ROI первого года: [проценты]
TCO на выбранный горизонт: [сумма]
Допущения: [что именно заложено в расчёт]

4. ТРИ ГЛАВНЫХ РИСКА
— [качество данных]
— [интеграция с legacy / MES / SCADA / ERP]
— [ПД / КИИ / санкции / ИБ]

5. СРОКИ
Discovery: [дата] → результат [что получаем]
Pilot: [дата] → результат [какой KPI подтверждён]
Scale-out: [дата] → результат [какой контур и сколько площадок]

6. КОМАНДА
Владелец бизнеса: [роль]
ИБ / КИИ: [роль]
ИТ / интеграция: [роль]
Оператор процесса: [роль]
Юрист / DPO: [роль, если нужны ПД или внешний сервис]

7. ЧТО НУЖНО СЕЙЧАС
Просим: [утвердить discovery / выделить бюджет пилота / назначить владельца / открыть доступ к данным]
Срок решения: [дата]

Ключевой принцип мокапа: каждая строка должна либо вести к деньгам, либо снимать риск. Всё остальное — лишнее. Если хочется добавить блок «архитектура решения», спросите себя: помогает ли это принять решение именно этому адресату. В большинстве случаев архитектура уезжает в приложение, а не в one-pager.

Один проект, три версии: CEO, CFO, ИБ

Суть проекта не меняется. Меняется первый экран документа и акцент на риске. Это та часть, где большинство команд ошибается: они показывают один и тот же лист всем подряд и удивляются, почему CFO спрашивает про TCO, а ИБ — про контур и подрядчика.

Для ИБ-версии есть две вещи, которые нельзя размывать.

Во-первых, если проект касается значимого объекта КИИ, в документе должен быть прямой вывод о допустимости контура. Не «планируем использовать облачный сервис», а «внешний иностранный облачный контур для данного сценария не рассматривается» — именно в такой логике, потому что для значимого объекта ограничения начинаются на уровне архитектуры (187-ФЗ; Указ № 166; урок p.3/02).

Во-вторых, в ИБ-версии должен быть назван владелец безопасности. Указ № 250 и ПП № 1272 закрепили требование к заместителю руководителя по ИБ и профильному подразделению для охваченных организаций (Указ № 250; ПП № 1272 от 15.07.2022). Если в one-pager нет ответа на вопрос «кто отвечает за контур и инцидент», ИБ будет права, когда затормозит проект.

Частые ошибки, которые убивают защиту

1. «У нас будет AI» вместо конкретной задачи

Это самая дорогая ошибка. Руководство не инвестирует в слово «AI». Оно инвестирует в уменьшение брака, снижение простоев, ускорение документооборота или защиту от регуляторного риска. Если задача не названа в первом абзаце, считайте, что one-pager уже проиграл.

2. Нет TCO

Проект приносит цифру годовой экономии, но не показывает, сколько стоит модель, интеграция, сопровождение, железо или API. CFO видит это сразу. Чтобы не спорить на встрече, в one-pager должны быть хотя бы три числа: CapEx, OpEx и горизонт TCO. Детальный расчёт уводите в приложение, но итог в самом документе обязателен — см. урок p.2/06.

3. Фантастический ROI

Проблема не в том, что цифра высокая. Проблема в том, что её нечем защитить. Если проект обещает космический ROI, а на вопрос «из каких предпосылок» команда отвечает общими словами, доверие исчезает. Защищайте проект консервативно: лучше прийти с нижней оценкой и превзойти её на факте, чем переобещать и потерять следующий бюджет (логика защиты также следует из методики расчёта в уроке 1 модуля p.4).

4. Игнор ИБ и юр-контура

В AI-проекте «риски обсудим потом» не работает. Если есть ПД, нужен законный режим обработки; если есть КИИ, нужен допустимый контур; если есть внешний подрядчик, нужны роли и договорные ограничения. Это не приложение к проекту, а часть самого бизнес-кейса (152-ФЗ, ст. 22.1; урок p.3/02; урок p.3/08).

5. В one-pager засунули всю презентацию

Десять логотипов, несколько архитектурных схем, прогноз рынка GenAI на далёкий горизонт и сравнительную таблицу моделей. Всё это делает документ длиннее, но не сильнее. Одностраничник должен вести к решению. Всё, что не ведёт, уезжает в приложение.

Чек-лист перед защитой

1. Проверьте, что первая строка говорит о деньгах. Не о платформе, не о модели, не о «цифровой трансформации».

2. Убедитесь, что в документе есть и CapEx, и OpEx. Если есть только экономия, это не бизнес-кейс.

3. Оставьте только один целевой KPI. Один главный KPI лучше, чем пять равноправных обещаний.

4. Покажите базовый и консервативный сценарий. Так CFO видит диапазон, а не рекламный максимум.

5. Уберите из основного листа всё, что не помогает принять решение сейчас. Архитектуру, бенчмарки, обзор рынка — в приложение.

6. Проверьте контур данных и правовую допустимость. Для значимого КИИ это вопрос архитектуры; для ПД — вопрос законности обработки.

7. Назовите владельца проекта и владельца риска. Бизнес-владелец без владельца ИБ — это незавершённая конструкция.

8. Сформулируйте три риска и три меры. Не восемнадцать, а три. Руководитель должен помнить их после встречи.

9. Проверьте, что следующий шаг можно реально одобрить на этой встрече. Формулировка «поддержать развитие AI» бесполезна. Формулировка «утвердить discovery на сумму [X] и назначить владельца» — рабочая.

10. Сделайте три версии первого абзаца. Отдельно для CEO, отдельно для CFO, отдельно для ИБ. Один текст на всех — почти всегда ошибка.

Как связать one-pager с остальными документами проекта

Правильная последовательность такая:

1. Сначала вы считаете ROI и payback — это урок 1 модуля p.4.
2. Потом считаете TCO и проверяете, не умирает ли экономика на выбранном контуре — это урок 6 модуля p.2.
3. Затем проверяете, можно ли вообще запускать проект в выбранной архитектуре — это урок 2 модуля p.3 и, если есть внешний сервис, урок p.3/05 (санкции 2026).
4. И только после этого упаковываете проект в one-pager для решения.

Если сделать наоборот, получится красивая записка без основания. Сильный one-pager — это последний шаг перед защитой, а не первый.

Итоги