Process First, Then Technology: Language Models in Government—Research and a Point of View

Disclaimer: This document is research and a point of view. It is entirely that of the writer and has no affiliation with any organisation—private, public, or institutional. The objective is to spread awareness about AI and its implications, not to promote bias or any particular interest. Readers are encouraged to verify facts and form their own conclusions.

Document purpose: Research and POV on SLMs in government contexts—definition, use, fine-tuning, adverse effects, bias, data, governance, state-level divergence, adversarial risks, and the gap between AI hype and production-ready, governed systems.

Critical thread: Do governments really need SLMs, or should they prioritise process design and documentation reduction first? What is the desired outcome—reducing effort or improving processes? And when governments use disclaimers ("please verify"), where do citizens actually go to verify?

1. Process Redesign and Reimagination Before AI and SLM

Before considering AI, SLMs, or any new technology, governments should redesign and reimagine the underlying processes and the role of documentation. This section sets that foundation. Technology—including SLMs—should support a reimagined process, not compensate for a broken one.

1.1 Why Process and Reimagination Come First

• The wrong sequence: "We have too many documents and confused citizens; let's add an AI chatbot." That automates access to the same mess. The right sequence is: reimagine the outcome → redesign the process → rationalise documentation → then decide what (if any) technology is needed.
• Reimagination means asking: What should a citizen or frontline worker experience? What should "success" look like (e.g. one visit, one application, one source of truth)? What can we stop doing or merge so that fewer steps and fewer documents are needed?
• Process redesign means changing how work flows: single window instead of multiple offices; clear eligibility rules and checklists; fewer forms and approvals; defined timelines and accountability. Without this, adding AI often speeds up the wrong thing or hides complexity that should have been removed.

1.2 Defining Outcomes from the Citizen’s and System’s Perspective

• Citizen outcome: e.g. "I can find out which schemes I am eligible for, and apply, without visiting five offices or reading fifty circulars." Or: "I get a clear, timely, verifiable answer to my grievance."
• System outcome: e.g. "Every scheme has one authoritative description, one eligibility definition, and one process; circulars are consolidated, versioned, and retired when superseded." Or: "Frontline workers have a single place to look, and citizens have a single place to verify."
• Outcomes should be specific and measurable. "Better service" is not enough. "Reduce visits from three to one" or "Answer eligibility within one working day with a cited source" are. Only when outcomes are clear can we judge whether a process redesign is sufficient or whether technology (including AI) is justified.

1.3 Process Redesign: Principles and Levers

• Simplify the journey: Map the current citizen or worker journey; identify redundant steps, unnecessary documents, and unclear handoffs. Redesign to the minimum necessary steps.
• Single window / one-stop: Where possible, one entry point (physical or digital) for a class of services, with clear routing inside the system—not multiple offices each with partial information.
• Clear eligibility and rules: Eligibility criteria in plain language, machine- and human-readable; decision trees or checklists that can be used without an AI. If a human can't determine eligibility from the rules, an AI trained on the same rules won't do it reliably either.
• Fewer, better documents: Consolidate circulars and schemes; one source of truth per policy area; version control and sunset dates. Retire obsolete documents instead of adding to the pile.
• Accountability and redress: Defined owners for each process; published timelines; clear grievance and appeal paths. Reimagined processes should make it obvious where to go when something goes wrong.

1.4 Documentation Discipline and Reimagination

• What should exist: Only what is needed for the reimagined process. Not "every circular we ever issued" but "current, consolidated guidance" with a clear update and retirement policy.
• How it should be maintained: Owned roles, review cycles, plain language, and (where possible) structured data (e.g. scheme name, eligibility, link, last updated). Documentation that is findable, readable, and trustworthy before any AI touches it.
• Reimagination of content: Ask not only "do we have documents?" but "do we have the right documents?" Often the reimagination reveals that much existing content is redundant, outdated, or contradictory—and should be fixed or removed rather than indexed by an AI.

1.5 When the Process Is Ready to Consider Technology

