Writing an AI technical specification for public procurement: clause-by-clause examples

Which legislation an AI technical specification rests on

Technical specifications drafted by Turkish public institutions for artificial intelligence service procurements are governed by Law No. 4734 of 4 January 2002 (Kamu İhale Kanunu, the Public Procurement Law) and by the Hizmet Alımı İhaleleri Uygulama Yönetmeliği (Regulation on the Implementation of Service Procurement Tenders), issued under Article 53 of that Law. There is no separate body of rules specific to artificial intelligence, so language model services are specified under the same general provisions.

Article 12 of Law No. 4734 sets the boundary: “İhale konusu mal veya hizmet alımları ile yapım işlerinin teknik kriterlerine ihale dokümanının bir parçası olan teknik şartnamelerde yer verilir. Belirlenecek teknik kriterler, verimliliği ve fonksiyonelliği sağlamaya yönelik olacak, rekabeti engelleyici hususlar içermeyecek ve bütün istekliler için fırsat eşitliği sağlayacaktır.” In English: technical criteria go into the technical specification that forms part of the tender documents, and those criteria must serve efficiency and functionality, must not restrict competition, and must give all bidders equal opportunity. The same article prohibits naming a particular brand, model, patent, origin, source, or product, and allows a brand or model to be named only where no national or international technical standard exists or the technical characteristics cannot otherwise be defined, and then only with the phrase “veya dengi” (“or equivalent”).

Article 16 of the service procurement regulation repeats the same obligation for service tenders: “İşin teknik ayrıntılarını ve şartlarını gösteren bir teknik şartname hazırlanarak ihale dokümanına dahil edilir.” A technical specification setting out the technical details and conditions of the work must be prepared and included in the tender documents, and its criteria must serve efficiency and functionality without restricting competition. The third paragraph of the same article makes drafting by the contracting authority itself the rule, allowing preparation by consultancy service providers only where the nature of the work requires it and the tender officer approves.

Getting the specification right before publication matters far more than fixing it later. Under Article 29 of Law No. 4734, the tender documents are in principle not to be changed after the notice is published; mandatory changes are made through an addendum (zeyilname) that must reach every party holding the documents at least ten days before the final bid submission date. The same article allows the tender date to be postponed once by no more than twenty days on account of an addendum, and lets bidders request written clarification up to twenty days before the final bid submission date.

Two real municipal tenders show the language Turkish institutions currently use for this service. The IT Department of Bahçelievler Municipality tendered “Yapay Zeka Asistan ve Yapay Zeka Müşteri Temsilcisi Yazılımı Kiralama Hizmeti” (AI Assistant and AI Customer Representative Software Rental Service) under tender registration number 2026/743700, with the tender held on 11 May 2026. The IT Department of Başakşehir Municipality tendered “Görev Takip ve Yapay Zeka Yazılımları Hizmet Alımı” (Task Tracking and AI Software Service Procurement) under tender registration number 2026/1455679, with the tender held on 2 September 2026. Both notices describe the work as software rental or software service procurement; terms such as API access or tokens do not appear in the notice text. Keeping that institutional vocabulary in the specification does not prevent you from defining the technical requirements precisely in a separate section.

The sharpest difference between the two notices is on qualification. The Bahçelievler notice states that no professional and technical qualification information, document, or criterion has been specified, while the Başakşehir notice requires a Yazılım Yetki Belgesi (Software Authorisation Certificate) together with documents evidencing work experience. That certificate was introduced by the Kamu Bilişim Hizmet Alımı Kapsamında Katılımcıların Yetkilendirilmesi Hakkında Yönetmelik (Regulation on the Authorisation of Participants in Public IT Service Procurement), published in Official Gazette No. 31881 of 29 June 2022 and in force three months after publication, from 29 September 2022.

• The technical specification is part of the tender documents; qualification criteria belong in the administrative specification, technical criteria in the technical specification.
• No brand, model, patent, origin, or product name may be written. Measurable technical characteristics take their place.
• A Yazılım Yetki Belgesi (Software Authorisation Certificate) is issued for participants supplying software development, software integration, and software maintenance services; it requires a TS EN ISO/IEC 27001 certificate together with at least TS ISO/IEC 15504 Level 2 or at least CMMI Level 3.
• Article 19 of Law No. 4734 defines the open procedure in a single sentence: “Açık ihale usulü, bütün isteklilerin teklif verebildiği usuldür.” — the open procedure is the procedure in which all bidders may submit a tender.
• Notice periods depend on the estimated cost; for goods and service procurements below the threshold values, Article 13 of the Law sets minimum notice periods of seven, fourteen, or twenty-one days.
• Before publication, have the draft read by people representing at least two different solution approaches; a specification that has collapsed into the description of a single product can be treated as restricting competition.

