Сотрудник видит повторяющуюся задачу, описывает её ИИ и получает небольшое приложение: сверку выгрузок, форму для заявки, отчёт или инструмент подготовки документов. Это уже другой уровень самостоятельности по сравнению с просьбой «напиши мне письмо».

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

Это первая статья серии об офисной разработке с ИИ. Здесь разберём навыки и организацию работы. Вторая посвящена безопасности, третья — историческому кейсу NC3A и архитектуре сервисов для людей и агентов. Источники проверены 1 ноября 2026 года.

Что действительно прогнозирует Gartner

Gartner прогнозирует: к 2027 году 75% сотрудников будут приобретать, изменять или создавать технологии вне видимости ИТ, по сравнению с 41% в 2022 году. Это прогноз широкого технологического поведения. Покупка сервиса, настройка инструмента и разработка программы входят в одну формулировку; считать её долей программистов нельзя. Gartner: The CISO for Digital Business — employee technology forecast ↗

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

Исследовательская записка МОТ от 17 апреля 2026 года отдельно объясняет: показатели потенциальной подверженности ИИ не являются прогнозом потери рабочих мест. Они описывают возможности изменения задач, не учитывая всех условий внедрения и экономических последствий. ILO: Workers’ exposure to AI — what indicators tell us and what they don’t, April 17, 2026 ↗

Практический вывод для компании — заранее развивать навыки и правила самостоятельной автоматизации. Дата 2027 в аналитическом прогнозе не должна превращаться в искусственный срок увольнения.

Как меняется полезный офисный навык

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

Самостоятельная разработка пользователями — citizen development — выросла из давно знакомой практики макросов, таблиц и настроек корпоративных платформ. Генеративный ИИ добавляет к ней возможность описывать поведение программы обычным языком и получать заготовку кода или интерфейса.

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

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

Шесть умений, которые стоит развивать

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

Предлагаемая матрица обучения. Это критерии проверяемой работы, а не всеобщий кадровый стандарт.
НавыкЧто освоитьКак показать результат
Постановка задачиОписать вход, результат и границыСформулировать условие приёмки на одном примере
Понимание данныхРазличать идентификаторы, статусы и версииОбъяснить, какие строки можно объединять
Правила и исключенияЗадать действия при пропусках и противоречияхПоказать случаи, когда программа обязана спросить
Проверка результатаСравнивать с эталоном и сохранять проверкиПовторить проверку после изменения инструмента
Данные и полномочияРазделять чтение, изменение и передачуПеречислить разрешённые файлы, операции и получателей
Передача и сопровождениеСохранять версию, владельца и описаниеПередать запуск коллеге и показать возврат к ручному процессу

Например, сотрудник хорошо знает, что в одной выгрузке «отгружено» означает передачу перевозчику, а в другой — получение клиентом. Без этого различия приложение может красиво свести несовместимые статусы. Умение сформулировать правило здесь важнее уверенности, с которой ИИ написал код.

Или программа находит строку с пустой датой и молча исключает её из отчёта. Пользователь должен заметить, что система приняла содержательное решение без согласованного правила. Хорошая постановка задачи требует показать такие строки отдельно и объяснить, почему итог пока неполон.

Один рабочий пример: сводка из нескольких выгрузок

Представим вымышленный пилот. Менеджер каждую неделю собирает сводку по заказам из нескольких CSV. Он хочет получать список расхождений и черновой отчёт. На первом этапе программа работает только с подготовленными копиями файлов и ничего не меняет в источниках.

Сотрудник описывает назначение столбцов, идентификатор заказа, правила обработки возвратов и смысл статусов. Вместе со специалистом по данным определяет, когда записи можно объединять. Затем ИИ помогает сделать форму загрузки и алгоритм сверки.

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

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

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

Как отделить полезный инструмент от бесконечной игрушки

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

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

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

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

Что руководителю стоит изменить в организации работы

Вместо требования «каждый должен что-нибудь написать с ИИ» полезнее собрать повторяющиеся неудобства. Где сотрудники копируют одни данные несколько раз? Какие отчёты отличаются только представлением? Какие проверки постоянно забываются? По таким задачам проще установить пользу.

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

Документация Microsoft по развитию Power Platform тоже разделяет роли создателей, администраторов, владельцев платформы, специалистов по безопасности и поддержке. Самостоятельность пользователей сочетается с ответственностью и управлением. Это пример устройства конкретной платформы, не обязательный выбор продукта для AI Office. Microsoft: Power Platform adoption roles and responsibilities ↗

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

Почему компания продолжит покупать софт и оплачивать сопровождение

Токены — только одна статья затрат. Остаются источники данных, доступы, хостинг, интеграции, резервные копии, лицензии и поддержка. Часть задач выгоднее решать настройкой существующего продукта. Для другой части оправдана индивидуальная разработка.

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

Microsoft описывает жизненный цикл low-code-приложения через требования, разработку, тестирование, развёртывание, эксплуатацию и управление изменениями. Низкий порог создания не отменяет эти этапы. Microsoft: Application lifecycle management with Power Platform ↗

Крупные сокращения тоже не являются единственной стратегией. В сентябрьском материале 2026 года Gartner предупреждает о рисках слишком раннего и глубокого сокращения персонала ради экономии и рекомендует развивать навыки и сохранять организационные знания. Это позиция аналитиков, а не обещание отсутствия увольнений. Gartner: Four shifts shaping the future of work, September 9, 2026 ↗

Где здесь место AI Office

AI Office помогает строить проверяемые процессы вокруг данных компании. В прототипе есть поиск по документам с учётом прав и ссылками на источники, подготовка КП с программным расчётом сумм, утверждение конкретной версии и локальные поручения. Совет аналитиков рассматривает вопрос через несколько ролей одной модели.

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

Мы не предлагаем давать каждой новой программе доступ ко всем документам, учётной системе и корпоративной почте. Готовых коннекторов к этим внешним системам в прототипе также нет. Развитие self-service-сценариев требует отдельного проектирования и проверки.

Как начать подготовку к 2027 году

Первый шаг — выбрать повторяемую задачу и описать её человеческим языком. Второй — подготовить обезличенные или вымышленные примеры с известным результатом. Третий — сделать небольшой инструмент и проверить его на исключениях. Четвёртый — определить владельца, права и условия использования в реальной работе.

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

Сильный результат — сотрудник умеет объяснить работу своего инструмента, показать проверку и признать границы. Такой навык полезен независимо от того, будет ли завтра компания менять штатное расписание. Обещание гарантированных увольнений для всех остальных из имеющихся источников не следует.

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