Loading...
Усі статті
AI Governance · 8 min read

Технічна готовність до EU AI Act: що розробникам треба знати до серпня 2026

Практичний інженерний посібник з EU AI Act: класифікація risk tier, вимоги до high-risk систем та конкретні реалізації логування, прозорості та deployment gating.

Чому серпень 2026 — це реальний дедлайн

EU AI Act набрав чинності в серпні 2024. Положення про заборонені практики почали діяти у лютому 2025. Зобов'язання щодо general-purpose AI models почалися в серпні 2025. А повний набір вимог до high-risk систем стає примусово виконуваним 2 серпня 2026. Це дата, на яку більшість продуктових команд мають звертати увагу, бо вона накладає найбільший інженерний тягар.

Ця стаття — не юридична порада. Для цього у нас є юристи; і у вас мають бути. Те, що вона охоплює — це те, що регулювання вимагає від програмних систем мовою, якою інженер може діяти, і як реалізувати поширені зобов'язання, не перетворюючи вашу кодову базу на пустку compliance.

Чотири тіри ризику

Акт класифікує AI-системи на чотири тіри, у кожного різні зобов'язання.

TierВизначенняЩо ви маєте робити
UnacceptableСоціальне скорування, real-time біометрична ідентифікація в публічних місцях, маніпулятивні системиЗаборонено — не будуйте це
High-riskUse 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 має реалізувати як мінімум:

  1. Систему управління ризиками (безперервну, задокументовану, оновлювану в міру еволюції системи).
  2. Data та data governance практики — якість, репрезентативність, bias analysis.
  3. Технічну документацію, достатню, щоб дозволити аудитору оцінити conformity.
  4. Record-keeping (автоматизовані логи протягом lifecycle).
  5. Прозорість та інформацію для deployers.
  6. Людський нагляд — система має бути спроєктована для осмисленого людського контролю.
  7. Accuracy, robustness, cybersecurity.
  8. Систему управління якістю.
  9. Post-market monitoring.
  10. 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 системи могли бути ефективно контрольовані фізичними особами. Для розробників це зазвичай зводиться до трьох питань:

  1. Чи може людина бачити, що система робить і чому?
  2. Чи може людина втрутитись?
  3. Чи може людина переважити вивід, перш ніж він матиме ефект?

Конкретно: якщо ваша система автоматично відхиляє заявки на роботу, вона не може бути 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-пайплайну, напишіть нам.

у категорії
eu-ai-actcomplianceairegulation
працювати з нами

Хочете, щоб наша команда допомогла з вашою інфраструктурою?

talk to an engineerFree 30-min discovery callBook
close