The clauses a specification needs and how each one is measured

The core of an artificial intelligence service specification can be organised into ten clause headings. These headings are chosen to prevent the four problems institutions most often hit after signature: not knowing where data is processed, becoming dependent on a single model, losing visibility of spend, and basing acceptance on an accuracy claim that was never measured.

Each clause needs three things written separately: what the clause requires, which document or declaration the bidder uses to demonstrate it, and how the contracting authority will verify it at acceptance. A clause with no measurement method stays unenforceable when a dispute arises.

The table below gives those ten headings together with their rationale and measurement method. It can be used as the skeleton of the technical requirements section, with each row turned into a numbered sub-clause.

• Write each clause as “the contractor provides … and evidences this with …” rather than “the bidder shall provide …”; the first form is enforceable at acceptance.
• When you write a numeric threshold, write the measurement point too: is latency measured at the institution's network egress or at the provider's edge?
• If you notice a clause only one product could satisfy, rewrite it as a functional requirement.
• Do not request qualification certificates in the technical specification; qualification criteria belong to the administrative specification.
• Write the acceptance criteria before the tender notice. A criterion added afterwards means an addendum and lost calendar time.

Example clause texts for data processing, locality, and retention

For public institutions the most critical part of an artificial intelligence specification is where data is processed and whether it is stored. Presidential Circular No. 2019/12 on Information and Communication Security Measures was published in Official Gazette No. 30823 of 6 July 2019, and its first item reads: “Nüfus, sağlık ve iletişim kayıt bilgileri ile genetik ve biyometrik veriler gibi kritik bilgi ve veriler yurtiçinde güvenli bir şekilde depolanacaktır.” Critical information and data such as population, health, and communication records together with genetic and biometric data are to be stored securely within the country.

The third item of the same circular draws a separate line for cloud services: “Kamu kurum ve kuruluşlarına ait veriler, kurumların kendi özel sistemleri veya kurum kontrolündeki yerli hizmet sağlayıcılar hariç bulut depolama hizmetlerinde saklanmayacaktır.” Public institution data is not to be held in cloud storage services other than the institution's own systems or domestic providers under institutional control. Read together, the two items mean the specification has to tie model selection to data classification.

Where personal data is processed, Article 9 of Law No. 6698 (KVKK, the Personal Data Protection Law) applies. That article was amended by Law No. 7499 of 2 March 2024; in its current form, transfer abroad is possible where an adequacy decision exists for the destination country or international organisation, and such decisions are reviewed at least once every four years. The specification does not make that assessment; its job is to establish the clauses that give the institution's compliance unit the information it needs to decide.

The example clause texts below can be lifted into a specification as they stand. None of them describes a particular product; each is an objective requirement that different providers can satisfy.

• Example clause — Retention declaration: “The contractor declares in writing whether prompt texts and model response bodies transmitted under the service are written to usage, billing, or logging databases. Where they are, the retention period, storage location, roles with access, and deletion method are each stated separately.”
• Example clause — Training use: “Content belonging to the authority may not be used by the contractor or by third parties for model training, fine-tuning, or building evaluation data sets. The contractor provides the same undertaking on behalf of every sub-provider included in the service.”
• Example clause — Hosting country: “For every model offered under the service, the hosting country is shown separately in the model list and in the technical documentation. The authority may restrict use to models hosted in specific countries through configuration, in line with its data classification.”
• Example clause — Critical data separation: “In scenarios processing content the authority has classified as critical, only models hosted in Türkiye are used. The list of such scenarios is defined in an annex to the contract, and the contractor documents how the restriction is technically enforced.”
• Example clause — Log content: “Usage records do not hold prompt or response text. Records consist of date, unit, model identifier, request count, input and output token counts, and amount fields.”
• Example clause — Sub-provider and transfer chain: “The contractor lists every sub-provider involved in delivering the service, their hosting countries, and their data processing roles. Any change to that list is notified to the authority in writing at least thirty days in advance.”
• Example clause — Deletion on termination: “On expiry or termination of the contract, all content belonging to the authority and any derived data are deleted within thirty days, and the deletion is confirmed to the authority in writing.”

Clauses that reduce model lock-in and preserve portability

The most expensive mistake in an artificial intelligence procurement is a specification that locks the institution to one model or one interface. Language models are retired far faster than conventional software components, and a single deprecation can force an institution back into procurement. The specification answers that risk by requiring redundancy and portability instead of naming a model.

