Irish local authorities sit on more institutional knowledge than almost any organisation I've worked with — planning files going back decades, housing applications, road schedules, derelict sites registers, motor tax records, library systems, water complaints, dog licences. The problem isn't a shortage of data. It's that almost none of it is queryable in a way that helps a staff member answer a citizen on the phone, or helps a director of services see what's actually happening across their districts. That's the gap an on-premise intelligence layer fills, and it's the work I spend most of my time on now.
Why councils don't behave like normal organisations
Before talking about AI, it's worth being honest about what a council actually is. A local authority in Ireland isn't one organisation — it's a federation of statutory functions glued together by a CEO, an SMT, and a corporate services team. Planning operates under the Planning and Development Act. Housing operates under separate housing legislation and a relationship with the Department. Roads, water (now Uisce Éireann but with legacy data still in council systems), environment, fire services, libraries, motor tax, rates — each has its own legislation, its own retention rules, its own legacy IT system, and often its own vendor.
If you walk into a county council and ask "where does customer data live?", the honest answer is fifteen places. iPlan or APAS for planning. iHouse or a Northgate variant for housing. CRM (sometimes Agresso, sometimes Microsoft Dynamics, sometimes a homegrown system) for the corporate side. SharePoint and shared drives for everything that didn't fit. Email for the rest. Add the elected members layer, the Part 8 process, the SPC structure, and the LCDC, and you have an organisation where "knowing what we know" is genuinely difficult — not through laziness, but through structure.
Any AI layer that ignores this reality and tries to dump everything into a single cloud index will fail an information governance review on day one. That's the design constraint that shapes everything that follows.
What "intelligence brain" actually means in a council context
I use the phrase intelligence brain to mean a specific thing: an on-premise (or sovereign-tenancy) layer that reads from your existing line-of-business systems, indexes content under the same access controls those systems already enforce, and lets staff ask questions in natural language without the data ever leaving your environment.
For a council, that means three concrete capabilities:
- Cross-system search that respects ACLs. A planner should see planning files. A housing officer should see housing files. The CE should see across, but only because their role permits it. The intelligence layer doesn't grant new access — it inherits what's already in iPlan, in Active Directory, in the housing system.
- Grounded answers with citations. Every response points back to the source document, file reference, register entry, or email. No hallucinated planning conditions. No made-up housing precedents. If the system can't ground the answer, it says so.
- Structured extraction from unstructured input. Submissions on a Part 8, observations on a planning file, complaints to environmental health — these arrive as PDFs, letters, emails, sometimes handwritten. Pulling structure out of that is where most of the staff hours go, and it's exactly what current models do well.
The deployment pattern I push for is the one I describe on the public-sector intelligence brain page: models running inside the council's own infrastructure or a sovereign Irish-hosted tenancy, with no training on council data, no outbound telemetry of content, and audit logs that satisfy a Section 132 query or a Data Protection Commission inspection.
The real use cases — not the slide-deck ones
I've sat through enough vendor pitches to know what gets shown: a chatbot on the council website. That's the least interesting use case and the riskiest. Citizen-facing generative AI on a council site is a reputational landmine — one wrong answer about a derelict sites levy or a housing eligibility threshold and you're in the local paper.
The high-value work is internal. A short list of what I see actually moving the needle:
- Planning report drafting assistance. A planner still writes the report and signs it. But the system can pull all observations, summarise them by theme, surface relevant precedent decisions from your own register, and produce a first-draft skeleton with citations. The planner edits. Time saved per file is measured in hours, not minutes.
- FOI and AIE request handling. Finding responsive records across email, SharePoint, and line-of-business systems is the bottleneck. A grounded search layer with redaction tooling cuts the search phase dramatically. The decision-making, exemption analysis, and schedule of records still sit with the FOI officer.
- Councillor query routing and tracking. Reps come in by email, at SPC meetings, in writing, and verbally. An intelligence layer can classify, deduplicate, route to the correct section, and flag SLA breaches before they become motions at the next plenary.
- Housing maintenance triage. Inbound calls and emails about boilers, damp, anti-social behaviour. Classifying severity, matching to active works orders, surfacing the tenancy history — all unglamorous, all high-volume.
- Derelict sites and vacant homes registers. Cross-referencing GeoDirectory, NPPR records, planning history, and rates data to identify candidates. This is currently a manual desk exercise in most councils.
- Internal policy lookup. Staff genuinely don't know all the circulars, all the SPPRs, all the local variations. A grounded Q&A layer over your circulars and policies — read-only, citation-required — saves the senior planner from being interrupted forty times a day.
The architecture I deploy
Without getting into vendor specifics, the shape of a defensible council deployment looks like this. There's a connector layer that reads from each line-of-business system using its existing API or database views — never bulk extracts, never copies of the entire planning file store sitting on a separate server. Indexing happens in place where possible, or into a vector store that lives inside the council's network with the same backup and DR posture as the source systems.
Authentication uses the council's existing identity provider — usually Entra ID at this point. ACLs are enforced at query time, not at index time, so when someone leaves a department their access changes the same day, the same way it does in every other system.
The model layer is the part where I push back hardest on cloud-default thinking. For a council, sending document content to a US-hosted commercial LLM API for inference creates a Schrems II analysis you don't want to do every quarter. Open-weight models running on local GPU infrastructure, or models hosted in an Irish or EU sovereign environment under a proper DPA, remove that problem. The performance difference for the use cases above is small. The legal difference is enormous.
Logging is non-negotiable. Every query, every retrieval, every generation, with the user identity and the documents touched. Six-year retention to match FOI. Exportable on demand for any DPC inquiry.
What blows up if you skip the boring parts
I've watched a few council AI pilots stall, and the failure modes repeat:
- Records management debt. If your SharePoint has fourteen versions of the same housing policy and nobody knows which is current, the AI will confidently quote the wrong one. The intelligence layer exposes records management problems you've been able to live with for years. Fix them first, or at minimum scope the index narrowly.
- Permissions drift. If your file shares are open to "everyone" because that was easier in 2011, the AI will surface things to staff who shouldn't see them. Run a permissions audit before you index. This is true even without AI; AI just makes it visible.
- No human-in-the-loop discipline. Anything that goes to a citizen, a councillor, an applicant, or a court file is reviewed and signed by a named officer. The AI drafts. The officer decides. Build that into the workflow, not into a training slide.
- Procurement via the wrong framework. OGP frameworks exist for a reason. Going outside them for an AI tool because a vendor is persuasive will cost you a Local Government Audit Service finding.
Where Ireland-specific context matters
A generic enterprise AI product, dropped into an Irish council, will get the small things wrong in ways that erode trust. Eircodes, not postcodes. PPSN handling under specific data protection rules. Irish-language obligations under the Official Languages Act — including the recent strengthening around services and signage. The MD/Municipal District structure. The difference between a Section 5 declaration and a Section 38 referral. The fact that "the executive" means something specific.
None of this is hard, but it has to be built in deliberately. A model that defaults to UK council terminology, or that doesn't understand the reserved-vs-executive function distinction, will produce confident nonsense. The Intelligence Brain approach I've taken is to ground every deployment in the actual policies, circulars, and local context of the specific authority — not a generic public-sector knowledge base scraped off the web.
Where to start this week
If you're a CE, director of services, or head of IT in a local authority and this is on your radar, don't start with a vendor demo. Start with a one-page audit: list your top ten line-of-business systems, who owns each one, what its access model is, and what its data retention obligations are. Pick one workflow that's eating staff hours — FOI, councillor queries, planning observations, take your pick — and scope a four-week, read-only proof of value over that single workflow with proper logging and a named officer in the loop. If it works, you'll know. If it doesn't, you'll have learned something useful and spent very little. That's the only honest way to bring this technology into a council, and it's the way