Как вести реестр ИИ в вашей компании

Почему список идёт раньше всего остального

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

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

Решите, что считается, до того как начнёте считать

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

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

Найдите то, что уже работает

ИИ редко приходит через закупку, поэтому закупочные записи его не найдут. Авансовые отчёты и корпоративные карты вскрывают личные подписки. Логи удостоверений и SSO показывают, в какие сервисы люди входят. Исходящий трафик к известным доменам поставщиков ловит и санкционированные интеграции, и те, о которых никто не упомянул. Скан зависимостей по репозиториям находит SDK поставщиков, а поиск по шаблонам API-ключей в конфигурации — остальное.

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

Записывайте поля, делающие запись полезной

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

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

Держите реестр там же, где остальные учётные записи

Реестр в отдельной таблице ветшает, потому что ничто другое в организации на него не ссылается. Заводите записи там, где уже живут ваши системы учёта, — в каталоге сервисов, CMDB, реестре активов, — чтобы ИИ-система была системой с дополнительными атрибутами, а не записью в параллельной вселенной, которую поддерживает один человек, рано или поздно меняющий роль.

Сделайте это шагом на путях, порождающих ИИ

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

Считайте, что реестр ветшает, и заложите это в план

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

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