Skip to content

Compliance profiles#

A compliance profile is a switch at the top of every pipeline that loads a regulator-aligned bundle: guardrail agents, YAML permission policies, required artefacts, and the audit-PDF template.

Today shipping: RBI FREE-AI (India BFSI), HIPAA (US healthcare), EU AI Act high-risk. SOC 2 controls map is included as a generic baseline.

Picking a profile#

From the CLI:

swarm pipelines run \
  --problem "Fraud detection" \
  --dataset transactions.csv \
  --template default_ml_pipeline \
  --compliance rbi_free_ai       # or hipaa | eu_ai_act_high_risk | none

Dashboard: Pipelines → New → Compliance profile.

What a profile does#

  1. Injects guardrail agents — e.g. RBI profile inserts fairness_auditor + model_card_writer + audit_logger.
  2. Enables specific feature flags — e.g. auto_fairness_audit, require_shap_explanations, audit_trail_security_events.
  3. Loads permission policies — e.g. HIPAA loads permission_policies_hipaa.yaml which denies export_raw_data and masks PHI in POST_TOOL hooks.
  4. Enforces required artefacts — pipeline can't complete without model card, SHAP explanation, fairness audit results.
  5. Selects the audit-PDF template — regulator-format output keyed to the right schema.

Profiles shipped#

rbi_free_ai (India BFSI)#

Covers all 7 Sutras of RBI FREE-AI Guidelines.

Sutra swarm enforcement
1. Trust-building audit_trail_security_events invariant; PDF signed
2. Human oversight require_approval gates on deploy, promote
3. Safety & robustness drift_check injected post-deploy; smoke_test pre-deploy
4. Fairness & non-discrimination fairness_auditor agent + fairness_audit tool on protected attributes
5. Accountability OIDC SSO + per-action user attribution
6. Inclusive innovation Plugin ecosystem enabled
7. Explainability explain_model + generate_model_card required artefacts

See Compliance: RBI FREE-AI for full evidence mapping.

hipaa (US healthcare)#

Maps to 45 CFR § 164.312 Technical Safeguards:

Safeguard swarm enforcement
§ 164.312(a)(1) Access control RBAC + per-agent tool allowlists
§ 164.312(b) Audit controls permission_denials + run_events + conversation JSONL
§ 164.312(c)(1) Integrity SHA-256 pin on model + audit PDF
§ 164.312(d) Person/entity auth OIDC SSO required
§ 164.312(e) Transmission security TLS required on all external egress

Plus: PHI-redacting POST_TOOL hook on tool outputs; export_raw_data denied by policy.

See Compliance: HIPAA.

eu_ai_act_high_risk (EU AI Act Annex III)#

Covers the requirements that apply when swarm is used for high-risk AI per Annex III:

Article swarm enforcement
Art. 9 Risk management Pipeline produces a risk assessment document alongside model card
Art. 10 Data governance Data profiler + data validator agents run every pipeline
Art. 11 Technical documentation Annex IV template auto-populated from run events
Art. 12 Record-keeping 6-month retention minimum (enforced by retention daemon)
Art. 13 Transparency Model card in human-readable form for deployer
Art. 14 Human oversight HITL gates configurable per tool
Art. 15 Accuracy, robustness, cybersecurity Drift + smoke + adversarial tests in pipeline

Conformity assessment by a notified body is NOT automated — swarm produces the evidence bundle the notified body will ask for.

See Compliance: EU AI Act.

soc_2 (generic controls map)#

Not a regulatory profile but useful as a baseline. Maps every swarm feature to SOC 2 TSC controls (CC1-CC9, Availability, Confidentiality). Reference for audit prep.

See Compliance: SOC 2 controls.

What gets produced#

Regardless of profile, a compliance-enabled pipeline outputs:

pipeline_runs/{run_id}/audit/
├── audit_report.pdf        # regulator-format, profile-specific
├── audit_report.sig        # detached signature + manifest of included files
├── model_card.md           # human-readable model card
├── fairness_audit.json     # fairness metrics, if applicable
├── shap_explanation.json   # global + local feature importances
├── drift_baseline.json     # baseline for future drift comparisons
└── evidence_bundle.tar.gz  # everything, tamper-evident (SHA-256 pin)

Custom profiles#

BFSI customers typically want their own internal governance profile on top of the regulator one. Build one at config/permission_policies_<org>.yaml and reference it in pipeline config:

compliance_profile: rbi_free_ai
additional_policies:
  - permission_policies_acme_bank.yaml

Policies stack additively; stricter rule wins. See YAML reference: permission-policies.

Why compliance as a profile, not a framework#

Because compliance is pluggable. Every regulator has a slightly different format, slightly different evidence requirement, slightly different vocabulary. A profile-per-regulator model scales linearly as we add PCI-DSS, SEBI, NAIC, or regional variants — without touching the core pipeline code.

Next#