Политика по AI для портфеля: покупка инструментов и доступ к данным

Почему AI-инструменты так быстро расползаются по портфелю

Расползание AI-инструментов редко начинается с большого решения. Обычно всё начинается с цепочки маленьких, разумных шагов, которые разные стартапы делают в разное время. Один основатель хочет быстрее проводить исследования, другой команде нужна помощь с письмами для продаж, а разработчику нужен ассистент для программирования. Каждая покупка по отдельности кажется дешёвой и безобидной.

В портфеле этот эффект только усиливается, потому что каждый стартап живёт по своему графику. Одна компания всё ещё ищет product-market fit. Другая быстро нанимает людей. Третья находится под давлением клиентов и хочет срочно получить помощь. Покупка инструментов происходит по чуть-чуть: пробные версии, списания с карты, тихие автопродления, а не один заметный момент согласования.

Любой, кто сопровождает несколько стартапов, видит одну и ту же картину. Основатели тестируют инструменты ещё до того, как кто-то успеет их проверить, потому что так работают ранние команды. Если активация занимает пять минут, большинство воспринимает сервис как обычное приложение, а не как поставщика, который может хранить промпты, файлы и данные учётной записи.

Настоящий риск обычно появляется во время тестирования. Сотрудники вставляют туда письма клиентов, переписку из поддержки, заметки со звонков, контракты или данные о продукте, чтобы проверить, даст ли промпт полезный ответ. Они не воспринимают это как решение по данным. Они думают: «Мне просто нужно проверить, работает ли это». Правила доступа к данным для стартапов должны быть достаточно простыми, чтобы занятые команды могли им следовать, не тормозя каждый эксперимент.

Finance часто замечает проблему слишком поздно. К тому моменту, когда расходы становятся видимыми, бесплатный период уже превратился в платные места, годовой план продлился автоматически, а ещё два стартапа в акселераторе купили похожие инструменты с другими настройками. В итоге в портфеле появляются дублирующиеся расходы, разные условия и никакой общей записи о том, кто и что одобрил.

Ситуация ухудшается ещё и потому, что AI-инструменты сначала становятся личными, а уже потом корпоративными. Маркетолог может купить инструмент с личной карты. Разработчик может подключить его к репозиторию. Основатель может загрузить таблицу поздно ночью во время теста. Никто не стремится создать риск, но в портфеле всё равно оказываются разные поставщики, слабый контроль и данные клиентов в местах, где их никто не планировал хранить.

Именно поэтому политика по AI для портфеля нужна заранее. Проблема не в том, что стартапы быстро двигаются. Проблема в том, что покупка, тестирование и обмен данными происходят десятками маленьких шагов, за которые никто не отвечает на уровне всего портфеля.

Быстрое внедрение — это нормально. Незаметное внедрение — вот где начинают расти и расходы, и риск.

Какие правила должен соблюдать каждый стартап

Хорошая политика по AI для портфеля начинается с нескольких простых правил. Они не должны замедлять команды. Их задача — остановить привычный хаос: дублирующиеся подписки, личные логины, случайные загрузки данных и счета, которые замечают только в конце месяца.

В каждом стартапе должен быть один человек, который утверждает новые AI-инструменты. Назначайте одного владельца, а не комитет. На ранней стадии это может быть основатель, CTO или fractional CTO. В более крупной команде это может быть руководитель разработки или операционный лидер. Один ответственный даёт людям понятный маршрут и сохраняет единообразие решений.

Команды должны использовать только корпоративные аккаунты. Личные аккаунты быстро создают проблемы. Компания теряет видимость того, какими инструментами пользуются сотрудники и что они туда загружают. Когда человек уходит, его промпты, файлы и история оплаты могут уйти вместе с ним. Корпоративная почта, корпоративная оплата и общий административный доступ должны быть стандартом с первого дня.

Прежде чем кто-то что-то загрузит, нужно понять, к какому типу данных это относится. Публичный текст с сайта — это одно. Списки клиентов, контракты, исходный код, финансовые отчёты и журналы обращений — совсем другое. Хорошо работает простое правило: если человек не может сразу сказать, какие именно данные он собирается загрузить, ему нужно остановиться и спросить.

