On-premise ИИ в регулируемых отраслях: что реально требует локализация данных в Узбекистане

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

Оговорка сразу: это полевая сводка инженерной компании, а не юридическая консультация. Последнее слово за вашим комплаенсом.

Правовая база

Закон Республики Узбекистан «О персональных данных» (ЗРУ-547) регулирует обработку персональных данных, а его статья 27-1 задаёт правило локализации: персональные данные граждан Узбекистана в определённых случаях должны записываться, храниться и обрабатываться на технических средствах, физически размещённых в стране, в зарегистрированных базах данных.

Для бизнеса, внедряющего ИИ-ассистента, операционный вопрос прям: когда клиент вводит в чат имя и телефон, какие серверы касаются этого сообщения. Если в ответе есть инференс-API в чужой юрисдикции, у вас впереди разговор о потоках данных с юристами, договорами с провайдерами и, возможно, с регулятором.

Три позы, которые мы видим

Облако с локальным якорем: сайт и базы живут на серверах в Узбекистане, а ИИ-слой спроектирован так, чтобы наружу к модели уходил минимум, по возможности обезличенный. Рабочий вариант для многих коммерческих внедрений; требует аккуратности в содержимом промптов.

Гибрид: клиентские данные и база знаний остаются локально; к внешней модели уходят только вычищенные, неидентифицирующие фрагменты. Лучше, и часто это прагматичная середина для чувствительных к затратам бизнесов с умеренными рисками.

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

Что реально нужно для on-premise

Железо, посчитанное честно. Ассистент поддержки на несколько сотен диалогов в день спокойно живёт на одном GPU-сервере; кластер для старта не нужен, а кто настаивает, тот продаёт вам кластер.

Открытые модели, замеренные на ваших вопросах. В приземлённых задачах (ответы по вашим документам) хорошо подобранные открытые модели работают близко к облачному качеству. Значимый бенчмарк — сотня ваших настоящих клиентских вопросов до принятия решения, а не таблица лидеров.

Интеграция внутри контура: SSO, сегментация сети, аудит-логи, ролевой доступ по вашим политикам. И документация такого качества, чтобы систему могла вести ваша собственная команда, потому что для этого класса клиентов зависимость от подрядчика — сама по себе замечание аудита.

Разговор о деньгах

On-premise дороже на входе и дешевле за диалог навсегда после. Точка окупаемости зависит от объёма, но решение редко упирается в юнит-экономику; оно упирается в то, внедряемо ли вообще альтернативное решение. Система, не прошедшая проверку безопасности, стоит бесконечно за диалог.

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