• After outcomes are defined, process redesigned, and documentation rationalised, the question becomes: What technology best supports this process?
• Layered choices:Structured informationSearchable knowledge base.Filters by scheme, department, date.Curated FAQ and decision treesFor the most common queries.Simple automationForms, workflows, notifications.Only then, if a well-defined gap remains, consider AI or SLM as one possible tool.Example gap: highly varied natural-language queries over a large but now-orderly corpus.Must be accompanied by: governance, assurance, and clear scope.
• Test: If a well-trained human cannot give a good answer using the current process and documents, an AI trained on the same will not magically fix it. Process and documentation first; technology to support, not substitute for, a broken foundation.

1.6 Summary: The Sequence Before AI and SLM

Governments should treat Process Redesign and Reimagination as Section 1—the foundation. The following sections on SLMs, fine-tuning, and risks apply when and only when this foundation is in place (or is being built in parallel, with AI in a supporting role, not leading it).

2. What Are Small Language Models (SLMs)?

Definition: Small Language Models are AI models that process and generate human language with far fewer parameters than Large Language Models (LLMs). SLMs typically range from a few thousand to a few hundred million parameters; LLMs run from hundreds of billions to trillions. Despite size, SLMs can perform text generation, summarisation, translation, and sentiment analysis.

How they work: Same transformer architecture as LLMs, with efficiency gained through:

• Knowledge distillation (smaller models learning from larger ones)
• Pruning (removing less critical parameters)
• Lower precision (e.g. quantisation) and reduced parameter counts

Recent developments (2024–2025): Capability is increasingly decoupled from scale—e.g. reinforcement learning with verifiable rewards, Mixture-of-Experts architectures, and frameworks combining large “planner” models with smaller “follower” models at much lower cost. SLMs can offer 1,000–10,000× lower inference cost than top reasoning LLMs.

Implication for government: SLMs are attractive for on-prem, single-GPU or limited-infrastructure deployment. The risk is assuming that “small and cheap” implies “safe, explainable, and fit for high-stakes public-sector use.”

3. Government Use of SLMs and Fine-Tuning

3.1 Government Use of AI: Landscape and Opportunity

Why government use of AI matters: Governments deliver services that affect every citizen—benefits, health, education, justice, regulation, and day-to-day administration. AI, used well, can improve access (e.g. 24/7 information, multilingual support), consistency (same rules applied across offices and regions), speed (faster eligibility checks, document handling), and transparency (cited sources, audit trails). It can also free frontline and back-office staff for higher-value or human-sensitive tasks. The goal is better outcomes for citizens and the system—not technology for its own sake.

Domains of government AI usage:

• Citizen-facing services: Scheme discovery, eligibility guidance, application support, grievance status, and plain-language answers to policy questions. Used well, this extends reach and reduces unnecessary visits and calls; used poorly, it can mislead or exclude.
• Frontline worker support: Decision support for counter staff, call centres, and field workers—lookup, drafting, suggested next steps—with the worker remaining accountable to the citizen.
• Back office and operations: Document classification and extraction, summarisation, fraud and anomaly detection, audit support, and workflow automation. These can cut cost and error when built on clear process and data.
• Policy and compliance: Analysis of consultations, regulatory monitoring, and risk assessment. AI can help sift large volumes; human judgment and governance must remain central.

What “good” government AI looks like:

• Outcome-led: Tied to specific, measurable goals (e.g. “reduce time to first response,” “one source of truth per scheme”) that are defined before technology choices.
• Process-anchored: Supports a process that has been redesigned and documented; does not compensate for broken or opaque workflows.
• Governed: Clear ownership, audit, and redress; alignment with data protection and equality law; no PII in training or prompts without legal basis and safeguards.
• Transparent and verifiable: Where citizens or workers get an answer, there is a path to verify (cited document, link, or office); “please verify” is backed by a real verification path.
• Assured: Tested for bias, drift, and adversarial behaviour; monitored in production; scope and limitations published.

Blending this with the rest of the POV: The sections that follow (current adoption, fine-tuning, need for SLMs, risks, and frontline use) apply within this landscape. Government use of AI—including SLMs—is most valuable when it sits in this frame: process first, outcome clarity, governance, and assurance. The following subsections detail how SLMs and fine-tuning fit (or do not fit) that picture.

