Евгений Наумов

Спасибо большое за поддержку!! Да, роутинг - одна из ключевых фич. По управлению приоритетами: можно передать objective в metadata - cheapest, fastest, reliable или balanced - и маршрутизатор подберёт модель под нужный критерий. Плюс есть allowed_models и blocked_models, если хочется ограничить пул конкретными провайдерами или моделями. Подробнее расписали здесь: https://docs.alltokens.ru/concepts/auto-router

Спасибо большое за Вашу поддержку!

Сразу встречный вопрос: Если 7Eleven и другие магазины начнут работать в РФ - Магнит, Пятерочка и другие просто закроются? Ценность решения можно понять изучив наш сайт и попробовав его в деле)

Спасибо большое за поддержку! Очень рад слышать!

Понимаю Вас, последнее время токены летят только шуба веет😅 У нас вы можете прозрачно отслеживать расходы, есть аналитика по расходам, токенам, запросам, можно смотреть метаданные каждого запроса, сколько стоил, сколько токенов и тд и тп

Если брать совокупные траты на иностранные карты, переводы, конвертации, комиссии, нервы, блокировки, vpn и тд - то да, мы дешевле Но даже при этом ценность проекта не в конкретном прокси, а в экосистеме, которая вокруг него строится и будет строиться. А если сравнивать напрямую (как многие делают), что ошибочно, то может показаться дороже на первый взгляд

Мы не совсем прокси, мы уже поняли проблему нашего позиционирования, кроме openrouter у нас подключены многие провайдеры напрямую, также собственный мониторинг SLA, собственный роутер, можно много перечислять) Дальше только больше, планируем добавить целый инструментарий для разработчиков и команд, также сейчас в разработке еще один проект, который будет в экосистеме AllTokens, но об этом чуть попозже)

Ограничение для бесплатных моделей сейчас по запросам, а не по токенам: chat/completions, responses, images/generations, completions - 30 запросов в минуту embeddings - 60 запросов в минуту лимит считается на пользователя/API key, только для аккаунтов с нулевым или отрицательным балансом плюс у бесплатных моделей может плавать доступность и latency

«все же четкие рекомендации должны давать компетентные профессионалы после глубокой аналитики и погружения в проект» Полностью с Вами согласен 👍

Добрый день! Прошу заметить важный момент: Мои наблюдения и замечания были написаны в ответ на нападки на мой проект, мне не очень хотелось ни атаковать ни получать атаку в свою сторону Но в дальнейшем, после написания комментариев и под моим проектом и под текущим, мы пообщались с основателем и обсудили все вопросы На данный момент я не критиковал проект, а спорил с другим гражданином)

Спасибо большое! ☺️ Надеемся на крепкое сотрудничество 💪🏼

Утомили Вы меня) Отвечу Вам напоследок цитатой Марка Аврелия: «Если кто меня оскорбил - это его дело… у меня свой нрав.»

Да я уж понял, что Вам скучно, и хочется пообщаться, поспорить) Можете не продолжать, не ведусь на Ваши провокации)

Ахаха, вы мне привели не целевой документ, уважаемый) А пока что кроме воздуха от вас никакой конкретики, только догадки и были написаны Я вам прямые ссылки и номера законов частей пунктов отправлял, читайте, учитесь, пользуйтесь) И да) вы так и не ответили на пункты, которые я для вас специально подчеркнул)

Да редактировать сообщения я тоже умею)

"Что у вас в сервисе с трансграничной передачей ПДн?" - работаем в этом направлении

😂 А Вы забавный!
Не даёте ни одной ссылки ни на одну статью)
Честно говоря так лень Вам тут всё расписывать…) Но давайте попробую 1. Ваш главный тезис про «идентификация только в базах органов» «идентификация возможна только в официальной базе…»
 Это просто ваша выдумка. 
 В законе такого нет.

 По 152-ФЗ: биометрия - это данные, которые позволяют установить личность и используются для этого не написано ничего про госбазы не требуется «официальная система» достаточно, что оператор использует данные для идентификации Любая система (даже твоя локальная модель), если она сопоставляет «голос - человек» уже попадает. 

