The post has been translated automatically. Original language: Russian
The product's history answers the question of how it all came about. The data card responds to another one: what happens right now when a person clicks a button, writes to support, or connects a new service.
In the first article of this series, I wrote about the moment when the product continues to work, and knowledge about the system around it no longer fits in the head of the team. In the following text, we reconstructed the history of the product's creation: what is in it, where did it come from, and how can we confirm the right to use it.
Now I want to look not back, but inside the working product.
Where does the data go after the form on the website? Who sees the user's message? Which systems do copies remain on? What changes if an employee uses an AI assistant or the team connects a new supplier?
From the outside, the path often looks like one screen and one button. Inside, it branches out quickly.
Start not with a list of data, but with an event.
When I started putting together a data management outline for a software project, the first difficulty wasn't the lack of the right column. Different people saw different parts of the same route.
The developer saw the database, integrations, and logs. The person who communicated with the clients saw the forms, mail, and correspondence. The manager remembered the work tables and external services. The documentary part had yet to be assembled.
Every description was true. None of them were complete maps.
For me, the work map begins precisely in this discrepancy: between the conceived architecture and the usual practice of the team.
Therefore, I would not start with the question "what data do we have?". He quickly leads to a list like "name, phone number, email, technical information." Such a list is useful, but it still does not show what the company is doing with this data.
The working question is different: what happens to the data inside one particular event?
For example:
- the user registers in the product;
- the client sends a request to support;
- the company accepts the payment;
- the candidate is responding to the vacancy;
- the team connects analytics, CRM or AI functions.
One event sets the border for the map. With it, you can already complete a real route from start to finish.
This is a first pass, not a complete registry of the entire company. His task is to assemble one verifiable route. When the method works on it, the map can be expanded to other significant processes.
Follow the route through the eyes of the data
Let's take the usual support message.
The user fills out the form. What can he contribute there? Just your name and email, or is it free text, a file, and a screenshot? Where does the form go? Is the application being created in the support system? Is a copy coming to the general mail? Does the issue get into the tracker? Can an employee forward it to the developer?
Then new questions appear.
Who has access to the application? Does the external provider of the support system see it? Where is the infrastructure located? Does the data remain in logs, backups, and uploads? What happens after the request is closed? Can a piece of correspondence end up in an AI tool if an employee asks for help with a response or error analysis?
One small process has already crossed the product interface, support, development, cloud infrastructure, vendor contracts, access rules, and people's work habits.
This is exactly what the map should show.
Show not only the systems, but also the copies.
The architectural diagram usually shows the main systems and integrations well. But data doesn't just live where it's supposed to live according to the scheme.
They can stay:
- in the email notification;
- in the issue comment;
- in the uploaded file;
- in the backup and event log;
- in a chat with a contractor;
- on the screenshot;
- in the history of the request to the AI tool.
Not every such copy means a violation. But an invisible copy cannot be consciously protected, restricted, or deleted.
Therefore, in the first pass, I would ask separately: where is the data stored by design and where does it remain in real work?
The difference between these two answers is often the most useful part of the map.
Write down the solutions next to the route
The data card should not attempt to provide a legal answer to every question immediately. But it should show where the answer already exists, and where the decision has not yet been made.
For each route, it is useful to see:
- why do we need the data?;
- whose data is this and whether there are any identifiers or information among them that require increased protection;
- who transmits them and from where;
- what kind of data is used;
- on what decision, contract, consent or other basis is the processing based;
- what systems and copies do they go through?;
- who gets access inside the company and how is it restricted;
- which external suppliers are involved;
- where exactly is the data stored and processed, including other countries;
- what determines the retention period and what triggers deletion;
- what organizational and technical measures protect them?;
- which document, setting, or recording confirms the agreement;
- who is responsible for the route and which question remains open.
In the first version, some of the cells will almost inevitably be empty. It is ok.
An honest "not found out" is more useful than a seemingly accurate answer that no one has checked.
At the research stage, such a cell shows the real work. But before launching a new process, questions about the purpose, basis, transfer and protection of data must turn into accepted decisions.
Assign a route owner and a map curator
One of the weak points of the card appears when it is given entirely to a lawyer, privacy or information security specialist.
These roles can assemble a structure, ask questions, and verify individual solutions. But they are not always the first to find out that a product has added a new field, support has started using another service, or the developers have enabled additional logging.
There is also a reverse problem. If you leave the map only to the owners of individual processes, the company will quickly have different formats, different description depths, and routes that no one has linked together.
Therefore, in the working model, responsibility is divided.
Each route has a process owner who sees the changes in the work itself. For registration, it can be a product owner. To support the function manager. To hire HR. For the infrastructure, the technical owner of the system.
The shared map also has a curator. The data governance, privacy, or other assigned role function supports the method, verifies the completeness and comparability of records, collects changes between processes, and connects the necessary assessment.
The goal is not to make the process owner a data governance specialist or transfer all responsibility to the supervisor. The task is to ensure that the route change does not remain invisible and gets into the general system.
Link the map to the points of change
The map becomes obsolete immediately after creation.
A new supplier, integration, a field in the form, a payment method, an AI tool, an access role, or a retention period change the route. If the update depends only on an annual review, the team will almost inevitably rebuild part of the picture.
Therefore, next to the map, you need a short list of events that return to it.:
- launching a new feature or client script;
- connecting or replacing an external service;
- changing the composition of the collected data;
- a new way of internal access or transfer;
- using AI for an existing process;
- changing the rules of storage, unloading or deletion;
- an incident or a customer's question that the card did not help answer.
The card does not become operational when the last line is filled in. It becomes operational when the team knows after which change it needs to be returned to.
First the table, then the diagram
The word "map" often makes you draw arrows between dozens of systems at once. For The critical flow diagram really helps. But you don't have to start with it.
By map here, I mean a small operational data flow map. This is not a technical data lineage, a corporate data catalog, or a ready-made registry of processing activities. But all these tools have the same factual basis.: what happens, where, with what data, and with the participation of whom.
On the first pass, one table, one event, and a conversation with two people who participate in the route from different sides are enough.
If their answers differ, the card has already brought benefits.
After that, you can add a second route, link the same systems, mark suppliers, and see recurring gaps. The diagram will appear later, when there is something to draw.
Checking for a single form
Open any form through which a person transmits your company's data: registration, a demo application, a support request, or a job response.
And try to go through it to the end.:
1. What data does the person enter himself and what does the system add automatically?
2. In which system does the first entry appear?
3. Who gets the notification and who can open the record later?
4. Which copies are created along the way?
5. Which external services are involved?
6. What should happen to the data when the goal ends?
7. Who will be the first to know if this route changes?
If you need to open three schemes to answer, ask one irreplaceable person and check old correspondence, this is not a failure.
This is the beginning of the work map.
Он редко входит в компанию как большой проект. Чаще появляется как вкладка в браузере, плагин или новая функция знакомого сервиса. Вместе с ним меняется не только скорость работы, но и маршрут данных, решений и ответственности.
Я сама пользуюсь AI-инструментами почти каждый день. Они помогают искать и сравнивать информацию, разбирать документы, собирать структуру, проверять логику и готовить первые версии текста.
Чем привычнее становится эта работа, тем легче воспринимать AI как ещё один удобный инструмент. Открыл, поставил задачу, получил результат, перенёс его дальше.
Но в обычном программном сервисе команда чаще понимает, что именно он делает. Калькулятор считает. Трекер хранит задачу. Система рассылки отправляет письмо по заданному сценарию. AI-инструмент получает рабочий контекст, преобразует его и создаёт новый результат, который может повлиять на код, письмо клиенту, решение о кандидате или вывод руководителя.
Поэтому вопрос быстро становится шире, чем «можно ли сотрудникам пользоваться нейросетью».
В первой статье этой серии я писала, что решение попробовать новый AI-инструмент часто принимается за один разговор. Теперь хочу посмотреть на следующий момент: что именно меняется в системе вокруг команды, когда разговор уже состоялся.
Здесь я говорю прежде всего о внутренних инструментах сотрудников. AI-функция, встроенная в продукт и работающая с пользователями автоматически, потребует более глубокого разбора. Но начинать полезно с того, что уже происходит в ежедневной работе.
AI редко приходит как отдельное внедрение
У компании может не быть AI-стратегии, проекта внедрения или строки в бюджете с таким названием. При этом разработчик уже пользуется coding assistant. Support готовит черновики ответов. HR улучшает вакансии и разбирает резюме. Руководитель суммирует встречи. Аналитик просит модель сравнить несколько документов.
Каждое действие выглядит небольшим и личным. Вместе они означают, что AI уже участвует в процессах компании.
Это не обязательно проблема. Многие применения действительно экономят время и снимают рутинную нагрузку. Проблема появляется, когда команда продолжает считать их личными экспериментами после того, как результат вошёл в общий рабочий контур.
Простой признак перехода: другой человек или процесс начинает полагаться на созданный результат. Черновик уходит клиенту. Код попадает в репозиторий. Summary становится основанием для задачи. Рекомендация влияет на решение. В этот момент эксперимент превращается в use case компании.
Начинайте с применения, а не со списка инструментов
Один и тот же AI-сервис может использоваться для очень разных задач.
Сотрудник просит придумать десять вариантов заголовка на основе публичного текста. Другой сотрудник загружает в тот же сервис обращение клиента со снимком экрана и деталями договора. Третий подключает его к корпоративному хранилищу и просит самостоятельно найти нужные документы.
Название инструмента одинаковое. Маршрут данных, возможные ошибки и последствия различаются.
Рабочей единицей становится конкретный AI use case, а не приложение само по себе:
задача + входные данные + роль результата + следующий шаг.
Список разрешённых сервисов всё равно нужен. Он помогает управлять поставщиками, аккаунтами, настройками и доступом. Но сам по себе список не объясняет, что сотрудник может делать внутри разрешённого сервиса и как команда будет использовать ответ.
Первый сдвиг: у данных появляется новый маршрут
До AI маршрут мог выглядеть так: обращение клиента попадает в support-систему, сотрудник читает его и отвечает.
После подключения ассистента появляется ещё один участок. Текст обращения, файл или снимок экрана передаются в AI-сервис. Там может сохраняться история диалога, использоваться память, работать интеграция или внешний поставщик модели. Затем созданный ответ возвращается в support-систему, почту или мессенджер.
Конкретные условия зависят от сервиса, тарифа, корпоративной или личной учётной записи, настроек и договора. Их нельзя угадывать по названию продукта.
Для первого прохода достаточно выяснить:
- что сотрудник передаёт инструменту;
- есть ли там персональные данные, коммерческая информация, код или внутренние документы;
- какая учётная запись и какие настройки используются;
- к каким системам и папкам у инструмента есть доступ;
- где сохраняются запрос, вложения и результат;
- куда результат переносится дальше.
Это уже знакомая работа с картой данных. AI добавляет к ней конкретного участника и новый участок маршрута. Абстрактный «риск нейросети» становится наблюдаемым процессом.
Второй сдвиг: результат получает роль в решении
Фраза «человек остаётся в контуре» звучит разумно, но почти ничего не объясняет.
Человек может бегло прочитать ответ и нажать Send. Может сверить каждое утверждение с источником. Может проверить только цифры. Может выбирать один вариант из нескольких. А иногда система уже отправляет ответ или выполняет действие автоматически.
Поэтому рядом с use case полезно записать, какую роль играет результат:
- идея или материал для размышления;
- первый черновик;
- рекомендация человеку;
- основание для решения;
- команда для автоматического действия.
Чем ближе результат к решению или действию, тем точнее должна быть проверка.
Для заголовка может быть достаточно редакторского выбора. Для ответа клиенту нужно проверить факты, обещания и соответствие реальной ситуации. Для изменения кода нужны review и тесты. Если созданный материал входит в продукт, может понадобиться проверка источника и условий использования. Для решения, которое затрагивает деньги, доступ, права человека или существенные условия продукта, простого взгляда на текст недостаточно.
Рабочая формулировка звучит конкретно: кто проверяет, что именно и по какому источнику или критерию?
Третий сдвиг: ответственность нужно назвать точнее
Человек, который составил запрос, не всегда владеет процессом и не всегда вправе принять итоговое решение.
В небольшом use case достаточно увидеть четыре роли:
1. Владелец применения понимает, зачем AI нужен в этом процессе и какой результат считается полезным.
2. Пользователь ставит задачу инструменту и соблюдает границы входных данных.
3. Проверяющий или владелец решения оценивает результат и отвечает за его дальнейшее использование.
4. Владелец инструмента или общего правила следит за аккаунтом, настройками, доступами и изменениями условий.
В маленькой команде один человек может совмещать несколько ролей. Ничейных зон при этом оставаться не должно.
Если ответ оказался неверным, данные ушли не туда или интеграция получила лишний доступ, команда должна понимать, кто остановит использование, исправит последствия и обновит правило.
Четвёртый сдвиг: рабочая практика может измениться без релиза вашей команды
AI-инструменты меняются быстрее многих внутренних процессов. Поставщик обновляет модель. В сервисе появляется память. Пользователь подключает новый источник. Корпоративный тариф заменяется личной подпиской. Ассистент получает возможность не только отвечать, но и выполнять действия.
Даже если название сервиса не изменилось, use case уже может стать другим.
Поэтому дата первого согласования мало что гарантирует. Нужны события, после которых команда возвращается к записи:
- изменилась задача или роль результата;
- появились новые данные или пользователи;
- подключена интеграция, память или функция автоматического действия;
- изменился аккаунт, тариф, поставщик или существенные настройки;
- результат AI стал использоваться без прежней проверки;
- произошла ошибка, жалоба или утечка контекста;
- инструмент начал влиять на более значимое решение.
Так AI use case остаётся живой частью процесса и не застывает строкой в когда-то утверждённом перечне.
Один пример: AI в поддержке
Представим, что сотрудник использует AI для подготовки ответа на обращение клиента.
На первом проходе команда может договориться о простой модели:
- AI используется только для черновика;
- лишние персональные и договорные детали не передаются;
- работа идёт через утверждённую корпоративную учётную запись;
- сотрудник проверяет факты, ссылки, обещания и тон;
- ответ клиенту не отправляется автоматически;
- сложные случаи возвращаются владельцу процесса;
- изменение интеграции, режима хранения или способа отправки запускает пересмотр.
Здесь нет запрета на полезный инструмент и нет попытки заранее описать все возможные ошибки. Есть видимый маршрут: что входит, что создаётся, кто проверяет, куда идёт результат и после какого изменения команда остановится и посмотрит ещё раз.
Минимальная карточка AI use case
Для начала не нужна большая AI policy. Достаточно одной карточки с восемью полями:
1. задача, ожидаемая польза и кого может затронуть результат;
2. владелец применения;
3. инструмент, учётная запись и режим работы;
4. разрешённые и запрещённые входные данные;
5. роль результата в процессе;
6. способ проверки и право принять решение;
7. место хранения результата и подтверждающий след;
8. события для пересмотра и дата следующей проверки.
Для низкорисковой задачи такая запись может занять одну строку. Для применения, которое влияет на людей, деньги, доступ, безопасность или поведение продукта, понадобится отдельная оценка, тестирование и более сильный контроль.
Не нужно сохранять каждый prompt только ради отчётности. След должен быть соразмерен последствиям и помогать восстановить важное: что было разрешено, на каких условиях использовался инструмент, как проверили результат и кто принял решение.
Проверка на один use case
Возьмите AI-задачу, которую команда уже повторяет, и попробуйте ответить:
1. Какую рабочую задачу она решает?
2. Какие данные получает инструмент?
3. Какую роль играет результат?
4. Кто и как его проверяет?
5. Кто отвечает за дальнейшее решение или действие?
6. Где остаются запрос, вложения и результат?
7. Какое изменение заставит пересмотреть эту практику?
Если ответы совпадают у пользователя инструмента, владельца процесса и человека, который принимает результат, use case уже имеет рабочую форму.
Если каждый описывает его по-разному, AI не обязательно нужно останавливать. Сначала стоит сделать видимым то, что уже происходит.
Именно это меняется с появлением AI-инструментов: в процесс входит новый участник, результат которого выглядит убедительно, быстро перемещается дальше и со временем получает всё больше самостоятельности. Команде нужен способ видеть этот маршрут и возвращаться к нему после изменений. Библиотека запретов такой видимости не создаёт.
Какой AI use case у вашей команды уже вышел за пределы личного эксперимента, хотя никто официально не называл его внедрением?
Share