3.2 Current Adoption

• Federal level: In some jurisdictions, use cases have grown sharply (e.g. roughly ninefold over a year) across selected agencies. Agencies responsible for security, veterans’ affairs, and health use GenAI for investigations, training, medical imaging, and outbreak detection.
• SLMs (7B–14B parameters) are deployed on agency-owned servers for secure, on-prem processing—no need for public cloud for inference.
• Use cases: Fraud detection and audit (plain-language queries on audit logs), document analysis, topic modelling, policy consultation, citizen-facing chatbots.

3.3 Why Governments Fine-Tune

• Sovereignty and control: Data stays in-house; no dependency on commercial API terms.
• Domain fit: Policies, schemes, circulars, and state-specific services are not well represented in general-purpose models.
• Language and context: Local language, legal terminology, and administrative jargon require custom data.

Critical point: Fine-tuning is not just technical—it is a policy choice that embeds “what we want the system to say” and “what data we consider authoritative.” That makes it a governance and accountability issue, not only an engineering one.

3.4 Do Governments Really Need SLMs? Use Cases, Alternatives, and Process-First Thinking

Before investing in SLMs, governments should ask: What problem are we solving? Is an AI chatbot the right solution—or are we papering over broken processes and document overload?

3.4.1 Do Governments Really Need SLMs—or Are There Better Alternatives?

• Alternatives to SLMs often exist and may be cheaper, more transparent, and easier to govern:
• Documentation reduction and simplificationIf the real problem is "citizens and frontline workers cannot find or understand the rules," the fix may be fewer, clearer documents—not a chatbot that summarises the same messy corpus.Levers: plain language, single source of truth, version control.
• Process redesign Lengthy approvals, redundant steps, and opaque eligibility criteria create confusion. Simplifying the process (e.g. single-window, clear checklists, fewer forms) can reduce queries and errors more than layering an AI on top of the same complexity.
• Structured information and search A well-maintained FAQ, a proper searchable knowledge base with filters (scheme, department, date), or a decision tree can answer many "which scheme do I qualify for?" questions without a language model.These are interpretable, auditable, and easier to update.
• Human capacity and training Sometimes the bottleneck is too few trained staff or high turnover.Investing in recruitment, training, and retention may improve outcomes more than deploying an SLM that workers may not trust or use correctly.
• When might SLMs still add value? When the corpus is large and genuinely unstructured, when queries are highly varied and natural-language search helps, and when the organisation has already simplified processes and documents and still has a well-defined gap. Even then, the bar should be high: need, not fashion.

3.4.2 What Use Cases Are Governments Actually Trying to Solve?

• Stated use cases (scheme discovery, policy Q&A, citizen chatbots, frontline decision support) often mask a deeper issue: too many policies, too many documents, too little structure. The question is not only "are frontline jobs so difficult that they need chatbots?" but "why are they so difficult?"If the answer is "because we have hundreds of circulars, no single source of truth, and policies that change without clear communication," then the first intervention should be documentation reduction, consolidation, and process clarity—not an AI that tries to navigate the same chaos.
• Are government policies and processes changing to be more nimble and less document-heavy? In many places, no. New schemes and circulars keep getting added; old ones are rarely retired. The result is a growing corpus that becomes harder for humans and machines alike. An SLM trained on this corpus will reflect and sometimes amplify the mess. Governments should ask: Are we committed to making policies and processes more nimble and documents fewer and clearer? If not, layering an SLM on top of the current state may lock in complexity and opacity rather than reduce it.

3.4.3 What Is the Final Outcome: Reducing Human Effort or Improving Processes?

