Low-code, гражданская разработка и теневое ИТ: риски, 3 линии контроля и чек-лист для руководителя

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

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

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

Гражданская разработка и теневое ИТ: как это связано в low-code

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

Гражданская разработка — это создание рабочих бизнес-приложений сотрудниками бизнес-подразделений, не занимающими профессиональную роль разработчика, средствами визуального конструктора на low-code платформе. В контексте low code гражданская разработка означает перенос части автоматизации ближе к владельцам процессов.

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

Гражданская разработка описывает не статус инструмента, а роль автора. Сотрудник бизнес-подразделения собирает нужный ему сервис сам, потому что лучше всех понимает предметную область. В low-code-подходе такой сервис может разрабатываться поэтапно: от локального прототипа до решения, прошедшего корпоративное ревью. Такая работа бывает и полностью легальной, и полностью теневой, разница определяется тем, где она выполняется и по каким правилам.

Гражданская разработка на корпоративной low-code-платформе — это преимущество, позволяющее сократить объём теневых ИТ, а не источник новых проблем; проблемой она становится ровно в той мере, в какой платформа поставлена без правил доступа, ревью и учёта созданного.

«Гражданская разработка работает эффективно только при понятных правилах и контроле со стороны ИТ-службы. Теневая активность обычно возникает не из-за low-code, а когда бизнес не может достаточно быстро получить нужные изменения через существующие ИТ-процессы»

Александр Воробьев, Product Owner СЭД ТЕЗИС

Подтверждением важности этого направления служат и оценки рынка, хотя они различаются по методике: данные проекта Staq и прогноз Gartner относятся к разным срезам платформенной автоматизации и low-code.

Кто такой гражданский разработчик и что он реально делает

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

Задачи, которые такие авторы закрывают чаще всего, укладываются в понятный перечень:

• Экранные формы и справочники вместо переписки по почте;
• Маршруты согласования заявок, договоров, служебных запросов;
• Локальные реестры: контрагенты, оборудование, обучение, инвентаризация;
• Внутренние сервисы самообслуживания для коллег;
• BI-системы аналитики для управленческих панелей и отчётов по показателям подразделения;
• Чат-боты для сбора обращений и уведомлений;
• Прототипы гипотез, которые дешевле проверить, чем описывать в требованиях.

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

От бизнес-аналитика он отличается результатом работы. Аналитик формулирует и формализует требования, гражданский автор сразу собирает работающий инструмент. На практике эти роли часто совмещаются в одном человеке, и именно поэтому такому специалисту нужны готовые проверенные блоки и понятные ограничения, а не свободное поле для творчества.

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

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

Корневые причины повторяются от компании к компании:

• Длинная очередь запросов в ИТ, где локальная автоматизация всегда уступает по приоритету крупным проектам;
• Тяжёлые регламенты: описание требований, оценка, согласование бюджета и включение в план занимают больше времени, чем сама сборка;
• Отсутствие легального инструмента, в котором сотрудник имеет право собрать что-то самостоятельно;
• Недоверие к срокам: опыт прошлых обещаний заставляет искать обходной путь заранее;
• Никто не отвечает за автоматизацию мелких локальных операций — задача формально ничья;
• Разрыв в языке: подразделение не может корректно описать потребность, а ИТ-специалист не погружён в предметную специфику.

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

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

Этот вывод подтверждается данными: независимые исследования^[1] фиксируют неизвестные и известные облачные сервисы, прогнозируют дальнейший рост активности сотрудников вне видимости ИТ, а российские данные показывают масштаб рисков для персональных данных. То, что сотрудники признаются^[1] в обходе политик ради рабочих задач, подтверждает: проблема носит структурный характер.

Как выглядит теневое ИТ до и после появления low-code платформы

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

Сравнение двух состояний по ключевым критериям выглядит так:

Разница не в удобстве интерфейса, а в наблюдаемости. В первом состоянии ИТ-руководитель не может ответить, где обрабатываются сведения о клиентах и кандидатах; во втором такой ответ занимает несколько минут.

Спорный взгляд: теневая разработка не всегда вредна

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

«Инициативу бизнеса не стоит автоматически считать угрозой: сотрудники всё равно ищут инструменты для решения своих задач. Low-code позволяет проводить такие эксперименты в среде, где гибкость настроек сочетается с управляемостью и безопасностью»

Сергей Трухин, директор по продажам FIS

