The post has been translated automatically. Original language: Russian
Employees start using AI before the company has time to choose tools and formulate rules. A ban may block access to the service, but it does not answer the main question: where is AI already involved in the work and what consequences does this create.
In a previous article in this series, I suggested looking at one AI use case: what task it solves, what data it receives, what role the result plays, and who is responsible for the next step.
But you can describe the use case only when the company knows about its existence.
In practice, AI often appears before the general solution. An employee opens a personal account because they need to quickly compare two documents. The supervisor includes a new feature in the meeting service. The developer connects the assistant to the development environment. The support team finds a way to prepare responses to customers faster.
I understand why this is happening. I use AI tools myself almost every day. When a tool really saves time, waiting for a big strategy looks superfluous. For an individual, a small experiment can be quite reasonable. The gap appears at the company level: the work has already changed, but the organization does not see it yet.
This is how **shadow AI** arises — the use of AI tools or AI functions outside the established visibility and control of the organization.
This is not necessarily an unknown application. Shadow AI can live inside a familiar and even authorized service.: An employee activates a new function, uploads a different type of data, connects a folder, uses a personal account, or begins to rely on the result in a more meaningful decision.
When working with processes, I usually start with a gap between the stated rule and how the work actually works. Shadow AI is just such a gap: a tool may be missing or banned in politics, and the result it has created is already moving forward in the process.
Therefore, it is not enough to search only for "unresolved neural networks". It is important to see specific application methods.
What exactly is the company losing sight of
Data route
The request may include a client's request, a contract, a candidate's resume, a piece of code, a financial spreadsheet, or an internal discussion. The further route depends on the supplier, the tariff, the settings, the region, the connected functions and the terms of the contract.
If a company does not know about the application, it cannot verify which data is allowed to be transferred, where it is stored, who gets access to it, and whether it is used for other purposes.
The phrase "we don't upload anything to AI" can also give false peace of mind. It is enough to include a transcript of the meeting, give the assistant access to the mail, or insert part of the working document into the request.
The role of the result
First, the AI prepares a draft. This draft then becomes a letter to the client, a change in the code, a conclusion for the supervisor, or a recommendation about the candidate.
Here, the risk is not only associated with an erroneous answer. The company may not know that AI was involved in the decision at all, which part of the result the person checked, and by which criterion. The formal "man looked" does not explain the quality of the control.
Access and independence
A modern AI tool can read files, search through a corporate database, work with a calendar, create tasks, modify code, or send messages. Enabling integration expands the use case even when the name of the service remains the same.
The employee's personal account adds another question: what happens to the history, settings, promptings, and work materials when the person changes roles or leaves the company?
The ability to restore the solution
If an important conclusion was received in a personal chat, the team may run out of sources, versions of the result, and explanations for why it was trusted. This becomes noticeable in case of an error, a dispute with a client, an internal audit, or a routine transfer of the process to another person.
The problem of shadow AI is not limited to data leakage. The company is losing the ability to answer simple questions: where is AI involved in the work, what is allowed to it, who checks the result and who will stop the application if something goes wrong.
Why is a general ban usually not enough
For individual data and scenarios, a strict ban is really needed. You can't turn the "let's figure it out first" principle into allowing you to upload secrets, personal data, or give the service wide access without evaluation.
But if the ban covers everything and does not offer a work path, the employee's task does not disappear anywhere. The benefits that he has already received are also preserved. The conversation about usage just becomes less open.
The goal of the first step is more modest: to return visibility to the company and separate the usual low-risk applications from those that require stopping, tuning, or deeper verification.
Start with a short detection period
You should not start with the question "who broke the rule?". It's more useful to ask teams what repetitive tasks they're already solving with AI.
For each application, it is enough to write:
1. the work task and the expected benefit;
2. Tool, function, and account type;
3. Input data;
4. the role of the result in the process;
5. Accesses, integrations, and possible automatic actions;
6. the person who owns the process and makes the final decision.
You don't need to collect every trial request. Inventory requires primarily repetitive applications, the results of which are included in the workflow or used by other people.
It is better to limit such a detection period in advance and explain its meaning: the team helps to collect the real picture and get a clear allowed path. If people are promised a dialogue and then punished for the very fact of disclosure, the next layer of shadow AI will only become deeper.
Evaluate the use case based on four criteria
The first distribution does not require a complex scoring model. I would look at four things.:
1. Data. Public, internal, confidential, personal, access secrets.
2. The consequences of the result. An idea, a draft, a recommendation, a basis for a decision, an automatic action.
3. Access and autonomy. A separate request, connection to a folder or system, the ability to perform actions without confirmation.
4. Scale. A one-time experiment by one person or a repetitive process that the team, customer, or product already depends on.
This results in a simple work queue.:
- Low risk: public or specially prepared data, reversible draft, no external action and integrations. It can be resolved using a short rule.
- Requires configuration and verification: internal documents, code, client materials, regular use, recommendations for a meaningful solution. We need a corporate account, clear data boundaries, and a specific verification of the result.
- Stop and separate evaluation: passwords and keys, data with limited access without an authorized contour, unappreciated processing of personal data, extensive connections to systems, automatic actions with significant consequences.
The latter category does not mean an eternal ban. It means that it is impossible to continue the experiment in its previous form until the team analyzes the data, the basis of use, settings, supplier, access and human control.
The allowed path must be convenient.
After an inventory, a company often wants to issue a long policy. An employee needs a few clear things in their daily work.:
- corporate account with verified settings;
- a short list of allowed scenarios and forbidden inputs;
- a clear way to quickly declare a new use case;
- a person or team who can provide an answer and offer a safe alternative;
- examples of checking the result for different tasks;
- a channel for reporting an error or accidental data transmission.
The list of approved tools remains useful, but the terms of use should be next to it. One service may be acceptable for a draft based on public data and unacceptable for processing a client's request in a personal account.
Name the responsibilities and events to review
Even a small application must have a workflow owner. Separately, you need to understand who is responsible for the account, settings, accesses and relationships with the supplier, and who checks the result and has the right to make the final decision.
You need to return to the use case not only according to the calendar. Revision triggers changes:
- a different type of data or a new user group;
- connecting memory, folder, mail or other integration;
- transition from from a corporate account to a personal account or vice versa;
- change of model, supplier, tariff or essential conditions;
- the new role of the result in the decision;
- the appearance of automatic action;
- error, complaint, incident, or unexpected result.
This is where shadow AI comes into contact with conventional change management: the practice can become riskier without a separate project and without a release from your team.
What is the same in world practice
There is no separate universal regulation for shadow AI in verified international sources. But professional approaches repeat the same pattern.
The NIST AI Risk Management Framework offers organizations to inventory AI systems, understand the context and specific tasks, assign roles, take into account third-party components, determine human control, and monitor incidents. This is a voluntary framework, not a mandatory checklist.
ISO/IEC 42001 considers AI through a management system: policies and processes must take into account risks and opportunities, be maintained and continuously improved. Certification according to the standard is not necessary to use its sound logic.
The UK government's AI Playbook separately names the use cases registry, clear review and escalation procedures, meaningful human control, training and monitoring. The recommendations of the British NCSC add transparency about where and how data is used, stored and viewed, as well as clear boundaries of user responsibility.
In the EU AI Act, AI literature is also tied to the role of a person, their experience and the context of using the system. The European Act is not a law of Kazakhstan, but it confirms a common vector: the same instruction is not enough for everyone.
The practical conclusion from these documents is quite mundane. Mature management begins with visibility, context of application, and responsibility. Technical constraints, training, supplier verification, and monitoring are already built around this picture.
What is happening in Kazakhstan
In Kazakhstan, the framework is already being formed, although there is no separate mode called shadow AI in the reviewed official documents.
The current Law of the Republic of Kazakhstan "On Artificial Intelligence" establishes transparency, responsibility and accountability, data protection and confidentiality, security and reliability. The owner, the owner and the user must control the AI system to the extent of their role; for owners and owners, risk management is provided throughout the lifecycle. The law also distinguishes between levels of risk and autonomy.
This is an important framework, but it does not in itself provide the company with a ready-made shadow AI registry form or describe how to identify established practices. The use cases inventory is a practical mechanism here: without it, it is difficult to understand which systems and roles already exist in real work and what requirements apply to them.
If personal data is transferred to the AI tool, the legislation of Kazakhstan on personal data applies separately. It is necessary to assess the basis and purpose of the processing, the required amount of data, the transfer to a third party, the storage of the database on the territory of Kazakhstan and the conditions for cross-border transfer. The name of a popular service by itself does not provide an answer as to whether a particular route is acceptable.
More applied industry rules are also emerging. The guidelines for education state that students' personal data cannot be entered into third-party services, AI materials must be checked by the teacher, and the final decisions remain with the teacher. This is still an example for one area, but it shows the direction well: general principles are gradually turning into rules for specific work.
Therefore, the answer to the question "is Kazakhstan doing something about this problem?" is that the legal and methodological framework is already developing. Companies will still have to create the corporate visibility of daily AI usage internally.
What can be done in one week
Choose one function where AI is already bringing significant benefits: support, marketing, development, HR, or document management.
Ask the team to uncover recurring use cases without looking for the culprits. Write down the task, data, result role, access rights, and owner for each one. Divide the applications into three groups. For low risk, immediately give the allowed path. Stop the scenarios from the red group until they are evaluated separately. Set the conditions, verification, and review period for the interim ones.
This week will not create a complete AI governance system. But the company will get something that the system does not start without: an honest picture of where AI is already working.
Сотрудники начинают пользоваться AI раньше, чем компания успевает выбрать инструменты и сформулировать правила. Запрет может закрыть доступ к сервису, но не отвечает на главный вопрос: где AI уже участвует в работе и какие последствия это создаёт.
В предыдущей статье этой серии я предложила посмотреть на один AI use case: какую задачу он решает, какие данные получает, какую роль играет результат и кто отвечает за следующий шаг.
Но описать use case можно только тогда, когда компания знает о его существовании.
На практике AI часто появляется раньше общего решения. Сотрудник открывает личный аккаунт, потому что нужно быстро сравнить два документа. Руководитель включает новую функцию в сервисе для встреч. Разработчик подключает помощника к среде разработки. Команда поддержки находит способ быстрее готовить ответы клиентам.
Я понимаю, почему это происходит. Я сама пользуюсь AI-инструментами почти каждый день. Когда инструмент действительно экономит время, ожидание большой стратегии выглядит лишним. Для отдельного человека маленький эксперимент может быть вполне разумным. Разрыв появляется на уровне компании: работа уже изменилась, а организация этого ещё не видит.
Так возникает **shadow AI** — использование AI-инструментов или AI-функций за пределами установленной видимости и контроля организации.
Это не обязательно неизвестное приложение. Shadow AI может жить внутри знакомого и даже разрешённого сервиса: сотрудник включает новую функцию, загружает другой тип данных, подключает папку, использует личную учётную запись или начинает опираться на результат в более значимом решении.
В работе с процессами я обычно начинаю с разрыва между заявленным правилом и тем, как работа устроена на самом деле. Shadow AI — именно такой разрыв: в политике инструмент может отсутствовать или быть запрещён, а созданный им результат уже движется дальше по процессу.
Поэтому искать только «неразрешённые нейросети» недостаточно. Важно увидеть конкретные способы применения.
Что именно компания теряет из виду
Маршрут данных
В запрос могут попасть обращение клиента, договор, резюме кандидата, фрагмент кода, финансовая таблица или внутреннее обсуждение. Дальнейший маршрут зависит от поставщика, тарифа, настроек, региона, подключённых функций и условий договора.
Если компания не знает о применении, она не может проверить, какие данные разрешено передавать, где они сохраняются, кто получает к ним доступ и используются ли они для других целей.
Фраза «мы ничего не загружаем в AI» тоже может давать ложное спокойствие. Достаточно включить расшифровку встречи, дать ассистенту доступ к почте или вставить в запрос часть рабочего документа.
Роль результата
Сначала AI готовит черновик. Затем этот черновик становится письмом клиенту, изменением в коде, выводом для руководителя или рекомендацией о кандидате.
Здесь риск связан не только с ошибочным ответом. Компания может не знать, что AI вообще участвовал в решении, какую часть результата проверил человек и по какому критерию. Формальное «человек посмотрел» не объясняет качество контроля.
Доступ и самостоятельность
Современный AI-инструмент может читать файлы, искать по корпоративной базе, работать с календарём, создавать задачи, изменять код или отправлять сообщения. Подключение интеграции расширяет use case даже тогда, когда название сервиса осталось прежним.
Личная учётная запись сотрудника добавляет ещё один вопрос: что произойдёт с историей, настройками, промптами и рабочими материалами, когда человек сменит роль или уйдёт из компании?
Возможность восстановить решение
Если важный вывод был получен в личном чате, у команды может не остаться источников, версии результата и объяснения, почему ему доверились. Это становится заметно при ошибке, споре с клиентом, внутренней проверке или обычной передаче процесса другому человеку.
Проблема shadow AI не исчерпывается утечкой данных. Компания теряет способность ответить на простые вопросы: где AI участвует в работе, что ему разрешено, кто проверяет результат и кто остановит применение, если что-то пойдёт не так.
Почему общего запрета обычно недостаточно
Для отдельных данных и сценариев жёсткий запрет действительно нужен. Нельзя превращать принцип «давайте сначала разберёмся» в разрешение загружать секреты, персональные данные или давать сервису широкий доступ без оценки.
Но если запрет охватывает всё и не предлагает рабочего пути, задача сотрудника никуда не исчезает. Сохраняется и польза, которую он уже получил. Разговор об использовании просто становится менее открытым.
Цель первого шага скромнее: вернуть компании видимость и отделить обычные низкорисковые применения от тех, которые требуют остановки, настройки или более глубокой проверки.
Начните с короткого периода обнаружения
Не стоит начинать с вопроса «кто нарушил правило?». Полезнее спросить команды, какие повторяющиеся задачи они уже решают с помощью AI.
Для каждого применения достаточно записать:
1. рабочую задачу и ожидаемую пользу;
2. инструмент, функцию и тип учётной записи;
3. входные данные;
4. роль результата в процессе;
5. доступы, интеграции и возможные автоматические действия;
6. человека, который владеет процессом и принимает итоговое решение.
Не нужно собирать каждый пробный запрос. Инвентаризации требуют прежде всего повторяющиеся применения, результаты которых входят в рабочий процесс или используются другими людьми.
Такой период обнаружения лучше заранее ограничить по времени и объяснить его смысл: команда помогает собрать реальную картину и получить понятный разрешённый путь. Если людям обещают диалог, а затем наказывают за сам факт раскрытия, следующий слой shadow AI станет только глубже.
Оцените use case по четырём признакам
Для первого распределения не нужна сложная балльная модель. Я бы смотрела на четыре вещи:
1. Данные. Публичные, внутренние, конфиденциальные, персональные, секреты доступа.
2. Последствия результата. Идея, черновик, рекомендация, основание для решения, автоматическое действие.
3. Доступ и автономность. Отдельный запрос, подключение к папке или системе, возможность выполнять действия без подтверждения.
4. Масштаб. Разовый эксперимент одного человека или повторяющийся процесс, от которого уже зависят команда, клиент или продукт.
Из этого получается простая рабочая очередь:
- Низкий риск: публичные или специально подготовленные данные, обратимый черновик, нет внешнего действия и интеграций. Можно разрешить по короткому правилу.
- Требует настройки и проверки: внутренние документы, код, клиентские материалы, регулярное использование, рекомендации для значимого решения. Нужны корпоративная учётная запись, понятные границы данных и конкретная проверка результата.
- Стоп и отдельная оценка: пароли и ключи, данные с ограниченным доступом без разрешённого контура, неоценённая обработка персональных данных, широкие подключения к системам, автоматические действия с существенными последствиями.
Последняя категория не означает вечный запрет. Она означает, что продолжать эксперимент в прежнем виде нельзя, пока команда не разберёт данные, основание использования, настройки, поставщика, доступы и контроль человека.
Разрешённый путь должен быть удобным
После инвентаризации компании часто хочется выпустить длинную политику. Сотруднику в ежедневной работе нужнее несколько ясных вещей:
- корпоративная учётная запись с проверенными настройками;
- короткий список разрешённых сценариев и запрещённых входных данных;
- понятный способ быстро заявить новый use case;
- человек или команда, которые могут дать ответ и предложить безопасную альтернативу;
- примеры проверки результата для разных задач;
- канал для сообщения об ошибке или случайной передаче данных.
Список одобренных инструментов остаётся полезным, но рядом с ним должны быть условия применения. Один сервис может быть приемлем для черновика на публичных данных и неприемлем для обработки обращения клиента в личном аккаунте.
Назовите ответственность и события для пересмотра
Даже у небольшого применения должен быть владелец рабочего процесса. Отдельно нужно понимать, кто отвечает за аккаунт, настройки, доступы и отношения с поставщиком, а кто проверяет результат и вправе принять итоговое решение.
Возвращаться к use case нужно не только по календарю. Пересмотр запускают изменения:
- другой тип данных или новая группа пользователей;
- подключение памяти, папки, почты или иной интеграции;
- переход с корпоративной учётной записи на личную или наоборот;
- изменение модели, поставщика, тарифа или существенных условий;
- новая роль результата в решении;
- появление автоматического действия;
- ошибка, жалоба, инцидент или неожиданный результат.
Здесь shadow AI соприкасается с обычным change management: практика может стать рискованнее без отдельного проекта и без релиза со стороны вашей команды.
Что совпадает в мировых практиках
В проверенных международных источниках нет отдельного универсального регламента для shadow AI. Но в профессиональных подходах повторяется один и тот же контур.
NIST AI Risk Management Framework предлагает организациям вести инвентаризацию AI-систем, понимать контекст и конкретные задачи, назначать роли, учитывать сторонние компоненты, определять человеческий контроль и отслеживать инциденты. Это добровольная рамка, а не обязательный чек-лист.
ISO/IEC 42001 рассматривает AI через систему управления: политики и процессы должны учитывать риски и возможности, поддерживаться в рабочем состоянии и постоянно улучшаться. Сертификация по стандарту не нужна, чтобы использовать его здравую логику.
AI Playbook правительства Великобритании отдельно называет реестр use cases, понятные процедуры review и escalation, meaningful human control, обучение и мониторинг. Рекомендации британского NCSC добавляют прозрачность о том, где и как используются, хранятся и просматриваются данные, а также ясные границы ответственности пользователя.
В EU AI Act AI literacy тоже привязана к роли человека, его опыту и контексту использования системы. Европейский акт не является правом Казахстана, но подтверждает общий вектор: одинакового инструктажа для всех недостаточно.
Практический вывод из этих документов довольно приземлённый. Зрелое управление начинается с видимости, контекста применения и ответственности. Технические ограничения, обучение, проверка поставщика и мониторинг строятся уже вокруг этой картины.
Что происходит в Казахстане
В Казахстане рамка уже формируется, хотя отдельного режима под названием shadow AI в просмотренных официальных документах нет.
Действующий Закон Республики Казахстан «Об искусственном интеллекте» закрепляет прозрачность, ответственность и подконтрольность, защиту данных и конфиденциальности, безопасность и надёжность. Собственник, владелец и пользователь должны контролировать AI-систему в объёме своей роли; для собственников и владельцев предусмотрено управление рисками в течение жизненного цикла. Закон также различает уровни риска и автономности.
Это важная рамка, но она сама по себе не выдаёт компании готовую форму реестра shadow AI и не описывает, как выявлять уже сложившиеся практики. Инвентаризация use cases здесь является практическим механизмом: без неё трудно понять, какие системы и роли уже существуют в реальной работе и какие требования к ним применимы.
Если в AI-инструмент передаются персональные данные, отдельно действует законодательство Казахстана о персональных данных. Нужно оценить основание и цель обработки, необходимый объём данных, передачу третьему лицу, хранение базы на территории Казахстана и условия трансграничной передачи. Название популярного сервиса само по себе не даёт ответа, допустим ли конкретный маршрут.
Появляются и более прикладные отраслевые правила. В методических рекомендациях для образования указано, что персональные данные учащихся нельзя вводить в сторонние сервисы, AI-материалы должен проверять учитель, а окончательные решения остаются за педагогом. Это пока пример для одной сферы, но он хорошо показывает направление: общие принципы постепенно превращаются в правила для конкретной работы.
Поэтому ответ на вопрос «делает ли Казахстан что-то с этой проблемой?» звучит так: правовая и методическая рамка уже развивается. Корпоративную видимость ежедневного AI-использования компаниям всё равно придётся создавать внутри.
Что можно сделать за одну неделю
Выберите одну функцию, где AI уже приносит заметную пользу: поддержку, маркетинг, разработку, HR или работу с документами.
Попросите команду раскрыть повторяющиеся use cases без поиска виноватых. Запишите для каждого задачу, данные, роль результата, доступы и владельца. Распределите применения по трём группам. Для низкого риска сразу дайте разрешённый путь. Сценарии из красной группы остановите до отдельной оценки. Для промежуточных назначьте условия, проверку и срок пересмотра.
Эта неделя не создаст полную AI governance system. Зато компания получит то, без чего система не начинается: честную картину того, где AI уже работает.
Share
