Audit CI/CD untuk data sovereignty dan approval vendor AI bertujuan mencegah adopsi SDK, API, plugin, atau layanan AI berlangsung diam-diam lewat pull request biasa. Solusi yang paling efektif bukan hanya dokumen kebijakan, tetapi guardrail teknis di pipeline CI/CD yang memaksa review keamanan, privasi, legal, dan lokasi pemrosesan data sebelum perubahan bisa di-merge atau dirilis.

Dalam praktiknya, risiko sering muncul bukan karena tim sengaja melanggar aturan, tetapi karena sebuah dependensi baru terlihat seperti library biasa, padahal ia mengirim prompt, log, telemetry, file, atau metadata ke layanan pihak ketiga. Artikel ini membahas cara membangun workflow yang bisa dipakai tim kecil sampai menengah: inventaris dependensi, klasifikasi data, policy-as-code, pemeriksaan secret dan egress, checklist pull request, approval gate, dan rollout bertahap tanpa membuat developer experience runtuh.

Mengapa guardrail vendor AI perlu ditaruh di CI/CD

Isu kebijakan vendor, perubahan syarat layanan, transparansi pemrosesan data, dan ketidakjelasan lokasi penyimpanan membuat review manual di awal proyek saja tidak cukup. Risiko berubah setiap kali tim:

  • menambah SDK AI baru ke backend atau frontend,
  • mengaktifkan plugin IDE atau agent coding yang ikut masuk ke build process,
  • menambahkan endpoint eksternal baru untuk inference, embedding, OCR, atau transcription,
  • mengirim log aplikasi, exception, atau file lampiran ke vendor pihak ketiga,
  • mengubah konfigurasi egress, proxy, secret, atau environment variable.

CI/CD adalah titik kontrol yang tepat karena semua perubahan kode, dependensi, dan konfigurasi melewati jalur yang sama. Dengan begitu, organisasi tidak bergantung pada ingatan reviewer atau checklist yang sering terlewat.

Model kontrol: apa yang sebaiknya diperiksa

Untuk membuat audit yang berguna, pecah kontrol menjadi beberapa lapisan. Jangan langsung mulai dari tool; mulai dari keputusan apa yang ingin dipaksa oleh pipeline.

1. Inventaris dependensi dan layanan eksternal

Tujuannya adalah mendeteksi penambahan library, package, container image, action CI, atau endpoint baru yang berpotensi mengirim data ke vendor AI. Yang perlu dipantau biasanya meliputi:

  • file lock dependensi seperti package-lock.json, yarn.lock, poetry.lock, requirements.txt, go.mod, pom.xml,
  • Dockerfile dan base image,
  • workflow CI yang memanggil action atau image pihak ketiga,
  • file konfigurasi aplikasi yang berisi base URL atau host egress baru.

2. Klasifikasi data

Pipeline tidak bisa menilai risiko vendor AI tanpa konteks data. Buat klasifikasi yang sederhana namun operasional, misalnya:

  • Public: data publik, dokumentasi, sampel anonim.
  • Internal: data operasional non-publik.
  • Confidential: data pelanggan, kontrak, log sensitif, source code privat.
  • Restricted: data yang diatur ketat, seperti data kesehatan, data finansial tertentu, atau kategori yang dibatasi kebijakan internal.

Tujuan klasifikasi ini bukan menyelesaikan semua kebutuhan tata kelola, tetapi memberi input ke kebijakan otomatis. Misalnya, vendor AI berbasis API mungkin boleh untuk data Public, tetapi wajib approval untuk Confidential dan dilarang untuk Restricted.

3. Policy-as-code

Aturan perlu ditulis sebagai kode agar konsisten, bisa diuji, dan bisa dijalankan otomatis. Formatnya bisa sederhana: file YAML untuk daftar vendor yang diizinkan, ditambah evaluasi policy via script atau mesin kebijakan seperti OPA/Rego. Yang penting adalah keputusan berikut bisa diekspresikan dengan jelas:

  • vendor mana yang sudah disetujui,
  • jenis data apa yang boleh diproses vendor itu,
  • apakah vendor mengizinkan training pada data pelanggan,
  • apakah lokasi pemrosesan atau penyimpanan memenuhi kebutuhan data sovereignty,
  • apakah penggunaan membutuhkan DPA, review legal, atau security assessment.

