Integration guides · 2026-08-18
Turkey's Public AI Ecosystem 2026: Common Architecture Across Six Government Specifications
Compare the six Public AI Ecosystem 2026 specifications from the Constitutional Court, education, climate, agriculture, tax, and audit authorities across data, models, deployment, security, and metrics.
Call status as of 18 August 2026
The Public AI Ecosystem 2026 call opened on 2 March 2026. Following evaluation of institutional needs, technical specifications for six public bodies were published on 12 June 2026. Online project submissions closed at 23:59 on 6 August, and electronic signatures for completed applications closed at 23:59 on 11 August 2026.
As of 18 August 2026, TÜBİTAK's public call page contained no new announcement of project results. This article therefore does not describe winners or contract status. It analyses the six public specifications and does not direct readers to a call that is still open.
One programme, six different problem classes
Although they sit under one call, the projects are not all generative AI. Legal and education needs emphasise LLMs, VLMs, OCR, and RAG, while carbon markets, vessel movement, and financial risk require time-series work, anomaly detection, regression, simulation, and explainable machine learning.
This variety is a procurement lesson: an 'AI platform' is not one technology. If a specification does not separate problem classes and acceptance metrics, a general chat model may be presented incorrectly as the answer to every task.
| Institution | Project need | Primary methods | Data and control focus |
|---|---|---|---|
| Constitutional Court | Individual-application review and decision drafting | OCR/VLM, RAG, LLM, classification | Files remain on court servers; sourced output and human review |
| Ministry of National Education | YAZDIS textbook review | Multimodal model, RAG, multilingual analysis | Isolated deployment; expert error review and final assessment |
| Ministry of Environment, Urbanisation and Climate Change | Microeconomic carbon-market decision support | Forecasting, simulation, scenario analysis | Verified emissions and market data; policy scenarios |
| Ministry of Agriculture and Forestry | Policy analysis from BAGIS vessel data | Anomaly, route forecasting, spatiotemporal analysis | Vessel telemetry and catch records; monitoring and simulation |
| Revenue Administration | Corporate tax-loss analysis | Regression, risk detection, explainable models | Returns and e-document data; institutional service boundaries |
| Public Oversight Authority | Financial failure and anomaly analysis | Classification, clustering, MLOps | Isolated deployment; role-based reports and sector models |
Pattern 1: data comes from existing institutional systems
None of the six solutions is described as an empty chat interface. The Court uses UYAP files and case law, education uses textbook PDFs and prior error records, agriculture uses BAGIS and SUBIS, tax uses returns and e-document systems, and audit uses EFR and FinAP. Value comes from controlled use of institutional data rather than a model's general knowledge.
The first architecture artifact should therefore be a data-flow map, not a model list. Source system, transfer format, refresh cadence, owner, quality rule, user role, and target output belong on one diagram. Performance measured without separating training, test, and live data is not reliable.
Pattern 2: decision support and explainable output
The Court and education projects explicitly support expert work. Tax and audit also expect risk factors to be reported for authorised users to inspect. Producing a score is not enough; the user needs to see the data and reasoning behind it.
Citations and hallucination controls in generative systems serve the same goal as feature contribution and error analysis in predictive models: the result must be reviewable. Human approval should stand between model output and any administrative or financial outcome.
Pattern 3: acceptance metrics vary by technology
The Court specification sets OCR character-error, classification F1, decision-draft review, concurrency, and duration targets. Education defines precision and recall. The oversight authority sets a Macro F1 threshold by subsector. These are not interchangeable and cannot be reduced to a generic '95 percent accuracy' claim.
Every output needs a test set, measurement method, acceptance threshold, and accepting role. Speed, resource use, and security tests remain separate gates from model quality.
Pattern 4: deployment boundaries are part of the requirement
The Court, education, and oversight specifications explicitly describe institution-controlled infrastructure. Some also require delivery of source code, models, database components, documentation, open-source dependencies, and security-test evidence. Deployment is not an operations decision left until the end.
Where a specification requires isolation or all data to remain on institutional servers, an external API cannot replace the core workload. A gateway can only be evaluated for separately cleared general work, anonymised test sets, or a model-comparison environment.
The correct boundary for LLMTR
LLMTR makes it easier to compare Turkey-hosted and global models through one OpenAI-compatible API. Per-key spending caps, rate limits, and model allowlists can be defined, while usage records retain token, cost, status, and latency metadata without prompt or response bodies. Those controls are useful for workloads approved for external service use.
LLMTR does not become the institution's isolated MLOps stack, internal data lake, or source-code delivery merely because it exposes an API. Each specification must be read with its own deployment boundary, and every selected global provider still requires a separate data-policy review.
Source and interpretation boundary
This analysis uses TÜBİTAK's 1007-SGB-2026-01 call document, the announcement of 12 June 2026, and six institution-specific technical specifications. It makes no inference about winners, contracts, or implementation status beyond those documents.
The article is a technical comparison and does not constitute legal advice. Qualification, data processing, deployment, and contractual decisions in a specific procurement depend on the current tender documents and the institution's procurement, information-security, compliance, and legal teams.
How to assess a public-sector AI technical specification
Six steps for assessing a government AI specification across problem, data, model, deployment, security, and acceptance criteria.
- Extract the problem and decision boundary. State which work the model supports, which output it produces, and who retains final authority.
- Map the data flow. Record source systems, owners, refresh cadence, train-test-live separation, and access roles.
- Match methods to problems. Separate the outputs produced by LLM, VLM, OCR, RAG, regression, classification, and simulation components.
- Fix the deployment boundary. Map isolated, on-premises, institutional cloud, and external API options to the data class and explicit clauses.
- Write the acceptance test. Define a test set, metric, threshold, performance condition, and institutional accepting role for each output.
- Plan operating evidence. Include logs, model and data versions, rollback, security tests, monitoring, and human feedback in the delivery list.
Frequently asked questions
Is the Public AI Ecosystem 2026 call still open?
No. Online applications closed at 23:59 on 6 August 2026 and electronic signatures closed at 23:59 on 11 August 2026.
Were the Public AI Ecosystem 2026 results announced?
As of 18 August 2026, the public TÜBİTAK call page contained no announcement of project application results. This article analyses only the published specifications.
How many public institutions had specifications published?
Six: the Constitutional Court, environment, education, agriculture, tax, and public oversight authorities.
Do all six projects use a large language model?
No. Alongside LLM, VLM, OCR, and RAG work, the call includes regression, anomaly detection, time-series, clustering, and simulation problems.
Can an API gateway replace an isolated government system?
No. If the specification requires an internal or disconnected deployment, an internet API cannot replace the core system. A gateway can only serve separately approved workloads.