Персональные данные в коворкингах — это не теория из презентаций Роскомнадзора, а вполне себе живая материя: паспорта на ресепшене, камеры в коридорах, оплаты по картам, CRM для резидентов и ещё три таблицы в Google Sheets (которые с 2025 года уже не ок для России). Для российских специалистов, которые автоматизируют процессы, запускают ИИ-агентов и обвязывают всё это через n8n или Make, история с 152-ФЗ в 2025 году стала особенно острой: закон о персональных данных ужесточили, федеральный Роскомнадзор подключил автоматический мониторинг, и теперь ошибка в виджете или согласии легко превращается в штраф. В этой статье я разбираю, как в коворкинге выстроить обработку персональных данных так, чтобы и 152-ФЗ был доволен, и автоматизация не ломалась, и люди не тратили по часу на ручную проверку согласий. Материал подойдёт владельцам и менеджерам коворкингов, разработчикам внутренних систем, специалистам по автоматизации и тем, кто отвечает за ИБ и хочет сделать так, чтобы защита персональных данных не превращалась в бесконечный хаос папок и устных договорённостей.
Время чтения: примерно 15 минут
Зачем коворкингам думать о персональных данных уже сейчас
Я заметила, что к персональным данным в коворкингах часто относятся по принципу «у нас же не больница и не банк, кто вообще до нас дойдёт». Типичная сцена: утро, ресепшен, администратор наливает себе кофе, рядом лежит толстая папка с договорами и копиями паспортов, а на мониторе торчит открытая таблица с телефонами резидентов и их ИНН, в которой одновременно ковыряются ещё два человека с ноутбуками в общем зале. На камерах, кстати, тоже всё весело: система видеонаблюдения пишет и хранит всё в облаке зарубежного провайдера, о локализации по 152-ФЗ никто не вспоминал уже года два, а согласие на обработку персональных данных у гостей либо вообще не берут, либо прячут в многостраничном договоре мелким шрифтом. Это означает, что коворкинг живёт до первой проверки или жалобы, а потом внезапно оказывается, что закон о персональных данных — это не про кого-то там, а про конкретную стойку ресепшена и конкретные таблицы в Google.
Когда я первый раз столкнулась с аудитом коворкинга, меня поразила не бессистемность (с этим я давно смирилась), а странный диссонанс между хайповыми словами про «умные пространства», «AI для аналитики загрузки» и тем, как реально устроена работа с данными. С одной стороны, ребята ставят ИИ-агентов, которые анализируют загрузку переговорок, предсказывают пиковые часы и пишут в Telegram-бота, кого предупредить. С другой — согласие на обработку персональных данных собирается в бумажной анкете, которую потом сканируют и складывают в папку «сканы клиенты новые новая финальная точно». В России после майских изменений 2025 года такой подход уже не работает: отдельное согласие, локализация, уведомление Роскомнадзора, защита информации и персональных данных — всё это перестало быть опцией «сделаем как-нибудь потом», и превратилось в довольно конкретные требования с понятными штрафами.
На практике коворкинг — идеальное поле для автоматизации работы с данными: поток клиентов, повторяющиеся операции, понятные точки входа (сайт, Telegram-бот, стойка ресепшена, турникет, CRM), плюс интерес к ИИ и привычка к цифровым сервисам. Вопрос не в том, нужен ли фз о персональных данных коворкингу (спойлер — нужен), а в том, как встроить все требования в уже существующую экосистему: бронь через форму, чат-бот, онлайн-оплаты, видеонаблюдение, доступ по картам, рассылки по базе резидентов. И да, всё это можно сделать так, чтобы процессы стали прозрачнее, а не тяжелее, а люди в итоге перестали держать в голове «кому мы давали доступ к камерам» и «где лежит образец персональных данных для анкеты резидента».
Коворкинг, который работает с персональными данными «по-честному», обычно выигрывает не только в снижении рисков, но и в управляемости процессов: любой шаг с данными становится предсказуемым и автоматизируемым.
С какими данными коворкинг реально работает каждый день
Если разложить типичный коворкинг по слоям, окажется, что обработка персональных данных там происходит в каждом втором действии, просто об этом редко думают вслух. Человек заходит на сайт, оставляет имя, телефон и почту в форме «забронировать рабочее место» — это уже персональные данные, и уже обработка. Гость приходит офлайн, заполняет бумажную карточку, оставляет паспортные данные и ставит подпись под согласием — снова обработка. Камеры пишут его лицо при входе, система контроля доступа связывает фото с пропуском и хэшом карты — да, это тоже персональные данные, и по закону о защите персональных данных РФ это попадает под те же правила, что и классическая анкета сотрудника. Получается, что коворкинг крутится на данных, как на электричестве, просто счётчик до недавнего времени мало кто смотрел.
Я поняла, что удобнее всего смотреть на коворкинг через «карты потоков» данных: откуда к нам что прилетает, куда мы это складываем, кто имеет доступ и когда удаляем. Онлайн-каналы обычно включают сайт (формы заявки, чат на сайте), мессенджеры (Telegram-боты для бронирования), маркетинговые инструменты (Яндекс Метрика, рекламные пиксели), а ещё сторонние виджеты, которые внезапно уезжают в зарубежные облака и ломают требования к локализации. Офлайн-каналы — это ресепшен, договоры, журналы посетителей, иногда даже синие тетрадки со столбиками «ФИО, время, кабинет». Плюс отдельная головная боль — видеонаблюдение и контроль доступа, которые часто закупаются «как есть», без проверки, где физически живут данные и кто у них оператор по 152-ФЗ.
Здесь работает простое наблюдение: как только начинаешь честно выписывать, какие персональные данные это вообще, список вырастает быстрее, чем кофе успевает остыть. ФИО, паспортные данные, телефоны, имейлы, ИНН и реквизиты по договорам, записи звонков менеджеров, чаты с поддержкой, лица и силуэты на видео, данные об оплатах, истории посещений, логика доступа по картам и пин-кодам, технические логи. Плюс микс из служебной информации: кто кому открыл турникет, кто смотрел камеры, кто экспортировал таблицу резидентов. Если к этому добавить ещё модные инструменты аналитики и AI-отчёты, получается, что работа с базами данных, работа с таблицей данных и вообще тема «работа с данными вопросы» для коворкинга далеко не академическая.
Когда я разбираю коворкинг как систему работы с данными, мне нравится подсвечивать один парадокс: бизнес часто вкладывается в красивую CRM, современные облака и умные отчёты, но забывает элементарно настроить права доступа. Администраторы видят полные паспортные данные, архив видеозаписей и финансовые отчёты, хотя по логике им достаточно ФИО, статуса оплаты и контакта на сегодня. Техперсонал может случайно получить доступ к журналу событий в системе контроля доступа, где видны перемещения резидентов. В итоге безопасность защиты персональных данных страдает не потому, что кто-то «хакнул коворкинг», а от банального избыточного доступа и отсутствия нормальной ролевой модели. Это критично, потому что в реальности первые утечки и скриншоты сливаются не из-за внешних атак, а из внутренних «ой, а я не знал, что так нельзя».
На практике базовый разбор потоков данных уже даёт коворкингу несколько быстрых выводов: какие таблицы нужно перенести с зарубежных сервисов в российские, где пора выдать сотрудникам отдельные учётные записи, а не один общий логин «админ», и где информация о защите персональных данных нужна не только на сайте, но и офлайн — в виде понятных уведомлений и понятного для человека согласия. После этого становится проще говорить и про нейросети: если ты понимаешь, какие категории данных у тебя ходят по проводам, ты уже не отправишь в ИИ-агента полный экспорт с паспортами и договорами только ради красивого отчёта.
Когда коворкинг честно описывает свои потоки данных, он неожиданно для себя получает карту, по которой можно наводить порядок, строить автоматизацию и снижать юридические риски без ощущения, что закон о персональных данных 2025 — это чья-то странная прихоть.
Что изменилось в 152-ФЗ в 2025 году для коворкингов
Я заметила, что многие до сих пор живут в версии «152-ФЗ — это что-то старое, уже как-нибудь всё устаканилось», и очень удивляются, когда слышат про майские изменения 2025 года. В реальности персональные данные 2025 — это уже более жёсткие правила игры, особенно для тех, кто работает с клиентами через сайты, формы и виджеты, а коворкинги как раз в этой категории. С конца мая закон прямо говорит: согласие на обработку персональных данных — отдельный документ, который нельзя прятать внутрь пользовательского соглашения или «галочки обо всём и сразу». Для коворкинга это значит, что старые формы «я согласен со всеми условиями» больше не работают, нужно отдельно показать человеку, какие данные, с какими целями, на каких основаниях и в течение какого срока вы будете обрабатывать.
Кроме отдельного согласия, в 2025 году усилился контроль за сайтами. Роскомнадзор персональные данные теперь мониторит не только по старой схеме жалоба — проверка, но и автоматизированно: скрипты, виджеты обратной связи, формы, которые отправляют данные за рубеж или используют запрещённые технологии трекинга, стали объектом отдельного интереса. Для коворкинга это значит, что миграция с «международных» конструкторов сайтов и облаков на российские сервисы перестала быть темой на потом, а превратилась в задачу на год максимум. Плюс поднялась планка по ответственности: штрафы для ИП и юридических лиц за нарушение фз о защите персональных данных выросли, а в случае утечек и игнорирования требований риски легко уходят в сотни тысяч рублей.
Я понимаю, что в момент, когда ты пишешь интеграцию через n8n, тебе меньше всего хочется читать сухие поправки в 152-ФЗ. Поэтому на практике я предлагаю коворкингам смотреть на закон как на чек-лист к архитектуре: есть ли уведомление Роскомнадзора об обработке персональных данных, описаны ли цели, где локализованы базы, как оформлено согласие, организована ли защита информации и персональных данных, прописаны ли роли и доступы. Важный акцент 2025 года — локализация: данные граждан РФ должны храниться в России, а это значит, что использование зарубежных облаков без зеркала в РФ под хранение ПДн становится плохой идеей не в теории, а прямо в ежедневной жизни коворкинга. Нельзя просто «сделать вид», что Excel в международном облаке — это не база персональных данных, закон это так не видит.
Когда я обсуждаю с собственниками коворкингов изменения в 152-ФЗ, обычно всплывает ещё один вопрос: «ну а если мы маленькие, до нас же никто не докопается». К сожалению, автоматический мониторинг и цифровые следы сделали размер бизнеса почти нерелевантным: если у вас есть сайт, собирающий данные, есть камеры и журналы, у вас уже есть фокус внимания регулятора. Это не повод паниковать, скорее приглашение подтянуть базу: привести в порядок документы, актуализировать формы согласий, убедиться, что информационная защита персональных данных не заканчивается паролем на wi-fi. Дальше поверх этого можно уже надёжно строить автоматизацию работы с данными, запускать ИИ-помощников и не бояться, что один неаккуратный скрипт собьёт весь домик.
Изменения 2025 года не убили коворкинги, но сделали видимыми те дыры, которые раньше прятались между «потом поправим» и «да кто это читает».
Как собрать работающий комплект документов без боли
Когда я первый раз прихожу в коворкинг и спрашиваю про документы по персональным данным, обычно из шкафа выезжает папка с распечатанным «образец персональных данных политика компании», скачанный лет пять назад из интернета. Там аккуратно прописано всё обо всём, от биометрии до госслужбы, только к реальному процессу работы с клиентами и резидентами это имеет слабое отношение. В 2025 году такой подход уже не спасает: фз о персональных данных требует соответствия фактической обработки тому, что написано в политике, а клиенты стали чаще задавать вопросы и про согласие персональных данных, и про то, что будет с их паспортом после визита. Это означает, что коворкингу нужен не красивый шаблон, а живой комплект документов, который описывает реальные процессы — и который, кстати, очень удобно потом использовать как каркас для автоматизации.
На практике я начинаю с трёх слоёв. Первый — публичный: политика обработки и защиты персональных данных на сайте, понятный текст о том, что за данные собираем, зачем, кому передаём, как долго храним, как можно отозвать согласие. Второй — операционный: формы согласий (отдельные, а не спрятанные в договор), уведомления для видеонаблюдения, шаблоны уведомлений о правах субъекта данных, реестр обрабатываемых персональных данных с целями и сроками. Третий — внутренний: приказ о назначении ответственного, инструкции для сотрудников, порядок доступа к системам, журнал инцидентов. Чем больше в этих документах завязки на реальную жизнь коворкинга (конкретные CRM, почтовые ящики, облака, бот в Telegram), тем проще потом построить рабочую защиту персональных данных РФ, а не только «бумажную».
Вот как это выглядит на практике в виде структурированных шагов, которыми удобно руководствоваться при настройке документации.
- Описать все точки сбора данных: сайт, боты, ресепшен, видеокамеры, системы доступа, платежи.
- Сопоставить каждой точке цель обработки, состав данных и срок хранения, записать это в реестр.
- Собрать и адаптировать тексты политик, согласий и уведомлений так, чтобы они совпадали с реестром, а не жили отдельной жизнью.
- Назначить ответственного за работу с персональными данными и прописать для него (и для команды) понятные инструкции.
- Проверить, какие сервисы используются, и зафиксировать их в документах как операторов или соисполнителей.
Звучит довольно бюрократично, но именно этот «скучный» слой потом позволяет безболезненно выстраивать работу с данными в автоматизированных сценариях: когда делаешь роботизацию через n8n, ты уже знаешь, какие поля трогать можно, какие нет, какие нужно псевдонимизировать или шифровать, где требуется журналирование действий. Пара приятных эффектов для коворкинга: сотрудники перестают спорить о том, что «можно ли администратору видеть паспортные данные», потому что это чётко отражено в регламентах, а клиенты получают возможность нормально реализовать свои права — запросить копию данных, отозвать согласие, уточнить срок хранения. И да, в России к таким запросам уже пора относиться как к реальности, а не как к «капризу одного-двух особо подозрительных гостей».
Когда документы собраны, я всегда прошу коворкинг пройтись по ним глазами человека, который не знает термин «152-ФЗ». Понятно ли, какие данные берут, куда их несут, кто за это отвечает. Нужны ли в форме согласия три абзаца юридических конструкций, или можно в человеческой форме объяснить, что камеры пишут видео только для безопасности, что записи хранятся, например, 30 дней, что к ним есть ограниченный доступ и что любой запрос будет обработан в конкретный срок. Такой «обратный перевод» с юридического на человеческий делает коворкинг более дружелюбным и снижает количество вопросов на ресепшене, а юристы при этом не страдают, если смысл не искажается.
Живые документы по персональным данным — это не набор файлов ради Роскомнадзора, а карта процессов коворкинга, по которой удобно строить автоматизацию и обучать команду.
Как автоматизировать обработку и защиту персональных данных в коворкинге
В какой-то момент любой коворкинг, который уже обжёгся на ручном введении анкеты в Excel, приходит к одинаковому вопросу: как сделать так, чтобы работа с данными не превращалась в вечное «скинь мне последнюю версию файла» и поиск согласий по почте. Здесь на сцену выходят ваши любимые инструменты — n8n, Make, кастомные боты, ИИ-агенты, которые могут взять на себя рутину, если правильно задать им рамки по 152-ФЗ. Я люблю начинать с простого: одна воронка данных — от первого касания до удаления — и сценарий, который сопровождает человека на каждом шаге, не забывая про согласие, права субъекта и безопасность информации.
Пример коворкинга, с которым мы работали, выглядел так: человек оставляет заявку на сайте, данные уходят в CRM, параллельно через автоматизацию формируется карточка в системе контроля доступа, включается напоминание на ресепшен, а если клиент подписывает договор — запускается сценарий создания профиля в биллинге и Telegram-боте. Весь этот зоопарк раньше жил на «если что — напомни мне в чате», и каждая смена администраторов добавляла новые ошибки и «забытые» согласия. После настройки автоматизации через n8n большинство действий стало детерминированным: нет согласия на обработку персональных данных — нет создания карточки, нет чекбокса про видеонаблюдение — не включаем флаг для хранения изображения, истёк срок хранения — сценарий ставит задачу на удаление или делает его автоматически, если так решено в регламенте.
Чтобы не утонуть в теории, я обычно делю автоматизацию обработки и защиты персональных данных на несколько блоков, каждый из которых можно постепенно наращивать.
- Шаг «сбор и согласие»: формы, боты и ресепшен отправляют данные в единую точку, а сценарий проверяет наличие явного и корректного согласия.
- Шаг «хранение и доступ»: данные распределяются по системам (CRM, контроль доступа, биллинг) с автоматическим назначением ролей и прав для сотрудников.
- Шаг «жизненный цикл»: автоматические задачи на актуализацию, ограничение доступа, удаление или обезличивание по истечении сроков.
- Шаг «реакция на запросы»: обработка запросов субъекта (выдать копию, удалить, скорректировать данные) через единый канал, например, через форму или бот.
- Шаг «аудит и контроль»: журналирование действий с данными, отслеживание аномалий доступа и сигналов о возможных инцидентах.
Здесь работает простое правило: чем чётче прописан процесс в документах, тем легче его положить на рельсы автоматизации. Если в политике и реестре данных уже прописано, что, скажем, данные о гостях коворкинга хранятся 3 месяца, то сценарий в n8n может раз в неделю пробегать по базе, находить тех, у кого срок истёк, и либо помечать записи к удалению, либо вызывать API нужной системы. Нейросети в этой архитектуре играют роль умных помощников: они могут, например, автоматически классифицировать обращения клиентов (это запрос на удаление, уточнение, жалоба), помогать формировать ответы на типовые запросы субъектов данных, подсказывать аномальные шаблоны доступа. Но решение «трогать или нет базу» всё равно принимает человек или проверенный бизнес-правилом сценарий.
Меня часто спрашивают, можно ли сделать так, чтобы «контент делался сам», а всё, что касается обработки и защиты персональных данных, просто не мешало жить. В коворкинге это реально, если с самого начала строить сценарии так, чтобы они не только облегчали работу, но и соблюдали закон о защите персональных данных. Пример: Telegram-бот может не только бронировать переговорки, но и автоматически показывать ссылку на политику обработки данных, фиксировать согласие, а потом, через API, передавать данные только в те системы, которые включены в реестр операторов. ИИ-агент может подсказывать администратору, что у этого резидента истёк срок хранения каких-то данных, или что запрос на удаление нужно закрыть до конкретной даты. Автоматизация в коворкинге становится взрослой, когда она учитывает персональные данные не как помеху, а как основу доверия и предсказуемости процессов.
Какие подводные камни чаще всего всплывают и как их обойти
Когда начинаешь копаться в реальных коворкингах, а не в идеальной картинке, быстро обнаруживаешь одни и те же «грабли». Первая — это попытка обойтись без отдельного согласия на обработку персональных данных, спрятав всё в общий договор или «политику конфиденциальности» на сайте, о которой никто не вспоминает на ресепшене. С 2025 года такая конструкция уже плохо дружит с законом: согласие должно быть отдельным, осознанным, конкретным, и лучше, если его легко отозвать тем же способом, которым вы его получили. Вторая грабля — использование зарубежных облаков и сервисов для хранения таблиц с клиентами, логов, видеозаписей, хотя закон о персональных данных в России требует локализации ПДн граждан РФ. Это часто не злой умысел, а инерция: «мы так работали, когда открывались, руки не дошли поменять».
Третья история — недооценка внутренних угроз. Я видела коворкинг, где у администраторов был общий логин к системе видеонаблюдения, который не менялся годами, а паролем служило название пространства. В другой локации уборщица имела физический доступ к компьютеру ресепшена, где постоянно была открыта CRM с полными паспортными данными резидентов и историей платежей. Формально на стене висело уведомление про защиту персональных данных РФ, но по факту система защиты персональных данных отсутствовала: не было разграничения прав, не было журналов доступа, не было даже элементарной блокировки экрана по таймеру. На бумаге — обработка и защита персональных данных, в реальности — картинка, которая может дорого обойтись при первой же проверке или конфликте.
Чтобы не наступать на эти грабли, я прошу коворкинг ответить себе на несколько честных вопросов и на основе этого перестроить архитектуру процессов.
- Есть ли отдельное согласие на обработку персональных данных для каждой ключевой операции (регистрация, видеонаблюдение, рассылки), и понимают ли это администраторы.
- Хранятся ли данные граждан РФ в сертифицированных российских облаках или локальных серверах, или всё ещё в условном «международном диске».
- Разграничен ли доступ: кто реально видит паспорт, кто видит только ФИО, кто имеет право выгружать базу целиком.
- Определён ли срок хранения для каждой категории данных и реализован ли механизм удаления или архивирования.
- Ведётся ли журнал действий с базой: кто что экспортировал, кто менял настройки, кто просматривал камеры.
- Знают ли сотрудники, как действовать при запросе на удаление или при утечке данных, или все надеются на «ну как-нибудь разрулим».
Здесь работает простой принцип: чем меньше в системе «общих» доступов и незадокументированных исключений, тем ниже риски и выше управляемость. Если администратор уходит в отпуск, его личный аккаунт просто деактивируется, а не передаётся сменщику «на время». Если нужно временно дать доступ к видеонаблюдению подрядчику, это оформляется как ограниченный по времени доступ с логированием действий, а не «логин один для всех». Нейросети и автоматизация отлично помогают методично проходиться по этим вопросам: сканировать системы на наличие общих учёток, отслеживать подозрительные выгрузки, напоминать про истечение сроков хранения. Но прежде чем подключать ИИ, нужно честно развести провода: какие действия с данными допустимы, какие должны быть подтверждены человеком, где включается дополнительная проверка.
Я поняла, что самый болезненный для коворкингов момент — это признать, что работа с данными это не только про таблички, но и про отношения внутри команды. Если в культуре принято «скинуть базу резидентов партнёру для рассылки», потому что «мы же доверяем», никакая система защиты персональных данных не выдержит. Придётся договариваться, что доверие и ответственность — не противоположности, а две части одной системы: мы доверяем, но при этом фиксируем, кто что делает, с какими данными, и не выносим персональные данные за пределы тех операторов, которые описаны в документах. Реальная защита начинается там, где коверкинг перестаёт закрывать глаза на «мелочи», вроде общего пароля или свободного доступа к журналам, и начинает относиться к данным как к активу, а не как к побочному продукту договоров.
К чему в итоге приходит коворкинг, который всё это внедрил
Когда все эти истории с законом, локализацией и внутренними доступами только начинаются, любому владельцу коворкинга хочется сказать: «можно я лучше ещё одну переговорку открою, чем буду разбираться с 152-ФЗ». Но спустя несколько месяцев после внедрения системы обработки и защиты персональных данных картина обычно меняется. Процессы становятся предсказуемыми: понятно, откуда к нам приходят данные, где они живут, кто может их посмотреть, когда они исчезают. Администраторы перестают судорожно искать бумажное согласие в стопке договоров, потому что оно живёт в понятном электронном виде, а сценарии автоматизации подсказывают, что без согласия опять-таки ничего не произойдёт. Команда начинает воспринимать персональные данные как структурированный ресурс, а не как случайную смесь «того, что где-то лежит».
На этом фоне появляются приятные побочные эффекты. Во-первых, коворкинг может честно отвечать клиентам на вопросы типа «какие мои персональные данные вы храните» или «как я могу отозвать согласие», не впадая в ступор. Во-вторых, легче внедрять новые цифровые сервисы: когда есть карта потоков данных и реестр операторов, подключение нового российского облака или CRM превращается не в головоломку, а в понятный проект. В-третьих, снижается уровень внутренней тревоги у собственника: даже если Роскомнадзор придёт с вопросами, у вас не хаос, а система, и ИИ-агенты в этой системе не выглядят чем-то подозрительным, а работают на уже выстроенных рельсах.
Мне нравится смотреть на коворкинг как на живой организм, у которого есть нервная система (данные), иммунитет (защита персональных данных), мозг (аналитика и ИИ), и привычки (регламенты и культура). Если один элемент выпадает, остальные начинают компенсировать, и это обычно дорого. Когда работа с данными и 152-ФЗ встроена в общую архитектуру, иммунитет наконец-то начинает работать по назначению: отлавливать необычные действия, защищать от лишнего любопытства, помогать переживать стрессы проверок и изменений закона. Автоматизация и нейросети при таком подходе уже не выглядят как риск, а становятся усилением — они не придумывают новые процессы, а ускоряют те, что вы заранее продумали и описали.
Если тебе хочется разобрать свои потоки данных глубже и посмотреть, как можно накрыть коворкинг системой, в которой и закон о персональных данных соблюдён, и люди не застревают в таблицах, можно заглянуть на мой сайт о системной работе с данными и автоматизацией, там я показываю, что работа с данными — это не обязательно боль и хаос. А если интересен более живой формат с разборами, кейсами и небольшими заданиями по автоматизации, я часто делюсь этим в telegram-канале MAREN про AI и процессы, где мы вместе учимся возвращать себе время, не теряя контроль над тем, что происходит с данными.
Коворкинг, который осознанно относится к персональным данным, в итоге получает не просто «галочку по 152-ФЗ», а управляемую экосистему, где нейросети, автоматизация и люди работают на одних и тех же, прозрачных правилах игры.
Как продолжить наводить порядок в данных и не застрять в теории
Я заметила, что самый сложный момент в теме персональных данных и автоматизации — это переключиться из режима «я примерно понял» в режим «у меня начинает появляться своя система». В коворкингах это особенно заметно: можно бесконечно обсуждать закон о персональных данных, смотреть чужие политики и слушать страшилки про штрафы, но пока не разложишь свои процессы, своя защита персональных данных так и остаётся абстракцией. Если ты дочитал(а) до этого места, значит, тема тебе действительно близка, а значит, можно аккуратно сдвинуться в практику: выбрать один поток данных (например, регистрацию гостей или работу с видеонаблюдением) и попробовать описать его с точки зрения 152-ФЗ и возможной автоматизации.
Для тех, кто готов перейти от теории к своим картам данных и сценариям, я стараюсь делать пространство, где можно спокойно задавать «глупые» вопросы, смотреть живые разборы и не чувствовать себя единственным человеком в России, который одновременно читает фз о защите персональных данных и настраивает n8n. На сайте про системную работу с данными и AI я собираю структурированные материалы и форматы работы, а в telegram-канале MAREN мы чаще говорим вживую про кейсы, авторских ИИ-агентов и то, как сделать так, чтобы контент и процессы «делались сами», но не превращались при этом в зону риска. Я не обещаю магии или мгновенных решений, но знаю по опыту: как только ты один раз через руки проведёшь свой процесс обработки персональных данных, автоматизация начнёт складываться гораздо спокойнее и быстрее.
Если сейчас взять один реальный процесс коворкинга и честно посмотреть на него глазами 152-ФЗ и архитектора автоматизации, следующая неделя уже пройдёт с другим уровнем контроля и ясности.
Что ещё важно знать про персональные данные в коворкингах
Нужно ли получать согласие на обработку персональных данных, если гость заходит всего на час
Да, если вы берёте у него какие-либо данные, даже минимальные (ФИО, телефон, номер документа), это уже обработка персональных данных по 152-ФЗ. Согласие можно оформить в упрощённом виде, в электронной форме или на бумаге, но оно должно быть отдельным, понятным и привязанным к конкретным целям. Для гостевых визитов удобно использовать короткую форму с указанием срока хранения и ссылки на полную политику обработки.
Можно ли хранить базу резидентов коворкинга в зарубежном облаке или Google-таблицах
В 2025 году это рискованно, потому что закон о защите персональных данных и требования к локализации обязывают хранить данные граждан РФ на серверах в России. Использование зарубежных облаков допустимо только при соблюдении условий локализации и договорных отношений с операторами, что в массовых сервисах обычно не выполняется. Без безопасной архитектуры и юридической базы такая база может привести к претензиям Роскомнадзора и штрафам.
Обязательно ли уведомлять Роскомнадзор о начале обработки персональных данных в коворкинге
В большинстве случаев да, коворкинг как оператор персональных данных обязан подать уведомление до начала обработки. Исключения есть, но они редко применимы к пространствам, где ведутся договоры, видеонаблюдение и учёт посещений. Проще один раз корректно оформить уведомление и поддерживать его в актуальном состоянии, чем потом объяснять отсутствие регистрации при проверке.
Что делать, если клиент потребовал удалить все его персональные данные
Нужно проверить, нет ли у вас законных оснований продолжать хранение части данных, например, по бухгалтерским или налоговым требованиям. Всё, что не обязано храниться по закону и обрабатывается только на основании согласия, подлежит удалению или обезличиванию в разумный срок, который лучше зафиксировать в политике. При этом клиенту стоит ответить, какие данные вы удалили, какие сохраняете и на каком основании.
Как быть с видеонаблюдением в коворкинге с точки зрения персональных данных
Видеозаписи с возможностью идентификации человека относятся к персональным данным и подпадают под 152-ФЗ. Нужно разместить понятные уведомления о видеонаблюдении, описать этот процесс в политике обработки, определить срок хранения и круг лиц с доступом. Систему хранения лучше разместить в российском дата-центре или на локальном сервере и ограничить доступ по индивидуальным учётным записям.
Можно ли использовать нейросети для анализа данных о резидентах и посетителях
Можно, но с аккуратной архитектурой: персональные данные лучше передавать в обезличенном виде или в рамках контролируемой инфраструктуры, где выполняются требования 152-ФЗ и локализации. Внешним ИИ-сервисам не стоит отдавать прямые идентификаторы, паспортные данные или полные выгрузки CRM. Безопаснее использовать нейросети для аналитики агрегированных показателей и текстов, а не для необработанных массивов персональной информации.
Кто в коворкинге должен отвечать за обработку и защиту персональных данных
Формально оператором является сама организация или ИП, владелец коворкинга, но внутри нужно назначить ответственного сотрудника приказом. Этот человек координирует работу с документами, обучением персонала, выбором сервисов и взаимодействием с регулятором при необходимости. При этом ответственность не снимается с руководителя, поэтому лучше строить систему, а не перекладывать всё на одного «назначенного крайним».
Метки: ai-agents, rag, персональные-данные