# Директор и машина — Право и риски: полные тексты

Направление: Право и риски — персональные данные · доступы · договоры
Хаб направления: https://davidgerstein.pro/pravo/
Материалов в файле: 3 из 3 по направлению.
Автор: Давид Герштейн. Цитирование свободное при указании источника.
Суммы пересчитаны на условную компанию: пропорции, механика и выводы реальные, абсолютные величины изменены. «оценка» = расчёт, а не замер.
Оглавление всех частей: https://davidgerstein.pro/llms.txt
Все направления одним файлом: https://davidgerstein.pro/llms-full.txt
Цифры и словарь понятий: https://davidgerstein.pro/cifry/ · машинная копия: https://davidgerstein.pro/cifry.json

## Персональные данные и ИИ: что можно доверить машине, а что запрещено законом
URL: https://davidgerstein.pro/blog/personalnye-dannye-i-neyroseti/
Дата: 2026-08-17
Направление: Право и риски
Цифры: фильтр ПД дешевле ручной проверки в 25–80 раз · окупаемость запуска фильтра меньше месяца · ревизия доступов с чек-листом короче в 2 раза
Коротко: Персональные данные и ИИ — не абстрактная угроза, а конкретные дыры в архитектуре: незащищённые вебхуки, публичные JS-файлы, таблицы с доступом «по ссылке». По 152-ФЗ компания обязана быть зарегистрированным оператором ПД и получить согласие клиента на трансграничную передачу, если данные обрабатываются на серверах ИИ-сервиса за границей. Решение — не запрет на ИИ, а фильтр перед моделью: по расчёту он обходится в десятки раз дешевле ручной проверки тех же данных.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Ваши сотрудники прямо сейчас вставляют данные клиентов в нейросети. Не со зла — просто им так удобнее, а правил вы не давали. Если вы не можете за минуту назвать, в каких ИИ-сервисах работает ваша команда и через чьи учётные записи они подключены, — у вас нет контроля над персональными данными. У вас есть надежда на аккуратность людей, а это не контроль. Разбираю, что можно и нельзя отправлять в ИИ, и как объяснить это команде так, чтобы правило соблюдалось. Аудит одной компании нашёл JavaScript-файл на публичном сервере с кошельками, данными менеджеров и информацией о клиентах. Файл индексировался поисковиками. Любой человек мог найти его обычным запросом в поиске — без взлома, без пароля, просто через выдачу. Никто в компании об этом не знал, пока не пришёл аудитор. Это и есть точка, где персональные данные и ИИ сталкиваются на практике: удобство автоматизации оборачивается дырой, о которой узнают последними. Это тема, которая всплывает в таких аудитах регулярно, потому что бизнес спешит автоматизировать процессы и не задаёт себе простой вопрос: куда уходят данные, которые в него заливают. Ревизия доступов на компанию среднего размера с несколькими юрлицами — это, по грубой оценке, 15–20 часов работы одного специалиста. Цена утечки, которую находит конкурент или регулятор раньше вас, не считается в часах. Персональные данные и ИИ: что нельзя отправлять в нейросеть В публичный чат нельзя: персональные данные клиентов и сотрудников (ФИО с контактами, паспорта, адреса, зарплаты), коммерческую тайну, доступы и ключи. Правило простое: если по данным можно опознать конкретного человека — они не идут в чат ни в каком виде. Рабочее решение — обезличивание до отправки: не «Иванов Пётр, +7 916…», а «клиент К., постоянный, чек 180 тыс. ₽». На качество ответа это не влияет, а автоматический фильтр обходится в 25–80 раз дешевле ручной проверки. Где именно ваш риск Не в том, что «ИИ украдёт данные». В том, что ваш сотрудник вставит в публичный чат таблицу с клиентами, потому что так быстрее. Когда сотрудник копирует переписку с клиентом в ChatGPT, чтобы «пусть ИИ ответит красивее», данные уходят на серверы сервиса, который физически находится за пределами страны. Это не абстракция. В одной компании юрист специально проверял это: документы клиентов лежали на американских серверах 2–3 месяца. Нужно было убедиться, что в договорах есть согласие клиента именно на трансграничную передачу данных. Без этого согласия компания нарушает закон, даже если ИИ используется из лучших побуждений и экономит менеджеру час в день. При аудите безопасности в другой компании выяснилось: вебхуки лежат без защиты, система имеет доступ к данным клиентов через внешний портал. Ошибки в коде оказались не главной бедой — хуже дыры в архитектуре доступа, через которые к чувствительным данным может добраться кто угодно со стороны. Сначала закрыли технические дыры и только потом занялись самим инструментом. Порядок важен: подключать нейросеть к процессу с дырявой архитектурой доступа — то же самое, что ставить сигнализацию на дверь, а окно оставлять открытым. Правило Прежде чем подключать нейросеть к рабочим процессам, проверьте архитектуру доступа. Промпт не спасёт, если данные утекают через незащищённый вебхук или таблицу с доступом «по ссылке для всех». Как проверить свой процесс перед подключением ИИ Четыре вопроса, на которые вам нужно ответить до того, как машина увидит первые данные. Всё это можно повторить со своей командой за одну-две недели. Вот последовательность, которую я использую сам. Инвентаризация. Составить список всех мест, откуда сотрудники берут данные для ИИ: CRM (Bitrix24, amoCRM), Google Таблицы, мессенджеры, файлы на сервере. Отдельно — список сервисов ИИ, к которым есть доступ, и через чьи учётные записи они подключены. Классификация данных. Разметить, какие поля в этих источниках относятся к персональным данным: ФИО, телефон, адрес, паспорт, платёжные реквизиты, данные о здоровье и происхождении. Это делает юрист или ответственный за комплаенс, не разработчик «на глаз». Фильтр перед моделью. Между источником данных и запросом к нейросети ставится промежуточный шаг — дешёвая модель или скрипт, который проверяет текст на наличие ПД и либо маскирует его, либо блокирует отправку. Это и есть техническая часть, разобранная в следующем разделе. Согласия и договоры. Проверить, есть ли в договорах с клиентами формулировка о согласии на трансграничную передачу данных — если ИИ-сервис зарубежный. Без неё юридически рискует не разработчик, а компания-оператор ПД. Контроль доступов. Развести права по принципу «один человек — одна таблица», токены и вебхуки хранить не в общих файлах, а в переменных окружения кода. Раз в квартал — повторный аудит, особенно после расширения команды. ИИ-связка: фильтр перед отправкой Техническое решение вашей проблемы: данные обезличиваются до того, как уйдут наружу, а не по памяти сотрудника. Конвейер простой: данные лежат в Google Таблице (или приходят вебхуком из Bitrix24) → перед тем как текст уходит в основную модель для анализа или генерации ответа, он проходит через дешёвую модель-классификатор → если найдены персональные данные, текст маскируется или блокируется → результат и лог решения пишутся в отдельный лист, ответственному падает уведомление в Telegram. Схема конвейера текстом: Google Sheets / Bitrix24-вебхук → Apps Script (триггер по расписанию) → дешёвая модель-классификатор → маскирование/блокировка → лист «Проверено» + алерт в Telegram при high-риске → только после этого текст может уйти в основную (дорогую) модель для содержательной работы . Для классификации персональных данных не нужна дорогая модель — задача формальная, не творческая: найти категории и вернуть структуру. Для такой задачи достаточно недорогой модели-классификатора начального уровня — она справляется не хуже старших моделей, а стоимость обращения на порядок ниже, чем даже одна SMS-верификация номера, которая в одной из компаний обходилась заметно дороже одного обращения к такому фильтру. Структура входных данных, которые Apps Script отправляет в модель (пример строки из Google Таблицы с заявками клиентов): Промпт для дешёвой модели-классификатора (system + user, отправляется через Apps Script UrlFetchApp на эндпоинт модели): Пример ответа модели на строку выше: Дорогая модель — старшая версия того же семейства — подключается только на следующем шаге, когда текст уже промаскирован, и работает с содержанием: формирует ответ клиенту. Распознавать ПД ей незачем — не потому что она хуже справляется, а потому что гонять сложную модель на формальную задачу классификации попросту дорого. Как это выглядит в самом листе «Проверено», куда Apps Script пишет результат каждой проверки: Google Sheets — лист «Проверено» ~1 200 обращений к фильтру в месяц ×25–80 дешевле ручной проверки doc_id risk_level action статус row_57 high block_before_ai row_58 medium mask row_59 low pass Обе цифры — оценка по потоку документов условной компании, расчёт — в разделе «Экономика». Инженерная обвязка Где крутится. Google Apps Script с триггером по времени (каждые 10–15 минут) читает новые строки таблицы или принимает вебхук от Bitrix24/amoCRM. Как перезапускается. Триггер идемпотентен: если модель не ответила или вернула невалидный JSON, строка помечается статусом «retry» и берётся в следующий проход. Без ручного вмешательства. Как сообщает об ошибке. Ошибки API (таймаут, невалидный ответ) пишутся в отдельный лист «Errors» с timestamp и текстом ошибки; при risk_level = high и при трёх подряд ошибках — уведомление ответственному в Telegram-бота. Учёт расходов. Каждый вызов дешёвой модели логируется отдельной строкой — это тот же принцип, что и учёт SMS-верификаций: мелкие операционные расходы должны быть видимыми, а не растворяться в общих счетах за ИИ. Персональные данные и ИИ: что требует 152-ФЗ Без юридических формулировок: что именно вам нужно иметь, чтобы спать спокойно. Коротко и по делу — без юридического языка, но с указанием, где вам стоит привлечь юриста. В одной группе компаний юрист провёл проверку: все юрлица группы зарегистрированы как операторы персональных данных в РКН. Это база, без которой любая автоматизация с ПД незаконна с самого начала. Но регистрация — только первый шаг. Дальше вопрос трансграничной передачи: если данные обрабатываются на серверах за границей (а большинство ИИ-сервисов работают именно так), нужно согласие клиента конкретно на такую передачу, а не общее согласие на обработку персональных данных. Регулирование быстро меняется, и не только у нас. На одной из встреч прозвучала формулировка, которая многое объясняет: «В Европе есть законопроект о запрете работы с персональными данными через ИИ без спецразрешения надзорного органа. В Америке разглашение персональной информации с расовыми, этническими признаками — уголовная статья». Это касается любой компании, которая работает с иностранными клиентами или использует зарубежные ИИ-сервисы, а не только международных корпораций. Категория данных Можно в ИИ без ограничений Требует согласия / обезличивания Обезличенная статистика (число звонков, конверсия) да — Имя, телефон, адрес клиента нет да, согласие на обработку и трансграничную передачу Паспортные данные, финансовые реквизиты нет да, отдельное согласие + минимизация доступа Раса, этническая, религиозная принадлежность нет в ряде юрисдикций — уголовная ответственность за разглашение Роль Доступ к сырым ПД Доступ к ИИ-фильтру Менеджер клиентского отдела да, в рамках своих сделок нет, только через фильтр Разработчик интеграции нет да, к коду фильтра, не к данным Ответственный за комплаенс да, для аудита да, полный доступ к логам Что нельзя отправлять — практический список Ваш ориентир: если по данным можно узнать конкретного человека — они не идут в публичный чат ни в каком виде. Распечатайте его и повесьте рядом с командой. Это дешевле любого штрафа. Правило простое, но его постоянно нарушают: если данные можно связать с конкретным человеком, их нельзя копировать в публичный чат ИИ без обезличивания. На практике это значит: Паспортные данные, номера документов, адреса — только через защищённые внутренние системы, не через веб-интерфейс общедоступной нейросети. Финансовые реквизиты и суммы платежей клиентов — обезличивать перед анализом, оставлять только агрегаты. Данные о здоровье, расе, религии — не передавать вообще, даже обезличенными, если нет отдельного юридического основания. Переписки с клиентами целиком — прежде чем отдавать ИИ на анализ тональности, вычищать имена, телефоны, адреса. Отдельная история — таблицы с доступом «у кого есть ссылка». В одной компании собственница попросила провести аудит всех таблиц и удалить посторонние адреса из совместных документов. Оказалось, что множество таблиц с финансовой информацией и данными клиентов были открыты для всех, у кого есть ссылка, включая людей, которые уже не работают в компании. Это не проблема ИИ напрямую, но именно из таких таблиц данные чаще всего попадают в промпты — сотрудник копирует строку в чат с нейросетью, не задумываясь, что таблица вообще не должна была быть открытой. Таблицы с доступом «по ссылке» 2 случая Вебхуки без защиты 1 случай JS-файл в открытом доступе 1 случай Личная учётная запись вместо служебной 1 случай На диаграмме — распределение зафиксированных случаев по типам утечки в наших аудитах, не статистика по рынку. Доступы сотрудников: где ломается контроль Ваша машина — такой же пользователь, как человек, и учитывать её доступы нужно так же. Один из самых частых источников проблем — не злой умысел, а разгильдяйство с учётными записями. При создании обучающего курса разработчик использовал личную учётную запись для авторизации вместо служебной. Прошло время, понадобилось дать доступ нескольким новым сотрудникам — и выяснилось, что отследить прохождение курса невозможно, потому что вся система завязана на личный аккаунт одного человека. С доступами к CRM та же болезнь: подробнее я разбирал её в статье о том, почему менеджеры не вносят данные в CRM — привычка обходить систему через личные каналы одна и та же. С доступами к ИИ-инструментам логика та же, только риски выше. Если промпты и API-токены привязаны к личной учётке сотрудника, компания теряет контроль в момент его увольнения или конфликта. На практике так и делали при настройке одной из интеграций: чувствительные ссылки доступа хранятся только в коде, локальные файлы не пересылаются во внешние каналы, доступ ограничивается минимально необходимыми правами. Это не бюрократия ради бюрократии — единственный способ не зависеть от одного человека и одной учётной записи. Похожий принцип звучал в цитате с одной из встреч: «Именно поэтому мы работаем в коде. Потому что единственный способ поставить работу, если вдруг случится какая-то блокировка, — это работать в коде, чтобы все файлы были у тебя и ты не зависела от доступа к учётной записи». Применительно к ИИ это значит: не собирайте всю автоматизацию вокруг личного кабинета одного сотрудника в ChatGPT или другом сервисе. Правило «один человек — одна таблица» Ещё один принцип разграничения прав пригодится и в работе с ИИ: «один человек — одна таблица» — правило против конфликтов между автоматическим и ручным редактированием. Когда несколько сотрудников и бот одновременно правят один документ, данные путаются, а отследить, кто передал строку в промпт нейросети, становится невозможно. Где ломается Автоматизация с доступом к персональным данным требует того же надзора, что и любая другая автоматизация — только цена ошибки выше. Подробнее о том, почему автоматизация без контроля превращается во вторую работу, — в статье про автоматизацию, которая требует надзора . Экономика: что стоит фильтр и что он даёт Сравнивайте не с нулём, а с размером штрафа за утечку: с 2026 года эта арифметика стала однозначной. Настройка фильтра занимает 12–18 часов работы разработчика и юриста, эксплуатация — 350–1 150 ₽ в месяц, а экономия по сравнению с ручной проверкой того же потока документов — около 28 000 ₽ в месяц (оценка). Возьмём условную сервисную компанию из легенды: отдел продаж 8 менеджеров, оборот ~9 млн ₽ в месяц, средний чек ~180 000 ₽ — это около 50 закрытых сделок в месяц. При таком масштабе поток входящих обращений с персональными данными (заявки, переписки, документы) — порядка 40 штук в день на весь отдел. Это и есть базовый поток, на который дальше считается экономика. Внедрение: настройка Apps Script-фильтра с классификатором и подключением к таблице/вебхуку — 8–12 часов работы разработчика. Дополнительно нужен юрист на проверку договоров на согласия — 4–6 часов. Итого разовые затраты на запуск — 12–18 часов специалистов среднего уровня. Эксплуатация фильтра считается по формуле «цена одного обращения к модели × число документов в день × 30 = расходы в месяц». При потоке 40 документов в день это 1 200 обращений в месяц. Цена короткого запроса к недорогой модели-классификатору — ориентировочно на два порядка меньше стоимости одной SMS-верификации, точная цифра зависит от длины текста и провайдера; совокупно это укладывается в 350–1 150 ₽ в месяц. Теперь — сколько стоит делать ту же проверку руками, без фильтра. Если человек тратит на ручную проверку одного документа около 2 минут, то при потоке 40 документов в день это 80 минут, или 1,3 часа в день, а за 22 рабочих дня — около 29 часов в месяц. По ставке ~1 000 ₽/час менеджера это 29 000 ₽ в месяц — потери рабочего времени на рутину, которую при этом человек всё равно частично пропускает. Разница между ~29 000 ₽ ручной проверки и 350–1 150 ₽ автоматического фильтра — это и есть заявленные 25–80 раз. Разовые затраты на внедрение (12–18 часов специалистов) окупаются меньше чем за месяц эксплуатации. Показатель Ручная проверка Автоматический фильтр Поток документов 40 в день 40 в день Время / нагрузка на человека в месяц ~29 часов без участия человека, кроме разбора high-риска Стоимость в месяц ~29 000 ₽ 350–1 150 ₽ Разовые затраты на запуск — 12–18 часов специалистов Окупаемость запуска — меньше месяца Эффект фильтра ПД мы считаем по двум составляющим: снятый юридический риск нарушения 152-ФЗ (в рублях напрямую не выражается) и экономия времени на ручной проверке документов, посчитанная выше. Ускорение продаж, конверсию сделок и прочие метрики отдела фильтр не трогает — это не его эффект, и смешивать его с другими ИИ-инициативами компании не стоит: если параллельно внедряются боты и распознавание документов, их экономику считайте отдельно — я разбирал это в статье о том, сколько реально стоит ИИ в месяц . Отдельная статья экономики — ревизия доступов на компанию с несколькими юрлицами: вручную, по грубой оценке, это несколько десятков часов — по 4 часа на юрлицо, если искать все таблицы, вебхуки и токены без структуры. С чек-листом из этой статьи то же самое укладывается в 15–20 часов — время короче примерно вдвое. На диаграмме — сравнение времени на ревизию доступов при нескольких юрлицах: без чек-листа и с ним. без чек-листа с чек-листом Время на ревизию доступов при нескольких юрлицах: без чек-листа и с чек-листом, часы специалиста. Знать, куда уходят данные из вашего процесса, — такой же базовый навык руководителя, как читать отчёт о деньгах. Без него вы управляете не компанией, а её видимой частью: пока никто не спросил про JS-файл на публичном сервере или таблицу «по ссылке», кажется, что всё в порядке. Я этот навык добирал задним числом — по итогам аудита, где мне показали то, чего я про собственную архитектуру доступов не знал. Отдельной должности он не требует: достаточно раз в квартал уметь ответить, кто и через какой доступ подаёт данные в машину. С чего начать вам в понедельник Регламент на одну страницу — и объявить его открыто. Выгрузить список всех ИИ-сервисов, к которым подключены сотрудники, и проверить, через чьи учётные записи — личные или служебные. Проверить все Google Таблицы и документы с доступом «по ссылке» — сменить на «только для приглашённых», удалить посторонние адреса. Найти все вебхуки и API-токены в коде и конфигурациях — перенести из открытых файлов в переменные окружения. Проверить договоры с клиентами на формулировку о согласии на трансграничную передачу данных, если используются зарубежные ИИ-сервисы. Поставить между источником данных и моделью промежуточный фильтр-классификатор ПД — хотя бы в виде скрипта на 20–30 строк, даже без дорогой модели на входе. Убедиться, что все юрлица компании зарегистрированы как операторы персональных данных в РКН. Что сделать вам на этой неделе: напишите короткий регламент на одну страницу — что запрещено всегда, чем можно пользоваться, кто отвечает за результат. И объявите его открыто, а не рассылкой в никуда. Полный разбор правовой стороны и рабочие формулировки — в бесплатном курсе для руководителей . Ваш минимум на эту неделю: одна страница правил и открытое объявление команде. Всё остальное — фильтры, контуры, договоры об обработке — можно достроить потом, но без правил вся эта техника защищает вас только на бумаге. У нас правило обезличивания появилось после того, как я сам чуть не отправил в чат таблицу с контактами клиентов — остановился на полсекунды. С тех пор мы не полагаемся на внимательность: данные обезличиваются до отправки, автоматически.

