AI governance in regulated industries is stuck in a manual loop. Models deploy faster than spreadsheets update, approvals live in email threads, and when an auditor shows up, nobody can prove that what's running in production is what was actually approved. This tutorial shows you how to fix that with automated compliance gates that make governance a deployment requirement, not a post-deployment hope. You'll build a working system using KitOps for model packaging, Jozu Hub for security scanning and attestation, and Open Policy Agent for policy enforcement.
1. The Problem: No Proof of What's Running
Your model just deployed to production. An auditor asks: "Show me the exact training data, code version, and approval for what's live right now."
With manual tracking, you're hunting through S3 buckets for dataset snapshots, Git commits for code versions, email threads for approvals, and spreadsheets that may not match reality. The problem isn't documenting these things. It's proving they match what's actually running in Kubernetes.
What we're building in this tutorial: An automated system where every production deployment carries cryptographic proof of what it contains (model, data, code, prompts packaged together), who approved it (cryptographic signatures), and what security checks it passed (scan attestations). The system blocks any deployment missing this proof. Everything from training data to production is cryptographically linked and tamper-proof.
The EU AI Act Article 72 requires continuous monitoring and Article 12 requires automatic logging with multi-year retention. Manual spreadsheets can't provide the tamper-proof evidence regulators expect. When governance becomes a bottleneck, teams bypass it entirely, creating shadow AI deployments you can't audit.
By the end of this tutorial, you'll have working deployment gates using KitOps for packaging, Jozu Hub for scanning and attestation, and OPA for policy enforcement. You'll see the actual code, test it with a sample model, and understand how to adapt it for your compliance requirements.
2. The Solution: Automated Compliance Gates
Instead of tracking compliance in spreadsheets, we make it a deployment requirement: if an artifact can't prove it's compliant, infrastructure refuses to deploy it.
The Architecture:
The system has three components. KitOps packages everything (model, data, code) into a single immutable artifact with a SHA-256 hash. Jozu Hub scans that artifact for AI-specific vulnerabilities across five attack categories and creates signed attestations. OPA evaluates your governance policies against the scan results and metadata, then returns allow or deny.
The before-and-after is simple. Before: email approvals, spreadsheet tracking, manual checks. After: push fails immediately if policies are violated, and every decision creates an automated audit trail.
Section 3: Technical Deep Dive
This section shows what each component looks like in practice, with the actual YAML, policies, and enforcement mechanisms.
3.1 ModelKits
ModelKits are OCI artifacts that package your model, training data, inference code, and documentation into a single immutable unit. They work with any container registry (Docker Hub, ECR, Harbor, etc.).
The Kitfile is a YAML manifest that describes what's in the package. Here's what a production ModelKit looks like:
manifestVersion: 1.0.0
package:
name: fraud-detection
version: 3.2.1
description: "Transaction fraud detection model"
authors: ["alice@company.com"]
license: Apache-2.0
model:
path: ./model.onnx
framework: scikit-learn
version: 1.3.0
code:
- path: ./inference.py
- path: ./preprocessing.py
datasets:
- path: ./validation_sample.parquet
description: "1000 transactions for validation"
docs:
- path: ./model_card.md
parameters:
risk_level: high
regulatory_scope: "EU AI Act Article 12"
bias_metrics:
demographic_parity: 0.96
equalized_odds: 0.94
performance_metrics:
precision: 0.94
recall: 0.89
approved_by: alice@company.com
approval_date: "2026-01-15T10:00:00Z"Why this matters: Every element gets hashed with SHA-256. Change one line of code, update one hyperparameter, or modify the approval date, and the hash changes. You get tamper-proof versioning. You can cryptographically prove what's running in production matches what was approved.
The parameters section is where governance lives. These fields don't affect the model's behavior. They're metadata that policies check. OPA reads risk_level: high and enforces stricter requirements. It sees approval_date and blocks deployments if approvals are expired.
3.2 Jozu Hub
Jozu Hub handles security scanning and attestation management. When you push a ModelKit to Jozu Hub's registry, it automatically runs five specialized AI security scanners.
ModelScan handles static supply-chain scanning for serialized model artifacts, detecting malicious deserialization payloads, embedded code, and packaging risks. LLM Guard provides input/output security filters for LLM apps, blocking prompt injection, PII/secrets, and toxic content. Garak runs automated LLM red teaming with behavioral probes for injection, policy evasion, data exfiltration, and system prompt leakage. Promptfoo handles prompt evaluation and adversarial testing, defining reproducible test suites that measure jailbreak resistance and enforce regression gates. ART (Adversarial Robustness Toolbox) covers adversarial ML evaluation, implementing evasion, poisoning, extraction, and inference attacks, plus defenses and robustness metrics.
Together, these five scanners cover the attack categories that traditional vulnerability scanners miss entirely: supply chain attacks, adversarial robustness, prompt injection, content safety, and privacy risks. Each scanner produces a report that gets cryptographically signed and attached to the ModelKit as an attestation. These attestations are the evidence that policies check.
The enforcement flow:
Before allowing a ModelKit to be pushed, pulled, or deployed, Jozu Hub queries OPA with the Kitfile metadata (risk level, approval status, bias metrics), scan results (vulnerability counts, license findings, SBOM), and existing attestations (who approved it, when, for what purpose).
OPA evaluates your policies and returns allow or deny with a specific reason. If denied, Jozu Hub blocks the operation and returns the policy violation message to the user. If allowed, the operation proceeds and the decision gets logged immutably.
What this solves: No more "the model in production doesn't match what was approved." The deployment pipeline enforces that only validated, scanned, signed ModelKits reach production. If it's not in Jozu Hub with passing attestations, it can't deploy.
3.3 Open Policy Agent
OPA is a CNCF graduated policy engine that evaluates rules written in Rego, a declarative language designed for expressing policies over JSON data.
Policies live in Git alongside your code. They're version-controlled, code-reviewed, and tested like any other software. When Jozu Hub queries OPA, it sends the ModelKit's metadata and attestations as JSON input.
Example policy: Block unapproved licenses
package governance.licenses
import future.keywords.in
# Define allowed licenses
allowed_licenses := {
"Apache-2.0",
"MIT",
"BSD-3-Clause",
"Proprietary-Internal"
}
# Deny if license not in allowed set
deny[msg] {
license := input.kitfile.package.license
not license in allowed_licenses
msg := sprintf("License '%s' not approved for production", [license])
}When a developer pushes a ModelKit with license: GPL-3.0, OPA evaluates this policy and returns:
{
"deny": ["License 'GPL-3.0' not approved for production"]
}Jozu Hub sees the denial, blocks the push, and shows the developer exactly why it failed. No ambiguity, no manual review needed.
Example policy: Enforce approval expiry
package governance.approvals
deny[msg] {
input.kitfile.parameters.risk_level == "high"
# Parse approval date
approval := time.parse_rfc3339_ns(input.kitfile.parameters.approval_date)
now := time.now_ns()
# Check if older than 90 days
age_days := (now - approval) / (1000000000 * 86400)
age_days > 90
msg := sprintf("High-risk model approval expired (%d days old, max 90)", [round(age_days)])
}This catches the common problem where a model was approved six months ago but is still being deployed with stale approvals. The policy automatically enforces re-approval every 90 days for high-risk models.
3.4 EU AI Act Compliance Example
The EU AI Act Article 72 requires continuous monitoring of bias in high-risk AI systems. Rather than manual quarterly reviews, you encode the requirements as policy.
Bias monitoring policy:
package governance.bias
# EU AI Act Article 72 - Continuous bias monitoring
deny[msg] {
input.kitfile.parameters.risk_level == "high"
# Check demographic parity (80% rule from disparate impact analysis)
dp := input.kitfile.parameters.bias_metrics.demographic_parity
dp Here's how it plays out. A data scientist trains a model and computes demographic_parity: 0.75. They push the ModelKit to Jozu Hub. Jozu Hub queries OPA with the bias metrics. OPA evaluates 0.75 against the 0.80 threshold, finds a violation, and the deployment is blocked with the message: "Demographic parity 0.75 below 0.80 threshold (EU AI Act Article 72)." The decision is logged immutably with the timestamp, user, model version, and exact metrics.
The data scientist sees the specific violation, fixes the bias issue, retrains, and pushes again. No manual review needed. The policy enforces the regulation automatically, and every decision creates audit evidence.
What regulators see: When audited, you provide the policy itself (version-controlled, dated), decision logs showing every deployment attempt, proof that violations were blocked (immutable logs), and evidence of when issues were fixed (new ModelKit versions with passing metrics).
Section 4: Implementation
The setup is fast. Deploying Jozu Hub takes about an hour (either through the hosted sandbox or on-premises via Helm chart). Creating your first ModelKit is a single CLI command (kit pack). Writing basic policies takes minutes.
Organizational rollout takes longer. Going from a working proof-of-concept to production enforcement across all teams takes about 1-2 weeks. This covers policy development for your specific compliance requirements, testing in audit mode to catch false positives, training data science and DevOps teams, and gradual rollout to production namespaces.
Step 1: Infrastructure Setup
Get Jozu Hub access through the hosted sandbox environment or the on-premises installation. The on-premises version is a Helm chart that deploys to your Kubernetes cluster and integrates with your existing container registry (ECR, Harbor, Artifactory) or uses its built-in registry.
Please note that Jozu's hosted sandbox environment is feature limited. To fully customize your instance of Jozu Hub, the self-hosted trial is required.
Install the KitOps CLI on your local machine:
# macOS
brew install jozu-org/tap/kit
# Linux
curl -L https://github.com/jozu-ai/kitops/releases/latest/download/kitops-linux-x86_64.tar.gz | tar xz
sudo mv kit /usr/local/bin/Deploy OPA as a server that Jozu Hub queries for policy decisions. Configure OPA to load policies from Git automatically using the bundle API.
Once the infrastructure is up, push a test ModelKit to Jozu Hub and watch automatic scanning run. The five integrated scanners execute without configuration. Just push and check the results.
Step 2: Create First ModelKit
Pick a pilot model that's already in production. Start with something simple to validate the workflow. You're packaging what's currently deployed, not changing behavior yet.
Create a Kitfile that describes the model:
manifestVersion: 1.0.0
package:
name: fraud-detection
version: 3.2.1
license: Apache-2.0
model:
path: ./model.pkl
framework: xgboost
code:
- path: ./inference.py
datasets:
- path: ./validation_sample.parquet
docs:
- path: ./model_card.md
parameters:
risk_level: medium
approved_by: alice@company.com
approval_date: "2026-01-15"Pack and push to Jozu Hub:
kit pack . -t jozu.yourcompany.com/fraud-model:3.2.1
kit push jozu.yourcompany.com/fraud-model:3.2.1Jozu Hub automatically scans on push. Review the scan results to understand what gets flagged in your environment. Common findings include outdated dependencies, license issues in transitive packages, or accidentally committed secrets.
Step 3: Write Initial Policies
Start with three Rego policies that encode rules you're already following manually.
License compliance:
package governance.licenses
allowed_licenses := {"Apache-2.0", "MIT", "Proprietary-Internal"}
deny[msg] {
not input.kitfile.package.license in allowed_licenses
msg := sprintf("License '%s' not approved", [input.kitfile.package.license])
}Security thresholds:
package governance.security
deny[msg] {
critical := input.attestations.vulnerability_scan.critical_count
critical > 0
msg := sprintf("Found %d critical vulnerabilities with available fixes", [critical])
}Approval validation:
package governance.approvals
deny[msg] {
input.kitfile.parameters.risk_level == "high"
not input.kitfile.parameters.approved_by
msg := "High-risk models require explicit approval"
}Test these locally with the OPA CLI using sample ModelKit metadata as test input. Verify policies catch violations correctly before deploying them to production.
Step 4: Audit Mode
Enable Jozu Hub's policy integration but configure it to log violations without blocking. Every push, pull, and deployment gets checked against OPA policies. Decisions are logged, but operations proceed even when policies fail.
Review the decision logs daily. Look at which policies trigger most frequently, whether there are false positives needing refinement, and whether teams understand the violation messages.
The most common tuning during audit mode involves three areas. License scanners tend to flag transitive dependencies, which you can handle by allowlisting specific acceptable versions. Approval metadata is often missing because teams need to update existing Kitfiles retroactively. And CVE thresholds are frequently too strict at first, so you'll want to adjust them to block only critical vulnerabilities with patches available.
Use this phase to refine policies before they start blocking production deployments. Share violation reports with teams so they know what's coming when you switch to enforcement.
Step 5: Enforcement and Training
Switch Jozu Hub to enforcement mode. When policies fail, operations are blocked. No more warnings, actual deployment gates.
Data scientists need to know how to create Kitfiles with governance metadata, where approval workflows live, and what to do when a deployment is blocked by policy. Platform engineers need to understand how to write OPA policies in Rego, where decision logs are stored, and how to troubleshoot policy evaluation issues. Compliance teams need to know how to audit decision logs, what evidence is available for regulators, and how the exception approval process works.
Start with a single production namespace. If that runs smoothly for two weeks, roll out to remaining namespaces incrementally.
Exception Handling
Sometimes legitimate reasons exist to bypass a policy: emergency hotfixes, approved exceptions for specific edge cases. Handle these with cryptographic signatures using Cosign.
The process works like this. A developer requests an exception with a business justification. A risk officer reviews and decides whether to approve. If approved, the risk officer signs the ModelKit with exception metadata:
cosign sign --key risk-officer.key \
--annotations exception-type=vulnerability-waiver \
--annotations reason="Emergency hotfix - CVE has no known exploit" \
--annotations approved-by=risk-officer@company.com \
--annotations expiry=2026-02-15T00:00:00Z \
jozu.yourcompany.com/fraud-model:3.2.1-hotfixOPA then checks for the valid exception signature before allowing deployment, and the decision is logged immutably with the exception details: who signed, the reason, and the expiry.
This creates an auditable exception process. You can query Cosign to see all exceptions granted, who approved them, and when they expire. When exceptions expire, policies automatically start blocking again. No manual tracking spreadsheets needed.
What You've Built
After implementation, you have automated scanning on every model push via Jozu Hub, policy gates enforcing governance rules via OPA, cryptographic signatures for approved exceptions via Cosign, an immutable audit trail meeting EU AI Act Article 12 and Article 72 requirements, and complete lineage from training data to production via ModelKits.
The system enforces compliance architecturally. If an artifact can't cryptographically prove it passed all checks, it doesn't deploy.
Section 5: ROI Analysis
Costs
The primary expense is the Jozu Hub Enterprise license, available as managed SaaS or on-premises installation. Implementation takes about 1-2 weeks with 2-3 engineers part-time covering infrastructure setup, policy writing and testing, rollout and training.
Ongoing maintenance averages 4 hours monthly: updating policies as regulations evolve, tuning thresholds based on false positives, and adding rules for new risks. Quarterly reviews align policy changes with organizational risk assessments.
Benefits
Risk mitigation: The EU AI Act imposes fines up to €35M or 7% of global revenue for systemic violations. For a €5B company, that's potentially €350M. Preventing a single compliance violation pays for the entire system.
Beyond regulatory fines, consider what a public incident costs: deploying a biased model or one with known vulnerabilities. Customer churn, legal settlements, and stock price impact often exceed the direct penalty. This system prevents violations before they happen by blocking non-compliant deployments at the infrastructure level.
Operational efficiency:
Manual model approval previously took 3-5 days of email threads and committee meetings. Now it's 30 seconds: push the ModelKit, policies evaluate automatically, deployment proceeds or blocks with specific feedback.
Compliance audits that required 2 weeks of assembling evidence from S3 logs, Git commits, email threads, and spreadsheets now take 2 days querying immutable decision logs that capture every deployment with timestamps and policy results. Security reviews that took 3-5 days per model as teams manually checked dependencies against CVE databases now complete in 30 seconds on every push, so security teams only review flagged exceptions.
For a team deploying 20 models monthly, this saves roughly 1,200 engineering hours annually (equivalent to half an FTE).
Proof Delivered
When regulators ask for evidence, you provide cryptographic proof rather than documentation that could be edited.
Complete lineage: Every ModelKit has a SHA-256 hash uniquely identifying its contents. Query any production model to retrieve the exact training data, code version (Git commit SHA), model artifact, approval signatures, and scan results, all cryptographically linked. This isn't a reconstruction from logs. It's architectural proof that what's running matches what was approved.
Enforcement proof: OPA decision logs capture every deployment attempt with nanosecond-precision timestamps, user identity, ModelKit hash, policies evaluated, and pass/fail results. For blocked models, logs show exactly why: "Demographic parity 0.73 below 0.80 threshold (EU AI Act Article 72)." For deployed models, logs prove all policies passed. Non-compliant models have no deployment logs because the infrastructure refused to run them.
Human oversight: Cosign signatures provide tamper-proof evidence of exceptions. When a risk officer approves deploying with a medium-severity CVE for an emergency hotfix, they cryptographically sign the ModelKit with their identity, exception type, justification, and expiry date. Query Cosign to see who signed, what they approved, and when it expires. If someone modifies the ModelKit after signing, verification fails.
Traditional governance asks regulators to trust your documentation. Cryptographic governance provides proofs regulators can verify independently.
Section 6: Takeaways
Manual compliance can't match AI velocity. Models deploy hourly while spreadsheets update weekly. The gap creates shadow AI deployments you can't audit.
Policy-as-Code makes governance infrastructure. When policies live in Rego, they're version-controlled, testable, and automated. Compliance becomes a deployment requirement, not a post-deployment hope.
1-2 weeks to implement with proven technology. KitOps, Jozu Hub, and OPA are production-ready tools solving this problem today. No research projects, no building from scratch.
Bottom Line
Spreadsheets = hope. Code = proof. Regulators want proof.
Real-world validation: See how organizations are implementing this approach in practice: https://jozu.com/case-study/
Resources
Documentation:
KitOps for ModelKit packaging and Kitfile format, Jozu Hub for security scanning and attestation management, Open Policy Agent for the policy engine and Rego language, OPA Gatekeeper for Kubernetes admission control, Cosign for artifact signing and verification, and Kubernetes Documentation for the container orchestration platform.
Specifications:
OCI Distribution Spec for the container registry standard, SPDX 3.0 for software bill of materials format, and Rego Language Reference for policy syntax.
Regulatory References:
EU AI Act full text and article-by-article analysis, Article 12 on automatic logging requirements, Article 72 on post-market monitoring, ISO/IEC 42001:2023 for AI management systems, and NIST AI Risk Management Framework for AI risk assessment.
Policy Examples:
OPA Policy Library for pre-built templates, Gatekeeper Policy Library for Kubernetes-specific policies, and Rego Playground for testing policies in the browser.
Real-World Examples:
Jozu Case Studies for production implementations, and KitOps Examples for sample Kitfiles and workflows.
Community & Support:
OPA Slack for policy questions and troubleshooting, KitOps GitHub for issues, discussions, and contributions, CNCF AI/ML TAG for the cloud-native AI working group, and Jozu Discord for ModelKit and Jozu Hub support.