EU AI Act, GDPR and KVKK compliant LLM deployment: the checklist

To deploy an LLM that complies with the EU AI Act, GDPR and KVKK, classify each use case against the AI Act risk tiers, run a DPIA (plus a KVKK-aligned assessment for Turkish data), and host the model and its data on-premise or in-region. The controls that matter technically are PII masking at the gateway, permission-aware RAG retrieval, immutable audit logs kept at least six months, a staffed human-review step for consequential decisions, and red-teaming before go-live. Most companies running a vendor or open-weight model are AI Act "deployers", a lighter but auditable role; fine-tuning, rebranding or repurposing a high-risk system makes you a "provider".

This is an engineering guide, not legal advice. Confirm obligations with counsel in each jurisdiction and check the official timeline on EUR-Lex before fixing internal deadlines.

EU AI Act essentials: risk tiers and timeline

Regulation (EU) 2024/1689 entered into force on 1 August 2024 and applies in stages. It defines four risk tiers plus a separate track for general-purpose AI (GPAI) models, which is where LLMs sit.

• Unacceptable risk (Article 5): banned, including manipulative techniques, social scoring, emotion recognition at work and in schools, and untargeted facial-image scraping.
• High risk (Annexes I and III): employment, education, credit scoring, life and health insurance pricing, critical infrastructure, biometrics, law enforcement, migration, justice, and safety components of regulated products.
• Limited risk (Article 50): transparency duties for chatbots, synthetic content and deepfakes.
• Minimal risk: no new AI Act duties, though GDPR and KVKK still govern any personal data.
• GPAI models: the provider owes documentation, a copyright policy and a training-content summary; models presumed to carry systemic risk (training compute above 10^25 FLOPs) also owe evaluations, adversarial testing and incident reporting.

These are the dates in the published regulation. As of 2026 the Commission has proposed adjustments to parts of the high-risk schedule, so check the official timeline on the Commission's AI Act pages before committing budgets. Fines reach €35 million or 7% of global turnover for prohibited practices and €15 million or 3% for most other breaches. Classify first: the tier decides whether you face a documentation exercise or a full conformity regime.

What it means for a company deploying an LLM

The Act separates the provider, who develops a system and markets it under its own name, from the deployer, who uses it under its own authority. A bank serving an open-weight model on its own GPUs, or calling a vendor API, is a deployer. Under Article 25 you become a provider if you put your name on a high-risk system, substantially modify it, or repurpose it into a high-risk use. Fine-tuning an open-weight model into a CV-screening tool does exactly that, even though Commission guidance indicates that modest fine-tuning compute does not make you a GPAI model provider.

Deployers of high-risk systems (Article 26) must follow the provider's instructions, assign human oversight to trained staff with authority to intervene, inform affected people, and keep automatically generated logs for at least six months. Credit and insurance deployers and public bodies also owe a fundamental rights impact assessment (Article 27). Article 50 transparency (tell people they are talking to an AI, label generated content where required) and Article 4 AI literacy reach almost every LLM.

To classify your estate:

1. Inventory every LLM use case, including AI features inside SaaS tools.
2. Screen each against the Article 5 prohibitions and stop anything that matches.
3. Map each to Annex III. If outputs influence decisions about people in employment, credit, insurance, education or essential services, treat it as high-risk unless the Article 6(3) exemption for narrow procedural tasks clearly applies, and document why.
4. Decide provider or deployer status, noting fine-tuning, rebranding or repurposing.
5. Record the result in an AI system register with owner, tier, model version and review date.

Assume deployer status by default, but treat any fine-tuned or rebranded high-risk system as if you were the provider, because you probably are.

GDPR essentials for LLM systems

The GDPR applies whatever the AI Act tier, whenever prompts, documents, logs or training data contain personal data. Prompting, retrieval indexing, logging, evaluation and fine-tuning are separate purposes, each needing a lawful basis (Article 6). Legitimate interests often works for internal assistants after a balancing test; consent is a poor fit for employee data, and special-category data needs an Article 9 condition.

