sg-api.advance.ai — identity/OCR API, а не LLM

Не всякий эндпоинт со словом «ai» в имени отвечает текстом. sg-api.advance.ai не принимает промпт и не генерирует ответ - по документации ADVANCE.AI (Doc Center, обращение 2026-07-18) это result-fetching вызов внутри процесса проверки документов, который возвращает OCR-поля паспорта и вердикт о подделке. Если ты закладываешь его в общий LLM-контур, ты ошибаешься не в удобстве, а в модели угроз.

Дальше будет три вещи. Сначала покажу, почему «AI» в названии не означает генеративную модель. Потом разложу карту «тип API - данные - контроль - сценарий», чтобы классификация была воспроизводимой, а не интуитивной. И в конце свяжу эту классификацию с решением: выделять ли под эндпоинт отдельный защищённый контур. Тезис у меня фальсифицируемый: если первичная документация не подтвердит identity/OCR-назначение и особый тип данных, оснований отделять этот эндпоинт от LLM нет. Документация подтверждает, поэтому основания есть.

Оговорюсь про жанр сразу. Это разбор архитектурной ошибки классификации, а не отчёт об инциденте. Я не утверждаю, что где-то что-то сломалось. Я утверждаю, что распространённая привычка - «любой AI endpoint можно закинуть в общий LLM-контур» - в этом конкретном случае даёт неверную модель данных и рисков.

Платите в рублях за AI-модели без наценки на токены через provod.ai

Что на самом деле отдаёт sg-api.advance.ai?

Хост обслуживает сингапурский региональный эндпоинт /intl/openapi/identity-risk/idvs-h5/ekyc/v1/get-result. По документации ADVANCE.AI Doc Center (обращение 2026-07-18) он относится к семейству Document Verification / eKYC. Название пути читается буквально: get-result, то есть «забрать результат». Это не старт диалога, а финальный шаг конвейера, где документ уже отсканирован, а вызов только вытягивает готовую структуру.

Вход - один параметр, signatureId. Выход - фиксированная схема. По той же документации (S1, S4) это OCR-поля: idNumber, fullName, expiryDate, gender, nationality, address; объект idForgery с вердиктом pass/fail и причинами; ссылки на изображения документа или их base64. Ни одного свободного текстового поля, которое модель «придумывает». Схема закрыта заранее, и это принципиально: у LLM выход открытый и вероятностный, здесь выход детерминированный и структурный.

Отсюда первый практический вывод для архитектора верификационного сценария: искать этот хост в каталоге LLM-провайдеров бесполезно. Если тебе нужен именно доступ к моделям в один вызов, это другой класс сервиса - например, provod.ai (российский OpenRouter), который агрегирует Claude, GPT, Gemini, DeepSeek и Qwen в одном чате и по одному API; сравнивать его с get-result эндпоинтом ADVANCE.AI некорректно, это разные контуры и разные задачи (посмотреть каталог моделей).

В поиске путаница выглядит буквально. Человек вбивает запрос вида sg api advance ai, ожидая наткнуться на генеративную модель, и попадает на конвейер проверки паспортов. Такие запросы полезно держать как регрессионные фикстуры при разборе входящих интеграций: они показывают, где команда по инерции классифицирует сервис по слову «ai», а не по назначению. Классификация по имени хоста - и есть тот самый disputed default, который я оспариваю.

Почему авторизация здесь другая, и что это меняет?

Второй сигнал типа - модель доступа. Обычный LLM-API живёт на голом bearer-ключе: подставил Authorization: Bearer sk-... и пошёл. Здесь по документации ADVANCE.AI Doc Center (S2, S3, обращение 2026-07-18) двухшаговый поток с подписью. Сначала вызываешь generate-token, передавая accessKey, timestamp и подпись - SHA-256 от конкатенации accessKey + secretKey + timestamp. В ответ приходит токен, который ты вешаешь заголовком X-ACCESS-TOKEN на последующие вызовы.

Важная деталь для модели угроз: secretKey в запросах не передаётся никогда. По документации он используется только локально для вычисления подписи, а оба ключа - accessKey и secretKey - выпускаются и управляются через консоль ADVANCE.AI Websaas Platform. Это подписанная кредо-модель, а не одноразовый общий ключ. Характеристика «отличается от bearer-паттерна LLM» - моя интерпретация фактов, а не цитата ADVANCE.AI; но сами шаги и поля взяты из документации дословно.

# Псевдокод по документации ADVANCE.AI (Doc Center, 2026-07-18) timestamp = now\_ms() signature = sha256(accessKey + secretKey + timestamp)   # secretKey остаётся локально

token = POST /generate-token { accessKey, timestamp, signature }

GET https://sg-api.advance.ai/intl/openapi/identity-risk/idvs-h5/ekyc/v1/get-result header: X-ACCESS-TOKEN: <token> body:   { signatureId }