Для новых инструментов нужна короткая письменная заметка. Без лишней бюрократии. Какую задачу решает инструмент? Кто будет им пользоваться? Какие данные в него попадают? Стартап заменяет другой сервис или просто добавляет ещё один? Такая маленькая привычка помогает отсечь расплывчатые просьбы вроде «давайте попробуем, потому что все так делают». Она же помогает легко увидеть пересечения между несколькими стартапами.

Расходы тоже должны попадать в точку проверки. Командам можно оставлять пространство для небольших тестов, но как только инструмент переходит заданный месячный порог, кто-то должен его пересмотреть. Конкретная сумма зависит от стадии компании, но правило должно быть одинаковым по всему портфелю. Десять стартапов, каждый из которых немного тратит на похожие инструменты, быстро превращаются в большой и запутанный счёт.

Эти правила работают потому, что им легко следовать. SaaS-стартап, health-стартап и онлайн-ритейл-компания могут использовать разные инструменты, но правила покупки и работы с данными могут оставаться почти одинаковыми. Так accelerator AI governance получает понятную базу без того, чтобы заставлять все компании жить по одной и той же стековой модели.

Разделите данные на простые уровни доступа

Если на все файлы навешивать одну и ту же метку, люди начинают гадать. А догадки ведут к рискованным загрузкам и медленным согласованиям. Политика по AI для портфеля работает лучше, когда в каждом стартапе используют одни и те же четыре уровня данных и один и тот же простой язык.

Четыре уровня доступа

Уровень 1 — публичный. Сюда относятся опубликованные статьи в блоге, открытая продуктовая документация, вакансии, пресс-релизы и тексты на сайте. Команды могут вставлять это в большинство одобренных AI-инструментов, потому что риск раскрытия здесь низкий.

Уровень 2 — внутренний. Это дорожные карты, заметки со встреч, черновики цен, скрипты продаж и продуктовые планы, которые остаются внутри компании. Сотрудники могут использовать их только в одобренных инструментах, если инструмент не обучается на данных компании и если стартап разрешил такое использование.

Уровень 3 — ограниченный. Здесь уже начинаются данные клиентов, а вместе с ними тикеты поддержки, выгрузки по использованию, счета, журналы безопасности и любые файлы, по которым можно определить человека, аккаунт или сделку. Командам следует использовать только одобренные инструменты с контролем доступа и журналами. Во многих случаях лучше брать замаскированные или тестовые данные.

Уровень 4 — закрытый. Сюда относятся контракты, исходный код, HR-файлы, payroll-данные, материалы для совета директоров, приватные ключи, секреты и документы по сделкам M&A. Базовое правило должно быть очень простым: не загружайте это во внешние AI-инструменты, если только стартап не выдал письменное исключение и не назначил ответственного.

Граница между внутренними планами и данными клиентов должна оставаться чёткой. Черновик меморандума о выходе на новый рынок — это внутренний документ. Таблица с именами клиентов, суммами, датами продления и историей обращений — это ограниченные данные. Люди часто путают эти вещи, потому что оба типа информации живут в обычных рабочих документах, но риск у них совсем разный.

Понятные примеры помогают лучше, чем юридические формулировки. Если основатель спрашивает: «Можно я вставлю это в AI-ассистент?», метка должна быстро дать ответ.

Командам также стоит держать короткий список того, что «никогда не загружать»:

• пароли, API-ключи, токены и приватные сертификаты
• полные выгрузки клиентов с именами, email, телефонами или платёжными данными
• оценки сотрудников, данные о компенсациях и документы по отпускам
• неподписанные контракты, материалы для совета директоров или условия раунда
• production-исходный код или дампы баз без письменного разрешения

Делайте эти метки видимыми там, где идёт работа. Добавьте их в шаблоны файлов, общие папки и формы запроса на AI-инструмент. Если человек не может распределить документ по уровню за 10 секунд, политика слишком сложная.

Как запустить это за 30 дней

Месяца достаточно, чтобы навести порядок, если первая версия останется небольшой. Не начинайте с длинного документа и медленного юридического круга. Начните с одного ответственного, одной общей таблицы и одного правила: новый AI-инструмент нельзя добавлять, пока кто-то не назовёт пользователя, плательщика и данные, которые будут использоваться.

Если в вашем акселераторе нет внутреннего технического лидера, назначьте одного человека, который будет вести этот процесс 30 дней. Должность важна меньше, чем реальная ответственность. Это может делать fractional CTO, но должен быть один конкретный человек, который собирает ответы и принимает решения.