Более того, часть таких наработок становится основой для тиражирования. Отдел собрал маршрут согласования под свою специфику, решение прижилось, и центр компетенций переносит его в корпоративный контур уже как проверенный шаблон для моделирования бизнес-процессов. Среда low code хорошо подходит для подобных экспериментов именно потому, что гибкость в ней сочетается со встроенными средствами управления: автор пробует, а система фиксирует, что именно он изменил.

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

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

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

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

Безопасность и утечки данных

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

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

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

На заметку: отдельный риск создают заброшенные наборы информации. Локальная база данных, заведённая «на два месяца» под проект, продолжает существовать без владельца, без обновлений и без резервных копий.

Соответствие требованиям и персональные данные

Согласно 152-ФЗ, персональными данными считается^[2] информация о физическом лице; реестр с фамилиями и телефонами подпадает под требования закона. Передача сведений за рубеж может быть трансграничной^[2]: до её начала оператор обязан уведомить уполномоченный орган. С 1 июля 2025 года базовые операции с персональными данными граждан России, как правило, не допускаются с использованием баз данных за пределами РФ, с предусмотренными законом исключениями.

Ответственность несёт оператор — организация, определяющая цели обработки. С 30 мая 2025 года действуют поправки, внесённые в статью 13.11 КоАП: размер санкции зависит^[3] от состава и масштаба нарушения, а для ряда повторных нарушений предусмотрен оборотный штраф от 1 до 3% совокупной выручки, с порогом 20–25 млн и максимумом 500 млн руб. Отдельная ответственность за неуведомление^[3] повышает риск скрытых хранилищ.

С 11 декабря 2024 года действует статья 272.1 УК РФ об ответственности за незаконные действия с компьютерной информацией, содержащей персональные данные. Для специальных категорий, биометрии и данных несовершеннолетних часть 2 статьи предусматривает лишение свободы до пяти лет, а при трансграничной передаче санкция может достигать восьми лет. Сам обход ИТ-службы состава преступления не образует, но незаконные действия с данными могут повлечь уголовные последствия.

Федеральный закон № 265-ФЗ от 26 июля 2026 года уточнил критерии формирования перечня иностранных государств с адекватной защитой прав субъектов персональных данных. Поэтому в реестре приложения стоит фиксировать страну размещения и правовое основание передачи.

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

Архитектурные и эксплуатационные риски

Самая частая эксплуатационная проблема — незадокументированные связи с корпоративными системами. Автор настроил выгрузку из учётной системы, ИТ-служба об этом не знает, обновление основной конфигурации меняет структуру выгрузки, и самодельный сервис останавливается в момент закрытия периода.

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

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

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

Что low-code не спасает сам по себе

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

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

Три линии контроля внутри платформы

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

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

Никита Аксёнов, директор по развитию Unitarius

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

Централизованная ролевая модель и права

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

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

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

Реестр приложений и версионность

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

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

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

Аудит и журналирование действий

Атрибуция изменений отвечает на вопрос «кто, когда и что именно изменил» в логике маршрута или экранной форме. Без такой записи разбор инцидента превращается в опрос свидетелей.

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

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

Рекомендации Gartner предлагают риск-ориентированные ограничители и заранее распределённые права вместо переноса на гражданскую разработку всех процедур классического ИТ.

Организационная часть: зрелая платформа, центр компетенций, каталог приложений

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

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

Павел Перов, директор по продукту «Авандок.Платформа» ГК «КОРУС Консалтинг»

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

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

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

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

Модель управляемой свободы: где сотрудник автономен, а где нужен ИТ

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

Практическая матрица уровней выглядит следующим образом:

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

Распределение ролей и ответственности в команде

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

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

Виталий Томко, менеджер по развитию no/low-code Directum

Распределение ответственности удобно закрепить в явном виде:

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

Governance как повседневный процесс, а не разовый запрет

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

Этапы жизненного цикла выглядят так:

1. Идея. Подразделение фиксирует потребность в общей заявке, а не собирает решение сразу;
2. Оценка. Центр компетенций проверяет, нет ли уже готового аналога и какой уровень охвата требуется;
3. Сборка. Работа ведётся в песочнице из утверждённых блоков и по правилам именования;
4. Проверка. Тестирование логики, прав доступа и корректности обмена в тестовой среде;
5. Ревью и согласование. Глубина зависит от уровня: от короткой проверки прав до полного разбора архитектуры;
6. Выпуск. Публикация с фиксацией версии, назначением владельца и внесением в каталог;
7. Эксплуатация. Мониторинг доступности, обработка обращений пользователей, плановые доработки;
8. Вывод из эксплуатации. Архивация сведений, отключение, снятие прав и удаление из каталога.

