Как внедрить ИИ в холдинге и не потерять контроль над данными

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

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

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

Именно такой подход нужен и казахстанским компаниям. Вопрос следует ставить не так: «можно ли использовать ChatGPT, Claude, Codex или другую модель?». Правильный вопрос звучит иначе: какую информацию компания вправе передать конкретной системе, для какой цели, где эта информация будет обработана и какие средства контроля сохранятся у компании?

Почему запрет обычно не решает проблему

У компании есть два простых, но одинаково слабых сценария.

• Первый — полностью запретить внешние ИИ-сервисы. Такой запрет не устраняет потребность сотрудников в инструменте. Если официальной альтернативы нет, часть работы переходит в личные учётные записи и неконтролируемые приложения. Компания не видит, какие документы были загружены, где они сохранились и использовались ли они для улучшения сервиса.
• Второй — купить корпоративные подписки и считать вопрос закрытым. Корпоративный тариф обычно улучшает договорные условия, управление доступом и защиту информации, но сам по себе не даёт компании права передавать любые данные. Отдельно остаются ограничения закона, договоров с клиентами и контрагентами, режима коммерческой или профессиональной тайны, а также внутренние правила доступа.

Следовательно, контролируемое внедрение требует не одного запрета или одной лицензии, а сочетания четырёх элементов:

1. правового основания для обработки и передачи информации;

2. подходящей архитектуры и места обработки;

3. договорных гарантий поставщика и всей цепочки его субподрядчиков;

4. внутренних правил, технических ограничений и проверки результата человеком.

Как это решают компании в США и Европе

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

Allen & Overy, ныне A&O Shearman, предоставила сотрудникам доступ к Harvey, а затем совместно с Harvey и Microsoftразработала ContractMatrix на базе Azure OpenAI. Linklaters и White & Case используют Legora. Clifford Chance и Freshfieldsсоздавали собственные защищённые точки доступа к внешним моделям.

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

Собственная фундаментальная модель для этого не обязательна. Harvey, например, использует модели нескольких поставщиков, но требует от них нулевого хранения переданных запросов, запрета обучения на данных клиентов и отсутствия человеческого просмотра. Данные клиентов логически разделяются, права пользователей разграничиваются, а перечень субподрядчиков и мест обработки раскрывается заранее.

Здесь важна не конкретная марка платформы, а модель управления:

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

Такой же подход прослеживается в рекомендациях профессиональных регуляторов. Заключение № 512 Американской ассоциации юристов требует учитывать конфиденциальность, компетентность, надзор и проверку результата. Если использование конкретного инструмента предполагает раскрытие сведений клиента и создаёт существенный риск, может потребоваться информированное согласие; общей формальной оговорки для этого не всегда достаточно. Британский регулятор солиситоров также обращает внимание на защищённую среду, ограничение хранения, запрет несанкционированного обучения и ответственность юриста за результат.

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

Какие вопросы необходимо разрешить до запуска? 

Юридическую и техническую проверку удобно строить не вокруг названия модели, а вокруг конкретного сценария использования.

• Какие данные получит система. Нужно определить не только тип документа, но и фактическое содержание. Один договор может одновременно включать персональные данные, коммерческую тайну, банковские реквизиты, сведения клиента и внутреннюю правовую позицию. Репозиторий может содержать не только исходный код, но и ключи доступа, журналы, данные тестовых пользователей и конфигурацию инфраструктуры.
  
• Имеет ли компания право передать эти данные. Безопасность поставщика не заменяет полномочие на передачу. Запрет обучения, шифрование и нулевое хранение отвечают на вопрос, что поставщик сделает после получения информации. Они не отменяют запрет в договоре с клиентом, обязанность сохранять профессиональную тайну или необходимость получить согласие субъекта персональных данных.
  
• Где и как будут обрабатываться данные. Следует различать хранение, трансграничную передачу и техническую обработку запроса. Данные могут не сохраняться поставщиком после завершения сессии, но всё равно передаваться и обрабатываться за рубежом. Нулевое хранение уменьшает риск, однако не превращает иностранную обработку в локальную.
  
• Кто входит в цепочку поставщиков. Корпоративная платформа может использовать облачную инфраструктуру, несколько моделей, сервис распознавания документов, модуль поиска и средства мониторинга. Проверять нужно не только основного контрагента, но и применимых субподрядчиков, регионы их работы, возможность их замены и порядок уведомления клиента.
  
• Какие полномочия получает инструмент. Обычный чат получает текст, который пользователь вставил вручную. ИИ-агент может читать папки и репозитории, выполнять команды, изменять файлы, обращаться к внешним ресурсам и использовать секреты из рабочей среды. Для каждого действия должны отдельно определяться права на чтение, запись, выполнение команд и выход в сеть.
  
• Кто проверяет результат и отвечает за решение. Языковая модель может подготовить проект договора, сводку или рекомендацию, но проверка не должна быть формальной. Чем выше влияние результата на права человека, деньги компании или безопасность системы, тем более содержательным должен быть человеческий контроль. Пользователь должен понимать ограничения модели и иметь доступ к первичным материалам, по которым проверяется ответ.

Казахстанское право, что необходимо учесть? 

Конфиденциальность договора и коммерческая тайна не одно и то же. 

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