2. Ваш тезис «STT и диаризация не имеют отношения к биометрии»
Тут ситуация сложнее: Вы частично правы
Если:
просто перевод в текст «спикер 1/2/3» нет связи с личностью
 это может не считаться биометрией
 Это подтверждается позицией РКН: если нет процедуры установления личности - ст. 11 не применяется

Но вы делаете ложный обобщающий вывод: «вообще не имеет отношения» Это неправда Потому что: голос сам по себе - биометрический признак и становится биометрией в момент использования для идентификации То есть технология не равно статус данных

Решает цель обработки, а не «это STT значит можно»

 3. Ваш тезис «если обезличено - значит не биометрия» Тут тонкий момент Закон: данные считаются обезличенными, если нельзя определить субъект Но, если есть: аудио, голосовые эмбецдинги это равно возможность связать с пользователем (даже косвенно) это уже не полноценная анонимизация 
4. Ваш главный промах 
 «обрабатываем на лету значит не требуется согласие» Это противоречит самому определению обработки:
обработка включает использование и извлечение она происходит в момент анализа аудио (ст. 3 152-ФЗ)
 Удаление потом ничего не меняет)) 6. Ваш аргумент про колл-центры и видеохостинги Это классический «а вот у них же работает» 😂

 Ответ по букве закона: Колл-центры: обычно опираются на: ст. 6 - исполнение договора и не используют голос для идентификации Поэтому это не всегда биометрия Видеохостинги: хранят контент, но не обязаны идентифицировать по голосу

значит могут обходиться без ст. 11 7. Ваш аргумент про «минимизацию РКН» Да, принцип минимизации есть Но он: не отменяет требования закона
не заменяет письменное согласие Минимизация = собирай меньше
а не «можно без согласия»

У меня Вам совет - подучите матчасть, пожалуйста, прежде чем писать подобные комментарии Вот вы не разобрались а всё пишете и пишете) Ключевой момент из ст. 11: биометрия - это данные, используемые для установления личности Так? Так Идем дальше Если голос используется для ИДЕНТИФИКАЦИИ (voice ID, speaker recognition (опа), биометрическая аутентификация) это биометрические ПДн нужно письменное согласие а что такое диаризация? подскажите пожалуйста) А, это как раз идентификация голоса Это серая область, но с очень тонкой гранью Но добавляем к этому всему привязку к конкретному человеку и получаем биометрические ПДн как только результаты диаризации начинают использоваться для идентификации или связываются с конкретным человеком это подпадает под ст. 11 152-ФЗ как обработка биометрических ПДн Один и тот же голос может быть как биометрией, так и не быть ею в зависимости от того, используется ли он для идентификации А это серая зона, тут уже не ко мне, смотря как обрабатываются данные и для каких целей И вы изначально писали, цитирую: "Это не так, не для обработки требуется, а для хранения. Если сервис обрабатывает и сразу удаляет исходный аудио файл, то письменного согласия не требуется." То есть Вы сначала говорите про хранение (и говорите неверно), сейчас уже про обработку, вы уж определитесь пожалуйста)

Ст. 11 152-ФЗ, ч. 1: "Обработка специальных категорий персональных данных... а также биометрических персональных данных не допускается, за исключением случаев, предусмотренных частью 2 настоящей статьи." Ст. 11, ч. 2: "Обработка биометрических персональных данных может осуществляться только при наличии письменного согласия субъекта персональных данных..." Ключевое слово - обработка Не хранение Обработка А ст. 3 п. 3 152-ФЗ определяет обработку как: "любое действие (операция) или совокупность действий с персональными данными, включая сбор, запись, систематизацию, накопление, хранение, уточнение, извлечение, использование..." То есть STT-транскрипция аудиофайла это и есть использование биометрических ПДн Это обработка по определению закона То, что файл потом удаляется не имеет значения: обработка уже произошла в момент, когда модель извлекала признаки из голоса Ваш тезис законодательно необоснован Вероятно Вы перепутали хранение с обработкой, тогда как хранение - это лишь один из видов обработки, а не её синоним письменное согласие требуется по ч. 1-2 ст. 11 152-ФЗ для любой обработки биометрии, включая однократную обработку "на лету" Галочка в форме это согласие по ст. 9, оно достаточно для обычных ПДн Для биометрии закон требует именно письменной формы (ч. 4 ст. 9: "в случаях, предусмотренных федеральными законами, обработка персональных данных осуществляется только с согласия в письменной форме")

