AI governance для компании: кто отвечает за нейросети, данные, риски и качество ответов

Пока нейросеть живёт в личной вкладке браузера, она кажется обычным рабочим инструментом — примерно как переводчик или поисковик. Сотрудники готовят с её помощью письма, анализируют документы, пишут код и отвечают клиентам. Но однажды выясняется, что в публичный AI-сервис уже отправляли договоры, выгрузки из CRM, фрагменты исходного кода и внутренние финансовые отчёты.

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

Для решения этих задач нужен AI governance — система управления искусственным интеллектом внутри организации.

Что такое AI governance простыми словами

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

Хорошая система управления отвечает как минимум на семь вопросов

• какие AI-инструменты разрешены

• для каких рабочих задач их можно использовать

• какие данные запрещено передавать модели

• кто отвечает за конкретный AI-сценарий

• как проверяется качество ответов

• как контролируются внешние поставщики

• что происходит при ошибке, жалобе или инциденте.

AI governance часто переводят как «управление ИИ». Формулировка точная, но немного сухая. На практике это скорее операционная система для корпоративного AI.

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

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

Задача governance — не остановить использование нейросетей, а сделать его контролируемым.

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

Самая распространённая корпоративная политика в отношении AI умещается в одну фразу: «Нейросетями пользоваться можно, но ничего конфиденциального туда не вставляйте».

Проблема в том, что понятие «конфиденциальное» каждый понимает по-своему.

Менеджер может считать коммерческое предложение обычным рабочим документом. Разработчик — воспринимать логи приложения как безобидный технический текст. Сотрудник поддержки — не замечать, что в обращении клиента есть имя, телефон, номер заказа и платёжная информация.

Никто не пытается намеренно нарушить правила. Люди просто хотят быстрее решить задачу.

Есть и другие риски.

Теневое использование AI

Отдел маркетинга подключает один сервис, разработчики — второй, HR — третий. Оплата проходит с личных карт или через корпоративные расходы, а централизованного списка инструментов нет.

Через несколько месяцев компания не может точно ответить, какие поставщики обрабатывают её данные.

Ошибочные ответы

Нейросеть уверенно придумывает несуществующий пункт договора, неправильно рассчитывает скидку или ссылается на устаревшую инструкцию.

Если сотрудник воспринимает такой ответ как готовое решение, ошибка уходит дальше — клиенту, партнёру или руководителю.

Неконтролируемые изменения у поставщика

Провайдер обновляет модель, меняет настройки хранения данных или подключает нового субподрядчика. Качество ответов меняется, хотя внутри компании никто ничего не перенастраивал.

Размытая ответственность

Когда происходит инцидент, начинается знакомый разговор:

— Бизнес использовал инструмент, значит отвечает бизнес.
— Доступ настроила IT-команда, значит отвечает IT.
— В документе были персональные данные, значит отвечает юрист или специалист по приватности.
— Модель принадлежит поставщику, значит виноват поставщик.

Если зона ответственности не определена заранее, после инцидента найти владельца решения почти невозможно.

NIST AI RMF: удобный каркас для управления рисками

Разрабатывать систему AI governance с чистого листа необязательно. Одной из практических основ может стать AI Risk Management Framework от Национального института стандартов и технологий США — NIST.

AI RMF 1.0 был опубликован в январе 2023 года. Это добровольный, отраслево-независимый и не привязанный к конкретному сценарию фреймворк, предназначенный для организаций, которые создают, внедряют или используют AI-системы.

В основе фреймворка находятся четыре функции

• Govern — установить правила, роли и ответственность

• Map — понять контекст использования и возможные последствия

• Measure — оценить качество и риски

• Manage — принять решения о снижении, принятии или контроле рисков.

Эти функции не стоит воспринимать как четыре последовательных этапа, после которых проект можно считать завершённым. Скорее это непрерывный цикл.

Сначала компания определяет правила. Затем описывает конкретный сценарий, измеряет его риски, внедряет защитные меры и возвращается к оценке после обновления модели, данных или бизнес-процесса. NIST также выпускает практический Playbook с предлагаемыми действиями для каждой из четырёх функций.

