Artificial intelligence has already become a working tool inside small local governments, often without the policies, training, procurement decisions, or security controls that should accompany it. That is the central warning from a new Pennsylvania-focused survey of municipal employees: AI did not wait for a formal public-sector rollout. It arrived through browsers, office suites, meeting rooms, and individual staff decisions—well before many boroughs and townships had decided how, or whether, to govern its use.
For Windows users and IT administrators, the finding should sound familiar. Generative AI adoption rarely begins with a carefully staged technology program. It begins when an employee uses a chatbot to polish a letter, summarize a lengthy document, turn rough meeting notes into minutes, or make sense of an unwieldy spreadsheet. In a small municipal office, those seemingly ordinary productivity tasks can involve resident records, personnel matters, procurement information, public safety details, or documents subject to public-records laws.
The issue is not that local governments are adopting AI. In many cases, the practical uses are reasonable, low-risk, and potentially valuable. The issue is that everyday use is outpacing institutional readiness, particularly in governments that may have only a few full-time employees responsible for finance, administration, public communications, records, payroll, technology, and compliance.
That mismatch matters because the smallest governments are not a niche edge case. They are where residents encounter government most directly: when applying for a permit, requesting a public record, calling a police department, attending a council meeting, paying a utility bill, or reporting a pothole. If AI becomes embedded in those workflows without clear rules, the consequences will not remain theoretical. They will appear as privacy failures, inaccurate public communications, unequal treatment, avoidable legal exposure, and diminished trust.
The survey at the center of this discussion drew responses from 35 local-government employees in Pennsylvania, largely senior personnel from boroughs and townships serving populations between 5,000 and 20,000. It is a small, self-selected sample and should not be presented as a national measurement of municipal AI adoption.
Still, its value is significant. Small local governments are difficult to study, yet they make up much of the country’s public-sector landscape. Their staffing model, budget constraints, and technology capacity differ sharply from those of state agencies, counties, and large cities that dominate most discussions about government AI.
The reported pattern is straightforward:
That gap is especially visible with generative AI because the barrier to entry is so low. A municipal employee does not need a capital project, a new server room, a long procurement cycle, or a formal IT implementation to start using a web-based AI assistant. They only need a browser, an account, and a task that feels too time-consuming.
In the traditional public-sector technology model, an organization procures software, configures it, assigns user permissions, trains staff, creates procedures, and gradually integrates it into workflows. Generative AI has inverted that sequence. Staff may begin using it first. Leadership may notice later. Governance may arrive only after a problem occurs.
The difference is not merely one of scale. It changes what responsible AI adoption can realistically look like.
Drafting a public announcement from already-approved text is not the same as asking an AI tool to summarize a resident complaint file. Improving grammar in a nonconfidential newsletter is not the same as uploading a personnel document, an investigative report, a legal memo, or procurement materials before a contract award.
The phrase “using AI for work” therefore hides an essential governance question: what data is being used, in which tool, by whom, under what controls, and for what decision?
Without a policy, employees may reasonably assume that a task is harmless because the output is only a draft. But the input may still be sensitive. The draft may still be wrong. And the interaction may still create records, retention obligations, or disclosure risks.
A personal AI account generally sits outside the organization’s usual identity, auditing, retention, access-control, and procurement structure. The municipality may not know what information was entered, who can access the account, whether multifactor authentication is enabled, how account recovery works, or what contractual data protections apply.
That does not mean every consumer AI tool is inherently unsafe. It means that the security and governance model cannot be assumed. Free and personal services can have different data terms, administrative capabilities, logging behavior, data-retention controls, model-training arrangements, and support commitments than an approved enterprise deployment.
This distinction is particularly important for municipalities using Microsoft environments. A properly configured Microsoft 365 Copilot deployment can operate within an organization’s existing Microsoft 365 identity, permissions, sensitivity labels, compliance controls, and audit capabilities. It can also preserve the fundamental rule that users should not gain access to organizational content they were not already authorized to see.
But those protections are not automatic merely because a product bears the Copilot name. Licensing, tenant configuration, web-grounding settings, information-protection rules, retention policies, data-loss-prevention controls, and user training all matter. A local government cannot simply declare that an AI assistant is “secure” and move on.
These are real benefits. Small teams routinely struggle with communications workload, and clearer writing can improve access to government services.
However, staff must distinguish between using AI as an editor and using it as an authority. A polished but inaccurate notice can be more dangerous than an awkward draft. If an AI-generated announcement changes a deadline, misstates a rule, omits an exception, or gives residents incorrect instructions, the result may be operational confusion or unequal access to public services.
The safest model is simple: AI may draft, but an authorized human must verify and approve.
But summarization is not neutral compression. An AI system decides what seems important, what it groups together, what it omits, and how it characterizes uncertainty. That creates risks when staff use summaries of public comments, policy proposals, investigative materials, legal documents, or resident complaints.
A summary can silently erase minority viewpoints. It can flatten disputes into false consensus. It can mistake a conditional statement for a conclusion. It can produce a confident, plausible explanation that the original document does not support.
For public bodies, the operational rule should be that summaries are navigation aids, not official records or final analyses. Staff should retain and consult the original source material, especially when a summary informs a decision, public statement, enforcement activity, or legal position.
Yet public meetings involve unique considerations. Official minutes must meet legal and procedural requirements. A generated summary may miss motions, votes, abstentions, public-comment details, amendments, or the precise language needed to reflect action taken by a governing body.
There are also consent, recording, retention, and accessibility questions. If a vendor processes audio or transcript data, the municipality needs to understand where that information goes, how long it is stored, whether it can be exported, and whether it becomes subject to records-management rules.
The practical approach is not to ban AI meeting assistance outright. It is to treat generated material as staff work product requiring review, not as an official minute-taking replacement.
AI-supported identification, video analysis, biometric matching, license-plate recognition, predictive systems, or automated threat assessments do not belong in the same category as grammar assistance or formatting a public notice. They can affect liberty, privacy, due process, and the relationship between residents and local government.
Small municipalities are particularly vulnerable to a troubling procurement pattern: buying a seemingly turnkey product without the staff capacity to evaluate accuracy claims, test performance across demographic groups, audit vendor practices, manage retention, or establish meaningful human oversight.
Before deploying AI for surveillance, identification, enforcement, or eligibility decisions, a local government should require a much higher standard than it would for office productivity tools. At minimum, it should establish:
That ambiguity is understandable. Municipal leaders are being asked to make decisions about a technology whose capabilities and product names change quickly, while their organizations still face longstanding concerns involving cybersecurity, aging software, public-records compliance, staffing shortages, and budget pressure.
Neutrality, however, is not a durable governance position once staff are already using the tools.
If leaders say nothing, employees may interpret silence in different ways:
The goal should not be a reflexive ban. Blanket prohibitions frequently drive activity underground, where governments have less visibility and fewer safeguards. The better goal is bounded permission: authorize appropriate, low-risk uses; prohibit specific high-risk practices; provide approved tools; and require escalation when the use case exceeds the policy.
A practical policy should answer four questions: what is allowed, what is prohibited, what needs approval, and what must be documented.
That preference should shape how local-government AI programs are built.
Large governance frameworks remain useful. They offer a vocabulary for managing risk, identifying stakeholders, measuring performance, and documenting decisions. The most widely used AI risk-management approaches emphasize four interconnected activities: govern, map, measure, and manage.
For a small municipality, though, those concepts must become concrete:
A two-hour live training session may be more valuable to a township office than a dense 75-page report. A peer demonstration from a similar borough may be more persuasive than a case study from a major city. Staff want to see the actual prompts, review checklists, approved-use examples, and mistakes that their counterparts encountered.
That is not a rejection of policy. It is a demand for policy translated into practice.
That creates a potential advantage. When an organization deploys AI within its existing Microsoft 365 environment, it may be able to apply established identity controls, user permissions, multifactor authentication, retention policies, sensitivity labels, data-loss-prevention rules, eDiscovery processes, and audit capabilities.
But it also creates a responsibility. Copilot can expose long-neglected permission problems. If a SharePoint site is overshared, an AI assistant may make that oversharing easier to discover. If records are stored inconsistently, AI may surface incomplete or conflicting information. If users have access they no longer need, the AI system may operate within those existing permissions rather than correcting them.
That means Copilot readiness is not only about licensing or user training. It is also a data-governance and identity-governance project.
Before broad deployment, small governments should prioritize:
That awareness creates an opportunity. Small governments do not need to be persuaded that AI carries risk; they need help converting that awareness into repeatable practices.
A responsible local AI program should begin modestly:
The Pennsylvania survey is limited in size, but its message is difficult to dismiss. Municipal employees are already using generative AI. Many are doing so without a formal policy, without consistent leadership direction, and sometimes outside approved enterprise environments. The tools have entered the workplace through individual initiative rather than institutional design.
That does not require panic. It requires action.
Small local governments should not wait for a perfect national standard, a major budget increase, or a technology crisis before establishing basic AI governance. A concise acceptable-use policy, approved tools, data-handling rules, practical staff training, peer learning, and meaningful human review can make a substantial difference.
AI has already reached the municipal desk. The next task is ensuring that public-sector accountability reaches it too.
For Windows users and IT administrators, the finding should sound familiar. Generative AI adoption rarely begins with a carefully staged technology program. It begins when an employee uses a chatbot to polish a letter, summarize a lengthy document, turn rough meeting notes into minutes, or make sense of an unwieldy spreadsheet. In a small municipal office, those seemingly ordinary productivity tasks can involve resident records, personnel matters, procurement information, public safety details, or documents subject to public-records laws.
The issue is not that local governments are adopting AI. In many cases, the practical uses are reasonable, low-risk, and potentially valuable. The issue is that everyday use is outpacing institutional readiness, particularly in governments that may have only a few full-time employees responsible for finance, administration, public communications, records, payroll, technology, and compliance.
That mismatch matters because the smallest governments are not a niche edge case. They are where residents encounter government most directly: when applying for a permit, requesting a public record, calling a police department, attending a council meeting, paying a utility bill, or reporting a pothole. If AI becomes embedded in those workflows without clear rules, the consequences will not remain theoretical. They will appear as privacy failures, inaccurate public communications, unequal treatment, avoidable legal exposure, and diminished trust.
Overview: AI Has Reached the Municipal Desk Before the Policy Binder
The survey at the center of this discussion drew responses from 35 local-government employees in Pennsylvania, largely senior personnel from boroughs and townships serving populations between 5,000 and 20,000. It is a small, self-selected sample and should not be presented as a national measurement of municipal AI adoption.Still, its value is significant. Small local governments are difficult to study, yet they make up much of the country’s public-sector landscape. Their staffing model, budget constraints, and technology capacity differ sharply from those of state agencies, counties, and large cities that dominate most discussions about government AI.
The reported pattern is straightforward:
- Two-thirds of respondents said they use generative AI for work at least monthly.
- More than half said their workplace had deployed enterprise AI tools such as Microsoft Copilot.
- More than one-quarter also reported using personal, free AI accounts for work-related tasks.
- A majority said their organization had no generative AI policy.
- More than half of respondents without a policy said such guidance would be valuable.
- Respondents identified staff expertise as the largest barrier to responsible adoption, ahead of budget limitations.
That gap is especially visible with generative AI because the barrier to entry is so low. A municipal employee does not need a capital project, a new server room, a long procurement cycle, or a formal IT implementation to start using a web-based AI assistant. They only need a browser, an account, and a task that feels too time-consuming.
In the traditional public-sector technology model, an organization procures software, configures it, assigns user permissions, trains staff, creates procedures, and gradually integrates it into workflows. Generative AI has inverted that sequence. Staff may begin using it first. Leadership may notice later. Governance may arrive only after a problem occurs.
Why Small Local Governments Face a Different AI Problem
A large city can assign AI governance to a chief information officer, chief data officer, privacy office, procurement team, legal department, cybersecurity unit, and departmental leadership group. A small township may have a manager, a secretary-treasurer, a public works supervisor, part-time elected officials, and outside IT support.The difference is not merely one of scale. It changes what responsible AI adoption can realistically look like.
One Employee, Many Sensitive Responsibilities
In a smaller municipality, a single employee may handle:- Council agendas and meeting packets
- Payroll and benefits paperwork
- Resident complaints
- Permit records
- Grant applications
- Vendor contracts
- Public notices
- Budget documents
- Right-to-know requests
- Human-resources files
- Police or code-enforcement coordination
Drafting a public announcement from already-approved text is not the same as asking an AI tool to summarize a resident complaint file. Improving grammar in a nonconfidential newsletter is not the same as uploading a personnel document, an investigative report, a legal memo, or procurement materials before a contract award.
The phrase “using AI for work” therefore hides an essential governance question: what data is being used, in which tool, by whom, under what controls, and for what decision?
Without a policy, employees may reasonably assume that a task is harmless because the output is only a draft. But the input may still be sensitive. The draft may still be wrong. And the interaction may still create records, retention obligations, or disclosure risks.
The Personal Account Problem
The finding that some municipal employees use personal, free AI accounts for work is among the survey’s most consequential details. It does not prove that confidential information has been exposed, and it should not be treated as evidence of misconduct. However, it does show how easily a government’s information-handling rules can be bypassed by convenience.A personal AI account generally sits outside the organization’s usual identity, auditing, retention, access-control, and procurement structure. The municipality may not know what information was entered, who can access the account, whether multifactor authentication is enabled, how account recovery works, or what contractual data protections apply.
That does not mean every consumer AI tool is inherently unsafe. It means that the security and governance model cannot be assumed. Free and personal services can have different data terms, administrative capabilities, logging behavior, data-retention controls, model-training arrangements, and support commitments than an approved enterprise deployment.
This distinction is particularly important for municipalities using Microsoft environments. A properly configured Microsoft 365 Copilot deployment can operate within an organization’s existing Microsoft 365 identity, permissions, sensitivity labels, compliance controls, and audit capabilities. It can also preserve the fundamental rule that users should not gain access to organizational content they were not already authorized to see.
But those protections are not automatic merely because a product bears the Copilot name. Licensing, tenant configuration, web-grounding settings, information-protection rules, retention policies, data-loss-prevention controls, and user training all matter. A local government cannot simply declare that an AI assistant is “secure” and move on.
The Most Common Uses Are Also the Most Deceptive
The survey suggests that local-government staff are using generative AI primarily for writing, summarization, and meeting notes. These are exactly the tasks most likely to appear benign—and exactly the tasks where careful controls are needed.Writing and Editing
AI can help a municipal office turn a rough outline into a clearer public notice, adjust the tone of a community update, create a plain-language version of an existing document, or propose a first draft of a routine letter.These are real benefits. Small teams routinely struggle with communications workload, and clearer writing can improve access to government services.
However, staff must distinguish between using AI as an editor and using it as an authority. A polished but inaccurate notice can be more dangerous than an awkward draft. If an AI-generated announcement changes a deadline, misstates a rule, omits an exception, or gives residents incorrect instructions, the result may be operational confusion or unequal access to public services.
The safest model is simple: AI may draft, but an authorized human must verify and approve.
Summarization
Summarization may be the most tempting municipal AI use case. Government offices often deal with lengthy reports, meeting packets, regulations, public comments, engineering documents, correspondence, and grant materials. An AI-generated summary can save time, identify themes, or create a useful starting point.But summarization is not neutral compression. An AI system decides what seems important, what it groups together, what it omits, and how it characterizes uncertainty. That creates risks when staff use summaries of public comments, policy proposals, investigative materials, legal documents, or resident complaints.
A summary can silently erase minority viewpoints. It can flatten disputes into false consensus. It can mistake a conditional statement for a conclusion. It can produce a confident, plausible explanation that the original document does not support.
For public bodies, the operational rule should be that summaries are navigation aids, not official records or final analyses. Staff should retain and consult the original source material, especially when a summary informs a decision, public statement, enforcement activity, or legal position.
Meeting Notes and Minutes
Meeting-note generation may offer immediate administrative value, particularly for understaffed governments. Recording a meeting and receiving a draft transcript, action list, or outline of discussion can reduce manual workload and help staff organize follow-up.Yet public meetings involve unique considerations. Official minutes must meet legal and procedural requirements. A generated summary may miss motions, votes, abstentions, public-comment details, amendments, or the precise language needed to reflect action taken by a governing body.
There are also consent, recording, retention, and accessibility questions. If a vendor processes audio or transcript data, the municipality needs to understand where that information goes, how long it is stored, whether it can be exported, and whether it becomes subject to records-management rules.
The practical approach is not to ban AI meeting assistance outright. It is to treat generated material as staff work product requiring review, not as an official minute-taking replacement.
Surveillance and Identification Require a Separate Threshold
Most survey participants described low-risk productivity uses, but a handful referenced surveillance and identification. Even if those uses represent only a small minority of respondents, they deserve disproportionate scrutiny.AI-supported identification, video analysis, biometric matching, license-plate recognition, predictive systems, or automated threat assessments do not belong in the same category as grammar assistance or formatting a public notice. They can affect liberty, privacy, due process, and the relationship between residents and local government.
Small municipalities are particularly vulnerable to a troubling procurement pattern: buying a seemingly turnkey product without the staff capacity to evaluate accuracy claims, test performance across demographic groups, audit vendor practices, manage retention, or establish meaningful human oversight.
Before deploying AI for surveillance, identification, enforcement, or eligibility decisions, a local government should require a much higher standard than it would for office productivity tools. At minimum, it should establish:
- A clearly documented public purpose.
- Legal review and procurement review.
- A data inventory covering what is collected, retained, shared, and deleted.
- Independent validation of performance claims where feasible.
- Human decision-making authority rather than automatic action.
- Complaint, appeal, and correction procedures.
- Public-facing transparency explaining the system’s use and limits.
- A process for suspending or retiring the system if harms emerge.
Why Leadership Is Often Neutral or Unclear
The survey found that only a minority of respondents described leadership as actively encouraging AI exploration. Others saw support without active promotion, while the largest group characterized leadership’s position as neutral or unclear. A small number reported discouragement or conflicting signals.That ambiguity is understandable. Municipal leaders are being asked to make decisions about a technology whose capabilities and product names change quickly, while their organizations still face longstanding concerns involving cybersecurity, aging software, public-records compliance, staffing shortages, and budget pressure.
Neutrality, however, is not a durable governance position once staff are already using the tools.
If leaders say nothing, employees may interpret silence in different ways:
- Some will assume AI use is permitted for routine work.
- Some will avoid useful tools entirely because they fear violating an unstated rule.
- Some will use personal accounts because approved options are unclear.
- Some will rely on AI more heavily than management realizes.
- Some will unknowingly enter information that should never leave a municipal system.
The goal should not be a reflexive ban. Blanket prohibitions frequently drive activity underground, where governments have less visibility and fewer safeguards. The better goal is bounded permission: authorize appropriate, low-risk uses; prohibit specific high-risk practices; provide approved tools; and require escalation when the use case exceeds the policy.
A Practical AI Policy for a Borough or Township
Small local governments do not need a hundred-page AI governance manual before they can improve their position. They need a concise, usable policy that staff can understand during a busy workday.A practical policy should answer four questions: what is allowed, what is prohibited, what needs approval, and what must be documented.
What Should Usually Be Allowed
Subject to human review and existing records rules, municipalities can generally consider allowing AI for tasks such as:- Editing grammar, tone, and readability in nonconfidential drafts
- Creating outlines from publicly available documents
- Generating brainstorming ideas for public outreach
- Reformatting already-approved public text
- Producing plain-language explanations that staff verify
- Translating nonconfidential content with human quality checks
- Drafting internal checklists and routine templates
- Organizing nonsensitive meeting preparation notes
What Should Be Prohibited Without Exception
A basic AI policy should clearly prohibit staff from entering the following into unapproved AI tools:- Nonpublic resident data
- Personally identifiable information
- Personnel, payroll, medical, or benefits information
- Financial account information
- Passwords, credentials, or security configurations
- Protected law-enforcement or investigative information
- Privileged legal advice
- Sensitive procurement or bid information
- Nonpublic records that could create cybersecurity, privacy, or legal risk
What Should Require Review and Approval
Some uses are not automatically prohibited but require managerial, legal, IT, or procurement review:- New AI subscriptions or paid accounts
- AI features embedded in existing software
- Meeting transcription or recording services
- Tools that connect to municipal email, files, or document repositories
- AI agents capable of taking actions in systems
- Public-facing chatbots
- Systems that analyze video, audio, location, behavior, or identity
- Tools used for benefits, licensing, inspections, enforcement, or eligibility
- Any system that shares municipal data with third parties
What Should Be Documented
Even a small office can maintain a simple AI register. It does not need to be complicated. A spreadsheet can capture:- Tool name and vendor
- Business purpose
- Departments or roles using it
- Data categories involved
- Whether it is enterprise-approved
- Account owner
- Contract and renewal information
- Security and privacy review status
- Human reviewer responsible for outputs
- Known limitations or restrictions
Training Is More Important Than Another Framework
The survey’s clearest operational conclusion is that employees want training, practical policy guidance, and examples from peer governments. They are not asking primarily for another abstract framework.That preference should shape how local-government AI programs are built.
Large governance frameworks remain useful. They offer a vocabulary for managing risk, identifying stakeholders, measuring performance, and documenting decisions. The most widely used AI risk-management approaches emphasize four interconnected activities: govern, map, measure, and manage.
For a small municipality, though, those concepts must become concrete:
- Govern: Who is responsible for AI decisions?
- Map: What tools are in use, and what data do they touch?
- Measure: How will the municipality check for errors, bias, leakage, or poor results?
- Manage: What happens when a tool creates a problem or no longer meets requirements?
A two-hour live training session may be more valuable to a township office than a dense 75-page report. A peer demonstration from a similar borough may be more persuasive than a case study from a major city. Staff want to see the actual prompts, review checklists, approved-use examples, and mistakes that their counterparts encountered.
That is not a rejection of policy. It is a demand for policy translated into practice.
The Role of Microsoft Copilot and the Windows Ecosystem
For many local governments, the most realistic path to governed AI will run through the tools they already use. Windows PCs, Microsoft 365, Teams, Outlook, SharePoint, OneDrive, and related business applications form the operational backbone of countless municipal offices.That creates a potential advantage. When an organization deploys AI within its existing Microsoft 365 environment, it may be able to apply established identity controls, user permissions, multifactor authentication, retention policies, sensitivity labels, data-loss-prevention rules, eDiscovery processes, and audit capabilities.
But it also creates a responsibility. Copilot can expose long-neglected permission problems. If a SharePoint site is overshared, an AI assistant may make that oversharing easier to discover. If records are stored inconsistently, AI may surface incomplete or conflicting information. If users have access they no longer need, the AI system may operate within those existing permissions rather than correcting them.
That means Copilot readiness is not only about licensing or user training. It is also a data-governance and identity-governance project.
Before broad deployment, small governments should prioritize:
- Reviewing shared-drive, SharePoint, and OneDrive permissions.
- Identifying highly sensitive document repositories.
- Applying appropriate sensitivity labels and retention rules.
- Confirming which Copilot features are enabled.
- Establishing a pilot group with defined use cases.
- Creating approved prompt examples and prohibited-data examples.
- Training employees to verify every substantive output.
- Monitoring usage and revising controls as real workflows emerge.
What Responsible Adoption Looks Like in Practice
The survey’s most optimistic finding is that local-government employees already understand the trade-offs. They see potential gains in efficiency, data analysis, and accessibility. They also recognize the risks involving confidentiality, bias, privacy, legal exposure, and loss of human connection.That awareness creates an opportunity. Small governments do not need to be persuaded that AI carries risk; they need help converting that awareness into repeatable practices.
A responsible local AI program should begin modestly:
- Choose a small number of low-risk administrative use cases.
- Provide approved enterprise tools rather than leaving staff to use personal accounts.
- Create a short policy that names permitted and prohibited activities.
- Require a human reviewer for externally shared or decision-relevant material.
- Train staff with realistic municipal examples.
- Share lessons through regional government networks.
- Review the policy periodically as products and workflows change.
Conclusion: Governance Must Catch Up to the Reality of Use
AI policy for local government cannot be designed only for major cities, large agencies, and well-funded technology offices. The smaller boroughs, townships, and municipal departments that make up so much of everyday government need guidance that matches their reality: limited staff, constrained budgets, broad responsibilities, and immediate public accountability.The Pennsylvania survey is limited in size, but its message is difficult to dismiss. Municipal employees are already using generative AI. Many are doing so without a formal policy, without consistent leadership direction, and sometimes outside approved enterprise environments. The tools have entered the workplace through individual initiative rather than institutional design.
That does not require panic. It requires action.
Small local governments should not wait for a perfect national standard, a major budget increase, or a technology crisis before establishing basic AI governance. A concise acceptable-use policy, approved tools, data-handling rules, practical staff training, peer learning, and meaningful human review can make a substantial difference.
AI has already reached the municipal desk. The next task is ensuring that public-sector accountability reaches it too.
References
- Primary source: Tech Policy Press
Published: 2026-07-24T12:53:22.944000+00:00
Loading…
www.techpolicy.press