4. Secret dan egress check

Banyak integrasi AI mulai dari menambahkan API key lalu memanggil host eksternal. Karena itu, selain memindai dependensi, pipeline juga perlu memeriksa:

  • apakah ada secret baru yang tampak seperti token vendor AI,
  • apakah ada host baru di allowlist egress,
  • apakah kode menambahkan pemanggilan HTTP ke domain yang belum terdaftar,
  • apakah telemetry atau log dapat membawa payload sensitif ke luar perimeter.

5. Approval gate yang benar-benar memblokir

Checklist tanpa enforcement mudah diabaikan. Jika perubahan menyentuh kategori berisiko, pipeline harus gagal atau menahan merge sampai pihak yang berwenang memberi approval. Di GitHub ini bisa dilakukan dengan required reviewers, status check, dan environment protection. Di GitLab, gunakan approval rules, protected branches, dan job manual yang dibatasi per role.

Arsitektur workflow yang realistis

Untuk tim kecil-menengah, jangan membangun sistem yang terlalu berat. Workflow berikut biasanya cukup:

  1. Deteksi perubahan: identifikasi file yang berubah di PR/MR.
  2. Inventaris: ekstrak dependensi, endpoint, dan secret candidate.
  3. Konteks: baca metadata klasifikasi data dan daftar vendor yang diizinkan.
  4. Evaluasi policy: tentukan apakah perubahan lolos, butuh approval, atau ditolak.
  5. Surface hasil: kirim komentar otomatis ke PR/MR dengan alasan yang bisa ditindaklanjuti.
  6. Gate: blok merge/deploy sampai approval lengkap.

Secara praktis, simpan konfigurasi tata kelola di repository agar review-nya transparan. Contoh struktur:

compliance/
  approved-vendors.yaml
  data-classification.yaml
  vendor-review-checklist.md
  egress-allowlist.txt
  policy/
    vendor_ai.rego
scripts/
  detect_vendor_changes.sh
  scan_egress.py
.github/
  workflows/
    vendor-guardrails.yml

Contoh metadata kebijakan yang sederhana

Mulailah dari format yang bisa dibaca tim non-security. YAML cukup baik untuk tahap awal.

vendors:
  - name: example-ai
    status: approved
    allowed_data_classes:
      - Public
      - Internal
    training_on_customer_data: false
    allowed_regions:
      - id
      - sg
      - eu
    requires_dpa: true
    notes: "Hanya untuk use case summarization non-sensitive"

  - name: another-ai
    status: review_required
    allowed_data_classes:
      - Public
    training_on_customer_data: unknown
    allowed_regions: []
    requires_dpa: true
    notes: "Belum ada keputusan final dari legal/security"

Contoh klasifikasi per aplikasi atau area kode:

services:
  billing-api:
    data_class: Restricted
  support-bot:
    data_class: Confidential
  docs-site:
    data_class: Public

Mengapa pendekatan ini bekerja? Karena pipeline tidak perlu menebak semua hal dari kode. Ia menggabungkan sinyal teknis dari diff dengan metadata kebijakan yang dikelola tim compliance, legal, dan security.

Implementasi di GitHub Actions

Contoh berikut menunjukkan alur dasar: saat ada pull request, workflow memeriksa apakah ada perubahan pada dependensi, file CI, Dockerfile, atau konfigurasi yang relevan. Jika ya, script akan mengevaluasi kebijakan dan gagal bila vendor belum disetujui atau butuh approval tambahan.

name: vendor-ai-guardrails

on:
  pull_request:
    branches: [ main ]