Data minimisation (Article 5) shapes the architecture: index only the document sets a use case needs, and do not reuse support transcripts for fine-tuning without a purpose-compatibility analysis. A DPIA (Article 35) is required where processing is likely to be high risk, which LLM systems that evaluate or monitor people at scale usually are; run it before go-live, reusing the provider's technical documentation.

Article 22 bars decisions based solely on automated processing with legal or similarly significant effects, such as loan denials, hiring rejections or claim refusals, unless necessary for a contract, authorised by law or based on explicit consent, and always with a right to human intervention and to contest. The CJEU's SCHUFA judgment (C-634/21, 2023) held that a score playing a determining role in a later decision can itself be that decision, so human review must be able to change outcomes and be recorded doing so.

Data subject rights are executable against prompts, logs and vector indexes, not against model weights; the EDPB's Opinion 28/2024 on AI models assesses model anonymity case by case and warns that unlawful training can taint downstream use. Vendors are processors (Article 28): you need a DPA, a sub-processor list, audit rights and a verified no-training, zero-retention configuration. Transfers outside the EEA need an adequacy decision (for the US, the Data Privacy Framework as of 2026; verify its status), standard contractual clauses with a transfer impact assessment, or binding corporate rules. Host in-region to remove most transfer analysis, and keep personal data out of model weights so rights requests stay executable.

KVKK essentials for Türkiye

Law No. 6698 on the Protection of Personal Data (KVKK) dates from 2016 and is enforced by the Personal Data Protection Authority and its Board (kvkk.gov.tr). Law No. 7499, in force since 1 June 2024, moved its special-category and cross-border rules closer to the GDPR. Breach notification is expected within 72 hours; fines are revalued yearly, so check current amounts.

Explicit consent (açık rıza) is the default basis, next to exceptions resembling the GDPR's (law, contract, legitimate interests, legal claims, data made public by the person). Whatever the basis, a privacy notice (Article 10) must precede processing, so your LLM notice needs a Turkish version describing the model, purposes and any automated analysis. Article 11 lets individuals object to results produced exclusively by automated systems.

VERBİS, the Data Controllers' Registry (verbis.kvkk.gov.tr), is mandatory for controllers above Board-set headcount or balance-sheet thresholds (check current figures), for controllers whose main activity involves special-category data, and for foreign controllers processing data of people in Türkiye, who must also appoint a local representative. Registration needs a processing inventory and a retention and destruction policy, which an LLM programme requires anyway.