В июле 2024 года NIST выпустил отдельный профиль AI RMF для генеративного искусственного интеллекта. Он дополняет базовый фреймворк и помогает учитывать риски, характерные именно для генеративных моделей: недостоверные ответы, утечки, вредоносный контент, информационную целостность и сложности с оценкой качества.

Для бизнеса ценность NIST AI RMF не в том, чтобы выполнить каждый пункт документа. Фреймворк даёт язык, на котором могут разговаривать руководители, разработчики, безопасники, юристы и владельцы процессов.

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

Кто должен отвечать за AI в компании

Назначить одного «ответственного за весь искусственный интеллект» звучит удобно, но редко работает.

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

Рабочий принцип выглядит иначе:

У каждого AI-сценария должен быть один владелец, но ответственность за отдельные риски распределяется между профильными ролями.

В небольшой компании несколько ролей может совмещать один сотрудник. Например, технический директор одновременно выступает владельцем AI-платформы и исполнительным спонсором. Это нормально.

Совмещать можно должности. Нельзя оставлять функции без владельца.

Исполнительный спонсор

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

Исполнительный спонсор

• утверждает общие принципы использования AI

• определяет допустимый уровень риска

• разрешает спорные и высокорисковые сценарии

• выделяет бюджет на инфраструктуру, безопасность и обучение

• снимает конфликты между подразделениями.

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

AI governance committee

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

В неё обычно входят представители

• бизнеса

• IT или AI-платформы

• информационной безопасности

• юридической функции

• управления данными

• внутреннего контроля или качества.

Комитет утверждает категории риска, рассматривает сложные сценарии, разрешает исключения и контролирует выполнение программы.

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

Владелец бизнес-сценария

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

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

Он отвечает за

• цель внедрения

• требования к результату

• допустимые ошибки

• организацию проверки ответов

• обучение пользователей

• экономический эффект

• решение о продолжении или остановке проекта.

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

Владелец данных

Владелец данных определяет, какие источники можно подключать к AI и на каких условиях.

Он отвечает на практические вопросы

• можно ли использовать конкретную базу документов

• какие поля нужно удалить или обезличить

• кто имеет право видеть информацию

• как долго она должна храниться

• какие документы считаются актуальными

• кто отвечает за исправление ошибок в базе знаний.

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

AI очень быстро масштабирует не только знания, но и беспорядок в данных.

Информационная безопасность

Специалисты по информационной безопасности оценивают, как AI-система может быть использована для утечки, обхода прав доступа или получения нежелательных действий.

В их зоне ответственности находятся

• аутентификация и авторизация

• сетевые ограничения

• защита API и ключей

• разделение сред

• мониторинг подозрительной активности

• фильтрация запросов

• управление уязвимостями

• реагирование на инциденты

• защита журналов и резервных копий.

ИБ не должна в одиночку решать, разрешать ли бизнесу конкретный сценарий. Её роль — описать угрозы и необходимые меры защиты.

Финальное решение принимается с учётом пользы, стоимости контроля и остаточного риска.

Юристы, комплаенс и специалисты по приватности

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

Особое внимание требуется, когда AI работает с

• персональными данными

• медицинской или финансовой информацией

• кадровыми решениями

• интеллектуальной собственностью

• материалами клиентов

• юридически значимыми рекомендациями

• автоматизированными решениями, влияющими на людей.

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

Владелец AI-платформы или модели

Техническая команда отвечает за эксплуатацию системы

• выбор и настройку моделей

• интеграцию с корпоративными сервисами

• управление версиями

• производительность

• доступность

• технические тесты

• логирование

• обновления

• откат изменений

• контроль затрат.

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

Внутренний аудит или независимый контроль

Команда, которая разработала AI-систему, не должна быть единственным источником информации о её надёжности.

Внутренний аудит, риск-функция или независимая группа контроля проверяет

• соблюдаются ли утверждённые правила

• соответствует ли фактическое использование заявленному