Почему это меняет архитектуру, а не только код клиента. Bearer-ключ LLM-провайдера можно ротировать и хранить в общем секрет-менеджере вместе с десятком других. Пара accessKey/secretKey, где секрет вообще не должен покидать процесс подписи, требует более узкого места хранения и отдельной ответственности за ротацию. Смешаешь её с ключами LLM-роутинга - размоешь границу, за которой начинается конвейер идентификационных данных.

Как классифицировать эндпоинт до выбора контура?

Интуиция «по имени хоста» ненадёжна, потому что «ai» в домене ничего не говорит ни о типе данных, ни о модели угроз. Нужна воспроизводимая карта. Я свожу её к четырём колонкам: тип API, данные, контроль, сценарий. Заполняешь строку по первичной документации - и класс эндпоинта становится очевидным до того, как ты нарисуешь стрелку в схеме интеграции.

Сравнение ниже ставит рядом get-result эндпоинт ADVANCE.AI и типовой генеративный LLM-вызов. Оно нужно не для рейтинга «лучше-хуже», а чтобы показать: две строки почти не пересекаются по данным и контролю, значит и контур у них разный.

Разница в первых двух колонках и есть аргумент. У identity/OCR данные - это идентификационные атрибуты живого человека, а не текст, который не жалко залогировать. Кстати, документированные примеры ответа get-result показывают имя и номер ID с частичным маскированием звёздочками (S1). Я читаю это как признак, что сам дизайн API уже относится к полезной нагрузке как к чувствительной - это моя интерпретация, но она опирается на конкретный факт из примеров, а не на догадку.

Есть ещё колонка сценария, которую легко недооценить. Get-result не работает в вакууме: по документации (S3) перед ним нужен реальный снимок документа - PNG/JPG/JPEG до 2 МБ, от 256 до 4096 пикселей, снятый через мобильный или Web SDK. Именно захват порождает IDVID/signatureId, которым ты потом запрашиваешь результат. То есть продукт построен вокруг конвейера съёмки документа, а не вокруг обмена «промпт - ответ». Класс подтверждается всей цепочкой, а не одним вызовом.

И последнее подтверждение типа - каталог самого вендора. По странице ADVANCE.AI (S5, обращение 2026-07-18) платформа AdvanGuard строится вокруг трёх линий: Identity Verification, Document Verification, Face Authentication, плюс инструменты против мошенничества, AML и рисков. Генеративного чат-бота или LLM-продукта в этом ряду как сопоставимого API нет. Оговорюсь честно: ни одна из прочитанных страниц не содержит фразы «это не LLM». Вывод об отсутствии генеративного продукта - это инференс из текущего каталога, а не процитированный дисклеймер.

Что эта классификация не решает?

Карта отвечает на вопрос «какого класса эндпоинт», и только на него. Она не является оценкой соответствия требованиям и не заменяет проверку безопасности. Из того, что API работает с идентификационными данными, не следует автоматически ни вывод о регуляторной адекватности, ни утверждение, что конкретная интеграция что-то нарушает. Это архитектурная позиция, а не факт из источников.

Классификация также не даёт тебе гарантий по регионам. Да, по документации (S1, S4, S6-факт) sg-api.advance.ai - лишь один из параллельных региональных базовых URL: рядом живут ph-api.advance.ai, api.advance.ai для Индонезии и другие страновые префиксы с тем же самым shape эндпоинта. Это подтверждает, что перед тобой регионально развёрнутый сервис идентификации, а не единая глобальная inference-точка генеративной модели. Но точный паритет фич между регионами, лимиты и гарантии резидентности данных в прочитанных страницах не документированы - и утверждать их нельзя.

Чего карта тем более не делает - не подтверждает цены, SLA и сертификации. Pricing, SOC2/ISO, юрисдикционные комплаенс-заявления в изученном материале не найдены и вынесены за рамки. Если кто-то в проектной переписке ссылается на них как на «очевидные», это повод запросить первичный документ, а не принять на веру.

Наконец, есть предел самого метода. Классификация надёжна ровно настолько, насколько полна первичная документация. Провал наступает в трёх случаях: документации нет; назначение или тип данных не удаётся классифицировать; требования интеграции противоречат друг другу. В любом из них честный ответ - «пока не выделяю контур, потому что не подтвердил свойства», а не «на всякий случай считаю LLM».

Какое решение принять архитектору?

Свожу к решению. Раз первичная документация подтверждает identity/OCR-назначение, чувствительные поля документа и подписанную авторизацию, я проектирую под этот эндпоинт отдельный защищённый контур для идентификационных данных. Принятая цена решения понятна: разделение усложняет систему. Появляется вторая модель авторизации, отдельное хранилище для secretKey, свои правила логирования полей вроде idNumber. Это плата за то, чтобы не смешивать чувствительные данные с LLM-задачей.