• Two different goals are often conflated:
• Reducing human effort "Frontline workers spend too much time searching; let's give them an AI so they can answer faster." This can lead to automation of the wrong thing—workers get a tool that speeds up lookup but does not fix wrong or outdated information, so they deliver wrong answers faster. Improving processes"Citizens and workers should get correct, timely, consistent answers; processes should be simple and transparent." This requires process design, document discipline, and accountability—of which technology (including AI) may be one part, but not the first.
• Process design first, not AI first: The right sequence is:Define the outcomee.g. "every eligible citizen can find and apply for the right scheme without visiting five offices."Design or redesign the processSingle window, clear eligibility rules, fewer documents.Simplify and maintain the documentationOne source of truth, plain language, version control.Only then ask whether automation or AI (search, FAQ, decision tree, or—if justified—SLM) can support that process.Starting with "we need an AI chatbot" skips (1)–(3) and risks automating confusion.
• ConclusionGovernments should look at process design first and treat AI as a possible enabler of a well-defined process, not as the default solution to "we have too many documents and too much complexity."

3.4.4 Summary: Need, Use Cases, and Outcome

• Do governments really need SLMs? Not by default. They need clear outcomes, simpler processes, and better documentation first. SLMs may have a role after that, for specific use cases where natural-language understanding over a large corpus adds value and can be governed.
• What use cases? Be explicit. If the use case is "help citizens find schemes," ask whether a curated FAQ, search, or decision tree would suffice. If the use case is "help frontline workers answer faster," ask whether the real fix is fewer documents, better training, or more staff—and only then whether an SLM is justified.
• Final outcome: Aim for improved processes and citizen experience, not just reduced human effort. Process design first; AI solution only when it clearly serves that design.

4. Adverse Effects, Bias, Readiness, and Data

4.1 Adverse Effects and Bias

• Catastrophic forgetting: Fine-tuning LLMs on domain-specific tasks causes loss or overwriting of pretrained knowledge. The model can “forget” general reasoning and safety behaviours.
• Biased forgetting: Forgetting is not uniform. Safety tuning and information about certain groups can be forgotten more than other knowledge—systematically skewing outputs.
• Political and ideological bias: Research shows that data selection and parameter-efficient fine-tuning can systematically embed political/ideological bias into large and mid-size open models. For a government, “we fine-tuned on our policies” can easily become “our assistant always defends our policies.”
• Civil rights and discrimination: Advisory and oversight bodies in several jurisdictions stress that AI systems processing citizen data can create or worsen privacy and discrimination risks. Agencies are required to assess differential impact on demographic groups—but implementation is often weak.

4.2 If Every State Fine-Tunes Its Own SLM: The Future of Policies, Sectors, and States

• Data divergence: Each state has different administrative data, schemes, circulars, and language mix. The “State X” SLM is trained on State X data; the “State Y” SLM on State Y data. No shared ground truth across states.
• Policy and narrative divergence: State A’s model may reflect State A’s political and administrative narrative; State B’s, another. Citizens moving or dealing with multiple states get inconsistent answers from “official” assistants.
• Bias amplification: State-level data can encode historical inequities (e.g. who got services, who was surveyed). Fine-tuning on such data can bake in and amplify those inequities.
• Adversarial and geopolitical risk: Competing state-level models can be exploited to spread disinformation, deepen polarisation, or create “official” narratives that conflict with each other or with central policy. Adversaries can target weak or poorly guarded SLM deployments (Jamtara-style social engineering at scale).

Conclusion: A future where every state runs its own fine-tuned SLM without strong central governance and common standards is a future of fragmented, inconsistent, and easily weaponised “official” AI.

5. Social Engineering More Than Transparency

• Transparency is often promised: “We use only government content,” “We tell the AI to ignore training data.” But social engineering targets the user and the system together: jailbreaking, prompt injection, RAG poisoning, and denial-of-resource attacks.
• Jailbreaking: Deliberately manipulating chatbots to produce inappropriate or harmful content. Public government chatbot pilots have acknowledged this risk despite safeguards. It is a cognitive and generative attack, not only a technical one.
• Indirect prompt injection: Malicious content in documents or web pages that the model retrieves can steer behaviour without the user typing anything obviously malicious. This is often cited as one of the biggest security flaws in GenAI.
• Implication: A “transparent” design (e.g. RAG over official docs) does not remove the risk. Assurance must include adversarial testing and continuous monitoring, not only disclosure.

6. SLMs as Black Box: Will Government Use PII for Fine-Tuning?

