ИИ и корпоративная безопасность

Из переписки:
«Мы дважды пробовали запустить пилоты [в области ИИ]. Но все проекты рубанули безопасники. Так что, это не мифы, а реальность. Нам ИИ нельзя. И что с этим делать, мне лично, не понятно.»

Сразу обозначу рамку. Я не собираюсь читать проповедь о «цифровой безопасности в целом». Такого добра и без меня как грязи. Как и не собираюсь доказывать, что ИИ не несет угроз корпоративной безопасности. И так понятно, что несет. А на сколько серьезные – понятно, что всё относительно.

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

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

Надо понимать простую вещь. Для многих сотрудников служб безопасности ИИ – это не технология, это туман. А туман у них вызывает не исследовательский интерес, а инстинкт окопаться, натянуть колючую проволоку и повесить табличку «до особого распоряжения». Не потому, что они все глупые. Хотя и такое, чего греха таить, встречается, а потому, что их система подготовки десятилетиями точилась не под развитие, а под недопущение.

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

И вот здесь аналитик или архитектор делает типичную ошибку. Он начинает разговаривать с ними как с техническими специалистами, которые просто не знают нужных деталей. И начинает объяснять про LLM, RAG, embeddings, orchestration, контекстные окна, маршрутизацию, политику retention, приватные контуры и прочую красоту. А это – выстрел мимо. В этот момент ваш визави думает не о вашей архитектуре. Он думает о трёх вещах.

Во-первых, не прилетит ли ему потом за согласование.
Во-вторых, можно ли это запретить сразу, не разбираясь.
В-третьих, нельзя ли переложить решение выше, чтобы оно перестало быть его проблемой.

И пока вы этого не поняли, вы будете безуспешно штурмовать бетон лбом.

Поэтому первая полезная мысль звучит грубо, но честно: с безопасниками надо говорить не о «пользе ИИ», а об управляемости риска.

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

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

Если говорить совсем по-взрослому, у вас две стратегии.

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

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

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

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

#ИИ #корпоративнаябезопасность