Внутренний корпоративный ИИ-чат для сотрудников: что точно нельзя туда отдавать

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

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

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

Что туда точно нельзя отдавать:

• Персональные данные сотрудников, клиентов, кандидатов. Риск утечки, нарушения 152-ФЗ и прямых претензий со стороны регулятора и субъектов данных. Даже обезличенный на первый взгляд набор атрибутов может быть реидентифицирован в контексте чата.
• Коммерческую тайну. Неконтролируемое распространение и потеря конкурентного преимущества. После попадания в ИИ-систему данные практически невозможно «изъять» обратно.
• Пароли, токены, ключи, сертификаты, учетные данные. Это не просто утечка, это готовый сценарий компрометации систем. Вектор атаки существенно упрощается, если злоумышленник получает доступ к истории сессий.
• Закрытые финансовые данные, бюджеты, прогнозы, управленческую отчетность. Финансовые и репутационные потери. Для публичных компаний это еще и риск нарушения требований раскрытия информации.
• Непубличную стратегию, материалы по сделкам и M&A. Риск срыва переговоров, роста цены ошибки и юридических последствий. Инсайдерская информация, попавшая в ИИ-контур, может стать предметом регуляторного расследования.
• Юридически чувствительную служебную переписку. Можно разрушить режим адвокатской тайны, исказить контекст и создать доказательства против самой компании в будущем споре.
• Чувствительные данные клиентов и партнеров. Нарушение договорных обязательств о конфиденциальности, потеря доверия и прямые санкции со стороны контрагентов. Многие партнерские соглашения прямо запрещают передачу данных третьим сторонам, и ИИ-система юридически может быть квалифицирована именно так.
• Исходный код, архитектурные схемы, внутренняя техническая документация без специально разрешенного режима. Расширение зоны доступа и упрощение атаки на инфраструктуру. Атакующий, получив контекст о внутренней архитектуре, существенно сокращает время на подготовку целевой атаки.
• Материалы расследований инцидентов и данные форензики. Риск раскрыть слабые места, скомпрометировать ход расследования и увеличить ущерб при повторной атаке.
• Данные под отраслевыми, договорными или государственными ограничениями — медицинские, персональные данные госорганов, сведения, составляющие государственную тайну. Прямое нарушение обязательного режима обработки, не только утечка, а уголовный и административный риск.

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

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

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

Станислав Ежов, директор по развитию ИИ, ПАО “Группа Астра”