• действуют ли защитные меры

• можно ли воспроизвести результаты тестирования

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

• не используются ли неразрешённые модели.

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

Матрица ответственности: кто принимает решения

Для каждого AI-сценария полезно составить простую таблицу ответственности.

Главное — избегать формулировки «отвечают все участники». Обычно она означает, что в критический момент не отвечает никто.

Какие политики нужны компании

Политика AI не должна быть энциклопедией на сто страниц. Сотруднику нужен понятный документ, в котором легко найти ответ на конкретный вопрос.

Минимальный пакет можно собрать из нескольких взаимосвязанных правил.

Политика допустимого использования

Она объясняет, для каких задач сотрудники могут применять AI.

Например, без дополнительного согласования можно

• составлять черновики общих текстов

• улучшать структуру публичных материалов

• генерировать идеи

• переводить несекретный контент

• объяснять общедоступную информацию

• создавать тестовые данные, не связанные с реальными людьми.

Отдельного согласования могут требовать

• анализ клиентских документов

• работа с внутренними базами

• генерация программного кода для продакшена

• подготовка юридических или финансовых рекомендаций

• автоматическое общение с клиентами

• принятие решений о сотрудниках.

А некоторые действия следует запретить полностью. Например, передавать нейросети пароли, закрытые ключи, платёжные реквизиты или использовать её ответ как единственное основание для увольнения сотрудника.

Политика работы с данными

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

Обычно к ним относятся

• персональные данные клиентов и сотрудников

• платёжная информация

• медицинские сведения

• коммерческая тайна

• неопубликованные финансовые показатели

• договоры с закрытыми условиями

• исходный код критичных систем

• API-ключи, пароли и токены

• схемы внутренней инфраструктуры

• данные, переданные клиентом с ограничениями

• материалы судебных и внутренних расследований.

Для каждой категории устанавливается режим обработки.

Публичные данные можно использовать в разрешённых сервисах. Внутренние данные — только в корпоративных аккаунтах. Конфиденциальные данные — в изолированной среде после согласования. Секреты доступа не должны передаваться модели ни при каких условиях.

Политика человеческой проверки

Не все ответы AI требуют одинакового контроля.

Черновик поздравления можно просмотреть бегло. Ответ клиенту о возврате денег должен проверить сотрудник поддержки. Финансовый расчёт — профильный специалист. Юридическое заключение — юрист.

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

Чем сильнее ответ влияет на деньги, права, здоровье, безопасность или репутацию, тем меньше автономии можно отдавать модели.

Политика журналирования

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

Поэтому заранее определяются

• какие события записываются

• сохраняется ли полный запрос

• маскируются ли персональные данные и секреты

• кто может читать журналы

• сколько времени они хранятся

• где находятся резервные копии

• как выполняется удаление.

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

Политика управления инцидентами

AI-инцидент — это не только взлом.

Инцидентом может считаться

• передача запрещённых данных внешнему сервису

• массовая выдача неверных ответов

• раскрытие документа пользователю без нужных прав

• генерация оскорбительного или дискриминационного контента

• несанкционированное изменение модели

• использование неутверждённого AI-сервиса

• неожиданное изменение поведения после обновления

• нарушение договорных условий поставщиком.

Сотрудник должен знать, куда сообщить о проблеме. Команда — кто принимает решение об ограничении доступа или остановке системы. Руководство — кто оценивает последствия и уведомляет заинтересованные стороны.

Реестр AI-систем: нельзя управлять тем, чего не видно

Первый практический инструмент AI governance — не сложная платформа, а обычный реестр.

В него включают не только собственные модели, но и все сервисы, где искусственный интеллект влияет на рабочий процесс

• корпоративные чат-боты

• AI-функции в CRM

• помощники программистов

• сервисы расшифровки звонков

• системы анализа кандидатов

• генераторы изображений

• автоматическую классификацию обращений

• функции AI, встроенные в офисные приложения

• API внешних моделей

• локально развёрнутые модели.

Для каждой записи желательно указать

• название системы