• Reality: Governments hold financial information, company information, personal information, and health information. The temptation to “improve” citizen-facing or internal models by fine-tuning on real citizen data is high. Doing so without strict legal and technical guardrails creates:Privacy violations (e.g. under national data protection or privacy laws).Re-identification and inference risks even from “anonymised” or aggregated data.Lack of explainability: If the model is a black box and trained on PII, why it said what it said cannot be meaningfully explained to the citizen or the court.
• Guidance exists but implementation lags: Advisory committees, privacy regulators, and agency policies in several jurisdictions say: assess differential impact, limit use of personal data in training, ensure transparency and accountability. In practice, studies have found that only a minority of formal AI governance requirements were verified as implemented; many agencies lack clear public inventories of AI use.
• Answer: The question “will they use PII?” is not only technical—it is governance and enforcement. Without strong data governance, access controls, and independent oversight, the default drift is toward using whatever data is available. Assuming “government will not use PII” is unsafe.

7. Each State Is Different: Data, SLMs, and Central Governance

• Data: State A has different schemes, language mix, and digitisation levels than State B. So State A’s training set ≠ State B’s. The resulting SLMs will differ not only in “personality” (e.g. “I am the public assistant for State X”) but in factual coverage and bias.
• Central government’s role: In some jurisdictions, the centre has set a techno-legal governance framework (e.g. no standalone AI law; law-plus with sectoral regulators). Sectoral regulators (e.g. for finance, securities, telecoms) enforce within their mandate. An inter-ministerial or cross-government body may coordinate. But state-level SLM development and data use are not always clearly within a single regulator’s remit. So: who governs the “State X” SLM? Often it is unclear; it falls between centre (policy) and state (implementation).
• Risk: Proliferation of state-level SLMs with no common standards, no mandatory adversarial testing, and no central register of training data and model cards. That is a governance gap, not just a technical one.

8. Controls, Infrastructure, and Expertise: Consulting vs In-House

• Controls in place: Vary by country and level. Some have algorithmic transparency records, risk assessments, and procurement rules. Many are reactive and under-resourced.
• Infrastructure and expertise: Over half of AI tools in some federal contexts are purchased from commercial vendors; state and local levels often have minimal in-house AI capacity. Governments rely heavily on big consulting and tech firms for design, integration, and sometimes operation. That creates:Vendor lock-in and cost.Conflicts of interest (vendor’s goal is sell more, not necessarily minimise risk).Erosion of institutional knowledge—when the contract ends, the state may not know how the system really works.
• Reality check: Many agencies lack the deep engineering and governance expertise to critically evaluate SLM pipelines, training data, and adversarial robustness. “We have an AI chatbot” is not the same as “we have a production-grade, governed, adversarially tested system.”

9. General-Purpose vs Government-Created Models

• General-purpose models from large commercial and open-source providers are trained on broad, diverse (and often geographically and linguistically uneven) data. They are not “for” any single government or state.
• Government-created (fine-tuned) SLMs are purpose-built: e.g. “Public assistant for State X.” That raises: Base-model bias: Many popular base models were trained largely on open-source data from a few large regions and languages. They “know” more about that context than about State X’s recent policies. Fine-tuning on State X data can partially override this but also cause catastrophic or biased forgetting. So the model may still reflect those original patterns while claiming to be “State X’s” assistant. Recency and coverage: “What policies changed in the last 3 years?” requires 3 years of structured, machine-readable policy data. Many states do not have that. So even with the best intentions, the SLM cannot answer accurately—it will hallucinate or default to base-model knowledge.Political sensitivity: Should the model “care” whether a policy was under one ruling party or another (or any other political framing)? If fine-tuned only on “recent” or “current” data, it may avoid or distort historical comparison. If fine-tuned on long-term data, it may encode political bias. There is no neutral design—only explicit choices.

10. Can Government SLMs Critically Analyse Their Own Policies?

