Создание инфографики через Make и Canva API звучит как мечта: настроил один раз, и визуалы для отчета сами высыпались в папку. Особенно в России, где многие дизайнеры и маркетологи уже живут в автоматизациях и n8n, а ручной Canva-марафон хочется оставить в прошлом. Но как только в эти картинки попадают имена клиентов, e-mail или телефоны, в игру заходит 152-ФЗ, Роскомнадзор и вопрос: где физически лежат данные. В этой статье я разберу, как организовать создание инфографики, не выезжая за границы РФ-реалий, и почему Canva API инфографика — это уже не про «подключил и забыл», а про архитектуру и ответственность. Писать буду из своего опыта AI Governance & Automation Lead, с фокусом на white-data: только легальные, чистые данные, никаких серых баз и «утекших» телефонов. Для кого этот текст: для дизайнеров, маркетологов, продакт-менеджеров и основателей, которые устали руками собирать графики из Excel и хотят, чтобы процессы были прозрачны, а метрики честные.
Чтобы не было ощущения сухого ГОСТа, заведем один живой кейс. Ко мне пришел клиент — Олег, руководитель маркетинга в небольшом ритейле из Подмосковья. У него был классический хаос: отчеты по рекламным кампаниям в Google Sheets, выгрузки из CRM, фрилансеры, которые раз в неделю собирали инфографику в Canva вручную. Олег хотел: один сценарий в Make, который берет данные, подставляет в шаблон, рендерит картинки и отправляет их в Telegram-чат команды. Идея красивая, но уже на первой встрече всплыло, что в этих таблицах полно ПДн: имена менеджеров, телефоны клиентов, иногда даже комментарии с жалобами. Я пообещала Олегу показать архитектуру, в которой он не влетит на штраф, а инфографика перестанет забирать вечера у дизайнеров.
По опыту, такой разговор обычно начинается с романтики про «5 шагов автоматизации», а заканчивается обсуждением Роскомнадзора и того, почему Google Sheets для метрик из России в 2025 году — это лотерея. Поэтому я предлагаю идти по-другому: сначала трезво посмотрим на риски и ограничения, затем на инструменты, потом на сам процесс интеграции Make с визуальными сервисами, а уже после вернемся к Олегу и его инфографике. Я буду периодически оговариваться, если чувствую, что сама когда-то делала не так, чтобы было понятно: это не лекция с кафедры, а честный разбор человека, который тоже однажды тянул данные в Canva API ночью, а утром читал новости про очередные штрафы Роскомнадзора.
Почему автоматизация инфографики в России начинается с 152-ФЗ, а не с шаблонов
Когда меня спрашивают, как автоматизировать создание инфографики для маркетинговых отчетов, многие ждут ответ про «5 модулей в Make и всё полетело». Но в России первый шаг — вообще не про Make и не про Canva, а про классификацию данных: что из того, что вы хотите визуализировать, является персональными данными по 152-ФЗ. Как только в диаграмму попадает ФИО менеджера, телефон клиента или e-mail, вы превращаете безобидный красивый график в объект интереса Роскомнадзора. И если данные уходят на иностранный сервер, это уже трансграничная передача, которую с 2025 года, по сути, нужно либо отдельно обосновывать, либо не допускать вообще. Поэтому Canva API инфографика для российских клиентов становится юридической задачей не меньше, чем дизайнерской.
Чтобы было проще, я обычно предлагаю мысленно разделить все, что попадает в автоматизацию, на три корзины. Первая — чисто агрегированные метрики: общий оборот, конверсия, средний чек, без возможности вывести конкретное лицо. Вторая — обезличенные данные, где есть, например, ID вместо имени, но где теоретически можно восстановить личность при наличии доступа к исходной базе. Третья — явные ПДн: имена, телефоны, e-mail, должности. С точки зрения закона, вторая и третья корзина — зона риска, и именно их нельзя бездумно прогонять через западные сервисы. White-data в моем понимании — это ситуация, когда и источник, и путь данных, и их конечное хранение прозрачны и задокументированы, без «ну мы просто так делали всегда». Это критично, потому что с 2026 года Роскомнадзор обещает автоматический анализ сайтов и политик, и история «фрилансер не знал» никого уже не тронет.
Я заметила, что настоящая головная боль начинается не на уровне закона, а на уровне привычек. Маркетологи обожают хранить всё в одном Google Sheets, дизайнеры берут эти таблицы и заливают в Canva, а фрилансеры, работающие из дома, даже не задумываются, где физически лежит сервер, обрабатывающий эти запросы. В российской реальности это уже не просто «плохо», а прямо рискованно: при проверке Роскомнадзор смотрит, где хранятся и куда утекают ПДн, и за отсутствие локализации или уведомления можно получить штраф до 300 тысяч, а при повторе — до 500. Я видела кейс агентства в Петербурге, которое словило 150 тысяч за то, что хранило ПДн клиентов в Google Sheets и использовало эти данные в автоматизации, хотя им казалось, что «это же просто таблица». Здесь работает простое правило: если вы тянете данные через Make, n8n или любой другой оркестратор, вы как оператор несете ответственность за каждый шаг маршрута этих данных.
Чтобы не утонуть в букве закона, я обычно предлагаю клиентам короткую дорожную карту того, с чего начать. Для первой оценки помогает подчеркивание тех полей, которые потенциально могут быть ПДн, прямо в схеме бизнес-процесса. Отмечаете все места, где фигурируют имя, контакты, поведенческие данные, привязанные к человеку, и сопоставляете это с тем, какие сервисы используются на каждом шаге. Это почти всегда открывает глаза, потому что внезапно выясняется, что данные одновременно проходят через зарубежный CRM-плагин, форму на сайте без шифрования и старый аккаунт в зарубежном облаке. Получается, что настоящий первый шаг к автоматизации инфографики в России — это ревизия маршрута данных, а не подбор красивого шаблона в Canva.
Как понять, какие данные можно смело пускать через Make и Canva, а какие нет
На практике я разделяю все сценарии создания инфографики по уровню риска. Есть низкорисковые сценарии, когда вы визуализируете обезличенные агрегированные метрики: например, рост продаж по категориям товаров без указания конкретных покупателей или сотрудников. Такие данные можно обрабатывать и в Make, и в любом графическом сервисе, если они не позволяют восстановить личность человека. Есть средний уровень — когда в инфографике фигурируют названия отделов, города или названия сегментов клиентов без прямого указания людей, но всё равно лучше держать эти данные на российских серверах, чтобы не цепляться за трансграничку. И есть высокий уровень — репорты по менеджерам, инфографика по клиентам, воронки с e-mail и телефонами. В этой зоне любая интеграция с Canva API становится проблемой, потому что Canva — зарубежный сервис, и данные туда просто не должны утекать.
Чтобы не споткнуться, я предлагаю клиентам простую логическую рамку (звучит громко, но в жизни это 15 минут с маркером). Сначала мы описываем, какие типы инфографики вообще нужны: отчеты по кампаниям, воронки продаж, HR-метрики, аналитика по обучению. Затем на каждом типе отмечаем, есть ли там привязка к человеку — и если да, то как глубоко. Если в отчете указывается только «команда отдела маркетинга», риски гораздо ниже, чем в истории «ТОП-10 менеджеров по продажам с фото и именами». На этом этапе часто всплывает противоречие: бизнесу хочется персональных рейтингов, а юристы (или я) говорят, что это уже не просто картинки, а довольно плотная обработка ПДн с оценочными суждениями. Иногда приходится говорить клиенту: забудь, что я только что сказала про красивый рейтинг в инфографике — под 152-ФЗ это отдельная болище, давай оставим только агрегированные данные по отделу.
Я заметила, что хороший индикатор адекватного уровня автоматизации — способность клиента внятно ответить на вопрос: где физически лежат данные для каждого шага. Если человек уверенно говорит «1C на сервере в РФ, Яндекс.Облако, VK Cloud, Make как оркестратор без хранения ПДн» — с ним работать комфортно. Если на каждом вопросе слышу «ну, вроде где-то в Европе, но там всё по GDPR» — это красный флаг. На уровне инфографики это кажется мелочью: ну какая разница, где рендерится картинка. Но в глазах регулятора разница огромная. Это означает, что качественная автоматизация здесь начинается не с API-ключа Canva, а с прозрачной схемы, на которой все стрелки с данными остаются в юрисдикции РФ.
Чтобы зафиксировать мысль, я люблю проговаривать с клиентом одну простую фразу.
Если в инфографике есть хотя бы один элемент, позволяющий идентифицировать человека, то вы обязаны думать о 152-ФЗ прямо так же серьезно, как о дизайне и юзабилити
. Для многих это становится точкой разворота, и разговор про «давайте срочно подключим Canva API» сам собой трансформируется в «давайте сначала посмотрим, что можно сделать на российских сервисах». На этом месте мы плавно переходим к тому, чем можно заменить Canva и как Make встраивается в архитектуру, не ломая ни закон, ни рабочий процесс.
Какими инструментами лучше собирать цепочку Make — визуальный сервис — хранилище
Когда с рисками более-менее разобрались, появляется естественный вопрос: чем в России заменить связку «данные — Make — Canva API инфографика». Здесь мне помогает базовое ИТ-аудиторское мышление: сначала рисуем архитектуру, потом выбираем конкретные сервисы. В центре у нас Make как оркестратор: он получает данные из CRM или таблиц, обрабатывает их и передает дальше. Вокруг — хранилище (Яндекс.Облако, VK Cloud, свой сервер), визуальный движок (российский графический сервис с API или собственный шаблонизатор) и конечные точки — Telegram, почта, внутренняя папка. Canva в этой схеме в классическом виде не помещается, потому что тянуть ПДн в зарубежный сервис нельзя, а чисто декоративные инфографики без данных проще собрать руками или через локальные альтернативы.
Я заметила, что чаще всего в российских проектах выбор идет между тремя путями. Первый — использовать готовые графические сервисы с API, размещенные в РФ: это могут быть конструкторы вроде российских аналогов Canva, движки на базе Tilda API или кастомные модули в своих продуктах. Второй — собирать инфографику через библиотеку визуализации (например, charts в backend-сервисе), а Make использовать только как триггер, который дергает endpoint и получает уже готовую картинку. Третий — максимально обезличивать данные до того, как они попадают хоть куда-то вне внутренней сети, и для внешних сервисов отдавать только агрегированные метрики. Ключевая идея здесь в том, что Make становится оркестратором, а не местом хранения или анализа ПДн.
Чтобы не запутаться в опциях, я люблю раскладывать их для клиента в виде небольшого списка решений с плюсами и минусами.
- Интеграция Make с российским конструктором дизайна, у которого есть API и сервера в РФ.
- Использование собственного backend-сервиса для рендера графиков с последующей автоматизацией выгрузки через Make.
- Комбинация: Make работает с агрегированными данными, а внутри компании отдельный сервис дорисовывает инфографику.
- Полный отказ от зарубежных сервисов для любых отчетов, содержащих ПДн, и перевод их на локальные решения.
Получается, что основной тренд в России сейчас — не попытаться запихнуть Canva в российскую реальность, а выстроить инфраструктуру вокруг Make и локальных игроков. Это звучит менее романтично, чем «подключили красивый зарубежный сервис и всё летает», но зато не держит бизнес на игле регуляторных рисков.
Я заметила еще одну интересную деталь: когда компаниям предлагаешь идти по пути «Make плюс российский визуальный движок», они сначала вздыхают, а потом, через пару месяцев, уже не хотят возвращаться обратно. Причина простая — настраиваемость. Собственный endpoint позволяет учесть нюансы их бренда, шрифтов, верстки, а не подстраиваться под шаблоны Canva. Да, порог входа выше, нужны разработчики, но зато через полгода-год это превращается в устойчивый конвейер. Иногда я слышу возражение «но фрилансерам так нельзя, им проще Canva», и тут, честно, приходится отвечать: в 2025-2026 годах проще — не всегда значит безопаснее. Особенно если этот фрилансер собирает в одной инфографике сводные данные о выручке, именах менеджеров и городах клиентов.
Как организовать хранилище и логи, чтобы не переживать за проверку
На практике автоматизация редко падает из-за Make или графического движка. Чаще всего узкое место — хранилище и отсутствие следов: кто к чему обращался, какие данные вытягивал, когда удалял. Я склонна смотреть на это как на еще одну часть дизайна процесса, только вместо цветов и шрифтов у нас журналы операций и политика хранения. Для инфографики по маркетингу это особенно актуально: данные обновляются часто, сценарии гоняются по расписанию, и если в какой-то момент Роскомнадзор спросит «а кто имел доступ к этим ПДн», вам нужно будет показать логи, а не вспоминать по ощущениям. Звучит занудно (хотя сама я так делала ровно один раз, когда надеялась на память), но жить с автоматизацией без журналов — это как летать без черного ящика.
Я обычно предлагаю связку: российское облако (Яндекс или VK) как базовое хранилище и логирование событий либо через встроенные средства облака, либо через отдельный DPO-сервис, который умеет регистрировать доступы и действия. Make в этом случае становится источником технических логов: он фиксирует, когда сработал сценарий, какие модули отработали, какие запросы ушли наружу. Эту информацию удобно потом подтягивать в журнал обработки ПДн. Смысл не в том, чтобы завалить себя логами, а в том, чтобы при проверке вы могли наглядно показать путь данных: из CRM в Make, из Make в визуальный сервис, дальше — в хранилище отчетов. Чем понятнее эта цепочка, тем легче и Роскомнадзору, и вашему внутреннему DPO.
Я заметила еще одну вещь: когда начинаешь проект с вопроса «где и как мы будем логировать обработку ПДн», остальные решения автоматически становятся аккуратнее. Клиенты меньше тянут данные через серые плагины, внимательнее относятся к выбору API и даже охотнее читают политики сервисов (нет, правда). Для инфографики это критично, потому что красивые картинки очень легко обманчивы: снаружи всё аккуратно, а внутри — хаос с маршрутами данных. Это означает, что если вы хотите, чтобы ваш автоматизированный конвейер инфографики жил больше одного года и не ломался от первой же регуляторной волны, стоит вложиться в хранилище и логи не меньше, чем в сами сценарии Make.
Здесь хорошо работает короткая фраза, которую однажды сказал мне DPO крупной компании.
Если процесс нельзя объяснить на одном листе А4 и показать по нему логи за год, то это не процесс, а потенциальный инцидент
. С тех пор я всегда представляю себе, как буду рисовать схему обработки данных для того или иного клиента, и встраиваю хранилище и логи в эту картинку с самого начала, а не «когда-нибудь потом».
Как выглядит по шагам создание инфографики через Make с учетом российских реалий
Возвращаясь к практическому вопросу: как автоматизировать создание инфографики, если мы не можем полагаться на Canva API и зарубежное хранилище. Я обычно строю процесс в 5-7 шагов, где классические «парсинг — шаблон — рендер — экспорт — рассылка» дополняются двумя слоями — инвентаризацией ПДн и фиксацией операций. В сухом остатке схема такая: данные аккуратно попадают в Make, там минимально преобразуются, уходят в российский визуальный сервис, возвращаются в виде PNG или PDF и дальше уже доставляются в те же Telegram-чаты или корпоративную почту. Звучит чуть сложнее, чем стандартные 5 шагов, но в российских условиях как раз этот «лишний» блок с проверкой ПДн и логами и спасает от сюрпризов.
Чтобы не потеряться, я разложу это на человеческие шаги. Сначала идет инвентаризация: вы отмечаете в CRM или таблицах, какие поля относятся к ПДн, и настраиваете в Make триггеры только на те данные, которые можно безопасно использовать в инфографике. Затем формируете шаблон — уже не в Canva, а в локальном визуальном сервисе или собственном движке. Дальше настраивается модуль Make, который берет очищенные данные и подставляет их в шаблон, запуская рендер. После рендера файл сохраняется в российском облаке, откуда Make забирает ссылку и отправляет ее в нужный канал: менеджеру, в общий чат, в архив. Параллельно сценарий пишет в журнал: такой-то отчет сформирован по таким-то данным, в такое-то время, таким-то пользователем. На бумаге это выглядит скучно, но по факту именно так и рождается устойчивая автоматизация, которая переживает и обновления законов, и новые требования к локализации.
Мне удобно структурировать этот процесс в виде шагов, особенно когда объясняю его команде клиента.
- Шаг А: ревизия полей и маркировка ПДн в источнике (CRM, БД, таблицы).
- Шаг Б: выбор и настройка шаблонов в российском визуальном сервисе или своем движке.
- Шаг В: конфигурация Make для безопасного вытаскивания и трансформации данных.
- Шаг Г: интеграция с рендером и сохранение файлов в российском облаке.
- Шаг Д: организация журналов и прав доступа к готовой инфографике.
Я заметила, что если в этот момент не полениться и проговорить каждый шаг с командой, дальше сценарии живут с минимальным количеством «пожаров». Это означает, что вы один раз вкладываетесь в архитектуру, а потом несколько лет экономите часы дизайнеров и маркетологов, не оглядываясь на страх «а вдруг придет Роскомнадзор». Помнишь про кофе из начала? Это как раз тот случай, когда он может спокойно остывать на столе, пока сценарий в Make quietly собирает очередной отчет.
Как встроить Make между CRM и визуальным сервисом без лишних рисков
На практике ключевой вызов — аккуратно проложить маршрут от CRM или БД до визуального сервиса, не потащив за собой лишние поля и не устроив утечку. Я обычно начинаю с минимального набора данных: только те показатели, которые нужны для конкретной инфографики, без «на всякий случай». Например, для отчета о продажах по категориям в Make уходит только дата, категория, сумма и, максимум, агрегированные показатели по отделу, но не имена сотрудников. Если клиент очень хочет видеть фамилии менеджеров на графике, мы отдельно обсуждаем юридическую сторону и либо переводим это на внутреннюю систему, где все остается в периметре компании, либо вообще отказываемся от персонализации. Звучит строго, но так спокойнее жить через год, когда меняются трактовки и штрафы.
Я тестировала разные подходы и поняла, что безопаснее всего использовать Make как «тонкий слой», который не хранит у себя ПДн дольше необходимого. То есть данные приходят из CRM, сразу же обезличиваются или агрегируются, отправляются в визуальный сервис, а на стороне Make сохраняются только технические метаданные: какой сценарий отработал, был ли успех или ошибка. Технически это можно реализовать через ограничение логов и очистку временных данных, что немного усложняет настройку, но снижает регуляторный риск. Иногда это кажется избыточным, особенно в маленьких компаниях, но именно у них чаще всего нет отдельного DPO, и автоматизация с «минимумом следов» в Make выглядит разумным компромиссом.
Я заметила еще один момент, который помогает: заранее договориться, какие именно статусы и ошибки будут логироваться и кто за ними следит. Если отчет не сформировался, потому что визуальный сервис недоступен, Make должен об этом сказать не только в своей консоли, но и ответственному в виде уведомления. Это снижает шанс, что в момент проверки вы вдруг обнаружите, что за последние две недели половина инфографики не рендерилась, а кто-то «доделывал руками». Когда такой контроль встроен в процесс, все участники меньше импровизируют, и автоматизация действительно сохраняет часы, а не создает иллюзию экономии.
В какой-то момент я даже поймала себя на мысли, что сценарии Make у клиентов становятся чем-то вроде швейцарского ножа — универсальным инструментом, который одновременно таскает данные, дергает визуальный сервис и пишет логи. Это удобно, но иногда приходится притормаживать и говорить: нет, подожди, есть нюанс, давай не перегружать один инструмент ответственностью, которую лучше разделить между Make, хранилищем и DPO-сервисом. Так конвейер получается устойчивым, а не завязанным на одном «волшебном» сценарии.
Чтобы эту идею зафиксировать, я часто проговариваю с командой одну фразу.
Make должен делать ровно столько, сколько нужно для автоматизации процесса, и не больше: лишние функции в одном месте почти всегда превращаются в лишние риски
. Это простой фильтр, который помогает не превращать оркестратор в монолит и оставлять данные там, где им и положено быть по логике безопасности и 152-ФЗ.
Как живой кейс с Олегом превратился в рабочую автоматизацию вместо штрафа
Возвращаясь к Олегу и его инфографике по маркетингу. На старте у него была типичная для российских компаний смесь: Google Sheets с ПДн, Canva для визуалов, разрозненные Excel-файлы и ручная работа дизайнеров по вечерам. Задача звучала просто: сделать процесс, где данные раз в неделю подхватываются, визуализируются и отправляются в Telegram-чат топ-менеджмента, без участия людей. Когда мы разложили это на шаги под российскую реальность, стало ясно, что половину текущей схемы нужно просто выкинуть. Google Sheets — мимо, Canva API — мимо, хранение на зарубежном облаке — тоже мимо. На бумаге это выглядело драматично, но с другой стороны открыло возможность собирать нормальную архитектуру, а не подпирающуюся костылями.
Я тестировала с его командой пару вариантов и в итоге мы остановились на следующем подходе: CRM и финансовые данные живут в 1C и российском облаке, Make подтягивает оттуда только агрегированные показатели по кампаниям, категории и неделе. Дальше Make дергает внутренний сервис, который их визуализирует на заранее подготовленных шаблонах. Этот сервис крутится в VK Cloud, рендерит PNG под брендинг компании и складывает их в защищенное хранилище. Make после успешного рендера отправляет ссылки на картинки в Telegram-чат руководства и в архивный канал. Весь маршрут данных и местоположение серверов задокументированы, а журналы обо всех сформированных отчетах подтягиваются в общую систему учета обработки ПДн. С точки зрения закона это аккуратная история, с точки зрения команды — наконец-то автоматический отчет по понедельникам, без беготни.
Чтобы было понятнее, какие элементы в этом кейсе сработали лучше всего, я для себя выделила несколько опорных решений.
Критичным оказалось заранее отказаться от идеи персональных рейтингов менеджеров в публичной инфографике и перевести весь персонализированный анализ в закрытую внутреннюю BI-систему.
Второй сильный шаг — перенос всех исходных данных с зарубежных сервисов на российские, даже если сначала это добавило немного хаоса при миграции. Третий — жесткая договоренность, что любые изменения в маршруте данных сначала обсуждаются с ответственным за ПДн, а потом уже летят в прод. Звучит строго, но Олег потом честно признался, что впервые за несколько лет он перестал испытывать нервный тик, когда слышит новость про очередное ужесточение 152-ФЗ. Помнишь, я в начале упоминала усталый кофе? У него теперь отчеты появляются в Telegram еще до того, как кружка успевает остыть, а дизайнеры больше не проводят вечера в Canva.
Что дала автоматизация Олегу в цифрах и где мы чуть не ошиблись
Если совсем по цифрам, то до автоматизации на еженедельные отчеты уходило у команды маркетинга примерно 6-8 часов: сбор данных, проверка, подготовка диаграмм в Canva, верстка под формат презентации. После запуска связки Make плюс внутренний визуальный сервис фактическое участие человека сократилось до 40-60 минут в неделю: проверить, что данные в источниках корректны, просмотреть пару тестовых отчетов и, если вдруг где-то всплыла неконсистентность, поправить исходную формулу. По грубой оценке Олега, это освобождает около 250 часов в год, которые раньше выгорали на рутине. Часть этих часов маркетологи теперь тратят на анализ причин изменений в метриках, а не на рисование стрелочек и рамочек. Получается довольно честный ROI — не фантастические «x10», но вменяемые 3-4x окупаемости инвестиций в автоматизацию за полтора года.
При этом путь был не без ошибок. В какой-то момент команда очень захотела добавить в инфографику мини-карточки по ключевым клиентам, с указанием города и объема заказов. На уровне маркетинга это отлично смотрелось, но когда мы вернулись к схеме обработки ПДн, стало очевидно, что это уже зона персонализированного анализа и требует совсем другого уровня защиты. Я в какой-то момент чуть было не махнула рукой, подумала «ладно, давайте сделаем анонимизацию и все», но потом поймала себя, остановилась и сказала: забудь, что я только что сказала — вот как правильно, давай ограничимся сегментами, а не конкретными клиентами. В результате инфографика осталась полезной, но не пересекла ту тонкую линию, за которой начинается уже не маркетинг, а аналитика по клиентам с отдельными правовыми рисками.
Олег потом признался, что особенно ценит в этой истории даже не сами автоматические отчеты, а то, что теперь у него есть понятная карта, кто за что отвечает. Разработчики — за устойчивость сценариев Make и визуального сервиса, маркетинг — за корректность исходных данных и постановку задач по визуализации, ответственный за ПДн — за актуальность схемы обработки и документов для Роскомнадзора. Это разрезает тот замкнутый круг, когда все молча надеются, что «где-то там в Make всё настроено правильно». Вместо этой веры на слово появляется нормальная управляемая система, в которой можно менять модули, добавлять новые виды инфографики и не бояться, что где-то в углу тихо зреет уголовный протокол.
В завершение этой части мне хочется проговорить одну, казалось бы, очевидную мысль.
Автоматизация ради экономии пары часов в неделю не стоит риска словить штраф и проверку, если при этом игнорируется базовый hygiene по ПДн и архитектуре
. В кейсе с Олегом это осознание пришло довольно рано, поэтому проект пошел по аккуратному пути. Я видела другие истории, где сначала месяцами собирали сложные сценарии с Canva и Google Sheets, а потом в панике все переделывали под российскую реальность. Лучше не так.
Где чаще всего обжигаются при интеграции Make и визуальных сервисов
Когда я смотрю на разные проекты по автоматизации инфографики, вижу одни и те же грабли. Первое — вера в то, что «если есть согласие пользователя, то можно все». В российских реалиях 2025-2026 годов это уже не так: согласие — только один из возможных оснований, и часто более устойчиво работать через договор или законный интерес, особенно когда речь о маркетинге и аналитике. Второе — привычка тянуть в автоматизацию вообще все поля, потому что «вдруг пригодится». В результате сценарий Make оперирует огромным массивом ПДн, которые ему вообще не нужны для построения диаграмм. Третье — отсутствие четкого разграничения зон: где заканчивается рабочий контур с ПДн и начинается безопасная, агрегированная витрина для инфографики. Именно на этих стыках рождаются ситуации, когда кто-то случайно подает в Canva или другой сервис данные, которые по-хорошему должны были остаться внутри периметра.
Я заметила интересную закономерность: самые опасные ошибки выглядят мелкими. Например, добавить в шаблон подпись «Менеджер: Иванов И.» под графиком по сделкам — кажется такой безобидной деталью, а на деле это уже персональные данные сотрудника, причем в связке с его производственными показателями. Или использовать один и тот же сценарий Make для формирования как агрегированных отчетов, так и отчетов по конкретным VIP-клиентам, просто переключая фильтр вручную. В живой жизни кто-нибудь обязательно забудет щелкнуть переключатель, и в общий канал улетит отчет, который вообще-то должен был видеть только коммерческий директор. Это критично, потому что в таких инцидентах тяжело объяснить, почему внутренние процессы не предусматривали технических ограничений и полагались только на «аккуратность» людей.
Чтобы немного структурировать эти грабли, я иногда даже записываю их для себя пунктами — как напоминание, о чем обязательно спросить клиента при аудите процессов.
- Использование одних и тех же сценариев Make для работы с ПДн и агрегированными данными без разграничения.
- Передача избыточных полей (ФИО, контакты) в визуальные сервисы, где они не нужны.
- Отсутствие проверки, где физически расположены сервера каждого из используемых инструментов.
- Вера в то, что согласие пользователя автоматически «покрывает» все последующие действия с данными.
- Отсутствие отдельных шаблонов и маршрутов для внешней и внутренней инфографики.
Я заметила, что если эти истории проговорить с командой еще до начала внедрения, вероятность серьезных промахов падает в разы. Это означает, что часть работы по автоматизации — это вообще не настройка Make и API, а тихий системный разговор о границах: какие данные мы берем, зачем, где они оказываются и кто может это увидеть. Здесь не получится закрыться фразой «мы все в цифре, значит, всё умно», потому что самая болезненная ошибка обычно случается из-за недосказанности и чувства «ну все же поняли, как надо».
Та ситуация с коллегой из питерского агентства, которое заплатило 150 тысяч за Google Sheets с ПДн, для меня стала в свое время хорошим тормозом. Мы с ним потом разбирали процесс и поняли, что технически автоматизация у них была настроена отлично, сценарии работали, отчеты появлялись вовремя. Провал случился в самом начале — они не задали себе вопрос, где живет таблица с исходными данными, и можно ли вообще в России 2025 года строить на ней бизнес-процессы с ПДн. С тех пор я каждый раз, когда слышу «мы тут на Google что-то завели», автоматически спрашиваю: это точно не про ПДн, правда?
Как не утонуть в требованиях и при этом не убить автоматизацию
Иногда после всего вышесказанного у людей возникает ощущение, что автоматизация инфографики в России — это сплошные запреты и страдания. Я очень не хочу, чтобы это так воспринималось. На практике можно жить вполне комфортно: просто вместо «подключим всё ко всему и посмотрим, полетит ли» вы идете от задач и ограничений. Я часто использую подход, в котором сначала формулируем, какие отчеты вообще нужны и кто их будет видеть, затем делим их на внешние и внутренние, и только потом под каждый тип подбираем инструменты. Для внешних — максимально обезличенные данные, локальные сервисы и строгое логирование. Для внутренних — можно позволить себе чуть больше гибкости, но все равно в рамках российского законодательства. При таком подходе Make и похожие решения становятся не источником риска, а инструментом, который точно встроен в понятный контур.
Я поймала себя на мысли, что лучшая метафора для этого процесса — не «волшебная кнопка», а ремонт в квартире. Сначала вы решаете, какие комнаты вообще нужны, потом согласуете план с теми, кто выдает разрешения (в нашем случае — Roskomnadzor и внутренний DPO), а уже после выбираете плитку и краску. Если поменять порядок, можно сделать очень красивый ремонт — но потом внезапно обнаружить, что вы залезли на несущую стену и всё придется переделывать. В автоматизации инфографики роль несущей стены играют ПДн, архитектура хранилища и маршруты данных. Это не самая яркая часть проекта, но без нее любая интеграция Make с визуальными сервисами превращается в временную декорацию.
Иногда мне хочется, конечно, махнуть рукой и сказать: «ладно, давайте просто сделаем, а там разберемся». Но опыт ИТ-рисков и аудита очень мешает так жить 🙂. Поэтому я предпочитаю потратить чуть больше времени в начале, нарисовать схему, согласовать зоны ответственности и только потом запускать сценарии. Это дает странное, но приятное ощущение — будто за спиной есть страховочная сетка, и если что-то пойдет не так, вы хотя бы будете понимать, где искать проблему. Это, наверное, и есть главная ценность аккуратной автоматизации: она возвращает чувство управляемости, а не только экономит часы.
Куда двигаться дальше тем, кто уже автоматизировал первые отчеты
Когда базовый конвейер инфографики через Make, локальные сервисы и российское хранилище заработал, у многих появляется естественный вопрос: а что дальше. Здесь у меня, честно, начинается самая любимая часть — можно добавлять умные элементы: динамические текстовые комментарии на основе метрик, интеграцию с ИИ-агентами для подсказок по данным, более сложные дашборды. Но даже здесь российская специфика не уходит: любые ИИ-сервисы, которые получают доступ к ПДн, должны быть либо локальными, либо работать с уже агрегированными, безопасными данными. То есть, если хочется, чтобы агент сам писал подписи к графикам, он должен видеть только цифры, а не имена клиентов или сотрудников. Это чуть ограничивает фантазию, но зато оставляет нервы и кошелек в целости.
Я заметила, что на этом уровне те, кто когда-то аккуратно подошел к архитектуре, бегут гораздо быстрее. У них уже есть разделенные витрины данных: одна — чистая, агрегированная, для инфографики и аналитики, другая — с ПДн, для операционки. Добавить ИИ-агента, который читает только чистую витрину и пишет краткие выводы к отчету, для них — дело пары недель, а не перепроектирования всей системы. Те же, кто пошел «по-быстрому», потом вынуждены вытаскивать ПДн изо всех углов, чистить сценарии Make, прятать их из визуального контура и переживать каждое новое письмо от регулятора. Это немного грустная, но честная развилка: либо сначала медленно и аккуратно, либо потом быстро, но с огнетушителем в руках.
Получается, что следующий логичный шаг после базовой автоматизации инфографики — это выстраивание вокруг нее небольшого «интеллектуального пояса». Можно, например, настроить сценарий, который по итогам недели не только формирует картинки, но и коротко описывает тренды: где выросли продажи, какие кампании провалились, где стоит проверить креативы. Можно подключить уведомления в Telegram, которые срабатывают, если какой-то показатель резко вышел за границы нормы. Можно, наконец, автоматически собирать отчеты для разных уровней управления — от операционного до стратегического, с разной глубиной детализации. И всё это по-прежнему укладывается в российскую реальность, если соблюдается базовое правило: ПДн живут в своем аккуратном периметре, а в мир выходят только безопасные цифры.
И здесь я возвращаюсь к Олегу в последний раз. Через полгода после запуска базовой автоматизации мы с ним снова созванивались, и он рассказывал, что теперь часть аналитики у них дополняется короткими текстовыми выводами, которые формирует ИИ по агрегированным данным. Он уже почти не вспоминал, с чего всё начиналось, как мы резали привычные им Google Sheets и Canva. В итоге клиент сэкономил примерно 250-300 часов команды в год и еще получил более осмысленные решения по маркетингу, потому что люди перестали тратить силы на сбор и оформление и начали тратить их на понимание. Возвращаясь к тому, с чего я начала… ради этого я вообще занимаюсь автоматизацией: чтобы контент рождался сам, а у людей появлялось время на то, что действительно требует человеческой головы, а не бесконечных кликов.
Как продолжить разбираться и не закапываться в одиночку
Если после всего этого текста у тебя появилось легкое желание сесть с бумагой и нарисовать свой маршрут данных для инфографики — это хороший знак. Значит, автоматизация у тебя будет не хаотичной, а осмысленной. Я заметила, что лучше всего такие вещи усваиваются, когда видишь не только чужие кейсы, но и живые разборы своих процессов. Я регулярно делюсь такими разборами, наблюдениями и свежими изменениями по 152-ФЗ и автоматизации у себя в Telegram-канале MAREN — в формате «нормального человеческого разговора», а не сухого чек-листа. Если хочется держать руку на пульсе и потихоньку докручивать свои процессы, можно присоединиться и время от времени сверять свои решения с тем, что происходит на рынке.
Для тех, кто уже созрел не просто читать, а что-то менять, я держу в актуальном состоянии описание подходов и форматов работы с автоматизацией и AI-губернансом на сайте Maren. Там можно посмотреть, чем я реально занимаюсь в проектах, какие архитектуры использую, как совмещаю Make, n8n, локальные хранилища и требования 152-ФЗ. Я очень за то, чтобы люди не просто знали, «что так можно», а понимали, как это сделать в своих конкретных условиях — с их CRM, их ПДн, их рисками. Поэтому, если созреешь к более предметному разговору, ты уже будешь знать, куда заглянуть.
Что ещё важно знать
Вопрос: Можно ли использовать Canva API для инфографики, если в данных нет ФИО и телефонов?
Ответ: Формально риск ниже, если нет явных ПДн, но в России все равно нужно смотреть, можно ли по этим данным идентифицировать человека. Если это чистые агрегированные метрики без привязки к личности, вероятности претензий меньше, но я бы всё равно держала такой процесс отдельно от потоков с ПДн и внимательно фиксировала, какие данные уходят за рубеж. При малейшем сомнении проще перейти на локальные сервисы, чтобы не держать этот «хвост».
Вопрос: Как фрилансеру понять, нужно ли ему уведомлять Роскомнадзор из-за автоматизации инфографики?
Ответ: Если ты обрабатываешь ПДн клиентов или сотрудников через цифровые инструменты, формально ты уже оператор и обязан уведомить Роскомнадзор до начала такой обработки. Исключения узкие и обычно не покрывают коммерческие проекты для бизнеса. Поэтому если твоя инфографика строится по реальным клиентским данным, а не по вымышленным учебным примерам, лучше сразу закладывать уведомление в план.
Вопрос: Можно ли строить автоматизацию на Make, если часть исходных данных хранится в Google Sheets?
Ответ: Для данных без ПДн это допустимо, но для любых персональных данных россиян хранение в зарубежных сервисах создает риск нарушения требований локализации. В таких случаях я рекомендую мигрировать критичные таблицы в российские облака или локальные базы, а Google Sheets оставить только для несекретных вещей. Тогда Make будет забирать нужное уже из безопасного источника.
Вопрос: Что делать, если клиент настаивает на персональных рейтингах в инфографике?
Ответ: В такой ситуации стоит честно проговорить юридические и этические последствия, а также предложить компромисс — например, агрегированные данные по отделам вместо имен. Если клиент настаивает, то персональные рейтинги лучше делать во внутренней системе, не вынося их в публичные отчеты и не прогоняя через внешние сервисы. В крайнем случае имеет смысл письменно зафиксировать позицию и границы ответственности.
Вопрос: Насколько безопасно использовать ИИ-агентов для анализа данных из инфографики?
Ответ: Безопасность здесь зависит от того, какие данные получает агент и где он крутится. Если агент работает в российском контуре и видит только агрегированные показатели, риски минимальны. Если же он обрабатывает ПДн и крутится на зарубежных сервисах, это уже проблема с точки зрения 152-ФЗ и трансграничной передачи, и от такой схемы лучше отказаться или сильно переосмыслить архитектуру.
Вопрос: Имеет ли смысл автоматизировать инфографику, если отчетов всего несколько в месяц?
Ответ: Если отчетов мало и в них почти нет ПДн, то иногда быстрее и дешевле делать их вручную, особенно в маленьких компаниях. Автоматизацию я бы рассматривала, когда повторяющихся отчетов много, данных несколько источников и есть перспектива роста нагрузки. Тогда один хорошо продуманный сценарий Make окупает вложения за счет сохраненного времени и меньшего числа ошибок.
Метки: ai-agents, makecom, n8n, автоматизация, автопостинг, контент-план