Недели 1 и 2

На первой неделе попросите каждый стартап перечислить все используемые AI-инструменты. Сюда входят чат-приложения, ассистенты для программирования, боты для встреч, инструменты для дизайна, сервисы поддержки и прямое использование API. Не полагайтесь только на память основателя. Проверьте списания по картам, отчёты о расходах и общие корпоративные почтовые ящики, куда приходят уведомления о продлении.

По каждому инструменту зафиксируйте, какой стартап и какая команда им пользуются, кто за него платит, сколько людей его используют, какую задачу он решает и какие данные в него попадают.

Обычно этот шаг быстро показывает, где проблема. У одного стартапа может быть два инструмента для текстов, у другого — три бота для встреч, а третий может использовать личные аккаунты для помощи с кодом. Нельзя справиться с расползанием AI-инструментов, пока вы не видите полную картину.

На второй неделе сгруппируйте инструменты по задачам и уберите пересечения. Если несколько стартапов используют разные инструменты для одной и той же простой задачи, выберите один вариант по умолчанию. Оставьте второй только тогда, когда у команды есть понятная причина, например, требование по контракту или функция, которой нет в стандартном инструменте.

Недели 3 и 4

К третьей неделе напишите короткую AI-политику для всего портфеля. Для первой версии достаточно одной страницы. В ней должно быть указано, какие инструменты одобрены по умолчанию, какие типы данных нельзя отправлять в публичные инструменты, кто может выдавать исключения и как долго действует такое исключение.

Сразу приложите короткую форму на исключение. Сделайте её простой, чтобы основатели действительно ею пользовались. Спросите название инструмента, зачем он нужен, какие данные туда попадут и когда наступает следующее продление.

На последней неделе сопоставьте реальное использование с датами продления. Отмените инструменты, которыми никто не пользуется. Объедините дублирующиеся места. Переведите работу с неутверждённых приложений до следующего биллингового цикла.

Ежемесячная проверка может оставаться простой: продлить инструмент как есть, включить его в стандартный стек, ограничить одной командой или отменить. Этого достаточно, чтобы превратить набор хаотичных привычек стартапов в рабочий процесс закупки AI-инструментов.

Первый месяц не сделает систему идеальной. Но он остановит дальнейшее распространение случайных покупок и рискованных загрузок.

Простой пример с тремя стартапами

Представьте акселератор с тремя компаниями, которые покупают AI-инструменты на свои карты. Никто не собирается создавать беспорядок. Он появляется, когда каждая команда решает сегодняшнюю проблему, не видя остальную часть портфеля.

Первая компания — SaaS-стартап. Его support-команда хочет отвечать быстрее, поэтому использует AI для черновиков ответов на основе прошлых тикетов и справки. Обычно это сценарий с низким риском, если команда убирает платёжные данные, пароли и всё, что связано с приватным клиентским аккаунтом.

Вторая компания работает в сфере health. Основатели тестируют AI-сводки для заметок на входе и внутренних обновлений. На первый взгляд инструмент полезен, но линия по приватности здесь гораздо жёстче. Даже короткая заметка может содержать персональные медицинские данные, поэтому стартап не может просто вставить сырые записи в универсальный инструмент только потому, что функция удобна.

Третья компания продаёт товары онлайн. Её маркетинговая команда за два месяца покупает пять инструментов для текстов: для описаний товаров, рекламных объявлений и тем писем. Все пять делают почти одно и то же. У команды теперь пять счетов, пять наборов промптов и нет понятного ответа, куда ушли данные о продукте.

Один общий набор правил решает большую часть проблем, не тормозя людей. Публичный и низкорисковый внутренний контент можно загружать в одобренные AI-инструменты. Данные клиентов, финансовые, медицинские, юридические и контрактные документы по умолчанию должны оставаться вне открытых инструментов. Каждый стартап должен выбрать один инструмент для текстов и один универсальный ассистент, если только нет явного пробела. Основатели должны заносить новые AI-покупки в один простой реестр, а назначенный ответственный должен утверждать исключения и пересматривать их каждый месяц.

Теперь все три стартапа по-прежнему могут использовать AI, но делают это с разумными ограничениями. Команда SaaS продолжает черновики ответов в поддержке, потому что данные контролируются. Health-стартап переходит на замаскированные тестовые примеры и запрашивает отдельную проверку перед работой с реальными записями. Онлайн-ритейл-компания убирает четыре инструмента и оставляет один, потому что пересечения становятся очевидны, когда кто-то их проверяет.