• The question: Even if a government wants its SLM to surface negatives or biased opinions about its own policies, how would it do so?Training data is usually what the government publishes—tenders, schemes, circulars, press releases. That is inherently positive or neutral framing. Little “negative” or “critical” official text exists to train on.Surveys and consultations can be used to add “citizen voice,” but survey data for LLMs is problematic: models show ordering/label biases and, when corrected, often trend toward uniformly random responses. So “we will survey and get data” does not automatically mean good-quality, balanced data for training.
• What is “good” data? Research (e.g. QuRating) stresses quality dimensions: writing style, expertise, facts, educational value—and diversity. For fairness, datasets underlying benchmarks are often underexamined; biases in datasets distort conclusions. So “good” must be defined: representative, non-discriminatory, temporally and geographically appropriate, and not selected to engineer a desired narrative. Many government bodies are not equipped to define or enforce this.
• Conclusion: A government SLM that is honestly critical of its own policies would require curated inclusion of dissenting and negative sources—and strong governance so that inclusion is not merely performative. Today, that is the exception, not the norm.

10. Fine-Tuning a Base Model for “State X”: Practical Paradoxes

• Identity: The model may say “I am the public assistant for State X” but its base knowledge is still the original model’s—skewed toward the regions and languages it was pretrained on. So it can overclaim local expertise.
• Temporal and policy coverage: “What changed in the last 3 years?” needs 3 years of policy data. If the state does not have it in a usable form, the model will guess or hallucinate.
• Recent-only fine-tuning? If we fine-tune only on “recent” data, we avoid some political sensitivity but lose historical context and may increase forgetting of base-model safety. So we trade one risk for another.
• Exposing as a citizen chat assistant: That implies public interface, so jailbreaking, prompt injection, and reputational risk. Without robust adversarial testing and monitoring, exposing such an SLM to all citizens is high risk. The question “where should we use it?” should be answered after assurance (internal use, limited pilot, then scaled exposure—not the reverse).

12. Scenarios and Jamtara-Style Risks

• Jamtara symbolises social engineering and fraud at scale. SLM-based government systems are new attack surfaces: Prompt injection to extract training data, change behaviour, or trigger harmful outputs. Indirect injection via poisoned documents in RAG. Impersonation: “Official”-looking chatbots that are cloned or compromised to phish or mislead. Denial of wallet / resource exhaustion to disrupt service.
• Multi-step attacks (e.g. “promptware kill chain”): initial access → privilege escalation (jailbreak) → persistence (memory/RAG poisoning) → lateral movement → data theft or ecosystem contamination. Government SLMs connected to internal or citizen data are high-value targets.

13. Benchmarks: Adversarial Testing, Consciousness, and Negative Manipulation

• Adversarial testing: National and international standards bodies have published taxonomies for adversarial ML (evasion, poisoning, etc.). For LLMs/SLMs, benchmarks exist but are not uniformly applied to government deployments:Jailbreak and robustness benchmarks: Standardised benchmarks for jailbreak robustness; leaderboards for attack/defence across models.
• Quantisation-specific risks: Research shows models can be crafted to be benign at full precision but malicious after quantisation—so models on public repositories (or government deployments using quantised SLMs) can be backdoored.
• There is no universal “adversarial certificate” for every quantised SLM.Evaluation frameworks: Some frameworks evaluate small LLMs (including quantised and fine-tuned) for security and QA—showing that quantisation + fine-tuning can be tuned for robustness, but it is not default.
• Consciousness and “negative manipulation”:Consciousness is not a standard benchmark; it is philosophically and scientifically contested. No widely accepted benchmark measures “consciousness” in SLMs.
• Negative manipulation / impersonation are partly addressed by jailbreak and misuse benchmarks (e.g. JBB-Behaviors), but government-specific benchmarks (e.g. “does not endorse only one political party,” “does not leak PII”) are not standard.
• So: benchmarks for adversarial testing exist in research; benchmarks for government SLM policy compliance, bias, and impersonation are ad hoc or missing.

14. Point of View: Hype vs Patience, Investment, Governance, Education

