Агрегатор не должен выигрывать рейтинг, если он уже проиграл одному условию, которое команда не имеет права нарушать. Это вся суть метода, к которому я веду: сначала стоп-критерии, и только потом цена и всё, что за неё покупается.
Типичная ошибка при отборе выглядит невинно. Ты собираешь пять кандидатов, ставишь им оценки по десяти параметрам, складываешь взвешенную сумму и берёшь лидера. В этой процедуре низкая цена и высокий общий балл спокойно компенсируют, например, отсутствие подтверждённой политики хранения данных. Формально победитель есть. Фактически ты только что дал вес кандидату, который провалил условие, ради которого весь отбор и затевался.
Дальше я разберу, почему кандидат не может отыграть рейтинг после проигрыша стоп-критерию, как устроена таблица «ограничение - доказательство - статус - вес» и почему scorecard начинается только после допуска. Если в твой shortlist попадает provod.ai, он проходит ровно тот же gate, что и любой другой кандидат: сначала обязательные поля с доказательствами, потом сравнение среди прошедших.
Платите в рублях за AI-модели без наценки на токены через provod.ai
Почему цена не выкупает провал стоп-критерия
Спорный по умолчанию тезис, который я оспариваю: «низкая цена и высокий общий балл компенсируют критичный разрыв». В большинстве сравнений он зашит неявно - через единую взвешенную сумму. Как только все параметры складываются в один балл, любой из них становится обмениваемым на любой другой. Дешевизна начинает выкупать риск по данным. Богатый каталог моделей начинает выкупать одностороннюю индемнити в контракте.
Моя позиция жёстче: критичный риск - это условие допуска, а не компонент цены. Если команда обязана держать персональные данные в определённом контуре, то кандидат, который этого не гарантирует, не «слабее на несколько баллов». Он просто не участвует. Взвешивать его цену бессмысленно, потому что его цена не относится к делу.
Отсюда falsifiable-формулировка, по которой этот метод можно проверить и опровергнуть: если кандидат не проходит обязательное ограничение, его цена или общий балл не должны вернуть его в shortlist. Как только ты видишь в своей таблице строку, где сильная цена «вытащила» кандидата с проваленным обязательным полем, метод сломан, и это видно сразу.
Важная оговорка про статус этого утверждения. «Один проваленный обязательный критерий делает сравнение цены нерелевантным» - это нормативная позиция дизайна отбора. Документированного отраслевого консенсуса за ней нет, и я не выдаю её за факт индустрии. Я утверждаю, что для команды с реальными обязательствами по данным и контракту такой fail-closed порядок честнее, чем усреднённый балл.
Как устроен gate: таблица «ограничение - доказательство - статус - вес»
Практический артефакт метода - одна таблица на два назначения. Первая её половина работает как fail-closed gate: перечисляет обязательные ограничения твоей команды и требует по каждому доказательство, а не обещание. Вторая половина - вес для рейтинга, и она заполняется только у тех, кто прошёл. У непрошедшего кандидата колонка веса остаётся пустой намеренно: присваивать ему вес - операционная ошибка.
Ключевое слово - доказательство. «Поддерживает ZDR» на лендинге и «трафик именно моей команды покрыт нужной областью действия ZDR» - это разные утверждения. По документации OpenRouter на 18 июля 2026 года Zero Data Retention не является единым глобальным дефолтом: его нужно активно включить на одном из трёх уровней - на весь аккаунт, на группу моделей по пяти категориям или на отдельный запрос через параметр zdr. Значит, статус допуска по этому полю - это проверенная область включения, а не наличие фразы в маркетинге.
Заметь ещё одну деталь про fail-closed. Там же в документации OpenRouter зафиксировано: если для конкретного апстрим-провайдера или эндпоинта нет ясной политики хранения и обучения, сервис по умолчанию считает, что эндпоинт и хранит, и обучается на данных. Отсутствие документации трактуется как провал: проходной статус недоказанное поле не получает. Ровно эту логику стоит перенести в собственный gate. Пустая ячейка доказательства - это FAIL, а не «уточним потом».
Как собрать доказательства по каждому кандидату
Разберу категории обязательных ограничений на конкретных, проверяемых примерах. Оговорюсь сразу: названные сервисы здесь иллюстрируют категории и не образуют готовый рейтинг. Сама двухступенчатая схема gate-then-scorecard - это мой предлагаемый метод, эти вендоры его не публикуют и не одобряют.
Категория «ответственность и SLA». По условиям OpenRouter на 18 июля 2026 года совокупная ответственность ограничена большей из величин: платежи за 12 месяцев или 100 долларов; косвенные убытки исключены; прямой гарантии, что сервис будет «бесперебойным, безопасным или без ошибок», нет, а аптайм на уровне моделей вынесен в отдельные Model Terms каждого провайдера. Там же клиент обязан защищать и возмещать убытки самого агрегатора по искам из своего использования сервиса. Для интегратора это значит, что контрактный риск инцидента смещён на него, а не поглощён агрегатором. Если у твоей команды это недопустимо - поле обязательное, и статус ставится по тексту договора.
Дальше - депрекация моделей. В собственном reliability-руководстве OpenRouter говорится, что за последние годы апстрим-провайдеры вывели или депрецировали более 70 моделей, и рекомендует цепочки fallback именно потому, что депрекации происходят регулярно и агрегатор их предотвратить не может. Это вендорское заявление в блоге, не независимо проаудированный подсчёт, и опираться на него стоит именно с такой атрибуцией. Базовый апстрим-ориентир по срокам даёт OpenAI: её политика депрекаций обещает минимум шесть месяцев предупреждения перед выводом общедоступной модели, с разделением терминов deprecation, sunset/shutdown и legacy. Но это гарантия OpenAI, а не агрегатора, который стоит перед её моделями.
Третье поле - комплаенс-сертификация. Portkey заявляет соответствие SOC2, ISO 27001, GDPR и HIPAA с проверкой через сторонний trust-портал. Но в публичной документации, доступной на 18 июля 2026 года, не указано, какой именно уровень развёртывания - управляемый SaaS, гибрид или приватный/air-gapped - нужен, чтобы фактически получить каждую сертификацию или подписанный BAA. Здесь именно документированный пробел; подтверждённого отсутствия такой детали я не утверждаю. Корректная формулировка статуса - «требуется письменное подтверждение вендора по нужному тиру до того, как считать поле пройденным».
Совсем другой случай - архитектура интеграции. LiteLLM - это self-hosted, OpenAI-совместимый шлюз, который транслирует единый интерфейс вида /chat/completions к более чем 100 бэкенд-провайдерам, включая Bedrock, Azure, Anthropic и Vertex AI. Профиль риска у него структурно другой: совместимость на уровне кода и собственный хостинг вместо коммерческого сервиса с его условиями договора. Я включаю его не как равнозначного конкурента в scorecard, а как отдельную категорию интеграционного риска, которую нельзя сравнивать с хостируемым агрегатором по тем же весам.
Ещё одно обязательное поле, которое любят пропускать: региональность данных. OpenRouter предлагает routing внутри EU, где промпты и ответы обрабатываются и хранятся в ЕС. Но включается эта опция по запросу и только на enterprise-тире; для обычного аккаунта она по умолчанию не работает. Вывод для gate прямой: «EU data residency» проверяется по конкретному тиру договора и не выводится из общей доступности продукта. Для российской команды тот же вопрос звучит про свой контур и 152-ФЗ. Это тоже обязательное поле, а не приятная опция.
Почему формулировка запроса прячет стоп-критерий
Прежде чем строить scorecard, стоит посмотреть, в какой формулировке задача вообще приходит. От руководителя, из тикета, из строки поиска - и почти всегда уже с зашитой осью сравнения. Одна формулировка тянет к цене, другая к абстрактному рейтингу. Обязательное поле команды не кодирует ни одна. Отсюда и берётся ложная объективность, о которой я предупреждал.
Ниже - шесть таких формулировок. Слева они приведены дословно, как их произносят и набирают, без правки грамматики; в середине - ось, на которую формулировка оптимизирует; справа - стоп-критерий, который при этом остаётся непроверенным.
| Формулировка запроса (как её вводят) | На что оптимизирует | Какой стоп-критерий не проверяет |
|---|---|---|
| «дешевые агрегаторы нейросетей», «самый дешевый агрегатор нейросетей», «агрегатор ии бесплатно», «бесплатный агрегатор ии», «агрегатор нейросетей бесплатно» | цена и наличие бесплатного входа | хранение и обучение на данных, ответственность по договору |
| «лучший агрегатор ии», «лучший ии агрегатор», «лучший агрегатор ai», «лучшее агрегаторы api для ai», «агрегатор нейросетей топ», «агрегатор нейросетей рейтинг», «лучший агрегатор ии 2026» | абстрактный общий рейтинг | обязательные поля конкретной команды |
| «агрегатор ии в россии», «российские агрегаторы нейросетей», «русский агрегатор нейросетей», «приложение ии для россии», «ии api в россии», «api нейросетей из россии» | доступ и оплата из РФ | контур данных, тир договора, резидентность |
| «агрегатор нейросетей фото», «агрегатор нейросетей для изображений», «агрегатор ии видео», «агрегатор нейросетей для фото и видео», «агрегатор нейросетей для презентаций», «агрегатор ии агентов» | набор задач и модальностей | депрекация моделей, стабильность совместимости |
| «агрегатор нейросетей для бизнеса», «агрегаторы нейросетей в россии для коммерческих целей» | бизнес-профиль и оформление | лимит ответственности, индемнити, резидентность |
| «какой агрегатор нейросетей выбрать» | сам факт выбора | ничего конкретного - это точка входа в gate |
Правая колонка - это список того, что усреднённый рейтинг тихо теряет. «Дешевые агрегаторы нейросетей» - совершенно разумный запрос, если данные и договор уже прошли gate. До этого он оптимизирует не ту ось. Вывод из таблицы простой: ни одна ходовая формулировка не спрашивает про обязательное поле, поэтому gate придётся ставить руками.
Что попадает в scorecard и как его считать
Scorecard начинается только после допуска. У кандидатов с полным набором PASS появляется вторая половина таблицы - веса. Здесь уже уместно сравнивать цену, широту каталога, качество маршрутизации, удобство SDK и всё остальное, что для непрошедшего было бы нерелевантно. Порядок «сначала fail-closed gate, потом scorecard» я выбрал сознательно вместо альтернативы «сразу взвесить всех кандидатов». Принятая цена этого решения честная: жёсткие стоп-критерии сокращают выбор раньше рейтинга. Но именно это и нужно - не дать сильной цене вернуть в игру неприемлемый риск.
Практический шаг для российской команды: заявленный OpenAI- или Anthropic-совместимый эндпоинт - это проверяемое поле. Проверка занимает минуту: замени ключ и base_url в существующем клиенте и отправь один запрос. В примере ниже подставлен адрес provod.ai.
from openai import OpenAI
client = OpenAI( api\_key="ВАШ\_КЛЮЧ", base\_url="https://api.provod.ai/v1", )
resp = client.chat.completions.create( model="ваша-модель-из-каталога", messages=[{"role": "user", "content": "healthcheck"}], ) print(resp.choices[0].message.content)
На нём же покажу заполнение gate. provod.ai (российский OpenRouter) - это market-аналогия для российского рынка; аффилиации с OpenRouter за ней нет. Три поля, которые у команды в РФ чаще всего попадают в обязательные, закрываются здесь проверяемо. Совместимость: клиент, работающий по протоколу OpenAI, подключается заменой base_url и ключа, без переписывания кода. Платёжный маршрут: российская карта, СБП или счёт от российского юрлица с закрывающими документами, без зарубежной карты и VPN. Контур данных: российский, спроектированный под требования к обработке персональных данных.
Это три заполненные строки gate, и только. Вывод о преимуществе из них не следует: остальные обязательные поля - твои, и статус по ним ставишь ты по тем же правилам, что и любому другому кандидату.
Чего этот метод не решает
Gate отражает только те обязательные условия, которые твоя команда согласовала заранее. Он не выбирает за тебя, какие именно риски - обучение на данных, длина уведомления о депрекации, лимит ответственности, сертификация, EU-резидентность - для тебя non-negotiable. Источники подтверждают, что эта вариативность существует и её надо проверять по каждому вендору и тиру договора, но какой риск критичен для тебя - это твоя политика, и никакая внешняя документация её не заменит.
Метод не про роль агрегатора во время инцидента. Это портфельный eligibility-gate для формирования shortlist, а не runbook на отказ канала. И включение кандидата в shortlist не является выводом о его преимуществе - только фактом прохождения обязательных полей.
Отдельно про границы самого сервиса. Совместимый API не заменяет ни приватную и on-prem инфраструктуру, ни функции, которые вендор отдаёт только по собственной подписке. provod.ai здесь не исключение: GigaChat он, например, не предоставляет. Если что-то из этого у тебя обязательное - это тоже строка в gate со своим статусом.
Наконец, про свежесть. Документация OpenRouter и Portkey версионируется и меняется без стабильного changelog. Факты по хранению, условиям договора и EU-роутингу здесь отражают страницы по состоянию на 18 июля 2026 года; перед фактическим выбором их нужно перепроверить. Перепроверка входит в сам метод; разовой сверкой она не закрывается.
Частые вопросы
Можно ли пропустить пустое обязательное поле, если цена очень низкая? Нет. В этом и falsifiable-суть метода: проваленное обязательное поле не возвращается в shortlist ни ценой, ни общим баллом. Пустая ячейка доказательства - это FAIL по умолчанию, как OpenRouter трактует отсутствие политики хранения.
Чем это отличается от обычного рейтинга с весами? Обычный рейтинг делает все параметры обмениваемыми через одну сумму. Здесь допуск и вес физически разделены: критерий допуска нельзя смешивать с весом рейтинга, а вес непрошедшему кандидату не присваивается.
Что писать в статусе, если вендор заявляет сертификацию, но не уточняет тир? Ставь «требуется письменное подтверждение по нужному тиру» и держи поле незакрытым. Так документированный пробел Portkey по маппингу сертификаций на уровень развёртывания не превращается в ложный PASS.
Как решать, какой агрегатор нейросетей выбрать, если несколько прошли gate? Тогда и только тогда включается scorecard: сравнивай цену, каталог, маршрутизацию и совместимость среди прошедших. До допуска это сравнение нерелевантно.
provod.ai — один API для поиска, анализа и генерации ответа
Соберите контур работы с документами без набора разрозненных сервисов: используйте эмбеддинги для поиска, reasoning для анализа и подходящую модель для итогового ответа.
В одном каталоге — актуальные модели для текста и медиа: GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.
Каждый компонент можно выбирать по реальной цене модели: официальные тарифы сохраняются 1:1, без собственной надбавки provod.ai.
Запустите поиск по корпоративным знаниям: форма регистрации · цены на модели · защита данных по 152-ФЗ · политика обработки данных
Источники
- OpenRouter, Zero Data Retention, доступ 2026-07-18: https://openrouter.ai/docs/guides/features/zdr
- OpenRouter, Terms, доступ 2026-07-18: https://openrouter.ai/terms
- OpenRouter, Reliability & failover, доступ 2026-07-18: https://openrouter.ai/blog/insights/reliability-failover/
- OpenAI, API deprecations, доступ 2026-07-18: https://developers.openai.com/api/docs/deprecations
- Portkey, Security & compliance, доступ 2026-07-18: https://portkey.ai/docs/product/enterprise-offering/security-portkey и https://portkey.ai/features/security-compliance
- LiteLLM (BerriAI), Proxy & OpenAI-compatible providers, доступ 2026-07-18: https://docs.litellm.ai/docs/simple_proxy и https://docs.litellm.ai/docs/providers/openai_compatible