EU AI Act and KIFF Cloud

1. What this page is

A mapping between specific KIFF Cloud features and specific AI Act articles. Each feature section names what KIFF Cloud provides today, plus what we do not provide so the mapping cannot be read as a guarantee of customer compliance.

Where this page references the AI Act, the canonical text is published by the European Union at EUR-Lex. Where it diverges, EUR-Lex controls.

2. Who this page is for

Providers and deployers of high-risk AI systems within the meaning of Article 6 and Annex III of the AI Act, whose obligations include traceable logging (Article 12) and effective human oversight (Article 14). KIFF Cloud is designed to help meet those two obligations specifically; other AI Act obligations remain the customer's responsibility.

3. Article 12 — Logging

Article 12 of the AI Act requires high-risk AI systems to "automatically record events ('logs') over the lifetime of the system" sufficient to enable identification of situations resulting in risk, traceability, and post-market monitoring.

What KIFF Cloud provides

• Automatic event recording for every governed action — event_ingested, state_changed, decision_recorded, action_validated, action_executed, approval_required, approval_granted, approval_denied, action_blocked.
• Per-record attribution — each event carries the actor identifier, timestamp, and trace id that link it to its causal chain.
• Append-only audit chain at the framework level; replay is deterministic.
• Tamper-evident summary hashes published to a public verifiable trail (when the deployment opts into the verifiable-trail mode).
• Signed Receipts per governed action, usable as evidence outside KIFF Cloud's own database.

What KIFF Cloud does not provide

• Decisions about what to log. The customer's domain configuration and action contracts determine which events are emitted.
• Retention periods. Default retention is the lifetime of the customer's tenant; the customer's policy determines whether that satisfies Article 12(3)'s "appropriate to the intended purpose" test.
• Automated reporting to supervisory authorities under Article 73. The customer is responsible for any outbound reporting.
• A determination of whether the customer's system qualifies as high-risk under Annex III. That classification is the customer's call.

4. Article 14 — Human oversight

Article 14 of the AI Act requires high-risk AI systems to be "designed and developed in such a way... that they can be effectively overseen by natural persons during the period in which they are in use." That includes the ability for a designated overseer to interpret outputs, intervene in operation, and halt operation if needed.

What KIFF Cloud provides

• Per-action approval requirement. Each ActionContract declares its approval requirement (Required, OptionalIfHigh, or None). Required approvals halt execution until a designated human reviews the proposal.
• Approval review surface. The dashboard and API expose pending approvals with the full causal context: the originating events, the current state, the proposed action and its parameters, and the rule that triggered the hold.
• Reviewer attribution. Every approval_granted or approval_denied record carries the reviewer's identifier, the timestamp, and a free-text reason field.
• Denial-is-terminal semantics. A denied approval blocks subsequent execution of the same proposal under the same context. The customer cannot accidentally bypass an oversight decision by retrying.
• Receipt fields. The Receipt for an approval-gated action records the reviewer's attribution, making the oversight visible to downstream auditors and regulators.

What KIFF Cloud does not provide

• Training of the human reviewer. Article 14(4) requires that overseers have "the necessary competence, training and authority"; that competence is established by the customer.
• Definition of which actions require oversight. The customer's domain configuration sets approval requirements; KIFF Cloud enforces what the configuration declares.
• Organisational policy. Article 14(2) and (3) place oversight obligations on the deployer's organisation; KIFF Cloud cannot substitute for those obligations.
• A "stop button" at the AI-system level. KIFF Cloud operates at the action level; halting the broader system requires the customer's own controls.

5. Other relevant articles

Beyond Articles 12 and 14, KIFF Cloud touches several other obligations more lightly. Each note below names the article and the limit of our contribution.

Article 9 — Risk management

The Receipt's risk_score field is reserved for cross-tenant priors data. As of v0.1 it is null because the dataset has not yet been built; see RFC 009. Customers cannot rely on this field today.

Article 10 — Data and data governance

Out of scope. The customer's training, validation, and test data is the customer's responsibility.

Article 13 — Transparency to deployers

The Receipt format gives downstream consumers a structured decision record they can read and audit; some deployers find that sufficient as transparency-to-end-users evidence, depending on their scenario.

Article 15 — Accuracy, robustness, cybersecurity

KIFF Cloud's own cybersecurity posture is documented at /security. Accuracy and robustness of the customer's AI system are the customer's responsibility; KIFF Cloud is a governance layer, not a model.

Article 17 — Quality management

Out of scope. The customer's quality-management system is the customer's responsibility.

Article 26 — Obligations of deployers

Many deployer obligations require evidence of monitoring and oversight. KIFF Cloud's audit chain and Receipts are designed to be that evidence.

6. What's not on this list

KIFF Cloud is a governance layer for actions taken by AI systems. It does not address obligations that flow from the model itself (training-data lineage, bias testing, model documentation), the deployer's organisational policies (incident reporting workflows, deployer registration), or post-market monitoring infrastructure that goes beyond logged events.

If your conformity assessment identifies obligations not covered here, KIFF Cloud is not the right tool for those. We will say so on a sales call rather than imply otherwise.

7. Receipt as evidence

A single KIFF Receipt collects, for one governed action:

• the causal chain — the events, state, decision, and action validation that produced the outcome (Article 12 logging evidence);
• the reviewer attribution when human approval was required (Article 14 oversight evidence);
• the policy version the decision was made under (lifecycle traceability under Article 12(2)(b));
• a cryptographic attestation over the chain, verifiable independent of the cloud's database (integrity under Article 15).

A regulator inspecting one action presents one Receipt; a regulator inspecting a system over time presents the receipt set. The Receipt's stable JSON shape is intended to make that exchange mechanical rather than discursive.

8. Limitations

We are not a notified body, an accredited conformity assessor, or an authorised representative within the meaning of the AI Act. We do not certify customer systems. The conformity assessment under Article 43 of the AI Act remains the customer's responsibility. KIFF Cloud's role is to provide evidence the customer's conformity assessment can rely on.

Where the AI Act's secondary legislation (delegated acts, implementing acts, harmonised standards) is updated, this mapping may lag. We update this page as the regulatory text and the relevant Commission guidance evolve.

9. Versioning

This mapping is versioned. v0.1 reflects the consolidated AI Act text published in OJ L of 12 July 2024 and Commission guidance available as of the date in the header. Version history is in git.

10. Contact

Compliance questions: legal@grouhub.co. Privacy questions: privacy@kiff.dev. Security disclosures: security@kiff.dev.

Document version: v0.1.
Status: informational; not legal advice.
Source of truth: this page is rendered from apps/web/internal/pages/aiact.templ. History is in git.