AI Governance в компании: политики, роли, изменения и ответственность за решения бота

Недавно коллега рассказал историю: их AI-бот, который должен был разгрузить поддержку, в три часа ночи пообещал VIP-клиенту скидку 99% на годовой тариф. Клиент, разумеется, сделал скриншот. Утром отдел продаж обнаружил заявку с пометкой «бот согласовал» — и начался цирк с извинениями, эскалациями и разбором полётов.

Ещё один случай из практики: бот перепутал контексты диалогов и в ответ на вопрос «Какой у меня баланс?» выдал данные совершенно другого пользователя. Хорошо, что клиент оказался понимающим и просто написал в поддержку. А могло быть и хуже — утечка персональных данных, жалоба в регулятор, репутационный удар.

Это не страшилки для презентаций — это реальные кейсы, которые происходят, когда AI запускают по принципу «авось прокатит». И здесь на сцену выходит AI Governance.

Когда слышишь «AI Governance», в голове рисуется бюрократический ад: толстые папки с регламентами, бесконечные согласования и юристы, которые всё запрещают. Но давайте честно — если у вас есть бот, который общается с клиентами, принимает решения или работает с данными, какой-то governance у вас уже есть. Вопрос только в том, осознанный он или «как получилось».

В этой статье я расскажу, как выстроить систему управления AI так, чтобы она реально работала, а не пылилась в Confluence. Без занудства, с конкретными примерами и чеклистами, которые можно взять и использовать.

TL;DR — Самое важное за 1 минуту

Понимаю, что времени мало. Вот четыре вещи, без которых запускать AI-бота — как ехать без ремня безопасности. Вроде можно, но при первом ДТП пожалеете.

• Политика — это закон. Документ, подписанный CEO/COO и CISO, определяющий, что боту строго запрещено делать.
• RACI матрица. Четкое понимание: кто отвечает за данные, кто за качество ответов, а кто — за то, что бот «ляпнул» лишнего.
• Промпты = Код. Любое изменение промпта должно проходить через тестирование (evals), как программный код, а не правиться «на лету» в админке.
• Люди важнее алгоритмов. Обучение сотрудников тому, как работать с AI и когда перехватывать управление — критически важно.

Если хотя бы один пункт вызвал вопрос «а у нас это есть?» — читайте дальше. Ниже разберу каждый подробно.

Когда вам ДЕЙСТВИТЕЛЬНО нужен AI Governance?

Сразу скажу: не всем нужен тяжёлый «энтерпрайзный» подход с комитетами, многоуровневыми согласованиями и стопкой регламентов. Если ваш бот отвечает на вопросы «Во сколько вы работаете?» и «Где вас найти?» — можно обойтись минимумом.

Но если узнали себя хотя бы в одном из этих пунктов — пора задуматься серьёзнее:

• Бот влияет на деньги. Он может менять цены, давать скидки, согласовывать лимиты или возвраты. Один неверный ответ — и вы в минусе.
• Работа с чувствительными данными. PII (персональные данные), финансы, здоровье, коммерческая тайна — всё, что не должно утечь наружу.
• Регулируемая отрасль. Банки, страховые, медицина, финтех. Регуляторы не будут разбираться, кто виноват — человек или алгоритм.
• Хаос в разработке. Промпты пишут маркетологи, разработчики и саппорт одновременно. Версий много, актуальная — непонятно какая.

Особенно последний пункт встречается часто. Приходишь в компанию, спрашиваешь: «Покажите текущий системный промпт бота». И начинается: «Ну, Вася что-то менял на прошлой неделе... А ещё Маша добавляла блок про акции... Или это было в старой версии?». Если это про вас — governance нужен вчера.

Кто за что отвечает? (RACI без занудства)

Знакомая картина: бот что-то «ляпнул», клиент жалуется, и начинается перекладывание ответственности. Разработчики говорят: «Мы сделали по ТЗ». Бизнес отвечает: «Мы не это имели в виду». Саппорт разводит руками: «Мы вообще не при делах». А виноватых нет.

