Writing a Technical Specification for a Public-Sector AI Project

Why is an AI technical specification different from an ordinary software specification?

Because an AI system does not give the same output every time, and its accuracy can only be measured statistically, on a defined set of data. In conventional software, "a report is produced when the user clicks the button" is an acceptance criterion in its own right. In AI, "the system answers questions correctly" cannot be measured until you state which questions, which document set, which definition of correct and which threshold. Two more facts come on top: the system's quality depends heavily on the data the institution provides, and the underlying model may be updated over time and behave differently afterwards. A good specification turns these three facts, probabilistic output, dependence on data and changing models, into measurable clauses.

This article is general guidance. On procurement procedure, required documents and contract terms, your institution's procurement unit and legal counsel have the final word; check the current text of the legislation on mevzuat.gov.tr and the Public Procurement Authority's EKAP platform.

What does Turkish public procurement law expect from a technical specification?

It expects technical criteria aimed at efficiency and functionality that do not restrict competition, give all bidders equal opportunity and do not point to a particular brand or model. Article 12 of Public Procurement Law No. 4734 says so explicitly: a technical specification may not name a particular brand, model, patent, origin, source or product. Only where no national or international standards exist, or technical characteristics cannot be defined, may a brand or model be mentioned, and then only with the words "or equivalent". Article 16 of the Regulation on Service Procurement Tenders repeats these principles, adds that the specification may not contain provisions that block domestic bidders, and makes preparation by the contracting authority itself the rule. Where the nature of the work requires it, and with the approval of the tender authority, the specification can be prepared by consultancy service providers.

For AI, the practical meaning is this: the specification describes measurable behaviour, not a model name. Instead of "model X or equivalent", writing "a solution that meets the stated criterion on the institution's acceptance set over Turkish internal regulations and can run on the institution's closed network" fits both the law and the purpose better. A year later the named model may have been updated or replaced; measurable behaviour stays valid.

Four more provisions of the same legislation are worth recalling before you write:

• Combining goods and services: Under Article 5 of Law No. 4734, procurement of goods, services and works may not be tendered together unless there is an acceptable natural link between them. For an on-premise deployment, decide early with your procurement unit whether servers and accelerator hardware are bought in the same tender as software development or separately.
• Estimated cost: Article 9 requires the estimated cost to be set through price research of every kind. Discussing the same needs statement with several firms tests the realism of the specification as well as the price.
• Consultants cannot bid: Under Article 11, contractors that provide consultancy services for the work being tendered may not take part in that tender. If you have a firm prepare the specification, that firm cannot bid.
• Non-price factors: If non-price factors such as quality or technical merit are used, Article 61 of the Regulation requires their monetary values or relative weights, the calculation method and the documents to be submitted to be stated clearly in the administrative specification; they may not be defined around a brand or model.

Which sections should an AI technical specification have?

Twelve sections, from purpose and scope to handover, tie AI-specific risks to measurable clauses. Adapt the template below to your project:

Section	What it states	AI-specific point
1. Purpose and scope	The job to be done, users, what is out of scope	The task itself instead of "AI-supported": which question, answered from which documents
2. Current state and data	Document types, volume, formats, source systems	Share of scanned documents, personal data, anonymised samples for bidders
3. Functional requirements	Tasks, user roles, screens, integrations	Source citation, "not found" behaviour, human approval steps
4. Performance and acceptance	Acceptance set, metrics, thresholds, test procedure	The set stays with the institution; metrics chosen per task
5. Deployment environment	Institution's data centre, closed network, hardware	Running without external services; hardware defined by performance
6. Information security	Authorisation, logging, security testing	Preserving source-system permissions, prompt injection tests
7. Personal data	Roles, processing terms, retention and destruction	Institution data not used for model training, masking
8. Model and version management	Models used, licences, update procedure	Rerunning the acceptance set when a model changes
9. Documentation	Installation, user and admin guides, architecture	Evaluation report, known limitations, component and licence list
10. Training	User and administrator training	The system's limits and the duty to verify answers
11. Maintenance, support and monitoring	Support scope, updates, quality monitoring	Repeating measurement as documents and regulations change
12. Rights and handover	Source code, model weights, test sets, handover	Open-source licences, handover terms that reduce vendor lock-in

