Trust and compliance · 2026-08-18

Public-Sector AI Applications: What the Cybersecurity Directorate's Framework Means

A technical reading of Turkey's Public-Sector AI Applications framework, covering needs discovery, roadmaps, data-quality standards, shared data spaces, and efficiency measurement.

A restrained diagram of a public-sector AI governance cycle covering needs inventory, data-quality checks, secure infrastructure, measurement, and improvement.

What the official page says, and what it does not

The Cybersecurity Directorate's Public-Sector AI Applications page brings needs discovery, implementation roadmaps, and guidance for government AI projects into one workstream. It also says work is under way to define technical data-quality criteria and standards, build shared data spaces and infrastructure mechanisms, and develop ways to measure and improve application efficiency.

The wording matters. The page describes work toward standards; it does not publish a binding, numbered standard set. A project should not invent certification clauses or article numbers that have not been published. What an institution can prepare now is a data and control inventory capable of producing evidence when detailed standards arrive.

Five workstreams inside the framework

The short official statement makes clear that public-sector AI is broader than choosing a model. Needs definition, data preparation, infrastructure boundaries, performance measurement, and institutional capability are parts of one chain. A pilot may work technically and still fail to become an auditable public service if one part is missing.

The table translates the official work areas into practical institutional outputs. It is an implementation reading of the published direction, not a legal or administrative obligation list.

Institutional outputs mapped to the Public-Sector AI Applications framework. Source: Cybersecurity Directorate, accessed 18 August 2026.
WorkstreamInstitutional outputMeasurable evidence
Needs discoveryService- and process-level use-case inventoryVolume, duration, error impact, and accountable unit
RoadmapPilot, acceptance, and scale gatesDates, owners, dependencies, and exit criteria
Data qualityData dictionary and quality rulesCompleteness, freshness, accuracy, and lineage
Shared data and infrastructureAccess, retention, and integration architectureRole matrix, data flow, and system boundary
Efficiency measurementBaseline-to-pilot comparisonQuality, time, cost, errors, and human intervention

Why data quality comes before model quality

Public data commonly contains fields with different meanings across systems, missing timestamps, stale reference tables, and unstructured notes. A larger model does not repair these defects automatically; it can hide them inside more fluent output. Source system, field owner, refresh cadence, and quality rule should therefore be recorded before model testing.

Quality controls should cover more than training data. Documents retrieved into RAG, fields accepted from users, and the authoritative record used to verify output belong to the same traceability chain. Accuracy alone is insufficient when an answer cannot be traced to a specific document version.

  • Accuracy: does the value match the authoritative source?
  • Completeness: are required decision fields present?
  • Freshness: when and through which process was the record updated?
  • Consistency: do identifiers and classifications align across systems?
  • Lineage: which system and document version supplied the information?

A shared data space is not one unrestricted pool

Shared data space should not be read as removing access boundaries. In public architecture the goal is controlled interoperability while preserving ownership, purpose, and authorisation. Common dictionaries, identity standards, access protocols, and audit trails can enable this without copying every record into one database.

The AI layer should connect under least privilege. A model call should see only fields required for its task, and a user must not retrieve a document through a vector index that they cannot access in the source system. Vector databases and caches are authorisation surfaces in their own right.

Efficiency measurement needs a baseline

A successful demonstration is not enough. Before a pilot starts, the institution needs a baseline for processing time, rework, error types, and specialist effort. Without a baseline, the claim that AI improved efficiency cannot be verified.

Quality and speed must be read together. A faster system that demands more human correction may not reduce total work. Automated metrics should therefore sit alongside human accept, edit, and reject rates, with final authority remaining with officials where an output affects an administrative outcome.

Protecting the data boundary at the model-access layer

If a data class requires an isolated deployment, an internet API does not satisfy that condition. When a gateway is considered for general, non-sensitive work, hosting location, provider data policy, retention behaviour, and contractual chain must be reviewed per model. Models listed in one platform should not be assumed to share one data path.

LLMTR's usage and billing schema stores operational metadata such as model identifiers, token counts, cost, status, latency, and message count; it has no field for prompt or response bodies. API keys are persisted as a SHA-256 hash plus a visible prefix. Those platform properties do not replace a separate review of the selected upstream provider's handling policy.

The minimum file an institution can prepare today

Preparation does not need to wait for detailed standards. Each use case can record its purpose, data fields, data owner, user roles, model task, human checkpoint, success metric, and stop condition. That record becomes the starting point for both a technical specification and a risk assessment.

This article is a technical analysis of the official page as accessed on 18 August 2026 and does not constitute legal advice. Decisions about data processing, external services, and compliance in a specific public project belong to the institution's information-security, compliance, and legal teams.

Frequently asked questions

Has Turkey published a detailed Public-Sector AI Applications standard?

The page accessed on 18 August 2026 says work is under way to define data-quality criteria and standards, but it does not contain a detailed numbered standard set.

Should a public institution start an AI project by choosing a model?

No. Service need, data class, data owner, human decision point, and success metric should be written first. Model selection follows those boundaries.

Does a shared data space mean placing all government data in one database?

No. Interoperability can be established through common dictionaries, identity standards, protocols, and audit trails while ownership and access boundaries remain intact.

Which efficiency metrics should a public AI pilot track?

Processing time, accept-edit-reject rates, error types, specialist effort, unit cost, and human intervention should be compared against a pre-pilot baseline.

Does LLMTR provide a fully isolated deployment for all public data?

No. LLMTR is an internet API gateway, not a substitute for an internal isolated system. It can only be considered for workloads whose data classification and institutional approval permit external service use.

Related posts