Как ИИ проходит проверку при закупке: доверие — это реестр
Со 2 августа 2025 года любой поставщик модели общего назначения (GPAI), которая выходит на рынок ЕС, обязан публиковать сводку данных, на которых модель обучалась. Это документ, который юрист заказчика вправе у вас запросить, — и он у вас либо есть, либо нет.
Решение о том, купят ли ваш ИИ, всё чаще уходит от бизнес-спонсора к службе безопасности и юристам заказчика. Намерения их не интересуют. Я сам строю системы, за которые отвечаю: у меня работает самодельный MCP-хаб, который отдаёт управляемые коммерческие датасеты ИИ-ассистентам, — поэтому знаю эту проверку со стороны поставщика: видел, какие вопросы останавливают сделку и на какие хорошо построенная система отвечает раньше, чем их успели задать. Картина каждый раз одна и та же: управление ИИ (AI governance), которое можно показать, — коммерческий актив; то, о котором можно только рассказать, тормозит сделку.
Что на самом деле нужно, чтобы закупку ИИ согласовали?
Доказательства. Проверка службы безопасности закрывается, когда реестр можно показать по первому запросу: какие модели работают, откуда пришли данные, что тестировали, что попадает в журнал, кто вправе отменить решение машины. Слайд о том, что вы «серьёзно относитесь к ИИ», эту проверку не закроет: такой читатель верит только документам.
Сместилась сама точка решения: раньше сделку двигал бизнес-спонсор, теперь последнее слово за проверяющим. Спонсору нужен результат, проверяющему — доказательства. Недостающий документ — это редко жёсткое «нет», чаще «подождите». А на этом «подождите» сделки и вязнут: кто-то собирает бумаги, которые должны были лежать наготове.
При этом отраслевые ассоциации уже раздали заказчикам готовые вопросы. Например, ISACA рекомендует закупщикам запрашивать у вендора SBOM (перечень программных компонентов) и его ИИ-аналог AIBOM, «пакет прозрачности» — документацию, источники обучающих данных, зависимости, — а также закреплять «явные права на аудит, чтобы самим проверять справедливость, качество работы и безопасность, а не верить вендору на слово». Этот опросник уже лежит на столе у заказчика.
Почему доверие к ИИ стало критерием покупки в 2026-м?
Потому что подошли сроки — и аналитики дали явлению имя. Европейский регламент об ИИ (EU AI Act) вступает в силу поэтапно, заказчики уже перенесли его вопросы в свои закупочные анкеты, а аналитические агентства превратили «доверие к ИИ» из строчки в бюджете на комплаенс в критерий выбора поставщика.
Этапность здесь важна. Запреты и требования к ИИ-грамотности действуют со 2 февраля 2025 года, обязательства для моделей общего назначения — со 2 августа 2025-го, а большая часть регламента включается 2 августа 2026 года. Дату для высокорисковых систем — ту самую, которую все обвели в календаре, — сдвинули. В июле 2026 года пакет упрощений Digital Omnibus вступил в силу и отложил обязательства для высокорисковых систем: автономные — на 2 декабря 2027 года, встроенные в продукты — на 2 августа 2028-го. Отсрочка реальная. Тем не менее это дата, а не амнистия.
Аналитики тем временем сделали из доверия рынок. Gartner дал категории имя — AI TRiSM, trust, risk and security management (доверие, риски и безопасность ИИ) — и выпустил по ней Market Guide, руководство для покупателя.
Forrester называет 2026-й годом, когда B2B-закупки перейдут на принцип «доказательства вместо обещаний», и прогнозирует, что генеративный ИИ, оставленный без управления, уничтожит более $10 млрд корпоративной стоимости — инцидентами, выплатами по искам и штрафами. Опрос McKinsey указывает туда же: среди примерно 500 организаций те, у кого управление ИИ закреплено за назначенным владельцем, заметно опережают по зрелости ответственного ИИ тех, у кого владельца нет.
Что входит в реестр?
Семь позиций — и заказчики уже спрашивают о каждой прямым текстом. Наложите требования AI Act к высокорисковым системам на то, что запрашивают службы безопасности и отраслевые ассоциации, — списки сойдутся в один и тот же реестр:
- Инвентаризация ИИ-систем — каждая модель и каждый ИИ-сервис в работе: поставщик, версия, хостинг.
- Классификация по риску — какие из решений высокорисковые; зафиксировано заранее, а не посреди спора.
- Происхождение данных (data lineage) — откуда пришли данные для обучения и дообучения и под какой они лицензией.
- Результаты оценок — что тестировали, включая prompt injection и утечку данных, и что при этом сломалось.
- Журналирование — аудиторский след, по которому можно восстановить, что система сделала.
- Человек в контуре — право отмены, которое реально срабатывает, а не живёт на слайде.
- Подтверждения вендора — перечни компонентов, сертификаты и права на аудит, по которым первые шесть пунктов может проверить кто-то со стороны.
Каждый пункт отвечает на вопрос, который заказчика уже научили задавать, — и у каждого есть норма или практика, где он закреплён:
| Что спрашивает заказчик | Чем отвечаете | Где закреплено |
|---|---|---|
| Какие здесь модели и чьи? | Инвентаризация ИИ-систем | AI-SBOM (CISA + G7); ISO/IEC 42001 |
| Откуда обучающие данные? | Происхождение данных | AI Act, ст. 10; сводка обучающих данных GPAI (ст. 53) |
| Насколько рискованно это решение? | Классификация по риску | Классификация AI Act (Приложение III) |
| Что тестировали и что сломалось? | Результаты оценок | NIST AI RMF (Measure); карточки моделей |
| Можете восстановить, что система сделала? | Журналы / аудиторский след | AI Act, ст. 12 |
| Человек может её остановить? | Право отмены, человек в контуре | AI Act, ст. 14 |
| Почему я должен верить вам на слово? | Подтверждения вендора | Рекомендации ISACA; ISO/IEC 42001 |
Ничего экзотического здесь нет. Контроли AI Act для высокорисковых систем — это статьи 9–15: система управления рисками, управление данными, техническая документация, журналирование, прозрачность для тех, кто внедряет систему, надзор человека, точность и устойчивость. Сама инвентаризация теперь описана на уровне государств: CISA с партнёрами по G7 опубликовала минимальные элементы ИИ-версии перечня компонентов — семь кластеров. Даже карточки моделей (model cards), самый скромный пункт списка, восходят к исследовательской статье 2019 года. Реестр — это документальный след аккуратно построенной системы; никакой новой повинности юристы здесь не придумали.
Встроить контроли — или платить за них при каждой сделке
Заложите контроли на этапе проектирования — и показать их ничего не стоит. Прикрутите задним числом — и платить будете при каждой сделке: контракт, по сути уже согласованный, стоит и ждёт, пока вы собираете ответы для службы безопасности. Контроли одни и те же, цены две: одну платят один раз, при проектировании, вторую — каждый раз, когда заказчик спрашивает, а вы к дедлайну собираете ответ.
Я знаю, какая из двух цен ниже, потому что сам строю системы, за которые отвечаю. В моём хабе данных инвентаризация, происхождение данных, журналирование и человек в контуре — это работающий код, а не PDF с политикой. Когда служба безопасности заказчика спрашивает, откуда взялась цифра, я открываю цепочку происхождения данных и показываю. Это и есть управление, встроенное при проектировании: реестр существует, потому что система построена так, чтобы его вести. Четырнадцать лет в регулируемой фарме довели эту привычку до рефлекса: в высокорисковой области управление модельными рисками, управление данными и надзор человека — условие выпуска продукта, слоем поверх них не приклеишь. И привычка переносится: подход AI Act к высокорисковым системам так же работает в финтехе, страховании и медтехе — везде, где у решения ИИ есть последствие, за которое кому-то придётся ответить.
Я уже писал, что расстояние от демо до внедрённой системы — это операционная модель. То была внутренняя сторона проблемы: почему пилот не доезжает до прода внутри вашей же компании. Здесь — внешняя: купит ли систему, которую вы всё-таки выпустили, заказчик, чьи юристы задают неудобные вопросы. Коммерческим системам с выстроенным управлением, которые я вёл, приходилось выдерживать и то и другое.
Не буду притворяться, что здесь есть цифра, которой нет. Ни один аналитик не опубликовал, как управление ИИ влияет на скорость сделки, а придумать такую цифру — значит сделать ровно то, против чего написан весь этот текст. При этом сам механизм известен, SOC 2 работает по нему уже десять лет: вендор, у которого документ готов к моменту запроса, проходит проверку быстрее вендора, который начинает собирать его после. Управление ИИ повторяет путь SOC 2: из разряда «хорошо бы иметь» — в обязательный минимум.
Реестр можно показать, а можно пообещать, что вы его ведёте. Проверку проходит только первое.
Отсрочка для высокорисковых систем — значит, можно выдохнуть?
Нет. Сдвинулась дата, а спрос никуда не делся. Большая часть AI Act всё равно применяется со 2 августа 2026 года, обязательства для моделей общего назначения действуют с августа 2025-го, а анкета службы безопасности заказчика не ждёт даты штрафов: она уже в RFP (запросе предложений).
Digital Omnibus сдвинул срок, с которого правила для высокорисковых систем начнут применяться, но их содержания не тронул. Контроли статей 9–15 не изменились, поэтому компания, которая закупает ИИ-систему в 2026-м, всё равно спросит про происхождение данных, журналы и право отмены — действуют штрафы или ещё нет. Вендоры, которые продают регулируемым заказчикам, уже считают реестр входным условием: планку задал заказчик, не дожидаясь регуляторного календаря. Ждать, когда включатся штрафы, — значит подстраиваться под регулятора и не замечать того, кто на самом деле решает, состоится ли покупка.
Разве это всё не комплаенс для галочки?
Для галочки получается, только если вместо реестра вы показываете декларацию. Критерий простой: чужая служба безопасности должна суметь проверить ваше утверждение, не веря вам на слово. Декларация ценностей проваливает эту проверку в ту же минуту, когда просят показать документ, который за ней стоит.
Убедительный разговор о доверии в 2026 году — это не «мы этичны». Это «вот инвентаризация, вот откуда данные, вот что тестировали, вот журнал, вот кто может остановить, вот права на аудит». ISO/IEC 42001 ровно для этого и существует — чтобы такое утверждение можно было проверить: добровольный стандарт, по которому сертифицируют систему управления ИИ в организации, а не отдельную модель. Вендоры от AWS до Anthropic и KPMG сертифицируются, потому что заказчики начали спрашивать. Стандарт просят, но пока не требуют — так критерий покупки выглядит в то короткое окно, пока стандарт не стал обязательным минимумом.
С чего начать: превратить управление в коммерческий актив
Реестр — побочный продукт правильно построенной системы: комплаенсу остаётся его распечатать. Четыре шага, по порядку:
- Постройте инвентаризацию так, чтобы её вела сама система. Не таблица, которую кто-то обновляет руками: система сама знает, какие модели запускает, откуда её данные и что записано в журнал, — и выдаёт это по запросу.
- Вшейте прослеживание происхождения данных, журналирование и право отмены в саму систему. Именно их служба безопасности запрашивает в первую очередь; сделайте так, чтобы они доставались одним запросом к системе, а не раскопками по переписке и папкам.
- Держите подтверждения для заказчика наготове. Карточки моделей, AIBOM и, где уместно, внятный ответ про ISO/IEC 42001 — чтобы вывод «этот вендор серьёзен» заказчик делал по готовым документам, без долгой переписки.
- Привяжите контроли к статьям регламента. Требования к высокорисковым системам — статьи 9–15 — это чек-лист, по которому заказчики уже сверяются; стройте под него, и один комплект свидетельств закроет вопросы и регулятора, и заказчика.
Сделайте это — и управление перестанет тормозить продажу и начнёт её закрывать: вопросы службы безопасности снимаются показом документов, а не долгой перепиской.
Вшить всё это в то, как команда строит, документирует и продаёт, — работа над операционной моделью, которой я занимаюсь; той же дисциплины требует и проблема управления агентами, о которой я уже писал. Если принципов у вашего ИИ много, а реестра нет — начните с инвентаризации.