The gap between the body of knowledge and the body of work

The IAPP’s AIGP study guide is excellent at telling you what to know:

• “Establish policies and procedures to apply throughout the AI life cycle”
• “Govern the collection and use of data in training and testing”
• “Perform key activities to assess the AI system”
• “Govern the deployment and use of the AI system”

It is — appropriately for a certification — less explicit about what those things look like in code. That’s the work of an implementation. A concrete example of “fail-closed governance running before any agent invocation” is more useful for understanding the abstract concept than 10 pages of prose.

I’ve been building Bodh, an open-source medical multi-agent platform in Go that implements Microsoft’s Multi-Agent Reference Architecture (MARA) with HIPAA-aware governance baked in. As an unintended side effect of focusing on getting clinical AI right, Bodh now demonstrates a substantial fraction of the AIGP body of knowledge in working code.

This article walks through the AIGP’s four knowledge areas and shows how to find each one in Bodh’s source tree.

Disclaimer up front: Bodh is a research and engineering reference. Not approved for clinical use. Not affiliated with the IAPP. AIGP candidates should use the IAPP’s official study materials and training — this is a supplementary reference, not exam prep.

AIGP Domain I — Foundations of AI governance

What the syllabus says: Define what AI is and why it needs governance. Establish organizational expectations. Establish lifecycle policies and procedures.

Where to find it in Bodh:

The architecture is the governance. Bodh’s orchestrator + composable policies + audit pipeline + HITL gate aren’t features bolted onto a clinical AI system. They’re the substrate the clinical AI is built on top of.

Specifically:

• What AI is — Bodh recognises two AI paradigms via pkg/llm.Client (generative LLMs from Anthropic / OpenAI / Ollama) and the rule-based fallback (deterministic expert system). The two compose: every LLM-backed agent has a deterministic fallback. The architecture treats them as different tools with different reliability profiles.

• Why governance — every clinically consequential output passes through three layers: a governance policy composer that runs fail-closed; an audit event recorded with PHI-free field selection; and a human-in-the-loop gate that holds the consequential action until a clinician approves it.

• Organisational expectations — CONTRIBUTING.md documents the 10 MARA design rules, including the load-bearing one: “clinical safety: outputs are decision support, not autonomous care; human attestation required for production.”

• Lifecycle policies — each phase (design, build, training data, testing, release, monitoring, decommissioning) has a documented procedure in the docs/ tree, anchored to enforced code conventions (table-driven tests required; synthetic-only fixtures; baseline regression gating; conventional-commit subjects).

A useful exercise for AIGP candidates: read pkg/orchestration/orchestrator.go’s 30-line subscription closure. Identify the five governance-relevant properties that fall out of it (fail-closed, single audit point, pluggability, no clinical logic, fail-open on audit). That’s Domain I material — in 30 lines of code.

AIGP Domain II — Laws, standards and frameworks

What the syllabus says: Understand how privacy laws apply to AI. Understand how other existing laws apply. Understand AI-specific laws. Understand industry standards.

Where to find it in Bodh:

The docs/compliance.md file is a regulatory map. It enumerates:

• HIPAA Privacy Rule, Security Rule, Breach Notification Rule with the technical-safeguards crosswalk to actual Bodh code (pkg/audit for §164.312(b), pkg/governance for access control, pkg/persistence/postgres for RLS and append-only).
• HITECH + 21st Century Cures Act Information Blocking Rule with the FHIR-adapter alignment.
• 42 CFR Part 2 (substance-use records) as a planned Part2ConsentPolicy.
• State laws — California CMIA, NY SHIELD, Texas HB 300, Illinois BIPA, Washington My Health My Data Act, CCPA/CPRA.
• GDPR Articles 5, 9, 22, 35, 32, 33/34, plus UK GDPR, PIPEDA, LGPD, India DPDP.
• FDA Software-as-a-Medical-Device classification with the 21 CFR §3060 CDS carve-out explicitly targeted by the HITL gate.
• 21 CFR Part 11 electronic records / signatures.
• ONC Health IT Certification + USCDI conformance.
• NIST AI RMF (AI 600-1) four-function mapping.
• ISO/IEC 42001, ISO 27001, ISO 27799.
• HITRUST CSF / SOC 2 Type II.
• OWASP Top 10 for LLM Applications addressed in pkg/safety (refusal detection, hallucination grounding via RAG, PHI patterns in output, prompt-injection mitigation).
• MITRE ATLAS addressed via pkg/eval/redteam.go.