How should the data section be written?

Bidders cannot price realistically without knowing the data, so the data section has to describe the institution's documents honestly and measurably. State the document types and approximate volumes, formats (text PDF, scanned image, word-processor file, database record), the share of scanned documents, the language, the systems the documents live in and how often they change. Personal data and classification levels belong here too. If possible, attach anonymised representative samples to the tender documents or let all bidders inspect them on equal terms. Otherwise bids rest on assumptions, and the differences between them reflect uncertainty rather than the work.

Also state who prepares correct answers and labels, the institution's experts or the contractor, and if the contractor, how the institution checks them. Whether data may leave the institution, and in which environment and with which permissions contractor staff can access it, are part of the data section as well.

How do you set acceptance criteria and evaluation metrics?

Define acceptance on an acceptance set that the institution prepares before the tender and does not share with the contractor, using a metric suited to the task and thresholds written in advance. The set is built by subject experts from real use cases and includes the hard cases: questions the documents cannot answer, repealed regulations, scanned documents. The full set is not handed to the contractor; a separate sample set can be shared for development. Otherwise the system gets tuned to the acceptance set rather than to the job.

Task	Suggested metric	Watch out for
Document classification and routing	Precision and recall per class	Overall accuracy hides errors in rare classes
Field extraction from documents	Exact-match rate per field	Separate thresholds for fields such as amounts and ID numbers
Question answering over documents	Share of correct answers with the correct source; "not found" rate on unanswerable questions	A correct answer with the wrong source does not count
Summarisation	Factual errors found in expert review	The review guideline is written in advance
All tasks	Response time, concurrent users, availability	Measured in the institution's own environment

Thresholds need a rationale. Measuring today's process (staff error rate and time on the same work), running a pilot, or gathering realistic information from several firms during market research are the ways to get one. An unjustified "99% accuracy" clause is either a target no bidder can meet or, because the measurement is undefined, a sentence every bidder can claim to meet. Write the test procedure as well: who runs the test, in which environment and with how many attempts; how many chances the contractor gets to fix failures; which report documents the results; and which committee signs off.

The model contractual AI clauses (MCC-AI), updated in 2025 by the public procurement community supported by the European Commission, are a useful checklist of headings: risk management, data and data governance, technical documentation, record-keeping, transparency, human oversight, accuracy, robustness and cybersecurity, and rights to data sets. Their commentary notes that "an appropriate level of accuracy" leaves considerable room for interpretation, which is why it suggests specifying the required level in a separate annex. The same document states plainly that the clauses do not cover intellectual property, acceptance, payment, delivery deadlines, applicable law or liability; the institution has to settle those itself. MCC-AI were written for the EU AI Act and are not binding on institutions in Türkiye.

How do you express KVKK and data location in the specification?

State clearly that the institution is the data controller, which data the contractor processes on which instructions, where the data stays and where it may not go. The Turkish Personal Data Protection Authority's generative AI guide explains the distinction between controller and processor and which decisions can be left to a processor by contract. Article 12 of the Personal Data Protection Law (KVKK, Law No. 6698) makes the controller jointly responsible for security measures with anyone processing data on its behalf, and Article 9 allows transfers abroad only on the basis of an adequacy decision, appropriate safeguards or narrow incidental cases. With a cloud language model service, prompts and document passages travel to the provider's infrastructure, so data location has to be specified for where the model runs, not only for where documents are stored.

Public institutions have one more framework. Presidential Circular 2019/12 on Information and Communication Security Measures requires critical data such as population, health and communication records and genetic and biometric data to be stored securely within the country, and data belonging to public institutions not to be kept in cloud storage services other than the institutions' own systems or domestic providers under institutional control. Within that framework, the specification can include clauses such as:

• Institution data, prompts, intermediate outputs and logs will not leave the environment designated by the institution.
• Institution data will not be used to train general-purpose models of the contractor or third parties.
• Personal data not needed for the processing purpose will be masked before processing, under rules agreed with the institution.
• The retention period for prompt and answer logs will follow the institution's personal data retention and destruction policy.

How do you write security and on-premise deployment requirements?

