Знакомая история? Вы приходите к руководству с горящими глазами: «Давайте внедрим AI-бота для поддержки клиентов!» Все кивают, бюджет одобряют, и тут... «Только сначала согласуйте с ИБ и юристами». Проект, который казался делом двух недель, уходит в болото бесконечных согласований.
Безопасники засыпают вопросами: «А куда пойдут данные клиентов? В какую страну? Кто их увидит?» Юристы требуют показать согласие на обработку. IT-архитектор хватается за голову: «Как мы будем логировать все решения AI для аудита?» И вот уже месяц прошёл, а проект застрял на нулевой стадии.
Но вот в чём штука: эти люди — не враги вашего проекта. Они его защитники. Просто большинство команд совершают одну и ту же ошибку — приходят к безопасникам уже после выбора решения. А потом удивляются «сюрпризам»: оказывается, выбранный вендор хранит данные где-то в Ирландии, API гоняет персональные данные в открытом виде, а логов для аудита вообще нет.
Я написал эту статью, чтобы вы не наступали на те же грабли. Здесь — практический гайд о том, как подготовить AI-проект так, чтобы встреча с ИБ и юристами закончилась не блокировкой, а одобрением. Поговорим про управление данными, работу с персональной информацией, доступы, хранение и аудит. Всё это — в контексте казахстанского законодательства.
Секрет быстрого согласования
Безопасники и юристы — не бюрократы, которые хотят «зарубить» вашу инициативу. Они просто хотят понять: какие риски несёт проект и как вы собираетесь их закрывать. Когда вы приходите с готовыми ответами — согласование занимает дни. Когда без ответов — месяцы.
Моя задача — дать вам «шпаргалку»: какие вопросы вам зададут и какие ответы подготовить заранее. Чтобы на встрече вы выглядели профессионально, а не как человек, который «хочет странного».
Часть 1: Data Governance — разберёмся, куда текут ваши данные
Термин «data governance» звучит пугающе корпоративно, но на самом деле это просто набор ответов на очень конкретные вопросы. Какие данные будет «видеть» ваш AI? Кому они принадлежат? Где физически лежат? Кто к ним имеет доступ? Сколько времени они хранятся?
Когда безопасник спрашивает про data governance — он не пытается вас завалить умными словами. Он хочет понять путь данных от точки А до точки Б. И если вы этот путь не знаете — у вас проблема.
К чему готовиться на встрече с ИБ
| Вопрос ИБ | Что нужно подготовить |
|---|---|
| Какие данные передаются в AI-систему? | Перечень полей: имя, телефон, email, история покупок и т.д. С классификацией: PII / конфиденциальные / публичные |
| Где физически хранятся данные? | Страна и дата-центр. Для Казахстана критично: данные граждан РК должны храниться на территории РК или в странах с адекватным уровнем защиты |
| Кто является процессором данных? | Вендор AI, облачный провайдер, подрядчик по интеграции — все, кто «видит» данные |
| Как данные передаются? | Протоколы (HTTPS, TLS 1.3), шифрование в transit и at rest |
| Сколько данные хранятся? | Retention policy: логи диалогов — 90 дней, персональные данные — до отзыва согласия |
Нарисуйте карту потоков данных — это снимет 80% вопросов
Серьёзно, это лучшая инвестиция времени перед встречей с безопасниками. Возьмите лист бумаги (или Miro, если вы современный человек) и нарисуйте, откуда данные приходят, куда уходят и что с ними происходит по дороге.
На схеме должно быть видно: откуда берутся данные (CRM, база заказов, история переписок), как они передаются (через API, вебхуки, выгрузки), что с ними делает AI, где всё это хранится и — самое важное — где проходит граница «внутри компании / снаружи». Когда безопасник видит такую схему, разговор сразу становится предметным. Вместо абстрактного «а как у вас с данными?» — конкретные вопросы по конкретным точкам.
Как это выглядит на практике: AI-бот для интернет-магазина
Допустим, вы делаете бота для поддержки клиентов. Вот как может выглядеть ваша карта данных:
Откуда берём: контакты клиентов из CRM, информацию о заказах из OMS, ответы на частые вопросы из базы знаний
Как передаём: всё летит по защищённому каналу (TLS 1.3), каждый запрос авторизован токеном, доступ только с определённых IP-адресов
Где обрабатывается: AI-платформа крутится в облаке на территории Казахстана, там же лежит векторная база для поиска по документам
Что храним и сколько: логи диалогов — 90 дней (потом автоудаление), метрики — год, всё персональное маскируется
Главное правило: персональные данные не выходят за периметр компании — в AI-модель уходит только обезличенный текст
С такой картой разговор с безопасниками превращается из допроса в конструктивное обсуждение. Вы показываете, что понимаете, о чём говорите.
Часть 2: Персональные данные — самая «горячая» тема
Если безопасник и юрист напрягаются при словах «AI-бот» — в 90% случаев они думают о персональных данных. И правильно делают. Казахстанский закон о персональных данных (от 21.05.2013 № 94-V) — штука серьёзная. Нужно согласие человека, данные можно использовать только для заявленной цели, и защищать их нужно как зеницу ока.
А теперь представьте типичную ситуацию. Клиент пишет в чат: «Здравствуйте, меня зовут Алексей Иванов, номер заказа 12345, телефон 87771234567, когда доставка?» Если вы передаёте это сообщение в ChatGPT или любую другую модель как есть — поздравляю, вы только что отправили персональные данные казахстанского гражданина на сервера в США. Это, мягко говоря, проблема.
Золотое правило: AI должен знать только то, что ему нужно для работы
Звучит очевидно, но на практике большинство решений «для простоты» гонят в модель всё подряд. А правильный подход — минимизация. Чтобы ответить на вопрос о доставке, AI не нужно знать ФИО клиента. Ему достаточно номера заказа.
Как делают обычно (и это плохо)
Клиент пишет: «Здравствуйте, я Алексей Иванов, тел. 87771234567, заказ #12345 не доставлен»
Система берёт и отправляет весь текст в облачную модель. Имя, телефон — всё утекло за рубеж. Упс.
Как нужно делать
Перед отправкой текст проходит через фильтр: «Здравствуйте, я [ИМЯ], тел. [ТЕЛЕФОН], заказ #12345 не доставлен»
Модель работает с обезличенным текстом. Персональные данные никуда не уходят — они остались на вашем сервере.
Инструменты защиты: выбирайте под задачу
Есть несколько способов «спрятать» персональные данные от AI, и каждый подходит для своей ситуации.
Маскирование — самый простой вариант. ФИО заменяем на [ИМЯ], телефон на [ТЕЛЕФОН]. AI видит, что там было что-то личное, но само «что-то» не видит. Отлично работает, когда модели не нужны реальные данные для ответа — а это 80% случаев.
Токенизация — чуть сложнее. Вместо «Алексей Иванов» система подставляет что-то вроде «USR_a7b3c9d2». Этот токен хранится в защищённой базе, и при необходимости можно «раскрыть» обратно. Нужно, когда ответ AI должен содержать персонализацию — «Алексей, ваш заказ доставлен».
Псевдонимизация — похоже на токенизацию, но проще. Иванов становится «Клиент_123». Связь между псевдонимом и реальным человеком хранится отдельно. Хорошо для аналитики и обучения моделей.
Агрегация — когда вам вообще не нужны конкретные люди. Вместо «Алексей купил на 50 000 тенге» — «средний чек клиентов из Алматы — 45 000 тенге». Идеально для дашбордов и отчётов.
А что скажут юристы про согласие?
Юристы обязательно спросят: «Как вы получаете согласие клиента на обработку его данных искусственным интеллектом?» И это правильный вопрос.
Минимум, который нужно обеспечить: клиент должен понимать, что общается с ботом, а не с живым человеком. Он должен знать, зачем вы обрабатываете его данные («чтобы ответить на ваш вопрос», «чтобы улучшить качество сервиса»). Он должен знать, сколько хранятся его диалоги. И у него должна быть возможность всё это отозвать и потребовать удаления.
На практике это решается просто: в начале диалога бот говорит что-то вроде «Привет! Я AI-ассистент. Продолжая разговор, вы соглашаетесь с нашей политикой обработки данных» — и ссылка на документ. Не идеально с точки зрения UX, но юристов успокаивает.
Часть 3: Кто куда лезет — разбираемся с доступами
AI-система — это не одна программа, а целый зоопарк компонентов. Админка, API для интеграций, логи диалогов, база знаний, дашборды с метриками... У каждого компонента — свои секреты, и не все должны их видеть.
Безопасник обязательно спросит: «Кто имеет доступ к чему? И почему именно он?» Если у вас нет чёткого ответа — это красный флаг. Поэтому перед встречей нарисуйте матрицу доступов.
Как может выглядеть такая матрица
| Роль | Админ-панель | Логи диалогов | База знаний | Настройки AI | Метрики |
|---|---|---|---|---|---|
| Администратор системы | |||||
| Контент-менеджер | |||||
| Оператор поддержки | * | только чтение | |||
| Руководитель отдела | только чтение | ||||
| Аудитор / ИБ | только чтение | только чтение |
* Оператор видит только диалоги, переданные ему на обработку
Четыре принципа, которые понравятся безопасникам
Когда будете объяснять свой подход к доступам, используйте эти термины — они говорят на этом языке.
Least Privilege — минимальные права. Контент-менеджеру не нужны логи диалогов, ему достаточно доступа к базе знаний. Не давайте больше, чем нужно для работы.
Segregation of Duties — разделение обязанностей. Человек, который настраивает AI, не должен сам же проверять качество его работы. Иначе получится «сам себе судья».
Need to Know — доступ только тем, кому это действительно нужно. Маркетологу для отчёта не нужны сырые логи диалогов — ему достаточно агрегированных цифр.
Временные доступы — про подрядчиков. Интегратору даёте доступ на время проекта. Проект закончился — доступ отозвали. Звучит очевидно, но забывают об этом постоянно.
Отдельная тема — API
AI-бот обычно интегрируется с кучей других систем: CRM, база заказов, склад, что угодно. Каждая такая интеграция — это потенциальная дыра, через которую могут утечь данные. Безопасники это знают и будут копать именно здесь.
Что им показать: API-ключи с ограниченными правами и сроком жизни (а не вечные «мастер-ключи»), список разрешённых IP-адресов, лимиты на количество запросов (защита от «пылесоса» данных) и, конечно, логи — кто, когда и какие данные запрашивал через API.
Часть 4: Хранение — где лежит, сколько живёт, как удалять
AI-системы — настоящие фабрики по производству данных. Логи диалогов, векторные представления текстов, кэш ответов, метрики производительности... Всё это где-то лежит и занимает место. И безопасники захотят понять: где именно, сколько времени, и что происходит потом.
Сколько чего хранить — нужна политика
Нельзя просто сказать «храним всё вечно» — это и дорого, и рискованно. Нельзя сказать «удаляем сразу» — потеряете возможность разбирать инциденты. Нужен баланс.
| Тип данных | Срок хранения | Обоснование | Способ удаления |
|---|---|---|---|
| Логи диалогов (с PII) | 90 дней | Разбор споров, обучение операторов | Автоматическое удаление по TTL |
| Логи диалогов (обезличенные) | 1 год | Аналитика, улучшение AI | Архивация + удаление |
| Метрики и статистика | 3 года | Отчётность, тренды | Агрегация + удаление деталей |
| Аудит-логи (кто что делал) | 5 лет | Требования регулятора, расследования | Архивное хранение |
| Кэш ответов | 7 дней | Производительность | Автоматическое вытеснение |
Локализация: казахстанская специфика
А вот тут начинается самое интересное для тех, кто работает в Казахстане. Закон требует, чтобы персональные данные граждан РК хранились и обрабатывались либо на территории Казахстана, либо в странах с «адекватным уровнем защиты».
Что это значит на практике? Если вы используете OpenAI, Anthropic, Google или любую другую модель с серверами за рубежом — персональные данные туда отправлять нельзя. Либо ищите вендора с дата-центром в Казахстане, либо обезличивайте данные перед отправкой.
Как это работает на практике
Представьте: клиент пишет «Я Алексей, заказ #12345». Сообщение попадает на ваш сервер в Казахстане, где стоит «шлюз» для маскирования. Шлюз превращает сообщение в «Я [ИМЯ], заказ #12345» и только потом отправляет в облачную модель.
Модель генерирует ответ: «[ИМЯ], ваш заказ #12345 будет доставлен завтра». Ответ возвращается на шлюз, тот подставляет обратно «Алексей» вместо «[ИМЯ]» — и клиент видит персонализированное сообщение.
Красота в том, что персональные данные никогда не покидали территорию Казахстана. Модель работала с обезличенным текстом, а «расшифровка» произошла уже внутри периметра.
«Удалите мои данные!» — а вы готовы?
Любой клиент имеет право потребовать удаления своих данных. И если вы не можете это сделать — у вас проблема с законом. Но в AI-системе это не так просто, как кажется.
Сначала нужно найти все данные конкретного человека. А они могут быть размазаны по десятку мест: логи диалогов, кэш ответов, метрики, может быть, даже в обучающей выборке. Поэтому ещё на этапе проектирования продумайте, как связать все данные с конкретным клиентом — иначе потом будете искать иголку в стоге сена.
Дальше — каскадное удаление: убрать нужно всё, что связано с человеком, а не только «основную» запись. И обязательно залогировать факт удаления — когда, что удалили, по чьему запросу. Это нужно для аудита. Кстати, сами аудит-логи можно хранить дольше, если они обезличены — это может потребоваться для расследований.
Часть 5: Аудит — чтобы потом не гадать «а что произошло?»
Рано или поздно случится инцидент. Клиент пожалуется: «Ваш бот мне нахамил!» или «Бот обещал скидку 50%, где она?» И в этот момент вам очень пригодится возможность «отмотать плёнку назад» и посмотреть, что именно произошло.
Если логов нет или они неполные — вы в положении человека, который пытается восстановить события по памяти. Это слабая позиция и для разбора с клиентом, и для общения с регулятором.
Что должно попадать в логи
| Событие | Что записывать | Зачем |
|---|---|---|
| Входящий запрос | Timestamp, ID клиента, канал, текст (маскированный) | Восстановить контекст |
| Решение AI | Intent, confidence, выбранное действие, причина | Понять логику AI |
| RAG-запрос | Какие документы использованы, релевантность | Проверить источники ответа |
| Ответ AI | Полный текст ответа, время генерации | Что увидел клиент |
| Действия пользователей | Кто, когда, что изменил (настройки, база знаний) | Кто отвечает за изменения |
| Эскалации | Причина эскалации, кому передано | Отследить проблемные кейсы |
«Чёрный ящик» — главная проблема AI
Регуляторы и безопасники очень не любят ситуацию «AI что-то там решил, а почему — непонятно». Поэтому важно логировать не только результат, но и логику принятия решения.
Если модель «думает» в несколько шагов (Chain-of-Thought) — сохраняйте эти промежуточные шаги. Если используете RAG и модель ищет по документам — записывайте, какие документы были использованы. Сохраняйте confidence score — насколько модель была уверена в ответе. И обязательно логируйте, если сработали какие-то ограничения («отказался отвечать на политический вопрос», «запрос был слишком агрессивным»).
Всё это нужно, чтобы потом можно было сказать: «Вот почему бот ответил именно так. Вот источники. Вот логика. Вот почему не ответил иначе».
Логи должны быть неизменяемыми
Смысл аудита теряется, если логи можно подправить задним числом. «А вот тут было написано другое» — и всё, доверие к логам на нуле.
Поэтому аудит-логи должны храниться в режиме «только запись» — изменить или удалить нельзя. Хорошая практика — подписывать каждую запись хэшем, чтобы было видно, если кто-то пытался что-то подменить. Хранить логи нужно отдельно от рабочих данных, и доступ к ним должен быть только у аудиторов и службы безопасности — не у разработчиков и не у операторов.
Шпаргалка на встречу: что взять с собой
Главное правило: приходите с ответами, а не с вопросами. Безопасники любят подготовленных людей — это экономит время всем. Вот что положить в папку перед встречей:
Бумажки (да, они нужны)
Схема потоков данных (та самая Data Flow Diagram). Список всех данных, которые будет видеть AI, с пометками «персональные / конфиденциальные / публичные». Матрица «кто к чему имеет доступ». Политика хранения — сколько что живёт. Если есть вендор — договор об обработке данных (DPA). И обновлённая политика конфиденциальности для клиентов.
Технические ответы
Как маскируете персональные данные. Как шифруете (и при передаче, и при хранении). Как устроена авторизация в API. Что и куда логируется. Как делаете бэкапы и как из них восстанавливаться. Что будете делать, если случится инцидент (план реагирования).
Лайфхак, который сэкономит вам месяцы
Не приходите к безопасникам с готовым решением и просьбой «согласуйте». Приходите на этапе выбора вендора с вопросом «какие требования нам нужно учесть?»
Когда ИБ участвует в формировании требований с самого начала — они становятся союзниками, а не блокерами. Они сами помогут выбрать решение, которое потом легко согласуют. Психология простая: люди охотнее одобряют то, в создании чего участвовали.
«А если спросят вот это?» — готовые ответы на каверзные вопросы
Безопасники — люди опытные, вопросы у них стандартные. Вот самые частые и как на них отвечать:
«Данные клиентов уходят за границу — это же нарушение закона!»
Ваш ответ: «Персональные данные не покидают Казахстан. Мы используем маскирование — в облачную модель уходит только обезличенный текст. Вот схема, смотрите: здесь точка маскирования, здесь граница периметра».
«А если бот скажет клиенту какую-нибудь глупость? Кто будет отвечать?»
Ваш ответ: «Мы настроили ограничения — список тем, на которые бот не отвечает, обязательные ссылки на источники в ответах. Если модель не уверена — автоматически переводит на оператора. Плюс все диалоги логируются, можно проверить любой ответ».
«AI пообещает клиенту скидку 90% — и что тогда?»
Ваш ответ: «Критичные действия — возвраты, скидки больше определённой суммы — требуют подтверждения живого человека. Бот может только инициировать процесс, но не завершить его. Вот матрица: что бот может делать сам, что только с одобрением».
«Клиент потребует удалить свои данные. Как будете это делать?»
Ваш ответ: «У нас есть процедура каскадного удаления. По запросу находим все данные клиента — диалоги, кэш, метрики — и удаляем. Время исполнения до 72 часов. Факт удаления логируем для отчётности».
Если хотите копнуть глубже
Эта статья — обзор для быстрого погружения. Если какая-то тема зацепила и хочется разобраться детальнее:
Вместо заключения: безопасность — это не про «нельзя», а про «можно, если правильно»
Знаете, что отличает успешные AI-проекты от тех, что застряли в бесконечном согласовании? Не бюджет. Не технологии. Подход к безопасности.
Компании, которые пытаются протащить AI «в обход» безопасников — рискуют дважды. Во-первых, штрафы за нарушение законодательства никто не отменял. Во-вторых, один инцидент с утечкой данных — и репутация летит в тартарары. А компании, которые делают безопасность частью проекта с самого начала — получают конкурентное преимущество.
Клиенты сегодня всё чаще спрашивают: «А что вы делаете с моими данными?» Если у вас есть чёткий, уверенный ответ — это доверие. Если начинаете мяться и говорить «ну, там, всё нормально» — это сигнал, что с вами лучше не связываться.
Три вещи, которые нужно вынести из этой статьи:
Первое — вовлекайте безопасников с первого дня. Не после выбора решения, а до. Пусть они помогут сформулировать требования.
Второе — приходите на встречу подготовленными. Схема потоков данных, матрица доступов, политика хранения — всё это должно быть готово заранее.
Третье — минимизируйте данные. AI должен видеть только то, что ему нужно для работы. Всё персональное — маскировать.
Безопасный AI-проект — это не дорогой проект. Это правильно спланированный проект, где защита данных заложена в архитектуру изначально, а не прикручена сбоку на скотч в последний момент.
Застряли на согласовании?
Поможем подготовить все документы для ИБ и юристов, проверим архитектуру на соответствие требованиям безопасности. Вместе выберем решение, которое пройдёт согласование без лишних итераций.
Давайте обсудим