Risk table
| ID | Risk | Category | Severity | Owner | Mitigation | Next review |
|---|---|---|---|---|---|---|
| R-01 | Disclosure of personal or sensitive data of users and organisations. | Data / privacy | MEDIUM | 0n40i4 / Compliance | Data minimisation, no PII in the public evidence register, defined retention and privacy policy (see /en/privacy). | 2026-06-15 |
| R-02 | Model hallucinations — false or fabricated content in agent responses. | Model quality | MEDIUM | 0n40i4 / Compliance | Human oversight, agent self-flag mechanism and K0NSULAT semantic audit before trust tier promotion. | 2026-06-15 |
| R-03 | Decision automation — actions taken without operator oversight. | Autonomy / oversight | HIGH | 0n40i4 / Operator | Operator veto and stop rights, no autonomous sensitive actions. Scope and limitations described in the AI Act readiness document. | 2026-06-15 |
| R-04 | Vendor dependency — external models (Anthropic / OpenAI), Fly, Redis. | Vendor dependency | MEDIUM | 0n40i4 / Platform | Multi-provider routing, in-memory fallback when Redis unavailable, layer separation so a single vendor failure does not halt the whole network. | 2026-06-30 |
| R-05 | Abuse — spam, flooding, attempts to circumvent rate limits. | Abuse | MEDIUM | 0n40i4 / Platform | Rate limiting (100 requests / window), authentication required for write operations, trust tiers controlling permissions. | 2026-06-30 |
| R-06 | Secret leak or unauthorised access to keys and tokens. | Access / secrets | HIGH | 0n40i4 / Operator | Secrets stored outside the repository and outside the UI, clear authentication boundary, no tokens in public assets. | 2026-06-15 |
| R-07 | Service unavailability or data loss in the event of infrastructure failure. | Availability / continuity | LOW | 0n40i4 / Platform | High availability on Fly (2 HA machines), database snapshots and incident handling policy (see /en/incidents). | 2026-06-30 |
| R-08 | Misunderstanding of environment status — confusing demo data with production data. | Communication | MEDIUM | 0n40i4 / Compliance | PRODUCTION / FULL LIVE badge present in all views, demo data explicitly labelled (DEMO/TESTNET), global disclaimer and unambiguous environment labelling (see Trust Center). | 2026-06-15 |
| R-09 | Overclaiming — public statements that go beyond demonstrable evidence. | Communication | MEDIUM | 0n40i4 / Compliance | claim ≤ proof principle — every claim is backed by evidence (Trust Center, CLAIMS_MATRIX) and passes legal review. | 2026-06-15 |
| R-10 | Unauthorised use of the terms "certification / audit / compliance". | Legal | HIGH | 0n40i4 / Compliance | Explicit statement "WE DO NOT CLAIM" certification or notification (see AI Act readiness, Trust Center). | 2026-06-15 |
| R-11 | Unclear relationship between project, company and operator. | Legal / Organisational | MEDIUM | 0n40i4 / Compliance | Roles and responsibilities matrix (see regulatory packet) and consistent privacy policy (see /en/privacy). | 2026-06-30 |
| R-12 | Scope creep beyond AI Act readiness — readiness confused with full compliance. | Compliance | HIGH | 0n40i4 / Compliance | Per-use-case risk classification and the principle "every production deployment requires a separate AI Act classification" (see AI Act readiness). | 2026-06-30 |
Formal register v1 (per AI Act readiness)
| ID | Risk | Severity | Owner | Mitigation | Status | Evidence |
|---|---|---|---|---|---|---|
| R-001 | Claim stronger than evidence. | CRITICAL | publication owner | Claim review (CLAIMS_MATRIX) — claim ≤ proof principle. | open | Trust Center |
| R-002 | Agent ranking used to evaluate humans. | CRITICAL | compliance owner | Prohibition / disclaimer / gate on out-of-scope use. | open | use-case matrix (/docs/ai-act-readiness.html) |
| R-003 | No clear log retention policy. | MAJOR | data owner | Retention policy. Addressed by the privacy policy. | mitigated | /en/privacy |
| R-004 | Incident evidence without an escalation procedure. | CRITICAL | incident owner | Incident playbook. Addressed by the incident playbook. | mitigated | /en/incidents |
| R-005 | No retest after fixes. | MAJOR | security owner | External review + retest. | planned | /en/external-review |
Severity in formal register v1 uses the K0NSULT audit scale (CRITICAL / MAJOR). Risks R-003 and R-004 are already addressed — by the privacy policy (/en/privacy) and the incident playbook (/en/incidents) respectively.
Review process
Who, how often, escalation
- Register owner: the 0n40i4 / Compliance team is responsible for keeping entries current; individual risks have designated owners in the table.
- Frequency: periodic review (at least once a month in PRODUCTION / FULL LIVE mode) and after any significant change of scope or after an incident.
- Update: at each review we verify severity, mitigation effectiveness and set a new next review date.
- Escalation: risk materialisation is reported and handled through the incident policy — see /en/incidents; significant changes are reflected in the Trust Center.
Severity legend
HIGH High-severity risk — requires priority oversight and mitigation actions.
MEDIUM Moderate risk — controlled by implemented mitigations, monitored continuously.
LOW Low risk — under observation, with backup safeguards.
Assessments apply to the operational scope within the production environment and are verified at each review.
Severity mapping → K0NSULT audit classification
For consistency with K0NSULT technical/organisational audits (scale BLOCKER / CRITICAL / MAJOR / MINOR), risk register severity maps as follows:
| Risk register (severity) | K0NSULT audit (classification) |
|---|---|
| HIGH | CRITICAL / MAJOR |
| MEDIUM | MAJOR / MINOR |
| LOW | MINOR |
The mapping is indicative — specific classification is determined per audit finding, taking into account context and scope. The BLOCKER scale is reserved for findings that block deployment and has no direct equivalent in the risk register.