Как подойти к задаче без лишней магии
Что бы я делал, если бы сотрудник прислал договор в AI и сказал: «Там просто текст». Я бы сначала нарисовал путь данных: где документ появился, кто увидит историю запуска, что уходит в облако и когда всё удаляется.
Ошибка, которую я бы сразу убрал: «Мы просто не отправляем паспорт целиком» не считается контролем, если в тексте остались email, номер договора, адрес и редкая комбинация признаков, по которой человека легко узнать.
Что подготовить и какой результат ждать
- На выходе: У вас есть минимальный набор данных, отдельные права и понятный маршрут для опасного входа или действия.
- Создайте реестр AI-сценарии с полями данные, провайдер, цель, срок хранения, доступ, владелец и риск.
- Сохраните исходные данные и права доступа отдельно от результата, чтобы можно было проверить, что сделал защита данных в AI-процессе.
- Протестируйте prompt injection, вредоносную инструкцию во вложении, чужой record_id и пустой ответ инструмента.
Сделайте опасное действие невозможным без согласования
- Составьте карту данных
Для каждого AI-шага укажите поля, источник, цель, срок хранения, регион и роль, которая может их видеть. Не пишите «все данные клиента».
Проверьте: Для каждого поля есть причина, а лишнее можно удалить.
Если не сработало: Начните с тестовых или обезличенных данных.
- Ограничьте credentials
В настройках Credentials/Permissions выдайте чтение вместо записи, одну папку вместо диска, один проект вместо всей CRM. Используйте отдельный ключ для каждого workflow.
Проверьте: Отзыв ключа не открывает доступ к остальной системе.
Если не сработало: Проверьте права на sandbox-аккаунте.
- Фильтруйте вход до AI
Перед моделью уберите пароли, токены, полные номера карт и лишние персональные данные. Перед send, refund, delete и update permissions поставьте Human approval.
Проверьте: В логе нет секретов и чувствительных полей, которые не нужны задаче.
Если не сработало: Замените значение на маску или внутренний id.
- Соберите набор атак и сбоев
Проверьте инструкции во вложении, подмену record_id, попытку прочитать чужую папку, превышение лимита и пустой ответ. Каждая проверка должна завершаться stop, retry или handoff.
Проверьте: Опасный сценарий не доходит до реального действия.
Если не сработало: Отзовите write-права до устранения причины.
Реестр данных перед первым запросом
Создайте таблицу data_type, source, purpose, legal_basis, allowed_destination, retention_days, access_role и deletion_owner. Отдельно отметьте паспорт, банковские реквизиты, договоры, переписку и внутренние цены.
Минимизация — это не только маска имени. Перед AI удалите поля, которые не нужны для задачи, замените оставшиеся на CLIENT_001 и сохраните таблицу соответствий отдельно. В ответе не должно быть возможности восстановить исходные значения через промпт.
- Не давайте workflow доступ ко всей папке ради одного документа.
- Проверьте договор поставщика, регион хранения, обучение на данных и удаление.
Как проверить, что маскирование работает
Создайте тестовый документ с заведомыми маркерами PASSPORT_TEST_001, CARD_TEST_002 и EMAIL_TEST_003. Посмотрите payload до отправки, payload поставщика и логи. Если маркер проходит дальше локального шага, маскирование стоит не там или применяется только к видимому тексту.
Реестр данных до первой интеграции
Создайте `data_type`, `source`, `purpose`, `legal_basis`, `allowed_destination`, `retention_days`, `access_role` и `deletion_owner`. Отдельно отметьте паспорт, договор, реквизиты, переписку и внутренние цены. AI получает только поля, необходимые для конкретной задачи.
API-ключи храните в `Credentials`, а не в `Set`, `Code` или URL. Для self-hosted n8n задайте отдельный ключ шифрования и ограничьте сохранение execution data только тем, что нужно для разборов инцидентов.
N8N_ENCRYPTION_KEY=<длинный_секретный_ключ>
EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168Проверка маскирования на тестовых маркерах
Создайте тестовый документ с `PASSPORT_TEST_001`, `CARD_TEST_002` и `EMAIL_TEST_003`. Проверьте payload до модели, payload поставщика и error logs. Если маркер проходит дальше локального шага, маскирование стоит слишком поздно.
Одинаковое исходное значение должно получать один и тот же токен внутри запуска, а таблица соответствий — лежать отдельно, быть зашифрованной и иметь TTL. Не отправляйте сырые данные в Slack и email через ветку ошибки.
Что должно измениться после настройки
У вас есть минимальный набор данных, отдельные права и понятный маршрут для опасного входа или действия.
Где безопасность ломается не в модели, а в доступах
Считать системный промпт защитой от вредного входа.
Логировать целиком персональные данные и секреты.
Использовать один админский ключ для всех интеграций.
Не иметь владельца, который отзовёт доступ при инциденте.
Когда нужен отдельный security-review
Нужен специалист, когда обрабатываются медицинские, финансовые или персональные данные, несколько провайдеров или требования регулятора.
Что проверить до подключения реальных данных
Можно ли отправлять клиентские письма в AI?
Только после проверки договора, политики хранения, региона и необходимости каждого поля. Для теста лучше использовать обезличенный текст.
Достаточно ли не показывать секрет в ответе?
Нет. Секрет не должен попадать во вход, контекст, лог и инструменты, которым он не нужен.
Что делать при подозрительном ответе агента?
Остановить workflow, отозвать доступ, сохранить технический лог без PII и проверить последние действия.
Какой первый контроль поставить?
Минимальные права и обязательное подтверждение перед любым действием, которое нельзя легко отменить.
