How to enforce an AI acceptable-use policy in local government

Acutis Gate · guides for IT directors · updated October 2026

Short answer: map every clause of the policy to a control that works whether or not people remember the policy. "Only data you're authorized to see" becomes identity on every AI action. "No personal data to outside AI" becomes a local model plus a data filter. "Changes need sign-off" becomes approval rules. "Keep records" becomes an audit trail in your SIEM. A policy people sign but nothing enforces is the reason so many towns simply ban AI.

Still writing the policy? Start from the AI acceptable use policy template (Word download) and the employee handbook section.

Clause by clause

"Staff may use AI only with data they are authorized to access"

Enforce it with identity, not trust. Every AI action should run as the employee who asked, so the HR system, finance system and file shares apply their own rights. Define who is in scope with a group you already manage: in Active Directory Users and Computers, open the group (for example AI-Users) and check the Members tab.

Command line

Get-ADGroupMember "AI-Users" -Recursive | Select-Object name, samAccountName

"No resident or employee personal data in public AI tools"

Run the model on your own hardware (see a local LLM for a small town), and redact card numbers, Social Security numbers and secrets before any text reaches a model. Then make the gateway the only tool server AI clients can reach, with a firewall rule, so nobody wires a tool straight to a database.

"AI may not make changes without human review"

Write it as rules: reads allowed for the right groups, writes staged for an approver, a few areas off limits to everyone. In the Gate console:

1. Open Guardrails and add a rule: who (a group), what (read, write, run), on which app or share, and the effect (allow, deny, needs approval).
2. Use Test as a person to see exactly what one employee's AI could do before you save.
3. Save. Rules you mark as locked need an admin with an authenticator code to change.

Underneath, the same rules are plain text you can review or keep in version control:

[
  {"id": "hr-reads-hr", "who": ["group:HR-Partners"], "effect": "allow",
   "do": ["read"], "on": ["hris://employees/**"]},
  {"id": "finance-writes-approved", "who": ["group:Finance"], "effect": "approve",
   "do": ["write"], "on": ["finance://**"], "approvers": ["group:Finance-Managers"]},
  {"id": "nobody-touches-legal", "who": ["*"], "effect": "deny",
   "do": ["*"], "on": ["files://fs1/Legal/**"], "locked": true}
]

No rule matches means deny; an explicit deny always wins; a staged call runs only after an approver enters an authenticator code, and it still runs as the person who asked.

"AI use must be recorded and retained"

Keep a per-action record (who, what, which rule, as whom, the arguments and the result) and send it to the system your records schedule already covers. See MCP audit logging to your SIEM. Check your state's retention schedule for how long; the trail should be exportable, not locked in a vendor.

Starting without rules on day one

Most towns don't know yet what staff will use AI for. Acutis Gate starts in learning mode: every call allowed and recorded. After a week or two, Build rules from the trail drafts allow and needs-approval rules from what people actually did; you review, save, and from then on anything new is denied until you allow it.

What to tell the council

Three promises you can check: every AI action is attributed to a real person, fenced by rules the IT director wrote, and recorded in a trail nobody can quietly edit. What no product can promise: detecting bad intent, or seeing AI use that skips the gateway. The firewall rule covers the second.

Frequently asked questions