EU AI Act для малого и среднего бизнеса: практический план управления

EU AI Act может звучать как проблема лабораторий моделей, банков, производителей медицинских устройств и государственных органов. Отчасти это правда. Самые тяжелые обязательства ложатся на поставщиков high-risk систем и поставщиков general-purpose AI models.

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

Эта статья - практический план governance для SME. Это не юридическая консультация. Это операционная система, которая должна быть до того, как legal review станет дорогим.

Сначала относитесь к готовности к AI Act как к задаче операционной инвентаризации. Если вы не можете перечислить AI-системы, поставщиков, пользователей, категории данных, влияние на решения и правила human oversight, вы не готовы классифицировать риск или доказывать ответственное использование.

Важная временная шкала

По состоянию на 17 мая 2026 года EU AI Act применяется поэтапно. Официальная временная шкала Европейской комиссии говорит, что акт вступил в силу 1 августа 2024 года. Запрещенные практики и обязательства по AI literacy начали применяться с 2 февраля 2025 года. Правила governance и обязательства для general-purpose AI models стали применимы 2 августа 2025 года. Правила прозрачности применяются с 2 августа 2026 года.

Сроки для high-risk систем двигались из-за пакета упрощений Digital Omnibus. Текущая страница Комиссии по AI Act говорит, что после политического соглашения 7 мая 2026 года правила для систем в отдельных high-risk областях, таких как биометрия, критическая инфраструктура, образование, занятость, миграция, убежище и пограничный контроль, применяются с 2 декабря 2027 года, а high-risk системы, встроенные в регулируемые продукты, применяются с 2 августа 2028 года.

Используйте эти даты как входные данные для планирования, а не как замену юридического подтверждения. Практический вывод для SME проще: начинайте сейчас, потому что инвентаризация, ownership, документация и human oversight требуют времени.

Поставщик, deployer или покупатель?

Большинство SME не обучают frontier models. Обычно они находятся в одной из трех ролей:

| Роль | Что это значит | Пример SME | Практическая обязанность | | --- | --- | --- | --- | | Покупатель | Вы покупаете инструмент с AI-функциями | CRM-ассистент, meeting summarizer, coding assistant | Vendor due diligence и внутренние правила использования | | Deployer | Вы вводите AI-систему в работу бизнеса | Support triage, lead scoring, HR screening workflow | Oversight, monitoring, disclosure, records | | Поставщик | Вы выводите AI-систему на рынок под своим именем | AI chatbot product, scoring API, отраслевой инструмент | Product compliance, technical documentation, risk management |

Можно быть больше чем одним. Компания, которая покупает model API, оборачивает его в отраслевой продукт и продает клиентам, вероятно, больше чем покупатель. Компания, которая использует SaaS-chatbot внутри, обычно deployer или user, в зависимости от use case.

Не угадывайте это на встрече. Поместите каждую AI-систему в inventory и классифицируйте роль.

Постройте AI inventory

Начните с таблицы. Каждая AI-система получает одну строку:

| Поле | Почему важно | | --- | --- | | Название системы | Людям нужна общая метка | | Поставщик или владелец | Кто-то должен отвечать на вопросы | | Бизнес-цель | Риск зависит от intended use | | Пользователи | Внутренние сотрудники, клиенты, кандидаты, публика | | Категории данных | Public, internal, personal, confidential, restricted | | Использование вывода | Черновик, рекомендация, automated decision, customer-facing answer | | Human oversight | Кто проверяет и когда | | Disclosure | Сообщают ли людям, что они взаимодействуют с AI | | Logs | Какие доказательства остаются после использования | | Risk rating | Low, limited, possible high-risk, prohibited/not allowed |

Эта инвентаризация ценнее политики, которую никто не читает. Она показывает, где AI реально существует в компании.

Классифицируйте практический риск

Не начинайте с вопроса "это high-risk по Annex III?". Начните с операционного влияния:

Low-risk assistance. Черновики писем, резюме внутренних встреч, brainstorming, редактирование текста. Человек использует вывод как черновик. Применяются обычные правила приватности.

Limited-risk interaction. Chatbots, voice agents, AI-generated media, публичный текст или ответы поддержки. Важны disclosure и ясность для пользователя.

