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

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

Контекст в двух предложениях. Защита персональных данных закреплена в ст. 21 Конституции РК — вместе с формулировкой «в том числе с применением цифровых технологий», то есть норма писалась именно про сервисы и платформы. В январе 2026 года принят Цифровой кодекс РК, который задал общую рамку для цифровой среды, данных и алгоритмических систем, а отраслевой Закон РК «О персональных данных и их защите» (Закон о ПДн) за последние месяцы оброс конкретными и вполне «технарскими» обязанностями. Дальше — по ним.

Шесть требований, которые уже действуют:

1. База — в Казахстане. Ст. 12 Закона о ПДн: база с персональными данными должна находиться на территории РК. Для данных ограниченного доступа действующие правила идут дальше — сбор и обработка должны идти на объектах информатизации, размещённых в РК. Зарубежное облако само по себе не запрещено, но первичная база — здесь. На уровне архитектуры это означает: primary — в казахстанском контуре, за рубежом — то, что вы оформили как передачу с основанием.

2. Шифрование — не рекомендация, а норматив. Для персональных данных ограниченного доступа правила требуют хранения с применением средств криптографической защиты не ниже третьего уровня безопасности по СТ РК 1073-2007, а передачи — по защищённым каналам и (или) с шифрованием. Отдельная деталь, которую мало кто замечает: для баз более ста тысяч записей данных ограниченного доступа требуются средства идентификации и аутентификации пользователей, включая биометрическую. Если у вас растущий b2c-продукт, эта планка ближе, чем кажется.

3. Один рабочий день на уведомление об утечке. С момента обнаружения нарушения безопасности данных у собственника или оператора есть один рабочий день, чтобы уведомить уполномоченный орган (ст. 25 Закона о ПДн и правила уведомления). Один. Это означает, что классическая схема «сначала неделя внутреннего расследования, потом решим, говорить ли» — уже работать не будет. Нужен заранее написанный регламент реагирования: кто фиксирует время обнаружения, кто собирает состав инцидента, кто отправляет уведомление и по какому шаблону. Писать его в момент инцидента поздно.

4. Согласие уходит в сервисы контроля доступа. Согласие перестаёт быть галочкой в вашей форме. Закон вводит государственный и негосударственный сервисы контроля доступа к персональным данным — инфраструктуру, через которую субъект даёт и отзывает согласия. Принципиальный момент для интеграций: если ваш продукт взаимодействует с объектами информатизации госорганов (например, получает данные пользователя через госсистемы), интеграция с государственным сервисом — обязанность, а не опция (ст. 8-1 Закона о ПДн). Технически это ещё один внешний контур в вашей схеме авторизации согласий, и его стоит закладывать в роадмап заранее.

5. Автоматизированные решения — только с согласием и правом на возражение. Новая ст. 19-1 Закона о ПДн запрещает автоматизированную обработку данных, в результате которой у человека возникают, меняются или прекращаются права, без его согласия (либо вне случаев, прямо предусмотренных законами). Скоринг, автоматический отказ в услуге, профилирование с юридическими последствиями — это всё сюда. У пользователя есть право заявить возражение, у вас — три рабочих дня на его рассмотрение и обязанность объяснить порядок обработки. В ту же сторону смотрит и Цифровой кодекс: алгоритмические решения применяются с соблюдением прозрачности, недискриминации и возможности контроля со стороны человека. Если в продукте есть автопринятие решений по людям — в пайплайне должен быть предусмотрен человек и кнопка «пересмотреть».

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

Цена ошибки

Теперь о деньгах. Действующий максимум штрафа за несоблюдение требований по защите персональных данных — 2 000 МРП для крупных организаций, около 8,6 млн тенге. Эта планка — сама по себе результат недавнего утроения. И останавливаться на ней не планируют: в январе 2026 года в правительстве анонсировали повышение максимального штрафа до 5 000 МРП — это 21,6 млн тенге в ценах 2026 года — и введение уголовной ответственности за массовые утечки. Поправки пока разрабатываются и параметры могут измениться, но риторика регулятора однозначна — «нулевая терпимость», и эти меры прямо называются развитием конституционной нормы. 

Регуляторка не стоит на месте: свежий пример

Чтобы было понятно, с какой скоростью обновляются требования, — один пример из этого квартала. 20 апреля 2026 года АРРФР утвердило минимальные требования по информационной безопасности на финансовом рынке, они вводятся в действие с 12.07.2026. Внутри — вещи, которые ещё недавно считались добровольными best practices:

• персональная ответственность первого руководителя финансовой организации за информационную безопасность — прямо, отдельным пунктом;
• шифрование всех телеком-соединений, выходящих за периметр защиты;
• почтовые сервисы — только на инфраструктуре, физически размещённой в РК, с обязательными SPF, DKIM и DMARC;
• двухфакторная аутентификация для любого доступа извне периметра;
• дистанционная регистрация клиента — только с биометрической проверкой по государственной базе изображений либо с проверкой владения номером или ЭЦП;
• уведомление регулятора об инцидентах — незамедлительно, через специализированную систему.

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

Что пока в проекте

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

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

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

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