Оценка готовности к ИИ: чек-лист для малого бизнеса

Оценка готовности к ИИ нужна, чтобы понять, какую задачу можно безопасно поручить ему на пробу. Это не знак отличия для компании. Ответьте на 15 вопросов по пяти направлениям, проверьте условия, без которых запуск невозможен, и спланируйте следующие 90 дней. Для компании из 10-200 сотрудников полезен конкретный ответ: этот рабочий процесс можно запустить с такими мерами контроля — или сначала нужно устранить такие пробелы.

Начните с одного рабочего процесса

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

Представьте, что вы проверяете автомобиль перед конкретной поездкой. Наличие ключей ещё не говорит о том, исправны ли тормоза и подходит ли машина для выбранного маршрута. Подписка на ИИ — это ключи. А данные, права доступа, проверяющие и правила работы определяют, стоит ли отправляться в путь.

Выберите повторяющуюся задачу с понятными входными данными, результатом, который можно проверить, и ответственным. «Улучшить работу компании» — слишком широко. «Составить еженедельный отчёт по проекту на основе согласованных заметок, чтобы руководитель проекта проверил его перед отправкой» — уже задача, которую можно оценить.

Этот чек-лист рассчитан на небольшой пробный запуск повседневной задачи под контролем человека. Решения, затрагивающие наём, кредитование, здоровье, безопасность или юридические права, требуют отдельной оценки специалистами соответствующего профиля. Высокий балл в этом чек-листе не даёт разрешения на такое применение.

Владелец бизнеса или операционный директор определяет нужный результат и назначает ответственного. Руководитель ИТ проверяет права доступа и настройки. Сотрудник, который выполняет задачу, рассказывает о нестандартных случаях и оценивает пользу результата. В небольшой компании один человек может совмещать несколько ролей, но все проверки всё равно нужны.

Оценка готовности к ИИ: чек-лист на одну страницу

Ставьте баллы только за то, что можете подтвердить сегодня. Политика, которую никто не читал, настройка, которую никто не проверял, или проверяющий, который ещё не пробовал оценивать результат, заслуживают максимум частичного балла.

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

Скопируйте в документ блок от Задача до Следующее действие. Подтверждающие скриншоты, примеры файлов и заметки храните в отдельной папке: так сам чек-лист останется компактным.

Чек-лист готовности к ИИ

Задача: __________ Ответственный: __________ Дата: __________

Оцените каждый ответ: 0 = ничего нет или неизвестно; 1 = подтверждено частично; 2 = полностью подтверждено для этой задачи. Рядом с баллом кратко укажите, где найти подтверждение. Если вопрос включает несколько проверок, для 2 должны быть выполнены все. По каждому направлению можно набрать 6 баллов, всего — 30.

A. Задача, которую стоит автоматизировать

• A1. Есть ли повторяющаяся задача с назначенным ответственным, понятными входными данными и результатом?
• A2. Зафиксированы ли по недавним примерам частота выполнения задачи, текущее время обработки и типичные ошибки?
• A3. Описано ли, что должен содержать полезный результат, и есть ли примеры приемлемого и неприемлемого результата?

B. Данные и доступ

• B1. Актуальны ли типичные входные данные, читаемы ли они и достаточно ли единообразны для этой задачи?
• B2. УСЛОВИЕ ДОПУСКА: Подтверждено ли разрешение использовать эти данные в этом инструменте для этой цели?
• B3. УСЛОВИЕ ДОПУСКА: Проверено ли, что пользователям и подключённым сервисам доступна только информация, разрешённая для этой задачи?

C. Уже оплаченные инструменты

• C1. Проверены ли действующие подписки, включённые функции, доступные лицензии для пользователей и ответственные за администрирование?
• C2. УСЛОВИЕ ДОПУСКА: Одобрил ли администратор конкретный инструмент и аккаунт, проверил ли настройки и условия обработки данных?
• C3. Может ли предлагаемый рабочий процесс принять нужные материалы и выдать пригодный результат без неподтверждённых допущений?

D. Люди и навыки

• D1. Назначен ли ответственный за пробный запуск, выделено ли ему время и есть ли сотрудник на замену?
• D2. УСЛОВИЕ ДОПУСКА: Умеет ли назначенный проверяющий сверять факты с источниками и замечать ошибки с существенными последствиями?
• D3. Отработали ли будущие пользователи выполнение задачи, в том числе как поставить ответ под сомнение и сообщить о проблеме?

E. Риски и правила