При этом правила всё ещё оставляют место для исключений. Если health-стартап найдёт инструмент, созданный для более строгой работы с данными, он может попросить согласование и объяснить, зачем он нужен. Если онлайн-ритейл-команда докажет, что один дополнительный инструмент экономит шесть часов в неделю и делает то, чего другие не умеют, они могут его оставить.

Вот как выглядит практичная политика по AI для портфеля. Она не запрещает AI. Она останавливает случайные покупки, рискованные загрузки и дублирующиеся инструменты, при этом оставляя каждой компании пространство для обоснования.

Ошибки, которые создают расползание инструментов

Расползание инструментов обычно начинается с обычных решений. Основателю нужна помощь с письмами для продаж, подрядчику — более быстрые заметки, а тимлид тестирует AI-ассистента для программирования. Никто не планирует создавать риск, но несколько отдельных регистраций по всему портфелю быстро превращаются в дублирующиеся расходы, неясные потоки данных и инструменты, которые никто полностью не отслеживает.

Первая ошибка — позволить каждому основателю покупать в одиночку. Это кажется быстрым, но ломает любой общий стандарт. Один стартап принимает слабые условия, другой платит за инструмент, который делает ту же работу, что и уже одобренный сервис, а третий даёт слишком широкий доступ к клиентским файлам просто ради пилота. Политика по AI для портфеля должна замедлять процесс ровно настолько, чтобы задать три вопроса: кто владеет инструментом, какие данные туда попадают и когда будет проверка.

Личные аккаунты только усугубляют хаос. Когда люди используют личные AI-логины для работы компании, стартап теряет контроль над промптами, файлами и историей чатов. Если человек уходит, вместе с ним уходит и работа. Команда также не может проверить, какие данные попадали в инструмент и кто ещё может их видеть.

Короткие пилоты часто становятся постоянными случайно. Команды говорят, что просто тестируют инструмент, а потом никто не ставит дату окончания и не проверяет расходы. Через шесть месяцев стартап всё ещё за него платит, люди используют его каждый день, и никто не знает, должен ли он остаться.

Расширения для браузера и другие теневые инструменты тоже создают проблемы, потому что кажутся безобидными. Они дешёвые, легко ставятся и часто обходят обычное согласование. Некоторые из них могут читать страницы, письма, документы или данные CRM прямо в браузере. Из-за этого они становятся одним из самых простых способов отправить чувствительные данные туда, куда компания никогда не давала разрешения.

Сигналы риска хорошо знакомы. Команды не могут назвать все AI-инструменты, которыми пользовались на этой неделе. Сотрудники загружают файлы компании через личные аккаунты. У пилотов нет владельца, цели или даты проверки. Расширения для браузера обходят согласование программного обеспечения. Бывшие сотрудники или подрядчики всё ещё имеют AI-логины или доступ к API.

Доступ должен закрываться в день окончания работы. Это касается общих рабочих пространств, API моделей, браузерных инструментов, ботов для встреч и любых сохранённых токенов в скриптах или автоматизациях. Если акселераторы игнорируют offboarding, старые аккаунты остаются активными месяцами. Один чистый список доступа, которым управляет ops или fractional CTO, обычно решает больше проблем, чем ещё один новый инструмент.

Быстрые проверки для команд акселератора

Короткая еженедельная проверка помогает заметить большинство проблем с политикой до того, как они превратятся в лишние траты или в беспорядок с данными. Если акселератор поддерживает несколько стартапов, маленькие пробелы быстро распространяются. Один основатель покупает инструмент для текстов на карте, другая команда загружает звонки клиентов в бот для встреч, а finance видит расходы только после накопления продлений.

Проверка должна быть простой намеренно. Задавайте одни и те же вопросы каждую неделю и задавайте их каждому стартапу одинаково. Хорошая политика по AI для портфеля должна делать эти проверки достаточно лёгкими, чтобы их мог провести ops-лид, финансовый менеджер или венчурный партнёр за 10 минут.