Спасибо большое за поддержку!!🥹 Демо выкатим на днях!

Благодарю за внимание к проекту и конструктивный разбор! Берем в работу и исправим все недочёты!

Спасибо, что подсветили такой важный вопрос, мы всё тщательно перепроверим и исправим!

И Вам спасибо! Ваши замечания (в коментариях нашего проекта) мы тоже взяли в работу, проводим полный анализ и исправление проблем.

Главная дыра - конструкция "клиент-оператор, мы обработчик". Да, такая конструкция законна и применяется повсеместно. Но она работает только если: (а) клиент сам легально собрал биометрию с письменного согласия, (б) субъект был уведомлён о том, что данные передаются в Aiesa. Aiesa не верифицирует ни то, ни другое - она просто перекладывает ответственность в оферте. На практике большинство клиентов этого тоже не делают.

Так что, настойчиво и упорно заявлять о "соблюдении 152-ФЗ" легко) Соблюдать - уже не так-то просто) Я понимаю, что вы хотите создать российский аналог всем известных сервисов, и продвигать отечественное ПО. Это похвально, это поднимает (хоть и незначительно) локальный it рынок. Но прежде чем заявлять о соблюдении законов - стоит удостовериться, что законы соблюдены) Всё просто ;) А так - удачи вашему проекту! Кстати, такие проекты чаще всего и становятся нашими клиентами, когда собственной инфраструктуры становится недостаточно. Так что пишите, если будут вопросы или предложения)

Что сделано нормально Плюс Уведомление об инцидентах: 72 часа прописаны В DPA явно указан срок 72 часа - соответствует требованиям 152-ФЗ (изменения 2022 года). Плюс Не дообучают модели на данных клиентов Явно прописано в разд. 15.5 оферты. Снимает один из распространённых рисков для B2B.

В нашей платформе используется специализированный локальный детектор персональных данных и потенциальных нарушений, выступающий в роли серверного регулятора. То, что вы пишете про ваш продукт и 152 фз сильно расходится с реальностью И вот что выявила наша система: Критические нарушения 152-ФЗ Крит Биометрия без специального режима обработки Продукт - распознавание речи. Голос - это биометрические ПДн (ст. 11 152-ФЗ). Для их обработки требуется письменное согласие субъекта, а не просто галочка при регистрации. Aiesa принимает от клиентов аудиозаписи звонков, интервью, переговоров - в них чужие голоса без их ведома. В политике написано: "не используем для идентификации личности" - это не освобождает от обязанности соблюдать ст. 11. Обработка биометрии вообще требует письменного согласия. Уйти от этого через DPA с заказчиком нельзя, потому что согласие должен дать именно субъект. Крит Cookie-согласие не работает: аналитика грузится без выбора В политике написано (разд. 5.4.2): согласие на cookies выражается "продолжением использования Сайта". Это нарушение прямого требования регулятора. РКН в своих разъяснениях и судебная практика фиксируют: для аналитических cookies нужно активное, заранее полученное согласие с возможностью отказаться. Формула "продолжили - согласились" не является действительным согласием по ст. 9 152-ФЗ. Яндекс.Метрика с Вебвизором при этом уже запущена и пишет поведение. Крит Отсутствие уведомления в РКН Компания основана в 2025 году (ОГРН 1257700504907, зарегистрирована в 2025), сервис работает. По ст. 22 152-ФЗ оператор обязан до начала обработки уведомить Роскомнадзор. В реестре операторов РКН ООО «АЕСА» с ИНН 9707053099 - отсутствует (проверяется на pd.rkn.gov.ru). Это не техническая оговорка, это прямое административное нарушение (ч. 1 ст. 19.7 КоАП). Крит Запись телефонных звонков: согласие притянуто за уши Раздел 6 политики говорит: продолжение разговора после "автоматического уведомления" = согласие на запись. Но нет подтверждения, что уведомление реально воспроизводится - это декларация. Главное - такое "согласие" не является письменным согласием на обработку биометрии (голос = биометрия, см. выше). И передача записей в МТТ (субобработчик по звонкам) требует отдельного согласия субъекта на передачу третьему лицу. Крит Яндекс.Облако как субобработчик: двойная проблема Приложение 2 к оферте называет ООО «Яндекс.Облако» субобработчиком хранения данных. При этом Яндекс.Облако - самостоятельный оператор ПДн с собственной политикой. Заказчики Aiesa не уведомлены индивидуально о том, что их клиентские данные уходят в Яндекс.Облако - написано только "перечень может обновляться без уведомления заказчиков". Это противоречит ч. 3 ст. 6 152-ФЗ, требующей чётко определённого и согласованного поручения обработки. Крит Физические лица как заказчики: нет отдельного механизма согласия на обработку Сервис доступен физлицам (оферта прямо это допускает). Физлицо, загрузившее аудиофайл с голосами других людей, де-факто становится оператором ПДн третьих лиц. Aiesa не требует подтверждения наличия законного основания обработки — галочка "согласен с офертой" перекладывает всю ответственность. Это законно в B2B, но в B2C такая схема не защищает от регуляторных претензий к самой Aiesa. Спорные и слабые места Спорно Логи API "хранятся бессрочно" - без правового основания Раздел 8.4.4 оферты: "Логи запросов хранятся бессрочно". По ст. 5 152-ФЗ данные должны храниться не дольше, чем необходимо для цели обработки. Бессрочное хранение IP-адресов, метаданных запросов - это данные, позволяющие идентифицировать субъектов. "Техподдержка и биллинг" не дают права хранить их вечно. Спорно Ссылки на TikTok и Instagram как источники контента Aiesa принимает ссылки на TikTok/Instagram для скачивания и транскрипции. Instagram признан нежелательной организацией в РФ. Предоставление технического доступа к скачиванию контента оттуда создаёт правовые риски не только в плане ПДн, но и в контексте ФЗ-149 и решений Роскомнадзора. Спорно Срок хранения регданных: "3 года после удаления" без ссылки на норму Таблица сроков хранения ссылается на "исковую давность" как основание хранить регданные 3 года после закрытия аккаунта. Это законная практика, но в политике нет ссылки на конкретную норму — ГК ст. 196. Без этого РКН может квалифицировать как избыточное хранение. Спорно DPA акцептуется автоматически - без отдельного подписания По ч. 3 ст. 6 152-ФЗ поручение на обработку ПДн должно быть оформлено в виде документа. Aiesa говорит: акцепт оферты = акцепт DPA. Это серая зона — судебная практика неоднородна, но РКН такой подход критикует и требует явного двустороннего документа.

Понимаю вас, тогда логика участия вполне ясна. Успехов с привлечением инвестиций и развитием проекта! 🔥

Честно, выглядит уже не как стартап, а как сформировавшийся продукт с понятным позиционированием и набором функций. Отсюда вопрос: а зачем участвовать в рейтинге стартапов? Обычно такие площадки - про поиск модели, гипотез и первых пользователей, а у вас уже ощущение готового бизнеса. Сам продукт при этом воспринимается нормально, но контекст участия немного выбивает из общей картины. А так лайк!

Но спасибо за отзыв! Вы как раз напомнили о важной теме - внимании к персональным данным и архитектуре таких сервисов. Мы это учитываем: персональные данные не передаются наружу, используются технические идентификаторы, а сама логика выстроена с учётом требований к обработке и хранению.