Public sector AI projects are growing fast, and so is the number of proposals that promise much and deliver little. This guide gives procurement officers concrete criteria for telling a serious proposal from a marketing document.
Why public sector projects are different
In a private company an AI project is measured by return. In a government institution it is measured by three things at once: impact on the service, security of the data, and the ability to keep running after the vendor's contract ends.
The third is the most neglected. Many projects run well during the contract and stop afterwards, because the knowledge stayed with the vendor and never transferred to the institution's own team.
So the first question in evaluating a proposal is not "what does it cost?" but "what remains with us when the contract ends?"
Data sovereignty: where is data actually processed?
"In the cloud" is not an answer. The country, the data centre and the provider must be named.
Many institutions require that data stay within national borders. That requirement automatically rules out most off-the-shelf public services and points the project towards deployment inside the institution's own infrastructure.
On-premise deployment costs more up front and less over time, because it removes the per-user monthly fee entirely.
Air-gapped networks: does AI work without internet?
Yes. Models that run locally need no external connection, which makes them suitable for the closed networks used in sensitive sectors.
Technically, the model is downloaded and executed on the institution's own servers, and no request leaves the network. Updates are applied manually and on the institution's decision.
When evaluating a proposal, ask directly: does the system still work if we cut the internet completely? If the answer is no, it is not suitable for a closed network — whatever the proposal claims.
Integration with legacy systems
Government institutions do not start from zero. Systems have been running for years and some have no modern integration interfaces.
A serious proposal names each system it will integrate with, states the method, and says who provides access. A weak proposal says only "integration-ready".
Ask for a data-flow diagram at proposal stage: where data is read, where it is processed, where it is written. If it cannot be drawn on one page, the vendor has not understood the project yet.
Acceptance criteria: how do we know it worked?
Acceptance criteria must be written before implementation starts, not after. Without them, handover becomes an open-ended argument.
Measurable criteria: transaction time before and after, share of requests handled automatically, number of errors detected, time to train a new employee.
Criteria to avoid because they cannot be measured: "improved efficiency", "better service quality", "digital transformation". These are goals, not acceptance criteria.
Knowledge transfer and sustainability
Require in the tender documents that handover includes complete technical documentation, training for the institution's team, and source code or access rights as appropriate to the project.
Require documented knowledge-transfer sessions, not merely "technical support". Support ends with the contract; knowledge stays.
An institution that cannot operate its own system a year after handover did not buy a system — it bought a permanent subscription to the vendor.
What Hendez brings to public sector work
Internal platforms running on the institution's own infrastructure, integration with e-government services, and secure deployments on networks closed to the internet.
Data-protection-compliant architecture, role-based access rights, and tamper-evident access logs.
Training is a core part of every project rather than an add-on — a system nobody on the team can operate is not a completed project.
We work in Turkish, English and Arabic, and we are based in Istanbul.