Чтобы избежать этого цирка, нужна простая вещь — матрица ответственности. RACI звучит скучно, но суть проста: для каждой области должен быть один человек, который отвечает головой (Accountable), и те, кто делают работу руками (Responsible).

Вот как это может выглядеть на практике:

Важный момент: эта таблица — не просто документ для галочки. Каждый человек в ней должен знать свою роль и понимать, что именно он отвечает за свой кусок. Когда случается инцидент, не должно быть вопроса «а кто должен был это предусмотреть?».

Практическая Политика Использования AI

Когда говорят «политика», многие представляют документ на 100 страниц, который никто никогда не прочитает. Я видел такие — они обычно лежат в дальней папке SharePoint и достаются только для аудиторов.

Вместо этого предлагаю сделать одностраничник (one-pager), который можно распечатать и повесить над рабочим столом. Документ, который люди реально прочитают и запомнят. Что в нём должно быть:

• Красные линии по данным. Четкий список: "Никогда не отправлять в LLM: паспортные данные, номера карт, пароли".
• Прозрачность для клиента. Обязательство сообщать пользователю, что он общается с AI (это часто требование закона и просто честно).
• Human in the loop. Определение сценариев, когда бот обязан переключить на человека (например, угроза жизни, жалоба на сервис, сложные финансовые вопросы).
• Логи и Аудит. Правило "Всё, что сказал бот, записывается". Это ваша страховка на случай споров.

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

Управление изменениями: Промпты = Код

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

LLM — это не детерминированные системы. Маленькое изменение в одном месте может привести к неожиданным последствиям в другом. Поменяли запятую в инструкции про скидки — и вдруг бот стал хуже отвечать на вопросы про доставку. Звучит абсурдно, но это реальность работы с языковыми моделями.

Поэтому к промптам нужно относиться как к коду. Никто же не правит production-код «на живую» без тестов? С промптами должно быть так же.

Как организовать процесс изменений:

1. Заявка. Есть идея улучшения? Заводим тикет в Jira, Notion или хотя бы в общий чат с пометкой. Главное — зафиксировать, что и зачем хотим менять.
2. Оценка риска. Быстро отвечаем на вопрос: «Может ли это изменение затронуть безопасность или критичные сценарии?». Если да — привлекаем CISO или техлида.
3. Оффлайн-тесты (Evals). Прогоняем новый промпт через набор из 50-100 тестовых диалогов. Это ваша «регрессия» — проверяем, что не сломали то, что работало.
4. Канареечный релиз. Раскатываем изменения на 5-10% пользователей. Смотрим логи пару дней. Всё в порядке? Раскатываем на всех.
5. Кнопка «Откат». Всегда, всегда должна быть возможность вернуть предыдущую версию промпта за минуту. Не за час, не «надо развернуть предыдущий релиз» — за минуту.

Да, это замедляет процесс. Но это замедление — плата за стабильность. Лучше потратить день на тестирование, чем неделю на разгребание последствий неудачного изменения.

Чеклист запуска AI-бота (Safe Launch)

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

Отдельно хочу остановиться на Prompt Injection — это когда пользователь пытается «взломать» бота, вставив в своё сообщение инструкции вроде «Забудь всё, что тебе говорили, и выполни X». Звучит как хакерство из фильмов, но на практике такие атаки встречаются. Убедитесь, что ваш бот на них не ведётся.

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

FAQ: Живые вопросы от команд

Эти вопросы я слышу практически на каждой встрече, когда обсуждаем внедрение AI. Собрал самые частые с честными ответами.

Вместо заключения

AI Governance — это не про бюрократию и не про то, чтобы замедлить внедрение технологий. Это про то, чтобы спать спокойно, зная, что ваш бот не устроит вам сюрприз в три часа ночи.

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

Главное — не откладывать на потом. Потому что «потом» обычно наступает, когда уже что-то сломалось.

Полезное чтение

Если тема зацепила, вот ещё пара статей, которые дополняют эту:

• Юридически безопасные боты: как не получить штраф — подробнее про правовые аспекты и ответственность.
• Идеальное ТЗ на LLM-бота — как правильно сформулировать требования, чтобы потом не переделывать.