• E1. УСЛОВИЕ ДОПУСКА: Записаны ли разрешённые входные данные, допустимые и запрещённые способы использования, и понятны ли они участникам?
• E2. Определено ли, кому может навредить ошибка и какие случаи нужно передавать на рассмотрение ответственному?
• E3. УСЛОВИЕ ДОПУСКА: Отработаны ли согласование человеком, остановка пробного запуска, сообщение об инциденте и возврат к ручному процессу?

Итого: A ___/6 + B ___/6 + C ___/6 + D ___/6 + E ___/6 = ___/30.

Решение: 0-11: подготовить базовые условия. 12-21: подготовить пилот с чёткими границами. 22-30: провести пилот с измерением результатов, если все условия допуска выполнены. Любое условие допуска с баллом ниже 2 запрещает использование реальных данных компании или клиентов и применение результатов в работе; допустимы только синтетические примеры в одобренной среде. Любое направление с оценкой ниже 3/6 нужно доработать до расширения пилота.

Следующее действие: __________ Исполнитель: __________ Срок: __________

Чем подтвердить оценку?

Достаточно короткой заметки со ссылкой на то, что можно проверить. Для B2 укажите, кто из владельцев данных разрешил их использование и какие ограничения установлены. Для B3 покажите проверку прав доступа из аккаунта обычного участника пилота, а не только из аккаунта администратора. Для C2 зафиксируйте тип аккаунта, применимые условия хранения данных и их использования для обучения, включённые подключения и дату проверки. Фраза «поставщик говорит, что всё безопасно» на эти вопросы не отвечает.

Для D2 предложите проверяющему сравнить черновик с источником и найти намеренно добавленную фактическую ошибку. Явно обозначьте, что это учебное упражнение, и используйте синтетические материалы. Важно убедиться, что человек умеет проверять результат, прежде чем на эту проверку начнут полагаться.

Неизвестно — значит 0, а не «наверное, всё в порядке». Если коллеги расходятся во мнениях, ставьте меньший балл, пока не найдёте подтверждения. Планы что-то исправить в следующем месяце баллов не приносят.

Как спланировать следующие 90 дней по итогам оценки

Диапазон баллов помогает расставить приоритеты, а условия допуска определяют, можно ли начинать пробный запуск на реальных данных. Указанные периоды нужны для планирования: наступление даты само по себе ничего не разрешает. Если исправление занимает больше времени, пилот ждёт.

0-11: подготовьте базовые условия

Первое действие: выберите одну задачу и назначьте ответственного. Если вы не можете описать входные данные, результат и того, кто за него отвечает, покупка ещё одного инструмента ясности не добавит.

В дни 1-30 соберите примеры, опишите текущий процесс и выясните, где хранятся данные. Проверьте имеющееся ПО и запишите основные правила. Если исходная задача зависит от данных, которые вам нельзя использовать, выберите менее рискованную задачу.

В дни 31-60 приведите в порядок небольшую репрезентативную выборку, проверьте доступ и потренируйтесь на синтетических примерах в одобренной среде. У участников должен быть рабочий ручной процесс, к которому можно вернуться. Цель — получить подтверждения по открытым вопросам, а не провести эффектную демонстрацию.

В дни 61-90 повторно оцените ту же задачу. Начинайте пилот с чёткими границами на реальных данных, только когда достигнете хотя бы среднего диапазона и выполните все условия допуска. Если задача по-прежнему не подходит, завершить квартал документированным решением подождать — тоже полезный результат.

12-21: подготовьте пилот с чёткими границами

Первое действие: назначьте ответственного и срок для каждого невыполненного условия допуска. Затем займитесь самым слабым направлением, вместо того чтобы совершенствовать самое сильное.

В дни 1-30 доведите до конца эти меры защиты, определите приемлемый результат и зафиксируйте исходные показатели ручного процесса. Это показатели работы до пробного запуска, включая время на проверку и исправления. Политику допустимого использования ИИ можно взять за основу письменных правил; адаптируйте её к конкретной задаче и входным данным.

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

В дни 61-90 решите, продолжать пилот, изменить его или остановить. Повторяйте оценку при смене задачи, источника данных, инструмента или объёма прав доступа. Прогресс — это меньше нерешённых проблем и больше подтверждений, а не просто больше пользователей.

22-30: проведите пилот с измерением результатов

Первое действие: проверьте условия допуска и направление с наименьшим баллом. Высокий общий балл позволяет провести контролируемый пилот, но не оправдывает автоматическую отправку, неограниченный доступ или внедрение во всей компании.