jobs:
  audit-vendor-ai:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Get changed files
        id: changes
        run: |
          git diff --name-only origin/${{ github.base_ref }}...HEAD > changed_files.txt
          cat changed_files.txt

      - name: Detect sensitive changes
        id: detect
        run: |
          python3 scripts/detect_vendor_changes.py changed_files.txt > result.json
          cat result.json

      - name: Evaluate policy
        run: |
          python3 scripts/evaluate_vendor_policy.py result.json compliance/approved-vendors.yaml compliance/data-classification.yaml

      - name: Comment on PR when review is required
        if: failure()
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const body = fs.readFileSync('policy_report.md', 'utf8');
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
              body
            });

Workflow di atas sengaja tidak bergantung pada perilaku yang terlalu spesifik. Intinya:

  • detect_vendor_changes.py mencari sinyal perubahan berisiko,
  • evaluate_vendor_policy.py memutuskan lolos atau gagal,
  • status check menjadi syarat merge di branch protection.

Contoh aturan deteksi yang masuk akal

Script deteksi tidak perlu sempurna pada hari pertama. Fokus pada sinyal yang bernilai tinggi:

  • perubahan file lock atau manifest dependensi,
  • penambahan package yang namanya cocok dengan daftar vendor AI yang dipantau,
  • penambahan URL host eksternal di source code atau file konfigurasi,
  • penambahan environment variable seperti API_KEY, TOKEN, OPENAI, ANTHROPIC, atau nama vendor lain yang relevan,
  • perubahan pada workflow CI yang memanggil action pihak ketiga.

Contoh pseudo-output dari script deteksi:

{
  "service": "support-bot",
  "data_class": "Confidential",
  "new_dependencies": ["example-ai-sdk"],
  "new_hosts": ["api.example-ai.com"],
  "new_secrets": ["EXAMPLE_AI_API_KEY"],
  "requires_review": true,
  "reasons": [
    "Vendor AI baru terdeteksi",
    "Service memproses data Confidential",
    "Host egress baru belum ada di allowlist"
  ]
}

Approval gate di GitHub

Agar status check benar-benar efektif, biasanya Anda perlu:

  • mengaktifkan branch protection untuk mewajibkan status check lulus,
  • mewajibkan review dari code owner untuk folder kebijakan atau area sensitif,
  • memisahkan deployment production ke environment yang membutuhkan reviewer tertentu,
  • membatasi siapa yang boleh mengubah workflow CI dan file di compliance/.

Contoh CODEOWNERS sederhana:

/compliance/ @security-team @legal-ops
/.github/workflows/ @platform-team @security-team
/services/support-bot/ @app-team @security-team

Catatan: jika file kebijakan bisa diubah oleh orang yang sama dengan pengusul integrasi vendor, guardrail kehilangan nilainya. Lindungi file policy dan workflow dengan reviewer yang independen.

Implementasi di GitLab CI

GitLab CI cocok jika Anda ingin menggabungkan job pipeline dengan approval rule di merge request.

stages:
  - audit
  - test

vendor_ai_audit:
  stage: audit
  image: python:3.11-slim
  script:
    - python scripts/detect_vendor_changes.py changed_files.txt > result.json
    - python scripts/evaluate_vendor_policy.py result.json compliance/approved-vendors.yaml compliance/data-classification.yaml
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
  allow_failure: false
  artifacts:
    when: always
    paths:
      - result.json
      - policy_report.md

Di sisi GitLab, Anda bisa menambahkan:

  • approval rules untuk mewajibkan tim security atau legal saat file tertentu berubah,
  • protected branches agar merge ke branch utama dikendalikan,
  • CODEOWNERS untuk area kebijakan, networking, dan deployment.

Jika memungkinkan, kombinasikan job audit dengan aturan merge request berbasis path. Contohnya, perubahan pada compliance/, .gitlab-ci.yml, atau file manifest dependensi dapat memicu reviewer tambahan.

Checklist pull request untuk vendor AI

Checklist di PR bukan pengganti policy-as-code, tetapi sangat membantu mengumpulkan konteks yang tidak terlihat dari diff. Buat singkat dan wajib dijawab jika integrasi vendor terdeteksi.