• бизнес-владельца

• технического владельца

• поставщика

• цель использования

• категории данных

• группы пользователей

• уровень риска

• версию модели

• место обработки и хранения

• дату последней оценки

• дату следующего пересмотра

• связанные инциденты

• статус: пилот, промышленная эксплуатация, приостановлена или выведена.

Представим, что отдел продаж использует функцию AI-резюме встреч, встроенную в CRM. Сотрудники могут даже не считать её отдельной нейросетью. Но сервис получает записи разговоров, имена клиентов, коммерческие условия и планы сделок.

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

Каталог разрешённых моделей

Компании редко нужна одна универсальная модель для всех задач. Гораздо практичнее создать каталог разрешённых инструментов с понятными условиями применения.

Каталог может включать четыре типа среды.

Публичные AI-сервисы

Подходят для открытой информации, идей, общих текстов и задач без корпоративных данных.

Доступ к ним можно разрешить при условии, что сотрудники используют личную или общедоступную информацию и не передают внутренние материалы.

Корпоративные SaaS-сервисы

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

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

AI через корпоративный API-шлюз

Запросы к одной или нескольким внешним моделям идут через инфраструктуру компании.

Шлюз позволяет

• управлять ключами

• ограничивать модели

• маскировать данные

• применять лимиты

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

• распределять трафик

• вести единый аудит

• отключать поставщика без изменения всех приложений.

Локальная или выделенная модель

Модель запускается в изолированном контуре, на собственных или арендованных выделенных серверах.

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

Самостоятельное размещение не делает систему безопасной автоматически. Неправильно настроенный локальный сервис может быть опаснее зрелой корпоративной платформы.

Как оценивать поставщиков AI

Проверка поставщика не должна ограничиваться вопросом: «Используете ли вы наши данные для обучения?»

Это важный пункт, но далеко не единственный.

Обработка данных

Нужно выяснить

• какие данные получает поставщик

• для каких целей он их использует

• сохраняются ли запросы и ответы

• каков срок хранения

• можно ли отключить хранение

• выполняется ли удаление из резервных копий

• используются ли данные для обучения или оценки моделей

• где физически и юридически происходит обработка.

Субподрядчики

У AI-сервиса может быть собственная цепочка поставщиков: облачная платформа, разработчик модели, сервис мониторинга, система модерации.

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

Информационная безопасность

Оцениваются

• шифрование

• изоляция клиентов

• управление доступом

• многофакторная аутентификация

• журналы административных действий

• тестирование безопасности

• управление уязвимостями

• порядок уведомления об инцидентах

• доступные отчёты независимых проверок.

Управление изменениями

Модель может обновиться без изменения названия продукта.

Поэтому важно определить

• предупреждает ли поставщик о крупных обновлениях

• можно ли зафиксировать версию

• доступен ли период тестирования

• можно ли временно вернуться к предыдущей версии

• как публикуются изменения в ограничениях и поведении модели.

Качество и ответственность

В договоре и технической документации стоит проверить

• какие показатели доступности гарантируются

• какие ограничения прямо заявлены

• кому принадлежат входные и выходные данные

• как рассматриваются претензии

• предоставляется ли поддержка

• может ли компания экспортировать данные и журналы

• что произойдёт после расторжения договора.

План выхода

Поставщика выбирают не навсегда.

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

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

Как запретить передачу чувствительных данных на практике

Политика, которую невозможно технически выполнить, постепенно превращается в пожелание.

Поэтому организационные правила нужно поддерживать техническими мерами.

Единый корпоративный доступ

Вместо десятков личных аккаунтов сотрудникам предоставляют утверждённый интерфейс или набор корпоративных сервисов.

Так компания может отключать пользователей, управлять ролями и применять единые настройки.

AI-шлюз

Централизованный шлюз позволяет проверять запрос до отправки модели.

Например, он может обнаружить

• номера банковских карт

• паспортные данные

• токены и ключи

• внутренние домены

• фрагменты исходного кода

• документы с определённой меткой конфиденциальности.

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

Минимизация данных

