Александр Костин – Внедрение ИИ в компании: пошаговая система устранения хаоса (страница 6)

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

Безопасность в контексте ИИ – это не тема для отдельного отдела и не страховка «на всякий случай». Это рабочая дисциплина. Если вы не зададите правила по данным и проверке фактов на старте, внедрение либо заблокируют из страха, либо оно начнёт жить стихийно: сотрудники будут использовать ИИ в личных аккаунтах, пересылать куски переписок, копировать коммерческие условия, вставлять персональные данные, а потом вы получите конфликт с клиентом или внутренний скандал, после которого внедрение закроют на месяцы.

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

Почему нейросети опасны не «утечками», а привычкой к удобству

Классический страх звучит так: «если мы отправим данные в ИИ, их украдут». Иногда это правда, но чаще проблема другая. Главная опасность нейросетей в бизнесе – это то, что они создают иллюзию завершённой работы. Текст выглядит гладко, структура убедительна, тон уверенный. У человека возникает ощущение: раз написано красиво, значит верно. Это и есть самообман, который приводит к ошибкам в обещаниях, сроках, суммах, условиях и фактах.

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

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

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

Категории данных: что запрещено, что условно допустимо, что безопасно

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

Практичная классификация на пилоте может состоять из трёх уровней.

Первый уровень – запрещено. Это данные, которые нельзя передавать в ИИ в исходном виде ни при каких условиях.

Сюда обычно относятся персональные данные клиентов и сотрудников, которые позволяют идентифицировать человека: ФИО, телефон, email, адрес, паспортные данные, даты рождения, аккаунты в мессенджерах, ID в CRM, любые уникальные номера, медицинские сведения, если вы работаете с медициной, и вообще любой набор данных, который однозначно привязывает информацию к человеку.

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

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

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

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

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

Важно понимать: «безопасно» не означает «можно делать что угодно». Это означает, что риск утечки минимален, и основная задача – проверка качества результата, а не защита данных.

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

Обезличивание: как делать быстро и не ломать задачу

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

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

Есть несколько практичных правил.

Заменять людей и компании ролями. Вместо «Иван Петров из компании Ромашка» – «клиент», «контактное лицо», «партнёр», «поставщик». Вместо названий – «компания А», «компания Б».

Убирать уникальные номера и ссылки. Любой ID, номер договора, номер заказа, ссылка на внутренние документы – это идентификатор. Его нужно убрать или заменить маркером.

Обобщать суммы и сроки. Если сумма критична для логики, используйте диапазон («около X», «в пределах Y–Z») или замените маркерами («СУММА», «СРОК»), если задача про структуру текста, а не про точные условия.

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

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

Для пилота полезно сделать два шаблона обезличивания: для переписки с клиентом и для коммерческого предложения. Тогда сотрудник не будет каждый раз изобретать способ скрыть данные.

Строгий режим: для каких задач он обязателен и почему

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

Строгий режим обязателен, когда в тексте есть:

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

суммы, скидки, штрафы, условия оплаты;

сроки и гарантии;

юридические формулировки и ссылки на договорные условия;

ответы на претензии и конфликтные ситуации;

публичные заявления и тексты, которые могут быть процитированы;

любые факты, которые клиент может проверить и оспорить.

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

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

Проверка фактов: источник правды, метод, минимальный стандарт

Фактчекинг в бизнесе – это не журналистская работа. Это дисциплина сверки с источником правды.

Источник правды – это не нейросеть, не память сотрудника и не «кажется, мы так делали». Источник правды – это документы и системы: договор, CRM, прайс, регламент, база знаний, протокол встречи, утверждённые условия. Внедрение ИИ часто выявляет, что источника правды нет или он размазан по чатам. Это отдельная проблема, но на пилоте её можно решить минимально: определить, где лежит актуальная информация по ключевым вопросам.

Минимальный стандарт проверки фактов должен быть таким, чтобы его реально делали. Если вы требуете «проверять всё», вы получите ноль. Лучше требовать «проверять всегда вот эти элементы»: