API, своя инфраструктура или гибрид: как регулируемой компании построить обработку документов на LLM и кто доводит такие системы до прода

Регулируемая компания может обрабатывать документы с помощью LLM через API провайдера по договору, на собственных серверах или в гибридной схеме, которая сочетает оба варианта. Если все классы документов могут уходить наружу по договору, используйте API, а если ни один не может — свою инфраструктуру. Гибрид окупается, только когда по обе стороны оказывается много документов, потому что вы эксплуатируете две системы и отвечаете за таблицу маршрутизации. Чтобы понять, какие компании действительно довели такую систему до прода, попросите показать записи, которые она после себя оставляет.

Чем различаются три подхода?

Подробно их сравнивает статья о закрытом периметре, ссылка на которую дана выше. При работе через API провайдера ваши данные защищают договор и те меры контроля данных, которые провайдер берёт на себя. На странице OpenAI о контроле данных (прочитана 8 октября 2026 года) сказано, что данные, отправленные в её API начиная с 1 марта 2023 года, не используются для обучения, если вы сами на это не согласились.

На той же странице сказано, что логи мониторинга злоупотреблений, по которым OpenAI выявляет недопустимое использование и которые могут содержать промпты и ответы, по умолчанию хранятся до 30 дней. Дольше их хранят, если этого требует закон или если это обоснованно необходимо, чтобы защитить от вреда сервисы OpenAI или других. Чтобы ваш контент не попадал в эти логи, нужно предварительное одобрение OpenAI.

В управляемом сервисе моделей облачной платформы модель за вас эксплуатирует облачная компания, и часть её моделей продаётся в рамках облачного договора, который у вас, возможно, уже есть. В документации Microsoft сказано, что для моделей, которые продаёт Azure, ваши промпты и ответы модели недоступны OpenAI и другим провайдерам этих моделей. В документации Amazon Bedrock сказано, что у провайдеров моделей нет доступа к промптам клиентов и ответам модели. Модель всё равно работает на серверах облака, и считается ли это нахождением внутри вашего периметра, то есть сети и систем, которые контролирует ваша компания, решает ваша команда по рискам.

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

Как гибридная схема выглядит на практике?

Гибрид объединяет в одном пайплайне внешний маршрут (API провайдера или управляемый облачный сервис) и внутренний. Логику, которая решает, куда отправить каждый документ, называют маршрутизатором. Базовых схем три, и их можно сочетать:

• Публичные или малорисковые документы, например опубликованные правила и разъяснения, идут в API, а документы, удостоверяющие личность клиентов, остаются внутри
• Каждый документ сначала идёт в модель на своей инфраструктуре, а те, с которыми она не справилась, уходят наружу, только если это позволяет их класс
• Идентификаторы, например имена, заменяются условными метками внутри периметра, прежде чем текст уйдёт в API

Кто решает, какие документы можно отправлять в API?

Решают риск-менеджмент или специалисты по защите данных, а инженеры воплощают это решение в коде. Сначала запишите его на бумаге в виде короткой таблицы, которая здесь называется таблицей маршрутизации. Для каждого класса документов в ней указаны разрешённые маршруты, обязательно ли маскирование и как долго провайдер может хранить текст.

Затем пайплайн должен определить класс каждого документа. Сигналы, которые вы контролируете, надёжнее суждения модели: канал, по которому пришёл документ, отправитель, тип документа. Если сигналы расходятся, побеждает более строгий класс, а документ, который никто не может классифицировать, остаётся внутри.

Эта проверка выполняется внутри периметра. Проверка, которая спрашивает у внешнего API, можно ли выпустить документ, уже его отправила. Изменение таблицы маршрутизации проходит ревью и получает номер версии и дату, как любое изменение кода.

Можно ли замаскировать текст и всё-таки отправить его в API?

Иногда и с ограничениями. Open-source инструменты вроде Presidio заменяют имена, номера счетов и другие идентификаторы условными метками или шифруют их ключом. Если ключ хранится внутри, шаг расшифровки в Presidio возвращает реальные значения, когда приходит ответ; при замене метками вы ведёте собственную таблицу соответствия меток и значений. Данные, замаскированные таким образом, называются псевдонимизированными.

Европейский совет по защите данных (EDPB) 16 января 2025 года принял Руководящие принципы 01/2025 о псевдонимизации в редакции для публичного обсуждения. В них сказано, что такие данные по-прежнему считаются персональными, если дополнительная информация позволяет связать их с человеком. Там же добавлено, что это верно и тогда, когда замаскированный текст и эта информация находятся у разных сторон, например текст у провайдера, а таблица или ключ у вас.

Суд ЕС рассмотрел тот же вопрос в сентябре 2025 года в деле C-413/23 P, которое касалось правил защиты данных для органов ЕС. Суд указал, что псевдонимизированные данные не во всех случаях и не для всех лиц являются персональными: в зависимости от обстоятельств маскирование может не позволить никому, кроме компании, замаскировавшей данные, установить, о ком в них идёт речь. Для вас, раз таблица или ключ у вас, данные остаются персональными. Что из этого следует для ваших договоров, спросите у своего юриста по защите данных.

Второе ограничение — обнаружение. Presidio находит персональные данные с помощью модели, которая распознаёт имена людей, названия мест и организаций, и с помощью правил, которые ищут известные форматы, например номера счетов. В его документации сказано, что, поскольку обнаружение автоматическое, «нет гарантии, что Presidio найдёт всю чувствительную информацию». Типичные пропуски при работе с документами:

• Оптическое распознавание символов (OCR), то есть этап, на котором сканы превращаются в текст, искажает имя, и детектор больше не видит в нём имени
• Человека можно установить и без имени: по должности в небольшой компании или по уникальной сумме в определённую дату
• Замаскировано как раз нужное поле: если задача — извлечь наименование контрагента, в замаскированном тексте его уже нет

Прежде чем кто-то одобрит маршрут с маскированием, поручите людям вручную разметить все идентификаторы на выборке ваших собственных документов, а затем посчитайте, что пропустил детектор.

Что происходит, когда документ уходит не туда?

В гибриде утечка — это ошибка маршрутизации. Скан паспорта, приложенный к обычному уведомлению, или сообщение клиента, процитированное внизу пересланного письма, может унести закрытое содержимое на внешний маршрут. Классифицируйте каждое вложение отдельно, а процитированную историю переписки считайте частью содержимого.

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

Если документ всё же ушёл наружу по ошибке, журнал маршрутов покажет, какие документы ушли, когда и к какому провайдеру. Договор с провайдером покажет, как долго он может их хранить. Разбирайте это как инцидент вместе с командой по защите данных: она решает, нужно ли о нём уведомлять.

Как проверять качество, когда работу делают две модели?

Приёмочный набор — это подборка реальных документов с правильным ответом для каждого, по которой решают, проходит ли система проверку. Две модели в гибриде отвечают по-разному, поэтому одна оценка на весь пайплайн скрывает более слабый маршрут.

К тому же модель в API нельзя проверить на закрытых документах, потому что отправлять их туда нельзя. Поэтому общий приёмочный набор, который статья о закрытом периметре рекомендует для всех маршрутов, может содержать только документы, разрешённые на обоих маршрутах. Сравнивайте на нём две модели, а каждому маршруту дайте собственный, более крупный набор из классов, которые он обрабатывает. Когда провайдер выводит модель API из эксплуатации, этот маршрут оценивают заново до переключения.

Что нужно, чтобы эксплуатировать оба маршрута?

Гибрид удваивает договоры: условия провайдера и соглашение об обработке данных плюс договор на оборудование или облако, на котором работает модель на своей инфраструктуре. Европейское банковское управление (EBA) отмечает, что DORA, Регламент ЕС о цифровой операционной устойчивости, применяется с 17 января 2025 года. Финансовые организации ЕС, подпадающие под его действие, обязаны вести реестр своих договорных соглашений со сторонними поставщиками ИКТ-услуг (информационно-коммуникационных технологий). Подключение внешнего провайдера модели — вопрос для этого реестра, и отвечает на него ваша служба комплаенса.

Эксплуатация тоже удваивается. Провайдер ограничивает число запросов в минуту и выводит модели из эксплуатации по своему графику, так что за тем и другим кто-то должен следить. Собственным серверам нужны планирование мощностей и ночной дежурный. Маршрутизатор и слой маскирования эксплуатируете только вы.

Каждый день следите за долей документов на каждом маршруте в разбивке по классам. Когда модель на своей инфраструктуре первой видит каждый документ, растущая доля, отправляемая в API, означает, что наружу уходит больше документов и счёт за API растёт. Часто причина — новый шаблон документа, который внутренняя модель не может прочитать.

