Potter County commissioners in Amarillo, Texas, voted unanimously on June 22, 2026, to adopt an AI Appropriate Use Policy that puts the county IT department in charge of approving and implementing artificial intelligence tools for employee use. The vote is a small local-government item with a much larger Windows-era lesson: AI adoption is no longer waiting for Washington, Austin, or the next enterprise software licensing cycle. It is arriving at the county desk, the sheriff’s office, the clerk’s counter, and the shared Microsoft 365 tenant. Potter County’s move is not anti-AI; it is the beginning of AI becoming ordinary enough to require boring rules.
The headline fact from Potter County is simple: employees may use AI tools only under a county policy, and the county’s own IT staff will approve what gets used. That matters because it shifts AI from a personal productivity experiment to a governed workplace system. The county is not telling employees that generative AI has no place in public work; it is saying the place has to be defined before the tool is trusted.
That distinction is easy to miss in the current AI debate, where public institutions are often described as either embracing the future or hiding from it. Potter County’s policy lands somewhere more practical. Commissioners appear to recognize that AI can help with mundane work such as designing forms, drafting routine material, or speeding up administrative tasks, while also recognizing that a prompt box is not a private filing cabinet.
Commissioner John Coffee’s public explanation gets to the core of the issue: employees should not feed personal or private information into public AI platforms. That sounds obvious until one remembers how generative AI is actually used. People paste in emails, spreadsheets, letters, complaints, draft legal language, HR notes, and case details because the magic of the tool is that it works better with context.
The policy is therefore less about “AI” in the abstract than about where county information goes when employees try to make their jobs easier. For public-sector IT, that is the familiar problem wearing a new interface. The old shadow IT pattern was an employee uploading files to a consumer cloud drive; the new version is an employee pasting sensitive text into a chatbot because it rewrites paragraphs faster than Word’s grammar checker.
But from an IT governance perspective, a prompt can be as sensitive as an attachment. If it contains names, addresses, Social Security numbers, health details, juvenile information, law-enforcement material, personnel records, or vendor data, the county has just moved protected information outside the systems built to contain it. The fact that the user experiences the transaction as typing into a helpful assistant does not change the risk.
This is where Potter County’s policy reflects a broader maturation of AI governance. Early generative AI policies were often framed around accuracy: do not trust hallucinated answers, verify generated text, and remember that chatbots can be wrong. Those warnings are still necessary, but they are not enough. The bigger institutional risk may be less about a chatbot inventing a fact than about an employee casually disclosing a real one.
The county’s reported ban on submitting personal information also recognizes a hard truth about public AI services. Consumer-grade or broadly accessible AI tools are not automatically private merely because an employee is using them for work. Terms of service, retention controls, training settings, administrative auditability, regional processing, and vendor contractual commitments all matter.
That is why IT approval is not bureaucratic theater. An approved AI tool should come with configuration, logging, identity controls, retention expectations, and a clear understanding of what data may enter the system. Without that, the policy is just a memo telling employees to be careful in a world designed to reward speed over caution.
In other words, counties sit on precisely the kind of information that should not be casually copied into unvetted AI systems. They also operate under budget and staffing constraints that make AI especially attractive. A large federal agency can stand up an AI governance office; a county department may have one person juggling endpoint management, email security, printer misery, and a backlog of software requests.
That tension is why Potter County’s action is notable. The county is creating a permission structure before AI use hardens into habit. Once employees begin relying on personal AI accounts for routine work, clawing that behavior back becomes difficult. Every IT administrator knows the pattern: first the tool is convenient, then it is unofficially essential, then the organization discovers it has no records, controls, or contract.
Public agencies also face a different transparency environment than private companies. Work product, communications, and certain records may be subject to public-information laws. AI prompts and outputs could become part of a records dispute depending on how they are used, stored, or relied upon. Even when the law is unsettled, the operational lesson is clear: government employees should not assume that AI interactions are invisible, informal, or disposable.
The county’s policy also points toward a future in which “approved AI” becomes a standard line item in local IT. Not every department needs a custom model. Many need a sanctioned way to summarize non-sensitive documents, draft templates, brainstorm internal communications, or improve accessibility without leaking data. A modest policy can become the foundation for that more useful environment.
That changes the governance problem. When AI lived mostly at public chatbot websites, blocking or discouraging access was comparatively straightforward. As AI becomes embedded in productivity suites, search experiences, document editors, meeting tools, and security platforms, organizations need policy that maps to identity, licensing, tenant configuration, and data classification.
A county IT department approving AI programs is therefore not just approving “apps.” It may be deciding which Microsoft 365 features are enabled, whether Copilot-style tools are available to certain departments, what sensitivity labels apply, and how audit logs are reviewed. The boundary between AI policy and ordinary endpoint administration will keep getting thinner.
Microsoft’s enterprise pitch is that AI can respect existing permissions and compliance boundaries when deployed properly. That is a serious argument, and for many organizations an enterprise AI service with tenant controls is much safer than a patchwork of consumer accounts. But “safer” is not the same as “automatic.” If files are overshared in SharePoint, if mailbox permissions are sloppy, or if retention policies are inconsistent, AI can amplify existing governance failures.
This is the quiet nightmare for sysadmins. AI does not create every data problem from scratch; it often accelerates discovery of problems that were already there. A chatbot that can summarize everything a user can access will also reveal how much that user should perhaps never have been able to access in the first place.
That kind of use can produce real benefits without requiring the county to disclose private information. The employee does not need to paste in a resident’s case file to ask for a better dog-license renewal form or a cleaner public-works request template. The AI can help with structure, readability, translation drafts, accessibility improvements, and routine formatting.
The risk begins when “help me design a form” becomes “use this completed form as an example.” One version uses generic requirements. The other may expose names, addresses, signatures, medical information, payment details, or law-enforcement context. The difference is not philosophical; it is operational.
Good AI policy has to teach employees that distinction. The safe prompt is abstracted, anonymized, or synthetic. The unsafe prompt contains real people, real cases, real identifiers, or internal material that the organization would never post publicly. That training burden cannot be solved by a single commissioners court vote, but the vote gives IT the authority to build the practice.
The form example also underscores why outright bans rarely survive contact with office life. Employees have legitimate reasons to want better tools. If the official answer is simply “no AI,” the unofficial answer may become personal accounts, home devices, and copy-paste workflows that nobody can see. A controlled yes is often safer than an unenforceable no.
The first test will be whether employees know which tools are allowed. If the rule says “IT must approve AI programs” but does not provide a clear list, employees will improvise. A good policy needs a living catalog of approved services, denied services, and conditional uses. It also needs to account for AI features hidden inside products that may not look like standalone AI tools.
The second test will be data classification. Telling employees not to use “personal information” is necessary, but government data categories are messy. Public records, confidential records, law-enforcement-sensitive information, health data, personnel files, procurement material, attorney-client communications, and routine correspondence all carry different risks. Employees need examples from their own jobs, not abstract warnings.
The third test will be accountability. If AI output is used in county work, someone remains responsible for it. A chatbot cannot be the author of a policy decision, the witness to a fact, or the final reviewer of a public communication. Human review is not a slogan; it is the control that keeps automation from quietly becoming authority.
This is where local governments must resist vendor language that treats AI as a neutral productivity layer. AI systems generate plausible outputs, not institutional judgment. They can summarize, suggest, translate, classify, and draft, but the county owns the consequence when something wrong, biased, incomplete, or unauthorized is sent out under its seal.
On Windows fleets, that may mean browser policies, application control, data-loss prevention, DNS filtering, and restrictions on extensions. In Microsoft 365 environments, it may mean sensitivity labels, conditional access, audit logging, Purview policies, and careful review of Copilot eligibility. In mixed environments, it may mean procurement rules that stop departments from buying AI-enabled SaaS tools with a credit card.
The tricky part is that AI features are spreading faster than traditional approval cycles. A vendor may add a “smart assistant” to a product the county already uses. A browser update may place an AI sidebar one click away. A meeting platform may introduce summaries, transcripts, or action items that create new records and new retention questions.
This is not a reason for panic, but it is a reason for inventory. Counties need to know where AI already exists in their environment before they can govern it. The question is no longer “Should we buy an AI tool?” It is “Which tools we already bought now contain AI, and what data can they touch?”
That inventory work is unglamorous and essential. It also favors the IT departments that already practice disciplined asset management. Organizations that know their devices, apps, accounts, data stores, and permissions will find AI governance difficult but manageable. Organizations that lack that baseline will find AI turning every neglected spreadsheet and overshared folder into a policy problem.
A perfectly accurate AI output can still be improper if it was produced using confidential input. A beautifully written letter can still violate policy if the employee pasted in a resident’s private information to generate it. A summary can still be dangerous if it compresses uncertainty into false confidence.
There is also the problem of provenance. If an AI tool drafts language for a public form, who verifies that the language reflects county policy and current law? If it translates instructions into another language, who checks the translation before publication? If it summarizes a long document for an official, does the official understand what was omitted?
These questions are not theoretical in government work. Public agencies are expected to be explainable in a way that private internal workflows often are not. If a resident is denied a service, misdirected by a form, or affected by an administrative decision, “the AI suggested it” will not be an acceptable answer.
That is why the best early AI use cases in local government are assistive rather than decisive. Drafting a blank template is safer than evaluating a person. Summarizing a public document is safer than summarizing a confidential case file. Brainstorming plain-language instructions is safer than generating legal conclusions.
Consumer AI tools often put the user in a weak position. Enterprise agreements can offer stronger privacy and security commitments, but those commitments vary by product and tier. A county cannot assume that a familiar brand automatically provides a government-appropriate configuration.
This is especially important for AI features added to existing SaaS platforms. Departments may not think they are acquiring a new AI system when a vendor turns on automated drafting or summarization. But if the feature processes county data in a new way, it deserves review. The procurement question becomes not only “What are we buying?” but “What did our vendor just change?”
The contract also has to match the sensitivity of the use case. An AI tool for generating generic newsletter copy is not the same as one used around court records, health information, tax data, or law-enforcement workflows. A mature policy should not treat all AI as equally dangerous or equally safe.
This risk-tiered approach is where local governments can learn from established cybersecurity practice. Not every system needs the same controls, but every system needs a classification. The worst policy outcome is a vague rule that scares employees away from low-risk uses while failing to stop high-risk ones.
The legal environment remains uneven. Federal AI law is still fragmented, state rules are evolving, and local governments have to reconcile AI with existing privacy, records, procurement, cybersecurity, and civil-rights obligations. That creates uncertainty, but it does not create a vacuum. Existing duties still apply when the tool is new.
For Texas local government, public-information obligations add another layer. If AI-generated material becomes part of public business, it may need to be retained or produced like other records. If prompts include sensitive material, the county may face the unpleasant combination of disclosure risk and confidentiality risk at the same time.
That is one reason a policy adopted in a commissioners court meeting can matter more than its short news write-up suggests. It creates a public record that the county sees the risk and is assigning responsibility. That does not solve implementation, but it establishes intent and authority.
The more counties do this, the more AI governance will become part of ordinary civic infrastructure. Ten years ago, ransomware readiness moved from specialist concern to boardroom and council-chamber business. AI use is making a similar journey, though with a more seductive sales pitch. Nobody wants ransomware; plenty of employees genuinely want AI.
The better approach is practical literacy. Employees should understand that AI prompts can transmit data, that outputs require review, that public-facing material needs approval, and that certain categories of information must never enter unapproved systems. They should also be given safe alternatives when AI can legitimately help.
This is where IT departments need support from leadership. If commissioners want safeguards, departments need time for training, procurement review, and configuration. If the policy becomes an unfunded mandate dropped on an already stretched IT staff, it will become a binder rule rather than a working control.
The policy should also invite employees to ask before they experiment. A culture of “check with IT” is healthier than a culture of “hope nobody notices.” That requires IT to respond quickly and pragmatically. If every request disappears into a months-long review, employees will route around the process.
Potter County’s policy gives IT the gatekeeping role, but gatekeeping is not the same as obstruction. The best version of this policy will make the safe path easier than the risky one. Approved tools, clear examples, short training, and department-specific guidance will do more than a stern warning ever could.
Potter County Chooses Permission Over Panic
The headline fact from Potter County is simple: employees may use AI tools only under a county policy, and the county’s own IT staff will approve what gets used. That matters because it shifts AI from a personal productivity experiment to a governed workplace system. The county is not telling employees that generative AI has no place in public work; it is saying the place has to be defined before the tool is trusted.That distinction is easy to miss in the current AI debate, where public institutions are often described as either embracing the future or hiding from it. Potter County’s policy lands somewhere more practical. Commissioners appear to recognize that AI can help with mundane work such as designing forms, drafting routine material, or speeding up administrative tasks, while also recognizing that a prompt box is not a private filing cabinet.
Commissioner John Coffee’s public explanation gets to the core of the issue: employees should not feed personal or private information into public AI platforms. That sounds obvious until one remembers how generative AI is actually used. People paste in emails, spreadsheets, letters, complaints, draft legal language, HR notes, and case details because the magic of the tool is that it works better with context.
The policy is therefore less about “AI” in the abstract than about where county information goes when employees try to make their jobs easier. For public-sector IT, that is the familiar problem wearing a new interface. The old shadow IT pattern was an employee uploading files to a consumer cloud drive; the new version is an employee pasting sensitive text into a chatbot because it rewrites paragraphs faster than Word’s grammar checker.
The Prompt Box Is the New Data Leak
Generative AI has made data handling feel conversational, and that is precisely why it is dangerous in government offices. A prompt does not look like an upload. A chatbot does not feel like a third-party processor. A clerk asking an AI system to “clean up this letter” may not think they are transmitting citizen data anywhere significant.But from an IT governance perspective, a prompt can be as sensitive as an attachment. If it contains names, addresses, Social Security numbers, health details, juvenile information, law-enforcement material, personnel records, or vendor data, the county has just moved protected information outside the systems built to contain it. The fact that the user experiences the transaction as typing into a helpful assistant does not change the risk.
This is where Potter County’s policy reflects a broader maturation of AI governance. Early generative AI policies were often framed around accuracy: do not trust hallucinated answers, verify generated text, and remember that chatbots can be wrong. Those warnings are still necessary, but they are not enough. The bigger institutional risk may be less about a chatbot inventing a fact than about an employee casually disclosing a real one.
The county’s reported ban on submitting personal information also recognizes a hard truth about public AI services. Consumer-grade or broadly accessible AI tools are not automatically private merely because an employee is using them for work. Terms of service, retention controls, training settings, administrative auditability, regional processing, and vendor contractual commitments all matter.
That is why IT approval is not bureaucratic theater. An approved AI tool should come with configuration, logging, identity controls, retention expectations, and a clear understanding of what data may enter the system. Without that, the policy is just a memo telling employees to be careful in a world designed to reward speed over caution.
Local Government Is Where AI Governance Gets Real
It is tempting to see a county AI policy as small news compared with Microsoft Copilot, OpenAI model releases, or federal AI executive orders. That misses the importance of where government technology actually meets citizens. Counties process property records, court documents, benefits paperwork, jail records, emergency management data, public health information, elections material, procurement files, and employee records.In other words, counties sit on precisely the kind of information that should not be casually copied into unvetted AI systems. They also operate under budget and staffing constraints that make AI especially attractive. A large federal agency can stand up an AI governance office; a county department may have one person juggling endpoint management, email security, printer misery, and a backlog of software requests.
That tension is why Potter County’s action is notable. The county is creating a permission structure before AI use hardens into habit. Once employees begin relying on personal AI accounts for routine work, clawing that behavior back becomes difficult. Every IT administrator knows the pattern: first the tool is convenient, then it is unofficially essential, then the organization discovers it has no records, controls, or contract.
Public agencies also face a different transparency environment than private companies. Work product, communications, and certain records may be subject to public-information laws. AI prompts and outputs could become part of a records dispute depending on how they are used, stored, or relied upon. Even when the law is unsettled, the operational lesson is clear: government employees should not assume that AI interactions are invisible, informal, or disposable.
The county’s policy also points toward a future in which “approved AI” becomes a standard line item in local IT. Not every department needs a custom model. Many need a sanctioned way to summarize non-sensitive documents, draft templates, brainstorm internal communications, or improve accessibility without leaking data. A modest policy can become the foundation for that more useful environment.
Microsoft’s AI Push Makes County Rules Urgent
For WindowsForum readers, the Potter County decision should be read against the backdrop of Microsoft’s aggressive integration of AI across Windows, Edge, Teams, Outlook, Word, Excel, SharePoint, and the broader Microsoft 365 stack. AI is no longer a separate destination employees visit in a browser. Increasingly, it is a button inside the software they already use.That changes the governance problem. When AI lived mostly at public chatbot websites, blocking or discouraging access was comparatively straightforward. As AI becomes embedded in productivity suites, search experiences, document editors, meeting tools, and security platforms, organizations need policy that maps to identity, licensing, tenant configuration, and data classification.
A county IT department approving AI programs is therefore not just approving “apps.” It may be deciding which Microsoft 365 features are enabled, whether Copilot-style tools are available to certain departments, what sensitivity labels apply, and how audit logs are reviewed. The boundary between AI policy and ordinary endpoint administration will keep getting thinner.
Microsoft’s enterprise pitch is that AI can respect existing permissions and compliance boundaries when deployed properly. That is a serious argument, and for many organizations an enterprise AI service with tenant controls is much safer than a patchwork of consumer accounts. But “safer” is not the same as “automatic.” If files are overshared in SharePoint, if mailbox permissions are sloppy, or if retention policies are inconsistent, AI can amplify existing governance failures.
This is the quiet nightmare for sysadmins. AI does not create every data problem from scratch; it often accelerates discovery of problems that were already there. A chatbot that can summarize everything a user can access will also reveal how much that user should perhaps never have been able to access in the first place.
The Form-Design Example Tells the Whole Story
Commissioner Coffee’s example of using AI to design a form is more revealing than it first appears. Form design is exactly the kind of low-risk, high-friction work where AI can help public employees. A worker can ask for a clearer layout, better instructions, plain-language phrasing, or a checklist that reduces errors from residents.That kind of use can produce real benefits without requiring the county to disclose private information. The employee does not need to paste in a resident’s case file to ask for a better dog-license renewal form or a cleaner public-works request template. The AI can help with structure, readability, translation drafts, accessibility improvements, and routine formatting.
The risk begins when “help me design a form” becomes “use this completed form as an example.” One version uses generic requirements. The other may expose names, addresses, signatures, medical information, payment details, or law-enforcement context. The difference is not philosophical; it is operational.
Good AI policy has to teach employees that distinction. The safe prompt is abstracted, anonymized, or synthetic. The unsafe prompt contains real people, real cases, real identifiers, or internal material that the organization would never post publicly. That training burden cannot be solved by a single commissioners court vote, but the vote gives IT the authority to build the practice.
The form example also underscores why outright bans rarely survive contact with office life. Employees have legitimate reasons to want better tools. If the official answer is simply “no AI,” the unofficial answer may become personal accounts, home devices, and copy-paste workflows that nobody can see. A controlled yes is often safer than an unenforceable no.
Appropriate Use Is a Governance Layer, Not a Magic Shield
An AI Appropriate Use Policy sounds reassuring, but its value depends on the machinery behind it. The phrase can mean anything from a one-page warning to a full governance program with approved tools, training, reporting channels, procurement review, audit logs, incident response, and disciplinary consequences. Potter County’s public description gives the direction of travel, not the full map.The first test will be whether employees know which tools are allowed. If the rule says “IT must approve AI programs” but does not provide a clear list, employees will improvise. A good policy needs a living catalog of approved services, denied services, and conditional uses. It also needs to account for AI features hidden inside products that may not look like standalone AI tools.
The second test will be data classification. Telling employees not to use “personal information” is necessary, but government data categories are messy. Public records, confidential records, law-enforcement-sensitive information, health data, personnel files, procurement material, attorney-client communications, and routine correspondence all carry different risks. Employees need examples from their own jobs, not abstract warnings.
The third test will be accountability. If AI output is used in county work, someone remains responsible for it. A chatbot cannot be the author of a policy decision, the witness to a fact, or the final reviewer of a public communication. Human review is not a slogan; it is the control that keeps automation from quietly becoming authority.
This is where local governments must resist vendor language that treats AI as a neutral productivity layer. AI systems generate plausible outputs, not institutional judgment. They can summarize, suggest, translate, classify, and draft, but the county owns the consequence when something wrong, biased, incomplete, or unauthorized is sent out under its seal.
The Public-Sector AI Problem Is Also a Windows Admin Problem
For many county employees, the practical AI policy will arrive through Windows devices, browsers, identity providers, and office suites. That means endpoint management and cloud administration become frontline AI governance. The commissioners can set the rule, but IT has to translate it into controls.On Windows fleets, that may mean browser policies, application control, data-loss prevention, DNS filtering, and restrictions on extensions. In Microsoft 365 environments, it may mean sensitivity labels, conditional access, audit logging, Purview policies, and careful review of Copilot eligibility. In mixed environments, it may mean procurement rules that stop departments from buying AI-enabled SaaS tools with a credit card.
The tricky part is that AI features are spreading faster than traditional approval cycles. A vendor may add a “smart assistant” to a product the county already uses. A browser update may place an AI sidebar one click away. A meeting platform may introduce summaries, transcripts, or action items that create new records and new retention questions.
This is not a reason for panic, but it is a reason for inventory. Counties need to know where AI already exists in their environment before they can govern it. The question is no longer “Should we buy an AI tool?” It is “Which tools we already bought now contain AI, and what data can they touch?”
That inventory work is unglamorous and essential. It also favors the IT departments that already practice disciplined asset management. Organizations that know their devices, apps, accounts, data stores, and permissions will find AI governance difficult but manageable. Organizations that lack that baseline will find AI turning every neglected spreadsheet and overshared folder into a policy problem.
The Accuracy Debate Is Too Narrow
Much of the public conversation around generative AI still centers on hallucination, and rightly so. A county cannot have employees relying on fabricated statutes, invented citations, fake case summaries, or incorrect public instructions. But accuracy is only one dimension of the risk.A perfectly accurate AI output can still be improper if it was produced using confidential input. A beautifully written letter can still violate policy if the employee pasted in a resident’s private information to generate it. A summary can still be dangerous if it compresses uncertainty into false confidence.
There is also the problem of provenance. If an AI tool drafts language for a public form, who verifies that the language reflects county policy and current law? If it translates instructions into another language, who checks the translation before publication? If it summarizes a long document for an official, does the official understand what was omitted?
These questions are not theoretical in government work. Public agencies are expected to be explainable in a way that private internal workflows often are not. If a resident is denied a service, misdirected by a form, or affected by an administrative decision, “the AI suggested it” will not be an acceptable answer.
That is why the best early AI use cases in local government are assistive rather than decisive. Drafting a blank template is safer than evaluating a person. Summarizing a public document is safer than summarizing a confidential case file. Brainstorming plain-language instructions is safer than generating legal conclusions.
The Vendor Contract Is Where the Policy Becomes Real
Potter County’s decision to let IT approve AI programs places a heavy burden on procurement and vendor review. The question is not merely whether a tool is useful. It is whether the county has acceptable terms governing data retention, model training, access controls, breach notification, subcontractors, auditability, and deletion.Consumer AI tools often put the user in a weak position. Enterprise agreements can offer stronger privacy and security commitments, but those commitments vary by product and tier. A county cannot assume that a familiar brand automatically provides a government-appropriate configuration.
This is especially important for AI features added to existing SaaS platforms. Departments may not think they are acquiring a new AI system when a vendor turns on automated drafting or summarization. But if the feature processes county data in a new way, it deserves review. The procurement question becomes not only “What are we buying?” but “What did our vendor just change?”
The contract also has to match the sensitivity of the use case. An AI tool for generating generic newsletter copy is not the same as one used around court records, health information, tax data, or law-enforcement workflows. A mature policy should not treat all AI as equally dangerous or equally safe.
This risk-tiered approach is where local governments can learn from established cybersecurity practice. Not every system needs the same controls, but every system needs a classification. The worst policy outcome is a vague rule that scares employees away from low-risk uses while failing to stop high-risk ones.
Texas Counties Are Moving Before the Rulebook Is Finished
Potter County is not acting in a vacuum. Texas has been building more formal AI governance expectations, including state resources around acceptable use, public-facing AI notices, and ethical principles. Counties, meanwhile, are watching neighboring governments adopt policies because the tools are already in employee hands.The legal environment remains uneven. Federal AI law is still fragmented, state rules are evolving, and local governments have to reconcile AI with existing privacy, records, procurement, cybersecurity, and civil-rights obligations. That creates uncertainty, but it does not create a vacuum. Existing duties still apply when the tool is new.
For Texas local government, public-information obligations add another layer. If AI-generated material becomes part of public business, it may need to be retained or produced like other records. If prompts include sensitive material, the county may face the unpleasant combination of disclosure risk and confidentiality risk at the same time.
That is one reason a policy adopted in a commissioners court meeting can matter more than its short news write-up suggests. It creates a public record that the county sees the risk and is assigning responsibility. That does not solve implementation, but it establishes intent and authority.
The more counties do this, the more AI governance will become part of ordinary civic infrastructure. Ten years ago, ransomware readiness moved from specialist concern to boardroom and council-chamber business. AI use is making a similar journey, though with a more seductive sales pitch. Nobody wants ransomware; plenty of employees genuinely want AI.
The Human Factor Will Decide Whether the Policy Works
No county AI policy can succeed if it treats employees as the enemy. Workers paste sensitive data into tools because they are under time pressure, because the tool appears helpful, because the interface gives no warning, or because nobody has explained the boundary in terms that fit their job. Punitive rules without training will drive the behavior underground.The better approach is practical literacy. Employees should understand that AI prompts can transmit data, that outputs require review, that public-facing material needs approval, and that certain categories of information must never enter unapproved systems. They should also be given safe alternatives when AI can legitimately help.
This is where IT departments need support from leadership. If commissioners want safeguards, departments need time for training, procurement review, and configuration. If the policy becomes an unfunded mandate dropped on an already stretched IT staff, it will become a binder rule rather than a working control.
The policy should also invite employees to ask before they experiment. A culture of “check with IT” is healthier than a culture of “hope nobody notices.” That requires IT to respond quickly and pragmatically. If every request disappears into a months-long review, employees will route around the process.
Potter County’s policy gives IT the gatekeeping role, but gatekeeping is not the same as obstruction. The best version of this policy will make the safe path easier than the risky one. Approved tools, clear examples, short training, and department-specific guidance will do more than a stern warning ever could.
The Potter County Vote Is Small, but the Pattern Is Big
The concrete lessons from Potter County’s vote are not complicated, which is exactly why they are useful. Local governments do not need to solve every philosophical problem in AI before setting workplace rules. They need to decide who approves tools, what data is off limits, and who remains accountable for the output.- Potter County’s commissioners unanimously adopted an AI Appropriate Use Policy on June 22, 2026, placing AI approval and implementation under county IT rather than leaving employees to choose tools on their own.
- The policy’s central safeguard is a ban on submitting personal or private information into AI systems that are not treated as private county environments.
- The county’s public framing leaves room for low-risk productivity uses, such as designing forms, while drawing a line around non-county personnel data and other sensitive information.
- For Windows and Microsoft 365 administrators, the practical work will be inventorying AI features, configuring approved services, and preventing consumer-grade AI use from becoming shadow IT.
- The hardest part will not be writing the policy; it will be training employees to distinguish generic, safe prompts from prompts that expose real people, real records, or confidential county business.
- Potter County’s move reflects a broader shift in which AI governance is becoming a routine responsibility for local IT, not an experimental topic reserved for large agencies and tech companies.
References
- Primary source: KVII
Published: Mon, 22 Jun 2026 23:57:53 GMT
Loading…
abc7amarillo.com - Official source: nist.gov
Loading…
www.nist.gov - Related coverage: texasattorneygeneral.gov
Loading…
www.texasattorneygeneral.gov - Related coverage: tpr.org
Loading…
www.tpr.org - Related coverage: naco.org
Loading…
www.naco.org