Public Sector AI API Guide: LLM Access Architecture for Government Institutions and Contractors

A public sector AI API setup means government institutions — and the contractors serving them — access large language models through a single, auditable layer with budgets capped in advance. In the right architecture, citizen data is masked before the API call, spending is limited per key, and the contract and invoice stay with a local counterparty; Onysoft AI Gateway provides that layer through one OpenAI-compatible API.

The ground is prepared: Türkiye's AI Action Plan 2026-2030 positions AI as a natural component of public services and targets opening 2,000 public datasets to developers. That is a concrete opportunity window both for institutions improving their own processes with LLMs and for contractors building services on top of that data. (For a developer's reading of the plan, see our action plan guide.)

This guide walks through the four critical questions of the public sector context one by one: why a corporate API layer rather than individual chat accounts, which pattern handles citizen data, what a local contract changes on the procurement and accounting side, and which steps build a pilot project from zero.

Why Do Government Institutions Need an AI API Now?

Because AI is already being used in the public sector — the question is whether that happens through a controlled API layer or through staff members' individual chat accounts. Regulation scanning, circular summarization, petition classification, and reducing call-center load are among the tasks LLMs are most mature at today; the staff doing this work will reach the tools one way or another. If the institution offers no official channel, shadow usage emerges: citizen data pasted into personal accounts, outputs that cannot be logged, decisions that cannot be justified.

A corporate API layer reverses that picture:

• One gate: Every unit accesses through the same endpoint; which unit sent what to which model is logged per request.
• Separation of authority: Each unit or project gets its own API key; access is cut by revoking a single key when needed.
• Budget visibility: Spending can be reported per unit and per project — budget justification rests on records, not estimates.
• Model flexibility: One integration reaches 739+ models; vendor lock-in risk disappears at the architecture level.

The action plan's opening of 2,000 public datasets demands the same architecture: any team building citizen-facing assistant, search, or summarization services on open data first needs a reliable, measurable LLM access layer.

Can Citizen Data Be Sent to an LLM? Data Classification and Masking

Not in raw form; the correct pattern is to separate scenarios by data class and mask personal data at the application layer before the API call. A significant share of public sector scenarios contains no personal data at all — legislation, circulars, technical specifications, open data. In scenarios that do, identity fields (full name, national ID number, address, phone) are replaced with placeholders before reaching the model; the model works on masked text and results are re-mapped on the institution's side.

Scenario	Typical data	Personal data risk	Recommended pattern
Legislation / circular summarization	Publicly available text	None	Direct API call
Internal knowledge assistant	Directives, handbooks, minutes	Low	Curate the document pool, anonymize where needed
Petition / application summarization	Name, national ID, address	High	Pre-call masking (NER/regex), post-call re-mapping
Call-center transcript analysis	Voice transcripts, personal narrative	High	Pseudonymization + aggregate/statistical analysis only

Masking is technically simple: regular formats such as national ID and phone numbers are caught with regex, free-text fields such as names and addresses with entity recognition (NER), and converted into tags like [FULL-NAME] and [NATIONAL-ID]. Once this pattern is in place, identity data never reaches the API provider — and your privacy notice and data-processing inventory simplify accordingly. The full KVKK picture deserves its own guide: KVKK-compliant AI usage.

Note: This section is not legal advice; consult your institution's KVKK officer and legal counsel on personal data processing.

Procurement and Accounting: Local Contract, E-Invoice, and the Simplified Purchasing Framework

Working with a local contracting party resolves three chronic frictions of public and contractor accounting at the source: foreign payments, documentation, and the absence of an accountable counterparty. Buying AI services directly from abroad means paying in USD with a foreign card, receipts that are often inadequate as expense documents, and no counterparty under Turkish law when something goes wrong. On Onysoft, the contracting party is Onysoft Veri Merkezi A.Ş., established in İzmir, Türkiye, and invoices are issued in Turkish lira at the central bank (TCMB) rate.

The e-invoice flow is designed for corporate buyers: during registration you enter your tax ID (VKN) in the billing details, and the "Query from GİB" button checks the tax registry live — if you are an e-invoice taxpayer your legal title auto-fills and you receive an e-Fatura; otherwise an e-Arşiv invoice is issued automatically. No manual title entry, no wrong-scenario invoices, no cancel-and-reissue loops.

Two points matter especially to budget and financial services units:

• Tax side: The reverse-charge VAT (KDV-2) and withholding obligations that arise with foreign AI subscriptions do not arise on a lira-denominated invoice from a local supplier — the declaration burden disappears.
• Purchasing method: For small-value pilots, simplified procedures institutions use (such as direct procurement) are practically easier with a Türkiye-established supplier issuing lira invoices; for contractors, documenting the sub-service purchase also becomes cleaner.

