Make автоматизация облачных хранилищ вроде Dropbox и Google Диска в России сейчас звучит как что-то между «экономим время» и «играем в русскую рулетку с Роскомнадзором». Для российских специалистов, которые работают с ИИ, документами, CRM и хранилищами, вопрос один: как сделать, чтобы файлы летали быстро, но данные не уезжали за границу и не превращались в штраф по 152-ФЗ. В этой статье я разберу, как использовать make автоматизацию так, чтобы Dropbox и настройка Make Google Диск работали как временный буфер и мост к российским облакам, а не как прямое нарушение требований локализации. Расскажу, как выстроить цепочку: файл появился — автоматом переехал в защищенное облако в РФ, зашифровался, записался в журнал, а ответственный получил понятное уведомление. И всё это на человеческом языке, без страха перед проверками и с минимальным количеством ручных действий.
Чтобы не быть голословной, сразу обозначу живой кейс. Ко мне пришел клиент, его зовут Андрей, он руководитель небольшой онлайн-школы по подготовке к ЕГЭ в Екатеринбурге. У Андрея Dropbox, Google Диск, куча папок «договоры», «сканы паспортов», «видео-уроки с детьми», плюс CRM на российском хостинге. Он уже слышал про ужесточения по 152-ФЗ с 2025 года, про реестр операторов, про проверки Роскомнадзора, но файлы как летали через зарубежные облака, так и летали. Задача, с которой Андрей пришел: настроить make автоматизацию так, чтобы Dropbox и Google Диск превратились в безопасный транзитный коридор, а все, что содержит персональные данные, оказывалось в российском облаке с аттестатом ФСТЭК. Я покажу, как мы это сделали, какие шаги прошли, где споткнулись и что в итоге сэкономили.
Если говорить шире, тема болезненная не только для онлайн-школ. Любой ИП с интернет-магазином, HR-агентство, бухгалтер на аутсорсе или фрилансерка-дизайнер в России сейчас живут в реальности, где «просто закинем файл на диск» превращается в юридический риск. С сентября 2025 года регистрация как оператора персональных данных стала обязательной практически для всех, кто хоть как-то трогает ФИО, телефоны, договора или анкеты. Проверки автоматизированы, сканируются сайты, политика обработки, использование зарубежных сервисов. И если раньше Dropbox и Google Диск сходили с рук «ну мы так привыкли», то к 2026 году это уже прям системный триггер для проверяющих. Поэтому мой фокус — показать, как встроить Make, облака и ИИ-инструменты в российскую повестку так, чтобы и бизнес не тормозил, и данные жили по закону.
Почему make автоматизация Dropbox и Google Диска в России стала рисковой задачей
Что изменилось в регулировании и почему зарубежные облака под прицелом
Я часто слышу вопрос: «Ну мы же просто файлики храним, кому до этого есть дело?». До 2025 года ответ и правда был размазанный, но сейчас картина изменилась радикально, особенно если смотреть глазами Роскомнадзора. С сентября 2025 года каждый, кто собирает и обрабатывает персональные данные россиян, должен быть в реестре операторов, а с 2026 контроль за использованием зарубежных сервисов усилили через автоматические сканеры: смотрят политики, домены, публичные ссылки, аналитику.Dropbox и Google Диск попадают в фокус сразу, как только фигурируют в публичной документации или засвечиваются в типовых процессах по хранению документов с ПДн. Это не страшилка, это просто новая «норма погоды» в правовом поле.
Чтобы не плавать в общих фразах, полезно четко назвать, за что прилетает. Во-первых, несоблюдение принципа локализации: если ФИО, паспорта, адреса, сведения о здоровье, биометрия или даже «просто» телефоны клиентов хранятся и обрабатываются с помощью зарубежных сервисов без зеркала в РФ, это конфликт с 152-ФЗ. Во-вторых, отсутствие согласий или устаревшие формулировки согласий, где не прописаны конкретные сервисы, цели и сроки обработки. И в-третьих, использование сервисов без аттестаций ФСТЭК и Минцифры для систем, которые официально признаны ИСПД определенного уровня защищенности. Dropbox и Google Диск под такие аттестации не попадают, и это не изменится, как бы они ни были удобны в интерфейсе.
Мне нравится сводить такие вещи в короткую мысль, чтобы оперировать не абстрактным «страшно», а конкретным «что делать».
Если в папках Dropbox или Google Диска у тебя лежат файлы с персональными данными россиян — это почти всегда означает, что у тебя есть риск штрафа, если эти файлы не дублируются и не локализуются в российском хранилище.
Исключения бывают, например, полностью обезличенные данные или временные технические кэши без идентификаторов, но это нужно еще доказать. Поэтому задача для нас с тобой не в том, чтобы «прятать следы», а в том, чтобы выстроить честную, документированную схему: зарубежное облако как транзит и рабочий инструмент, российское — как основное место жизни данных.
Штрафы — это еще половина беды. Вторая половина — блокировки и предписания. Организации могут обязать прекратить использовать конкретный сервис, мигрировать данные в срок, предоставить доказательства уничтожения копий, а это уже не про «слегка неприятно», а про операционный коллапс, если процессы не описаны и не автоматизированы. Я видела кейс, когда небольшая дизайн-студия неделю вручную выгружала архив Dropbox в российское облако, потому что не была готова ни технически, ни организационно. Там не было катастрофы, но люди просто взяли и потеряли 7 рабочих дней, хотя можно было закрыть вопрос аккуратным make сценарием за вечер.
Это означает, что make автоматизация здесь нужна не для красоты, а для того, чтобы встроиться в правовые требования России и не заниматься пожаротушением каждые полгода. Мы сейчас еще не про конкретные сценарии, а про контекст: почему вообще приходится так заморачиваться с Dropbox и Google Диском. Как только это становится понятно, следующий шаг — спроектировать маршруты файлов так, чтобы зарубежный облак служил буфером и окном в мир, а не единственным домом для чувствительных документов.
Как проверки и автоматизированный контроль ломают «серые» схемы хранения
На практике я заметила, что многое изменилось не из-за самих штрафов, а из-за автоматизации проверок. Роскомнадзор давно перестал быть «дядей с бумажкой», сейчас значительная часть первичного контроля происходит через роботов: сканируются сайты, публичные документы, интеграции с формами, оттуда же вытаскиваются упоминания Google Drive, Dropbox, иностранных CDN. В итоге даже у маленького бизнеса шансов «проскочить незаметно» становится меньше, особенно если он активно работает в онлайне и использует лендинги, квизы, формы записи.
Интересный момент: автоматизация проверок подталкивает нас автоматизировать процессы обработки данных. Звучит как замкнутый круг, но это как раз тот редкий случай, когда круг лучше не разрывать, а использовать. Если делать все вручную — вести журналы учета, составлять акты уничтожения, отслеживать согласия, проверять, какие файлы куда улетели, — ты становишься уязвимым именно там, где проверяющий автомат: он работает системно, а человек — по остаточному принципу. А если строить маршруты через инструменты make автоматизация, можно, наоборот, превратить роботов регулятора в условного «коллегу», к которому ты уже готова документально.
Чтобы чуть заземлить разговор, приведу наблюдение, которое регулярно встречаю у клиентов. У большинства компаний нет осознанного понимания, какие данные где живут: Google Диск используется для обмена с подрядчиками, Dropbox — для резервного копирования, плюс Яндекс Диск, российские S3-совместимые хранилища, файлы в почте и мессенджерах. В голове это выглядит как «ну у нас все нормально», а в реальности это набор не связанных между собой точек, которые очень сложно потом восстановить в виде схемы: что именно, в какой момент, с чьим согласием, с какой целью и сроком обработки туда попало.
Получается, что автоматизация в Make и похожих инструментах нужна не только для того, чтобы переложить часть рутины на робота, но и чтобы вытащить бизнес из зоны «случайно нарушили, потому что не уследили». Когда маршруты файлов описаны, задокументированы и реализованы в виде прозрачных сценариев — проверка превращается из лотереи в техническое упражнение. И здесь уже можно переходить от вопросов «почему все так строго» к вопросам «как именно нам настроить Dropbox и Google Диск через Make, чтобы и было удобно, и регулятор спал спокойно».
Какие типы данных вообще можно трогать через Dropbox и Google Диск
Я часто задаю клиентам один и тот же, на первый взгляд скучный вопрос: «Что именно у вас лежит в облаке?». И в ответ слышу либо «да там все подряд», либо длинный список папок, вообще без привязки к видам данных. С точки зрения 152-ФЗ это критичный момент, потому что разные категории информации требуют разной жесткости подхода. Если в Google Диске хранятся методички без ФИО, маркетинговые картинки и технические инструкции — разговор один, а если там лежат сканы паспортов, анкеты сотрудников, резюме с телефонами и адресами — уже совсем другой уровень.
Чтобы чуть упростить, я мысленно делю данные на три корзины. В первой — общедоступная или условно нейтральная информация, которая не позволяет идентифицировать человека, тем более в связке с другими источниками. Во второй — персональные данные в базовом смысле: ФИО, контакты, данные договоров, история обращений в поддержку. В третьей — чувствительные штуки: биометрия, здоровье, банковские реквизиты, информация о детях и любые документы, которые могут привести к серьезному ущербу при утечке. Dropbox и Google Диск для первой корзины относительно безопасны (хотя и тут есть нюансы), для второй и третьей они могут использоваться только как промежуточное звено, с обязательной миграцией и локализацией в российском хранилище.
Чтобы не утонуть в классификациях, полезно зафиксировать для себя одно простое правило. Если файл содержит хотя бы одно поле, однозначно привязанное к конкретному человеку, его «дом» должен быть в российском хранилище, а не в зарубежном. Dropbox и Google Диск в этом случае превращаются в «коридор», через который файл проходит по пути к своему дому. Make автоматизация как раз и нужна, чтобы этот проход происходил быстро, безопасно и с понятным журналом событий: кто загрузил, когда миграция прошла, куда именно положили, как зашифровали и что потом с файлом сделали. Как только в голове появляется эта картинка «дом — коридор», многие вопросы про «а можно ли так» упрощаются до проверки: а дом у нас точно в России?
Как спроектировать безопасную архитектуру make автоматизации с Dropbox и Google Диском
С чего начать: инвентаризация, реестр и базовая схема потоков
Когда я первый раз захожу в проект по автоматизации облачных хранилищ, у меня нет задачи сразу рисовать сложные схемы в Make или спорить, чей интерфейс красивее — Dropbox или Google Диска. Я начинаю с бумажки и ручки, ну или с Miro, если день особенно организованный. Нужно честно зафиксировать, какие типы данных есть, кто их трогает, какие системы уже используются и где сейчас «болит». Без этого make автоматизация будет похожа на попытку прибить картину к стене, не глянув, что там за проводка внутри.
Минимальный набор шагов для старта обычно один и тот же: инвентаризация категорий персональных данных, картирование систем (облака, CRM, почта, мессенджеры, локальные папки), определение ответственного за обработку ПДн, проверка регистрации в реестре Роскомнадзора и актуализации политики обработки. И да, это скучнее, чем настраивать webhooks в Make, но без этого куча интересных автоматизаций превращается в юридический риск. Как только структура хотя бы в черновике понятна, можно начинать рисовать логическую схему потоков: откуда файлы приходят, через какие точки проходят и куда попадают в итоге.
Здесь очень помогает мысленное разделение ролей: Dropbox и Google Диск — временный буфер и рабочий стол, российское облако — архив и «источник правды», CRM и учетные системы — надстройка, которая работает с метаданными и ссылками. Если не держать это разделение в голове, есть риск скатиться в старую модель, где «все лежит в одном месте, потому что так удобнее». А наша цель как раз в том, чтобы удобство осталось, а модель изменилась: человек продолжает пользоваться привычными папками, но под капотом файлы живут уже совсем другой жизнью.
Я обычно предлагаю нарисовать три слоя: слой пользователей (кто загружает и скачивает файлы), слой интеграций (Make, n8n, API хранилищ) и слой хранения (российские облака с аттестатами). В каждом слое фиксируются точки входа и выхода. Например: преподаватель Андрея кладет договор в Google Диск, Make ловит событие «новый файл», проверяет, есть ли в имени потенциальные маркеры ПДн (ФИО, слова «договор», «паспорт»), вытаскивает файл через API, кладет его в защищенную папку в российском хранилище и записывает лог с идентификатором пользователя и временем события. Пользователь при этом продолжает жить в своем привычном интерфейсе Google Диска, даже не задумываясь, что под ним пляшут сценарии.
Это означает, что архитектура делится на две оптики: человеческую (папки, привычки, интерфейсы) и машинную (маршруты, триггеры, логи). make автоматизация как раз и служит мостом между ними, позволяя не ломать устоявшиеся процессы, а аккуратно оборачивать их в защитный и юридически корректный слой. Как только тебе удается нарисовать такую карту на одном листе и не запутаться, дальше переход к конкретной настройке уже не пугает.
Какие российские облака стыкуются с Make и как их выбирать
Следующий вопрос, который почти всегда всплывает: «Окей, с Dropbox и Google Диском понятно, а куда именно мигрировать?». В российской реальности выбор меньше, чем у глобальных SaaS, но все равно достаточный, чтобы зависнуть на два дня в сравнении тарифов. Я смотрю не только на цену и объем, а в первую очередь на три вещи: наличие аттестатов ФСТЭК (уровень защищенности ИСПД), адекватный API для интеграции с Make и понятный SLA по доступности. Без первых двух любой разговор про 152-ФЗ превращается в теоретический.
Из облаков, которые на сегодняшний день чаще всего всплывают в проектах, можно назвать S3-совместимые решения с российской юрисдикцией, специализированные сервисы с упором на безопасное хранение персональных данных, а также комплексы, где хранилище уже встроено в более широкий контур управления ИСПД и журналами. Для make автоматизации Dropbox и Google Диска мне особенно важен API: возможность загрузить файл, получить прямую ссылку, управлять правами доступа и метаданными, а также записывать и читать логи. Если API костыльный или ограниченный, приходится городить лишние обходные сценарии.
Когда выбираешь облако под конкретную задачу, полезно сформулировать короткий чек-лист для себя.
Минимальные критерии для хранилища ПДн в РФ: юридическое лицо в российской юрисдикции, наличие аттестации ФСТЭК под нужный уровень ИСПД, доступный API и техническая поддержка, которая понимает слова «152-ФЗ» и «локализация».
Звучит банально, но я сталкивалась с ситуациями, где облако формально находилось в РФ, но техническая поддержка на вопрос про журналы обработки ПДн отвечала чем-то вроде «ну у нас просто файлы, мы про это не думаем». С такими партнерами строить долгосрочную систему не хочется, как минимум.
Здесь работает и еще один критерий — доступность нормальной документации для интеграторов. Когда вендор хранилища делает адекватные гайды, примеры запросов, ограничения по размеру файлов и скорости, make автоматизация превращается из «эксперимента» в контролируемый проект. Если же документация состоит из двух скриншотов и одной общей фразы, ты заранее понимаешь, сколько ночей проведешь с постманом и логами. Я не шучу, у меня был проект, где из-за ломаного API и непредсказуемых таймаутов автоматизация миграции из Google Диска убила больше времени, чем сэкономила… в первые недели. Потом, когда все устаканилось, она начала приносить пользу, но старт был болезненный.
Получается, что выбор российского облака — это не «где дешевле», а «где можно безопасно и предсказуемо построить маршруты из Dropbox и Google Диска, не нарушая 152-ФЗ». Как только подходящее хранилище найдено, мы снова возвращаемся к архитектуре: как встроить его в существующую экосистему клиента через Make, так, чтобы пользователи не убежали обратно в хаос «скинь на почту, а там разберемся».
Как описать роли и ответственности, чтобы Make не остался в одиночестве
Когда я говорю «архитектура», многие представляют себе только техническую часть: API, сценарии, вебхуки. Но без людей даже идеальная make автоматизация начнет со временем рассыпаться, потому что процессы меняются, появляются новые папки, новые сотрудники, новые курсы или кампании, а сценарии никто не трогает. В итоге через год ты обнаруживаешь, что половина данных продолжает жить в Dropbox, а часть автоматизации просто перестала срабатывать после переименования папок (нет, подожди, я сейчас не преувеличиваю, это прям типичная история).
Поэтому параллельно с проектированием потоков я всегда прошу клиента назначить ответственного за обработку ПДн и за эксплуатацию автоматизации. Это не обязательно должен быть отдельный человек с громким титулом, но у него должны быть полномочия и время хотя бы раз в месяц смотреть отчеты, журналы, логи Make и перечень активных сценариев. В идеале этот человек понимает, что такое 152-ФЗ, какие типы данных у компании есть и чем отличается техническая ошибка сценария от потенциального инцидента безопасности. Если весь проект «висит» только на внешнем подрядчике, риск потерять управляемость очень высокий.
Я поняла, что хорошо работает простая модель ролей. Владелец процесса (например, Андрей как руководитель онлайн-школы) отвечает за политику, список систем и категорий данных. Ответственный по ПДн следит за регистрацией в реестре, согласиями, журналами и коммуникацией с регуляторами. Технический владелец автоматизации (иногда это тот же человек, иногда отдельный админ или интегратор) контролирует, что сценарии в Make живы, обновлены, не ломаются от переезда папок и изменений в API Dropbox, Google Диска и российского облака. Если хотя бы одна из этих ролей «размыта», автоматизация начинает вырождаться в набор разрозненных костылей.
Это означает, что проект по make автоматизации облачных хранилищ нужно сразу продавать внутри компании не как «один раз настроили и забыли», а как живую систему, которая требует минимального, но регулярного ухода. И здесь я возвращаюсь мыслями к нашему Андрею: именно он в итоге стал тем человеком, кто раз в месяц открывает дашборд с логами и пару раз в квартал зовет меня «пошуршать» в сценариях, когда добавляются новые курсы или меняются условия хранения договоров. Она не про тотальный контроль, она про спокойствие: если что-то пойдет не так, мы это увидим не через год, а в тот же день.
Как именно настраивать make Dropbox и Make Google Диск как безопасный буфер
Как поймать файл в Dropbox и сразу отправить его в российское облако
Переходим к самой вкусной части — как руками собрать ту самую make автоматизацию, чтобы Dropbox остался удобным «рабочим столом», но не стал кладбищем персональных данных. На практике это выглядит проще, чем звучит, если заранее хорошо продумать логику. Я обычно начинаю с триггера «New file» или «Watch files» для Dropbox: он реагирует на появление нового файла в указанной папке или наборе папок. Важно сразу договориться с командой, какие папки считаются «входными», чтобы не сканировать весь аккаунт ради красивой архитектуры (нет, подожди, лучше честно признать, что ресурсы не резиновые).
После триггера я вставляю один или два модуля проверки: смотрю имя файла, путь, иногда расширение. Если договориться с пользователями о простых правилах именования, можно сильно разгрузить логику сценария. Например, все договоры с ПДн начинаются с «AGR_», резюме с «CV_», а сканы документов кладутся в отдельную папку «00_scans». Это не идеально, но уже помогает Make быстрее понимать, что перед ним: нейтральный файл или чувствительный. Чем больше семантики мы переносим в имена и структуру папок, тем проще и стабильнее работает автоматизация.
Дальше подключается API российского облака: Make забирает файл из Dropbox, отправляет POST-запрос на загрузку в защищенное хранилище, получает в ответ идентификатор и прямую ссылку. На этом этапе полезно сразу же записать событие в какой-нибудь лог: таблицу, базу или специализированную систему журналирования.
Минимальный состав лога: идентификатор файла в исходном сервисе, идентификатор в целевом хранилище, время события, инициатор (пользователь или система) и тип операции (создание, обновление, удаление).
Если логов нет, потом очень тяжело объяснять, что именно и когда переехало, особенно на фоне проверок или внутренних аудитов.
Финальный штрих — управление судьбой исходного файла в Dropbox. Здесь возможны разные подходы: кто-то предпочитает сразу удалять файл после успешной миграции, кто-то переносит его в архивную папку «migrated», кто-то ставит на него специфический тег или пометку. Я обычно рекомендую мягкий режим: переносить в отдельную папку с ограниченным доступом и периодически запускать отдельный сценарий, который удаляет файлы старше определенного срока, параллельно формируя акты уничтожения. Это дает баланс между юридической чистотой и возможностью откатить ошибку, если вдруг российское хранилище отвалилось в момент миграции.
Получается цепочка: пользователь кладет файл в Dropbox, Make его ловит, определяет тип, передает в российское облако, пишет лог и приводит Dropbox к чистому состоянию. Пользователь продолжает работать в привычной среде, но с точки зрения 152-ФЗ «дом» файла находится уже в России. Помнишь нашу подругу-дизайнершу с предписанием от Роскомнадзора? В ее случае достаточно было бы такого сценария, чтобы избежать ручной миграции в панике и потери недели жизни.
Как работает настройка Make Google Диск, если файлы редактируются и живут дольше
Google Диск ведет себя чуть хитрее, чем Dropbox, потому что там чаще работают не просто с файлами, а с документами, таблицами и презентациями, которые живут своей жизнью, постоянно редактируются и имеют сильнее завязанную совместную работу. Поэтому настройка Make Google Диск почти всегда включает не только событие «новый файл», но и «изменение файла», а также пересборку логики вокруг версионности и прав доступа. С Google Диском приходится мириться с тем, что он — не только временный буфер, но и активная рабочая среда.
Я тестировала два подхода. В первом Google Диск используется только как входной шлюз: загружаются PDF, сканы, архивы, после чего файлы переезжают в российское хранилище, а в самом диске остаются только «пустышки» — ссылки или документы-обертки без ПДн. Во втором подходе часть документов живет в Google как рабочие, но все финальные версии (например, подписанные договоры, закрывающие документы) регулярным заданием Make выгружаются и складываются в российское облако. Первый подход безопаснее, второй — комфортнее для пользователей, и тут приходится выбирать баланс.
На практике настройка Make Google Диск выглядит так: триггер «Watch files» или «Watch changes», фильтры по типам файлов и папкам, модуль «Get a file» для скачивания нужного содержимого (или экспорт в PDF для документов Google Docs/Sheets), затем передача в российское хранилище через API и запись логов. Отдельно я обычно настраиваю сценарий, который отслеживает изменения прав доступа: если документ с ПДн внезапно стал доступен «по ссылке» или «для всех в домене», приходит уведомление ответственному. Это тот редкий случай, когда Make превращается не только в логистику, но и в маленького DLP-агента.
Чтобы не перегружать Google Диск и не столкнуться с лимитами API, полезно разбивать задачи на две категории: событие-реакция (когда что-то изменилось прямо сейчас) и периодическая синхронизация (когда нас интересует накопительный результат, например, все измененные за день договоры). Я заметила, что ежедневная задача по выгрузке новых и измененных файлов с меткой «final» или «signed» в названии работает надежнее, чем попытка ловить каждую правку в реальном времени. И да, звучит странно, но иногда небольшой лаг в несколько часов полностью устраивает бизнес, зато автоматизация становится более стабильной и предсказуемой.
Возвращаясь к нашему кейсу с Андреем, именно Google Диск оказался у него «сердцем» работы преподавателей: там висели расписания, методички, комментарии. Мы не стали выдирать это все в российское облако, потому что там не было ПДн, но все документы с персональными данными (журналы успеваемости, договоры с родителями, личные карточки) получили отдельные папки и метки, которые Make отслеживал и выгружал в защищенное хранилище. В результате Google Диск остался рабочей средой, но перестал быть единственным местом, где живут чувствительные данные.
Как встроить проверки согласий и журналирование прямо в сценарии Make
На этом этапе многие расслабляются: «Ну все, файлы переезжают в РФ, можно выдохнуть». Я всегда чуть морщусь, потому что половина задач по 152-ФЗ крутится не только вокруг места хранения, но и вокруг законности самой обработки: есть ли согласие, не истек ли срок, правильно ли описаны цели. И вот здесь как раз Make может забрать на себя кусок работы, который иначе делался бы в Excel кем-то уставшим по вечерам. Мне нравится идея, что автоматизация не просто двигает байты, а помогает человеку не ошибиться в юридических деталях.
Вот как это выглядит на практике: перед тем как отправить файл из Dropbox или Google Диска в российское хранилище, сценарий Make обращается к CRM или базе согласий и проверяет, есть ли для конкретного субъекта (клиента, сотрудника, ученика) актуальное согласие на соответствующую цель обработки. Если согласия нет или оно истекло, файл либо не попадает в целевое хранилище, либо обрабатывается по другому маршруту (например, шифруется и отправляется ответственному на разбор).
Автоматическая проверка согласий не отменяет юристов, но резко снижает шанс, что «забыли обновить галочку, а данные уже улетели».
Второй слой — журналирование. Каждый сценарий в Make можно снабдить логированием: записью того, что и когда было сделано. Иногда хватает таблицы в Google Sheets или российском аналоге, иногда лучше использовать базу данных. Важный момент: логи не должны содержать лишних ПДн, там достаточно идентификаторов, времени и результата операции. При этом наличие таких журналов сильно упрощает ответы на запросы субъектов («какие мои данные вы обрабатываете?») и на запросы регуляторов. Я один раз видела, как клиент при проверке РКН просто достал аккуратную выгрузку из журнала, и диалог сразу стал спокойнее.
Здесь работает простая логика: если тебе лень руками вести журналы в Excel, лучше потратить время на то, чтобы Make делал это за тебя. Я сама не фанат рутинной отчетности, но как внутренний аудитор по прошлой жизни очень люблю, когда все лежит по полочкам. Ирония в том, что один сценарий, который за минуту записывает все операции с файлами, экономит часы и нервы ответственному по ПДн. Это тот случай, когда автоматизация окупается не только в часах, но и в количестве выпитого кофе (помнишь мой остывший кружку рядом с n8n на третьей попытке?).
Как кейс Андрея превратился в рабочую схему: пошаговая реализация и первые итоги
Как мы собрали первую версию маршрутов и где сразу стало легче
Возвращаясь к истории Андрея, расскажу, как это выглядело по шагам, без глянца. На первой встрече мы открыли его Dropbox и Google Диск и честно ужаснулись: папки «старое», «очень старое», «архив до 2022», «новое», «ученики новое», внутри — договоры, резюме преподавателей, сканы паспортов родителей, какие-то таблицы с оплатами. Классика. Я предложила не пытаться за один вечер навести идеальный порядок, а разделить работу на три волны: срочная защита, базовая структура и потом уже косметика. Если пытаться сделать все идеально, проект зависает.
В первую волну мы взяли только те папки, где явно были ПДн: «договоры», «резюме», «сканы». Для них настроили два ключевых сценария в Make: один для Dropbox, второй для Google Диска. Оба работали по принципу «новый или измененный файл — миграция в российское облако — логирование — приведение исходного облака к безопасному состоянию». Чтобы не устраивать революцию, мы сохраняли пользователям привычные пути: они продолжали класть файлы туда же, куда и раньше, просто через день начали замечать, что старые договоры «куда-то переезжают» в дополнительные архивные папки.
Первые ощутимые плюсы появились уже через неделю. Во-первых, Андрей перестал бояться фразы «а если к нам придут», потому что мог открыть карту потоков и показать, что с новыми файлами все хорошо. Во-вторых, преподаватели наконец-то получили четкие инструкции: куда класть отчеты об успеваемости, как называть файлы, что будет дальше происходить. В-третьих, мы сразу начали писать логи всех операций, и Андрей увидел, как много файлов вообще проходит через систему за день — это полезный побочный эффект, который позволяет иначе взглянуть на объемы обработки данных.
Чтобы не плодить хаос, мы договорились, что все новые процессы, где появляется файл с ПДн, должны проходить короткий «аудит» на предмет того, как он попадает в систему. Если где-то всплывал новый путь «скинули в телеграм, потом загрузили в Google Диск», мы допиливали сценарий или процесс. Да, это звучит как допнагрузка, но в реальности занимает по 15-20 минут и сильно экономит время потом, когда не нужно латать дыры в трех местах. Андрей сначала ворчал, что его превращают в «офицера по данным», а потом признался, что ему стало проще спать.
Получается, что первая версия архитектуры не была идеальной, но уже дала ощущение контроля. Мы не переписали все процессы онлайн-школы за месяц, но создали коридор безопасности для самых чувствительных файлов. И это, на мой взгляд, лучший подход: не ждать, пока появится время на «большую трансформацию», а начинать с узких мест, постепенно расширяя автоматизацию. Так и make автоматизация не превращается в монстра, и команда успевает привыкнуть к новым правилам игры.
Как мы подключили проверки согласий и автоматические журналы ПДн
На второй волне мы занялись тем, что обычно откладывают «на потом»: согласиями и журналами. У Андрея в CRM были поля «согласие на обработку» и «согласие на рассылку», но никто толком не отслеживал сроки и связи с конкретными файлами. Я предложила встроить проверку согласий прямо в сценарии Make: перед тем как отправить файл в российское хранилище, сценарий обращался к CRM, проверял наличие актуального согласия по ученику или родителю и в зависимости от результата выбирал маршрут.
Если согласие было в порядке, файл ехал в свою законную папку, а в лог записывалось «обработка разрешена». Если согласие отсутствовало или истекло, сценарий помечал файл как «требует проверки» и складывал его в отдельную защищенную папку с ограниченным доступом, параллельно отправляя Андрею уведомление. Да, это добавляло немного ручной работы, но зато позволило не пропускать «серые» случаи, где юристы могли бы иметь вопросы.
Фактически мы перевели часть юридического контроля в техническую плоскость, оставив человеку только те кейсы, где действительно нужен живой мозг.
Параллельно мы отказались от Excel-таблиц для журналов обработки ПДн и переключились на автоматическое логирование. Каждый сценарий Make в конце отправлял небольшую запись в таблицу в российском облаке: какой файл, какой тип операции, когда, кем инициирован, какой результат. Через месяц Андрей уже мог открыть эту таблицу и увидеть кумулятивную картину: сколько договоров обработано, сколько файлов потребовали ручной проверки, сколько было отклонено из-за отсутствия согласия. Для аудиторского мозга это была музыка, для него — неожиданная аналитика, которую можно использовать и по управленческим целям, не только для РКН.
На этом этапе я поймала себя на мысли, что проект перестал быть «страшной историей про Роскомнадзор» и превратился в нормальное улучшение процессов. Да, драйвером был закон, но результатом стала более прозрачная система работы с файлами, где каждый понимает, что происходит после того, как он нажимает «загрузить». Андрей даже начал шутить, что теперь у него не просто онлайн-школа, а маленький «data-driven» бизнес (хотя сама я не очень люблю эти модные ярлыки, но тут получилось почти честно).
Как автоматизация поменяла культуру обращения с файлами у команды Андрея
Самый интересный эффект проявился не сразу, а через пару месяцев, когда первичный ажиотаж утих. Команда Андрея перестала относиться к Dropbox и Google Диску как к «черной дыре, куда все летит». Преподаватели начали осознанно называть файлы, использовать договоренные префиксы, задавать вопросы, если не понимали, в какую папку положить тот или иной документ. Я не буду идеализировать, пару раз все равно кто-то кидал скан паспорта в общий чат, но это становилось исключением, а не нормой.
Автоматизация через Make сыграла здесь роль «невидимого модератора»: люди видели, что файлы не пропадают, что приходит уведомление о том, что договор успешно сохранен в защищенном хранилище, что можно запросить восстановление старой версии без паники. Это мелочи, но именно из них складывается доверие к системе. Кстати, помнишь кофе из самого начала? На одном из созвонов Андрей честно признался, что раньше он оттягивал любую тему, связанную с ПДн, и наливал себе еще одну кружку, лишь бы не заниматься политиками и реестрами. Сейчас эта тема перестала быть «темной материей» и стала просто еще одной частью операционной рутины.
Я заметила, что когда автоматизация сделана прозрачно и без «магии», люди готовы подстраиваться под нее. Они видят, как их действия влияют на работу сценариев, как naming влияет на маршруты файлов, как вовремя оформленное согласие экономит всем время. И тогда 152-ФЗ перестает быть абстрактной страшилкой, а превращается в набор понятных правил игры: куда можно, куда нельзя, что будет, если перейти границу. Это не значит, что ошибок больше нет, но теперь они происходят на фоне системы, которая умеет их ловить и подсвечивать, а не в полном хаосе.
Какие подводные камни чаще всего ломают make автоматизацию и как их обойти
Где обычно ошибаются с Dropbox и Google Диском под 152-ФЗ
Когда ко мне приходят за «переделать автоматизацию», в девяти случаях из десяти я вижу одни и те же боли. Первая — попытка использовать Dropbox или Google Диск как основное и единственное место хранения всех файлов, включая самые чувствительные. Люди добавляют пару «секретных» папок, включают доступ только по ссылке и искренне верят, что это уже какая-то защита. На фоне требований локализации это, конечно, иллюзия. Если нет зеркала или базового хранилища в РФ, какой бы красивой ни была структура в Google Диске, это все равно рисковая история.
Вторая типичная ошибка — отсутствие четких правил именования и структурирования. Сценарии Make висят на соплях, потому что пытаются угадать тип файла по его содержимому или случайным признакам, вместо того чтобы опираться на простые и понятные шаблоны. Я понимаю, что заставить всех одинаково называть документы — это отдельный квест, но без хотя бы минимальных договоренностей любая автоматизация превращается в набор костылей. И да, иногда лучше потратить час на объяснение команды, чем неделю на отладку тридцати условий в одном сценарии.
Третья ошибка — игнорирование старых файлов. На новых все молодцы: настроили миграцию, файлы из Dropbox и Google Диска едут в российское облако, логи крутятся. А вот наследие за прошлые годы так и живет в зарубежных папках, на которые уже никто не смотрит. Проверяющему, к сожалению, все равно, когда именно файл был загружен, если он до сих пор там лежит и содержит ПДн. Поэтому приходится отдельно планировать «генеральную уборку»: разовую миграцию архивов с последующим актом уничтожения или хотя бы четким аудитом, что осталось и почему.
Четвертая боль — отсутствие планового мониторинга сценариев Make. Пока все работает, никто не заглядывает в логи, а когда что-то ломается (например, поменялся формат ответа API или переименовали папку), ошибка обнаруживается через месяцы, когда уже нужна ретроспективная миграция. Здесь очень выручает простая метрика: хотя бы раз в неделю смотреть, сколько сценариев выполнилось успешно, сколько упало, какие были сообщения об ошибках.
Автоматизация — это не «поставил галочку и забыл», а скорее «поставил галочку и иногда заглядываешь, жива ли».
Наконец, многие недооценивают тему прав доступа. Файлы могут корректно переезжать в российское хранилище, но если права на папки в Dropbox или Google Диске раздаются по принципу «всем все», риск утечки остается. Make тут не волшебная палочка, но он может хотя бы сигнализировать: если файл с ПДн оказывается в папке с широкими правами, сценарий может отправить уведомление или даже автоматически переместить его в более защищенное место. Это не панацея, но хороший дополнительный слой контроля там, где люди ошибаются по привычке.
Почему «давайте использовать только российские сервисы» не всегда решение
Иногда на консультациях я слышу радикальное предложение: «Давайте просто выкинем Dropbox и Google Диск, перейдем на российские облака и забудем про проблемы». Звучит логично, но на практике редко работает идеально. Многим компаниям нужно обмениваться файлами с зарубежными партнерами, подключаться к международным платформам, использовать ИИ-сервисы, которые умеют интегрироваться именно с Google Диском. Полный разрыв с глобальной экосистемой часто бьет по эффективности сильнее, чем потенциальные риски, особенно если бизнес завязан на кросс-границы.
Я заметила, что гораздо жизнеспособнее модель, где зарубежные сервисы остаются в роли инструментов, но не единственных хранилищ правды. Dropbox и Google Диск прекрасно подходят для обмена материалами, временного совместного редактирования, интеграций с ИИ и внешними системами. Российские хранилища, в свою очередь, становятся местом, где лежат «юридически значимые» копии документов с ПДн. Make автоматизация как раз и позволяет склеить эти два мира, не впадая в крайности. (Хотя сама я видела один проект, где полный отказ от зарубежных сервисов сработал, но там была очень специфическая отрасль.)
Важный нюанс: иногда российские облака пока проигрывают по удобству интерфейса или совместной работе. Я не буду скрывать, что преподавателям Андрея гораздо комфортнее было продолжать жить в Google Диске, чем переезжать на менее знакомые решения, где, скажем так, UX еще развивается. И вместо того чтобы заставлять всех переучиваться, мы приняли эту реальность и построили защиту через Make, сохранив людям привычный инструмент. Это не идеал, но реальный компромисс, который работает в 2026 году для российских компаний.
Получается интересный парадокс: строгие требования по 152-ФЗ подталкивают к полному «импортозамещению», а реальная жизнь бизнеса тянет в сторону гибридных решений. Make и похожие платформы автоматизации как раз оказываются тем тонким слоем клея, который позволяет соблюдать закон и не убивать операционную эффективность. Я не говорю, что так будет вечно, возможно, через пару лет экосистема российских сервисов станет настолько зрелой, что необходимость в гибридах уменьшится. Но здесь и сейчас именно гибридная стратегия выглядит наиболее честной по отношению и к регулятору, и к команде.
Как не уйти в избыточную паранойю и при этом не расслабиться
На другом полюсе есть еще одна крайность: компании, которые после пары громких новостей и разговоров с юристами впадают в тотальную паранойю. Любой файл объявляется секретным, доступы режутся до абсурда, автоматизация запрещается «на всякий случай», все возвращается на бумагу. Я правда понимаю, откуда растут ноги у такого подхода, но он плохо сочетается с реальностью 2026 года, где бизнесу нужно быстро реагировать, а не ждать согласования каждой операции с документом по три дня.
Я поняла, что здесь помогает расстановка приоритетов. Не все данные одинаково чувствительны, и не везде требуется одинаковый уровень защиты. Биометрия, данные о здоровье, сведения о детях — да, это красная зона, и там я за максимально жесткий подход. Договоры с ФИО и паспортами — оранжевая зона, где нужна серьезная автоматизация и журналы, но не обязательно трехфакторная аутентификация для всех. Общие методички и обезличенные отчеты — зеленая зона, где можно позволить себе больше удобства, в том числе и за счет зарубежных сервисов без зеркал.
Make здесь выступает как инструмент, который позволяет технически закрепить эту градацию. В сценариях можно прописывать разные маршруты, разный уровень логирования, разную реакцию на ошибки в зависимости от типа файла и его папки. Где-то достаточно предупреждения, где-то — блокировки операции.
Главная идея — не строить бункер из бетона там, где достаточно нормальной двери с замком.
Иначе люди начнут искать обходные пути: личные флешки, частные аккаунты Google, пересылка через мессенджеры без каких-либо логов.
Баланс между безопасностью и удобством — вещь тонкая, и честно скажу, я сама не всегда попадаю в него с первого раза. Но в связке «клиент — автоматизация — регулирование» почти всегда находится точка, в которой и Роскомнадзор доволен, и команда не чувствует себя под колпаком. Андрей с его онлайн-школой как раз в итоге пришел к такому состоянию: формальные требования соблюдены, процесс прозрачный, а люди продолжают работать в комфортных для них инструментах. И на этой позитивной ноте можно плавно переходить к тому, что же в итоге дала вся эта история в цифрах и ощущениях.
Что в итоге меняет такая автоматизация и как вернуть себе время
Как изменились время, риски и качество жизни у Андрея
Я люблю, когда история заканчивается не абстрактным «стало лучше», а конкретными цифрами и наблюдениями. В случае с Андреем автоматизация make Dropbox и настройка Make Google Диск в связке с российским хранилищем дала несколько измеримых эффектов. Во-первых, время на обработку одного «досье» ученика (договор, анкета, согласия, сканы) сократилось примерно с 20-25 минут ручных операций до 5-7 минут, из которых основное — все равно живое общение с родителем. Файлы сами уезжают, логи сами пишутся, человек не бегает между папками в поисках «куда это теперь положить».
Во-вторых, Андрей перестал тратить вечера на «генеральные уборки» в облаках. Раньше он раз в пару месяцев заходил в Dropbox и Google Диск «просто посмотреть, что там творится», и каждый раз находил кучу сюрпризов. Сейчас у него есть дашборд и журналы, по которым он видит картину без ручного копания. В-третьих, снизился уровень тревожности по поводу проверок: регистрация в реестре операторов пройдена, политика обработки и реестр ПДн в порядке, автоматизация позволяет показать, что новые данные живут по правилам. Да, старые архивы еще потребуют отдельной кампании по миграции, но это уже плановая работа, а не внезапный пожар.
Если совсем сухо, за первые три месяца проект сэкономил Андрею и его команде около 40-50 часов чистого времени на ручной перекладке файлов, ведении журналов и поисках «последней версии договора». За год это вырастает в приличную сумму человеко-часов, которые можно потратить на новые курсы, улучшение методики или просто на то, чтобы не засиживаться в офисе до ночи. Возвращаясь к началу нашей истории, это ровно то, ради чего я занимаюсь автоматизацией: чтобы контент, документы и процессы двигались сами, а люди возвращали себе время.
Меня очень порадовало, что с течением времени Андрей стал сам инициировать небольшие улучшения. Он предлагал новые правила именования, спрашивал, можно ли автоматически формировать акты уничтожения файлов, интересовался, как интегрировать эту систему с другими частями его бизнеса. Это тот момент, когда автоматизация перестает быть «чужеродной штукой от консультанта» и становится частью ДНК компании. И да, я немного улыбаюсь, когда вспоминаю, как он вначале говорил «только давайте без этих ваших сложных штук», а потом сам предлагал добавить еще один сценарий в Make 🤭.
Как применить те же принципы в своем проекте без копирования один в один
Я сознательно не давала тебе готовые «рецепты на копипаст» с конкретными модулями и названиями, потому что каждая компания живет в своей экосистеме сервисов и привычек. Но принципы, по которым мы строили автоматизацию для Андрея, вполне универсальны. Сначала честная инвентаризация данных и систем, потом выбор российского хранилища с адекватным API и аттестациями, затем проектирование маршрутов для чувствительных файлов с участием Make и только после этого — косметика и оптимизация. Если перевернуть этот порядок, проект часто застревает в красивых, но бесполезных схемах.
Хорошее упражнение — взять любой свой процесс, где участвуют Dropbox или Google Диск, и задать себе три вопроса. Первое: какие там реально есть ПДн. Второе: где сейчас живет «дом» этих данных — за рубежом или в России. Третье: можно ли за вечер нарисовать на листке бумаги маршрут, в котором зарубежное облако — только коридор, а российское хранилище — финальная точка. Если ответ на третий вопрос «да», то Make или n8n уже можно подключать как мост. Если ответ «нет», скорее всего, тебе еще рано лезть в авторматизацию, надо сначала собрать архитектуру.
Здесь работает простое наблюдение: make автоматизация усиливает то, что уже есть. Если процессы хаотичны, автоматизация ускорит хаос. Если структура понемногу выстраивается, Make позволяет зафиксировать ее и не дать ей развалиться дальше. Поэтому мне так нравится подход «сначала мозг, потом платформа». И если хочется посмотреть, какие еще связки я собираю в своих проектах, можно заглянуть на мой сайт про автоматизацию и управление AI-процессами — там я подробно разбираю разные комбинации хранилищ, ИИ и бизнес-процессов.
Куда двигаться дальше, если базовая автоматизация уже работает
Когда первая волна автоматизации уже запущена, возникает логичный вопрос: «А что дальше?». Здесь много соблазнов: хочется сразу подключить ИИ-агентов, кластеризацию документов, автоматическое разбор согласий и даже предиктивные модели, которые угадывают, чего хочет регулятор. Я не против этих идей, но всегда предлагаю сначала стабилизировать базовый контур: убедиться, что основные маршруты из Dropbox и Google Диска в российское хранилище работают стабильно хотя бы пару месяцев, что команда привыкла к новым правилам, что журналы не забиваются мусором.
Дальше можно аккуратно добавлять новые слои. Например, анализ содержимого файлов перед миграцией (чтобы не полагаться только на имена), автоматическую классификацию документов по типам договоров, интеграцию с системами электронного документооборота. Можно подключать ИИ, который помогает маршрутизировать резюме, анкеты, заявки. Но все это должно опираться на уже настроенный и спокойный фундамент.
Идея не в том, чтобы сделать «космический корабль» за один заход, а в том, чтобы каждый новый слой не ломал предыдущий.
Получается, что путь к зрелой автоматизации обработки файлов с ПДн через Dropbox, Google Диск и Make — это не спринт, а скорее серия аккуратных шагов. Где-то ты спотыкаешься, где-то возвращаешься на шаг назад, где-то обнаруживаешь, что старый сценарий стал не нужен, и смело его выкидываешь. Но в конечном итоге у тебя появляется система, которая работает в реальной российской юридической и технической среде, а не в презентации. А это, как по мне, самый ценный результат.
Что ещё важно знать о такой автоматизации
Вопрос: Можно ли использовать Dropbox только как временный буфер и будет ли это законно?
Ответ: Да, использование Dropbox как временного буфера допустимо, если все файлы с ПДн автоматически и без задержек мигрируют в российское хранилище, а в самом Dropbox не остается рабочих копий. При этом должны быть оформлены документы по 152-ФЗ, описана такая схема в модели угроз и обработке ПДн, а также настроены журналы, подтверждающие миграцию. Важно, чтобы «временный» не превращался в «лежит годами», иначе регулятор оценит фактическое состояние, а не красивые слова.
Вопрос: Как быть, если сотрудники используют личные аккаунты Google Диска для работы с файлами?
Ответ: Лучше всего постепенно увести рабочие процессы в корпоративные аккаунты с контролируемыми правами и интеграцией с автоматизацией. Личные аккаунты сложно учесть в реестре ИСПД и практически невозможно нормально журналировать. На переходный период можно использовать Make для отслеживания файлов, приходящих из определенных источников, но стратегически стоит закрывать тему личных аккаунтов именно организационными мерами.
Вопрос: Что делать, если часть клиентов за рубежом и они настаивают на Google Диске?
Ответ: В таких случаях удобно разделять контуры данных: для зарубежных клиентов, не подпадающих под 152-ФЗ, можно использовать Google Диск как основное хранилище. Для российских клиентов лучше настроить гибридную схему, при которой Google Диск служит только точкой обмена, а все копии с ПДн локализуются в РФ. Внутри компании стоит четко развести эти потоки и не смешивать данные разных категорий в одних и тех же папках.
Вопрос: Обязательно ли регистрироваться как оператор ПДн, если я фрилансер и у меня только база клиентов?
Ответ: Да, с учетом изменений последних лет регистрация как оператор ПДн требуется практически всем, кто системно собирает и обрабатывает персональные данные, даже если это маленькая база клиентов. Объем бизнеса или количество людей в штате не освобождает от этой обязанности. Автоматизация через Make не заменяет регистрацию, но помогает потом выполнять обязанности оператора без лишней ручной рутины.
Вопрос: Можно ли полностью доверить настройку Make внешнему подрядчику и не вникать в детали?
Ответ: Передать техническую реализацию подрядчику можно, но ответственность за соответствие 152-ФЗ все равно останется на вас как на операторе ПДн. Поэтому хотя бы на базовом уровне разбираться в архитектуре и понимать, где лежат ваши данные и какие сценарии их обрабатывают, все-таки нужно. Хорошая связка — внешний интегратор для глубокой настройки и внутренний ответственный, который контролирует, что автоматизация живет и не противоречит политике обработки данных.
Метки: ai-agents, makecom, n8n, автоматизация, автопостинг, контент-план