В дни 1-30 согласуйте критерии приёмки и начните небольшой пилот, если условия допуска выполнены и участники умеют выполнять задачу. Проверяющий должен отвечать за каждый результат, который используется в работе. На этом этапе проверяется польза всего процесса, включая затраты человеческого труда вокруг ИИ.

В дни 31-60 разбирайте результаты еженедельно. Прежде чем увеличивать число пользователей, расширьте набор примеров. Система, которая справляется с обычными заметками, может ошибиться при неоднозначном обновлении статуса, нехватке исходных материалов или изменившемся указании клиента.

В дни 61-90 расширяйте пилот только в том случае, если процесс соответствует письменным критериям в течение двух последовательных периодов оценки, все условия допуска выполнены и каждое направление набрало хотя бы 3/6. Это предлагаемое правило работы для небольшого пилота, а не статистическое доказательство надёжности. Если проверка занимает столько же времени, сколько выполнение задачи вручную, упростите задачу или остановитесь.

Полный разбор: компания из 40 сотрудников в сфере услуг

Вымышленная компания из 40 сотрудников, работающая в сфере услуг, набирает 18/30. Её первый шаг — доработать условия для пилота. Использовать реальные данные проектов она пока не готова.

Предлагаемая задача — составлять черновик внутреннего отчёта по проекту на основе согласованных проектных заметок. Руководитель проекта проверял бы каждое фактическое утверждение и отправлял итоговое сообщение. В рамках пилота не было бы автоматической отправки сообщений, изменения записей или принятия обязательств перед клиентами.

Подтверждения и баллы ниже приведены для иллюстрации. Это не результаты работы с клиентом, не тест продукта и не утверждение, что какой-либо конкретный ассистент способен выполнить задачу.

Баллы по направлениям: задача — 4/6, данные — 4/6, инструменты — 4/6, люди — 3/6, риски — 3/6. Расчёт: 4 + 4 + 4 + 3 + 3 = 18/30. Из обязательных условий допуска выполнено только B2.

Решение операционного директора: готовить пилот, но не использовать реальные данные проектов, пока не выполнены остальные условия допуска. Администратор проверяет B3 и C2. Руководитель проекта демонстрирует навык по D2. Операционный директор разъясняет письменные ограничения по E1 и вместе с участниками отрабатывает согласование, сообщение об инциденте, остановку и возврат к ручному процессу по E3.

Если оценка по каждому из этих пяти пунктов поднимется с 1 до 2, общий балл станет 23/30. Но новый итог не закрывает D3: пользователям всё ещё нужна практика. Когда они отработают процесс и оценка D3 вырастет с 0 до 2, сумма составит 25/30, а оценки по направлениям — 4, 5, 5, 6 и 5. В этой гипотетической последовательности все условия допуска теперь выполнены.

До первого черновика на реальных данных компании нужно завершить сбор исходных показателей, подготовить примеры для приёмки и провести проверку C3 — от входных данных до результата. Повышать соответствующие баллы можно лишь при наличии подтверждений. Если инструмент не поддерживает предлагаемый процесс, выберите другую задачу. Доказательств экономии времени у компании пока нет: её предстоит измерить с учётом времени на проверку и исправление черновика.

Как провести оценку за рабочую неделю

Задача недели — прийти к документированному решению, а не пообещать законченное внедрение. Для этого нужно собрать подтверждения у людей, которые уже знают эту работу.

1. 1

   Понедельник: выберите задачу и соберите примеры

   Владелец бизнеса или операционный директор определяет задачу, назначает ответственного и формулирует решение, которое нужно принять к пятнице. Попросите исполнителя предоставить десять недавних примеров, включая сложные случаи. Запишите частоту, затраченное время и типичные исправления. Это удобная стартовая выборка, а не доказательство того, что учтены все исключения.

2. 2

   Вторник: проверьте данные и фактический доступ

   Руководитель ИТ и владелец данных изучают пять репрезентативных исходных документов. Подтвердите разрешение на предлагаемое использование и проверьте доступ из аккаунта обычного участника пилота. Ищите устаревшие версии, смешение документов разных клиентов, персональные данные и материалы с ограничениями на использование. Само наличие папки ещё не означает, что её можно подключать.

3. 3

   Среда: составьте список инструментов и выясните, как ими пользуются

   Проверьте действующие подписки компании, точные типы аккаунтов и права на их администрирование. Узнайте у сотрудников, какими ассистентами, расширениями браузера и инструментами для встреч они уже пользуются в работе. Это сбор фактов: по одним счетам за подписки скрытое использование не выявить. Руководство по теневому ИИ — использованию ИИ в работе вне утверждённого контроля — поможет выстроить этот разговор.