Второй уровень — установленный компанией режим коммерческой тайны. По статье 126 Гражданского кодекса информация должна иметь коммерческую ценность вследствие неизвестности третьим лицам, не быть свободно доступной и охраняться её обладателем. Статья 28 Предпринимательского кодекса предполагает, что компания определяет перечень таких сведений, круг допущенных лиц и порядок обращения с ними.

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

В новых договорах полезно заранее предусматривать технологически нейтральное право привлекать проверенных поставщиков. Например:

Сторона вправе предоставлять конфиденциальную информацию проверенным поставщикам технологий, облачных сервисов, обработчикам и субподрядчикам исключительно в объёме, необходимом для исполнения договора, при условии принятия ими обязательств по конфиденциальности и безопасности не менее строгих, чем предусмотренные договором, запрета самостоятельного использования информации и сохранения ответственности Стороны за действия таких лиц.

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

Открытая закрытая и локальная система юридические категории

Статья 17 Закона Республики Казахстан «Об искусственном интеллекте» делит системы по режиму использования на открытые, закрытые и локальные.

Открытой признаётся система, архитектура и параметры которой доступны для свободного использования, модификации и распространения. В закрытой системе доступ к архитектуре и параметрам ограничивает собственник или владелец. Поэтому ChatGPT или Claude корректнее рассматривать как закрытые системы, а не как «открытые» только потому, что ими можно пользоваться через интернет.

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

Закон связывает локальные системы с обработкой данных, доступ к которым ограничен законодательством, и с иными случаями, когда подключённые к публичным сетям системы использовать нельзя. Поэтому одной маркетинговой характеристики «private» или «enterprise» недостаточно: нужно оценивать фактическую архитектуру.

Персональные данные хранение и передача проверяются отдельно

Пункт 2 статьи 12 Закона «О персональных данных и их защите» требует хранить персональные данные в базе и (или) цифровом объекте, находящихся на территории Казахстана. Норма распространяется именно на фактическое место хранения. Она не даёт безопасного основания считать постоянную зарубежную копию допустимой только потому, что основная база находится в Казахстане.

Если запрос с персональными данными направляется иностранному поставщику, отдельно возникает вопрос трансграничной передачи по статье 16. Нулевое хранение не исключает сам факт передачи и обработки за рубежом. Для государств, не обеспечивающих защиту персональных данных, закон предусматривает специальные основания, включая согласие субъекта, а также иные прямо названные случаи. Следовательно, одного общего упоминания зарубежного облака в политике конфиденциальности может быть недостаточно.

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

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

• есть ли в запросе персональные данные;
• можно ли достичь цели без них;
• на каком основании они обрабатываются и передаются;
• где находится основная система хранения;
• сохраняет ли поставщик запросы и на какой срок;
• какие государства и субподрядчики участвуют в обработке;
• можно ли до передачи провести настоящее обезличивание.

При этом простая замена ФИО или ИИН условным обозначением не всегда является обезличиванием в юридическом смысле. Закон исходит из невозможности определить принадлежность данных конкретному субъекту. Если человека можно восстановить по контексту, сумме сделки, должности или сохранённой таблице соответствий, речь может идти лишь о снижении риска или псевдонимизации.

Три контура вместо одного универсального доступа

Для крупной организации практичнее не делить все сервисы на «разрешённые» и «запрещённые», а установить несколько режимов использования.

Контур 1. Общедоступные и надёжно обезличенные данные. 

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

Контур 2. Контролируемая корпоративная обработка. 

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

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

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

Контур 3. Локальная обработка. 

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

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

Практическая последовательность внедрения

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

1. Выбрать несколько полезных сценариев. Например, подготовку проектов документов, поиск по внутренней базе знаний или помощь разработчикам.

2. Составить карту данных и полномочий. Определить, какие сведения попадут в систему и на каком основании компания ими распоряжается.

3. Отнести каждый сценарий к контуру. Не пытаться одним сервисом обработать одновременно публичные материалы и сведения с законодательным ограничением доступа.

4. Проверить поставщика и всю цепочку обработки. Зафиксировать модели, субподрядчиков, регионы, хранение, обучение, человеческий доступ и порядок удаления.

5. Согласовать договоры. Урегулировать конфиденциальность, персональные данные, аудит, уведомление об инцидентах, изменение субподрядчиков и прекращение сервиса.

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

7. Принять внутренние правила и обучить сотрудников. Короткая понятная инструкция обычно полезнее общего запрета на несколько страниц.

8. Запустить ограниченный пилот и пересмотреть риски. Оценивать нужно не только качество ответов, но и реальные данные, которые пользователи пытались передать, ошибки модели и работу мер контроля.

Вместо вывода

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

Международный опыт показывает, что для внедрения не нужна собственная фундаментальная модель. Нужна управляемая система: понятные категории данных, право на их обработку, проверенная цепочка поставщиков, корпоративная точка доступа, разграничение полномочий и ответственность человека за результат.

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

Задача юриста в таком проекте — не остановить технологию и не выдать абстрактное разрешение. Его задача — вместе с ИТ, информационной безопасностью и бизнесом определить допустимый маршрут для каждого типа данных. Тогда ИИ становится не исключением из корпоративных правил, а ещё одной управляемой частью инфраструктуры.

Материал подготовлен по состоянию на 8 октября 2026 года и носит общий информационный характер. Он не заменяет анализ конкретной системы, договора или сценария обработки данных.