Чому серпень 2026 — це реальний дедлайн
EU AI Act набрав чинності в серпні 2024. Положення про заборонені практики почали діяти у лютому 2025. Зобов'язання щодо general-purpose AI models почалися в серпні 2025. А повний набір вимог до high-risk систем стає примусово виконуваним 2 серпня 2026. Це дата, на яку більшість продуктових команд мають звертати увагу, бо вона накладає найбільший інженерний тягар.
Ця стаття — не юридична порада. Для цього у нас є юристи; і у вас мають бути. Те, що вона охоплює — це те, що регулювання вимагає від програмних систем мовою, якою інженер може діяти, і як реалізувати поширені зобов'язання, не перетворюючи вашу кодову базу на пустку compliance.
Чотири тіри ризику
Акт класифікує AI-системи на чотири тіри, у кожного різні зобов'язання.
| Tier | Визначення | Що ви маєте робити |
|---|---|---|
| Unacceptable | Соціальне скорування, real-time біометрична ідентифікація в публічних місцях, маніпулятивні системи | Заборонено — не будуйте це |
| High-risk | Use cases з Annex III (працевлаштування, кредити, освіта, critical infra, law enforcement тощо) | Повний набір вимог — документація, oversight, logging, monitoring |
| Limited risk | Чатботи, генеративний AI, emotion recognition | Зобов'язання щодо прозорості |
| Minimal risk | Усе інше | Добровільні codes of conduct |
Більшість стартап-команд потраплять в одну з двох категорій: limited-risk для customer-facing LLM-фічі або high-risk, якщо ви торкаєтесь HR, кредитів, освіти або інших доменів Annex III. Якщо ви сумніваєтесь — схиляйтесь до high-risk.
High-Risk: чого це насправді вимагає
High-risk AI система під Articles 9–15 має реалізувати як мінімум:
- Систему управління ризиками (безперервну, задокументовану, оновлювану в міру еволюції системи).
- Data та data governance практики — якість, репрезентативність, bias analysis.
- Технічну документацію, достатню, щоб дозволити аудитору оцінити conformity.
- Record-keeping (автоматизовані логи протягом lifecycle).
- Прозорість та інформацію для deployers.
- Людський нагляд — система має бути спроєктована для осмисленого людського контролю.
- Accuracy, robustness, cybersecurity.
- Систему управління якістю.
- Post-market monitoring.
- Incident reporting для серйозних інцидентів.
Пройдімося по тих, що з'являються в коді.
Record-Keeping: логування промптів та відповідей
Article 12 вимагає автоматичне логування протягом експлуатації high-risk AI системи. Для LLM-застосунку це означає кожен промпт, кожну відповідь, кожен tool call, кожне рішення. Логи мають дозволяти простежити поведінку системи до входів.
Мінімальне logging middleware для FastAPI застосунку:
from __future__ import annotations
import hashlib
import json
import time
import uuid
from datetime import datetime, timezone
from typing import Any
from fastapi import FastAPI, Request
from pydantic import BaseModel, Field
import structlog
logger = structlog.get_logger()
app = FastAPI()
class LLMInteraction(BaseModel):
interaction_id: str = Field(default_factory=lambda: str(uuid.uuid4()))
timestamp_utc: str = Field(
default_factory=lambda: datetime.now(timezone.utc).isoformat()
)
system_id: str
system_version: str
model: str
model_version: str
user_id_hash: str
input_hash: str
input_tokens: int
output_tokens: int
latency_ms: int
safety_flags: list[str] = []
human_review_requested: bool = False
def hash_user_id(raw: str) -> str:
salt = b"eu-ai-act-log-salt-v1"
return hashlib.sha256(salt + raw.encode()).hexdigest()[:16]
@app.middleware("http")
async def log_llm_interaction(request: Request, call_next):
start = time.monotonic()
response = await call_next(request)
latency = int((time.monotonic() - start) * 1000)
if request.url.path.startswith("/v1/generate"):
interaction = LLMInteraction(
system_id="hr-screening",
system_version=request.app.state.version,
model="claude-sonnet-4.6",
model_version="20260115",
user_id_hash=hash_user_id(request.headers.get("x-user-id", "anon")),
input_hash=request.state.input_hash,
input_tokens=request.state.input_tokens,
output_tokens=request.state.output_tokens,
latency_ms=latency,
safety_flags=getattr(request.state, "safety_flags", []),
)
logger.info("llm.interaction", **interaction.model_dump())
return response
Дві нотатки. По-перше, ми хешуємо ідентифікатори користувачів із сіллю — ви не зобов'язані псевдонімізувати у самих логах, але ви майже завжди хочете з GDPR-міркувань. По-друге, ми логуємо кількості токенів, а не raw content. Акт вимагає record-keeping, але не обов'язково повного збереження вмісту; ви можете зберігати хеші чи summaries, якщо у вас є політика, що так каже. Виберіть одне і задокументуйте.
Retention
В Акті немає єдиного числа retention. Recitals та Article 19 вимагають від провайдера тримати логи "appropriate for the purpose" та "for a period appropriate to the intended purpose" — зазвичай принаймні шість місяців, часто довше. Ми дефолтимо клієнтів на 12 місяців у hot storage, 5 років у cold storage, з документованим видаленням на запит користувача для компонентів персональних даних.
Технічна документація: Model Card
Annex IV перераховує, що має охоплювати технічна документація. Для системи на базі моделі найефективніший формат — це model card, що зберігається у version control поруч із кодом.
Запис Pydantic model registry, що одночасно працює як model card:
from __future__ import annotations
from datetime import date
from typing import Literal
from pydantic import BaseModel, Field, HttpUrl
class IntendedPurpose(BaseModel):
description: str
deployers: list[str]
geographic_scope: list[str]
not_intended_for: list[str] = []
class DataGovernance(BaseModel):
training_data_sources: list[str]
training_data_licensing: list[str]
bias_evaluation: str
bias_metrics: dict[str, float]
pii_handling: str
class HumanOversight(BaseModel):
oversight_type: Literal["human-in-the-loop", "human-on-the-loop", "human-in-command"]
override_mechanism: str
escalation_path: str
class PostMarketMonitoring(BaseModel):
metrics: list[str]
alerting: str
review_cadence_days: int
class ModelCard(BaseModel):
system_id: str
name: str
provider: str
version: str
risk_tier: Literal["unacceptable", "high", "limited", "minimal"]
annex_iii_category: str | None = None
intended_purpose: IntendedPurpose
data_governance: DataGovernance
human_oversight: HumanOversight
monitoring: PostMarketMonitoring
known_limitations: list[str]
accuracy_estimate: float = Field(ge=0, le=1)
robustness_notes: str
last_reviewed: date
reviewed_by: list[str]
documentation_url: HttpUrl
Зберігайте по одному такому на систему у директорії model-cards/. CI валідує, що кожна система, на яку посилається продакшн-код, має картку, і що картку переглядали за останні 180 днів.
Human Oversight: проєктування для нього
Article 14 вимагає, щоб high-risk системи могли бути ефективно контрольовані фізичними особами. Для розробників це зазвичай зводиться до трьох питань:
- Чи може людина бачити, що система робить і чому?
- Чи може людина втрутитись?
- Чи може людина переважити вивід, перш ніж він матиме ефект?
Конкретно: якщо ваша система автоматично відхиляє заявки на роботу, вона не може бути fire-and-forget пайплайном. Людина має побачити рішення, побачити обґрунтування і мати змогу переважити його, перш ніж кандидат отримає повідомлення.
Простий патерн: AI видає рекомендацію з confidence та reason; workflow ставить її в чергу на людський огляд; лише після явного схвалення виконується дія.
class Recommendation(BaseModel):
candidate_id: str
decision: Literal["proceed", "reject", "uncertain"]
confidence: float
reasoning: str
model_version: str
generated_at: str
class ReviewOutcome(BaseModel):
recommendation: Recommendation
reviewer_id: str
reviewer_decision: Literal["approved", "overridden", "escalated"]
reviewer_notes: str
reviewed_at: str
Аудитор очікуватиме побачити приклади overridden. Якщо 100% рекомендацій схвалені як є — або ваша модель ідеальна, або ваш нагляд — це театр.
Прозорість: що бачить користувач
Article 52 охоплює зобов'язання щодо прозорості для limited-risk систем. Ключові:
- Користувачів треба інформувати, що вони взаємодіють з AI-системою (якщо не очевидно).
- AI-згенерований чи маніпульований контент (deepfakes, синтетичні зображення) має бути промаркований.
- Користувачам emotion recognition та biometric categorization треба повідомляти.
- General-purpose AI models мають watermark-увати синтетичні виводи там, де технічно можливо.
На практиці це невелика UI-зміна. Постійний бейдж біля чат-інтерфейсу: "Ви спілкуєтесь з AI-асистентом. Відповіді можуть бути неточними". Для згенерованих зображень: тег у метаданих і видимий індикатор.
Deployment Gating у CI
Найчистіший спосіб примусити це у щоденній інженерії — CI-перевірка, що відмовляється промоутити код у продакшн, якщо пов'язана model card відсутня, застаріла або має неусунуті gaps.
name: AI Compliance Gate
on:
pull_request:
paths:
- "apps/**"
- "model-cards/**"
jobs:
gate:
runs-on: ubuntu-24.04
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.12"
- run: pip install pydantic==2.9 pyyaml==6.0
- name: Validate model cards
run: python scripts/validate_model_cards.py
- name: Check referenced systems have cards
run: python scripts/check_coverage.py
- name: Enforce staleness
run: python scripts/check_staleness.py --max-days 180
І валідаційний скрипт — це кілька рядків:
from __future__ import annotations
import pathlib
import sys
from datetime import date, timedelta
import yaml
from compliance.model_card import ModelCard
root = pathlib.Path("model-cards")
max_age = timedelta(days=180)
today = date.today()
errors: list[str] = []
for path in root.glob("*.yaml"):
raw = yaml.safe_load(path.read_text())
try:
card = ModelCard.model_validate(raw)
except Exception as exc:
errors.append(f"{path}: {exc}")
continue
if today - card.last_reviewed > max_age:
errors.append(f"{path}: stale, last reviewed {card.last_reviewed}")
if card.risk_tier == "high" and not card.annex_iii_category:
errors.append(f"{path}: high-risk card missing Annex III category")
if errors:
print("Compliance gate failed:")
for e in errors:
print(f" - {e}")
sys.exit(1)
print(f"All {len(list(root.glob('*.yaml')))} model cards valid.")
Post-Market Monitoring
Article 72 вимагає post-market monitoring plan — не лише метрики, а задокументований процес того, як ви збираєте, аналізуєте і дієте на дані реальної продуктивності. Ваш існуючий observability-стек — це 80% відповіді. Інші 20% — це заплановане review, де іменована людина дивиться на дані, записує, що побачила, і зберігає це. Щоквартально — мінімум; щомісячно — краще для новіших систем.
Серйозні інциденти — коли система спричиняє шкоду або near-miss — мають бути повідомлені національному органу протягом 15 днів (Article 73). Ваш incident runbook потребує гілки для цього: "чи це reportable під EU AI Act?" Якщо так, compliance team отримує paging поруч з інженерією.
Прагматичний чекліст готовності
- Усі AI-системи класифіковані в risk tiers
- High-risk системи мають model cards, що охоплюють Annex IV
- Логування промптів/відповідей запроваджене з визначеним retention
- Людський нагляд спроєктований у кожен high-risk workflow
- Transparency disclosures у UI для limited-risk систем
- CI gate, що забороняє deployment систем без карток
- Incident runbook включає гілку звітності за AI Act
- Post-market monitoring plan задокументований і запланований
Наступні кроки
Дедлайн серпня 2026 достатньо близький, щоб продуктові команди ставились до цього як до проблеми цього кварталу, а не цього року. Патерн впровадження не екзотичний — це registry, трохи middleware, CI gate і review cadence — але він достатньо нудний, щоб його не зробили, якщо не запланувати. Заплануйте роботу зараз. Якщо хочете допомоги з мапінгом ваших систем на Акт і побудовою gating-пайплайну, напишіть нам.