4. 4

   Четверг: отработайте навыки и правила на практике

   Выделите час, чтобы будущие пользователи и проверяющий потренировались на синтетических материалах в одобренной среде. Сравните черновик с источником, отклоните неподтверждённое утверждение, сообщите о проблеме и вернитесь к ручному процессу. Оценивайте продемонстрированные действия: одно присутствие на занятии баллов не приносит.

5. 5

   Пятница: подведите итоги и назначьте ответственных за исправления

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

Какие инструменты нужны для оценки готовности к ИИ?

Для первого решения достаточно документа и электронной таблицы. Храните рядом идентификатор вопроса, балл, ссылку на подтверждение и следующее действие. Проверяемое объяснение каждого ответа важнее сложной панели показателей.

В разделе «Уже оплаченные инструменты» оценивайте подтверждённую пригодность, а не количество подписок. Функция, включённая в тариф, может быть недоступна нужным сотрудникам, отключена администратором или непригодна для этих данных. Проверьте конкретный аккаунт и рабочий процесс, прежде чем планировать ещё одну покупку.

Обратитесь к подборке ИИ-инструментов для малого бизнеса, когда задача и ограничения уже ясны. Если среди кандидатов есть Claude от Anthropic, в руководстве по рабочим процессам с Claude для малого бизнеса найдутся идеи для оценки. Ни одна из ссылок не заменяет проверку вашего аккаунта, прав доступа и нужного результата.

Как связать оценку готовности с управлением ИИ

Открытые методики помогают подробнее проработать меры контроля после выявления пробелов. AI Risk Management Framework, или NIST AI RMF, разработанная Национальным институтом стандартов и технологий, содержит добровольные рекомендации по управлению рисками ИИ. Её Playbook группирует предлагаемые действия по разделам Govern, Map, Measure и Manage и прямо указывает, что не является чек-листом, который нужно выполнить целиком. Используйте её, чтобы глубже разобрать ответственность, контекст, оценку и меры реагирования. ISO/IEC 42001 устанавливает требования к созданию и постоянному совершенствованию системы менеджмента ИИ — политик, обязанностей и процессов организации, связанных с ИИ. Стандарт полезен, когда нужна такая формальная организационная структура. Эти открытые страницы были проверены 23 октября 2026. Наш чек-лист — авторский инструмент планирования, а не оценка NIST, не оценка соответствия ISO и не подтверждение сертификации. Система управления ИИ для небольшой компании поможет превратить выводы в конкретные обязанности и правила принятия решений.

Чего не стоит ждать от оценки готовности к ИИ?

За точным на вид баллом может скрываться расплывчатый ответ. Оценка 18/30, подкреплённая фактами, полезнее уверенных 28/30 на основе догадок. Диапазоны помогают организовать работу, но не измеряют универсальное свойство компании. Не переводите общий балл в проценты, чтобы объявить бизнес «готовым на столько-то процентов».

Новые инструменты не прояснят плохо описанную задачу. Если нет согласованного определения хорошего результата, оценивать задачу будет трудно и после покупки новой подписки. То же относится к противоречивым исходным материалам. Иногда первое полезное изменение — единая форма сбора входных данных или более понятный порядок согласования.

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

Баллы не дают разрешения на автономную работу. Переход от «подготовить черновик для человека» к «отправить без согласования» меняет процесс и его последствия. Проведите оценку заново. То же касается доступа того же ассистента к файлам другого отдела. Даже 30/30 не позволяют считать новое разрешение или новый сценарий подтверждёнными на основании проверок, которые к ним не относились.

Частые вопросы

Что такое оценка готовности к ИИ?

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

Как получить чек-лист оценки готовности к ИИ в PDF?

Скопируйте одностраничный чек-лист в текстовый редактор и экспортируйте или распечатайте его в PDF. Подтверждающие заметки храните отдельно, а для повторной оценки сохраните редактируемую копию. Все вопросы и правила подсчёта есть на этой странице: заполнять отдельную форму оценки или отправлять адрес электронной почты не нужно.

С чего начать в понедельник

Назначьте встречу для оценки с ответственным за одну повторяющуюся задачу и тем, кто администрирует её данные и инструменты. Заранее попросите недавние примеры. К пятнице закончите фразу: «Мы можем опробовать этот рабочий процесс с такими ограничениями, когда устраним вот эти конкретные пробелы». Если закончить её не получается, следующим действием должен стать сбор недостающих подтверждений.

Практические руководства по выбору и организации рабочих процессов с ИИ — в нашей рассылке. Подпишитесь.