The circular and the Information and Communication Security Guide prepared under it already bind the institution; the specification should refer to them and add AI-specific risks. Under the circular, new information systems in public institutions must follow the procedures and principles in the Guide. The circular also requires, to the extent possible, a written commitment from the manufacturer or supplier that procured software and hardware contain no feature or back door unsuited to their purpose, and requires procured or developed software to pass security testing before use. For AI, add:

• Permissions: The system must not use a document in an answer that the user cannot read in the source system. This has to be enforced inside retrieval and tested at acceptance with users of different permission levels.
• Prompt injection: Instructions embedded in documents must not change the system's behaviour; these scenarios belong in the security tests.
• Logging: Who asked what and when, which documents were used and what was answered must be kept for audit.
• Closed network: If the system runs without external connections, state how models, libraries and updates reach that environment.
• Model provenance: Document the source and licence of the model weights used and how their integrity is verified.
• Hardware: Define hardware by performance requirements rather than brand and model, for example an acceptable response time at a given document volume and number of concurrent users. In service procurement, also remember that the technical characteristics of equipment used in the work are to be set so that domestic goods can be used too.

How do you write documentation, intellectual property and handover terms?

List the deliverables and the rights that stay with the institution item by item; in an AI project that list includes models, configuration and evaluation assets as well as code and manuals. For documentation you can request installation, user and administration guides, an architecture document, a data flow diagram, a list of the models and open-source components used with their licences, the acceptance test report, the evaluation method and known limitations.

In the rights section, state separately who owns the source code, model weights adapted with institution data, prompt templates and configuration, acceptance and development sets, and evaluation scripts. For components that do not pass to the institution, state under which licence, for how long and in what scope the institution may use them. The MCC-AI annex on data sets serves the same goal: letting the institution keep using the data sets after the contract ends and reducing the risk of vendor lock-in. Handover of data and indexes or their deletion at the end of the contract, knowledge transfer, and the documents another contractor would need to take over the work are also part of the handover clause.

Hypothetical example: how do you write acceptance clauses for a regulations assistant?

This example is hypothetical; the numbers illustrate the method and should be set from your own measurement. A directorate general wants an assistant on its closed network where staff can ask questions about internal regulations, circulars and procedures and see each answer with the provision it relies on. The acceptance section could include:

1. Before the tender, the institution prepares an acceptance set of 300 questions with correct answers from its internal regulations. Some questions have no answer in the documents; some concern repealed regulations. The set is not shared with the contractor; a separate sample set is provided for development.
2. For questions answered in the documents, the answer must be judged correct by the institution's experts and must cite the regulation and article it relies on. An answer without a source does not count as correct.
3. For questions with no answer in the documents, the system must state that no answer was found.
4. An answer based on a repealed regulation counts as wrong.
5. In a test with three user roles of different permission levels, no user may be shown content from a document they are not authorised to read.
6. The system must run on the institution's closed network without connecting to external services.
7. When a model or component is updated, the acceptance set is rerun; if results fall below the acceptance thresholds, the update does not go live.

Thresholds such as the share of correct, sourced answers are set from values measured in a pilot and in staff's current search process. Check with your procurement unit that these clauses are consistent with the administrative specification and the draft contract.

What are the common mistakes in AI technical specifications?

• Naming a model, brand or cloud service.
• Using unmeasurable phrases such as "AI-supported", "smart" or "high accuracy".
• Writing a percentage without a measurement definition or acceptance set.
• Leaving the data section empty and forcing bidders to price on assumptions.
• Accepting the system on a demo or presentation alone.
• Not regulating model updates and the retesting that should follow.
• Not stating rights to source code, adapted models and test sets.
• Putting hardware and software in one tender without assessing the link between them, or splitting interdependent parts across tenders and leaving integration with no owner.

How can you get help while preparing the specification?

Talking to several firms about the same needs statement during market research is the most direct way to test the specification's feasibility and the estimated cost. Hold those conversations on equal terms: the same needs statement, the same anonymised samples, the same questions. If you want a firm to prepare the specification, remember that this is a consultancy service and that firm will not be able to bid. We cover writing scope and acceptance criteria in our article on scoping an AI project, and on-premise deployment options in our article on on-prem and sovereign AI.

Our AI for public institutions page describes how we work with an itemised delivery model that answers each clause of the technical specification and has written acceptance criteria. If you would like a technical view on your needs statement during market research, the first meeting is free.