The honest answer, and why it is not the end of the conversation
Türkiye has no dedicated artificial intelligence law in force. Several bills have been submitted to the Grand National Assembly, and none has been enacted. That is the complete and accurate statement of the position, and it is where almost every Turkish page on this subject stops. If you searched for this topic you have probably read four law-firm summaries that all reach the same paragraph and then end, leaving you with a legal fact and no engineering decision. This article is written from the other side of that gap. The question worth answering is not what the law says, it is what a team should change in its architecture, its logging and its contracts this quarter.
The absence of a single statute is genuinely different from the absence of regulation. Turkish organisations building AI systems are already constrained by data protection law, by criminal law, by the rules governing internet publication and content liability, by commercial law duties owed to shareholders and counterparties, by sectoral supervision where they are supervised, and increasingly by the contractual demands of European customers. None of those disappear because a dedicated act has not passed. In practice we have never met a Turkish AI system that faced no regulatory constraint at all. We have met plenty whose owners believed they faced none, which is a different and more expensive condition.
There is also a planning question hiding inside the legal one. If a dedicated law arrives, it will not arrive as a surprise in its substance. Regulatory instruments in this field converge on a recognisable set of demands: know what systems you run, know what data goes into them, be able to explain a decision that affects a person, keep records, let a human intervene, and tell people when they are talking to a machine. A team that has built those capabilities is well positioned under any plausible text. A team that has built a policy binder is not. That is the whole argument of this article, and everything below is a way of making it concrete.
Regulation by adaptation: the instruments that already bind you
The first instrument is Law No. 6698 on the Protection of Personal Data. It is the one that touches nearly every AI project, because almost every useful corpus contains personal data somewhere. Article 5 governs lawful basis for processing, Article 6 governs special categories such as health and biometric data, Article 10 imposes the duty to inform data subjects, Article 11(g) gives a person the right not to be subject to a result produced solely by automated analysis where it works against them, and Article 12 imposes data security obligations on the controller. Those five articles are the practical skeleton of Turkish AI compliance today, and they are enough to reshape a system design.
The second is the Turkish Penal Code, which matters more than most engineering teams expect. Unlawful recording, obtaining or disclosure of personal data, and failure to delete data when required, are criminal matters rather than merely administrative ones. That changes the risk conversation inside a company: an unlogged export of a customer table into a fine-tuning pipeline is not only a compliance finding. Add Law No. 5651 on internet publications, which governs content liability, takedown mechanics and hosting responsibilities, and you have a direct constraint on anything that generates or publishes content at scale. A generative feature that publishes to a public surface is squarely inside that regime.
The fourth is the Turkish Commercial Code, and it is the one nobody mentions. Directors owe duties of care in running the company, records have to be kept, and material operational risks belong in the board's field of view. An AI system that makes or shapes commercial decisions without any record of how it did so is a corporate governance problem before it is anything else. Taken together these four instruments already generate a coherent set of requirements: a lawful basis you can articulate, a security posture you can evidence, a record of automated decisions, a human path for challenge, and a content liability position. That is not nothing. It is most of a programme.
What the data protection authority already expects
The Turkish data protection authority has published guidance specific to generative AI. The guide, Üretken Yapay Zekâ ve Kişisel Verilerin Korunması Rehberi, appears on the authority's own Rehberler index at kvkk.gov.tr, and there is a shorter fifteen-question version on the same site. It is guidance rather than binding regulation, which some teams read as permission to ignore it. That is a misreading of how supervision works. Guidance tells you what the regulator considers reasonable, which is precisely the standard you will be measured against in an inspection or a complaint, and it is far cheaper to design toward than to argue against after the fact.
The authority also published a document on agentic systems, using its own Turkish term Etken Yapay Zekâ, on 12 March 2026. Whatever you call them in your own documentation, and we use AI ajanı, systems that take actions rather than merely produce text raise the stakes on every control in this article. An agent that can send an email, update a record or trigger a payment turns a wrong output into a wrong action, and the audit question moves from what did the model say to what did the system do and who could have stopped it. If you are building agents, read that document before you design the permission model rather than after.
What the guidance means in practice is covered at length in our engineering read of the generative AI guide, but the short version fits in a paragraph. Establish and record a lawful basis for the corpus and not only for the prompt. Inform people in language they can actually parse. Do not feed special-category data into a general-purpose pipeline without a specific and defensible reason. Keep prompts and outputs only as long as you can justify. Make erasure reach every store that holds a derivative, including the vector index. And be able to show, on a specific date, who reviewed what a model produced.
The Brussels effect: how the EU AI Act reaches a Turkish company anyway
The most common route into serious AI regulation for a Turkish company does not run through Ankara at all. It runs through a customer in Munich. The EU AI Act, Regulation (EU) 2024/1689, reaches providers who place systems on the Union market and also providers and deployers established outside the Union where the output of the system is used in the Union. A Turkish SaaS vendor with European accounts, an exporter whose product embeds a model, a services firm whose output is consumed by an EU client: all of these can sit inside the Regulation while every server, every engineer and every contract remains in Türkiye.
The timeline moved this summer, and a great deal of Turkish material has not caught up. Regulation (EU) 2026/1744 of 8 July 2026 was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. It deferred Annex III standalone high-risk obligations to 2 December 2027 and Annex I product-embedded high-risk obligations to 2 August 2028. It did not delay the Article 50 transparency obligations, which took effect on 2 August 2026, with a grace period to 2 December 2026 for synthetic-content marking on systems already on the market. The text is at eur-lex.europa.eu/eli/reg/2026/1744/oj and the Commission maintains digital-strategy.ec.europa.eu.
Two consequences follow for a Turkish team. First, the penalty exposure is not sized to your local balance sheet: the regime is tiered and expressed as a share of worldwide annual turnover or a fixed euro amount, whichever is higher, with the top band reaching up to 7% of worldwide annual turnover or EUR 35 million. Second, the obligations arrive commercially long before any regulator does, through procurement questionnaires and contract clauses. The full timeline, the classification questions and what the deferral does and does not buy are set out in our breakdown of the AI Act after the omnibus, which is the companion piece to this one.
Sector regulators: the layer most articles skip
If you are supervised, the supervisor is closer to you than any AI law. Banking, capital markets and energy each have their own regulator in Türkiye, the BDDK, the SPK and the EPDK, and each of them already issues rules on information systems, outsourcing, service provider management, business continuity and audit. Those rules were not written with large language models in mind, but they apply to them without needing to be. An externally hosted model that processes customer data is a service provider arrangement. A model that materially influences a credit or trading decision is an information system supporting a regulated activity. Neither of those characterisations requires a new instrument to be true.
The practical effect is that regulated institutions face their most binding constraints first, and those constraints usually concern location and control rather than model quality. Where does inference run. Who else can see the data. Can the arrangement be audited. What happens if the provider fails. Can the institution exit within a defined period. These questions decide architecture, and they decide it early: they are why so many Turkish bank and energy projects end up on self-hosted open-weight models or on regional deployments with contractual guarantees, and why the model choice conversation is often over before it starts.
We are deliberately not citing specific circulars here, because their numbers and dates change and a stale citation is worse than none. The correct move is not to read a summary of a communiqué on a consultancy blog. It is to ask your own compliance function for the current information systems and outsourcing rules that apply to your institution, and to treat those documents as system requirements alongside your functional spec. In our experience that conversation takes a week and removes about half the architectural uncertainty in a regulated AI project, which is a better return than any amount of general reading.
The dual-compliance programme: build once for the stricter of the two
The mistake we see most often is running two programmes. A Turkish team builds a KVKK track for domestic operations, then bolts on an AI Act track when a European customer asks, and ends up with two inventories, two sets of documentation, two review workflows and two teams who disagree about which one is authoritative. The duplication does not merely cost money, it produces contradictions that surface at the worst moment, when an auditor compares the two and finds that the same system is described differently in each. Once that happens you are not defending a system, you are defending a discrepancy.
The alternative is a single control set built to the stricter of the two regimes for each control, with jurisdiction handled as metadata rather than as a separate programme. Data minimisation and lawful basis analysis follow Turkish law because that is where your primary obligations sit. Technical documentation, evaluation evidence and post-market monitoring follow the European template because it is more prescriptive. Transparency follows whichever gives the user more, which is usually the AI Act. Records of automated decisions and the human challenge path satisfy both, because both demand it. You end up with one inventory, one evidence store and a jurisdiction field.
This is not a theoretical preference. The stricter-of-the-two approach is measurably cheaper because the expensive artefacts are the shared ones. An evaluation harness, a model registry, structured logs and a review workflow are built once and serve every regime, while the genuinely jurisdiction-specific work is mostly wording: notices, contract clauses and the legal analysis attached to each system. In organisations we have worked with, the split is roughly eighty per cent shared engineering and twenty per cent local legal specificity. Budget accordingly, and put the engineering under one owner. The artefacts themselves are specified in the governance work engineers actually run.
The controls that satisfy both regimes
Start with an inventory, because you cannot comply with anything for systems you cannot name. One row per AI-touching system, including features bought inside SaaS products, carrying an owner, the business process it serves, the model and version, the data categories it touches, whether output reaches the European Union, the lawful basis under Turkish law, a risk tier, the human oversight pattern, log retention and a last-reviewed date. In organisations of a few hundred people this typically takes four to eight weeks of part-time effort and reliably uncovers two to five systems nobody had recorded, which is the point of doing it before anyone asks.
Next, make the data path explicit and defensible. That means a documented lawful basis for the corpus rather than only for the user prompt, redaction before text reaches a hosted model, a retention schedule that a deletion job actually enforces, and access control carried through retrieval so a user never receives a passage they could not open in the source system. It also means knowing where inference physically runs and which sub-processors sit behind your provider. The privacy architecture that supports this is set out in our data privacy article, and it is the part of the stack Turkish regulators and European customers ask about in almost identical terms.
Then the evidence layer, which is what turns claims into defences. Version your prompts in source control, pin model versions, run a versioned evaluation suite in CI, log inputs, outputs, model version, retrieval sources and reviewer actions, and monitor for drift. This is ordinary engineering with a compliance side effect, and the mechanics are covered in AI observability and evaluation. The reason to build it now, rather than when a law passes or a customer asks, is that evidence cannot be produced retrospectively. You cannot generate 2026 evaluation history in 2028, and no amount of documentation effort will fill that gap.
Finally, the human path. Both regimes care that a person affected by an automated result can reach a human who can actually change the outcome, and Article 11(g) of Law 6698 makes that concrete in Turkish law where a decision is produced solely by automated analysis and works against the person. Design it as a real workflow with a queue, a service level, an override button and a record of who used it, not as an email address in a footer. It is also the control most likely to be tested first, because it is the one a complainant can trigger without any technical knowledge at all.
Where the requirement actually arrives: procurement
For most Turkish companies, the first serious AI compliance demand does not come from a regulator. It comes from a customer's procurement team, usually in a spreadsheet with sixty rows. The questions are consistent enough to prepare for: which models do you use and can you pin versions, where does inference run, are our prompts or outputs used for training, what is your log retention, how do you handle deletion requests, what evaluation evidence can you share, what is your incident notification window, and who is accountable internally. Every one of those is answerable in a paragraph if you have built the controls, and unanswerable if you have not.
Prepare the answers once and keep them versioned. We maintain what amounts to a standing response pack per client: an architecture description, a data flow, a sub-processor list, the retention schedule, a summary of the evaluation approach, and the incident process. Assembling it the first time takes a week or two of real effort. Reusing it takes an hour. Teams that answer these questionnaires from scratch each time do three things badly at once: they answer slowly, they answer inconsistently across deals, and they promise things engineering has not built. The third is the one that ends up in a contract.
Read your contracts for what they have already committed you to. Cross-border transfer terms, audit rights, deletion timelines and notification windows are frequently agreed by commercial teams without an engineering review, and they become binding obligations regardless of whether the underlying capability exists. A seventy-two hour breach notification clause is a paging policy. A thirty-day deletion commitment is a scheduled job that has to reach the vector index. A right to audit is a documentation requirement with a date attached. Reading the last twelve months of signed contracts is the cheapest compliance exercise available to most companies, and it usually finds at least one surprise.
What to do in the next ninety days
Days one to thirty: build the inventory and read the contracts. Name every system, assign an owner, mark the ones whose output reaches the European Union, and record a lawful basis for each corpus. In parallel, pull the AI-relevant clauses out of your signed customer agreements. This is deliberately unglamorous, it needs one engineer and one person from legal working part-time, and it produces the first genuinely useful artefact in the programme: a list you can prioritise against. Almost every subsequent decision, including how much to spend, depends on knowing how many systems you actually have and which ones carry external exposure.
Days thirty to sixty: close the obvious gaps. Redaction before hosted inference, retention that a job enforces, access control carried through retrieval, transparency notices on every user-facing surface, and a human review path that exists as software rather than as a promise. If any product surface reaches European users, treat the AI Act transparency work as time-boxed against the December 2026 grace date rather than as a 2027 problem. These are small, discrete engineering tasks and a competent team ships most of them inside a month. They also happen to be the ones most visible to customers.
Days sixty to ninety: stand up the evidence layer and write the decision records. Prompts in version control, pinned model versions, a versioned evaluation set running in CI, structured logging with a retention policy, and a one-page classification record per system stating the role you play, the jurisdictions involved, the risk tier and who signed it. Then schedule the review cadence, because the single most common failure of a compliance programme is not that it was never built but that it was built once and never revisited. Quarterly is enough for most portfolios, monthly if you are shipping agents.
How we approach this at HatsonTech
We are an engineering company, not a law firm, and we hold that line carefully. We do not advise on whether a bill will pass or how a court would read a provision. What we do is build the systems that make a legal position implementable and durable: the inventory, the redaction layer, the retrieval access control, the evaluation harness, the logging and retention design, the human review workflow, and documentation generated from those systems rather than typed into a template. When a client's counsel takes a position, our job is to make the software match it and keep matching after the next release.
The pattern we see most often in Turkish organisations is asymmetric maturity. The legal analysis is competent and the systems underneath cannot evidence any of it. There is no record of who approved a prompt change, no versioned evaluation set, no way to show that a deletion request reached every store, and no log that would let anyone reconstruct a decision from six months ago. Closing that gap is ordinary platform work and it pays off well beyond compliance, because the same instrumentation is what lets a team change models without fear. Our legal-domain work, described in AI in law, runs on exactly this stack.
Our advice to a team waiting for a Turkish AI act is simple: do not wait, and do not overbuild either. Build the inventory, the data path controls, the evidence layer and the human path. Those four survive any plausible statute, satisfy most of what European customers ask, and are defensible under the law that already applies today. We build them into custom platforms as part of normal delivery rather than as a separate compliance project, which is what our custom software engineering practice is for. If you want a blunt read on where you stand, send us your system list and your last three customer questionnaires.