Сотрудники сами пишут программы с AI. Это экономия или новый бардак?

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

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

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

Почему сотрудники часто находят лучшие задачи для автоматизации

Человек внутри процесса видит мелочи, до которых не доходит ИТ-отдел. Он знает, что каждое утро надо открыть письмо, скопировать артикулы, убрать пробелы, сверить остатки и только потом ответить клиенту. Для директора это «обработка заказа», для сотрудника — двадцать конкретных действий.

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

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

Где проходит граница личного инструмента

Я бы смотрела не на технологию и не на должность автора, а на последствия ошибки.

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

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

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

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

Успешные компании не просто разрешают всем писать всё

Хороший пример даёт производитель автокомпонентов ZF. Компания открыла Microsoft Power Platform сотрудникам и к 2024 году получила больше 25 000 приложений и 37 000 активных пользователей. Впечатляет не только количество, а устройство контроля.

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

Даже внутри одной компании подход различается: личная автоматизация не проходит тот же путь, что приложение для 140 заводов и 5 000 работников.

Кейс опубликован Microsoft, поэтому он показывает успешного клиента платформы и не является независимым исследованием. Но принцип не зависит от продукта: свобода для малых задач, ворота контроля при росте риска.

Shell: четыре тысячи разработчиков из бизнеса и центр компетенций

В Shell программа самостоятельной разработки выросла до более чем 4 000 активных участников. Сотрудники сделали, например, приложение для согласования подъёмных работ на строительной площадке. По данным компании, процесс сократился примерно с 2,5 часа до одного.

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

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

Deutsche Bahn: разработка рядом с пользователем

В Deutsche Bahn самостоятельные разработчики цифровизировали локальные операции, которым было трудно попасть в очередь центральной разработки. Компания создала сеть сообществ и центр компетенций, чтобы решения можно было повторно использовать и сопровождать.

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

Какие проблемы появляются без контроля

Данные уходят неизвестно куда

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

Расчёт выглядит убедительно, но ошибается

Нейросеть пишет формулу и интерфейс одновременно. Красивый результат создаёт больше доверия, чем заслуживает. Если нет эталонных примеров, ошибку находят уже в отчёте руководителя.

Пароль знает весь отдел

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

Нельзя восстановить данные

Приложение работает на ноутбуке автора. Резервной копии нет, история изменений отсутствует, обновление библиотеки ломает запуск.

Возникают десятки дублей

Три отдела решают одну задачу тремя несовместимыми способами. Компания платит за одинаковые интеграции и получает три версии справочника.

У программы нет хозяина

Автор создал инструмент из интереса, но не обязан поддерживать его в отпуске и после перехода в другую компанию.

Семь вопросов перед тем, как дать программу коллегам

1. Что произойдёт при ошибке? Потеряем десять минут, отправим неверный счёт или остановим отгрузку?
2. Какие данные использует программа? Есть ли персональные, финансовые, коммерческие сведения и куда они передаются?
3. Кто владелец? Один человек отвечает за правила, доступы и решение о дальнейшей работе.
4. Как проверен результат? Нужны обычные, граничные и заведомо ошибочные примеры.
5. Где хранятся код, настройки и данные? Компания должна иметь доступ независимо от автора.
6. Как восстановиться? Нужны резервная копия и понятный ручной путь хотя бы на время сбоя.
7. Когда нужен ИТ-специалист? Порог определяют заранее: число пользователей, критичные данные, интеграция или влияние на деньги.

Минимальный реестр вместо большого комитета

Малому бизнесу не нужен департамент из двадцати человек. Достаточно простой таблицы:

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

Что можно разрешить сразу

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

А перед общим запуском проверить доступы, данные, расчёты, резервирование и владельца.

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

Экономия или новый бардак?

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

Разрешение без правил создаст коллекцию программ, на которые никто не решается опереться и которые некому чинить.

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

Источники и ограничения

• Microsoft, кейс ZF Group — данные клиента опубликованы поставщиком Power Platform; ценны детали модели управления.
• Microsoft, кейс Shell — платформенный кейс с показателями, сообщёнными Shell.
• Microsoft Learn, кейс Deutsche Bahn — описание программы самостоятельной разработки со стороны поставщика технологии.
• NIST AI Risk Management Framework — добровольная рамка управления рисками; конкретные меры надо соотносить с масштабом и законодательством компании.