Что должен показывать аудиторский след по каждому документу?

Храните класс документа и сигналы, по которым он определён, версию таблицы маршрутизации и выбранный маршрут. Добавьте, маскировался ли документ и какой версией детектора, а также провайдера и точную версию модели, которая дала ответ. С такой записью «показать все документы этого класса, которые покинули периметр в прошлом квартале» — это один запрос к базе данных.

Когда гибрид — неправильный выбор?

Одного маршрута достаточно, если все ваши документы относятся к одному классу данных. При небольшом объёме второй маршрут обходится дороже, чем экономит, а то, что модель на своей инфраструктуре не может прочитать, способен обработать человек. Гибрид также наследует любой пробел в ночных дежурствах по собственным серверам. А если управляемый облачный сервис в вашем регионе удовлетворяет требованиям для каждого класса, он даёт вам один договор и один контур эксплуатации.

Как проверить, что компания довела такую систему от пилота до прода?

Эта статья не составляет рейтинга компаний, потому что любая компания может написать на своём сайте «AI в продакшене». Система в проде оставляет записи, которых у пилота нет, поэтому попросите показать их, убрав данные клиентов.

• Таблица маршрутизации как версионируемый документ и имя человека, который утверждает изменения
• Несколько строк журнала маршрутов с классом, маршрутом, версией таблицы маршрутизации и версией модели для каждого документа
• Последний прогон теста, который направляет закрытый документ к внешнему провайдеру и показывает, что документ останавливается
• Оценки на приёмочном наборе для каждого маршрута и релиза, включая релиз, выпущенный, когда провайдер вывел модель из эксплуатации
• Если схема маскирует текст — измеренные пропуски детектора на собственных документах клиента
• Runbook (письменные инструкции для операторов) на случай отказа каждого маршрута и сведения о том, кто дежурит
• Созвон с человеком, который эксплуатирует систему сегодня

Какие тревожные сигналы?

• Маскирование предлагают как полный ответ на вопрос о приватности, без измеренной доли пропусков
• Проверка, которая решает, что можно выпускать наружу, обращается к самому внешнему API
• Когда внутренняя модель не работает, трафик переключается на API и уносит с собой закрытые документы
• Нет оценки по каждому маршруту, есть только одна цифра точности на весь пайплайн

Где здесь место amBrain?

Единственный проект с языковой моделью, который amBrain описывает публично, таков: «Мы вывели интеграцию LLM в прод внутри FinTech-периметра клиента: извлечение и нормализация неструктурированных уведомлений брокеров и торговых площадок — о корпоративных действиях, изменениях по инструментам и марже — в структурированные записи, которые потребляет торговая система».

Эта статья — не кейс: клиент не называется, а где работала модель в том проекте, не раскрывается. Статья не утверждает, что amBrain строил для какого-либо клиента гибридную схему, слой маскирования или маршрутизатор, и не приводит ни цен, ни сроков.

amBrain берёт на себя проекты, застрявшие у другой команды, и доводит их до продакшена.

amBrain делает софт с 2019 года. Компания работает в трёх форматах: полная разработка, выделенная команда или инженеры внутри вашей команды. Клиент сохраняет полное владение продуктом и кодом, кроме переиспользуемых компонентов amBrain.

Если вы взвешиваете эти варианты, приходите с классами своих документов и списком записей выше в каждую компанию, с которой говорите, включая amBrain.

Частые вопросы

• Позволяет ли маскирование отправлять в API любой документ? Нет. Замаскированный текст, который вы можете связать с человеком, для вас остаётся персональными данными, а детекторы пропускают часть идентификаторов. Используйте маскирование, чтобы раскрывать меньше данных в тех классах, которым уже разрешено уходить наружу
• Может ли модель на своей инфраструктуре сравниться по качеству с моделью в API? На некоторых типах документов — да. Оцените обе на общем наборе документов, разрешённых на обоих маршрутах, прежде чем решать, как распределить работу
• Можно ли начать с одного маршрута и добавить второй позже? Да, и часто это более дешёвый путь. Постройте маршрутизатор и журнал маршрутов с первого дня, чтобы добавление второго маршрута потом не требовало перестраивать пайплайн