• AI hype suggests that with “open source models,” “quantisation,” and “fine-tuning” we can quickly roll out state-level or agency-level SLMs.
• Reality is different: Patience: Robust data curation, evaluation, and adversarial testing take time. Rushing to “launch the chatbot” undermines safety and fairness.
• Investment: Production-grade systems need infrastructure, talent, and ongoing assurance—not one-off consulting projects. That requires sustained budget and hiring.
• Policies: Clear rules on data (especially PII), training data provenance, model cards, and human oversight. Many jurisdictions are still catching up.
• Governance: Who is accountable for the “State X” SLM? Who audits it? Who can citizens appeal to? Central–state coordination and sectoral regulator roles must be explicit.
• Education: Opening schools and technical institutes is necessary but not sufficient. Production-grade systems require deep engineering, security, and governance expertise—not just “we use a public model repository and a quantised model.”
• Open-source and quantised models are ingredients, not a full solution. Quantised models from various providers on public repositories are not, by default, adversarially tested or policy-compliant. Deploying them as “government AI” without ownership of the full pipeline (data, training, evaluation, deployment, monitoring) is risky.

Summary: SLMs can offer cost and control benefits for government, but only as part of a larger equation: patience, investment, policies, governance, and education. Without that, SLM adoption will amplify bias, fragment narratives, and create new attack surfaces—social engineering more than transparency, and black boxes trained on data the government holds (including PII risks), with no clear answer to “who governs state-level SLMs?” or “can this system critically analyse our own policies?” The future of government AI must be deliberate and governed, not driven by hype alone.

15. Where Should Government Use SLMs? (Synthesis)

• Use with strong guardrails: Internal document search, summarisation, audit support, non-public decision support—with clear boundaries, no PII in training without legal basis, and human-in-the-loop. Frontline-worker decision support (see §16) fits here when designed with clear accountability and training.
• Use with caution: Limited citizen-facing pilots (e.g. scheme discovery) with strict scope, monitoring, and adversarial testing. Transparent disclosure of limitations.
• Avoid until assurance exists: Broad public “official” chatbots that promise policy advice or personal outcomes; any use of PII in fine-tuning without robust legal and technical safeguards; state-level proliferation without central governance and common standards.

16. Frontline Workers Using SLMs to Solve Citizen Problems

Context: Frontline workers—counter staff, call-centre agents, field officers, scheme facilitators, grievance officers—are the human face of government. They answer citizen queries, process applications, and resolve complaints. SLMs can be used as a decision-support tool for these workers: the worker uses the SLM to look up schemes, check eligibility, draft responses, or get suggested next steps, then delivers the answer to the citizen. The citizen interacts with the worker, not directly with the model.

16.1 Why This Use Case Matters

• Volume and complexity: Schemes, circulars, and policies change often; no single worker can retain everything. An SLM with RAG over official documents can surface the right excerpt or summary in seconds.
• Consistency and quality: Same question in different offices or shifts can get different answers. A shared SLM (with cited sources) can reduce inconsistency while leaving the worker to interpret and communicate.
• Scale: Workers can resolve more cases per day if they spend less time searching manuals and more time talking to the citizen—provided the tool is reliable and workers are trained to verify.

16.2 How It Differs from Direct Citizen-Facing Chatbots

Implication: Frontline use is a stronger candidate for SLM deployment than open public chatbots, because the human-in-the-loop reduces direct adversarial exposure and keeps accountability with the government employee. It does not remove risks—it shifts them (see below).

16.3 Benefits When Done Right

• Faster resolution: Lookup and summarisation in seconds instead of minutes of manual search.
• Better coverage: RAG over a large document set (schemes, circulars, FAQs) that would be hard to memorise.
• Language and drafting: Model can suggest wording or translations; worker adapts for the citizen.
• Audit trail: Queries and retrieved sources can be logged for quality and dispute resolution (with appropriate privacy controls).

16.4 Risks and Pitfalls

