> For the complete documentation index, see [llms.txt](https://k-ai.gitbook.io/knowledge-ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://k-ai.gitbook.io/knowledge-ai/the-k-ai-platform/compliance.md).

# Compliance

{% hint style="info" %}
Compliance content here is descriptive of the platform's posture, not a legal opinion. Consult your DPO / Legal team for jurisdiction-specific assessments.
{% endhint %}

K-AI's compliance footprint is shaped by three pressures: the EU AI Act for high-risk AI systems, the GDPR for personal data, and a set of sectoral regulations that apply to specific customer industries. The platform's architecture is designed to make compliance evidence producible, not to assume it is granted.

## AI Act

The EU AI Act applies in tranches. The provisions that matter most for a Document Knowledge Platform — those covering high-risk AI systems that operate on enterprise document estates — enter into application in August 2026. Customers deploying AI agents on top of K-AI are typically the obligated parties; K-AI is a provider of the supporting infrastructure and an enabler of the evidence those customers need to produce.

The Act's traceability and transparency requirements map cleanly to three platform capabilities:

* **Document Lineage** (Layer 2) — every document carries its origin, the transformations it has gone through, the version chain it belongs to. Lineage is queryable and exportable.
* **Per-query lineage in MCP responses** — every MCP retrieval response carries, for each document returned, the lineage chain that produced it. The host LLM has the provenance information it needs to cite or to refuse.
* **K-AI Audit's audit trail** — every conflict, every mandatory question, every missing-subject decision is logged with actor, timestamp, and resolution. The trail is queryable through the Audit API and exportable for regulatory review.

These three together cover the provenance-proof requirements the Act articulates for high-risk systems. Customers integrating K-AI into a high-risk AI system can rely on them as primary evidence rather than building parallel traceability infrastructure.

## GDPR / RGPD

**Data residency.** SaaS deployments are hosted in France. On-premise deployments are in the customer's region of choice. Snowflake Native App deployments are in the customer's Snowflake region. See [Deployment models](/knowledge-ai/the-k-ai-platform/deployment.md) for the residency matrix.

**Right to erasure.** Per-document delete propagates through the index, the semantic graph, and the object storage. A deleted document is removed from the vector index, removed from the Neural Semantic Graph (with the surrounding edges recomputed), and removed from the storage bucket. The lineage trail of a deleted document is preserved as a tombstone — the document content is gone, but the audit-trail entry that records its existence and its deletion remains, which is the GDPR-aligned shape.

**Personal data handling.** K-AI performs no personal-data inference. The platform does not derive personal attributes from document content; it indexes the content the customer provides and exposes it under the customer's ACLs. Documents may contain PII — handled per the customer's classification and DPO policy. The platform's role is to preserve the access boundaries the customer has set, not to introduce new ones.

**Data Processing Agreement.** A standard DPA is available on request for SaaS deployments; on-premise and Snowflake Native App deployments operate under the customer's own DPA framework (the customer is the controller and the processor of their own data).

## Sectoral

K-AI's posture on sectoral regulations is to provide the **evidence primitives** — lineage, audit trail, ACL preservation, freshness — that auditors look for, and to let the customer's sectoral team (Compliance, Legal, Regulatory Affairs) compose the formal compliance package on top.

* **Banking / Insurance** — Solvency II, MiFID II evidence hooks via opposable Document Lineage. KYC / LCB-FT supporting documents indexed under preserved ACLs, with per-query lineage that meets the typical regulator's audit expectations.
* **Pharma / Health** — HAS, EMA, FDA contexts. Citation lineage in the audit trail (every Audit decision is sourced to specific documents). Clinical trial documentation lineage for GxP-adjacent workflows.
* **HSE** — ISO 45001 procedure governance. Document Authority's transverse standard maps to the ISO requirement for a documented management system; the Steward's daily routine maps to the periodic-review obligation.
* **Public sector** — RGS (Référentiel Général de Sécurité). For classified environments or highly classified data (e.g. *secret-défense* in the French defence sector), on-premise air-gapped deployment (see [Deployment — On-premise](/knowledge-ai/the-k-ai-platform/deployment.md#on-premise)) is the supported path.

## What K-AI does not certify

The platform's certified compliance posture is bounded. To set expectations:

* **SOC 2** — not yet attested. Internal controls are aligned with the SOC 2 trust-services criteria; formal attestation is not in scope for the current edition.
* **ISO 27001** — in progress; status to be confirmed by the platform's Authority team.
* **FedRAMP** — not pursued. US federal deployments are not a target segment at this stage.

Customers requiring any of the above as a contractual prerequisite should engage with K-AI's commercial team to align on timing and on the substrate certifications (Azure, AWS, Snowflake) that may already satisfy parts of the customer's audit requirement.