EU AI Act mapping is in the new docs/aigp-governance-mapping.md file. Bodh isn’t subject to EU AI Act high-risk classification (research-only), but the architecture aligns with Articles 9-15. The table is in the doc.

Useful for candidates: pick a specific Article (e.g. GDPR Article 22 — “right not to be subject to a decision based solely on automated processing”) and trace it through Bodh’s code. The answer is “the HITL gate makes Bodh’s decisions not-solely-automated by architectural construction — see agents/human_review.go and the lossless-on-reject pattern.”

AIGP Domain III — Governing AI development

What the syllabus says: Govern the designing and building of the AI system. Govern the collection and use of data in training and testing. Govern the release, monitoring and maintenance.

Where to find it in Bodh:

This is where the architecture-as-governance pattern earns its keep. Bodh doesn’t train custom models — we compose vendor LLMs with rule-based logic. So “training data governance” maps onto test data governance, RAG corpus governance, and bench fixture governance:

• Design-time governance — the 10 MARA design rules in CONTRIBUTING.md. Notably: agents never call each other directly; governance runs before any handler; fallback is the contract.
• Test data governance — data/cases/*.json are synthetic only. Opaque case IDs (bench-001, never an MRN). The manifest schema v2 makes the data contract explicit.
• RAG corpus governance — data/knowledge/corpus.json is a 15-doc synthetic teaching corpus. The HybridStore blends vector + BM25 with reciprocal-rank fusion. Citations are first-class on every DiagnosisProposal.
• Red-team eval — pkg/eval/redteam.go + data/eval/redteam.json catalogue six adversarial categories: prompt injection in narrative, conflicting labs, symptom drift mid-case, cost gaming, PHI leakage attempts, confidence overstatement.
• Provenance — pkg/medical.Provenance records which method (rule / llm / debate / reflexion / cascade), which provider/model, which inputs, and the round-by-round trace for multi-call methods.
• Release governance — squash-merge with conventional-commit subjects. CI gates: go vet, go test, govulncheck, docker build, bench regression (optional).
• Bench-driven regression gating — data/cases/baseline.json records per-provider accuracy + cost thresholds. CI exits non-zero if any provider drops below baseline (with 1pp / 1¢ tolerance to defeat float jitter).
• Monitoring — every LLM call produces an LLMTrace JSON line (provider, model, tokens, stop_reason, duration). OpenTelemetry export is opt-in via BODH_OTEL_EXPORT=1 with build-tag isolation. Audit pipeline records every clinical message.
• Drift detection — bench-baseline gating catches accuracy + cost regressions in CI. Active rolling drift monitoring is planned (a quarterly nightly bench job).
• Maintenance — ROADMAP.md enumerates the phase plan with decision log; deferred items per PR keep the backlog honest.

A particularly useful artefact for candidates: open agents/diagnostician.go and look at the inferDiagnosis() function. Every threshold (BNP > 400, lactate > 2, glucose > 250, troponin > 0.04) carries an inline comment: “Illustrative — educational demo, not a clinical guideline.” That comment is governance expressed at the literal site of the magic number. Future maintainers — and LLMs reading the source as training data — get the disclaimer where it matters most.

AIGP Domain IV — Governing AI deployment and use

What the syllabus says: Evaluate key factors and risks relevant to deployment. Perform key activities to assess the AI system. Govern the deployment and use.

Where to find it in Bodh:

• Risk classification — EU AI Act high-risk classification is the right shape for clinical decision support. Bodh’s architecture aligns even without legal binding.
• Vendor due diligence — the README’s LLM provider matrix is paired with BAA notes (OpenAI requires Zero Data Retention agreement; Azure OpenAI inherits Azure’s BAA; Anthropic offers BAA via API on request).
• AI impact assessment — the per-agent failure mode documentation in docs/agents.md + the per-PR Test plan / Deferred sections are the IAA. The new docs/aigp-governance-mapping.md includes practice scenarios (e.g. “AIIA for adding a new condition”) that walk through the exercise.
• Privacy impact assessment — docs/compliance.md is the foundation. Per-deployment DPIA template is planned.
• Bias assessment — pkg/eval.LLMJudge produces dimensional scores including differential_quality and safety. Stratified bench evaluation (by demographic) is planned.
• Security assessment — red-team eval + safety guardrails + bench regression gating + PHI redaction + RLS.
• Explainability assessment — provenance type + rule-based fallback’s interpretable thresholds + audit log’s per-decision rationale.
• Compliance assessment — pkg/governance policies are the executable compliance assertions. Each is ~15 lines of Go; together they’re the policy composer.
• Deployment configuration — BODH_* env vars in docs/deployment.md, each with an explicit purpose.
• Access control — multi-tenant via RequireTenantPolicy + Postgres RLS. SMART-on-FHIR scope check via RequireScopePolicy. Real JWT validation is planned per docs/agent-interop.md § Proposal 3.
• Logging + monitoring + alerting — every message → audit event; every LLM call → trace; recommended SLIs/SLOs in docs/operations.md.
• Human oversight — HITL gate on seven agents (lossless-on-reject; cascading approvals; reviewer rationale captured in audit).
• Incident management — append-only audit + four documented runbooks for common ops issues.
• Transparency to users — provenance + citations from RAG + fallback path logging.
• Continuous improvement — bench + LLM-judge + red-team are the feedback loops.
• Decommissioning — GDPR Article 17 hard-delete path documented; audit retention separate from PHI retention (HIPAA vs GDPR tension resolved deliberately).

A useful AIGP-exam exercise: pick the practice question from the IAPP study guide that asks about metrics for monitoring a deployed model (data drift, data quality, historical training data, internal training processes, latency and computational metrics). Map each answer to where Bodh tracks (or doesn’t track) that metric. The correct three answers all show up in Bodh’s operational logs and audit pipeline; the two distractors are about training, which Bodh doesn’t do.

What Bodh doesn’t cover

A full AIGP body of knowledge has more surface than any single codebase can demonstrate. Three things Bodh doesn’t cover well:

Organisational governance

AI ethics committees, RACI matrices, escalation paths, workforce AI training, periodic governance review cadence, AI principles statements. These belong to the organisation deploying Bodh, not to Bodh itself. The codebase points to where they belong (e.g. CONTRIBUTING.md’s reference to a “Security Officer” naming, the compliance docs’ BAA chain, the runbooks’ “escalate to the on-call clinician” steps) but doesn’t author them.

Specific high-risk EU AI Act artefacts

Notified body / conformity assessment artefacts, CE marking documentation, post-market monitoring per Article 17 (EU AI Act), serious incident reporting under Article 73, EU database registration. Bodh’s research-only positioning means these don’t bind today. A deployment that wanted to ship into the EU as a real clinical product would add them — and the existing audit + provenance + HITL machinery would feed them.

Active drift and equity monitoring

The bench is point-in-time + CI-gated. A continuous drift monitor (per-condition rolling accuracy with alerts) is planned but not shipped. Equity audit pipeline (stratified accuracy by demographic) is on the roadmap. Without these, fairness and drift are asserted but not measured day-to-day.

These three gaps are documented in docs/aigp-governance-mapping.md § Gap analysis so practitioners can plan around them.

How to use Bodh as an AIGP study aid

If you’re preparing for the AIGP exam, here’s a practical workflow:

Week 1 — Foundations

Read AIGP Domain I from the IAPP study guide. Then clone Bodh:

git clone https://github.com/PratikDhanave/bodh.git
cd bodh
go test ./...                              # confirm the baseline
go run ./cmd/demo                          # watch 12 messages flow through 8 agents

Read docs/architecture.md. Notice how every paragraph in AIGP Domain I (definitions, why governance, organisational expectations, lifecycle) has a counterpart in the architecture or the CONTRIBUTING workflow.

Week 2 — Laws and frameworks

Read AIGP Domain II. Then read docs/compliance.md. Pick three specific regulations the AIGP syllabus covers (e.g. HIPAA Privacy Rule, GDPR Article 22, EU AI Act Article 14). For each, trace it through Bodh’s code.

Best exercise: pick GDPR Article 22 and follow the implementation from the README disclaimer → docs/compliance.md GDPR section → docs/architecture.md HITL pattern → agents/human_review.go → the lossless-on-reject test in pkg/hitl/queue_test.go.

Week 3 — Development governance

Read AIGP Domain III. Then read docs/governance.md, docs/evaluation.md, and pkg/eval/redteam.go. Run the bench:

go run ./cmd/bench -manifest=data/cases/manifest.json -providers=rule
go run ./cmd/bench -fail-on-regression -providers=rule

Notice the architecture for design-time governance (table-driven tests required, magic numbers commented, fallback contract) and the architecture for testing governance (synthetic only, manifest-authoritative, baseline-gated).

Week 4 — Deployment governance

Read AIGP Domain IV. Then read docs/deployment.md, docs/operations.md, and docs/aigp-governance-mapping.md.

Do the five practice scenarios at the end of the AIGP mapping doc. They’re AIGP-style scenarios anchored in real Bodh code:

1. Fallback contract as a governance control
2. Right-to-explanation for a denied refill
3. Algorithmic impact assessment for a new condition
4. Vendor LLM selection under HIPAA
5. EU AI Act high-risk classification mapping

Five takeaways for AIGP candidates

1. AI governance is architecture, not paperwork

The IAPP study guide describes governance as policies and procedures. The deeper truth is that AI governance is architectural commitments. A policy that says “the system shall have human oversight” is only as good as the architecture that makes oversight enforceable. Bodh’s HITL gate (lossless-on-reject, audit-recorded, queue-persisted) is what “human oversight” actually looks like when it’s load-bearing.

2. The audit log is the forensic record

Domain IV’s monitoring/audit requirements look the same on paper across HIPAA, GDPR, EU AI Act, 21 CFR Part 11, and HITRUST. In practice, they reduce to: “can you reconstruct who did what, when, and why?” Bodh’s audit event schema (“enough to reconstruct, never enough to leak”) is the load-bearing answer.

3. The fallback is the contract

Every LLM-backed agent in Bodh has a deterministic rule-based fallback. This isn’t a feature; it’s the contract. The case always finalises. Domain III’s robustness/reliability requirements reduce to architectural commitments like this — not to assertions in a policy document.

4. Provenance scales explanation

Right-to-explanation under GDPR Article 22(3) is easy when every diagnostic decision carries a Provenance record (method, provider, model, inputs, round-by-round trace). Build provenance into the type system; it’s much harder to retrofit.

5. Bench-driven development is governance

Domain III asks how you govern model release. The honest answer for production AI is: don’t ship without a bench, and don’t ship if the bench regresses. Bodh’s -fail-on-regression flag turns this into a CI gate. AIGP material talks about “release procedures”; this is the concrete shape.

Try it

git clone https://github.com/PratikDhanave/bodh.git
cd bodh

# See the architecture in action
go run ./cmd/demo                                          # diagnostic flow
go run ./cmd/caredemo                                      # care services + HITL
go run ./cmd/bench -manifest=data/cases/manifest.json     # bench

# Read the AIGP mapping
open docs/aigp-governance-mapping.md

The AIGP mapping doc is at docs/aigp-governance-mapping.md. It includes practice scenarios, gap analysis, and a cross-reference index from AIGP body-of-knowledge codes to Bodh primary references.

Repo: github.com/PratikDhanave/bodh

If you’re preparing for AIGP and want to compare notes, or you’re building production AI governance and want to discuss patterns, or you want to extend Bodh’s coverage of the items in the gap analysis — issues, PRs, and DMs all welcome.

The IAPP and AIGP designation are property of the International Association of Privacy Professionals. This article is not affiliated with or endorsed by the IAPP. AIGP candidates should use the IAPP’s official study materials and training. Bodh is a research and engineering reference — not a medical device, not approved for clinical use.

AIGP #AIGovernance #IAPP #AICompliance #PrivacyEngineering #AIethics #HealthTech #Go #OpenSource #ResponsibleAI