## Vendor AI Review Checklist

- [ ] Apakah perubahan ini menambah SDK, API, plugin, atau layanan AI baru?
- [ ] Nama vendor dan use case dijelaskan di deskripsi PR.
- [ ] Jenis data yang dikirim ke vendor sudah diklasifikasikan.
- [ ] Tidak ada data Restricted yang dikirim.
- [ ] Host egress baru sudah didaftarkan dan dijelaskan.
- [ ] Secret disimpan di secret manager, bukan di repository.
- [ ] Legal/security review sudah diminta jika vendor belum approved.
- [ ] Retention, training usage, dan lokasi pemrosesan data vendor sudah diverifikasi.

Mengapa checklist masih diperlukan? Karena hal seperti “vendor memakai data untuk training” atau “subprocessor berada di wilayah tertentu” sering tidak bisa dipastikan hanya dari source code. Pipeline perlu menuntut bukti review, bukan hanya mendeteksi kode.

Pemeriksaan secret dan egress yang sering terlewat

Secret scanning

Integrasi AI hampir selalu menambah credential baru. Minimal, lakukan dua hal:

  • scan repository dan diff untuk secret yang ter-commit,
  • deteksi penambahan nama secret baru yang berhubungan dengan vendor dan pastikan berasal dari secret manager atau CI variable, bukan hardcoded.

Kesalahan umum adalah merasa aman karena nilai secret tidak ada di repo, padahal nama environment variable baru menandakan integrasi vendor yang belum direview.

Egress scanning

Dari sisi data sovereignty, endpoint keluar sama pentingnya dengan package. Beberapa tim hanya memeriksa dependensi, tetapi lupa bahwa call HTTP bisa dibuat langsung tanpa SDK. Karena itu, pertimbangkan:

  • allowlist domain egress per aplikasi,
  • review tambahan saat ada base URL baru,
  • sinkronisasi dengan firewall, proxy, service mesh, atau gateway bila dipakai.

Contoh file allowlist sederhana:

# service,domain,purpose
support-bot,api.example-ai.com,summarization
billing-api,internal-ml.company.local,internal inference only

Pemeriksaan ini tidak harus sangat canggih. Untuk tahap awal, membandingkan domain baru di diff dengan allowlist sudah memberi nilai besar.

Contoh logika policy-as-code

Jika Anda ingin aturan lebih formal, mesin kebijakan seperti OPA/Rego bisa dipakai. Tidak wajib, tetapi berguna saat aturan mulai kompleks. Contoh konsep aturan:

  • tolak jika vendor belum ada di daftar approved dan service mengolah data Confidential atau Restricted,
  • tolak jika region vendor tidak cocok dengan batasan data sovereignty organisasi,
  • tolak jika host egress baru belum terdaftar,
  • wajibkan approval security dan legal jika atribut vendor tertentu masih unknown.

Inti policy-as-code bukan bahasanya, melainkan kemampuan untuk mengekspresikan keputusan secara konsisten dan dapat diaudit. Simpan hasil evaluasi sebagai artefak pipeline agar ada jejak alasan mengapa PR ditahan atau diloloskan.

Rollout bertahap untuk tim kecil-menengah

Kesalahan paling umum adalah mencoba memblokir semua hal sekaligus. Hasilnya banyak false positive, developer frustrasi, lalu aturan dimatikan. Rollout bertahap biasanya lebih efektif.

Fase 1: observability dulu

  • jalankan deteksi dependensi, host, dan secret dalam mode laporan,
  • kirim komentar otomatis ke PR tanpa memblokir merge,
  • kumpulkan pola package, domain, dan workflow yang paling sering muncul.

Fase 2: block perubahan berisiko tinggi

  • mulai blok hanya untuk vendor yang tidak dikenal,
  • blok service dengan klasifikasi Confidential dan Restricted,
  • wajibkan approval pada perubahan file CI, egress, dan policy.

Fase 3: rapikan tata kelola

  • lengkapi daftar vendor approved beserta batasannya,
  • tambahkan code owners dan approval rule yang lebih presisi,
  • integrasikan dengan inventory aset, CMDB, atau katalog layanan internal bila ada.

