Автоматизация Power BI в Make в России — это не про волшебную кнопку, а про аккуратный тетрис из интеграций, 152-ФЗ и здравого смысла. За несколько шагов можно собрать обновляемые отчеты без ручных выгрузок по ночам, но только если сразу учесть локализацию, обезличивание и то, что Роскомнадзор сейчас смотрит в сторону автоматизации куда внимательнее, чем пару лет назад. В этом тексте я разберу, как настроить автоматизацию Power BI через Make так, чтобы это работало стабильно и при этом не становилось бомбой замедленного действия с точки зрения ПДн. Материал рассчитан на российских специалистов — аналитиков, интеграторов, владельцев продуктов и тех, кто уже дружит с n8n, Make, ИИ-агентами и хочет, чтобы отчеты жили своей жизнью, а не отнимали полдня каждую неделю.
Пока я допивала остывший кофе и в третий раз перезапускала сценарий в Make, мне писала Света из маркетинга: «Марин, ну сколько можно, у меня отчеты по рекламным кампаниям всегда отстают на день, а бить руками выгрузки из CRM я больше не могу». У Светы был типичный набор: российская CRM с заявками и продажами, рекламные кабинеты, несколько отдельных таблиц в Excel и руководитель, который хотел утром видеть живые цифры в Power BI, а не объяснения, почему дашборд снова вчерашний. Я пообещала, что мы сделаем ей обновляемый отчет через Make, и в этой статье покажу, как мы к этому пришли и как повторить тот же путь без нарушения 152-ФЗ, истерик в ИБ и бессонных ночей у аналитика.
Время чтения: примерно 8-10 минут
Зачем вообще трогать автоматизацию Power BI в Make
Как выглядит ручная жизнь с отчетами и почему это быстро надоедает
Когда я первый раз пришла на проект, где Power BI обновлялся только руками, я поймала себя на мысли, что нахожусь в 2010-м, а не в 2025-м. Аналитик по утрам открывал CRM, выгружал Excel, чистил лишние колонки, грузил в папку, запускал обновление Dataset, а потом еще писал письмо: «Отчет обновлен, смотрите». Продолжалось это до тех пор, пока один день он не заболел, и отчет «встал». Руководитель привык, что цифры есть, а вот автоматизации — нет, и каждый такой сбой превращался в мини-кризис. Автоматизация Power BI через Make как раз и решает эту проблему: Make выступает оркестратором, который сам следит за событиями в источниках и по расписанию или по триггеру отдает Power BI аккуратно подготовленный кусок данных.
С точки зрения бизнеса, все звучит тривиально: меньше ручного труда, меньше ошибок, меньше зависимости от конкретного человека. Но в России на это накладывается дополнительный слой — 152-ФЗ, локализация персональных данных и аккуратное обращение с сервисами, которые потенциально могут лежать за пределами РФ. Один и тот же сценарий «подтянуть сделки из CRM в Power BI через Make» в условной европейской компании и в московском офисе может иметь разный набор ограничений, именно поэтому я в таких историях начинаю не с интеграции, а с карты данных: где хранятся, чей сервер, есть ли ФИО и телефоны, какие цели обработки. Это скучно, но иначе интеграция рискует стать юридически токсичной.
Вот как это выглядит на практике в самом простом случае: у нас есть CRM, где лежат сделки, клиенты, статусы, суммы. Есть Power BI, в котором настроен Dataset и построены отчеты для руководителей. Есть Make, который умеет раз в час забирать новые сделки из CRM по API, складывать их в промежуточный набор (таблица или JSON), подчищать и потом через Power BI API обновлять Dataset. Звучит красиво, но если в этих сделках есть телефон, e-mail и ФИО, а Make использует инфраструктуру, которая не локализована под РФ, то у юриста начинает дергаться глаз. Это означает, что правильная автоматизация всегда начинается с вопроса «что мы передаем» и только потом — «как мы это автоматизируем».
Чтобы было проще представить общую картинку, мне нравится визуализировать архитектуру. Здесь не нужны сложные UML-диаграммы, достаточно один раз посмотреть на понятную схему, а потом возвращаться к ней, когда рука тянется «просто кинуть еще одно поле в интеграцию».
Получается, что автоматизация power bi через Make — это не просто «подружить два сервиса», а продумать цепочку: источники — слой подготовки — Make — Power BI — пользователи. И чем лучше вы понимаете эту цепочку, тем меньше сюрпризов потом прилетит от ИБ, Роскомнадзора или просто от расширившейся команды, которая внезапно начнет спрашивать, почему логика обновлений нигде не документирована.
Какие задачи автоматизации Power BI особенно хорошо решаются через Make
На практике Make для Power BI я использую как швейцарский нож, который закрывает сразу несколько классов задач. Во-первых, это регулярное обновление Dataset по расписанию, когда источники данных живут в разных системах: часть в CRM, часть в файлах, часть в базе данных. Power BI сам по себе умеет много, но Make позволяет заранее собрать все нужные кусочки, преобразовать и только потом отдавать в Power BI уже готовый набор. Во-вторых, это реактивные обновления: например, когда пришла крупная сделка, сценарий в Make ловит вебхук и сразу запускает обновление конкретного набора данных, чтобы руководитель увидел изменение не через несколько часов, а почти сразу.
В-третьих, Make отлично справляется с подготовкой экспортов и рассылок — сделать PDF-отчет на базе Power BI и разослать конкретным людям, сохранить CSV в архив или положить файл в защищенное хранилище в РФ. Это особенно полезно для компаний, где не все пользуются онлайновым Power BI, но хотят утром получать свежий срез в почту или в корпоративный мессенджер. И в-четвертых, Make удобно использовать как «прослойку здравого смысла»: он умеет фильтровать события, считать метрики, проверять, не ушла ли аномальная цифра, и в нужный момент останавливать или логировать подозрительную активность (хотя сама я так делала ровно один раз, когда словили странный всплеск заказов из тестовой среды).
Если выделить типовые сценарии, где автоматизация Power BI в Make выглядит логично, получится несколько категорий, и они хорошо соотносятся с задачами российских команд, работающих в white-data-зоне.
Чаще всего через Make автоматизируют: обновления продаж и выручки из CRM, маркетинговые метрики по кампаниям, операционные KPI (звонки, заявки, статусы), а также подготовку агрегированных данных для руководителей, где ФИО и контакты вообще не нужны.
Это означает, что автоматизация Power BI через Make в российских реалиях особенно хороша там, где удается уйти в агрегаты и обезличенные данные, оставляя персональные детали внутри локальной инфраструктуры. В следующих разделах я покажу, как эту архитектуру собрать аккуратно и не наступить на юридические грабли.
Что меняется, когда подключается российский контекст и 152-ФЗ
Как только мы переносимся в Россию, базовый вопрос «как автоматизировать обновления в Power BI» превращается в пару дополнительных вопросов: «какие данные считаются персональными, где они хранятся физически, и какие у нас есть основания для их обработки и передачи». Я не юрист, но внутренний аудитор во мне регулярно поднимает бровь, когда я вижу, как в Make тянут в чистом виде ФИО, телефоны и e-mail во внешние сервисы. Если вы работаете с гражданами РФ, то 152-ФЗ требует локализовать базы данных, где первично обрабатываются ПДн, на территории России, а зарубежные и облачные сервисы автоматически попадают в зону повышенного внимания.
На практике это не значит, что автоматизация make для power bi запрещена, это значит, что нужно уметь отделять обезличенные наборы данных от тех, где можно идентифицировать человека. Если нам нужны только суммы, статусы, даты, каналы привлечения и конверсии — мы можем обезличить данные до того, как они попадут в Make и дальше в Power BI Service. Если же кому-то в отчете зачем-то понадобилось полное ФИО и телефон клиента в облачной витрине — вот там и начинается самое интересное с точки зрения регулятора и ИБ. В таких проектах я всегда спорю с владельцами процессов: «Вы действительно хотите видеть телефоны в этом отчете или это просто привычка?». Звучит странно, но работает.
В истории со Светой из маркетинга картина была типичной: CRM на российском сервере, Power BI частично в облаке Microsoft, Make — как отдельная интеграционная прослойка. Света хотела видеть эффективность кампаний и разбивку по сегментам, но не нужна была каждая конкретная Мария Иванова с номером телефона. Мы быстро поняли, что вместо переноса сырых данных, проще на этапе ETL заменить ФИО на анонимные ID и агрегировать показатели по когорте и каналу. В итоге Power BI получал белые данные, Make не видел персональные детали, а ИБ на проекте вздохнула чуть спокойнее. На этом месте логично перейти к тому, как эту архитектуру вообще собирать.
Получается, что вопрос «зачем автоматизировать Power BI через Make» в российских реалиях имеет простой ответ: чтобы освободить людям время, не потерять контроль над персональными данными и не превращать каждую выгрузку в отдельное приключение с флешками, паролями и устными договоренностями. Дальше — про архитектуру.
Как продумать архитектуру автоматизации Power BI с учетом 152-ФЗ
С чего начать: описание процессов и классификация данных
Когда я захожу на проект, где хотят автоматизировать отчеты, я не открываю сразу Make, а открываю таблицу. Там я описываю процессы обработки данных: что за процесс, откуда данные, кто владелец, какие категории информации внутри, есть ли персональные данные граждан РФ. Это не про бюрократию ради бумажки, а про то, чтобы через неделю не обнаружить сюрприз в виде того, что один из потоков данных внезапно содержит паспорта, ИНН или геолокацию, которая позволяет идентифицировать человека. По 152-ФЗ у российских операторов должна быть прозрачная картинка по обработке ПДн, и автоматизация никуда от этого не девалась, она просто добавила динамики.
В этой таблице я обычно выделяю столбец «Можно ли обезличить данные для отчетности». Очень часто оказывается, что в Power BI нам вообще не нужно видеть того, кого можно идентифицировать. Аналитику интересуют суммы, конверсии, длительность сделок, воронки, а не номера телефонов. Если ответ «да, можно обезличить», то дальнейшая автоматизация power bi становится заметно проще: мы проектируем ETL таким образом, чтобы на выходе в Make и дальше в Power BI летели только обезличенные агрегаты или идентификаторы, которые без отдельной таблицы сопоставлений ни о чем не говорят.
Чтобы не забыть, какую информацию мы уже классифицировали, я использую очень простой прием — делаю для каждого процесса небольшую текстовую карточку. Это может быть внутренняя страничка на портале или даже запись в документации ИБ, но суть одна: кому принадлежит процесс, какие данные используются, где физически они лежат (дата-центр в РФ, локальный сервер, российское облако), как долго хранятся. Потом эти же карточки отлично ложатся в реестр обработки ПДн, который нужен по закону, так что работа не пропадает впустую.
Здесь стоит зафиксировать короткое напоминание, которое хорошо работает как проверка здравого смысла перед любой интеграцией.
Если вы не можете за минуту объяснить, какие именно категории данных уходят в Make и дальше в Power BI, автоматизация еще не готова к продакшену.
Это означает, что первый этап архитектуры — не про API и токены, а про осознанное описание того, какие данные вы гоняете и зачем. И да, в истории со Светой мы именно с этого начали, хотя ей казалось, что быстрее «просто настроить интеграцию, а потом разберемся».
Как выглядит базовая архитектурная схема Make — Power BI для России
Когда с классификацией разобрались, я рисую довольно понятную схему, которая в российском контексте почти всегда включает отдельный слой подготовки данных, размещенный в РФ. В простом виде это выглядит так: Источники данных (CRM, ERP, заявки с сайта, рекламные кабинеты) — Локальный ETL в инфраструктуре в России — Make как оркестратор — Power BI Dataset и отчеты. Локальный ETL может быть чем угодно: скриптом на сервере, интеграционной платформой в дата-центре, даже регулярным заданием в СУБД, но его задача — принять сырые данные, обезличить там, где это нужно, агрегировать, отфильтровать, а дальше приготовить «белый» набор для передачи.
На этапе ETL я предпочитаю делать все тяжелые операции: соединения таблиц, расчеты производных метрик, маскирование полей. Make при такой архитектуре становится легче — он больше про оркестрацию, чем про серьезные трансформации. Это хорошо еще и потому, что вы можете жестко ограничить, какие поля из исходной базы вообще доступны за пределами РФ. В идеале Make никогда не видит чистые ФИО и телефоны, а работает уже с обезличенными ID и суммами. Да, с точки зрения гибкости это чуть менее удобно, чем просто кинуть весь JSON в Make, но зато не нужно потом объяснять ИБ, почему облачный сервис получил полный набор персональных данных.
В этой архитектуре важно не забыть про обратную сторону — куда уходят отчеты и выгрузки. Power BI может жить в локальной среде или частично в облаке Microsoft, а дальше отчеты читают менеджеры, руководители, иногда внешние партнеры. Я всегда смотрю на настройки доступа и на то, не вываливается ли случайно чувствительная информация в общий доступ. Если в компании несколько уровней отчетов, то имеет смысл разнести их по Dataset: один набор с максимально обезличенными агрегатами для широкой аудитории, второй — с более детальными полями, но доступный ограниченному кругу пользователей через RLS и отдельную инфраструктуру.
Иногда мне задают вопрос: «Можно ли вообще не делать отдельный ETL-слой, а всё делать прямо в Make?» Теоретически да, Make умеет и фильтровать, и маскировать поля, и подготавливать таблицы. Но для российского контекста наличие отдельного слоя в инфраструктуре РФ — это не только про удобство, а скорее про контроль и соответствие 152-ФЗ. ETL на своей стороне, под управлением своей ИБ-команды, всегда проще объяснить проверяющим, чем магический облачный сценарий, где часть логики живет где-то «там» (нет, подожди, есть нюанс: если у вас частное облако с понятной юрисдикцией, иногда его можно приравнять к своей инфраструктуре, но это уже отдельный разговор с юристами).
Архитектура Make — Power BI для России почти всегда выигрывает, когда есть локальный слой подготовки данных, а в облако уходит только то, что не идентифицирует человека или не нарушает локализацию.
Получается, что схема, нарисованная на салфетке, превращается в реальную политику обработки ПДн и набор тех настроек, который потом спасает от неудобных вопросов. Дальше можно переходить к конкретике — как именно Make подключать к Power BI, какие шаги в сценарии нужны и где там живут наши любимые токены.
Где в эту архитектуру встроить реестр обработки и ИБ-документацию
Я заметила, что про документы вспоминают только тогда, когда в дверь стучится аудит, а лучше бы наоборот. Реестр обработки ПДн, который сейчас обязателен для операторов в России, отлично дружит с архитектурой Make — Power BI. Каждый автоматизированный сценарий можно описать как отдельный элемент реестра: какие данные берутся из CRM, какие операции над ними выполняются, кто получает доступ к отчетам в Power BI, какие сроки хранения и как реализована защита. Это скучно, но потом именно эти записи открываются на проверках, и хорошо, когда они написаны не задним числом.
Часть работы удобно автоматизировать: тот же Make может при запуске сценария писать события в отдельную таблицу — кто обновлял Dataset, когда, сколько строк обработано. Эти логи потом становятся частью доказательной базы, что вы контролируете автоматизацию, а не работаете вслепую. Я иногда подключаю российские сервисы учета и аудита ПДн, чтобы не изобретать велосипед, но при желании можно вести и свой реестр, пока он не разросся до монструозных размеров. Главное, чтобы он существовал не только в голове аналитика.
В архитектурной схеме я добавляю еще одну стрелочку — от Make и Power BI к реестру и журналу событий. Это позволяет держать одну картинку: слева источники данных, сверху ETL в РФ, посредине Make, справа Power BI, а внизу документация и учет. Когда через полгода на проекте появляется новый аналитик, он открывает эту схему и уже не задает двадцать вопросов про то, кто придумал эти интеграции и почему они устроены именно так. Для российских реалий такая прозрачность — не роскошь, а способ сэкономить нервы при первых же изменениях в законе или проверках.
Чем раньше автоматизация попадает в реестр и документацию, тем меньше шансов, что потом ее придется в спешке «узаконивать» под прицелом проверяющих.
Это означает, что архитектура автоматизации Power BI в Make — это не только про технические блоки, но и про встроенность в систему управления ПДн внутри компании. Как только это понимаешь, многие решения становятся проще: появляется критерий выбора — «мы делаем так, потому что потом сможем спокойно это описать и защитить».
Как настроить Make для Power BI: от триггера до обновления Dataset
Что нужно подготовить в Power BI, прежде чем лезть в Make
На практике я вижу, что многие бросаются в Make, пока в Power BI ещё нет внятной структуры. А на самом деле удобнее сначала навести порядок в самом Power BI: создать Dataset, который будет принимать данные, описать модель, настроить права доступа и RLS, если нужны разные уровни видимости, и только потом к нему «подводить» Make. В противном случае вы получите интеграцию, которая каждый раз ломается при любой правке модели, и это особенно болезненно, когда сценарий в Make запускается ночью.
В Power BI я рекомендую выделить отдельный Dataset для автоматических обновлений, а не пытаться совать все в один монолитный набор. Это позволяет вам обновлять только то, что реально нужно, а не гонять по сети гигантские таблицы ради одной метрики. В настройках вы определяете, будет ли использоваться incremental refresh, какие поля считаются ключами, какие — датами для отсечек. Потом уже Make будет подготавливать данные в нужном формате: чаще всего это таблица с колонками, которые точно совпадают с моделью, чтобы обновления шли без сюрпризов.
Помнишь про кофе из начала? Вот это тот момент, когда он как раз остывает, потому что пока ты объясняешь команде, что без описанной модели в Power BI есть шанс испытывать боль каждый раз при обновлении. Я предпочитаю потратить час на то, чтобы нарисовать минимальную ER-схему, чем потом ночами разбираться, почему Power BI внезапно перестал понимать приходящий набор из Make после очередного «мелкого» изменения столбца.
Чтобы не упустить nothing, я обычно записываю текстом, какие таблицы будут обновляться автоматизированно, какие остаются статичными, и какие связи между ними не должны ломаться. Это не та документация, которую будут читать на совещаниях, но она спасает в моменты, когда нужно быстро понять, куда смотреть при ошибке. Особенно, если через полгода вы сами забудете, почему сделали именно так (а вы забудете, это нормально).
Перед тем как подключать Make, в Power BI должен быть понятный Dataset с четко описанной моделью, правами доступа и пониманием, какие поля будут обновляться автоматически.
Это означает, что настройка make для power bi начинается не в одном, а сразу в двух инструментах, и Power BI тут не пассивный получатель, а равноправный участник связки. Чем аккуратнее он подготовлен, тем проще будет сама интеграция.
Как собрать базовый сценарий в Make для обновления Power BI Dataset
Когда в Power BI всё готово, я иду в Make и создаю новый сценарий. В самой простой конфигурации он состоит из триггера, блока обработки данных и шага загрузки в Power BI. В качестве триггера может быть расписание (каждый час, каждый день в 3:00), вебхук из CRM, изменение файла в хранилище, событие в базе данных. Дальше Make забирает данные, проводит нужные преобразования — фильтрацию, агрегацию, маскирование — и формирует итоговый массив, который отправляется в Power BI через API.
Технически всё упирается в то, как именно вы будете подключаться к Power BI. В большинстве случаев это работа с REST API, где нужно получить токен доступа, указать Dataset, таблицу и передать данные в формате JSON. Make позволяет упаковать это в удобные модули, чтобы не писать код руками каждый раз. В некоторых конфигурациях я добавляю промежуточный шаг: сохранить подготовленные данные во временный файл или таблицу в российском хранилище, а уже потом инициировать обновление Power BI через локальный шлюз. Это добавляет один шаг, но даёт дополнительный контроль над тем, что именно было отправлено.
Чтобы контролировать то, что уходит в Power BI, я обязательно добавляю в сценарий шаг логирования: короткая запись в отдельную таблицу с датой, количеством обработанных записей, типом события. Один раз эта маленькая привычка спасла проект — мы быстро доказали, что данные обновлялись корректно, а проблема была уже в визуализациях. Без логов разговоры «а вы точно всё правильно обновили?» могут растянуться на часы. Кстати, здесь удобно подключить российские хранилища, чтобы все журналы лежали в РФ и не вызывали лишних вопросов у ИБ.
Если сценарий Make обновляет Power BI и при этом нигде не фиксируется, что он сделал, вы теряете половину ценности автоматизации.
Это означает, что базовый сценарий Make для Power BI — это не только триггер и API-вызов, а минимальный набор шагов: забор данных, подготовка/маскирование, загрузка в Power BI, логирование события. Для российской компании именно такая «расширенная база» будет рабочей, а не голый вызов API без следов.
Как встроить в сценарий Make российские ограничения и требования по ПДн
Когда речь заходит о России, в каждый сценарий Make я мысленно вставляю два фильтра. Первый — «нужна ли идентификация конкретного человека на этом этапе?». Если нет, то все, что можно, уходит в агрегаты и обезличивание. Второй — «где физически будут храниться и обрабатываться эти данные?». Если ответ — за пределами РФ или на неясной инфраструктуре, то необезличенные ПДн туда лучше не пускать. Эти вопросы превращаются в конкретные шаги в сценарии: маскирование полей, удаление лишних колонок, сокращение логов.
В Make это делается довольно прямолинейно: перед отправкой данных в Power BI вы добавляете блок, который удаляет или изменяет чувствительные поля. ФИО заменяется на хеш или внутренний ID, телефоны маскируются, оставляя примерно код региона и несколько цифр, e-mail можно усечь до домена, если он вам нужен для аналитики. Важный момент — делать это ещё до того, как данные попадут в модули, которые могут вести логи или кэшировать запросы. Иногда приходится вручную отключать подробное логирование в Make, чтобы в журналах не осталось «подарков» проверяющим.
Помимо маскирования, я всегда смотрю на ретеншн: как долго Make хранит историю запусков и временные данные. В некоторых случаях можно сократить сроки хранения до минимума и хранить только агрегированные результаты. Это не только снижает нагрузку, но и уменьшает поверхность риска. В одном проекте мы настроили так, что полные массивы данных вообще нигде не сохранялись после отправки в Power BI, а логировались только факты запуска и короткая статистика. ИБ сначала удивилась, потом одобрила.
Хороший сценарий Make для Power BI в России не только обновляет отчеты, но и минимизирует количество мест, где могут «осесть» персональные данные.
Возвращаясь к той самой ситуации со Светой: мы встроили в сценарий Make отдельный шаг, который брал отчетную выгрузку из локального ETL-слоя уже в обезличенном виде. Make даже теоретически не видел ФИО и телефоны, его задачей была только оркестрация. В результате сценарий стал чуть длиннее, но архитектура — заметно спокойнее для ИБ и юристов. Это типичный компромисс, к которому стоит быть готовыми, если вы хотите долго и мирно жить с автоматизацией в России.
Как обезличивать данные и не поссориться с безопасниками
Какие методы обезличивания реально работают для Power BI и Make
Я поняла, что разговоры про обезличивание перестают быть теорией, когда один из безопасников на проекте положил передо мной распечатку и сказал: «Покажи, где здесь человек». На листе были только ID клиентов, суммы и даты. Это было то, к чему мы стремились — Power BI получал полноценные данные для аналитики, но без возможности восстановить, кто именно стоял за каждой строкой, без отдельной базы сопоставлений. Для автоматизации через Make это почти идеальный вариант, потому что снимается большая часть рисков, связанных с передачей ПДн за пределы локальной инфраструктуры.
На практике я использую три основных подхода. Первый — хеширование или замена идентификаторов. Исходный клиентский ID или ФИО превращаются во внутренний суррогатный ключ, чаще всего через одностороннюю функцию, которую нельзя легко обратить. При этом аналитика по клиентам сохраняется: одна и та же Мария Иванова всегда будет иметь один и тот же ID в отчетах, но без доступа к исходной таблице сопоставлений вы не узнаете, что это именно она. Второй подход — частичное маскирование: полезно, когда нужны, например, регион или тип контакта, но не конкретные реквизиты. Третий — агрегация: когда можно вообще отказаться от уровня «строка = человек» и подняться на уровень когорты, дня, сегмента.
Каждый из этих методов по-своему влияет на то, как вы строите отчеты в Power BI. Иногда приходится потратить лишний час, чтобы адаптировать визуализации под агрегированный уровень, но это та цена, которую я, как человек из ИТ-рисков, плачу с удовольствием. Между отчетом, где можно узнать, что конкретный Иван Петров купил товар на 5000 рублей, и отчетом, где видно просто сумму по сегменту в Москве, я всегда выберу второй вариант, если он закрывает бизнес-вопрос. И да, иногда маркетинг сопротивляется, но после первого разговора с ИБ энтузиазм «дайте нам все поля» обычно слегка остывает.
Чтобы не утонуть в терминах, можно зафиксировать несколько базовых формул, которые хорошо работают как напоминание перед любым новым сценарием в Make.
- Правило: если отчет не требует идентификации человека, поднимайте уровень до когорты или агрегата.
- Прием: заменяйте ФИО и ID клиентов на хеши или внутренние ключи, которые хранятся только в локальной базе.
- Формула: телефон → маска по региону + 2-3 символа, e-mail → домен или укороченная версия.
- Вариант: там, где нужен анализ поведения, используйте стабильный псевдо-ID вместо реальных данных.
- Дополнение: в Make оставляйте только обезличенные поля и убирайте всё, что можно отнести к ПДн.
Это означает, что обезличивание — не отдельная «страшная технология», а набор вполне приземленных практик, которые вы встраиваете в ETL и сценарии Make. И чем привычнее это становится для команды, тем меньше споров возникает при каждом новом отчете.
Как встроить обезличивание в ETL так, чтобы Make и Power BI не страдали
Когда я первый раз предложила выносить обезличивание в отдельный ETL-слой, часть команды вздохнула: еще один компонент, еще одна точка отказа. Но очень быстро стало ясно, что это не усложнение, а способ собрать всю «юридическую магию» в одном понятном месте. В локальном ETL мы берем сырые таблицы из CRM и других источников, проводим очистку, рассчитываем метрики, потом встраиваем шаги маскирования и только после этого складываем результат в «белое» хранилище, откуда его забирает Make.
Важный момент — разделение таблиц по уровню чувствительности. В одном проекте мы сделали две витрины: одна — полностью обезличенная, с которой работали и Make, и большинство отчетов в Power BI, вторая — детальная, доступная только ограниченному кругу людей через внутренние инструменты. Power BI к ней подключался только внутри периметра, без участия Make и внешних интеграций. Такой подход позволяет честно сказать: вот тут у нас автоматизация через облачные компоненты, но работает она только с white-data, а вот тут — закрытая часть, где живут полные ПДн.
С технической точки зрения ETL-шаги обезличивания можно описать в документации так, чтобы ИБ было легче оценивать риски: какие поля маскируются, какая функция используется (без деталей реализации, если они секретны), на каком этапе и насколько это влияет на возможность восстановления личности. Я часто упрашиваю команды завести отдельный раздел в документации под эти трансформации, чтобы потом не искать по коду, где именно «обрезали» телефоны. Да, это чуть больше работы, но зато потом никто не спорит, обезличены данные или нет, когда на проверке задают прямые вопросы.
Лучшее место для обезличивания — локальный ETL перед тем, как данные попадают в Make и дальше в Power BI, а не какая-то случайная функция в глубине сценария.
Возвращаясь к истории Светы, мы как раз пошли этим путем: в ETL на локальном сервере заменяли ФИО на внутренние ID, агрегировали сделки по кампаниям и периодам, убирали телефоны и e-mail полностью. Make видел только ID кампаний, даты, суммы и несколько тегов сегмента. Power BI строил дашборд по этим данным, и маркетинг при этом ничего не потерял: все ключевые цифры и срезы были на месте. Зато вопрос «а где у вас хранятся персональные данные клиентов?» имел четкий ответ — в локальной базе, а не в облачной интеграции.
Как договориться с безопасниками и юристами о границах автоматизации
Самый эффектный момент в истории любой автоматизации — разговор с ИБ и юристами. Я видела, как проекты стопорились только потому, что команды приходили к безопасникам в формате «мы тут уже всё настроили, просто подпишите». Работает хуже всего. Гораздо продуктивнее приходит на раннем этапе с черновой схемой, описанием данных и предложением вариантов: вот так мы можем делать, если обезличиваем, вот так — если хотим оставить идентификацию. В российских компаниях это особенно критично, потому что штрафы и претензии за ПДн сейчас — не теория, а регулярная практика.
Мой любимый прием — принести на встречу с ИБ не только архитектуру Make — Power BI, но и заранее заполненный кусочек реестра обработки ПДн по этому процессу. Там уже написано, какие данные используются, где хранятся, какие меры защиты планируются. У людей на той стороне стола сразу меняется выражение лица: вместо «опять к нам пришли с чем-то непонятным» появляется ощущение, что мы играем в одну игру, где цель — сделать удобно бизнесу и безопасно для компании. Иногда по ходу обсуждения меняются детали, но общий принцип остается.
Иногда (забудь, что я только что сказала — есть нюанс) безопасники сами подкидывают хорошие идеи. Например, один раз нам предложили ограничить доступ к части отчетов Power BI через VPN и отдельную группу в AD, чтобы детальные данные точно не потекли наружу. Другой раз юристы подсветили, что один из источников данных не был формально описан в политике обработки ПДн, и мы успели это поправить до запуска автоматизации. Это неприятные мелочи, но лучше пусть они всплывают на этапе проектирования, чем потом, когда Make уже крутит сценарии каждую ночь.
Когда ИБ видит, что в архитектуре Make — Power BI заранее предусмотрены обезличивание, локализация и учет событий, отношение к автоматизации резко теплеет.
Это означает, что путь к спокойной автоматизации в России лежит не только через техническую аккуратность, но и через вовлечение тех, кто отвечает за 152-ФЗ. И чем раньше вы их позовете к столу, тем меньше шансов, что готовый сценарий придется ломать и переписывать.
Что ещё важно знать про Make, Power BI и проверки
Какие типичные ошибки встречаются в российских проектах автоматизации Power BI
Когда я смотрю на проекты, которые ко мне приносят «на экспертизу», почти в каждом втором вижу один и тот же набор ошибок. Первая — прямая выгрузка сырых таблиц с ФИО, телефонами и e-mail из CRM через Make в Power BI Service, расположенный за рубежом. Это классика. В момент, когда всё только настраивается, кажется, что мы просто смотрим цифры, а то, что в каждой строке есть человек, забывается. Вторая ошибка — отсутствие какого-либо реестра обработки и описания сценариев. Когда я спрашиваю: «Где у вас задокументировано, что Make обновляет эти отчеты?», в ответ часто тишина или ссылка на переписку в чате.
Третья ошибка — хранение логов и бэкапов с ПДн в том же облаке, где работает Make или Power BI, без учета локализации. Иногда сценарий даже маскирует данные, но при этом логирует полные JSON-ответы в системе мониторинга, которая живет где-то далеко. Четвертая — полное отсутствие разграничения доступа к отчетам: один и тот же Dashboard, где видны и агрегаты, и чувствительные детали, открыт всем, у кого есть ссылка. Пятая — полагаться на то, что «нас маленьких никто не тронет». Это забавно, пока не приходит первая проверка по 152-ФЗ даже в небольшой компании.
В истории со Светой из маркетинга нас как раз попросили посмотреть старую схему, которую собирал предыдущий подрядчик. Она выглядела внушительно: Make, десяток сервисов, Power BI, куча стрелочек. Но при ближайшем рассмотрении оказалось, что в одном из сценариев вся таблица заказов с ФИО летела в облачный Power BI без какого-либо обезличивания. Это работало год, и всем было удобно, пока не появился ИБ-специалист, который задал пару нехитрых вопросов. Пришлось аккуратно разворачивать ситуацию: добавлять ETL, маскировать, менять Dataset и переписывать сценарии.
Самая распространенная ошибка — считать, что если автоматизация работает и всем удобно, значит, с точки зрения ПДн тоже всё в порядке.
Это означает, что при автоматизации Power BI в Make в России нужно смотреть не только на скорость и удобство, но и на «грязные» детали: где хранятся логи, какие поля уходят в интеграцию, есть ли формальные описания процессов. Чем раньше вы поймаете эти ошибки на уровне дизайна, тем меньше будет боли позже.
Как подготовиться к возможной проверке Роскомнадзора или внутреннему аудиту
Я немного предвзята, потому что у меня корни во внутреннем аудите, но считаю, что лучше готовиться к проверке всегда, даже если ее никто не анонсировал. В контексте Make и Power BI это означает две вещи: наличие документации и наличие технических следов. Под документацией я понимаю ту самую архитектурную схему, реестр процессов обработки ПДн, описание сценариев Make и политик доступа к отчетам Power BI. Под техническими следами — логи запусков, записи об обновлениях, метрики использования отчетов.
Когда аудиторы или Роскомнадзор приходят смотреть на автоматизацию, их интересует не только то, какие поля гоняются между системами, но и насколько вы сами контролируете процесс. Есть ли у вас механизмы отката, можете ли вы остановить сценарий, если что-то пошло не так, ведете ли учет, кто и когда менял настройки. Make здесь помогает: многие вещи можно логировать почти автоматически, главное — не выключать эту опцию «чтобы не засорять». В паре проектов мы добавляли отдельный шаг в каждый важный сценарий: записать факт обновления в локальную таблицу с указанием инициатора, времени и объема данных.
Одним из неожиданных, но полезных инструментов я считаю скромные внутренние обзоры — маленький внутренний аудит, когда раз в квартал вы сами проходите по своим интеграциям и проверяете: всё ли работает, всё ли еще соответствует политике обработки ПДн, не изменились ли источники. В одном из таких обзоров мы поймали ситуацию, когда CRM добавила новое поле с чувствительными данными, которое по умолчанию попадало в выгрузку, а сценарий Make уже был готов его схватить. Успели поправить фильтры до того, как данные утекли дальше.
Когда у вас под рукой есть схема, реестр и логи, разговор с аудитором превращается из стресса в рабочую встречу.
Это означает, что подготовка к проверке в контексте Make — Power BI — это не разовое действие «под аудит», а регулярная практика: вести учет процессов, логировать действия, время от времени пересматривать архитектуру. Звучит занудно, но в момент, когда кто-то задает прямой вопрос, вы радуетесь каждому вложенному в это часу.
Чем закончилась история Светы и сколько часов можно реально сэкономить
Помнишь Свету из маркетинга, у которой отчеты в Power BI всегда отставали на день? Мы с ней прошли весь путь, который я описала выше: начали с карты данных и реестра, поняли, какие показатели ей реально нужны, договорились с ИБ, что в отчет попадут только обезличенные агрегаты, настроили локальный ETL, сделали в Make сценарий, который раз в час подтягивает данные из обезличенной витрины и обновляет Dataset в Power BI. Параллельно мы задокументировали этот процесс в реестре обработки ПДн и настроили логи запусков.
До автоматизации Света тратила по 1-1,5 часа в день на подготовку и проверку выгрузок, плюс ещё время на объяснения, почему в дашборде опоздали обновления. После настройки сценария Make эти 1,5 часа вернулись к ней обратно — за месяц набежало порядка 25-30 часов, которые она смогла вложить в анализ и оптимизацию кампаний, а не в рутинные действия. За квартал это уже около 70-80 часов. Руководитель увидел не только более свежие цифры, но и улучшение самих метрик: Света успевала быстрее реагировать на провальные кампании.
С точки зрения 152-ФЗ у этой истории тоже всё было аккуратно: персональные данные клиентов остались в локальной базе, ETL готовил обезличенный набор, Make работал только с white-data, Power BI использовал эти обезличенные агрегаты для отчетов. Если бы в какой-то момент пришла проверка, у нас были бы: реестр процесса обработки, описание архитектуры, логи запусков и четкое разграничение доступа к отчетам. На практике это тот случай, когда автоматизация не только экономит время, но и снижает регуляторный риск.
В итоге Света перестала обновлять отчеты по утрам руками, получила плюс 25-30 часов в месяц и перестала вздрагивать при словах «152-ФЗ» и «Роскомнадзор».
Это означает, что грамотная настройка make для power bi в России — это не про фокусы с API, а про системный подход: архитектура, обезличивание, учет, прозрачность. Технически всё это вполне реализуемо, а эффект в часах и в спокойствии заметен уже в первый месяц.
Что ещё полезно знать перед автоматизацией
Нужно ли регистрировать Make как отдельного оператора персональных данных по 152-ФЗ
Я бы разделила ситуацию на два случая. Если вы используете Make только для обработки обезличенных данных, которые уже не позволяют идентифицировать человека, формально он не попадает под требования как обработчик ПДн, и вопрос регистрации снимается. Если же Make так или иначе работает с необезличенными ПДн граждан РФ, то его роль как лица, привлекаемого оператором к обработке, должна быть отражена в документах и договорах, что обычно делают через договор поручения и упоминание в политике обработки.
Можно ли полностью обойтись без локализации, если данные в Power BI и Make обезличены
Если данные действительно обезличены так, что невозможно восстановить связь с конкретным человеком разумными способами, то требования локализации ПДн впрямую на такие наборы не распространяются. Проблема в том, что степень обезличивания нужно уметь обосновать, и лучше, если это зафиксировано в документации и поддержано позицией ИБ и юристов. В сложных случаях имеет смысл проконсультироваться отдельно, но в целом работа с качественно обезличенными данными значительно упрощает жизнь в части 152-ФЗ.
Что делать, если Power BI Service находится за рубежом, а нужны отчеты с детализацией
В такой конфигурации я бы не рекомендовала отправлять в облачный Power BI Service необезличенные ПДн граждан РФ, чтобы не нарушать требования по локализации. Один из рабочих вариантов — хранить детальные данные в локальной базе или частном отчётном контуре внутри РФ, а в облако выводить только обезличенные агрегаты. Если нужна именно идентифицируемая детализация, имеет смысл рассмотреть локальный вариант Power BI или аналогичные инструменты, развернутые в российской инфраструктуре.
Как лучше документировать сценарии Make для внутреннего аудита
На практике работает простая структура описания: цель сценария, источники данных, перечень полей, которые обрабатываются, шаги обработки (включая обезличивание и фильтрацию), целевая система (Power BI Dataset), права доступа и сроки хранения журналов. Это можно оформить в виде карточки процесса в реестре обработки ПДн и дополнить схемой интеграции. Важно, чтобы описание было актуальным и обновлялось при изменении сценария, иначе на аудите возникнут расхождения между фактической логикой и документами.
Можно ли хранить логи Make и Power BI в зарубежных сервисах мониторинга
Если в логах и метриках нет ПДн и другой чувствительной информации, формально это возможно, но я бы рекомендовала тщательно проверить, какие именно фрагменты данных туда попадают. В случае, когда логи содержат фрагменты запросов, значения полей или идентификаторы пользователей, лучше настраивать маскирование, минимизацию или вообще хранить такие журналы в инфраструктуре РФ. Это снижает риски утечки и упрощает ответы на вопросы проверяющих о том, где именно могут оказаться ПДн.
Какой минимум нужно сделать, чтобы автоматизация Power BI через Make была безопаснее
Если совсем коротко, то имеет смысл начать с инвентаризации данных, выделить процессы, где есть ПДн, и по ним настроить обезличивание до попадания в Make и Power BI. Параллельно стоит завести реестр обработки с описанием сценариев и ограничить логирование чувствительных полей в Make и смежных сервисах. Даже эти базовые шаги уже заметно снижают риск и помогают выстроить более зрелую архитектуру, к которой потом можно добавлять дополнительные уровни защиты и контроля.
Как продолжить работу с автоматизацией и не перегореть по дороге
Если ты дочитала до этого места, у тебя уже есть скелет рабочей схемы: как автоматизировать Power BI через Make, не вываливаясь из 152-ФЗ и здравого смысла. Здесь можно пойти по двум траекториям. Первая — взять один текущий отчет, описать его в реестре, вытащить структуру данных, выстроить локальный ETL и собрать аккуратный сценарий в Make. Вторая — сначала сделать маленький «аудит автоматизации» в компании: где уже крутятся интеграции, какие отчеты обновляются руками, какие поля там на самом деле живут. После этого картинка становится заметно яснее, и решение, за что браться первым, приходит само.
Когда мне пишут про автоматизацию через n8n, Make или ИИ-агентов, чаще всего это запрос «как перестать все делать руками и не нарваться на проблемы с ПДн». На эти вопросы я регулярно отвечаю у себя в телеграм-канале, и если хочется посмотреть на большее количество живых кейсов и схем, можно заглянуть в канал MAREN — там я как раз разбираю такие истории по слоям. А если интереснее структурированная часть, где собраны материалы по автоматизации, AI governance и примеры архитектур, то на сайте promaren.ru можно найти разборы проектов и подходов без рекламного шума.
Самое полезное, что можно сделать в ближайшие 1-2 недели, — выбрать один понятный процесс (например, обновление отчета по продажам), описать его, проверить, какие данные реально нужны для аналитики, и попробовать собрать минимальную, но аккуратную цепочку: локальный ETL, Make, Power BI, логи и запись в реестре. Не обязательно сразу автоматизировать всё, иногда один хорошо сделанный сценарий меняет отношение команды к автоматизации намного сильнее, чем десять полуготовых. И да, кофе, который остывает рядом с ноутбуком, можно наконец-то допить, пока Make ночью сам тянет данные и бережет ваше время.
Метки: ai-agents, makecom, n8n, автоматизация, автопостинг, контент-план