Article 12 of Law No. 4734 already bars characteristics and definitions aimed at a particular brand or model. In practice that prohibition works in the institution's favour: writing a capability definition instead of a model name preserves competition and makes mid-contract model changes possible. Writing “a model that meets the authority's minimum success threshold on its sample set for Turkish text summarisation” expresses the same need without naming anything.

Interface compatibility is the single clause that raises portability the most. When the specification names a widely used request and response shape, changing provider limits the work in the institution's own application to the service address and the model identifier. That lowers switching cost in the next tender cycle and widens the bidder pool.

The example clauses below target dependency reduction and name no platform.

• Example clause — Model diversity: “The service offers models from at least two different providers capable of performing the tasks covered by the tender. The authority may switch between those models at no additional charge throughout the contract term.”
• Example clause — Fallback model: “A primary and a fallback model are defined for each use case in an annex to the contract. Where the primary model becomes unavailable, the contractor provides the switch to the fallback model without requiring any code change in the authority's application.”
• Example clause — Deprecation notice: “The contractor notifies the authority in writing as soon as it learns that a model in use will be retired, and proposes at least one functionally equivalent alternative in that notice. Notice is given at least sixty days before the retirement date.”
• Example clause — Interface standard: “The service is delivered through an endpoint compatible with a widely used chat completion interface. Compatibility is measured by the same client code running with only the service address and the model identifier changed.”
• Example clause — Portability test: “At acceptance, the same task is run against at least two different models through a client application chosen by the authority, and the fact that a configuration change alone produced the result is recorded in the acceptance minutes.”
• Example clause — Exit rights: “On expiry of the contract the authority receives, at no cost, the technical information needed to move its application to another provider. The contractor declares in writing that the authority's application code contains no mandatory component proprietary to the contractor.”
• Example clause — Version pinning: “The authority may pin the model version in critical scenarios. A version change is not applied automatically without the authority's written approval.”

Metering, access security, service level, pricing, and acceptance clauses

Usage metering is what separates an artificial intelligence procurement from conventional software rental. Consumption is variable, so an institution that cannot see which unit is spending what has no way to enforce a ceiling, and the budget surprise lands mid-year. The specification resolves this with per-unit access keys, per-unit ceilings, and a monthly report.

The pricing clause is tied directly to the evaluation method. Article 40 of Law No. 4734 provides: “Ekonomik açıdan en avantajlı teklif, sadece fiyat esasına göre veya fiyat ile birlikte işletme ve bakım maliyeti, maliyet etkinliği, verimlilik, kalite ve teknik değer gibi fiyat dışındaki unsurlar da dikkate alınarak belirlenir.” The most economically advantageous tender is determined on price alone or on price together with non-price factors such as operating and maintenance cost, cost effectiveness, productivity, quality, and technical merit. The same paragraph requires the monetary values or relative weights of any non-price factors to be set out in the tender documents. In both verified municipal notices the award is made on price alone, which means every quality requirement has to be written into the technical specification as a minimum condition.

Service level clauses need a numeric threshold and a measurement point. Phrases such as “high performance” are useless at acceptance, whereas “monthly availability of 99.5 percent, p95 time to first token of 2,000 milliseconds, measured at the authority's network egress” is measurable and beyond argument. Set thresholds against the institution's real need; a threshold set higher than necessary narrows competition.

Acceptance criteria are the most frequently skipped part of a specification. Because acceptance cannot rest on an unmeasured accuracy claim, the sample set prepared by the authority has to be defined in the specification itself. That sample set should be drawn from the institution's real workload, stripped of personal data, and ready before the tender notice.