Pola ini menjaga keseimbangan antara kontrol dan adopsi. Tim kecil tidak perlu langsung membeli platform governance besar; repository, workflow CI, dan beberapa script sudah cukup untuk tahap awal.

Trade-off dan keterbatasan

  • Deteksi berbasis nama package tidak sempurna. Vendor bisa masuk lewat wrapper internal atau package generik.
  • Pemeriksaan diff tidak melihat perilaku runtime penuh. Call egress bisa dibentuk dinamis dari environment variable.
  • Checklist PR bergantung pada kejujuran dan kualitas konteks. Karena itu tetap perlu guardrail teknis.
  • Approval gate bisa memperlambat delivery. Kurangi dampaknya dengan SLA review yang jelas dan daftar vendor pre-approved.
  • Data sovereignty tidak berhenti di region. Perlu juga mempertimbangkan subprocessors, retention, training usage, dan transfer lintas batas.

Karena itu, anggap pipeline sebagai lapisan kontrol praktis, bukan jaminan absolut. Ia paling efektif bila dikombinasikan dengan inventaris vendor, review kontrak, dan kontrol jaringan.

Debugging dan kesalahan yang sering terjadi

False positive terlalu banyak

Biasanya disebabkan pola deteksi terlalu luas. Solusinya:

  • batasi hanya file/path yang relevan,
  • gunakan daftar vendor yang dipantau, bukan kata kunci umum,
  • pisahkan mode “warning” dan “blocking”.

Policy mudah di-bypass

Ini terjadi jika workflow CI atau file kebijakan dapat diubah tanpa reviewer independen. Pastikan:

  • workflow dan policy punya code owner,
  • branch utama dilindungi,
  • status check wajib lulus sebelum merge.

Reviewer bingung apa yang harus dicek

Approval gate tidak akan membantu jika reviewer tidak punya kriteria. Sediakan template review yang menjawab pertanyaan minimum:

  • data apa yang dikirim,
  • ke vendor mana,
  • untuk use case apa,
  • di region mana diproses,
  • apakah dipakai untuk training,
  • apakah ada DPA atau dokumen vendor yang relevan.

Rekomendasi implementasi minimum yang layak

Jika Anda ingin mulai minggu ini tanpa proyek besar, implementasi minimum berikut sudah cukup berguna:

  1. Buat folder compliance/ berisi daftar vendor approved, klasifikasi data, dan allowlist egress.
  2. Tambahkan script CI untuk mendeteksi perubahan pada manifest dependensi, workflow, Dockerfile, host eksternal, dan nama secret.
  3. Aktifkan status check wajib di GitHub Actions atau GitLab CI.
  4. Tambahkan CODEOWNERS untuk file policy, workflow CI, dan service sensitif.
  5. Pasang checklist PR untuk integrasi vendor AI.
  6. Mulai dari mode laporan 1-2 sprint, lalu blok perubahan berisiko tinggi.

Pendekatan ini cukup ringan untuk tim kecil-menengah, tetapi sudah memberikan dua manfaat utama: visibilitas atas adopsi vendor AI dan enforcement agar keputusan keamanan, privasi, dan data sovereignty tidak bergantung pada ingatan individu.

Penutup

Audit CI/CD untuk data sovereignty dan approval vendor AI paling efektif bila diposisikan sebagai kontrol rekayasa, bukan sekadar proses administrasi. Dengan menggabungkan inventaris dependensi, klasifikasi data, policy-as-code, pemeriksaan secret dan egress, checklist pull request, serta approval gate yang memblokir, tim dapat mengurangi risiko adopsi vendor AI tanpa kehilangan kecepatan sepenuhnya.

Mulailah dari aturan yang sederhana, ukur false positive, lalu perketat secara bertahap. Tujuannya bukan melarang semua tool AI, melainkan memastikan setiap integrasi melewati review yang tepat sebelum menyentuh data dan sistem yang sensitif.