The Compliance Architecture Taking Shape Before the Law
Asutay Duhan Meydan, Attorney at Law
Meydan AI & Tech Law
Legal position and regulatory developments assessed as of 29 August 2026.
Introduction: Türkiye Does Not Yet Have an AI Act. That Does Not Mean AI Providers Should Ignore the Action Plan.
Türkiye’s regulatory position on artificial intelligence changed materially in August 2026.
Presidential Circular No. 2026/9, dated 17 August 2026 and published in the Official Gazette No. 33344 on 18 August 2026, formally introduced the Türkiye Artificial Intelligence Action Plan 2026–2030. The Circular describes the Plan as the country’s new roadmap for artificial intelligence following the completion of the 2021–2025 National Artificial Intelligence Strategy. Its stated priorities include technological sovereignty, competitiveness, data-driven development, trustworthy AI and sustainable digital transformation.
The first point must, however, be made with some care.
The Action Plan is not Türkiye’s equivalent of the EU Artificial Intelligence Act.
It does not, by itself, establish a comprehensive statutory regime under which every company providing an AI model, API or AI-powered service in Türkiye must immediately complete a conformity assessment, prepare a Model Card, appoint a representative, register its system or face an AI-specific administrative fine.
Indeed, the operative wording of Presidential Circular No. 2026/9 is directed primarily at public authorities: public institutions are instructed to perform the duties assigned to them under the Plan and to provide the support necessary for its implementation. The Plan itself further anticipates that a general statutory framework will be established and that implementation details will subsequently be developed through secondary legislation and sector-specific rules.
It would therefore be legally inaccurate to present the Action Plan as though a Turkish AI Act had already entered into force.
It would be equally inaccurate, however, to dismiss the document as a political declaration without legal relevance.
For companies developing, operating or supplying AI services into Türkiye, the Plan reveals something considerably more useful than a generic statement of policy: it shows the architecture around which Türkiye intends to build its AI regulatory system.
Risk classification, Algorithmic Impact Assessments, Model Cards, technical documentation, model evaluations, data governance, cybersecurity testing, regulatory sandboxes and sector-specific supervision are no longer merely academic concepts in the Turkish debate. They now appear within an official national implementation programme.
For an AI provider, that distinction matters. The immediate question is no longer simply, “What does Turkish law require from me today?”
A second question has become equally important:
What compliance capability should I begin building today if I intend to continue serving the Turkish market tomorrow?
1. The Legal Starting Point: What Does the Action Plan Mean for an AI Provider?
The Action Plan adopts four principal axes — Fark Et, İstifade Et, Üret and Yönet — and contains sixteen priority actions. From the perspective of an AI provider, however, several provisions are significantly more important than the others.
Three parts deserve particular attention.
Action 3 concerns data infrastructure and governance.
Action 4 concerns the establishment of a national legal and ethical AI framework based on a proportionate risk approach.
Action 16 concerns AI safety evaluation, regulatory sandboxes and the legislative framework required to support AI deployment.
Together, these provisions are beginning to form what may be described as Türkiye’s emerging provider compliance architecture.
This expression should not be misunderstood. The architecture is emerging; the statutory obligations are not yet complete.
The distinction can already be seen in the Plan’s treatment of high-impact public systems. During the initial implementation period, the Plan aims to introduce Algorithmic Impact Assessments and Model Card packages for newly deployed high-impact AI systems in the public sector. That is a concrete implementation target, but it is not the same thing as imposing an immediately enforceable Model Card obligation upon every private AI provider operating in Türkiye.
The public sector is therefore functioning, at least in part, as a regulatory testing ground.
Providers should pay attention to what is being tested there.
The documentation standards first developed for public systems may later become the reference point for procurement criteria, sectoral rules and eventually statutory duties applicable to private actors.
2. Who Is an “AI Provider” Under Turkish Law?
There is an important terminological problem at the outset.
The Action Plan does not yet establish a final statutory definition of “AI provider” comparable to the definitions contained in the EU AI Act. The Plan itself acknowledges that concepts requiring legal enforceability will need to be defined through subsequent legislative work.
Accordingly, “provider” should presently be used in Türkiye as a functional description rather than as though it were already a legally settled operator category.
For the purposes of this analysis, the term should encompass at least four different commercial positions.
The first is the model provider: an undertaking developing a foundation or general-purpose model and making that model available to third parties.
The second is the AI system provider: an undertaking that takes a model — whether internally developed or supplied by another company — and builds a market-facing product around it.
The third is the AI-as-a-service or API provider, which provides AI functionality remotely without necessarily supplying model weights or infrastructure to the customer.
The fourth is the downstream integrator, which may use a third-party foundation model but nevertheless supplies the final AI system to the Turkish customer under its own brand.
These distinctions are not theoretical.
Consider a Turkish legal-tech company that builds a legal research assistant using a foreign large language model. The foundation-model company, the cloud infrastructure provider and the Turkish company supplying the final legal assistant are not performing the same function. Their access to training information, logs, security controls, model evaluations and customer data will differ substantially.
A future Turkish AI regime will have to decide where obligations sit within that chain.
The EU AI Act provides a useful comparison. Article 3(3) defines a provider as an entity that develops, or has developed, an AI system or general-purpose AI model and places it on the market or puts the system into service under its own name or trademark. The Regulation separately recognises a downstream provider that integrates an AI model into an AI system.
Türkiye has not yet adopted those definitions.
But the supply-chain problem that produced them in Europe exists here as well.
If a Turkish downstream provider is expected to prepare a technical file but its foreign upstream model supplier refuses to provide evaluation information, the legal obligation cannot be analysed in isolation from the underlying contractual relationship. This issue will become particularly important if Türkiye eventually distributes compliance obligations between model providers and downstream system providers.
3. Risk-Based Classification: The First Regulatory Gate
Action 4 is probably the single most important part of the Plan for companies providing AI systems into Türkiye.
The Plan contemplates a proportionate, risk-based regulatory framework taking account of the European Union’s approach. Under the structure described in the Plan, regulatory expectations increase according to the impact of the system.
Low-risk applications are associated with simplified compliance checklists.
Medium-risk applications are associated with a short-form Algorithmic Impact Assessment.
High-impact systems are associated with an expanded Algorithmic Impact Assessment, a publicly accessible summary Model Card, and detailed technical documentation capable of being submitted to the competent regulator.
This is an important shift.
The regulatory question is no longer simply whether software contains artificial intelligence. The relevant question becomes:
What does the system do, who can it affect, and what happens when it is wrong?
That approach is more sophisticated than attempting to regulate every AI product in the same manner.
A recommendation engine suggesting music should not necessarily face the same regulatory burden as an algorithm ranking employment applicants.
Likewise, a grammar assistant should not automatically be regulated in the same manner as a system assisting with creditworthiness assessments.
For providers, this means product classification may eventually become the first legal exercise before market deployment.
That classification cannot sensibly be performed solely by engineers or solely by lawyers. Intended purpose, reasonably foreseeable use, model capability, deployment environment and the consequences of failure are technical and legal facts at the same time.
A provider entering Türkiye should therefore expect the future compliance question to begin not with the architecture of its neural network, but with the function performed by the system in the Turkish market.
4. High-Impact AI Systems: Where Provider Exposure Becomes Material
The Action Plan identifies a number of areas as particularly significant for high-impact AI governance.
These include healthcare, education, employment, social assistance, credit assessment, biometric recognition, law enforcement and justice processes, as well as applications directly affecting children and other vulnerable groups. High-impact systems are described more broadly as systems capable of directly affecting individuals’ health, safety, fundamental rights or social welfare.
For providers, the consequence is straightforward.
The same underlying model may attract very different regulatory scrutiny depending on its deployment.
A general-purpose language model offered through a consumer chatbot and the same model embedded into software that ranks employment candidates do not present the same legal risk.
Similarly, an image-recognition model used to organise a private photo library cannot automatically be equated with a biometric identification system used in a security environment.
This distinction also creates an important issue for foundation-model companies.
A general-purpose model provider may argue that it does not control every downstream use of the model. That is true as a matter of technical architecture. It does not necessarily resolve the legal question.
Future Turkish legislation will have to decide what information an upstream provider must make available to the downstream company so that the latter can identify and mitigate deployment-specific risks.
The EU has already confronted this issue by imposing information and documentation duties upon providers of general-purpose AI models for the benefit of downstream system providers. Article 53 of the EU AI Act requires, among other matters, technical documentation and information intended to enable downstream providers to understand the model’s capabilities and limitations.
The Turkish Action Plan does not yet replicate Article 53.
But once Türkiye requires a downstream provider to explain a high-impact system, the information asymmetry between the downstream company and its upstream model provider becomes impossible to ignore.
5. Algorithmic Impact Assessment: From Technical Capability to Legal Consequence
The introduction of the Algorithmic Impact Assessment, or AIA, is one of the clearest indications that Turkish AI regulation is moving towards lifecycle governance rather than simple after-the-fact liability.
The concept is significant because it asks a question traditional software compliance often does not:
What consequences can this system produce before those consequences actually occur?
For medium-risk applications, the Plan contemplates a short-form assessment. For high-impact systems, the contemplated assessment becomes more extensive.
The precise mandatory contents of the future Turkish AIA have not yet been established by binding legislation. Providers should therefore resist the temptation to invent a statutory checklist where none exists.
Nevertheless, the function of the instrument is reasonably clear.
A meaningful assessment would need to identify the intended use of the system, the persons affected by it, the nature of the decision or recommendation produced, foreseeable failure modes, potential discriminatory effects, data-related risks, the degree of human intervention and the mechanisms available for remediation.
This is not merely paperwork.
For high-impact AI, an impact assessment may become the point at which product design and legal responsibility meet.
Imagine an AI provider selling automated recruitment software. A legal review performed only after deployment asks whether discrimination occurred.
An impact assessment asks an earlier question:
Could the architecture, data, proxy variables or deployment method systematically produce discriminatory outcomes, and what has the provider done about that possibility?
That distinction is likely to become central to provider governance.
It also changes the role of legal counsel. Counsel cannot merely review the provider’s terms of service after the product has been completed. Legal review has to move upstream into model design, data sourcing, evaluation and deployment decisions.
6. Model Cards: Transparency Is Becoming a Product Requirement
The Action Plan’s use of the Model Card is particularly noteworthy.
For high-impact systems, the Plan contemplates a publicly accessible summary document containing information about the system’s purpose, limitations and evaluation results. A more detailed technical file would remain available for regulatory scrutiny.
Those two documents should not be confused.
A Model Card is a transparency instrument.
A technical file is an accountability instrument.
The first speaks primarily to users, customers, affected persons and the wider public. The second speaks to regulators, auditors and potentially courts.
For providers, this distinction is commercially important.
A Model Card cannot simply reproduce proprietary architecture, confidential security information or trade secrets. Nor can “trade secret” become a blanket excuse for withholding every meaningful piece of information about a high-impact system.
The emerging regulatory problem will be finding the boundary between meaningful transparency and legitimate confidentiality.
In practice, providers should expect Model Cards to become part of product governance rather than marketing material.
A credible Model Card should not read like a sales brochure. Statements such as “state-of-the-art”, “safe”, “accurate” or “responsible” have little compliance value without context.
What matters is the scope of the system, the conditions under which it was evaluated, known limitations and the circumstances in which human review remains necessary.
The more serious point is evidentiary.
Once a provider publicly represents that a model has particular limitations, safeguards or performance characteristics, those statements may later be compared with the provider’s actual design decisions and conduct.
Transparency therefore creates accountability not only because information is disclosed, but because the provider creates a record against which its later conduct can be assessed.
7. The Technical File: Compliance Must Be Capable of Proof
The Action Plan contemplates detailed technical documentation for high-impact systems that can be made available to the competent supervisory authority.
For AI providers, this may prove more important than the Model Card.
A recurring mistake in technology compliance is to assume that doing the right thing and being able to prove that the right thing was done are the same.
They are not.
A provider may have performed safety testing. If it cannot identify which model version was tested, which dataset was used, what threshold was applied and what remediation followed, the evidentiary value of the exercise rapidly decreases.
A mature technical file would therefore have to evolve with the system.
Model versioning, evaluation reports, material changes, known limitations, security testing, risk acceptance decisions, human-oversight mechanisms and incident records are likely to become relevant components of the provider’s compliance history.
This is particularly important because AI products do not behave like static goods.
Models are updated.
System prompts change.
Retrieval databases change.
Guardrails are modified.
Third-party APIs are replaced.
Fine-tuning changes outputs.
A provider that documented version 1.0 but cannot reconstruct what changed in version 1.4 may discover that its compliance file describes a product that no longer exists.
The issue also extends beyond regulatory enforcement.
Under Turkish private law, contractual liability continues to exist independently of the Action Plan. Article 112 of the Turkish Code of Obligations provides that where an obligation is not performed or is improperly performed, the debtor is liable for the resulting loss unless it proves that no fault can be attributed to it. Tort liability under Article 49 remains separately available where the applicable conditions are satisfied.
Documentation therefore matters twice.
It may be required for regulation tomorrow.
It may become evidence in litigation today.
8. AI Safety and Model Evaluation: “It Works” Is No Longer an Adequate Standard
Action 16 goes beyond abstract ethical principles and moves directly into technical evaluation.
The Plan envisages strengthening AI safety-evaluation capability within the TÜBİTAK BİLGEM Artificial Intelligence Institute. The contemplated evaluation criteria include security, performance, robustness, bias, explainability, data protection and resistance to cyber threats.
Most importantly, high-impact systems are expected to be evaluated before going live and again following major version updates.
For providers, this introduces a concept familiar from regulated industries but still relatively new to many AI companies:
change control becomes a legal issue.
A model update is not merely a product improvement.
An update can alter error rates, safety behaviour, refusal patterns, bias characteristics, tool use, output quality and susceptibility to adversarial inputs.
The unresolved issue is what constitutes a “major” update.
A future regulatory instrument will need to distinguish between routine changes and changes substantial enough to trigger renewed evaluation.
This question becomes even more difficult in multi-provider systems.
A Turkish AI company may not update anything itself. Its foreign foundation-model provider may silently change the API model underlying the Turkish product.
From the customer’s perspective, however, the product has changed.
Provider contracts will therefore increasingly require version transparency, advance notice of material model changes, access to updated evaluation materials and mechanisms for regression testing.
Again, the European comparison is instructive rather than binding. Providers of general-purpose AI models presenting systemic risk under Article 55 of the EU AI Act must undertake model evaluation, including adversarial testing, assess and mitigate systemic risks, report serious incidents and maintain appropriate cybersecurity protections.
The Turkish framework is not yet at that level of statutory detail.
The direction of travel is nevertheless visible.
9. Personal Data: The Action Plan Does Not Replace the KVKK
There is one area in which AI providers cannot wait for future AI legislation: personal data protection.
The Action Plan expressly links the development of Türkiye’s AI framework with KVKK/GDPR alignment, including explainability in automated decision-making, personal-data processing during model training and cross-border transfers. It also contemplates AI-specific anonymisation standards and secure data environments.
But these proposals must not create the impression that data protection obligations begin only when the AI framework is completed.
Law No. 6698 on the Protection of Personal Data already applies where its substantive requirements are engaged.
The Turkish Data Protection Authority has also issued specific guidance on generative AI. Its 2025 guide addresses personal-data processing throughout the lifecycle of generative AI systems and is expressly intended to guide actors qualifying as data controllers.
For a provider, the practical data map can be considerably more complicated than the training dataset alone.
Personal data may enter the system through pre-training data, fine-tuning datasets, user prompts, uploaded files, retrieval-augmented generation databases, vector stores, customer-support records, security logs, human-review processes and model-improvement pipelines.
Those flows should not be collapsed into a single statement that “the AI processes data”.
Each operation may involve a different purpose, legal basis, retention period and allocation of responsibility.
The cross-border issue is particularly important for foreign APIs.
Where personal data is transferred abroad, the current KVKK regime provides a structured mechanism based on adequacy decisions, appropriate safeguards and, where those mechanisms are unavailable, limited exceptional circumstances.
Accordingly, a Turkish enterprise purchasing an AI service from an overseas provider cannot treat “cloud processing” as a purely technical procurement decision.
Where personal data leaves Türkiye, the architecture of the service can become a data-transfer issue.
The Action Plan’s express intention to review cloud use, external service procurement, data processing and cross-border data transfers in regulated sectors confirms that this intersection will become more, not less, important.
10. Foreign AI Providers: When Does Serving Türkiye Become Subject to Turkish AI Regulation?
This is one of the most important questions that the Action Plan does not yet answer.
Suppose a company is incorporated in the United States.
Its models are trained outside Türkiye.
Its servers are located outside Türkiye.
It has no Turkish subsidiary.
Yet Turkish consumers use its chatbot, Turkish companies purchase its API, and Turkish personal or commercial data is processed through the service.
Would that company fall within the territorial scope of a future Turkish AI law?
The Action Plan does not establish the answer.
This gap should be recognised rather than filled by assumption.
The EU AI Act provides a useful illustration of how another legislature has addressed the problem. Its territorial scope expressly includes providers placing AI systems or general-purpose AI models on the EU market regardless of whether the provider is established within the Union, and it can also apply to certain providers or deployers established outside the EU where the AI system’s output is used within the Union.
The EU framework also requires certain third-country providers of high-risk AI systems and general-purpose AI models to appoint an authorised representative within the Union.
Türkiye has not enacted an equivalent rule under the Action Plan.
Whether the eventual Turkish framework will rely on establishment, targeting of the Turkish market, location of users, place of deployment, location of affected persons, use of outputs or another connecting factor remains open.
This is not a minor drafting question.
A domestic AI startup and a global provider offering the same functionality to the same Turkish customer cannot operate under a sustainable regulatory system if the former is readily supervisable while the latter remains practically unreachable.
The territorial-scope provisions of future legislation will therefore determine not only regulatory jurisdiction, but also competitive equality.
11. Public-Sector AI Procurement May Become a De Facto Compliance Gate
The Action Plan does not merely intend for government to regulate AI.
It intends for government to buy AI.
The Government has stated that at least 2 per cent of public investment programme resources will be allocated to AI projects and that the public sector should become the first purchaser and strongest reference for successful domestic AI solutions.
For providers, this creates an unusually important intersection between AI governance and public procurement.
Regulatory requirements do not always need to appear first in legislation.
They can appear in procurement specifications.
A public authority purchasing a high-impact AI system may require documentation concerning security, data location, Model Cards, evaluation results, auditability, business continuity, model changes, human oversight and incident response before awarding the contract.
Once those requirements become standard procurement practice, they can influence the wider commercial market.
A provider that develops a complete compliance package for public procurement can reuse substantial parts of that package when dealing with banks, hospitals, insurers, telecommunications companies or other heavily regulated customers.
Public procurement may therefore become one of the mechanisms through which the Action Plan’s soft regulatory expectations become market standards before becoming statutory standards.
There is, however, another side to the issue.
The commitment to favour the development and purchase of domestic AI solutions must operate within the existing legal framework governing procurement and competition. Turkish procurement legislation already contains mechanisms concerning domestic bidders and domestic goods, while technical specifications must remain compatible with competition and equal opportunity principles. The Public Procurement Authority has previously emphasised that technical specifications should not contain competition-restricting criteria and should ensure equal opportunity among bidders.
The Action Plan therefore creates a policy preference.
It does not, on its own, rewrite every public-procurement rule applicable to foreign AI providers.
12. Regulatory Sandboxes: A Route Into the Market, Not a Zone Outside the Law
Action 16 also calls for regulatory sandboxes in at least five priority sectors, particularly finance, healthcare, energy, mobility and telecommunications.
The contemplated structure includes a single digital application point, time-limited testing and a “graduation” mechanism through which successful pilots may move towards permanent regulation, licensing or public procurement.
For AI providers, the commercial importance is obvious.
Highly regulated industries often produce a paradox.
The sectors that could benefit most from AI may also be the sectors where uncertainty over data protection, outsourcing, cybersecurity, secrecy, licensing and supervisory rules makes deployment most difficult.
A properly functioning sandbox can reduce that uncertainty.
But a regulatory sandbox should not be confused with a legal vacuum.
Unless a specific legal derogation says otherwise, participation in a sandbox does not automatically suspend the KVKK, confidentiality obligations, sectoral licensing rules, cybersecurity requirements or contractual duties.
Its real value lies elsewhere.
The provider can expose the actual system to regulatory scrutiny before attempting full-scale deployment.
The regulator, in turn, sees the technology functioning in context rather than trying to regulate it solely through abstract descriptions.
That exchange is especially valuable in AI.
A system that appears safe in a technical paper can become risky when connected to real databases, real employees and real decision-making processes.
Conversely, a system that appears dangerous in the abstract may become manageable when technical limits, human review and institutional controls are properly designed.
For providers capable of demonstrating their systems rather than merely describing them, the sandbox model may therefore become one of the most commercially valuable elements of the Action Plan.
13. Provider–Customer Contracts Will Carry More of the Regulatory Burden
The Action Plan does not prescribe the clauses that must appear in an AI services agreement.
That does not mean contracts are peripheral to the regulatory framework.
They are likely to become one of its principal transmission mechanisms.
A downstream provider cannot prepare reliable documentation if its upstream model supplier provides no information about model changes.
A bank cannot complete an AI risk assessment if its vendor refuses to disclose relevant evaluation data.
A Turkish customer cannot properly assess cross-border transfers if it does not know where data is processed or which subprocessors receive it.
The compliance chain therefore has to be reflected in the contractual chain.
AI agreements serving the Turkish market increasingly need to address the permitted use of customer data, whether inputs or outputs may be reused for model training, the role of subprocessors, international transfers, security standards, model-update notifications, access to technical documentation, audit cooperation, incident notification, service continuity, intellectual-property allocation, output restrictions, retention and deletion, migration assistance and the allocation of liability.
Provider contracts must also be read together with mandatory law.
Where the relationship is consumer-facing, Law No. 6502 on Consumer Protection may independently apply. Articles 13 and 14 regulate defective services and require a service provider to perform the service in conformity with the contract. The statutory concept also encompasses services that do not possess characteristics represented by the provider or reasonably expected by the consumer.
For B2B relationships, the Turkish Code of Obligations remains central.
This produces an important point for AI providers.
A disclaimer saying “AI may make mistakes” is not necessarily a complete allocation of legal risk.
The effect of such language depends on the nature of the contract, the parties, mandatory rules, the representations made about the product and the actual cause of the loss.
In other words, provider liability cannot be solved by a disclaimer copied from a global terms-of-service document.
Local legal context matters.
14. Domestic and Foreign Providers: The Coming Question of Regulatory Equality
Türkiye’s Action Plan is deliberately industrial as well as regulatory.
It seeks to strengthen domestic models, domestic infrastructure, AI startups, data centres, research capacity and public-sector demand.
That is a legitimate policy objective.
It also creates an unavoidable legal problem.
If Turkish providers are expected to produce Algorithmic Impact Assessments, Model Cards, technical documentation and evaluation records while global providers serving the same Turkish customers remain outside effective supervision, the result would not be a genuinely risk-based system.
It would be a location-based compliance asymmetry.
Conversely, imposing requirements designed for large global model developers indiscriminately upon early-stage Turkish startups could create a barrier to entry that benefits precisely the largest companies the policy seeks to compete with.
The future regime therefore requires proportionality in two directions.
Compliance requirements should correspond to the risk created by the system.
They should also reflect the position and control of each actor in the AI supply chain.
An application provider should not be required to disclose technical information that only the foundation-model provider possesses.
A foundation-model provider should not automatically be treated as responsible for every decision independently made by a downstream deployer.
The difficult work of AI legislation lies precisely in allocating those responsibilities.
The Action Plan has identified the architecture.
The next legislative stage will have to define the boundaries.
15. What Is Legally Binding Today — and What Is Merely Being Signalled?
This distinction is the most important legal conclusion of the entire Plan.
As of 29 August 2026, Türkiye has not enacted the Action Plan’s proposed Model Card, Algorithmic Impact Assessment and technical-file framework as a generally applicable statutory obligation imposed upon every private AI provider.
Presidential Circular No. 2026/9 instructs public authorities to perform their responsibilities under the Plan. The Plan itself anticipates a general legal basis followed by secondary legislation and sector-specific implementation.
Parliamentary initiatives concerning AI also exist, but the relevant proposals have not, merely by being introduced, become the country’s general AI statute. For example, the 2024 “Artificial Intelligence Bill” and a separate 2025 proposal concerning AI systems remain recorded by the Grand National Assembly as being at committee stage.
Providers should therefore distinguish three categories.
First, there is existing law. The KVKK, Turkish Code of Obligations, consumer law, intellectual-property rules, sectoral legislation, cybersecurity requirements, public-procurement law and other generally applicable rules already apply where their conditions are met.
Second, there are Action Plan implementation measures, including risk guidance, sector annexes, public-sector pilots, institutional structures and regulatory sandboxes.
Third, there is the future AI legislative regime, under which the Plan’s current concepts may eventually become directly enforceable duties.
Confusing these three categories leads to two opposite errors.
One is overstatement: claiming that every AI provider in Türkiye is already legally obliged to prepare a Model Card.
The other is complacency: claiming that nothing has changed because Parliament has not yet enacted a comprehensive AI statute.
Neither position is satisfactory.
16. Conclusion: Regulation Before Regulation
The most useful way to read Türkiye’s 2026–2030 Artificial Intelligence Action Plan is not as an AI Act that already exists.
It is better understood as regulation before regulation.
The Plan tells providers what concepts Türkiye intends to institutionalise before the legislature and sectoral regulators have finished turning those concepts into enforceable rules.
And the message is relatively consistent.
The Turkish regulatory system is moving towards an environment in which an AI provider may be expected to know what systems it supplies, classify their risks, understand the data moving through them, document their capabilities and limitations, evaluate material safety risks, preserve evidence of those evaluations, control major model changes, cooperate with downstream customers and regulators, and demonstrate that high-impact deployments have not been treated as ordinary software projects.
For providers already subject to the EU AI Act, much of this vocabulary will be familiar. The EU regime already contains formal provider and downstream-provider categories, technical-documentation duties, obligations for general-purpose model providers, safety requirements and express territorial rules.
That does not mean Türkiye will simply copy the European framework.
Nor should it.
Türkiye has its own public-law structure, sectoral regulators, data-protection regime, procurement system, industrial priorities and technology policy.
But companies providing AI services into Türkiye should recognise what has now changed.
Before August 2026, a provider could reasonably say that the direction of Turkish AI regulation remained fragmented.
After the Action Plan, that position is considerably harder to maintain.
The exact statutory duties remain unfinished.
The regulatory direction does not.
For a provider intending to remain in the Turkish market, the sensible response is therefore not premature compliance with obligations that do not yet exist. It is to build a compliance infrastructure that can absorb them when they do.
That means maintaining a reliable AI-system inventory; establishing an internal risk-classification methodology; preparing Model Card and technical-documentation templates; connecting AI assessments with existing KVKK processes; establishing model-evaluation and change-control procedures; mapping upstream and downstream provider dependencies; preserving contractual rights to obtain technical information; developing incident-response procedures; and maintaining a regulatory file capable of showing not merely what the provider says its AI does, but what the provider actually did to understand and control its risks.
That final distinction may ultimately matter more than any particular form.
When regulation arrives, fluent policies will not be enough.
Compliance will have to be capable of proof.
Asutay Duhan Meydan
Attorney at Law
Meydan AI & Tech Law
This article is intended for legal and regulatory analysis and does not constitute legal advice for any specific AI system, provider or deployment.