Модели редко нужен весь документ.

Для классификации обращения может быть достаточно темы и обезличенного текста. Для составления ответа — описания проблемы без имени клиента и номера договора. Для поиска ошибки — небольшого фрагмента кода без конфигурации окружения.

Чем меньше данных передаётся, тем меньше последствий у возможной ошибки.

Псевдонимизация и маскирование

Имена заменяются идентификаторами, номера — частично скрываются, секреты удаляются до отправки.

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

Доступ к базе знаний с учётом прав

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

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

Сотрудник отдела продаж не должен получать HR-документы. Подрядчик — внутренние финансовые инструкции. Стажёр — полную схему производственной инфраструктуры.

Контроль доступа должен работать до передачи контекста модели.

Как контролировать качество ответов

Оценивать AI фразой «отвечает неплохо» нельзя.

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

Сначала определить допустимый результат

Для каждого сценария нужно описать

• что считается правильным ответом

• какие ошибки допустимы

• какие ошибки критичны

• когда модель должна отказаться от ответа

• требуется ли ссылка на источник

• должен ли результат проверяться человеком

• сколько времени может занимать обработка

• какая стоимость запроса приемлема.

Например, внутренний помощник по отпускной политике должен ссылаться на действующий регламент и не отвечать по памяти, если источник не найден.

Генератор идей для рекламной кампании может работать свободнее: его результат всё равно проходит редактуру.

Создать набор контрольных примеров

До запуска собирается тестовый набор из реальных или реалистичных вопросов.

В него включают

• обычные запросы

• неоднозначные формулировки

• вопросы без ответа в базе

• устаревшие данные

• конфликтующие документы

• попытки получить закрытую информацию

• запросы с ошибками

• провокационные инструкции

• пограничные сценарии.

Ответы оценивают профильные специалисты, а не только разработчики.

Если система предназначена для юристов, финальную оценку должны давать юристы. Если для поддержки — опытные сотрудники поддержки.

Использовать несколько метрик

В зависимости от сценария измеряют

• фактическую точность

• полноту

• соответствие источникам

• долю неподтверждённых утверждений

• корректность отказов

• соблюдение формата

• отсутствие запрещённого контента

• время ответа

• стоимость

• количество исправлений человеком

• долю обращений, решённых без повторного запроса.

Одна усреднённая оценка легко скрывает проблему.

Система может иметь точность 95%, но ошибаться именно в пяти процентах запросов, связанных с возвратом денег или изменением договора. Для бизнеса это будет важнее сотен правильных ответов на простые вопросы.

Установить критерии запуска

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

Например

• не менее 90% правильных ответов на типовые вопросы

• 100% блокировка тестовых запросов с ключами доступа

• обязательная ссылка на утверждённый документ

• отсутствие доступа к материалам других подразделений

• ручная проверка всех клиентских ответов

• возможность отключить систему за установленное время.

Если критерии не выполнены, проект остаётся пилотом.

Повторять тесты после изменений

Поведение системы может измениться после

• обновления модели

• изменения системного промпта

• подключения новых документов

• замены поискового алгоритма

• изменения фильтров

• обновления прав доступа

• перехода к другому поставщику.

Каждое значимое изменение должно запускать повторную проверку.

Новая версия не считается лучшей только потому, что у неё больше параметров или выше позиция в публичном рейтинге.

Риск-ориентированная классификация AI-сценариев

Чтобы не проверять генератор заголовков так же строго, как систему оценки кандидатов, сценарии делят по уровню риска.

Низкий риск

AI помогает подготовить черновик, но не получает чувствительные данные и не принимает решений.

Примеры

• идеи для публикаций

• форматирование текста

• перевод публичного материала

• генерация тестовых названий

• объяснение общедоступного кода.

Обычно достаточно разрешённого инструмента и базового обучения сотрудников.

Средний риск

Модель работает с внутренними данными или создаёт материалы, которые могут повлиять на клиента, но результат обязательно проверяет человек.

Примеры

• резюме внутренних встреч

• поиск по базе знаний

