Чому ISO 42001 на вашому roadmap, хочете ви цього чи ні
ISO/IEC 42001:2023 — це перший міжнародний сертифікований стандарт системи менеджменту для штучного інтелекту. Якщо ви колись проходили ISO 27001, то вже знаєте форму: цикл Plan-Do-Check-Act навколо набору контролів, Statement of Applicability, внутрішній аудит і врешті-решт зовнішній сертифікаційний аудит. ISO 42001 приносить ту саму механіку до AI-систем — охоплюючи те, як ви їх будуєте, керуєте, моніторите та виводите з експлуатації.
Протягом 2025 року це було цікавою темою для читання. На початку 2026 це стає вимогою покупця. Enterprise-клієнти — особливо в регульованих галузях — починають додавати "ISO 42001 сертифіковано або на шляху до сертифікації" у свої RFP. EU AI Act також явно визнає ISO 42001 як презумпцію відповідності для кількох зобов'язань AIMS. Якщо ви стартап, що будує AI-функції або продає enterprise, цей стандарт більше не опціональний для розуміння.
Ця стаття — інженерна сторона впровадження ISO 42001. Ми залишаємо паперову роботу вашій команді compliance, де можемо, і зосереджуємося на тому, що вам, людям, які керують системами, насправді треба побудувати.
Що стандарт насправді вимагає
ISO 42001 визначає AI Management System (AIMS). На високому рівні:
- Clauses 4–10 описують саму систему менеджменту — контекст, leadership, planning, support, operation, evaluation, improvement. Це "ISO-форма" скелета, ідентичного 27001.
- Annex A перераховує 38 контролів, що охоплюють AI-специфічні питання: політики для AI, внутрішня організація, ресурси (дані, інструменти, люди), impact assessments, AI system lifecycle, data for AI, information for interested parties, використання AI-систем та відносини з третіми сторонами.
- Annex B — це implementation guidance для цих контролів.
- Annex C мапить цілі AI та джерела ризику.
- Annex D охоплює міркування, специфічні для галузі.
Сертифікаційний аудитор захоче побачити докази того, що кожен застосовний контроль Annex A впроваджений, підтримується і є ефективним. Ваша робота як інженерів — генерувати ці докази автоматично всюди, де можливо, бо альтернатива — це PDF-и.
Як це співвідноситься з ISO 27001
Якщо у вас уже є 27001 програма, приблизно 40–50% механіки переноситься. Ми робили overlap analysis для кількох клієнтів, і ось приблизна картина:
| Область контролю ISO 27001 | Еквівалент ISO 42001 | Reuse % |
|---|---|---|
| Access control | A.4 Resources (доступ до AI-систем/даних) | ~80% |
| Cryptography | Застосовується до вагів моделей, тренувальних даних | ~90% |
| Supplier relationships | A.10 Third-party relationships | ~70% |
| Incident management | A.9 AI system lifecycle - incidents | ~60% |
| Change management | A.6 AI system impact assessment | ~40% |
| Risk assessment | A.5 Assessing impacts of AI systems | ~30% |
Області з найнижчим reuse — це ті, що унікальні для AI: impact assessments щодо людей і груп, міркування щодо bias та fairness, управління model lifecycle та explainability. Плануйте інвестувати туди реальний інженерний час.
Крок 1: Визначення області AIMS
Перше питання, яке поставить аудитор: які AI-системи у області? Відповідь не може бути "усі" або "жодна". Це має бути визначений, захищуваний набір систем з документованими межами.
Ми рекомендуємо підхід інвентаризації. Побудуйте model registry — так, реальне програмне забезпечення, а не spreadsheet — і трактуйте його як джерело істини. Кожна AI-система в області має запис. Ось мінімальна схема:
# models/claude-rag-assistant.yaml
id: claude-rag-assistant
name: Customer Support RAG Assistant
owner: team-ai-platform
contact: [email protected]
deployment:
environment: production
regions: [eu-west-1]
endpoint: https://api.example.com/v1/assistant
classification:
purpose: customer-support
data_sensitivity: pii
risk_tier: high
eu_ai_act_tier: limited
affected_parties: [customers, support-agents]
model:
type: llm-rag
base_model: claude-sonnet-4.6
provider: anthropic
version_pinned: true
weights_location: vendor-hosted
data:
training_sources: none-fine-tuning
rag_sources:
- name: support-kb
location: s3://example-kb/support/
pii: false
- name: ticket-history
location: postgres://prod-rds/tickets
pii: true
retention_days: 365
governance:
impact_assessment_id: IA-2026-014
last_reviewed: "2026-01-15"
approved_by: [cto, dpo]
lifecycle:
stage: production
decommission_date: null
Кожна модель у registry тригерить downstream workflow: impact assessment, якщо його немає, data-governance перевірку, конфігурацію логування, дашборди моніторингу та audit trail. Людина дає підпис, перш ніж запис зможе перейти у stage: production.
Крок 2: Risk And Impact Assessment
ISO 42001 йде далі за 27001 у risk assessment. Ви оцінюєте ризики не лише для організації, а й для окремих людей та суспільства, яких торкається AI-система. Annex B.5 дає фреймворк: ідентифікуйте AI-систему, опишіть її контекст, ідентифікуйте впливи (позитивні та негативні), оцініть severity та likelihood і задокументуйте рішення продовжити, мітігувати чи відмовитись.
Легковаговий шаблон impact assessment:
# Impact Assessment: <System Name>
## 1. System context
- Purpose and intended users
- Operating environment
- Data flows
## 2. Affected parties
- Direct users
- Third parties
- Vulnerable populations
## 3. Potential impacts
- Privacy
- Fairness / discrimination
- Safety
- Financial
- Autonomy and human oversight
## 4. Likelihood and severity
- Matrix scored 1-5 each
## 5. Mitigations
- Technical
- Procedural
## 6. Residual risk and decision
- Accept / mitigate / decline
- Approver and date
Зберігайте їх як markdown у compliance-репозиторії, доступному лише для читання для всіх, крім невеликої групи, версіонованому і посиланому за model ID з registry.
Крок 3: Controls As Code
38 контролів Annex A — це те, що аудитор трасуватиме. Ви можете задовольнити більшість із них паперовою роботою, але швидший шлях — виразити якомога більше як machine-checkable policy. Ми використовуємо OPA з Rego для цього. Воно запускається у CI, в admission controllers і як окрема перевірка проти model registry.
Політика, що блокує будь-яку модель від потрапляння у продакшн без impact assessment та підпису DPO:
package ai.model_registry
default allow := false
deny contains msg if {
input.deployment.environment == "production"
input.classification.data_sensitivity == "pii"
not input.governance.impact_assessment_id
msg := sprintf("model %q handles PII but has no impact assessment", [input.id])
}
deny contains msg if {
input.deployment.environment == "production"
input.classification.risk_tier == "high"
not "dpo" in input.governance.approved_by
msg := sprintf("high-risk model %q missing DPO approval", [input.id])
}
deny contains msg if {
input.lifecycle.stage == "production"
not input.governance.last_reviewed
msg := sprintf("model %q has no review date", [input.id])
}
allow if {
count(deny) == 0
}
Запуск у CI проти кожного PR у директорію models/:
- name: Validate model registry
run: |
for file in models/*.yaml; do
yq -o=json "$file" | \
opa eval -I -d policies/ \
"data.ai.model_registry.deny" --format=pretty
done
Кожен merge, що змінює запис моделі, породжує audit-запис. Аудитор отримує Git log.
Крок 4: Data Governance для Training та RAG
Контроль Annex A A.7 охоплює data for AI: якість, походження, підготовка та ongoing management. Для LLM-застосунку це зазвичай означає:
- Тренувальні дані, якщо ви робите fine-tune — джерело, ліцензія, згода, PII scrubbing.
- RAG-корпус — які документи індексуються, як вони оновлюються, як видаляються на запит користувача.
- Логи промптів та відповідей — що ви захоплюєте, як довго зберігаєте, хто може читати.
Закрийте S3 бакет, що містить RAG-корпус, з object lock, versioning та access logging. Terraform:
resource "aws_s3_bucket" "ai_corpus" {
bucket = "example-ai-corpus-prod"
}
resource "aws_s3_bucket_versioning" "corpus" {
bucket = aws_s3_bucket.ai_corpus.id
versioning_configuration {
status = "Enabled"
}
}
resource "aws_s3_bucket_object_lock_configuration" "corpus" {
bucket = aws_s3_bucket.ai_corpus.id
rule {
default_retention {
mode = "GOVERNANCE"
days = 365
}
}
}
resource "aws_s3_bucket_logging" "corpus" {
bucket = aws_s3_bucket.ai_corpus.id
target_bucket = aws_s3_bucket.audit_logs.id
target_prefix = "s3-access/ai-corpus/"
}
resource "aws_cloudtrail" "ai_data_events" {
name = "ai-data-events"
s3_bucket_name = aws_s3_bucket.audit_logs.id
include_global_service_events = false
event_selector {
read_write_type = "All"
include_management_events = true
data_resource {
type = "AWS::S3::Object"
values = ["${aws_s3_bucket.ai_corpus.arn}/"]
}
}
}
Така конфігурація CloudTrail дає вам per-object access logs. Надайте їх у ваш SIEM — і ви маєте захищуваний слід доказів для аудитора.
Крок 5: Model Lifecycle та Change Management
Кожна істотна зміна моделі у продакшні тригерить evaluation. Оновлення базової моделі з Claude Sonnet 4.5 до Sonnet 4.6 — це зміна. Заміна embedding-моделі — це зміна. Додавання нового інструмента до агента — це зміна. Кожна з них має пройти через:
- Change record (PR до model registry).
- Оновлений impact assessment, якщо purpose, users або data sensitivity змінилися.
- Регресійний eval проти збереженого benchmark.
- Canary deployment з моніторингом.
- Схвалення та rollout.
Крок eval — це той, що команди найчастіше пропускають. Побудуйте його зараз. Мінімальна Python-обв'язка на базі LangSmith, Promptfoo або власних скриптів підійде. Мета: "чи нова модель все ще дає прийнятні виводи на нашому golden dataset?"
Крок 6: Моніторинг продуктивності та реагування на інциденти
A.9 охоплює operational monitoring та incident handling. Вам потрібно:
- Quality metrics — task completion, hallucination rate, сигнали user feedback.
- Safety metrics — refusal rate, policy violations, jailbreak detection.
- Performance metrics — latency, token usage, cost.
- Drift detection — зсуви розподілу входів у часі.
Підключіть усе це до тієї самої observability-стека, яку ви використовуєте для звичайних сервісів. OpenTelemetry spans для кожного LLM-виклику, теговані model ID, user ID (хешованим), кількостями вхідних і вихідних токенів та quality-сигналом.
Incident response — це друга половина. Коли модель поводиться неправильно — видає шкідливий output, зливає промпт, порушує політику — вам потрібен runbook, що тригерить протягом хвилин. Він має виглядати як будь-який інший incident runbook: on-call інженер отримує paging, початковий triage, containment (вимкнути модель або перенаправити на fallback), розслідування, postmortem. Єдина AI-специфічна частина — це те, що postmortem може вимагати dataset review та повторної оцінки, перш ніж модель повернеться в онлайн.
Крок 7: Внутрішній аудит
ISO вимагає внутрішній аудит перед сертифікацією. Не ставтеся до цього як до формальності. Виберіть інженера, якого не було в команді впровадження, дайте йому Statement of Applicability і попросіть простежити кожен застосовний контроль до доказів. Усюди, де він не може знайти автоматизованих доказів, у вас є gap. Виправте його і бронюйте зовнішній аудит.
Чекліст gap-аналізу
Короткий чекліст, який ми використовуємо на клієнтських проєктах, щоб швидко оцінити, де ви:
- Інвентар AI-систем в області існує і є machine-readable
- Кожна система має owner і контакт
- Кожна система має impact assessment у файлі
- Походження тренувальних даних задокументоване
- RAG corpus має access logs та object versioning
- Зміни моделей проходять через PR review з OPA перевірками
- Логи промптів/відповідей мають визначений retention та access control
- Quality та safety метрики моніторяться у продакшні
- Incident runbook для AI-специфічних проблем існує і протестований
- Supplier due diligence щодо провайдерів моделей задокументовано
- DPO та security команди мають sign-off на high-risk системи
- Внутрішній аудит був проведений принаймні один раз
Якщо сьогодні правдиві менше ніж 7 із них, вас чекає 4–6 місяців роботи до certification readiness.
Наступні кроки
ISO 42001 значно зручніший, ніж виглядає на перший погляд, особливо для команд, у яких уже є ISO 27001 або SOC 2. Трюк у тому, щоб ставитися до контролів як до інженерних проблем, а не до проблем документації — збудуйте registry, підключіть policy-as-code, автоматизуйте докази, і паперова робота подбає про себе сама. Якщо хочете допомоги з підняттям машинерії або проведенням gap-assessment, напишіть нам.