Decision-support workflows. Lead scoring, маршрутизация поддержки, обработка счетов, quality review, fraud flags. Важны human oversight, monitoring и пути обжалования.

Потенциальные high-risk области. Занятость, образование, кредит, essential services, healthcare, law enforcement, migration, critical infrastructure, biometric categorization. Перед внедрением нужен legal review.

Не разрешено без явного legal/security approval. Emotion inference в чувствительных контекстах, manipulative systems, social scoring, workplace surveillance patterns или системы, которые могут materially affect rights без proper safeguards.

Это не финальная юридическая классификация. Это triage, который показывает, где нужен экспертный review.

Минимальные SME governance controls

Для каждой нетривиальной AI-системы требуйте шесть контролей:

1. Owner. Один названный человек или команда отвечает за систему.
2. Use boundary. Для чего систему можно и нельзя использовать.
3. Data rule. Какие данные могут входить в систему.
4. Human oversight. Какие выводы требуют проверки до действия.
5. Monitoring. Как замечаются ошибки, жалобы, drift и изменения поставщика.
6. Record. Какие evidence хранятся: vendor docs, prompts, settings, approvals, logs, test results.

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

Проверка поставщика

Для vendor tools спрашивайте доказательства, а не обещания:

• Используются ли customer data для обучения по умолчанию?
• Где данные обрабатываются и хранятся?
• Какие retention controls существуют?
• Есть ли enterprise settings для training opt-out, logging, SSO и access control?
• Предоставляет ли поставщик документацию по AI Act, GDPR, security и subprocessors?
• Можно ли отключить или ограничить AI-функцию?
• Раскрывает ли поставщик model providers и крупные architecture changes?
• Что происходит, если поставщик меняет model, prompt или retrieval behavior?

Если поставщик не может ответить на эти вопросы по инструменту, который будет обрабатывать клиентские, сотруднические или конфиденциальные данные, держите use case low-risk или выберите другой инструмент.

Disclosure и human oversight

Для customer-facing AI disclosure должно быть простым и видимым. Если клиент говорит с AI-chatbot или voice agent, скажите об этом. Если AI-generated text отправляется человеком после review, внутренняя политика должна решить, требуется ли disclosure для этого канала.

Human oversight должен быть конкретным. "Human in the loop" недостаточно. Определите:

• какой output видит человек;
• какие source evidence он может проверить;
• может ли он override или reject;
• сколько времени у него есть;
• логируется ли approval;
• что происходит, если человек не согласен с системой.

Oversight без полномочий - театр. Если человек не может остановить действие, это не meaningful oversight.

30-дневное внедрение для SME

Неделя 1: Inventory. Перечислите все AI tools и workflows. Включите unsanctioned tools, которыми люди реально пользуются.

Неделя 2: Risk triage. Классифицируйте low, limited, decision-support, possible high-risk или not allowed. Эскалируйте possible high-risk.

Неделя 3: Controls. Добавьте owner, data rule, oversight rule, disclosure rule, logging rule и vendor evidence для каждой активной системы.

Неделя 4: Policy and training. Опубликуйте короткую внутреннюю AI use policy и проведите 45-минутную командную сессию. Фокус на практических примерах, не на юридической теории.

Этого достаточно, чтобы перейти от ad hoc AI use к governed AI use.

Пока не делайте этого

Не покупайте compliance platform до inventory. Она автоматизирует путаницу.

Не позволяйте каждому отделу писать свою AI policy. Централизуйте baseline, а затем разрешайте department-specific rules.

Не считайте vendor terms governance. Договор с поставщиком не говорит sales team, что можно вставлять в модель.

Не ждите идеальной regulatory certainty. Сроки и guidance могут двигаться, но inventory, ownership, data rules, oversight и logging все равно будут нужны.

Итог

AI Act readiness для SME - не панический проект. Это привычка governance.

Начните с inventory. Классифицируйте риск по use case. Оставляйте людей ответственными за meaningful decisions. Требуйте vendor evidence. Документируйте controls. Эскалируйте employment, credit, health, education, essential services, biometric и rights-impacting uses до запуска.

Если вы это сделаете, вы будете впереди большинства компаний. Что важнее, ваши AI-системы будет проще понимать, безопаснее эксплуатировать и легче защищать перед клиентами.