EU AI ActRegulation (EU) 2024/1689GDPRRegulation (EU) 2016/679DORADigital operational resilienceNIS2Network and information securityEU Cyber Resilience ActRegulation (EU) 2024/2847
CoE AI ConventionFramework Convention, CETS 225
NIST AI RMFAI Risk Management Framework 1.0
OECD AI PrinciplesCouncil Recommendation
SOC 2AICPA Trust Services Criteria
ISO/IEC 42001AI management system standardISO/IEC 27001Information security managementProduct · Capabilities
The enforcement layer between applications and AI execution: every request is verified, judged against consent and policy, inspected and recorded as signed, independently verifiable evidence.
The execution path
Twelve ordered stages from request to response. Each stage can end the request; none can be skipped.
Identity, consent, tenant policy and content inspection are evaluated deterministically before any provider call. The default answer to uncertainty is block.
A short-lived Ed25519 artifact binds the exact request to the tenant’s policy set. A request that differs from what was authorised does not execute.
Decisions are written to a hash-chained audit log and a Merkle transparency log, so a third party can verify what was decided without trusting the operator.
Capability map
Ten capability groups, each explained once and linked to the others through the execution path.
01
A hardened HTTP edge is the front door. It applies security headers, CORS, proxy and host validation, a kill switch, admission control, rate limiting and strict body validation before anything else runs. The API is described by a 364-operation OpenAPI 3.1 contract, and streaming requests release checked output in batches.
02
Consent is who agreed: a record ties a caller, an AI provider and a tenant to a scope and an expiry, and every request is checked against it. Policy is what is allowed: rules are validated, frozen and evaluated in priority order, and the first failing rule blocks. A tenant can tighten them but never loosen them.
03
Rule-based classifiers and an embedding ensemble judge prompts, responses and tool results. Semantic scores assess meaning; deterministic checks and signatures decide, and neither pretends to be the other. DLP and content rules can redact, mask or block.
04
One guarded path leads to eight provider families, with policy-driven routing, breakers, retries and failover. Dispatch is refused without a verified context, and the provider call carries an execution token.
05
Operators, machine identities, organisations and tenants are governed by role-based access control, single sign-on and multi-factor step-up. Consent management requires an admin permission plus second-factor step-up, and PostgreSQL enforces row-level tenant isolation.
06
Authorisation is carried by a short-lived Ed25519 artifact that binds the exact request to the tenant’s policy set. Signing uses domain separation, and key custody can be local, HashiCorp Vault, a cloud KMS or a PKCS#11 hardware security module. The inventory documents 24 cryptographic constructions.
07
Decisions are written to a hash-chained audit log, with signed checkpoints and a Merkle transparency log, so a third party can verify what was decided without trusting the operator. A refusal is recorded too, and a live verifier walks the audit chain and reports any break; it never repairs.
08
Agent actions are authorised, signed and recorded: tools are registered, versioned and reviewed, and actions are executed once. The MCP gateway reaches servers over HTTPS with a pinned server identity, and approvals and delegations keep a person in the loop.
09
The platform includes data-subject requests and an erasure workflow, an AI disclosure notice and usage metering. The consent provenance snapshot is recorded without personal data. Compliance reports and a verification portal are available to operators and auditors.
10
Operators get structured logs, 315 Prometheus metrics, tracing, health probes, seven alert channels and backup and recovery tooling. Developers get JavaScript, Python, Go and Java clients, offline verifiers and a local sandbox.
Architecture at a glance
Requests enter a hardened edge, pass an enforcement core, reach one guarded execution layer, and emit evidence on the way out.
Why the combination matters
Each capability is useful alone. Together they make enforcement exact, decisions provable and failures visible.
Safeguards beside a model can be bypassed. qodiqa places them on the one route to a provider and refuses dispatch without a verified context.
A signed artifact binds the exact request and policy set, so what is executed is what was approved.
Dependency loss, missing state and engine errors produce a BLOCK decision, not an unrecorded execution.
Semantic scores assess meaning; deterministic checks and signatures decide. Neither pretends to be the other.
Chains, checkpoints and Merkle proofs let third parties verify what was decided, with out-of-band trust anchors.
qodiqa provides evidence about enforcement. It does not claim that AI outputs are correct, nor does it determine the legal admissibility of any record.
Framework names in compliance material identify the controls a report maps to, not a certification.
Questions about what the platform covers? contact@qodiqa.com
Back to home