## Регламент работы с договорами: как сделать шаблон, который не подведёт в суде
URL: https://davidgerstein.pro/blog/dogovory-shablony-i-riski/
Дата: 2026-07-25
Направление: Право и риски
Цифры: иск в разы превысил фактическую оплату · 60–70% условий закрыто актами до старта · 5 чарджбеков за полтора года
Коротко: Регламент работы с договорами держится не на папке с бланками, а на четырёх вещах: одно место хранения шаблона, реестр версий с причиной каждой правки, пять закрытых блоков риска и порог, после которого зовут юриста. Один из кейсов статьи: иск на 772 тыс. ₽ против фактической оплаты 262 тыс. ₽ — компания смогла подтвердить только 150 тыс. как неоказанные услуги. Ускорить согласование без юриста на каждый чих можно, если заранее закрыть типовые риски библиотекой проверенных формулировок и передать первичную проверку модели.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Сколько версий вашего типового договора ходит сейчас по компании? Если вы уверены, что одна, — проверьте: я почти уверен, что их три. И одна из них — та, куда менеджер когда-то внёс правку клиента и забыл откатить. Если у вас нет одного места, откуда шаблон берут все, и одного человека, который отвечает за его версию, — регламента работы с договорами у вас нет. Есть привычка, которая держится ровно до первого спора. Разбираю, как навести здесь порядок и что из этого можно отдать машине. У компании, которая снимает семейные фильмы на заказ, были старые договоры с первыми клиентами и новые — с последними. В старых не было ни слова про итоговый фильм, сопровождение и визуальные ожидания. В новых — было. Разница появилась не потому, что кто-то сел и продумал риски заранее. Она появилась после конфликтов. Шаблоны договоров с клиентами в этой компании росли как заплатки поверх дыр, а не как система. Я видел это в нескольких компаниях: юрист есть, договор подписывается, но каждый новый конфликт обнажает формулировку, которую никто не проверял. Садятся переписывать один пункт вместо того, чтобы посмотреть на весь шаблон целиком. Пока идёт эта переписка — юрист тратит часы на ручную проверку каждого нового договора, потому что не доверяет старому шаблону. Если в отделе несколько менеджеров и каждый ведёт по 4 сделки в месяц с договором, это несколько десятков документов, из которых юрист вручную читает каждый — при 20–30 минутах на документ это десяток с лишним часов в месяц только на то, чтобы убедиться, что в тексте нет старой дыры. Что должно быть в регламенте работы с договорами Регламент работы с договорами — это не папка с бланками, а четыре правила: одно место, откуда шаблон берут все; реестр версий с причиной каждой правки; пять блоков, которые юрист закрывает один раз (гарантии, возвраты, этапы с актами, данные, запрет боковых договоров сотрудников); и порог, после которого зовут юриста. В разобранном кейсе 60–70% условий закрывается актами ещё до старта производства — именно этой фиксации не хватило в споре, где клиент требовал 772 тыс. ₽ при фактической оплате 262 тыс. ₽ , а подтвердить удалось только 150 тыс. ₽ . Первичную проверку договора на эти пять рисков вы можете отдать дешёвой модели: на потоке в 32 договора в месяц время юриста сокращается с 13 часов до 4 (оценка), а сам скрининг стоит десятки-сотни рублей в месяц. Договоры с клиентами: шаблоны, которые растут заплатками — это риск Разработчику курса дали задачу — он использовал личную учётку вместо служебной. Никто не заметил, потому что всё работало. Проблема всплыла, когда понадобилось выдать доступ новым сотрудникам, а прогресс прохождения курса оказалось невозможно отследить. С договорами то же самое: пока нет конфликта, дырявая формулировка не мешает. Мешает она в момент, когда клиент требует деньги назад, а вы читаете пункт и понимаете — там нет однозначного ответа. В компании, которая сопровождает клиентов в длительных разрешительных процедурах через внешние инстанции, был пункт 6.8: возврат денег полагался «при соблюдении рекомендаций компании о продолжении работы». Клиент получил два отказа от внешнего ведомства, отказался от дальнейшего обжалования и потребовал полный возврат. Компания потратила 70 тыс. ₽ на сбор документов и бонусы менеджерам, но вернула клиенту оплаченные 420 тыс. ₽ — потому что формулировка не выдерживала спора. Слово «отказ» звучало как финальная точка, хотя по факту первый отказ ведомства не был последней инстанцией. Решение — не карательное, а редакторское: заменить «отказ» на «уведомительное письмо от ведомства» и прямо прописать, что это не финальная инстанция. Полный возврат — только после исчерпания всех возможностей, включая обращение в вышестоящие органы. Один термин меняет всю логику ответственности. Правило Проверяйте каждую формулировку в договоре вопросом: «а что если клиент прочитает это буквально и максимально в свою пользу?» Если ответ неочевиден — переписывайте, не дожидаясь суда. Регламент работы с договорами: какие версии хранить и когда их менять У кинокомпании было решение сделать дополнительное соглашение — срочно, к пятнице. В нём: количество часов съёмки, определение качества видео, число локаций, обязательства клиента по предоставлению информации и участию семьи, границы ответственности компании при отказе клиента участвовать. Это типичный список того, что должно быть в шаблоне с самого начала, а не появляться после первого скандального проекта. Второе решение той же компании — разбить договор по этапам работ с согласованием выполненного перед переходом к следующему. До выхода на производство должно быть закрыто 60–70% условий, с актами выполненной работы. Это защищает обе стороны: клиент видит, за что платит на каждом шаге, компания фиксирует, что этап принят, и не отвечает потом за то, что происходило до подписания акта. Версия шаблона Чего не было Что добавили Первые клиенты Описание фильма, сопровождения, итоговых визуальных ожиданий Отдельный раздел с ожиданиями и определением качества Дополнительное соглашение (срочное) Часы съёмки, локации, обязательства клиента Конкретные цифры и границы ответственности при отказе участвовать Этапная версия Разбивки по этапам, актов 60–70% условий закрыто до старта производства, акты на каждый этап Гарантийная версия (п. 6.8) Точное определение «отказа» «Уведомительное письмо», явное указание — не финальная инстанция Если у вас нет истории конфликтов, по которой можно построить такую таблицу — начните собирать её сейчас. Каждый спор, дошедший до претензии, это готовая строка для будущей версии шаблона. Держите таблицу версий в отдельном реестре — Google Sheets или лист в CRM, — а не в переписке между менеджером и юристом, иначе через год никто не вспомнит, почему пункт звучит именно так. Гарантии: разделить то, что вы контролируете, и то, что нет Клиент требовал гарантировать итоговый результат в срок 6–12 месяцев с полным возвратом за 10 рабочих дней при неудаче. Компания не может контролировать проверки внешних инстанций, форс-мажоры и действия самого клиента. Но по договору обязана отвечать за результат целиком — это ловушка, в которую легко попасть, если гарантия написана одной строкой без разбивки. Решение, которое предложило руководство: перейти от гарантий по итоговому результату к гарантиям только по тем этапам, которые компания реально контролирует — сроки записи, этапы подготовки документов. По рискам, на которые компания не влияет, отдельно обсуждать с клиентом, какой конкретно риск он хочет застраховать. Это честнее, чем обещать всё и разбираться с последствиями постфактум. Похожая логика применима к деньгам. У компании было 5 чарджбеков за полтора года: клиент получает услугу, общается с менеджером, а потом оспаривает платёж через банк. Договор с чёткой фиксацией этапов и подписанными актами — лучшая защита от такого спора, потому что банк видит документальный след, а не голословное «услугу не оказали». Другой пример — слишком маленький минимальный аванс создавал риск неплатежей и требовал отдельного сотрудника только для сбора задолженности. Это тоже договорная проблема: если условия оплаты прописаны слабо, вы нанимаете человека разгребать то, что должен был закрыть текст на бумаге. Подробнее про то, как контроль дебиторки снимает эту нагрузку — в статье «Дебиторка растёт: контроль, который не зависит от памяти людей» . Типовые договоры: риски, которые не в тексте, а в людях Шаблон может быть идеальным, но его нарушает конкретный человек. Руководитель отдела заключил договор на консультационные услуги на 350 тыс. ₽ с клиентом, которому компания такие услуги не оказывает. Деньги получены, чек не выписан, договор подписан на ИП сотрудника — вопреки прямому запрету руководства. Это классический прецедент бокового заработка, и, что хуже, не первый: политика против таких договоров уже озвучивалась на совещаниях. Клиенты потом звонили собственнику с претензией, думая, что покупали услугу у компании, а получили её по отдельному договору мимо кассы. Здесь шаблон бессилен — нужен контроль исполнения. Я долго считал такие истории проблемой найма: не тех взяли. Оказалось, дело в другом — в компании не было ни одной бумаги, где сотруднику прямо запрещалось бы это делать. Но кое-что шаблон всё же может: явный пункт о запрете параллельных договоров с клиентами компании, подписанный каждым сотрудником с доступом к клиентской базе. Это не остановит недобросовестного человека, но даёт основание для иска и увольнения без долгих споров о трудовом праве. Второй похожий кейс — клиент оплатил 262 тысячи, а через суд потребовал 772 тысячи. Компания смогла задокументировать только 150 тысяч как не оказанные услуги и вернула именно эту сумму. Разница между тем, что требовал клиент, и тем, что удалось доказать, — это разница между компанией с актами на каждый этап и компанией без них. Похожая история — спор, где клиент требовал вернуть большую часть предоплаты, заявив, что не получил обещанную стратегию. Компания предложила стратегию постфактум, но было поздно: договор не фиксировал, что именно и когда должно быть предоставлено. Требование клиента 772 тыс. ₽ Реально оплачено 262 тыс. ₽ Задокументировано как неоказанное 150 тыс. ₽ Разрыв между верхним и нижним баром — это цена договора без промежуточных актов. Каждый из трёх кейсов в этом разделе решался бы иначе, если бы этап был закрыт документом до того, как начался следующий. Где ломается Договор без промежуточной фиксации результата — это договор, который в суде читается в пользу клиента. Акт на каждом этапе стоит дешевле, чем спор о том, что вообще было сделано. Данные клиентов в договоре: не только про деньги Отдельная категория рисков — то, что вы обязаны прописать про данные клиента, а не только про услугу. Юрист проверил, что все юрлица группы зарегистрированы как операторы персональных данных, но выявил пробел: в договорах с клиентами не было явного согласия на трансграничную передачу данных, хотя документы обрабатывались на зарубежных серверах. Это отдельный пункт, который легко забыть, если шаблон писался до того, как в процессе появилась внешняя обработка данных. Подробнее о том, что можно и что нельзя передавать через ИИ-сервисы — в статье «Персональные данные и нейросети: что можно отправлять в ИИ, а что нельзя» . Договор — это только половина защиты данных. Вторая половина — то, где вы физически храните файлы и таблицы, на которые в договоре ссылаетесь. При аудите одной из систем нашли конфиденциальную информацию — кошельки, данные менеджеров, сведения о компаниях — открыто лежащей в JS-файле на публичном сервере; её проиндексировали поисковики. В другой раз выяснилось, что таблицы с финансовой информацией и данными клиентов доступны всем, у кого есть ссылка. Формально в договоре может быть безупречный пункт про согласие на обработку данных — но если реестр рисков или база договоров лежит открытой по ссылке, этот пункт существует только на бумаге. Ещё один пробел того же типа — ответственность за иностранное контрактное право. Юрист составляет и проверяет договоры, но не имеет права общаться с клиентом напрямую. Ответ на это — не переписывание договора, а назначение отдельного специалиста, который отвечает за юридическую поддержку и может привлекать консультантов при необходимости. Иногда риск не в тексте документа, а в том, что некому объяснить клиенту, что там написано. ИИ-связка: автоматическая проверка договора перед юристом Юрист не должен читать каждый договор целиком, если 80% текста — типовые блоки, уже проверенные раньше. Его время нужно тратить на нестандартные условия. Чтобы это работало, между менеджером и юристом ставится дешёвая модель — она не подписывает и не советует, она находит расхождения с эталонным шаблоном и помечает риск. Схема конвейера — как это выглядит в виде реестра шагов и статусов: Конвейер проверки договора Шаг Инструмент Статус 1. Сборка договора из блоков Google Docs 2. Выгрузка текста по кнопке Apps Script 3. Скрининг риска Дешёвая модель (API) 4. Запись вердикта в реестр Google Sheets 5. Уведомление при high-риске Вебхук в Bitrix24 Дорогую модель я сюда сначала и ставил — и зря платил за то, что делает дешёвая. Модель здесь нужна дешёвая (класса mini, тип GPT-4o-mini или аналог) — задача не творческая, а классификационная: сверить пункт с пятью известными типами дыр и вернуть структурированный вердикт. По публичным ценникам таких моделей стоимость входных и выходных токенов минимальна — доли рубля за тысячу токенов (курс и точная цифра зависят от провайдера и меняются). Дорогую модель звать незачем, она нужна только если позже понадобится сгенерировать саму формулировку правки, а не найти проблему. Пример ответа модели на договор с пунктом про возврат без уточнения инстанции: Инженерная обвязка простая и без иллюзий: скрипт крутится в Google Apps Script, привязанном к служебному аккаунту, а не к личному — ровно тот урок, который компания усвоила на истории с курсом, где доступ был завязан на личную учётку разработчика и стал недоступен при масштабировании. Промпт и API-ключ хранятся в коде скрипта, а не в текстовом файле на диске — тот же принцип, что и с токенами доступа к порталу: «единственный способ сохранить работу при блокировке — чтобы все файлы были у тебя, а не зависели от чужой учётной записи». Шаг 5 в таблице конвейера — вебхук в CRM при high-риске — помечен предупреждением не случайно. При аудите безопасности в одной из систем выяснилось, что вебхуки лежат без защиты и через них можно достучаться до данных клиентов на внешнем портале. Ошибки в самом коде проверки риска оказались там мельче проблемы: настоящей дырой была архитектура доступа, а не логика скрипта. Прежде чем подключать вебхук уведомлений к боевой CRM, закройте его токеном и ограничьте IP отправителя — иначе вы чините одну дыру и открываете другую. При сбое API — три автоматических повтора с паузой, затем письмо ответственному юристу с пометкой «скрининг не сработал, проверьте вручную». Реестр рисков в Google Sheets открыт по принципу «один человек — одна таблица»: юрист правит статусы, менеджер только читает, чтобы автоматическая запись не конфликтовала с ручной правкой. Реальная стоимость токенов на поток в несколько десятков договоров в месяц оказалась ниже, чем я закладывал в план: по прикидке выше это десятки-сотни рублей в месяц даже с запасом на повторные прогоны. Основные деньги в этой схеме экономятся не на API, а на часах юриста — это разбираем в разделе экономики. Ограничение модели Скрининг ловит только известные пять типов риска — то, что уже случалось. Новый тип дыры, которого не было в истории компании, модель не увидит. Реестр нужно пополнять после каждого нового конфликта, иначе список рисков замораживается на дне выпуска промпта. Согласование без юриста на каждый пункт: пять блоков, которые закрывают всё заранее Самый частый вопрос, который я слышу: «Можно ли согласовывать договоры быстрее, не гоняя каждый вариант через юриста?» Можно, если заранее закрыть типовые риски библиотекой формулировок: Гарантийные пункты — по этапам, которые компания контролирует, а не по итоговому результату. Возвраты — с чёткой развилкой «что считается отказом» и «что не является финальной инстанцией». Этапы и акты — минимум для 60–70% объёма работ до основной фазы проекта. Данные — согласие на трансграничную передачу, если данные уходят на внешние серверы. Ограничения для сотрудников — прямой запрет параллельных договоров с клиентами компании. Когда эти пять пунктов закрыты один раз юристом, дальше менеджер собирает договор из проверенных блоков без согласования каждой версии заново. Юрист подключается только когда клиент просит нестандартное условие — гарантию срока, особый порядок оплаты, изменение ответственности. Это резко сокращает время согласования, потому что большая часть текста уже проверена, а спорным остаётся один-два пункта. Работает это только если версии шаблона хранятся централизованно, а не расползаются по личным папкам менеджеров — иначе вы снова получите ситуацию с первыми и последними договорами, которые отличаются друг от друга без всякой логики. Автоматизация без владельца процесса создаёт похожий хаос и в других системах компании: без человека, который следит за версией, документы расползаются так же, как когда-то расползались вкладки в CRM без ответственного. Экономика: что стоит библиотека шаблонов и что она даёт Настройка ИИ-скрининга — около 6 часов на скрипт и промпт, эксплуатация — десятки-сотни рублей в месяц на токены, эффект — около 13 500 ₽ экономии на времени юриста в месяц (оценка). Возьмём отдел из 8 менеджеров со средним чеком 180 тыс. ₽. Каждый ведёт по 4 сделки в месяц с договором — 32 договора в месяц. Ниже — грубая оценка, не факт компании, а типовой расчёт «часы × ставка», который можно приложить к своим цифрам. Показатель Без библиотеки шаблонов С библиотекой + ИИ-скрининг Договоров в месяц 32 32 Время юриста на документ 20–30 минут (читает всё) 3–5 минут на «чистые», 20–30 минут на нестандартные (≈20% потока) Часы юриста в месяц (оценка) ~13 часов ~4 часа Стоимость по условной ставке (оценка) ~19 500 ₽/мес ~6 000 ₽/мес Стоимость ИИ-скрининга — единицы-десятки рублей/мес Разница — около 13 500 ₽ экономии на времени юриста в месяц: ставка юриста ~1 500 ₽/час, у вас юрист может стоить дороже или дешевле. Разовые затраты на создание самой библиотеки — юрист один раз сводит существующие формулировки, переписывает пять проблемных блоков и утверждает эталонный шаблон: около 40 часов по той же ставке — разово около 60 000 ₽. При экономии ~13 500 ₽/мес окупаемость составляет примерно 4–5 месяцев (оценка, без учёта того, что часть этих часов юрист и так тратил бы на разбор конкретных конфликтов). Это только эффект от сокращения ручного чтения — не смешивайте его с эффектом от кейса 772/262/150 тысяч. Там сработал не ИИ-скрининг, а факт наличия поэтапных актов в договоре: это отдельная инициатива (перестройка структуры договора), и её вклад нельзя списывать на автоматизацию проверки. Что не считаем эффектом ИИ-скрининга: снижение суммы иска в конкретном споре, ускорение получения оплаты и любые изменения, которые дали акты и этапная разбивка договора, — это отдельные рычаги со своей отдельной экономикой. Не путать эффекты ИИ-скрининг экономит часы юриста на чтении типовых блоков — это около 162 000 ₽ в год. Поэтапные акты снижают сумму, которую можно отсудить постфактум, — это может быть на порядок больше в конкретном споре (см. разницу 772/262/150 тысяч выше). Считайте окупаемость каждого рычага отдельно, иначе завышенная общая цифра развалится при первой проверке цифр советом директоров. Чек-лист: с чего начать в понедельник Внедрение библиотеки шаблонов и ИИ-скрининга — не проект на квартал, а неделя сфокусированной работы, если у вас уже есть история конфликтов. Понедельник. Собрать все действующие версии договорных шаблонов в один реестр (Google Sheets или лист CRM). Выписать все претензии и споры за последние 12 месяцев — каждая станет строкой будущей таблицы версий. Вторник. Свести найденные проблемы в пять категорий: гарантии, возвраты, этапы/акты, данные, боковые договоры сотрудников. Отдать список юристу на разовую вычитку — не всего шаблона, а именно этих пяти блоков. Среда. Юрист переписывает проблемные формулировки один раз и утверждает эталонный шаблон. Параллельно — проверить права доступа к реестру и таблицам с договорами: не лежат ли они открытыми по ссылке. Четверг. Настроить скрипт скрининга: Apps Script на служебном аккаунте, промпт из этой статьи, запись вердиктов в Google Sheets. Прогнать на 5–10 старых договорах, чтобы откалибровать severity и убедиться, что модель не путает риски. Пятница. Подключить уведомление в CRM при high-риске через защищённый вебхук (токен + ограничение по отправителю). Провести короткую летучку с менеджерами: как собирать договор из готовых блоков и когда обязательно звать юриста. Через месяц. Пересчитать часы, которые юрист реально тратит на договоры, и сверить с оценкой из раздела экономики — если цифры разошлись сильно, дело либо в ставке, либо в доле нестандартных условий выше ожидаемых 20%. Отдельно — про людей, а не про текст. Библиотека шаблонов и ИИ-скрининг не остановят сотрудника, который решит заключить параллельный договор в обход компании, как это уже случалось. Здесь помогает только явный пункт о запрете и регулярный аудит закрытых сделок — если политика озвучена один раз на совещании, это не значит, что прецедент не повторится. Если проблема шире, чем формулировки в договоре — например, менеджеры вообще не фиксируют этапы работы в CRM, и акты подписывать не с чем, — начинать нужно не с шаблона, а с дисциплины внесения данных. Об этом — в статье «Менеджеры не вносят данные в CRM: что делать без репрессий» . Ни один шаблон не заменит договора, прочитанного человеком. Но если типовые риски закрыты один раз, юрист тратит время именно на то, на что тратить его должен, — а не на пятый одинаковый абзац про гарантии. И ещё одно, чему мне пришлось учиться самому: читать собственный договор глазами клиента, который завтра захочет вернуть деньги. Это управленческий навык, а не юридический. Юрист сверит текст с законом, но только вы знаете, что менеджер пообещал клиенту голосом и чего клиент ждёт по факту. Руководитель, который умеет заранее назвать пять мест, где его же договор прочитают против него, стоит компании дешевле любого разбирательства. Ваша проверка на эту неделю: соберите у трёх менеджеров файл «типового договора», который они отправляют клиентам, и сравните между собой. Если найдёте расхождения — вы нашли свой риск, и он дороже любой автоматизации. Как поставить проверку версий и первичный разбор входящих договоров машиной — в бесплатном курсе для руководителей . И последнее: договорите с вашим юристом одну вещь — кто и как часто проверяет актуальность шаблонов. Без этого правила ваш идеальный договор устареет вместе с законодательством, и узнаете вы об этом в суде. Как это было у нас Мы обнаружили три разные версии типового договора случайно, и я до сих пор считаю это везением — когда клиент прислал наш же документ с пунктом, который мы год назад убрали. Оказалось, у одного менеджера сохранилась старая версия, и он отправлял именно её. Я тогда не стал разбираться, кто виноват: система позволяла хранить договоры где угодно, и рано или поздно это должно было случиться. Мы завели единое место, откуда берётся шаблон, и правило, что личные копии не используются. Сверьте свои шаблоны на этой неделе — и заведите одно место, откуда их берут все. Как поставить проверку версий машиной, разбираю в бесплатном курсе .

