Compliance
EU AI Act enforcement, Federal Compliance (NIST, FedRAMP, CMMC), Governance Proof Tokens, the model inventory, and the Policy Registry.
EU AI Act Compliance
The EU AI Act's high-risk requirements apply from 2 December 2027 for Annex III systems, and from 2 August 2028 for AI in Annex I products (Digital Omnibus on AI, Regulation (EU) 2026/1744). GaaS implements five governance policies covering Articles 9, 10, 13, 14 and 15, giving high-risk AI deployments a compliance-ready audit trail from day one.
Implemented Policies
| Policy ID | Article | Name | Failure Mode |
|---|---|---|---|
pol_euaia_001 |
Art. 9 | Risk Management System | FAIL |
pol_euaia_002 |
Art. 10 | Data Governance & Management | CONDITIONAL |
pol_euaia_003 |
Art. 13 | Transparency & Information | CONDITIONAL |
pol_euaia_004 |
Art. 14 | Human Oversight | FAIL CRITICAL |
pol_euaia_005 |
Art. 15 | Accuracy, Robustness & Cybersecurity | FAIL |
healthcare, critical_infrastructure, education, employment, essential_services, law_enforcement, migration, justice.
API Endpoints
- GET /v1/compliance/eu-ai-act — Current compliance status for your organisation
- GET /v1/compliance/eu-ai-act/report — Full compliance report with policy-level detail
Compliance Status Response
// GET https://api.gaas.is/v1/compliance/eu-ai-act
// X-API-Key: your_api_key
{
"compliance": {
"org_id": "org_abc123",
"assessed_at": "2026-09-28T18:30:00",
"overall_status": "partial",
"implemented_count": 6,
"partial_count": 4,
"requires_action_count": 1,
"not_applicable_count": 0,
"high_risk_ai_detected": true,
"enforcement_deadline": "2027-12-02",
"articles": [
{
"article": "Article 9",
"title": "Risk management system",
"requirement": "Establish, implement, document and maintain a risk management system throughout the lifecycle of the high-risk AI system.",
"status": "implemented",
"gaas_capability": "GaaS governance membranes define the risk boundary for each AI agent. The 5-stage pipeline (intent validation → enrichment → policy evaluation → deliberation → decision assembly) constitutes the risk management system. Audit trail provides lifecycle documentation.",
"evidence": [
"GET /v1/membranes/current",
"GET /v1/audit/chain/verify",
"pol_euaia_001"
],
"notes": null
}
// … one entry per article
]
}
}
Federal Compliance
GaaS maps governance controls to four major US federal frameworks, enabling AI systems to satisfy procurement and security requirements for government agencies and defense contractors.
NIST AI Risk Management Framework 1.0
Maps to all 4 NIST AI RMF functions (GOVERN, MAP, MEASURE, MANAGE) across 23 subcategories. GaaS provides automated evidence generation for each subcategory based on live pipeline data.
- GET /v1/compliance/nist-ai-rmf — Current NIST AI RMF status
- GET /v1/compliance/nist-ai-rmf/report — Full report with subcategory-level detail
NIST SP 800-53 Rev. 5 Moderate Baseline
5 enforcement policies (pol_nist800_001–005) covering 4 control families: Access Control (AC), Audit & Accountability (AU), System & Information Integrity (SI), and Incident Response (IR).
- GET /v1/compliance/nist-800-53 — Current NIST 800-53 status
- GET /v1/compliance/nist-800-53/report — Full report with control-family detail
FedRAMP Moderate Baseline
5 enforcement policies (pol_fedramp_001–005) for cloud services selling to US federal agencies. Includes 3PAO-ready evidence packages with NIST SP 800-53A assessment procedures.
- GET /v1/compliance/fedramp — Current FedRAMP status
- GET /v1/compliance/fedramp/report — Full FedRAMP report
CMMC 2.0 Level 1–2
4 enforcement policies (pol_cmmc_001–004) covering Level 1 (basic safeguarding of Federal Contract Information) and Level 2 (advanced protection aligned to NIST SP 800-171 Rev. 2) for Defense Industrial Base contractors.
- GET /v1/compliance/cmmc — Current CMMC status
- GET /v1/compliance/cmmc/report — Full CMMC report
Federal Procurement Summary
A single endpoint that aggregates compliance status across all four frameworks, plus 3PAO evidence packages per control.
- GET /v1/compliance/federal — Combined federal procurement readiness summary
- GET /v1/compliance/federal/evidence/{control_id} — 3PAO evidence package for a specific control (ControlEvidencePackage with NIST SP 800-53A assessment procedures)
SOC 2 Control Mapping
GaaS maps 20 SOC 2 Trust Services Criteria controls (CC1–CC9 and
Availability) to concrete platform capabilities, each with API evidence endpoints and
[EXAMINE/TEST] assessment procedures. This is a control mapping to
support your own SOC 2 audit — it is not a SOC 2 attestation of GaaS, and
statuses are honest: controls with open gaps (e.g. a formal penetration-testing program)
report partial, not implemented.
Fetch any control's evidence package via
GET /v1/compliance/federal/evidence/{control_id} (e.g. CC6.1
logical access, CC8.1 change management, A1.2 recovery
infrastructure). Evidence endpoints include the hash-chained audit export, chain
verification, SLO reports, and the policy registry.
ISO/IEC 42001 Control Mapping
GaaS maps 15 ISO/IEC 42001 Annex A controls (AI policy, internal
organization, resources, impact assessment, life cycle, data, transparency, responsible
use, and third parties) to platform capabilities with API evidence endpoints and
[EXAMINE/TEST] assessment procedures. This is a control mapping to
support your AI management system audit — it is not an ISO/IEC 42001
certification of GaaS, and statuses are honest: incomplete capabilities (e.g. independent
model validation, automated sub-processor notification) report partial.
Fetch any control's evidence package via
GET /v1/compliance/federal/evidence/{control_id} (e.g. A.2.2
AI policy via governance membranes, A.5.2 impact assessment via
six-dimensional risk scoring, A.6.1.2 life cycle via the membrane
DRAFT→SHADOW→LIVE progression).
Exporting Evidence for Your GRC Platform
Pull every control evidence row — across NIST AI RMF, NIST SP 800-53, FedRAMP, CMMC, NIST CSF, SOC 2 TSC, and ISO/IEC 42001 — in one call for manual upload to Vanta, Drata, or any GRC platform:
GET /v1/compliance/evidence/export?framework=SOC%202%20TSC&format=csv
Omit framework for all frameworks. format=csv returns one row
per control (id, family, title, requirement, status, capability, evidence endpoints,
assessment procedures, last assessed) with a download filename;
format=json returns the full evidence packages. Operator role required.
Governance Proof Tokens
When a GaaS deployment has a signing key configured, every live decision carries a
Governance Proof Token (GPT) in decision.governance_proof_token: a signed record of
what was decided, for which agent, and which audit record anchors it. Every field is signed, so changing any of
them — the verdict, the organization, the audit hash — breaks the signature. Shadow and test decisions get no token.
Anyone holding a token can check it: an auditor, a regulator, an insurer, or the other party to a transaction. They need no GaaS account.
Token Fields
| Field | Description |
|---|---|
token_id |
Random UUID4. Anyone holding it can check the token. |
issued_at |
When GaaS issued the token (UTC). |
decision_id / intent_id |
The decision and intent this token covers. |
agent_id / org_id |
The agent that asked, and its organization. |
verdict |
The decision's verdict as the API returns it: approve, approve_modified, block or escalate. |
pipeline_mode |
Always live: shadow and test decisions get no token. |
policies_evaluated / policies_passed |
How many policies ran, and how many passed. |
risk_score / risk_classification |
The decision's risk score (0.0–1.0) and class. |
audit_ref / audit_hash |
The audit record the decision is anchored to, and that record's hash in the tamper-evident audit chain. |
key_id |
Which signing key; matches kid in /.well-known/gaas-audit-keys.json. |
gaas_signature |
ECDSA P-256 with SHA-256, DER-encoded, hex — over every other field (see below). |
Checking a token online
-
GET
/v1/verify/proof/{token_id}
— Public, no API key. Checks the signature, and that the anchoring audit record still matches
audit_hash. 404 when no token has that id. - GET /.well-known/gaas-audit-keys.json — Public. The signing key as a JWK Set (also as PEM), for checking offline.
Example token
{
"token_id": "ea3fb059-42d6-4663-b9a5-366aefa536f0",
"issued_at": "2026-09-28T18:45:17.265864Z",
"decision_id": "dec_001d59151d7b4d629c482c5544e6c93f",
"intent_id": "int_94fb1d4e6e034df287c112d2dd81340d",
"agent_id": "agent_farm_bot",
"org_id": "org_default",
"verdict": "approve",
"pipeline_mode": "live",
"policies_evaluated": 10,
"policies_passed": 10,
"risk_score": 0.0001,
"risk_classification": "low",
"audit_ref": "aud_05f7496b8a614707b135b822905368f2",
"audit_hash": "25a4fef2a81c9872b30609828ad092a50ae69f5da03f873f8c0e340399999fa5",
"key_id": "b3e18dff8282417d",
"gaas_version": "0.3.0",
"gaas_signature": "3046022100a4d7519db157a1e049526e7f391509607d6a05ddc5e4141ee63be486a8e4d5420221009ac5c64e2dde91721b140150fe1161d165dd4e4d45205ea6646ff56e985e3a60"
}
Example check
// GET https://api.gaas.is/v1/verify/proof/ea3fb059-42d6-4663-b9a5-366aefa536f0 (no API key; "token" field omitted here)
{
"token_id": "ea3fb059-42d6-4663-b9a5-366aefa536f0",
"valid": true,
"signature_valid": true,
"chain_integrity": true,
"verdict": "approve",
"agent_id": "agent_farm_bot",
"org_id": "org_default",
"issued_at": "2026-09-28T18:45:17.265864Z",
"key_id": "b3e18dff8282417d",
"error": null
}
Checking a token offline
The signed bytes are the token's JSON with gaas_signature removed, keys sorted, and no whitespace.
The signature is ordinary ECDSA P-256 / SHA-256 over those bytes, so any crypto library can check it:
# Python (pip install cryptography)
import json
from cryptography.hazmat.primitives import hashes, serialization
from cryptography.hazmat.primitives.asymmetric import ec
token = json.load(open("token.json"))
signature = bytes.fromhex(token.pop("gaas_signature"))
payload = json.dumps(token, sort_keys=True, separators=(",", ":")).encode()
key = serialization.load_pem_public_key(open("gaas-audit-key.pem", "rb").read()) # "pem" in the JWK
key.verify(signature, payload, ec.ECDSA(hashes.SHA256())) # raises InvalidSignature if anything changed
# Or with jq 1.7+ (it keeps numbers exactly as written) and OpenSSL
jq -cS 'del(.gaas_signature)' token.json | tr -d '\n' > payload.json
jq -r .gaas_signature token.json | xxd -r -p > signature.der
openssl dgst -sha256 -verify gaas-audit-key.pem -signature signature.der payload.json # Verified OK
Model Inventory
GaaS auto-generates an inventory of every AI agent in your organization from agent profiles and live audit data — purpose, owner, validation status and decision history — for your model risk management, with no spreadsheet required.
On SR 11-7: the inventory was built for the Federal Reserve's SR 11-7 and OCC Bulletin 2011-12. Both were rescinded on 17 April 2026 by SR 26-2 and OCC Bulletin 2026-13, “Revised Guidance on Model Risk Management”, which states that generative and agentic AI models are not within its scope. GaaS does not claim the inventory meets a supervisory letter.
Validation Status Mapping
| GaaS Agent Status | Inventory Validation Status |
|---|---|
CERTIFIED |
VALIDATED — Model has passed full independent validation |
VERIFIED |
IN_VALIDATION — Validation in progress; compensating controls active |
REGISTERED |
PENDING_VALIDATION — Model registered but not yet submitted for validation |
API Endpoints
- GET /v1/model-inventory — Full model inventory for your organisation
- GET /v1/model-inventory/{agent_id} — Inventory record for a single agent
Example
# GET https://api.gaas.is/v1/model-inventory/agent_fintech_01
# X-API-Key: your_api_key
{
"agent_id": "agent_fintech_01",
"model_name": "Payment Authorisation Agent v2.3",
"model_type": "decision_engine",
"owner": "treasury@acme-bank.com",
"purpose": "Real-time payment fraud scoring and authorisation",
"sr117_status": "VALIDATED",
"gaas_status": "CERTIFIED",
"last_validation_date": "2026-01-15",
"next_review_date": "2026-07-15",
"decisions_last_90d": 48391,
"block_rate": 0.023,
"escalation_rate": 0.004,
"audit_coverage": "100%"
}
Policy Registry
The Policy Registry is npm for AI governance — a curated catalogue of versioned, composable policy packs that you can install into your membrane with a single API call. Packs are maintained by the GaaS team and the community, pinned to a semver, and verified for compatibility before installation.
Seed Packs
| Pack ID | Description | Policies |
|---|---|---|
gaas-core-v1 |
Foundational governance policies for all AI deployments | 10 |
gaas-healthcare-v1 |
HIPAA patient access, minimum necessary, TCPA consent for patient communications | 3 |
gaas-financial-v1 |
SOX, AP2 payment mandates and spend limits, PCI DSS, PSD2 SCA, AML velocity | 8 |
gaas-privacy-v1 |
GDPR lawful basis, CCPA opt-out, FERPA education records | 3 |
gaas-eu-ai-act-v1 |
EU AI Act Articles 9/10/13/14/15 for high-risk systems | 5 |
gaas-nist-csf-v1 |
NIST Cybersecurity Framework 2.0 | 5 |
gaas-nist-800-53-v1 |
NIST SP 800-53 Rev. 5 Moderate Baseline (AC, AU, SI, IR) | 5 |
gaas-fedramp-moderate-v1 |
FedRAMP Moderate Baseline with 3PAO evidence packages | 5 |
gaas-cmmc-v1 |
CMMC 2.0 Level 1–2 for Defense Industrial Base | 4 |
API Endpoints
- GET /v1/policy-registry — Search and browse available policy packs
- GET /v1/policy-registry/{pack_id} — Full details and changelog for a specific pack
- POST /v1/policy-registry/{pack_id}/install — Install a pack into your active membrane
Installing the EU AI Act Pack
# Install the EU AI Act pack
# POST https://api.gaas.is/v1/policy-registry/gaas-eu-ai-act-v1/install
# X-API-Key: your_api_key
{
"membrane_id": "mem_xyz789",
"version": "1.0.0"
}
// Response
{
"status": "installed",
"pack_id": "gaas-eu-ai-act-v1",
"version": "1.0.0",
"policies_added": ["pol_euaia_001", "pol_euaia_002", "pol_euaia_003", "pol_euaia_004", "pol_euaia_005"],
"membrane_id": "mem_xyz789",
"effective_from": "2026-08-01T00:00:00Z",
"requires_restart": false
}
Audit Reconstruction & Verification
GaaS provides auditor-facing endpoints for independently verifying governance decisions without live system access. Download self-contained verification bundles (ZIP archives) or retrieve structured decision reconstructions with inline hash verification.
Verification Bundles
Verification bundles are ZIP archives containing audit records, governance proof tokens,
a self-contained Python verification script (verify.py), and a manifest.
Auditors can verify hash chain integrity and cryptographic signatures offline.
- GET /v1/audit/{audit_id}/verification-bundle — Download verification bundle for a single audit record (ZIP)
-
GET
/v1/audit/verification-bundle
— Download verification bundle for a date range. Query params:
start_date,end_date,limit(1–1000),offset
Decision Reconstruction
Returns a structured JSON report for a governance decision, including all 5 pipeline stages, inline SHA-256 hash re-verification, and chain position validation. Suitable for regulators who need to understand exactly how a decision was made.
- GET /v1/audit/{audit_id}/reconstruction — Reconstruct a governance decision with inline hash verification
operator role or above.
Related Pages
- GDPR Compliance — Data subject rights, erasure, and sub-processor notifications
- Policies — Full policy catalogue and tier structure
- API Reference — Complete endpoint documentation
- Advanced Features — Audit trail, webhooks, and observability
Ready to achieve EU AI Act compliance?
Provision your governance membrane in under five minutes and have all five EU AI Act policies active before August 2026.
Get started free →