Note: This section is not legal or financial advice; purchasing procedures and tax obligations vary by institution and contract — consult your financial services unit and tax advisor.

Budget Discipline: How Overspending Becomes Technically Impossible

Budget overruns are prevented by architecture, not by rules: on Onysoft, every request passes a balance pre-check before reaching the provider. The system estimates the request's cost with a 1.2 buffer factor; if the balance is insufficient, the request returns a 402 without ever being processed. A surprise invoice is impossible in this architecture — spending can only go as far as the pre-loaded lira balance, and when the balance runs out the system stops automatically, with no negative balance.

Four more control layers sit on top:

• Key-level limits: Model and token limits can be defined per API key — a unit's pilot key cannot exceed its ceiling.
• Real cost per request: Every response returns the request's actual cost in a cost field, with the lira equivalent shown in the dashboard. Spending is traceable at the request level.
• Audit-ready reports: Usage reports filter by date, model, and status; they can be downloaded as PDF or shared as a branded e-mail report — feeding directly into internal audit and budget justification files.
• Automatic savings: OnyRouter (onysoft/auto) routes simple tasks to economical models with free routing — no extra charge for the routing itself.

In the public sector context these features are not nice-to-haves but preconditions: a unit with a fixed annual budget cannot comfortably use any cloud service whose upper bound is not technically guaranteed.

How It Works on Onysoft: Setup for Institutions and Contractors

Setup is short enough to test before the purchasing decision and completes in five steps:

1. Account and billing details: After registration, enter your tax ID in the billing details; the GİB query verifies your legal title and the e-Fatura/e-Arşiv scenario is determined automatically.
2. Project and key structure: Generate a separate API key per unit or project; define model and token limits per key.
3. No-code evaluation: Try the same prompt across multiple models side by side in the in-panel Playground and Chat — see which model class is sufficient before writing a technical specification.
4. Integration: In existing OpenAI-compatible code, only base_url changes.
5. Monitoring: Pull usage reports per unit; log the cost field from each response into your spending records.

An example call with the masking pattern:

from openai import OpenAI

client = OpenAI(
    base_url="https://api.onysoft.com/v1",  # the only line that changes
    api_key="sk-ony-YOUR_KEY",
)

# Personal data was masked at the application layer BEFORE the call
response = client.chat.completions.create(
    model="anthropic/claude-sonnet-5",
    messages=[{"role": "user", "content":
        "Summarize this application in three bullets and suggest the responsible unit: "
        "[FULL-NAME], holder of [NATIONAL-ID], requests zoning information for the address in [DISTRICT]."}],
)
print(response.choices[0].message.content)
print(response.usage)  # token and cost breakdown

For contractors serving the public sector there is also a partner program: in a separate partner portal you open a distinct project and API key for each institutional client, usage is reported per institution, you set your own margin, and client consumption is deducted from your partner balance — clarifying expense separation and progress-payment documentation in multi-institution projects. Apply at /partner/apply. For administrations looking for a trust signal, there is a verifiable reference as well: Onysoft is a member of the Anthropic Claude Partner Network.

Pilot Project Roadmap: Start Small, Measure, Scale

The right pilot starts with a narrow scenario containing no personal data and produces measurements at every stage. Our recommended four phases:

1. Scenario selection (week 1): Pick a task from the "no personal data risk" class — a legislation/circular assistant or technical specification summarization is ideal. Limit the scope to a single unit.
2. No-code validation (weeks 1-2): Run 20-30 sample prompts with real documents in the Playground; have the staff who do the work score the output quality. This phase requires no software development.
3. Limited live pilot (weeks 3-6): Open the integration with a single token-limited key and a small lira balance. Thanks to the balance pre-check, the pilot's budget is technically capped.
4. Measurement and scaling decision: Prepare the rollout file with request counts, costs, and staff feedback from the usage report.

Calibrate speed expectations with real data — the values below are production traffic measurements, not estimates:

Metric	Value
Successful requests (last 14 days)	6,959
Average end-to-end response time	3.8 s
Fastest response	0.3 s

Measured: August 5, 2026 — api.onysoft.com live catalog.

What pulls the average up is long-generation flagship-class requests; for pilot tasks such as classification and summarization, speed-class models drop below a second. Indeed, all three of the most-called models in the last 30 days are from the speed class — most public sector pilots do not require a flagship model. For the broader model selection framework, the AI API guide is a good next stop; the 24/7 Turkish-language support team is available for questions.

Last updated: August 5, 2026 · Data: api.onysoft.com live catalog