Сотрудник открывает личный аккаунт в LLM, потому что ответ нужен сегодня. Служба информационной безопасности закрывает внешний ИИ-сервис, потому что не знает, какие данные туда попадут. Руководитель показывает на совещании несколько ИИ-пилотов и считает, что внедрение началось.
Каждое действие по отдельности выглядит разумно. Вместе они создают порядок, которого никто не ожидал: инструменты выбирают сами сотрудники, безопасность держится на запретах, внедрение ИИ ограничивается пилотами, обучение остается личным делом.
По данным исследования российских экспертов, 71% опрошенных компаний применяли генеративный ИИ хотя бы в одной функции, 46% внедрили или тестировали агентов. Другое российское исследование показывает ту же ситуацию со стороны работников. ИИ использовали 88% из 798 респондентов, об официальных инструментах и правилах сообщили 24%, через личные аккаунты рабочие задачи хотя бы иногда решали 58% пользователей.
Эти исследования проведены на разных выборках, поэтому их цифры нельзя складывать в одну оценку ситуации. Но вместе они описывают общий разрыв: применение ИИ распространяется быстрее, чем общий порядок работы с ним.
Мы предлагаем посмотреть на этот разрыв через модель организационной культуры Эдгара Шейна. Статья адресована руководителям бизнеса и функций, HR, ИТ, информационной безопасности и командам трансформации. Ее задача — показать, почему наличие моделей и пилотов еще не создает организационной способности, и предложить порядок перехода к устойчивой практике.
Мы разберем четыре аспекта внедрения ИИ в компании: выбор инструментов, безопасность, приемку результатов работы ИИ и роль сотрудника. Каждый из аспектов разложим на артефакты, декларируемые ценности и базовые предположения. Затем соберем четыре культурных разрыва в целевую модель и перейдем к конкретным действиям.
Как читать внедрение ИИ через модель Шейна
Шейн описывал культуру как результат коллективного обучения. Группа находит способ решить задачу, повторяет его, получает приемлемый результат и со временем перестает обсуждать сам способ. Он становится обычным порядком работы.
В модели Шейна три уровня.
Разрыв возникает, когда три уровня указывают в разные стороны. Компания говорит о производительности, сотрудник работает через личный ИИ-аккаунт, служба безопасности узнает об этом после инцидента. Или компания говорит о развитии людей, одновременно ожидая, что новый навык сотрудники освоят по вечерам.
Ниже мы моделируем четыре типичных разрыва, относящихся к четырем аспектам внедрения ИИ, упомянутым выше. Как мы говорили, базовые предположения не могут наблюдаться непосредственно – и они не могут быть выявлены по одной публикации или опросу. В конкретной компании их следует сопоставить с интервью, наблюдением и различными артефактами, такими как журналы доступа, сроки согласований, данные об обучении, решения руководителей.
Первый вопрос — кто фактически организует применение ИИ: компания или отдельный сотрудник?
Что мы наблюдаем
В приведенном выше исследовании 36% пользователей регулярно решали рабочие задачи через личные аккаунты, еще 22% делали это время от времени. При отсутствии централизованного внедрения регулярно использовали личные аккаунты 55% пользователей, при его наличии — 27%. Это сравнение не устанавливает причинность. Но оно показывает, что организационная среда связана с выбором рабочего инструмента.
Публичная позиция одной из крупнейших продуктовых розничных компаний России дает пример конкретной корпоративной декларации. Ее управляющий директор летом 2026 года заявил о намерении сделать ИИ частью операционной модели компании. В том же сообщении компания называет наблюдаемые артефакты: корпоративным CoPilot воспользовались более 32 тыс. сотрудников, 21 тыс. применяли его регулярно, сотрудники создали свыше 2,3 тыс. ИИ-агентов.
Здесь декларация и артефакты поддерживают друг друга. ИИ назван частью операционной модели, компания дает единый интерфейс, инфраструктуру и возможность создавать рабочие сценарии.
Разрыв по Шейну
В других организациях артефакты могут выглядеть иначе: личные подписки, проекты отдельных команд, длинное ожидание доступа, неизвестный статус официальной модели, обмен удачными промптами в частных чатах.
Из повторяющегося выбора личного сервиса можно вывести гипотезу о базовом предположении сотрудника: «У меня горит срок. Ждать корпоративный инструмент некогда». За формальной выдачей доступа может стоять предположение руководства: «Инструмент дали. Дальше все будет хорошо, команды разберутся».
Культурный разрыв возникает, когда ИИ объявлен общей инициативой, а рабочий способ остается личной находкой. Компания получает отдельные быстрые результаты, но не нарабатывает общий метод. История запросов, проверенные сценарии и знание ограничений остаются у отдельных людей. И нет гарантий, что эти сценарии соответствуют ожиданиям компании.
Что требуется изменить
Компаниям следует отвечать за допустимый рабочий путь. Официальный инструмент должен решать частые задачи с приемлемым качеством, доступ к нему должен появляться до того, как сотрудник найдет обходной маршрут. Личные находки нужно превращать в общую библиотеку сценариев с понятными владельцами и правилами проверки.
Признак изменения виден в артефактах: сокращается использование личных аккаунтов, растет число повторно используемых сценариев, сотрудник знает, куда принести задачу, которую официальный инструмент пока не решает.
Когда компания не организует выбор инструмента, вопрос удобства быстро становится вызовом информационной безопасности.
Второй вопрос — создает ли запрет безопасную практику, если у сотрудника нет допустимого способа выполнить задачу?
Что мы наблюдаем
По исследованию УЦСБ и ГК «Солар», 8,1% из 102 организаций сообщили об утечках через ИИ, 42,4% подозревали такие случаи, треть не применяла специальных мер. Обучение и внутренние политики безопасности назвали неудовлетворенной потребностью 63,6% участников.
В моем опросе о запрете внешних LLM участвовали 59 человека. Вариант «использование просто уходит в тень» выбрали 54%, зависимость от данных и рабочих задач — 23%, необходимость внутренней альтернативы — 25%. Вариант «запрет снижает риск» отметили 25%.
Ответы показывают декларируемые суждения аудитории. Они не доказывают, что сотрудники будут обходить запрет. Они позволяют сформулировать гипотезу: значительная часть ответивших связывает безопасность с доступностью разрешенного маршрута и характером задачи.
Конкретную корпоративную декларацию ответственного ИИ дает «Яндекс». Компания публикует принципы разработки и использования ИИ. В 2026 году она сообщила, что процессы создания и внедрения моделей Alice AI прошли аудит на соответствие ISO/IEC 42001. В сообщении перечислены артефакты: обучение сотрудников, оценка этических, юридических и социальных рисков, мониторинг ошибок и аномалий, контроль жизненного цикла модели.
Этот пример важен по двум причинам. Заявление об ответственном ИИ связано с конкретными процедурами. Безопасность описана как работа на всем жизненном цикле модели.
Разрыв по Шейну
Типичные артефакты безопасности — закрытые модели, списки разрешенных сервисов, DLP-системы предотвращения утечек, ручные согласования и журналы действий. Декларируемые ценности — конфиденциальность, управляемость и ответственность.
За этими артефактами может стоять базовое предположение функции безопасности: «Модель внутри периметра — значит, риск под контролем». У сотрудника может сложиться другое правило: «Если официальный путь мешает сделать работу, придется найти другой».
Разрыв возникает, когда безопасность измеряют отсутствием зафиксированных инцидентов, а время согласования и теневое использование остаются в показателях других подразделений. Запрет уменьшает видимость практики. Риск при этом может перейти в личные аккаунты, скриншоты, ручное копирование и неконтролируемые локальные решения.
Эту гипотезу можно проверить по обращениям за доступом, DLP-событиям, использованию личных аккаунтов, срокам согласования и числу задач, для которых разрешенного решения еще нет.
Что требуется изменить
Безопасность должна описывать сценарий целиком: какие данные используются, какой инструмент разрешен, что может делать агент, кто проверяет результат, когда система передает задачу человеку и при каких условиях ее останавливают, и даже удобство получения разрешения для новых кейсов во избежание формирования «теневых» каналов работы с LLM.
Кодекс Банка России дает полезную рамку: учет моделей, уровни риска, мониторинг, конфиденциальность, контроль качества и непрерывность деятельности. Ее можно перевести в правила конкретных процессов.
Службе безопасности нужен дополнительный показатель — срок ввода в действие нового запрашиваемого функционала. Тогда функция отвечает одновременно за ограничение риска и за возможность выполнить новую задачу в рамках установленных правил.
Безопасное использование модели решает только часть проблемы. Оно еще не говорит, в какой момент сгенерированную работу можно принять.
Третий вопрос — в какой момент сгенерированный материал становится результатом, за который организация готова отвечать?
Гипотеза этой главы проста: ИИ снижает стоимость генерации, но переносит значительную часть работы в проверку, согласование и доказательство достоверности. Выигрыш зависит от того, сколько стоит принять результат с допустимым уровнем риска.
Что мы наблюдаем
Представим типичную ситуацию: PESTEL-анализ экономической ситуации компании сгенерирован с помощью ИИ за одну-две минуты. Но попытка полностью проверить утверждения может занять намного больше времени, поскольку не сможет быть реализована как надежный автоматический процесс. Дополнительная модель-проверяющий будет создавать новые запросы, искать источники и добавлять возможные расхождения, которые снова потребуют разбора.
Этот пример показывает механизм переноса затрат: черновик появляется быстро, проверка требует источников, сопоставления данных и профессионального суждения.
Связь с устойчивым результатом здесь прямая. Пилот может показать, что ИИ-модель способна выдать подходящий ответ. Но продуктивное использование модели требует данных приемлемого качества, специалистов для постановки задачи и проверки, времени и бюджета на отладку процесса и дальнейшее его поддержание. Перечисленные барьеры описывают ресурсы, которых часто не хватает между успешной демонстрацией и повторяемым результатом.
X5 показывает, как выглядит другой набор артефактов. Компания сообщает, что эффект ИИ-инициатив оценивается через вклад в EBITDA, экономию затрат и совокупную стоимость владения; для ключевых решений применяются A/B-тесты и финансовые модели. Здесь декларация об экономическом эффекте связана с процедурой проверки.
В моем опросе о готовности результата участвовали 63 человека. Проверку исполнителем выбрали 87%, достаточность достойно выглядящего результата — 11%, полный отказ считать такую работу выполненной — 4%.
За самым частым ответом читается базовое предположение: «Модель может подготовить материал. Принимать его и отвечать за него должен человек».
В обсуждении опроса появилось еще одно условие: достойного результата может быть достаточно, если LLM настроена на стандарты компании. Такая настройка помогает выдерживать форму, терминологию и критерии приемки. Полнота исходных данных, достоверность фактов и применимость стандарта к конкретному случаю остаются отдельными вопросами. Для типовой задачи с низкой ценой ошибки корпоративного стандарта может быть достаточно. При высокой цене ошибки понадобится дополнительная проверка.
Разрыв по Шейну
Артефакты многих пилотов — число пользователей, количество созданных документов, время ответа и красивое демо. Часы экспертов, повторные проверки, исправления и согласования распределены по календарям и редко попадают в расчет.
Декларируемые ценности связаны со скоростью, качеством и снижением затрат. Возможные базовые предположения звучат живее: «Демо работает — можно запускать»; «черновик готов за минуту — мы сэкономили день»; «эксперт потом быстро посмотрит».
Разрыв возникает между производством ответа и производством доверия. Компания считает то, что модель создала, и почти не видит работу, после которой результат становится пригодным для решения.
Что требуется изменить
Предлагается оценивать полную стоимость доверенного результата (Total Cost of Trustworthy Outcome):
Для каждой задачи до запуска нужно определить критерии приемки. Если результат можно автоматически сравнить с эталоном или покрыть тестами, проверка будет короткой. Для стратегии, экспертного текста или консультационного вывода проверяющему может потребоваться сопоставимая профессиональная работа.
Проектировать следует весь путь результата: источники, тесты, журнал действий, границы стандарта, ручную приемку и ответственного за последствия. Метрика пилота должна включать стоимость проверки. Решение о масштабировании пилота должно иметь дату и три допустимых исхода: продолжить, изменить или закрыть данную тематику.
Когда приемка становится отдельной частью процесса, меняется и роль сотрудника. Его вклад все чаще находится в постановке задачи, проверке и ответственности за применение результата.
Четвертый вопрос — кто должен создать новую квалификацию: сотрудник, руководитель или компания?
Что мы наблюдаем
Согласно совместному исследованию HeadHunter и Touch Instinct, 60% работодателей ожидают от сотрудников базовых ИИ-навыков. По опросу Русской школы управления, обучение работе с ИИ планировали 33% компаний.
Цифры измеряют разные группы, поэтому прямое сравнение ограничено. Они описывают напряжение между растущим требованием и доступностью организованного обучения.
В опросе Level Group и HeadHunter, внедрение ИИ поддержали 73% респондентов. Из них примерно для половины (38,5% от общего числа) поддержка зависела от сохранения рабочих мест, 12% опасались замещения.
В моем опросе об ответственности за освоение ИИ участвовали 72 человека. Совместную ответственность сотрудника и компании выбрали 63%, ответственность компании — 25%, руководителя команды — 23%. Только на сотрудника ее возложили 6% ответивших.
Это декларируемая позиция аудитории. Она помогает сформулировать ожидание взаимности: сотрудник осваивает новый способ работы, компания дает инструмент, правила и время, руководитель связывает обучение с реальными задачами команды.
Публичная позиция «Северстали» показывает, как может звучать корпоративная декларация роли человека. На странице о нейросетях компания пишет: «Без человека, его знаний и опыта эффективного продукта не получится». Там же назван артефакт этой позиции: ИИ-решения разрабатываются совместно с технологами, дефектоскопистами и экспертами по качеству.
Разрыв по Шейну
Артефакты этого уровня — требования в вакансиях, самостоятельные курсы, корпоративные программы, автоматизация отдельных задач, новые показатели и решения о численности. Декларируемые ценности — развитие людей, освобождение времени и повышение качества работы.
В реальной ситуации у сотрудника могут сложиться другие базовые предположения: «Разбираться придется самому»; «Если покажу, сколько за меня делает ИИ, компания решит, что без меня можно обойтись».
У компании может работать встречное правило: «Освоение нового инструмента входит в личную ответственность профессионала».
Разрыв возникает, когда организация требует новый навык, но не дает времени на обучение, критериев квалификации и понятного описания будущей роли. Сотрудник получает стимул скрывать практику или осваивать ее фрагментарно. Обучение может восприниматься как подготовка к собственному сокращению.
Что требуется изменить
Ответственность следует разделить.
Компания дает пригодный инструмент, правила, рабочее время и описание того, какие задачи меняются. Руководитель выбирает реальные сценарии для обучения, дает обратную связь и меняет критерии результата. Сотрудник осваивает применение ИИ, понимает ограничения и отвечает за качество своей работы.
Новая квалификация включает постановку задачи, выбор источников, проверку, работу с исключениями и ответственность за последствия. Ее признаки должны появиться в профилях ролей, обучении, оценке и карьерных переходах.
Переход к согласованной культуре ИИ
Мы получили четыре культурных разрыва.
Четыре главы, анализирующие культурные разрывы, показывают общий механизм: инструменты уже вошли в работу, привычный порядок принятия решений сохранился. Теперь разрывы можно собрать в целевую модель культуры.
Переведем эти разрывы в новые базовые предположения, которые требуется закрепить через повторяющийся опыт.
Второй и третий столбцы — гипотезы для проверки внутри компании. Четвертый столбец описывает новый негласный договор. Последний столбец нужен для контроля: если новые слова не подтверждены артефактами, культура осталась прежней.
Протокол перехода
Культура меняется через повторяющийся опыт. Поэтому каждый пункт ниже включает владельца, первый шаг и наблюдаемый признак изменения.
Владелец: ИТ совместно с руководителями функций и информационной безопасностью.
Первый шаг: выбрать пять-десять частых сценариев и проверить, может ли официальный инструмент выполнить их с приемлемым качеством, стоимостью и сроком доступа.
Признак изменения: сокращается использование личных аккаунтов, растет библиотека повторно используемых сценариев, новые запросы попадают в понятный маршрут развития инструмента.
Основание: данные исследования о личных аккаунтах, результаты опроса о запретах, корпоративный CoPilot и единая ИИ-инфраструктура одной из крупнейших продуктовых розничных компаний России.
Владелец: информационная безопасность, юридическая функция и владелец процесса.
Первый шаг: разделить задачи по данным, цене ошибки и допустимой автономности. Для каждого класса определить инструмент, права, проверку и условия остановки.
Признак изменения: сотрудник знает допустимый путь, действия агента журналируются, отклонения передаются человеку, срок согласования измеряется.
Основание: исследование УЦСБ и «Солара», Кодекс Банка России, практики жизненного цикла и аудита ИИ в «Яндексе».
Владелец: бизнес-руководитель с бюджетом и правом принять решение о продолжении или закрытии.
Первый шаг: до старта зафиксировать исходную метрику, полную стоимость текущей работы, допустимую ошибку, владельца приемки и дату решения.
Признак изменения: у пилота есть сравнение «до» и «после», учтена работа экспертов и стоимость проверки предлагаемых ИИ решений, в назначенную дату гипотеза масштабируется, меняется или закрывается.
Основание: подход одной из крупнейших продуктовых розничных компаний России к A/B-тестам и финансовым моделям, рекомендации «Яндекса» в РБК, чек-лист VK Tech в интервью «Эксперту».
Владелец: владелец процесса вместе с функцией качества или экспертом, который принимает результат.
Первый шаг: составить карту приемки: что проверяется автоматически, что сверяется со стандартом, где нужны источники и профессиональное суждение, кто подписывает итог.
Признак изменения: стоимость проверки видна, критерии приемки воспроизводимы, источники и исправления сохраняются, цена ошибки включена в решение о масштабировании.
Основание: опрос о готовности результата, обсуждение настройки LLM на корпоративные стандарты, Кодекс Банка России и практики проверки эффекта одной из крупнейших продуктовых розничных компаний России.
Владелец: руководитель функции совместно с HR и владельцем проекта автоматизации.
Первый шаг: разложить роль на задачи и для каждой определить один из исходов: ИИ выполняет задачу, помогает сотруднику, меняет порядок работы или не применяется из-за риска.
Признак изменения: сотрудник знает, какие задачи и критерии оценки меняются, какие навыки нужны, какие переходы доступны. Решения о численности не маскируются языком обучения.
Основание: исследования Level Group и HeadHunter, НИУ ВШЭ, позиция «Северстали» о совместной работе ИИ и отраслевых экспертов.
Владелец: HR, руководители команд и информационная безопасность.
Первый шаг: дать общий минимум по конфиденциальности, ограничениям моделей и ответственности, затем провести ролевые практикумы на реальных документах, коде и решениях подразделения.
Признак изменения: обучение проходит в рабочее время, сценарии попадают в должностную практику, сотрудники понимают характерные ошибки и знают, когда обращаться к эксперту.
Основание: исследования HeadHunter и Touch Instinct, Русской школы управления, опрос об ответственности за освоение ИИ и практики корпоративного обучения, описанные в материалах РБК и «Яндекса».
Первый шаг: анализ одного процесса
Для первого шага не нужна программа на всю компанию. Достаточно выбрать один процесс, где ИИ уже используется или проходит пилот.
Распоряжение может изменить формальное правило. Базовое предположение меняется после нескольких ситуаций, в которых новый способ сработал: сотрудник получил пригодный инструмент вовремя, выполнил задачу внутри допустимых границ, понял критерии приемки и увидел свое место в изменившейся работе.
С анализа одного процесса и стоит начать.