• Example clause — Per-unit keys: “A separate access key is defined for each directorate or unit. Key creation, revocation, and permission changes can be performed by the authority through the management interface.”
• Example clause — Ceiling and rate limit: “A monthly spending ceiling and a per-minute request limit can be set for each key. When a ceiling is reached, requests are rejected and the authority is notified; exceeding a ceiling does not generate automatic additional spend.”
• Example clause — Monthly usage report: “Within the first five working days of the following month, the contractor provides a machine-readable usage report containing unit, model identifier, request count, input and output token counts, and amount columns. The report reconciles exactly with the invoice.”
• Example clause — Key storage: “Access keys are not stored in plain text. The contractor declares in writing how keys are stored and the maximum number of minutes within which key revocation takes effect.”
• Example clause — Service level: “Monthly availability is at least 99.5 percent. Latency is expressed as p95 time to first token and measured at the authority's internet egress. Measurement results appear in the monthly report, and the deduction applied in months falling below the threshold is defined in the contract.”
• Example clause — Unit price transparency: “Pricing is given per model as a unit price per thousand input tokens and per thousand output tokens. The unit price schedule is submitted with the bid and cannot be increased during the contract term without the authority's written approval.”
• Example clause — Acceptance test: “Acceptance is carried out against a set of at least two hundred samples prepared by the authority and stripped of personal data. A minimum success threshold is defined numerically per scenario in an annex to the contract, with a remediation period granted for scenarios falling below it.”
• Example clause — Intellectual property: “Usage rights over content sent by the authority and over output produced from that content belong to the authority. The contractor may claim no right to retain, reproduce, or transfer that content to third parties.”
• Example clause — Human approval: “Output presented directly to citizens or carrying legal effect is not published without approval by staff of the relevant unit. The approval workflow and the record of the approving staff member are kept by the system.”
• Example clause — Output responsibility: “The interface shown to users states clearly that model output is probabilistic and may contain errors. The contractor provides an error reporting mechanism, and reports are summarised in the monthly report.”

Which of these clauses LLMTR answers directly

LLMTR is a gateway platform providing access to both Turkey-hosted and global language models through a single OpenAI-compatible API. The purpose of this section is not to translate the platform into specification language but to show which of the clauses above have a verifiable counterpart on the platform side; the specification itself still has to be written brand-independently.

On the data processing clauses, what is verifiable is this: user prompts and model response bodies are not written to the usage and billing database, and usage records consist of measurement fields such as token counts, model identifier, and amount. Customer API keys are stored as SHA-256 hashes rather than plain text, and provider keys are held only in environment variables. Those three properties answer the retention declaration and log content clauses directly.

On data locality, the catalog marks Turkey-hosted models separately. It includes Turkey-hosted models such as llmtr/gemma-4, llmtr/qwen3-6-35b, llmtr/medgemma-4b, llmtr/trendyol-7b, llmtr/magibu-11b-v8, llmtr/qwen3-5-4b, llmtr/ornith-1-35b, and llmtr/embeddinggemma-300m, alongside models from global providers such as OpenAI, Anthropic, Google, xAI, Qwen, and Mistral called from the same catalog. A clause restricting critical scenarios to domestically hosted models becomes enforceable through configuration because of that separation.

On model diversity and interface compatibility, the decisive factor is the single /v1 surface: when the provider or model changes, what changes in the institution's application is limited to the service address and the model identifier. Fallback model definition and the portability test clause are measurable against that structure.

On metering and pricing, each unit can hold its own API key with its own rate limit, its own spending ceiling, and its own usage report. One pricing distinction matters here: an 8% platform margin applies to credit top-ups, and no margin is added to model unit prices. That distinction also describes how the unit price transparency clause is verified — the unit price schedule multiplied by the monthly usage report should reproduce the invoice amount.

• Retention declaration clause: the fact that prompt and response bodies are not written to the usage database can be verified by declaration and through a sample request identifier.
• Data locality clause: hosting country is visible in the catalog and the model identifier is returned with the response.
• Model diversity clause: because domestic and global models sit in the same catalog, defining a fallback model requires no extra integration.
• Interface compatibility clause: the OpenAI-compatible /v1 surface keeps the portability test to a configuration change.
• Metering and ceiling clauses: per-unit key, rate limit, ceiling, and usage report can each be defined separately.
• Key security clause: customer keys are stored as SHA-256 hashes and provider keys are held only in environment variables.

Sources

The legislative references and tender details in this article were verified against the primary sources below. Last checked: 13 August 2026.

This content is informational and does not constitute legal advice. The final assessment rests with the institution's compliance and legal units.

• Law No. 4734 (Kamu İhale Kanunu, Public Procurement Law), Articles 5, 12, 13, 19, 29, and 40 — mevzuat.gov.tr
• Hizmet Alımı İhaleleri Uygulama Yönetmeliği (Regulation on the Implementation of Service Procurement Tenders), Article 16 — mevzuat.gov.tr
• Kamu Bilişim Hizmet Alımı Kapsamında Katılımcıların Yetkilendirilmesi Hakkında Yönetmelik (Regulation on the Authorisation of Participants in Public IT Service Procurement), Official Gazette No. 31881 of 29 June 2022 — resmigazete.gov.tr
• Presidential Circular No. 2019/12 on Information and Communication Security Measures, Official Gazette No. 30823 of 6 July 2019 — cbddo.gov.tr
• Law No. 6698 (KVKK, Personal Data Protection Law), Article 9 as amended by Law No. 7499 of 2 March 2024 — mevzuat.gov.tr
• AI Assistant and AI Customer Representative Software Rental Service tender notice, registration number 2026/743700 — bahcelievler.istanbul
• Task Tracking and AI Software Service Procurement tender notice, registration number 2026/1455679 — milliyet.com.tr official notices