К циклу добавляются три рутинные практики:

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

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

ИИ-ассистенты и генерация приложений: новый источник тени или помощник

ИИ-ассистенты увеличивают долю автоматизации, которую бизнес создаёт без прямого участия ИТ, и одновременно расширяют риск невидимых потоков данных. Это подтверждают прогноз Gartner, исследование Microsoft и LinkedIn, данные IBM, отчёт Netskope и отчёт Work Trend Index Microsoft. Корпоративные сведения могут загружаться во внешние сервисы без оценки рисков, поэтому контроль должен охватывать не только приложения, но и учётные записи с коннекторами.

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

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

Чек-лист: как проверить платформу и собственные процессы

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

• Ролевое разграничение на уровне объектов, записей и отдельных атрибутов;
• Версионность логики со сравнением редакций и возвратом к прежней;
• Журнал операций с указанием автора, времени и содержания правки;
• Обязательное согласование при выпуске в продуктивную эксплуатацию;
• Раздельные тестовый и продуктивный участки с понятной процедурой переноса;
• Каталог созданного с владельцами и составом обрабатываемых сведений;
• Подтверждённая независимая проверка функций защиты и наличие продукта в реестре отечественного программного обеспечения.

Проверка платформы по демонстрации особенно важна: исследование Фонда «Сколково» 2025 года, в котором проанализировали 30 продуктов по 410 критериям, показало высокую степень развития функций управления доступом, логирования и аудита, но более слабую проработку интеграции со сторонними приложениями и встроенных инструментов ИИ. Поэтому именно эти участки стоит включать в обязательный сценарий пилота, а не ограничиваться показом конструктора форм.

Не менее полезно оценить собственную зрелость до выбора поставщика:

• Существует ли актуальный реестр самодельных сервисов, включая таблицы с макросами;
• У каждого ли инструмента есть назначенный владелец, а не «автор, который уже уволился»;
• Описан ли порядок вывода доработки в продуктивную эксплуатацию;
• Проходят ли авторы обучение правилам работы с персональными данными;
• Известен ли порядок действий при инциденте, включая сроки уведомления регулятора;
• Измеряется ли время от обращения подразделения до готового результата.

Типичные ошибки при выстраивании гражданской разработки

Ошибки повторяются и почти всегда сводятся к перекосу в одну из сторон: либо всё запрещено, либо ничего не проверяется.

Наиболее заметные из них:

• Полный запрет вместо легальной альтернативы: потребность сохраняется, но уходит из поля зрения ИТ;
• Десяток разных конструкторов у разных отделов вместо единой среды с общими правилами;
• Правила без обучения: регламент подписан, авторы о нём не знают и не понимают его логики;
• Ревью каждой мелочи, из-за которого согласование снова растягивается и подразделения возвращаются к самодеятельности;
• Отсутствие ответственного за платформу: обновления, лимиты и права никем не ведутся;
• Учёт ради отчёта: каталог заполняется формально и не используется при планировании изменений;
• Оценка эффекта по количеству собранных сервисов, а не по сокращению ручных операций.

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

Чем low-code отличается от no-code применительно к гражданской разработке?

No-code полностью исключает программирование и подходит для типовых форм, реестров и простых маршрутов. Low-code сохраняет визуальную сборку, но позволяет точечно дописать логику, поэтому именно он используется для сервисов, которые со временем усложняются. Для автора без технической подготовки практическая разница в том, что во втором случае рядом должен быть профессиональный разработчик.

Заменит ли гражданская разработка ИТ-отдел?

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

Какие задачи нельзя отдавать бизнесу?

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

Можно ли считать электронные таблицы теневым ИТ?

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

Как измерить эффект от программы гражданской разработки?

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

Заключение

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

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

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

Список источников

1. What Is Shadow IT? 2024 Statistics & Solutions — https://jumpcloud.com/blog/shadow-it. Дата обращения: 11 августа 2026. ^{1 2 3}
2. Статья 3. Основные понятия, используемые в настоящем Федеральном законе \ КонсультантПлюс — https://www.consultant.ru/document/cons_doc_LAW_61801/4f41fe599ce341751e4e34dc50a4b676674c1416/. Дата обращения: 11 августа 2026. ^{1 2}
3. КоАП РФ Статья 13.11. Нарушение законодательства Российской Федерации в области персональных данных \ КонсультантПлюс — https://www.consultant.ru/document/cons_doc_LAW_34661/1f421640c6775ff67079ebde06a7d2f6d17b96db/. Дата обращения: 11 августа 2026. ^{1 2}