Cross-border transfers (Article 9, as amended) rest on a Board adequacy decision, appropriate safeguards (the Board's standard contract, binding corporate rules or an approved undertaking), or explicit consent for incidental transfers only. A signed standard contract must be notified to the Authority within five business days. Sending prompts with Turkish personal data to a US-hosted API is a transfer, and the vendor's sub-processors must be covered.

Local data residency is mostly sector practice: banking regulation (BDDK) requires primary and secondary systems in Türkiye, capital-markets and insurance regulators expect the same, and public bodies follow Presidential Circular 2019/12. Hyperscaler region coverage in Türkiye is still limited as of 2026 (verify availability). For Turkish regulated sectors, plan on-premise or local colocation GPUs and treat any foreign API call as a notified cross-border transfer. Our on-premise deployment guide covers the architecture.

The compliance checklist

Each row names the control, the rule behind it and the implementation Nanobase AI uses in private deployments; every row needs a named owner and evidence an auditor can inspect.

A minimal audit record for the logging row:

{
  "request_id": "9f3c1a7e",
  "timestamp": "2026-09-05T10:14:22Z",
  "user_id": "hmac:4b1f...",
  "model_version": "llama-3.3-70b-instruct/2026-06-fp8",
  "system_prompt_sha256": "e3b0c442...",
  "retrieved_doc_ids": ["kb:policy-4471", "kb:claim-88213"],
  "pii_masked": true,
  "output_sha256": "a7ffc6f8...",
  "human_review": {"decision": "override", "reason_code": "R7"}
}

Hashes and identifiers go to long-term storage; full prompt and completion text sits in a separate short-retention store with tighter access, reconciling the six-month logging duty with data minimisation. Every control must map to a named owner, a technical mechanism and an artefact an auditor can inspect.

Mapping to ISO/IEC 42001 and SOC 2

ISO/IEC 42001:2023 is the certifiable AI management system standard; its Annex A controls (policy, roles, resources, impact assessment, lifecycle, data, information for interested parties, responsible use, third parties) line up with the AI Act's risk management and documentation duties. As of 2026 the harmonised standards that would give a presumption of conformity are still being finalised, so 42001 is the best available scaffold, not a legal safe harbour. SOC 2's Security criteria already demand most of the same evidence.

Build one evidence library and map it three ways; separate AI Act, ISO and SOC 2 programmes triple the cost and contradict each other.

Common pitfalls

• "The API vendor handles compliance." You remain the deployer under the AI Act and the controller under GDPR and KVKK; vendor certifications are inputs, not substitutes.
• Fine-tuning on customer conversations. Once personal data is in the weights, erasure is impractical. Keep personal data in retrieval; see RAG vs fine-tuning.
• Indexing the whole document estate. Without query-time ACLs, a RAG assistant is a search engine over everything the service account can read, including HR and legal folders.
• Rubber-stamp oversight. A reviewer approving 99% of outputs in seconds will not satisfy Article 22 or Article 14; measure override rates.
• Assuming EU mechanisms cover Türkiye. A Data Privacy Framework certification says nothing about KVKK; Turkish transfers need the Board's standard contract and notification.

Most failures are architectural, not legal: fix data flows, retrieval scope and access control before writing policy documents.

Frequently asked questions

Is a company using a vendor LLM API or an open-weight model a provider or a deployer?

Usually a deployer: you use the system under your own authority but did not develop or market it. You become a provider under Article 25 if you rebrand, substantially modify or repurpose a high-risk system. Fine-tuning an open-weight model into an HR or credit tool is the usual trigger; prompt engineering and RAG normally are not.

Does the EU AI Act apply to companies in Türkiye or the United States?

Yes, when the system is placed on the EU market or its output is used in the EU, wherever the company sits. A Turkish insurer serving EU residents or a US vendor selling into Europe is in scope, and non-EU providers of high-risk systems need an EU authorised representative. KVKK likewise reaches foreign companies processing data of people in Türkiye.

Do we need a DPIA for an internal LLM assistant?

In most cases, yes. A DPIA is mandatory when processing is likely to be high risk, and regulators list new technology, large-scale processing and evaluation of individuals as triggers; an assistant reading employee documents or customer records typically meets two. A narrow tool over public documentation may not, but document that conclusion and refresh the DPIA when the model or data scope changes.

Can we send personal data from Türkiye to an LLM API hosted in the United States?

Only with a mechanism under the amended Article 9 of KVKK: in practice the Board's standard contract, signed with the vendor and notified to the Authority within five business days, with sub-processors covered. Explicit consent works only for incidental transfers. For banks, insurers and public bodies, sector residency rules usually make in-country hosting the only workable option.

How long must we keep LLM logs?

Deployers of high-risk AI systems keep automatically generated logs for at least six months under Article 26(6), longer where other law requires. GDPR and KVKK storage limitation pull the other way, so keep the minimum: a long-retention store of hashes, identifiers and reviewer decisions, and a short-retention store of full prompt and completion text with tighter access.

Does on-premise hosting make an LLM deployment compliant by itself?

No. On-premise or in-region hosting removes cross-border transfer questions and most sector residency concerns, a large share of the work for regulated companies. It does nothing for lawful basis, DPIA, Article 22 human intervention, RAG access control, logging, transparency notices or AI Act classification. Treat hosting location as one row in the checklist, not the whole checklist.

How Nanobase AI can help

Nanobase AI delivers compliant private LLM platforms end to end: risk-tier classification and the AI system register, DPIA and KVKK documentation support alongside your counsel, on-premise or in-region deployment on H100, H200, B200 or RTX PRO GPUs with vLLM, TensorRT-LLM or NVIDIA NIM, a PII-masking gateway, permission-aware RAG, immutable audit logging, human-review workflows, pre-launch red-teaming, and ISO/IEC 42001 and SOC 2 evidence mapping. We are a Silicon Valley enterprise AI engineering company and a member of the NVIDIA Inception Program, with a practice focused on insurance and finance AI. See our solutions or book a live demo. Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.