«Модель этого не отвечала» — слабая позиция после инцидента. Корпоративному AI-шлюзу нужен проверяемый след каждого запроса: кто получил доступ, какая политика сработала, что ушло модели и что вернулось клиенту. Панель облачного провайдера не заменяет доказательство, которое вы можете проверить самостоятельно. На входе — авторизация и локальная PII-санитизация. Для исходного и очищенного промпта считаем отдельные HMAC; фиксируем request_id, маршрут, идентификатор артефакта модели и версию политики. Ответ связываем с запросом через канонический формат события и хеш предыдущей записи. Корни пакетов подписываем ключом в отдельном контуре и выносим независимому хранителю. Одна хеш-цепочка не защищает от незаметного удаления хвоста. Для строгого аудита подтверждаем запись запроса до инференса, ответа — до выдачи клиенту. Стриминг требует фиксации каждого выдаваемого блока либо буферизации. Измеряем p99 задержки аудита, долю запросов с полной цепочкой и отставание внешнего закрепления. HMAC позволяет сверить предъявленное содержимое, но не восстановить его: если нужен разбор текста, храним его отдельно, зашифрованным, с ограниченным сроком и доступом. Экономику считаем без фокусов: при условных 10 млн событий в сутки и 1 КБ на событие получаем около 10 ГБ/сутки, 300 ГБ за 30 дней до репликации и индексов. На своём железе оплачиваем диски, подпись и эксплуатацию; в облаке дополнительно учитываем тарифы записи, хранения и выгрузки доказательств. Подпись доказывает целостность записи, а не истинность ответа модели. Архитектура под вашим контролем: https://run-as-daemon.dev/?utm_source=telegram&utm_medium=smm&utm_campaign=rad_ru&utm_content=arhitektura-korporativnogo-ai-shlyuza