## Права доступа сотрудников: кто ещё может зайти в ваши системы
URL: https://davidgerstein.pro/blog/dostupy-sotrudnikov-audit/
Дата: 2026-06-28
Направление: Право и риски
Цифры: 5 сотрудников без доступа к курсу · 500 000 ₽ мимо кассы за одну сделку · 30 ₽ за одноразовый SMS-номер
Коротко: Права доступа сотрудников — это ответ на вопрос, кто и через какую учётную запись реально может видеть данные компании, а не список паролей в файле. Ревизия находит три типовые дыры: личные аккаунты вместо служебных, таблицы с доступом «по ссылке» и права, которые не закрыли после увольнения. Цена такой дыры может быть ощутимой: в одном случае прямой доступ к клиенту позволил провести мимо кассы сделку на 500 000 ₽ — около 6% месячного оборота условной компании.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Смотрите. Если вы прямо сейчас не назовёте поимённо, кто из бывших сотрудников ещё может зайти в ваши системы, — открытые доступы у вас уже есть. Не «возможно есть», а есть. Я говорю это не для страху: у себя я нашёл их ровно так — не искал, а наткнулся. Это не вопрос доверия к людям, это вопрос гигиены, и он всплывает в самый неподходящий момент. Разработчик делал обучающий курс для сотрудников. Настроил его под свою личную учётную запись — так было быстрее, не пришлось заводить служебную. Курс работал, люди учились. Проблему заметили только через несколько месяцев, когда понадобилось дать доступ пятерым новым сотрудникам. Оказалось, что весь курс висит на личном аккаунте одного человека, отследить прохождение невозможно, а выдать права кому-то ещё — тоже. Права доступа сотрудников в этой компании до того дня не сверяли ни разу: всё работало, значит, всё в порядке. Это типичная логика среднего бизнеса. Доступы раздают по мере необходимости, никто не ведёт реестр, а вопрос «кто и куда может зайти» всплывает либо при увольнении, либо после утечки. Если для компании из нескольких десятков человек и полутора десятков сервисов такой сверки не делали ни разу — это не гипотетический риск, это уже накопленный долг, который однажды предъявят к оплате. Разберу, где обычно ломается, как это автоматизировать и что реально стоит проверить, если аудит доступов вы ещё не делали. Как проверить права доступа сотрудников Права доступа сотрудников проверяют так: выгрузите список всех учётных записей во всех системах и сверьте его с актуальным штатным расписанием. Час работы. Дальше по каждой строке решение: оставить, сузить права, отозвать. Что находят чаще всего: активные доступы уволенных, права «на всякий случай» шире задачи, общие учётки без владельца и доступ через личные аккаунты в облаках. Регулярность важнее глубины — раз в квартал, с именем ответственного в чек-листе увольнения. Аудит начинается не с паролей, а с денег Считайте не риски в абстракции, а конкретно: что произойдёт с вашим бизнесом, если завтра эти данные окажутся у конкурента. Первая ошибка — считать, что аудит доступов это ИТ-задача. Я сам так считал несколько лет: есть системный администратор, значит, доступы — его зона ответственности. На практике это в первую очередь вопрос контроля над деньгами и обязательствами компании. А значит, это не задача админа, а задача того, кто отвечает за деньги. Руководитель отдела, доверенное лицо, заключил договор на консультационные услуги с клиентом компании на 500 000 ₽ — около 6% месячного оборота условной компании (9 млн ₽/мес при отделе из 8 менеджеров). Клиенту такие услуги компания не оказывает — их не должно было существовать. Деньги получены, чек не выписан, договор подписан на ИП сотрудника. Руководство прямо запрещало такую деятельность на совещаниях. Прецедент всё равно случился. В другой истории похожая схема: сотрудник продавал услуги мимо компании, клиенты звонили собственнику с претензией, думая, что покупали у него, а на деле получили услугу по отдельному договору. Политика против боковых заработков была объявлена заранее — это не остановило. Оба случая — не про пароли. Но именно доступ к клиентской базе, к контактам, к переписке с клиентом делает такую схему возможной. Аудит доступов отвечает на вопрос: кто физически может дотянуться до клиента и данных, минуя систему учёта. Если ответ — «почти любой сотрудник, у кого есть логин», проблема уже создана, осталось дождаться, когда ей воспользуются. Правило Доверие к сотруднику — не повод не проверять его доступы. Именно доверенные сотрудники наносят самый дорогой ущерб — у них больше прав и меньше контроля. Где чаще всего находятся дыры Идите по списку и отмечайте. Три места, где дыры находятся почти всегда. Я ни разу не видел компанию, где не сработало бы хотя бы одно, — и ваша вряд ли исключение. Личные аккаунты вместо служебных История с курсом на личном аккаунте — не редкость. То же самое встречается с ботами, интеграциями, автоматизацией отчётов: человек настраивает сервис под себя, потому что так проще завести доступ прямо сейчас. Через полгода он увольняется или уходит в отпуск, и никто не может зайти в систему, которая держит на себе часть операционки. Таблицы и документы с доступом «по ссылке» В одной компании обнаружили: множество таблиц с финансовой информацией и данными клиентов открыты для всех, у кого есть ссылка. Не для конкретных людей — для любого, кто ссылку получил. Собственница запросила аудит всех таблиц и удаление посторонних адресов из совместных документов. В другом случае конфиденциальная информация — кошельки, данные менеджеров, сведения о компаниях — оказалась в открытом JavaScript-файле на публичном сервере. Файл индексировали поисковики. То есть данные не украли — их выложили сами, по невнимательности при настройке. Доступ третьих лиц через внешний портал При аудите безопасности одной системы выяснилось: веб-хуки лежат без защиты, а внешний портал имеет доступ к данным клиентов. Архитектурная проблема доступа третьих лиц оказалась серьёзнее обычных ошибок в коде — приоритет работ пересмотрели, сначала закрывали дыры в доступе, потом занимались остальным. Что проверять Типичная ошибка Что сделать Учётные записи в сервисах Настроено на личный аккаунт сотрудника Перевести на служебную учётную запись компании Таблицы и документы Доступ «по ссылке» для всех Именной доступ, регулярная ревизия списка API-токены и ключи Хранятся в переписке, передаются во внешние каналы Хранить в коде, минимально необходимые права Доступ уволенных Закрывают по памяти, когда вспомнят Регламент: чек-лист отзыва прав в день увольнения Внешние порталы и веб-хуки Без защиты, доступ к данным клиентов Аудит перед любой доработкой продукта Права доступа сотрудников: по минимуму, а не «на всякий случай» Правило, которое сэкономит вам нервы: если сотрудник просит доступ «чтобы посмотреть» — дайте выгрузку, а не доступ. Ваше правило: доступ выдаётся под задачу и на срок задачи. Расширить проще, чем потом разбираться. При настройке интеграции через API-токены в одной из систем применили простое правило: чувствительные ссылки доступа хранятся только в коде, локальные файлы не передаются во внешние каналы, права выдаются минимально необходимые. Не «дам доступ ко всему, вдруг понадобится», а ровно к тому, что нужно для задачи. Похожий принцип сформулировали для совместных документов: «один человек — одна таблица». Это разграничение прав, которое предотвращает конфликт между автоматическим обновлением и ручным редактированием — и заодно снимает вопрос, кто именно испортил данные, если что-то пошло не так. Когда за таблицу отвечает один человек, аудит доступов превращается в простую сверку: у кого есть права редактирования, должно совпадать со списком тех, кто реально должен туда писать. С массовой выдачей доступов та же логика. При регистрации сотрудников в облачных системах внедрили процесс автоматизации получения смс-кодов через третий сервис — по 30 ₽ за код — и регламент учёта: каждый номер одноразовый, использование фиксируется. Это мелочь, но она превращает хаотичную раздачу доступов в процесс, который можно проверить постфактум, а не гадать, кто и когда что регистрировал. Закрытие доступов — не разовая акция Проверьте свой процесс увольнения: есть ли в нём пункт про отзыв доступов, и кто за него отвечает поимённо. Проблема с личной учёткой разработчика показала главное: доступы, привязанные к человеку, а не к роли, невозможно закрыть чисто. Когда сотрудник увольняется, компания либо теряет доступ к системе, либо вынуждена держать его учётку живой неопределённо долго — потому что переносить настройки некому и некогда. Отсюда правило, которое стоит закрепить регламентом, а не держать в голове у одного администратора: любой сервис, влияющий на операционку, настраивается на служебный аккаунт компании. Личный аккаунт — только временное решение с датой, когда его заменят на служебный. Вторая часть регламента — чек-лист на день увольнения. Не «через неделю кто-нибудь вспомнит», а список: какие сервисы, какие таблицы, какие мессенджеры, какие общие ящики. Без такого списка отзыв доступа держится на памяти руководителя, а память подводит именно в конфликтных увольнениях — когда цена ошибки выше всего. Отдельно стоит вопрос блокировки самой платформы, а не человека. При внедрении бота в мессенджер обнаружили: платформа может заблокировать номер при нестандартном использовании. Решение — завести отдельный тестовый номер для проверки, прежде чем выводить бота на рабочий канал. Логику продолжает подход, который использовали в другой команде: «мы работаем в коде, потому что единственный способ устоять при блокировке — это чтобы все файлы были у тебя, и ты не зависела от доступа к учётной записи». Аудит доступов должен отвечать и на этот вопрос: что случится с операционкой, если один сервис исчезнет или заблокирует конкретный аккаунт. ИИ-связка: автоматическая сверка доступов Ваша цель — чтобы список расхождений приходил сам, а не собирался руками раз в год под аудит. Ручная сверка «кто уволен — у кого остались права» работает, пока в компании небольшая команда и несколько сервисов. На полусотне людей и полутора десятках систем (CRM, облачные таблицы, боты, порталы) это уже задача для регулярного скрипта, а не для памяти HR-менеджера. Собирать всё вручную каждый квартал — дорого по времени и ненадёжно: список из полутора десятков вкладок никто не сверяет построчно два раза подряд. Конвейер простой: раз в неделю скрипт выгружает список активных сотрудников (из HR-таблицы или через API CRM — например, список пользователей amoCRM) и список выданных доступов (ведётся отделом в отдельном листе Google Sheets), сводит их в один JSON и отправляет дешёвой модели на классификацию расхождений. Результат падает в лист «Аномалии», критичные случаи — сразу уведомлением ответственному. Схема: HR-таблица + список доступов → Google Apps Script собирает JSON → запрос к LLM API → ответ пишется в лист «Аномалии» → high-risk строки триггерят уведомление в Telegram. Модель нужна дешёвая — задача не творческая, а классификационная: сопоставить статус сотрудника с датой последнего доступа и вернуть структурированный список. Гонять её на дорогой модели — переплата без пользы. Пример ответа модели: Так это выглядит уже не в JSON, а в самом рабочем листе, куда падает результат: Google Sheets — лист «Аномалии» Email Сервис Проблема Риск ivanov@gmail.com Telegram-бот CRM уволен 3 мес назад, доступ активен высокий petrova@company.ru Google Sheets: Финансы Q2 доступ по ссылке, не именной средний sidorov@company.ru Портал клиентов дубль прав с уволенным низкий Инженерная обвязка: скрипт крутится на Google Apps Script с триггером по расписанию раз в неделю, читает два листа (сотрудники, доступы), формирует JSON и обращается к LLM через HTTP-запрос. Результат пишется в третий лист «Аномалии» с меткой времени. Если сервис недоступен — три повторные попытки с паузой, при неудаче запись падает в лист «Ошибки» и уходит уведомление ответственному за доступы, а не молча теряется. Ключ к LLM API и токены к CRM хранятся в свойствах скрипта, а не в самом коде таблицы — тот же принцип «минимально необходимые права», что и в истории с API-токенами выше. Если данные о пользователях идут из Bitrix24 через вебхук, тот же принцип разбирал я в статье про то, как CRM врёт с датами — прежде чем строить на вебхуке аудит доступов, стоит убедиться, что сами даты и статусы в CRM не съезжают. Разница в трудозатратах между ручным и автоматическим вариантом наглядно видна на диаграмме ниже. Ручная сверка всех сервисов (раз в квартал) 10 ч Поддержка двух листов для скрипта ~20 мин / неделя Проверка листа «Аномалии» человеком ~15 мин / неделя Автоматический прогон скрипта ~5 мин / неделя Цифры в диаграмме — оценка по типовым трудозатратам, не хронометраж. Во сколько раз автоматическая сверка выгоднее Прикиньте на своей численности: сколько человеко-часов уходит у вас на одну ручную сверку и сколько раз в год вы её делаете. Настройка автоматической сверки — около 8–10 часов, эксплуатация — около 300 ₽/мес на токены модели плюс около 35 минут в неделю ответственного, а эффект — окно, в котором доступ уволенного сотрудника или таблица «по ссылке» остаются незамеченными, сокращается с трёх месяцев при квартальной ручной сверке до одной недели (оценка). Формула для ручной сверки простая: число сервисов × среднее время проверки одного сервиса = трудозатраты одного цикла. На сбор списка активных сотрудников, проход по сервису и сверку прав обычно уходит 30–40 минут на сервис. Для 15 сервисов это 15 × 40 минут ≈ 10 часов — та же цифра, что на графике выше. Один квартальный проход стоит компании как 10 часов работы ответственного, а за год из четырёх проходов — около 40 часов той же работы. Если у вас 5 сервисов и меньше сотрудников, время пропорционально меньше — например, около 3 часов на проход: подставьте своё число сервисов в ту же формулу. Автоматическая сверка требует разовой настройки скрипта, промпта и тестового прогона на реальных данных — это те самые 8–10 часов из оценки выше, сопоставимые с одним ручным квартальным проходом. Дальше скрипт бегает сам раз в неделю, но кто-то должен поддерживать актуальность двух исходных листов (около 20 минут в неделю) и просматривать лист «Аномалии» (около 15 минут в неделю) — вместе это около 30 часов в год, заметно меньше 40 часов на четыре ручных прохода. При ставке около 1000 ₽/час эта разница — порядка 10 000 ₽/год, то есть по чистой экономии часов автоматизация окупается небыстро: настоящая выгода не в этих деньгах, а в частоте проверки. Показатель Ручная сверка (раз в квартал) Автоматическая сверка (раз в неделю) Частота проверки 4 раза в год 52 раза в год Трудозатраты в год ≈ 40 ч ≈ 30 ч + разово 8–10 ч на внедрение Затраты первого года относительно ручной сверки база для сравнения сопоставимы или чуть выше из-за внедрения; со второго года — заметно ниже Сколько доступ может «висеть» незамеченным до 3 месяцев до 1 недели По трудозатратам автоматизация в первый год почти не выигрывает у ручной сверки — экономия становится заметной со второго года, когда разовые часы на внедрение уже не в счёте. Настоящий эффект не в часах, а в частоте: тот же объём усилий покупает проверку раз в неделю вместо раза в квартал, а значит, доступ уволенного сотрудника или таблица «по ссылке» не успевают провисеть месяцами до следующей ревизии. На диаграмме — как меняется сама частота проверки. 4 раза до 52 раза после Было — ручная сверка раз в квартал, 4 прохода в год. Стало — автоматический прогон раз в неделю, 52 прохода в год. Что мы не считаем эффектом: сами ~10 000 ₽/год экономии на трудозатратах — не главная выгода автоматизации, это фон. Мы также не считаем эффектом аудита сам разовый случай на 500 000 ₽, разобранный ниже, — это иллюстрация масштаба риска, а не гарантированная ежемесячная экономия. Эффект самого аудита считать напрямую в деньгах сложнее — он не приносит выручку, он снимает риск. Но масштаб риска можно проиллюстрировать конкретным случаем: доверенный сотрудник заключил договор в обход компании на 500 000 ₽ — около 6% месячного оборота условной компании, пользуясь тем, что имел прямой доступ к клиенту без промежуточного контроля. Аудит доступов сам по себе не остановил бы умышленное мошенничество — это отдельный вопрос доверия и внутреннего контроля, и сдвиг здесь дала бы связка регламента доступа и общего контроля, а не один только аудит. Но регулярная сверка убирает техническую возможность делать это месяцами незаметно: если доступ к клиентской базе логируется и проверяется хотя бы раз в неделю, а не раз в квартал или никогда, аномальная активность видна раньше, а не тогда, когда клиент уже позвонил с претензией. Где ломается Регламент по доступам работает, только если его проверяют регулярно, а не пишут один раз после инцидента. Автоматическая сверка снимает часть нагрузки, но не заменяет человека, который читает лист «Аномалии» и реально закрывает найденные доступы — если этот шаг выпадает, скрипт превращается в красивый отчёт, который никто не открывает. Куда уходят ваши данные Три канала, о которых обычно не думают: облачные диски, личные аккаунты сотрудников и нейросети. Отдельный слой риска — данные, которые уходят за пределы компании: в облачные таблицы с доступом по ссылке, во внешние порталы, в ИИ-сервисы. Требования к персональным данным в целом ужесточаются не только в России: в разных юрисдикциях обсуждают более жёсткие правила работы с персональными данными через ИИ-сервисы и отдельно — с чувствительными категориями данных вроде расовой или этнической принадлежности. Формулировки и статус таких инициатив стоит уточнять по конкретной стране перед принятием решений, но общий вектор понятен уже сейчас: вопрос «кто и куда отправляет данные клиента» — не только вопрос внутреннего контроля, но и растущий юридический риск. Прежде чем встраивать ИИ в работу с клиентскими данными, стоит понять, что вообще можно отправлять во внешние модели, а что нет — это отдельная тема, я разбирал её в статье про персональные данные и нейросети . Если в компании уже есть автоматизация, которая работает без постоянного присмотра, риски доступов там множатся быстрее обычного — см. текст про автоматизацию, которая требует контроля . С чего начать вам в понедельник Один час, один список, одно решение по каждой строке. Выгрузить список всех сервисов, где хранятся данные клиентов, финансов или переписка с клиентом. По каждому сервису проверить: аккаунт служебный или личный. Личные — в план перевода на служебные, с датой. Пройтись по облачным таблицам и документам, найти доступ «по ссылке» вместо именного и закрыть. Составить чек-лист отзыва доступов на день увольнения: сервисы, таблицы, мессенджеры, общие ящики — списком, а не по памяти. Назначить одного ответственного за квартальную ревизию доступов — с датой в календаре, а не «когда-нибудь». Если сервисов больше десяти — запланировать автоматическую сверку по модели из этой статьи вместо ручной раз в квартал. Ревизия прав доступа сотрудников не заканчивается один раз. Она превращается в привычку: раз в квартал пройтись по списку сервисов, сверить, кто там реально должен быть, и закрыть то, что осталось от прошлых сотрудников, прошлых экспериментов и прошлой спешки. И вот что здесь важнее любого чек-листа. Держать в голове карту «кто куда может дотянуться» — это управленческий навык, такой же базовый, как чтение отчёта о деньгах. Руководитель, который за минуту скажет, кто имеет доступ к клиентской базе и к платежам, управляет бизнесом. Тот, кто не скажет, управляет ощущением контроля. Разница проявляется не каждый день, а один раз — и сразу дорого. Если вы за минуту такую карту по своей компании не соберёте — навыка пока нет. Сделайте на этой неделе: выгрузите список всех, у кого есть доступ к вашим системам, и сверьте с актуальным штатным расписанием. Час работы, и результат обычно неприятно удивляет. Как поставить регулярный аудит доступов без ручной сверки — в бесплатном курсе . Проверьте свою ситуацию прямо на этой неделе — и если найдёте активные доступы у бывших сотрудников, не устраивайте разбор полётов. Просто закройте и заведите регулярную сверку: это системная дыра, а не чья-то халатность. И ещё одно: заведите отдельную строку в вашем процессе увольнения — «доступы отозваны, проверил такой-то». Одна строка, а закрывает целый класс рисков. Как это было у нас Мы делали первую сверку доступов через полтора года после запуска — и нашли активные учётки людей, которые не работали у нас по восемь месяцев. Никакого злого умысла: просто увольнение шло через кадры, а доступы жили у нас в ИТ, и никто не соединил эти два процесса. Я тогда не стал искать виноватого — сама схема была дырявой. Мне было неприятно другое: полтора года я подписывал документы об увольнении и ни разу не спросил, закрыты ли доступы. Моя недоработка, не кадровиков. Мы связали два процесса одной строкой в чек-листе увольнения и завели ежеквартальную сверку. С тех пор находки единичные и закрываются в тот же день. Сделайте сверку на этой неделе — и заведите следующую на квартал вперёд прямо в календаре. Как автоматизировать — в бесплатном курсе . Мы нашли у себя доступы людей, которые не работали восемь месяцев, — и после этого сверка стала ежеквартальной. Ваша первая сверка, скорее всего, покажет то же самое.