Шесть вещей, которые стоит сделать сразу, даже если у вас маленький стартап, экспериментальный проект и пока нет бюджета на отдельного специалиста.
Если вы строите продукт с компонентом ИИ, вам не нужно с первого дня создавать тяжёлую систему соответствия требованиям. Но вам уже нужно заложить минимальную рабочую основу управления: понять, где именно в продукте используется ИИ, кто за это отвечает, на чём держится система, какие у неё ограничения и как команда принимает решения о выпуске новых функций.
Хороший старт в 2026 году — это не папка политик и не попытка играть в большую корпорацию. Это несколько простых правил, которые помогают не потерять контроль над продуктом на раннем этапе и не переделывать всё заново, когда появятся клиенты, инвесторы, рынок ЕС или первые серьёзные вопросы по рискам и надёжности.
Коротко: главный смысл статьи
На раннем этапе вам не нужна большая программа управления. Вам нужен минимальный контур, который даёт команде управляемость.
Это означает шесть простых вещей:
- один ответственный;
- понятный список функций, где используется ИИ;
- понимание, что у вас своё, а что зависит от внешнего поставщика;
- простые правила выпуска;
- порядок в данных и журнале решений;
- фиксация ошибок, ограничений и инцидентов.
Этого недостаточно, чтобы «закрыть тему навсегда». Но этого достаточно, чтобы потом не перестраивать продукт с нуля.
Почему эта тема уже актуальна в 2026 году
В 2026 году больше нельзя исходить из логики «сначала построим продукт, а управление добавим потом». EU AI Act уже действует. Требование обеспечивать достаточную готовность персонала к работе с ИИ применяется с 2 февраля 2025 года. Правила для моделей общего назначения — с 2 августа 2025 года. Основная масса положений регламента начинает применяться с 2 августа 2026 года.
Но даже до формального давления вопрос обычно приходит раньше — в более приземлённой форме. Клиент спрашивает, как устроен ваш ИИ-компонент. Инвестор хочет понять, насколько продукт управляем. Команда сама перестаёт понимать, где заканчивается внешний инструмент и начинается собственная система. Именно поэтому на раннем этапе нужна не большая программа, а рабочий управленческий минимум.
Для кого эта статья
Она полезна, если вы:
- запускаете стартап с ИИ-компонентом;
- строите небольшой экспериментальный продукт;
- используете внешние модели через API и оборачиваете их в собственную логику;
- пока не можете позволить себе отдельную функцию по вопросам соответствия требованиям;
- хотите сделать первые шаги правильно, но без лишней тяжести.
Что этот минимум даёт на практике
Если сделать всё правильно, у команды появится не «полная система соответствия требованиям», а гораздо более полезная вещь — рабочая управленческая основа.
После этого вы сможете ответить на базовые вопросы:
- где именно в продукте используется ИИ;
- кто отвечает за конкретную функцию;
- что зависит от внешнего поставщика, а что контролируете вы сами;
- какие у системы известные ограничения;
- на каком основании используются данные;
- как принимается решение о выпуске новых функций;
- что делать, если что-то идёт не так.
Именно это потом позволяет без хаоса перейти к следующему уровню зрелости.
1. Сразу назначьте одного ответственного
Даже если вас двое или трое, должен быть один человек, который удерживает общую рамку: где именно в продукте используется ИИ, какие функции можно выпускать, где уже есть повышенный риск, а когда нужно остановиться и пересмотреть решение.
Это не означает, что этот человек делает всё сам. Это означает, что в команде есть владелец темы. Пока такого владельца нет, вопросы управления почти всегда расползаются между разработкой, продуктом и операционной работой — и в итоге не принадлежат никому.
На этом этапе достаточно зафиксировать очень простую вещь: имя, зона ответственности и кто принимает решение в нестандартной ситуации.
2. Запишите, где именно у вас используется ИИ
Не нужно строить сложную карту архитектуры. Для начала достаточно простого реестра — таблицы или текстового файла — с ответами на несколько вопросов по каждой функции:
- что делает эта функция;
- кто её использует;
- на что влияет её результат;
- какая модель или внешний сервис лежит внутри;
- кто в команде за неё отвечает.
Это нужно не для отчётности, а для вас самих. Если у команды нет такого списка, она не управляет системой — она просто надеется, что помнит её устройство.
Реестр также защищает от другой типичной проблемы: когда кто-то из команды уходит, вместе с ним уходит и понимание того, как устроена конкретная функция.
3. Поймите, что у вас своё, а что зависит от внешнего поставщика
Это один из самых недооценённых вопросов на раннем этапе.
Многие небольшие команды рассуждают так: «Мы просто используем внешнюю модель, значит это не наша зона ответственности». На практике всё обычно сложнее. Вы можете использовать внешнюю модель, но при этом встроить её в собственный продукт, изменить сценарий использования, подключить свои данные, задать свои ограничения и превратить её в часть собственной логики.
С самого начала стоит письменно ответить хотя бы на три вопроса:
- мы строим свою систему или встраиваем чужую;
- мы меняем поведение модели или только используем её как внешний слой;
- что мы реально контролируем, а что зависит от поставщика.
Это особенно важно для продуктов на внешних API. Даже если вы не разрабатываете модель сами, у вас всё равно появляется собственная управленческая зона ответственности — потому что именно вы определяете сценарий, интерфейс, данные, ограничения и бизнес-контекст использования.
4. Не запускайте функцию без простых правил выпуска
У каждой функции с ИИ должен быть минимальный выпускной барьер. Не комитет и не многоуровневое согласование, а короткий список вопросов, на которые команда отвечает перед запуском:
- зачем эта функция нужна;
- где и как она может ошибаться;
- какие ограничения известны уже сейчас;
- кто проверил результат на реальных примерах;
- можно ли быстро отключить функцию, если что-то пойдёт не так.
Это и есть тот минимальный слой управления, который действительно работает на раннем этапе. Не «сначала выпустить, а потом думать о рисках», а заранее определить рамку выпуска.
Если вы работаете с генеративной моделью или внешним агентом, к этому же минимуму нужно добавить ещё один вопрос: какие действия система может выполнять самостоятельно, а какие должны требовать подтверждения человека.
Ваша ответственность vs ответственность поставщика (Инфографика)
5. Сразу наведите порядок в данных и журнале решений
Вам не нужен большой каталог данных. Но вам нужно понимать хотя бы основное:
- откуда берутся данные;
- зачем вы их используете;
- есть ли основания использовать их именно для этой задачи;
- кто это одобрил;
- где это зафиксировано.
Отдельно должен появиться журнал принятых решений: что меняли в системе, когда, кто утвердил и почему было принято именно такое решение.
Это не формальность. Через несколько месяцев именно этот журнал помогает понять, почему система ведёт себя так, а не иначе, и в какой момент возникла проблемная настройка.
6. Логируйте проблемы, ограничения и инциденты
Минимальное управление начинается не тогда, когда система идеальна, а тогда, когда команда умеет замечать сбои и не повторять одни и те же ошибки.
На раннем этапе достаточно трёх простых журналов:
- журнал изменений;
- журнал ошибок и инцидентов;
- список известных ограничений.
Этого уже достаточно, чтобы система перестала быть непрозрачным механизмом, который живёт своей жизнью.
Особенно важен список известных ограничений. Для продуктов на базе больших языковых моделей одна из самых распространённых ошибок состоит в том, что известные слабости системы остаются в голове у одного разработчика, а не фиксируются в общедоступном месте. Когда этот человек занят другим или уходит из команды, вместе с ним уходит и понимание того, где у системы края.
Что у вас должно появиться за один-два дня
Если перевести всё вышесказанное в очень практический формат, то за первый короткий цикл у команды должны появиться:
- один ответственный;
- таблица с функциями ИИ;
- короткая записка о внешних моделях и поставщиках;
- простые правила выпуска;
- журнал данных и решений;
- журнал ошибок и известных ограничений.
Это уже рабочая основа. Не идеальная. Не полная. Но достаточная для старта.
Что этот минимум не заменяет
Этот слой не заменяет:
- полноценную оценку применимости EU AI Act;
- разбор роли компании в цепочке поставки;
- классификацию уровня риска;
- формальную документацию для зрелой B2B-продажи;
- полноценную систему управления рисками.
Именно поэтому важно не переоценивать этот стартовый набор. Его задача — дать команде управляемость, а не создать иллюзию, что все вопросы уже закрыты.
Когда этого уже недостаточно
Минимальный контур перестаёт быть достаточным, когда появляется хотя бы один из следующих признаков:
- продукт идёт на рынок ЕС;
- приходит вопрос от клиента, партнёра или инвестора;
- в архитектуре несколько ИИ-функций и внешних поставщиков;
- у вас несколько юрлиц или сложная роль в цепочке поставки;
- есть сомнение по уровню риска;
- команда больше не может удерживать картину одной таблицей и несколькими короткими документами.
В этот момент уже полезен следующий шаг — не внутренняя импровизация, а структурированная оценка готовности: применимость, роли, вероятные обязанности и приоритеты.
Заключение
Главная ошибка маленьких команд — думать, что управление системами ИИ начинается только тогда, когда появляется бюджет, юрист или первый крупный клиент. На самом деле оно начинается намного раньше — в тот момент, когда вы впервые встраиваете ИИ в продукт и говорите себе: «Потом разберёмся».
В 2026 году такой подход уже слишком дорого обходится. Но и другая крайность — строить тяжёлую систему заранее — тоже не нужна.
Разумный путь выглядит так: с первого дня зафиксировать шесть базовых вещей, которые дают продукту управляемость. Не идеальность. Не полный контур соответствия требованиям. Не закрытие всех рисков. А именно управляемость — способность команды понимать, что происходит с системой, и принимать осознанные решения.
Для стартапа или небольшого экспериментального проекта это, как правило, лучший возможный старт.
Оценка готовности к EU AI Act
Если у вас уже есть продукт с ИИ-компонентом, внешний API внутри продукта, первые B2B-разговоры или планы по рынку ЕС, следующим разумным шагом становится оценка готовности. Это короткая диагностическая работа, помогающая понять: относится ли регуляция к вашей ситуации, какую роль вы занимаете и где зоны риска.
Запросить оценку готовности к EU AI ActЕсли удобнее сначала коротко описать ситуацию — можно перейти на страницу контакта.
Источники
Частые вопросы
Нужно ли маленькому стартапу сразу строить полноценную систему соответствия требованиям?
Нет. На раннем этапе команде обычно нужна не большая система соответствия требованиям, а минимальный управленческий контур: один ответственный, реестр функций ИИ, простые правила выпуска, журнал решений и понятные границы использования. Полноценный следующий этап нужен позже — когда появляется рынок ЕС, корпоративные клиенты, пограничные вопросы по ролям и уровню риска или более сложная архитектура продукта.
Мы используем внешний API. Это всё равно считается нашей задачей?
Да. Использование внешней модели или API не снимает вопрос автоматически. Если вы встраиваете такую модель в продукт, задаёте конкретный сценарий использования, добавляете свои данные, ограничения и интерфейс для клиентов, у вас появляется собственная управленческая зона ответственности. Именно поэтому с первого дня полезно разделять: что вы контролируете сами, а что зависит от поставщика.
Сколько времени занимает такой минимальный старт?
Для небольшой команды с одной-двумя функциями ИИ минимальный старт обычно занимает от нескольких часов до одного-двух рабочих дней. Речь идёт не о большом проекте, а о нескольких зафиксированных решениях и простых рабочих документах, которые потом можно усиливать по мере роста продукта.
Когда уже нужен следующий шаг в виде оценки готовности к EU AI Act?
Следующий шаг нужен тогда, когда вопрос перестаёт быть внутренним и становится внешним или регуляторным: продукт идёт на рынок ЕС, приходит вопрос от клиента или инвестора, в продукте несколько ролей или юрлиц, используется внешний AI-стек с непонятным распределением ответственности или есть сомнение по уровню риска. В этот момент уже полезна не только внутренняя дисциплина, но и структурированная оценка применимости, ролей и вероятных обязанностей.