• черновики ответов поддержки

• анализ обезличенной обратной связи

• помощник программиста для некритичного кода.

Нужны оценка поставщика, контроль доступа, журналирование и тестирование качества.

Высокий риск

AI влияет на значимые решения, использует чувствительные данные или может причинить существенный финансовый, правовой либо репутационный ущерб.

Примеры

• кадровый отбор

• кредитные решения

• медицинские рекомендации

• юридически значимые заключения

• управление критичной инфраструктурой

• автоматические действия с деньгами

• клиентская коммуникация без проверки человеком.

Такие сценарии требуют формальной оценки риска, усиленного тестирования, независимого контроля и одобрения руководства.

Запрещённые сценарии

Компания может заранее определить случаи, когда AI использовать нельзя.

Например

• передача секретов доступа в публичные модели

• скрытое принятие решений о сотрудниках

• создание вводящих в заблуждение материалов от имени клиента

• обход установленных ограничений доступа

• использование неутверждённого сервиса для конфиденциальных данных

• автоматическая публикация юридических или финансовых рекомендаций без проверки.

Чёткий список запрещённых действий полезнее общей формулировки «используйте AI ответственно».

Аудит AI: какие доказательства должна хранить компания

На аудите недостаточно сказать: «Мы внимательно относимся к искусственному интеллекту».

Нужны подтверждения.

Для каждого значимого AI-сценария желательно сформировать пакет документов

• карточку системы

• описание цели и пользователей

• назначенных владельцев

• категории обрабатываемых данных

• оценку рисков

• результаты тестирования

• критерии приёмки

• решение о запуске

• описание человеческого контроля

• перечень поставщиков

• договорные гарантии

• сведения о версиях

• журналы изменений

• зарегистрированные инциденты

• план устранения проблем

• дату следующего пересмотра.

Аудит можно проводить с разной периодичностью.

Низкорисковые инструменты пересматриваются при существенном изменении или раз в год. Среднерисковые — чаще. Высокорисковые системы требуют постоянного мониторинга и регулярной независимой проверки.

Хороший аудит отвечает не только на вопрос «соблюдена ли политика», но и на более важный: работает ли контроль в реальности?

Можно выборочно проверить запросы, права пользователей, актуальность документов, обработку жалоб и фактическую версию модели.

ISO/IEC 42001: следующий уровень зрелости

Когда отдельные политики и проверки превращаются в постоянную корпоративную систему, полезным ориентиром может стать ISO/IEC 42001.

Стандарт описывает требования к созданию, внедрению, поддержанию и постоянному улучшению системы менеджмента искусственного интеллекта. Он применим как к организациям, которые разрабатывают AI, так и к компаниям, использующим AI-продукты и услуги.

Логика знакома компаниям, которые работали с системами менеджмента информационной безопасности или качества

• определить контекст

• назначить ответственность

• оценить риски

• установить контроль

• измерять результаты

• проводить внутренние проверки

• улучшать систему.

Сертификация нужна не каждой организации. Но сама структура помогает перейти от разовых AI-проектов к воспроизводимому процессу.

NIST AI RMF и ISO/IEC 42001 не обязательно противопоставлять. Первый удобно использовать как практическую модель управления рисками, второй — как основу системного менеджмента и постоянного улучшения.

Как внедрить AI governance за 90 дней

Необязательно ждать, пока компания разработает идеальную стратегию на несколько лет. Базовую систему можно построить поэтапно.

Первые 30 дней: увидеть реальное использование

На первом этапе нужно

• Найти используемые AI-инструменты.

• Определить владельцев основных сценариев.

• Составить предварительный реестр.

• Выделить чувствительные данные.

• Выпустить короткие временные правила.

• Запретить передачу паролей, ключей и критичных данных.

• Назначить точку контакта для вопросов и инцидентов.

Главная цель — убрать слепую зону.

Не стоит начинать с длинной политики, пока компания не знает, как сотрудники уже используют нейросети.

Дни 31–60: установить правила и допуски

На втором этапе