Может ли кто-то назвать все оплачиваемые AI-инструменты, использованные на этой неделе, а не только те, что оформлены на годовой контракт? Знает ли каждая команда, какие данные никогда нельзя отправлять в публичную модель, например данные клиентов, контракты, заметки для совета директоров или исходный код? Есть ли у каждого инструмента один владелец, который утверждает доступ, отслеживает использование и знает дату продления? Может ли finance сопоставить каждый счёт или списание по карте с инструментом, который действительно был одобрен под конкретную задачу? Когда кто-то уходит, удаляет ли стартап его доступ в тот же день и из AI-инструмента, и из данных за ним?

Если на любой из этих вопросов команда отвечает «возможно», считайте это живой проблемой. «Возможно» обычно означает, что никто ей не владеет. И это также значит, что обзор портфеля слабее, чем кажется на бумаге.

Простой пример показывает, почему это важно. Startup A покупает два AI-инструмента для программирования, Startup B использует бота для sales calls, а Startup C даёт стажёрам попробовать бесплатный чат-бот для исследований. Ни одно из этих решений не выглядит драматично. Но если никто не отслеживает владельцев, продления, правила загрузки и увольнение, вы получаете дублирующиеся расходы, неизвестное раскрытие данных и бывших сотрудников, у которых доступ сохраняется неделями.

Finance часто быстрее всех замечает проблему. Если списания продолжают появляться под общими названиями и никто не может объяснить их в одной фразе, значит, инструмент, скорее всего, прошёл мимо согласования. Журналы доступа — ещё один быстрый сигнал. Если основатель не может подтвердить, кто потерял доступ после ухода сотрудника, значит, процесс увольнения ещё не работает.

Проводите такую проверку каждый пятничный день в течение месяца. Сохраняйте результаты в одной общей таблице по всему портфелю. Через четыре недели закономерности становятся очевидны: какие стартапы покупают слишком много инструментов, кому нужны более чёткие правила по данным и какие команды требуют помощи до следующего цикла продлений.

Следующие шаги для политики на весь портфель

Начните со стартапов, которые уже больше всех тратят на AI-инструменты или работают с наиболее чувствительными данными. Обычно именно они создают больше всего риска и быстрее всего показывают, где в правилах есть дыры. Если пытаться начать сразу со всех компаний, вы потратите недели на сбор крайних случаев и всё равно можете не увидеть настоящую проблему.

Хороший первый шаг очень простой. Выберите пять-десять стартапов, посмотрите на их текущие инструменты и задайте три понятных вопроса: кто может купить новый инструмент, какие данные можно в него загружать и кто может согласовать исключение. Так вы получите рабочий черновик, а не красивую презентацию, которой никто не пользуется.

Используйте один общий шаблон для всего портфеля. Сделайте его достаточно коротким, чтобы основатель мог прочитать его за десять минут и применить в тот же день. В нём должны быть правила покупки и согласования продления, уровни доступа к данным и правила загрузки, запросы на исключение с назначенным согласующим и датой окончания, а также базовый журнал того, кто что утвердил.

Один шаблон важен потому, что стартапы копируют друг друга. Если у одной компании правило мягкое, а у другой жёсткое, люди будут искать более лёгкий путь. Так расползание AI-инструментов и распространяется по акселератору.

Планируйте первую проверку заранее, а не потом. Лучшее время обновить политику по AI для портфеля — сразу после первого реального инцидента, неудачного аудита или почти случившейся ошибки. Люди помнят, что произошло, и политику можно менять на основе фактов, а не догадок. Квартальная проверка тоже подходит, но первая по-настоящему полезная проверка обычно появляется после конкретной ошибки.

Некоторые основатели будут сопротивляться, обычно потому, что не хотят лишнего процесса. Именно здесь помогает нейтральный оператор. Fractional CTO может посмотреть на несколько стартапов сразу, увидеть закономерности и сделать правила достаточно практичными, чтобы команды действительно им следовали.

Если вам нужна внешняя помощь, Oleg Sotnikov на oleg.is работает со стартапами как fractional CTO и советник по внедрению AI, выбору инструментов, инфраструктуре и рабочим правилам. Такая поддержка особенно полезна, когда портфелю нужен один практичный стандарт без превращения всего процесса в тяжёлый административный проект.

Если после прочтения вы примете только одно решение, пусть оно будет небольшим: выберите первую группу стартапов, дайте им один шаблон и назначьте дату проверки, привязанную к первому реальному тесту. Этого достаточно, чтобы превратить разрозненное использование инструментов в систему правил, которой действительно можно следовать.