Steps for preparing an AI service procurement technical specification

Six steps to complete the technical specification before a public institution publishes an artificial intelligence software rental or service procurement tender.

1. Write out use cases and data classification. List every scenario in which the service will be used and record, for each one, where the data processed sits in the institution's classification. Put the scenarios classified as critical into a separate table; that table becomes the basis of the data locality clause.
2. Prepare the acceptance test sample set. Build a sample set drawn from the institution's real workload and stripped of personal data, and write the expected output for each scenario. Fix the set size and the minimum success threshold numerically; those values go verbatim into the acceptance clause.
3. Write the technical requirement clauses brand-independently. Write data processing, data locality, model diversity, interface compatibility, usage metering, access security, service level, pricing, acceptance, and liability as separate clauses. In each one state what is required, which document the bidder uses to demonstrate it, and how the authority will verify it.
4. Run a measurability check. Read each clause and ask a single question: if this clause is breached, how do I prove it? Clauses with no numeric threshold, measurement point, or verification method are either made measurable or removed.
5. Run a competition and brand-independence check. Have the draft read by people representing at least two different solution approaches from outside the institution. Rewrite as functional requirements any clause only one product could satisfy, and move qualification certificate requests that have crept into the technical specification back to the administrative specification.
6. Plan the notice calendar and lock the documents. Determine the notice period that applies given the estimated cost and lock the specification before the notice date. Reflect in the calendar that a post-notice change requires an addendum, that the addendum must be served at least ten days before the final bid submission date, and that the tender date can be postponed by no more than twenty days.

Frequently asked questions

Is there separate legislation for AI procurement specifications in Türkiye?

There is no technical specification regime specific to artificial intelligence. The specification is prepared under the general provisions of Law No. 4734 (Kamu İhale Kanunu, the Public Procurement Law) and the Hizmet Alımı İhaleleri Uygulama Yönetmeliği (Regulation on the Implementation of Service Procurement Tenders). Article 12 of the Law and Article 16 of the Regulation require technical criteria to serve efficiency and functionality, to avoid restricting competition, and to give all bidders equal opportunity.

Can I name a specific model in the specification?

Article 12 of Law No. 4734 prohibits naming a particular brand, model, patent, origin, source, or product. A brand or model may be named only where no national or international technical standard exists or the technical characteristics cannot otherwise be defined, and then only together with the phrase “veya dengi” (“or equivalent”). In practice the correct route is a measurable capability definition and an acceptance threshold instead of a model name.

Is a Software Authorisation Certificate required in AI software tenders?

The contracting authority decides according to the nature of the work. The two verified examples differ: the Bahçelievler Municipality notice under registration number 2026/743700 specifies no professional and technical qualification criterion, while the Başakşehir Municipality notice under registration number 2026/1455679 requires a Yazılım Yetki Belgesi (Software Authorisation Certificate). The certificate was introduced by the regulation published in Official Gazette No. 31881 of 29 June 2022.

How should a data locality clause be written?

The clause has to tie model selection to data classification. A workable text states that the hosting country is shown separately for every model in the service, that only models hosted in Türkiye are used in scenarios the authority classifies as critical, and that the contractor documents how that restriction is technically enforced. Presidential Circular No. 2019/12, requiring critical data to be stored securely within the country, can serve as the underlying basis.

Can the technical specification be changed after the tender notice is published?

Under Article 29 of Law No. 4734 the tender documents are in principle not changed after publication. Where a change is unavoidable an addendum is issued, and it must reach every party holding the documents at least ten days before the final bid submission date. An addendum may postpone the tender date once by no more than twenty days. This is why acceptance criteria need to be written before publication.

How is quality secured when the award is made on price alone?

Article 40 of Law No. 4734 allows the most economically advantageous tender to be determined on price alone or on price together with non-price factors. In a price-only tender, quality is secured only to the extent it is written into the technical specification as a minimum condition. Service level thresholds, the acceptance test sample set, and the minimum success threshold therefore have to be defined numerically in the specification.

Related posts

• Public IT and software authorization certificates: which document does an AI tender in Turkey require?
• Planning an AI pilot budget within Turkey's 2026 direct procurement limit

• Model catalog
• Pricing
• Security documentation
• Usage tracking