• Сценарии делятся по уровню риска.

• Формируется каталог разрешённых моделей.

• Определяются требования к поставщикам.

• Назначаются владельцы данных.

• Устанавливаются правила человеческой проверки.

• Создаются минимальные тестовые наборы.

Определяется порядок запуска новых AI-систем.

Сотрудники проходят короткое практическое обучение.

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

Дни 61–90: включить постоянный контроль

На третьем этапе

• Запускается регулярная рабочая группа.

• Настраивается централизованный доступ.

• Вводятся журналы и метрики.

• Проводится первая выборочная проверка.

• Уточняются договоры с ключевыми поставщиками.

• Создаётся процесс реагирования на AI-инциденты.

• Устанавливается календарь пересмотра систем.

• Руководство получает первый отчёт по рискам и эффекту.

Через 90 дней у компании может не быть идеальной программы. Зато уже появляются владельцы, правила, реестр и доказательства контроля.

Это намного ценнее презентации о «стратегии ответственного AI», за которой не стоит ни одного работающего процесса.

Типичные ошибки AI governance

Создать комитет без полномочий

Участники обсуждают риски, но не могут остановить запуск, потребовать тестирование или изменить договор с поставщиком.

Governance работает только тогда, когда решения обязательны.

Написать политику и забыть о ней

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

Политике нужны удобные разрешённые инструменты, обучение и технический контроль.

Полностью запретить публичные нейросети

Жёсткий запрет без безопасной альтернативы часто увеличивает теневое использование.

Сотрудникам нужен легальный способ решать реальные задачи. Иначе они найдут нелегальный.

Выбрать одну модель для всего

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

Каталог с несколькими утверждёнными вариантами обычно безопаснее и практичнее искусственной стандартизации.

Измерять только количество пользователей

Высокая активность ещё не означает пользу.

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

Проверить систему один раз

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

Новые данные, версии моделей и интеграции требуют повторной оценки.

Передать всю ответственность IT-команде

AI-проект может быть технически безупречным и при этом давать бизнесу неверный результат.

Ответственность за смысл и последствия остаётся у владельца процесса.

Как инфраструктура помогает реализовать governance

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

Изолированная корпоративная среда позволяет

• централизованно управлять доступом

• контролировать размещение данных

• фиксировать версии моделей

• разделять тестовую и рабочую среду

• ограничивать сетевые соединения

• хранить журналы внутри выбранного контура

• применять маскирование и фильтрацию

• организовать резервное копирование

• быстро отключать проблемные компоненты

• запускать собственные или открытые модели.

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

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

Но инфраструктура не заменяет governance.

Можно развернуть модель на собственном сервере и всё равно подключить к ней лишние документы, выдать всем одинаковые права или забыть проверить ответы.

Сервер — это фундамент. Кто строит дом, по каким правилам и кто принимает работу, решает организация.

Короткий чек-лист AI governance

Перед запуском корпоративной AI-системы проверьте

• Есть ли у сценария бизнес-владелец?

• Зарегистрирован ли инструмент в реестре?

• Определён ли уровень риска?

• Понятно ли, какие данные обрабатываются?

• Разрешено ли использовать эти данные?

• Проверен ли поставщик?

• Зафиксирована ли версия модели?

• Установлены ли права доступа?

• Есть ли тестовый набор?

• Определены ли критерии качества?

• Нужна ли проверка человеком?

• Настроены ли журналы?

• Маскируются ли чувствительные данные?

• Существует ли порядок реагирования на инцидент?

• Можно ли быстро остановить систему?

• Назначена ли дата следующего пересмотра?

• Есть ли план замены поставщика?

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

AI governance — это способ использовать нейросети смелее

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

Лучше построить базовую систему раньше.

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

NIST AI RMF предлагает удобную логику: управлять, понимать контекст, измерять и принимать решения. Корпоративные политики переводят эту логику на язык ежедневной работы. А техническая инфраструктура помогает сделать правила обязательными, а не рекомендательными.

Зрелая компания не пытается исключить все риски. Это невозможно.

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

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