• Over-reliance: Workers may treat the SLM as authoritative and copy-paste answers without checking. If the model hallucinates or the source is outdated, the citizen gets wrong information—and the department is liable, not the model.
• Bias in suggestions: The model may surface certain schemes or options more often (e.g. due to training or retrieval bias). Workers who do not double-check can propagate that bias to citizens.
• Deskilling: Long-term reliance on “ask the AI” can erode workers’ own knowledge and judgment, making the system indispensable and workers less able to operate when the tool fails or is unavailable.
• PII in prompts: If workers paste citizen names, IDs, or case details into the SLM to “get a better answer,” that data may be logged, processed, or leaked. PII must not enter the SLM unless the system is designed for it (e.g. secure, compliant, access-controlled) and workers are trained not to paste unnecessary PII.
• Liability and redress: When the worker gives wrong information that originated from the SLM, the citizen’s recourse is against the department. Clear internal policy is needed: workers must verify high-stakes answers; escalation paths when the model says “I don’t know” or the worker is unsure.

16.5 Design Principles for Frontline SLM Use

1. Decision support, not decision replacement: The SLM suggests; the worker decides and communicates. UI and training should reinforce “use this to help you, not to replace your judgment.”
2. Cite sources: Every answer or suggestion should point to the document/section it came from (RAG with source attribution). Workers and citizens can then verify.
3. Training and guardrails: Workers need training on when to trust the tool, when to verify, and when to escalate. Guardrails: no PII in free-text prompts unless the system is explicitly designed and approved for it.
4. Secure channel and access control: Only authorised frontline staff; no public access to the same interface. Reduces jailbreak and abuse.
5. Audit and monitoring: Log queries (with PII stripped or minimised) and sample outcomes for quality and bias. Use to improve retrieval and catch systematic errors.
6. Escalation and “I don’t know”: The model should clearly indicate uncertainty. Workers must have a path to escalate when the answer is missing, ambiguous, or sensitive (e.g. eligibility, entitlements).

16.6 Where This Fits in the “Where to Use” Framework

• Use with strong guardrails: Frontline-worker decision support fits under “use with strong guardrails” provided:
• Without these conditions, frontline use can degenerate into opaque, unverified advice that looks official but is wrong—and the citizen has no way to know the answer came from an SLM the worker did not verify. So: frontline use is a good target for SLMs, but only with the right governance, training, and design.

16.7 The Disclaimer Trap: Who Reads It, and Where Do Citizens Go to Verify?

• The disclaimer in practice: Many systems show a line such as: "Main AI huin … mere responses galat ho sakte hain … kripya confirm karein aur apni research khud karen." (I am an AI … my responses may be wrong … please confirm and do your own research.) The intent is to shift responsibility and set expectations. The reality is different.Will frontline workers read it? Often no. Workers are under time pressure; they may skim, ignore, or forget. If the tool is fast and "usually right," the disclaimer becomes wallpaper. The worker may not confirm with the source document before answering the citizen—so the citizen gets an answer that looks official but is unverified.Will citizens see it? In a frontline scenario, the citizen does not see the AI at all. They see the worker. So the disclaimer, if it exists, is on the worker’s screen—not the citizen’s. The citizen has no idea the answer was partly or wholly generated by an AI. They have no reason to "confirm" or "do their own research" unless the worker explicitly says so—and even then, where do they go?
• Where do they go back and check? This is the verification dead-end. The disclaimer says "please confirm and do your own research." But:Where does the citizen confirm? Which document? Which office? Which website? If the government has not provided a clear, accessible path to the source (e.g. "this answer is from Circular XYZ, dated …, link: …"), the citizen cannot verify. They are left to: ask a friend, go back to the same or another office, search the web, or give up. That is not "empowering" the citizen—it is dumping the burden of verification on them without giving them the means.Asking a friend is not verification; it is hearsay. Going back to the office may mean another long queue, another worker who may also use the same AI, and no guarantee of a document or a written answer. Searching for the document assumes the document is online, findable, and in a language and format the citizen can use—often false in practice.
• Critical point: A disclaimer that says "we might be wrong, please verify" without providing where and how to verify is not transparency. It is liability shifting. It does not improve process or citizen experience; it leaves the citizen with an answer they cannot trust and no clear path to make it right. Governments that deploy AI-assisted frontline responses must either: (1) provide a clear verification path (cited document, link, office, or grievance channel), or (2) accept that the answer is official and therefore the government is accountable—not the citizen’s "own research."