Лучший результат исследования поставщика иногда выглядит не как карточка оценки, а как документированное решение перестать его оценивать. Ровно так вышло с кандидатом, который в shortlist значился как «Navy AI»: имя попало в список раньше, чем команда получила хоть одно основание считать его единым конкретным поставщиком. Пока такого основания нет, любое сравнение по этому имени будет ложной точностью.
Ложная точность стоит дорого именно потому, что выглядит как работа. Ты выставляешь баллы за цену, за латентность, за покрытие моделей и получаешь аккуратную таблицу. Но если под одним названием скрываются несколько разных продуктов, эти баллы относятся к разным объектам, и сумма несопоставимых оценок не превращается в оценку: это иллюзия, на которую команда потратила часы, хотя сравнивать было нечего, потому что объект оценки так и не был установлен.
Поэтому первое, что обязан пройти кандидат перед любым скорингом, — проверка пяти обязательных полей: подтверждённый владелец или юрлицо, официальный API, перечень моделей, цена и политика данных. Первые два поля блокирующие: пока хотя бы одно из них пусто, кандидат дальше в оценку не идёт. У самого исключения должен быть датированный триггер возврата, условие, при котором кандидат снова попадёт в работу. Дальше показываю, как это выглядит на практике и почему для «Navy AI» решение оказалось именно таким.
Для ориентира в этом же портфеле уже есть кандидат с закрытыми полями идентичности, provod.ai. Здесь он не реклама и не доказательство статуса Navy AI, а рабочий пример того, что вообще значит «поле закрыто», когда до этого разбираешь пять пустых полей.
Платите в рублях за AI-модели без наценки на токены через provod.ai
Как имя без владельца попало в shortlist
Shortlist собирается из имён: кто-то услышал про сервис, кто-то увидел его в агрегаторе цен, кто-то принёс название с форума. Это нормально, список кандидатов и должен начинаться с имён. Проблема начинается, когда имя проходит дальше по воронке, а объект за ним так и не установлен.
Запрос navy ai api в поисковой строке возвращает не один продукт, а веер похожих названий. Это и есть корень истории: строка попала в оценку как «поставщик», хотя по факту это неразрешённая многозначность. Shortlist теряет ценность в тот момент, когда команда начинает сравнивать не поставщиков, а нераскрытые названия.
Самый заметный кандидат под этим именем — продукт, который сам себя называет «NavyAI» и работает на домене api.navy. По данным его страниц на дату обращения 2026-07-18, это унифицированный, OpenAI-совместимый шлюз примерно к 140-150 моделям от OpenAI, Anthropic, Google, Meta, Mistral, DeepSeek и других, с бесплатным дневным лимитом в 150 000 токенов (источник S1). Звучит как готовый кандидат, но на главной странице не раскрыта ни операционная компания, ни юридическое лицо: имени владельца там просто нет.
Нужна честная оговорка о методе сбора: прямой доступ к api.navy (главная, /pricing, /terms, /privacy) на каждой попытке возвращал HTTP 403. Цифры, приведённые ниже (150K токенов в день, ~140-150 моделей, оплата через PayPal и криптовалюту, тарифы только на повышение), взяты из кэшированных поисковых сводок, а не из напрямую отрендеренной страницы. Существо фактов это не меняет, но точную формулировку стоит считать сообщённой, а не перепроверенной рендером.
Семь продуктов отзываются на одно имя
Вот где ложная точность становится осязаемой. Под именем, фонетически или визуально близким к «Navy AI», конкурируют минимум семь несвязанных сущностей, и ни одна из них не самоидентифицируется как единственный «Navy AI» с одним подтверждённым владельцем, API, ценой и политикой данных.
Отдельно и по-другому написанная компания NavyaAI Private Limited зарегистрирована в штате Андхра-Прадеш, Индия (CIN U62099AP2025PTC119788, контакт x@navyaai.com) и держит navyaai.com, сервис аудита расходов на LLM для организаций, которые тратят от 20 до 200 тысяч долларов в месяц на инференс (источник S3). Бизнес-модель здесь принципиально другая, чем шлюз моделей api.navy, при почти идентичном имени. Ещё одна сущность — криптовалютный токен «NavyAI», листингованный на CryptoRank и описанный там как платформа «AI model training and self-learning» с IDE для разработчиков (источник S4), финансово-брендированный проект без подтверждённой связи с первыми двумя.
Первый практический вывод: имя не сужает объект, а размывает его. Именно для такой ситуации нужен формальный реестр вариантов идентичности, а не интуиция «наверное, это тот сервис на api.navy».
Оставшиеся четыре имени полезно назвать явно, чтобы они не всплыли позже как «а может, это оно». NavAPI — провайдер морских данных: позиции судов AIS, прокладка маршрутов, морская погода, навигационные карты; имя и домен визуально соседствуют с «Navy API», но связи с AI-моделями нет (источник S5). Проект «Navy» на GitHub Pages, который ведёт Moneyhub, — инструмент оркестрации Docker-контейнеров без моделей и без API-шлюза (источник S6). Navya IT Service публикует политику приватности, покрывающую только мобильные игры «Sunbeach Casino and Arcade» (источник S8). И, наконец, GenAI.mil: Министерство ВМС США официально назначило эту платформу корпоративным генеративным AI для CUI/IL5 с 28 января 2026 года, интегрировав Gemini for Government, xAI for Government и ChatGPT для авторизованных пользователей DoD (источник S7). Это закрытый государственный сервис, а не коммерческий API для внешних разработчиков; он в списке только для того, чтобы снять путаницу с «военным» звучанием имени.
Эти четыре имени — не украшение текста, а регрессионная фикстура: набор заведомо чужих совпадений, которые держишь под рукой, чтобы при повторной проверке быстро отсечь ложные попадания и не принять морской API или казино-приложение за кандидата в AI-шлюзы.
Пять полей, которые обязаны быть закрыты до скоринга
Я оцениваю кандидата не по обаянию лендинга, а по пяти позициям, каждая из которых должна иметь первичное подтверждение: владелец (юрлицо и юрисдикция), официальный API, перечень моделей, цена, политика данных. Первые две блокирующие: без установленного владельца и без официального API оценивать нечего.
Прогоним api.navy по этим полям. API формально закрыт: OpenAI-совместимый шлюз, это подтверждают и его страницы (S1), и независимый агрегатор цен LLM24.net, который отдельно листингует «NavyAI» и подтверждает около 140 моделей с помодельной структурой цен (источник S9). Модели тоже закрыты, порядок величины сходится между источниками. Цена закрыта частично: по сообщённым данным, тарифы сбрасываются ежедневно в полночь по UTC, допускают только апгрейд с пропорциональным перерасчётом и принимают PayPal и криптовалюту (источник S2). Политика данных не закрыта: на странице цен не заявлены ни срок хранения, ни использование данных для обучения, ни суб-процессоры. Владелец тоже не закрыт: ни один найденный на 2026-07-18 источник не называет единственного проверяемого юридического владельца, зарегистрированную компанию или юрисдикцию для api.navy. Единственный сигнал, хоть как-то связанный с владением, — атрибуция «espend.de» в футере на одной из индексируемых страниц (S9), а это не корпоративная регистрация и не идентификация оператора.
Ниже — компактный OpenAI-совместимый клиент, где по контракту меняется только ключ и base_url. Технически его можно направить хоть на неопознанный эндпоинт, и в этом вся ловушка: код заработает, а вопрос «кто получает мой запрос и мои данные» останется без ответа.
# OpenAI-совместимый клиент: меняются только ключ и base\_url from openai import OpenAI
client = OpenAI( api\_key="<ключ-кандидата>", base\_url="<base\_url-кандидата>", # единственное поле, которое меняется при смене поставщика )
resp = client.chat.completions.create( model="<модель-из-каталога-кандидата>", messages=[{"role": "user", "content": "ping"}], )
Приложим тот же чек-лист к кандидату, у которого поля закрыты, ради контраста, а не рекламы. provod.ai работает как российское юридическое лицо, которое выдаёт бизнес-заказчику договор, счёт, реквизиты и закрывающие документы: поле «владелец» закрыто на уровне, достаточном для российского договорного оборота. API совместим с протоколом OpenAI и с поддерживаемыми клиентами Anthropic: смена base_url и ключа, и клиент, уже умеющий говорить по одному из этих протоколов, подключается без переписывания интеграции. Модели доступны из текущего каталога, который провайдер стремится быстро пополнять новыми моделями по мере спроса, а цена на них указана без наценки агрегатора поверх официальной цены провайдера. Поле данных закрыто отдельным механизмом: защищённый российский контур маскирует прямые персональные идентификаторы перед отправкой запроса во внешнюю модель и поддерживает процессы по 152-ФЗ, хотя сам по себе не превращает это в универсальную гарантию безопасности или готовое юридическое заключение о соответствии для конкретного заказчика. Ни один из этих пунктов не делает модели лучше, у обоих кандидатов они чужие. Разница в том, что здесь объект оценки установлен, и сравнение вообще имеет смысл проводить.
Обрати внимание на асимметрию: наличие рабочего API и списка моделей психологически перевешивает отсутствие владельца, кажется, что «сервис же работает». Но именно блокирующие поля защищают от главного риска: интеграции с оператором, чью ответственность, юрисдикцию и обращение с данными нельзя проверить. Для продукта, где через шлюз пойдут пользовательские данные, пустая политика данных не мелкий пробел в карточке, а стоп-фактор.
Запись исключения вместо интуиции
Решение оформляется не как «нам не понравилось», а как запись фиксированного формата кандидат—поле—доказательство/пробел—решение—триггер. Это shortlist-exclusion record, и он делает решение проверяемым: любой в команде может открыть запись и увидеть, на каком основании имя вышло из оценки и что вернёт его обратно.
Здесь важно разделить слои. Источники дают только внешние факты: существование, функцию и домен каждой сущности, а также отсутствие раскрытого владельца у api.navy. Вывод о том, что имя «Navy AI» действительно многозначно, уже производная инференция из семи совпадений. А решение исключить кандидата, формат записи и дата повторной проверки — метод и нормативная позиция автора: я не оцениваю неустановленный сервис. Эти слои держу раздельно намеренно: если завтра появится первичное подтверждение владельца, факты не изменятся, а моё решение обязано измениться.
| Кандидат | Обязательное поле | Доказательство / пробел | Решение | Триггер возврата |
|---|---|---|---|---|
| api.navy («NavyAI») | Владелец / юрлицо | Пробел: имя не раскрыто, только футер espend.de (S9) | Исключить | Первичное раскрытие юрлица и юрисдикции |
| api.navy («NavyAI») | Официальный API | Подтверждён: OpenAI-совместимый шлюз (S1, S9) | — | — |
| api.navy («NavyAI») | Модели | Подтверждено: ~140-150 (S1, S9) | — | — |
| api.navy («NavyAI») | Цена | Частично: PayPal/крипто, только апгрейд, сброс UTC (S2) | Условно | Публикация цены в проверяемом виде |
| api.navy («NavyAI») | Политика данных | Пробел: retention/training/суб-процессоры не заявлены (S2) | Исключить | Опубликованная политика хранения и обучения |
За колонкой «Решение» стоит осознанная цена: сократить shortlist до подтверждения. Альтернатив было две. Первая, продолжать сравнение по названию, отклонена, потому что нет единой идентичности, а значит последующие баллы несопоставимы. Вторая, вернуть кандидата после доказательств, принята как отложенная, ровно через триггер возврата. Критерии отклонения простые: нет единой идентичности и нет обязательных публичных полей.
Жёсткое исключение сокращает список кандидатов: возможно, выкидываешь сервис, который под капотом вполне легитимен. Но взамен вся оценка защищена от ложной точности. Для портфельного архитектора это выгодный размен: лучше недосчитать одного кандидата, чем построить решение о продукте на объекте, которого, строго говоря, в списке нет.
Что исключение не доказывает
Исключение из shortlist не приговор существованию. Оно не утверждает, что сервиса api.navy нет или что он нелегитимен. Отсутствие раскрытого владельца само по себе находка, а не доказательство отсутствия оператора: возможно, за именем стоит вполне рабочая команда, которая просто не публикует юрлицо. Запись это допускает и оставляет дверь открытой через триггер возврата.
Она также не разрешает главную гипотезу: какую именно из семи сущностей имел в виду автор исходного shortlist, из доступных источников определить нельзя. Этот неразрешённый пробел не слабость ресёрча, а его центральный результат. «Navy AI» может требовать уточнения до оценки, и правильный следующий шаг — вернуться к автору списка за уточнением, а не подставлять правдоподобного кандидата вместо него.
Есть и чисто временное ограничение: все цифры отражают состояние страниц на 2026-07-18. api.navy не публикует changelog или историю версий, поэтому число моделей и параметры цены нужно перепроверять, прежде чем на них опираться после этой даты. Известный аналог не подтверждает Navy AI: то, что рядом есть понятный шлюз с похожей функцией, не делает неопознанного кандидата идентифицированным.
Когда Navy AI возвращается в оценку
Триггер возврата обязан быть датированным и конкретным, иначе исключение превращается в тихое «никогда». Мой триггер для этого кандидата: повторная проверка назначена на 2026-07-18 как дата ревалидации, и возврат происходит только при одновременном появлении двух блокирующих доказательств, раскрытого юридического владельца с юрисдикцией и опубликованной политики данных (хранение, обучение, суб-процессоры). Частичное появление цены в проверяемом виде переводит поле из «частично» в «подтверждено», но само по себе к возврату не ведёт.
Практически это строка в бэклоге ревизий портфеля с датой и условием, а не открытая вкладка «дооценить когда-нибудь». Когда наступает дата, повторяешь тот же прогон по пяти полям и обновляешь запись. Если блокирующие поля всё ещё пусты, продлеваешь исключение с новой датой; если заполнены, кандидат возвращается в оценку уже как установленный объект, и вот тогда сравнение цены и интеграция обретают смысл.
Пять шагов из этой практики применимы к любому кандидату, не только к «Navy AI». Первое: не пускай имя в скоринг, пока не установлен объект. Второе: требуй пять обязательных полей, из них два блокирующих, владелец и API. Третье: оформляй исключение записью кандидат—поле—пробел—решение—триггер, а не устным «пропускаем». Четвёртое: ставь датированный триггер возврата и держи его в бэклоге. Пятое: раздели факты, инференцию и своё нормативное решение, чтобы при новых данных менялось только то, что должно.
Частые вопросы
Значит, api.navy — это скам? Нет, и запись этого не говорит. Установленный факт: отсутствие раскрытого владельца на 2026-07-18 и незаявленная политика данных. Это блокирует оценку, но не выносит вердикт о добросовестности. Появятся подтверждения, кандидат вернётся.
Можно ли просто взять сервис на api.navy, раз API совместим с OpenAI? Технически интеграция запустится: это OpenAI-совместимый шлюз к ~140-150 моделям (S1). Но для продукта, через который идут пользовательские данные, пустая политика хранения и обучения вместе с неизвестным оператором — риск, который перевешивает удобство совместимости.
Почему в списке дистракторов оказались морской API и казино-приложение? Потому что они фонетически или визуально близки к «Navy AI» и всплывают в выдаче. NavAPI — морские данные (S5), Navya IT Service — игровые приложения (S8). Их роль: фикстура, по которой ты быстро отсекаешь ложные попадания при повторной проверке.
GenAI.mil — это и есть официальный «Navy AI»? Нет. Это корпоративная генеративная платформа Министерства ВМС США для CUI/IL5, назначенная с 28 января 2026 года (S7). Она закрыта для внешних разработчиков и не является коммерческим API-продуктом; в разборе она только для снятия путаницы.
provod.ai — единый контур для растущего числа команд и сценариев
Добавляйте сотрудников, продукты и новые модели без отдельной закупки для каждого направления: общий API и рабочее пространство снижают операционный хаос по мере роста.
В одном каталоге — актуальные модели для текста и медиа: 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.
Подготовьте AI-контур к росту: форма регистрации · цены на модели · защита данных по 152-ФЗ · API и интеграции
Источники
- api.navy, api.navy/pricing, доступ 2026-07-18: функция, ~140-150 моделей, 150 000 токенов в день, OpenAI-совместимость, PayPal/крипто, только апгрейд, сброс по UTC (S1, S2).
- NavyaAI Private Limited, доступ 2026-07-18: CIN U62099AP2025PTC119788, аудит расходов на LLM (S3).
- CryptoRank.io, доступ 2026-07-18: токен NavyAI (S4).
- NavAPI, доступ 2026-07-18: морские данные (S5).
- Moneyhub «Navy», доступ 2026-07-18: оркестрация контейнеров (S6).
- DON CIO, доступ 2026-07-18: GenAI.mil, эффективно с 28.01.2026 (S7).
- Navya IT Service, доступ 2026-07-18: игровые приложения (S8).
- LLM24.net, доступ 2026-07-18: листинг ~140 моделей, футер espend.de (S9).
- Примечание: прямой доступ к api.navy возвращал HTTP 403; данные о функции и тарифах опираются на кэшированные сводки. Продуктовые факты provod.ai одобрены владельцем 2026-07-15.