B2Shift · Опубликовано 3 августа 2026 г. · Обновлено 14 августа 2026 г.
Большинство инцидентов с AI в бизнесе — это не сбои модели. Это сбои доступа: система могла дотянуться до большего объёма данных, чем требовала задача, действовала без точки контроля и не оставляла следа. Меры, которые это предотвращают, — обычная инженерная практика, применённая осознанно.
Начните с минимизации данных и задокументированной цели
Автоматизация с учётом GDPR начинается до первой строки кода: запишите, для чего нужен процесс, какие персональные данные ему действительно требуются и сколько их нужно хранить. Затем приведите систему в соответствие. Доступными должны быть только поля и системы, которые процессу реально нужны, а не весь CRM потому, что так было проще выдать права.
Это одновременно самая дешёвая мера при внедрении и самая дорогая при доработке задним числом. Расширить доступ позже — изменение конфигурации; сузить его после года эксплуатации — значит выяснять, что тихо успело от него зависеть.
Поставьте контроль там, где нельзя отменить
Не каждый шаг требует подтверждения, а одинаковое отношение ко всем приучает людей прокликивать не глядя. Разделите действия по обратимости. Чтение, классификация, подготовка черновика и маршрутизация обычно могут идти без надзора. Отправка денег, публикация цен, ответ на жалобу, удаление записей и всё, что доходит до клиента от вашего имени, заслуживает подтверждения человеком или хотя бы окна, в котором человек успеет вмешаться.
Ролевой доступ относится к тому же разговору. Автоматизация должна действовать со своей идентичностью и своими правами, а не под заимствованной учётной записью администратора — это проблема и безопасности, и аудита, потому что потом в журналах никто не отличит человека от машины.
Сделайте каждое решение восстановимым
Каждое действие должно оставлять аудиторскую запись: что его запустило, какой контекст использовался, что решила система, с какой уверенностью, подтверждал ли человек и что в итоге изменилось. Это выглядит как нагрузка ради формальностей ровно до первого спора с клиентом — и тогда оказывается единственным, что отделяет вас от догадки.
Работа с уверенностью тоже здесь. У процесса должен быть явный путь для случаев с низкой уверенностью: к названному человеку или в очередь, а не молча к лучшему предположению. Желаемый сценарий отказа звучит как «это ушло человеку», а не «это ушло неправильно, и три недели никто не заметил».
Знайте, где работает модель и что она сохраняет
Задайте любому поставщику три вопроса: где обрабатываются данные, сохраняются ли они и используются ли для обучения. Ответы существенно различаются между потребительскими продуктами и бизнес-тарифами одного и того же вендора, а также между размещённым и частным развёртыванием. Для регулируемых данных выбор развёртывания — регионы ЕС, частный хостинг или собственные открытые модели — это решение о соответствии, а не предпочтение.
Заключение Европейского совета по защите данных о моделях ИИ — та справка, которую стоит прочитать до фиксации архитектуры; в нём разбирается, когда выходы моделей и обучающие данные вообще порождают обязанности по защите данных.
Чего технические меры не могут
Всё перечисленное снижает риск. Ничто из этого не создаёт правового основания для обработки, не пишет вашу политику конфиденциальности, не решает, нужна ли оценка воздействия, и не определяет вашу роль контролёра или обработчика. Это зависит от конкретного сценария и участников и требует юридической, а не инженерной проверки. Хорошие меры делают такую проверку простой; они её не заменяют.
Обсудить процесс