Альтернатива - закинуть get-result в общий LLM-роутинг вместе с чатами и суммаризацией - выглядит дешевле ровно до первого разбора, где выясняется, что через тот же слой, что и безобидные промпты, текут поля паспорта под bearer-ключом в общем секрет-менеджере. Я отвергаю этот вариант не из перестраховки, а по критерию: назначение эндпоинта подтверждено, тип данных подтверждён, значит контур обязан быть отдельным. Если бы назначение не подтвердилось документацией - основания разделять исчезли бы, и я не стал бы усложнять систему ради красивой схемы.

Честно про уверенность. Установлено: назначение, данные, авторизация и требования - по первичной документации на 2026-07-18. Вероятно, но мягче: карта корректно разводит identity/OCR и LLM как разные контуры - это устойчивая, но всё же авторская модель. Неизвестно: точные обязательства конкретно твоей интеграции до чтения твоей же документации и договора. Классификацию нужно завершить до выбора контура и до первой передачи данных, потому что переклассифицировать работающий продакшн дороже, чем один раз прочитать доку.

Где здесь вообще место LLM-провайдеру?

Разделив контуры, легко впасть в обратную крайность и решить, что генеративные модели тут не нужны вовсе. Нужны, но в своём контуре и на своей задаче: подсказки оператору, черновики писем клиенту, разметка внутренних тикетов. Это ровно тот слой, где имеет смысл единый совместимый API вместо зоопарка ключей.

Здесь practical-интеграция для российской команды. provod.ai даёт один API, совместимый с SDK OpenAI и Anthropic: меняешь ключ и base_url - и работаешь с полным каталогом моделей из рыночных клиентов, агентов, IDE, ботов и бизнес-систем, поддерживающих OpenAI- или Anthropic-совместимые эндпоинты. Оплата - один рублёвый баланс, российская карта, СБП или счёт, без VPN и зарубежных карт; цены на модели идут без наценки provod.ai. Для команды пригодятся общие рабочие пространства с участниками, общими ключами и единым балансом организации, а стабильный мультиканальный роутинг держит работу, когда один внешний канал временно недоступен (сравнить под свой сценарий).

# LLM-контур: OpenAI-совместимый клиент, только генеративные задачи from openai import OpenAI

client = OpenAI( api\_key="provod\_...", base\_url="https://api.provod.ai/v1", )

Граница жёсткая, и я её проговариваю. provod.ai - это отдельный совместимый LLM API, а не замена identity/OCR-эндпоинту ADVANCE.AI. Он не делает eKYC, не извлекает поля документа и не выносит вердикт о подделке. Для команд, работающих с персональными данными, у provod.ai есть защищённый российский контур, который маскирует прямые персональные идентификаторы перед отправкой запроса во внешнюю модель и поддерживает процессы по 152-ФЗ, - но это про генеративный контур, а не про подмену проверки документов. Держи две задачи на двух разных API, и карта из этой статьи останется читаемой.

Мини-FAQ

Можно ли слать промпт на sg-api.advance.ai? Нет. По документации ADVANCE.AI это result-fetching эндпоинт eKYC: вход - signatureId, выход - фиксированная схема полей документа и вердикт idForgery (S1, S2).

Чем авторизация отличается от LLM? Двухшаговый подписанный токен вместо bearer-ключа: generate-token с подписью SHA-256, затем заголовок X-ACCESS-TOKEN; secretKey в запросах не передаётся (S2, S3).

Что искали люди, попадая сюда по ошибке? Часто это запросы вроде https sg api advance ai в надежде открыть генеративную модель - полезная регрессионная фикстура, показывающая, как классификация по имени хоста подводит.

Значит ли identity/OCR-класс, что интеграция соответствует требованиям? Нет. Классификация - не оценка соответствия и не проверка безопасности; регуляторную адекватность из неё выводить нельзя.

Одинаковы ли регионы sg/ph/id? Структурно путь один и тот же на разных хостах (S1, S4), но паритет фич, лимиты и резидентность данных в прочитанных страницах не документированы.

provod.ai — модели для IDE, SDK и внутренних инструментов

Не заставляйте разработчиков менять рабочую среду: OpenAI-совместимые IDE, библиотеки и приложения подключаются к общему endpoint, а команда продолжает работать привычными командами и SDK.

В одном каталоге — актуальные модели для текста и медиа: 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-ФЗ · инструкция по миграции

Источники

• ADVANCE.AI Doc Center, Document Verification Get Result API, обращение 2026-07-18 (F1, F2, F6, F8).
• ADVANCE.AI Doc Center, Common Token Authentication API, обращение 2026-07-18 (F3, F4).
• ADVANCE.AI Documentation, Global Document Verification, обращение 2026-07-18 (F3, F5).
• ADVANCE.AI, One-Stop Documentation mirror (ReadMe.io), обращение 2026-07-18 (F2, F6).
• ADVANCE.AI, публичная страница продукта AdvanGuard, обращение 2026-07-18 (F7).
• Факты о продукте provod.ai и заявление о лидерстве - данные вендора, 2026-07-15.