Voice AI and Freedom of Information: A Public Sector Guide

A council, an NHS trust, a university or a police force that puts a voice AI agent on its main phone line has quietly created a new body of recorded information: call recordings, transcripts, the contract with the AI vendor, the containment and error rates the system reports, the logic that decides which callers get routed to a human. Under the Freedom of Information Act 2000, any person can ask to see that information. Not just their own data. Any of it. And the clock is twenty working days, not the one month a data subject access request runs on.

This is the part public sector teams miss when they scope a voice AI deployment. They plan carefully for the UK GDPR, for the subject access request that lets a caller ask for their own recording, for the privacy notice that tells callers what is happening. Freedom of information is a different statute with a different requester, a different scope and a different clock, and it reaches the operational guts of the system, not just the personal data inside it.

This guide is shipped by the team behind Dilr Voice, enterprise voice AI built for regulated and public sector deployments. Or see DATS, our five-stage AI consulting system for institutions that answer to a regulator.

To be clear about who this binds: freedom of information duties fall on the public authority, not on the AI vendor and not on a private company running its own line. If your organisation is not a public authority, most of this guide is context rather than obligation. If it is, the deployment you build now decides whether you can answer an FOI request in twenty working days or spend the next quarter reconstructing what your own system did.

What is a freedom of information request, and how is it different from a subject access request?

A freedom of information request is a statutory right, under the Freedom of Information Act 2000, for any person to ask a public authority for any recorded information it holds. Dilr.ai treats it as distinct from a subject access request in three ways: the requester need not be the data subject, the scope is all recorded information rather than one person's data, and the deadline is twenty working days, not one month.

Public bodies are adopting AI at close to the same rate as everyone else, and every deployment adds to the pile of recorded information that freedom of information can reach. Across the wider economy, McKinsey's State of AI (November 2025) found that 88% of organisations report using AI in at least one function, but only 33% have it in production and just 6% are AI-mature. The gap matters here because a half-scaled voice deployment still produces contracts, logs and performance data the moment it goes live, and all of it is disclosable whether or not the project ever reaches maturity.

The distinction is not academic. If your team treats an FOI request about your voice AI system as if it were a data protection matter, you will apply the wrong exemptions, quote the wrong deadline and, in the worst case, hand over information that should have been protected as a trade secret. Section 40 of the Act is the seam between the two regimes: a person's request for their own personal data is actually exempt from freedom of information, precisely because the right route is a subject access request under data protection law. Get the classification right at intake and everything downstream follows.

Which organisations does the Freedom of Information Act actually bind?

The Freedom of Information Act binds public authorities, and only public authorities. Section 3 defines them as bodies listed in Schedule 1, bodies designated by order, and publicly owned companies. In practice that means central government departments, local councils, NHS trusts, most universities and police forces. A private company running a voice AI line is not directly caught, and neither is an AI vendor, a point Dilr.ai returns to below because it is where deployments go wrong.

So the first question at intake is not "what do we disclose" but "are we even in scope". If your organisation is a public authority under Schedule 1, the duty is yours and it is non-delegable. You cannot contract it away to the vendor, and you cannot answer "the AI supplier holds that, ask them". The wider enterprise AI governance work a private firm might do for its own comfort becomes, for a public authority, a statutory necessity that sits alongside the rest of your voice AI compliance obligations: the records you keep and the way you keep them determine whether you can meet the duty at all.

The trap is the assumption that recorded information stops at your own servers. It does not. Section 3 of the Act reaches information held by another person on your behalf, which is the single most important sentence in this guide for anyone deploying a third party voice AI platform. Your vendor's systems are, for freedom of information purposes, an extension of your own filing cabinet.

Can an FOI request reach data held by our voice AI vendor?

Yes, and this is where most public authorities go wrong. Section 3(2)(b) of the Freedom of Information Act says information is held by a public authority if "it is held by another person on behalf of the authority". Dilr.ai reads that plainly: recordings, transcripts and configuration a voice AI vendor stores for a public authority are within FOI scope, reachable through the authority even though the vendor is not itself bound by the Act.

This has a hard practical consequence. If your contract with the voice AI provider does not give you a fast, reliable way to retrieve recordings, transcripts and system logs, you have not reduced your FOI exposure, you have only made it harder to meet. An authority that cannot get its own operational data out of a vendor's platform in time will still be judged against the twenty-working-day deadline. The right place to fix this is the contract and the integration design, not the FOI officer's inbox three weeks into a request. Our AI placement diagnostic exists to surface exactly this kind of retrievability gap before a system goes live, not after a regulator asks why a request was late.

It is also why voice AI procurement for a public body is different from the private sector version of the same conversation. A commercial buyer optimises for cost per resolution and containment. A public authority has to add a column: can we extract what we will be legally required to disclose, in the format and timeframe the Act demands, without depending on the vendor's goodwill. That is a design requirement, and it belongs in the DATS methodology from the first workshop, not bolted on at go-live.

What information about a voice AI system can an FOI request reach?

An FOI request can reach almost any recorded information a public authority holds about its voice AI line: the contract and its value, procurement documents, measured error and containment rates, complaint volumes, the categories of decision the AI is allowed to make, and the recordings and transcripts themselves. Dilr.ai advises public authorities to assume anything they record about the system is potentially disclosable, then rely on the Act's specific exemptions rather than the hope that no one asks.

That list unsettles people, because a lot of it is information a vendor would rather keep quiet. Performance data is the obvious example. If your voice AI resolves fewer calls than the business case promised, that gap is recorded information, and a journalist, a councillor, a campaign group or a competitor can ask for it. So can the decision logic: which callers the system is permitted to handle end to end, and which it must hand to a person. The honest position is that a public deployment is a public deployment, and the operational data that comes with it is part of the record.

There is a real tension here, and it is the crux of building voice AI in the public sector. The authority has a transparency duty. The vendor has legitimate trade secrets and commercial interests. The Act does not resolve that tension by hiding everything, and it does not resolve it by disclosing everything. It resolves it through named exemptions, applied case by case, most of them subject to a public interest test. Which is the next question.

Which exemptions protect trade secrets and third parties?

Two exemptions do most of the work for voice AI. Section 43 of the Freedom of Information Act protects trade secrets and information whose disclosure would prejudice commercial interests, covering a vendor's proprietary methods and pricing. Section 40 protects third parties' personal data where disclosure would breach the data protection principles. Dilr.ai stresses that both apply information by information, not as a blanket shield: the authority must still disclose operational data that carries no such protection.

Section 43 is where vendor trade secrets live, but it is not a magic word. Much of it is a qualified exemption, meaning the authority must weigh the public interest in disclosure against the harm to commercial interests. A blanket "the whole contract is commercially confidential" will not survive scrutiny; the Information Commissioner's Office has consistently pushed authorities to disclose contract values, service levels and performance metrics even where genuinely proprietary technical detail is withheld. The lesson for deployment design is to keep the genuinely secret material, model weights, proprietary prompts, source configuration, separate and clearly labelled, so that disclosing the operational record does not force disclosure of the vendor's intellectual property.

Section 40 handles the personal data of callers and staff caught up in recordings. Note the split: a request for the requester's own personal data is exempt from FOI and handled as a subject access request, while third parties' personal data is exempt where releasing it would breach the UK GDPR. This is not a licence to withhold a whole recording because one name appears in it. Redaction is the expected tool, and a well-designed voice AI programme keeps transcripts in a form that can be redacted quickly rather than as opaque audio no one can search.

How long do we have to respond, and what happens if we get it wrong?

A public authority must respond to a freedom of information request promptly, and within twenty working days at the latest. Dilr.ai flags this as materially tighter than the one month a subject access request allows, with no general extension for complex requests of the kind data protection law grants. Miss it and the requester can escalate to the regulator, which can order disclosure. The Act sets the deadline out in plain terms:

"Subject to subsections (2) and (3), a public authority must comply with section 1(1) promptly and in any event not later than the twentieth working day following the date of receipt."

Freedom of Information Act 2000, section 10(1)

That is materially tighter than the one calendar month a subject access request allows, and there is no general "complex request" extension of the kind the UK GDPR grants, though a fees notice or a public interest test can pause or extend the clock in limited ways. Miss it, and the requester can complain to the Information Commissioner's Office, which enforces freedom of information in England, Wales and Northern Ireland and can issue a legally binding decision notice ordering disclosure. The ICO has sharpened its focus on public bodies with poor FOI timeliness, publicly committing in late 2025 to hold them to account, so sustained lateness is a genuine enforcement risk rather than a technicality.

The scale is easy to underestimate. Central government's forty-one monitored bodies alone received 83,041 FOI requests in 2024, the most since monitoring began in 2005 and 18% up on the year before, and only 76% were answered in time, down from 81% a year earlier, according to the Cabinet Office's annual freedom of information statistics. That figure counts only those forty-one central bodies. It does not include the thousands of councils, NHS trusts, universities and police forces that make up the bulk of the public sector and handle far more requests between them. If your authority is one of those, the volume landing on your FOI team is not captured in the headline number at all, and a voice AI line that generates its own steady stream of questions only adds to it. Sustained lateness is what draws an ICO audit or intervention, and the operating model you put around the system is what keeps you on the right side of the deadline.

How should a public authority build a voice AI deployment to be FOI-ready?

Build for retrievability and separation from day one. Dilr.ai's advice to public authorities is to design the deployment so that the operational data an FOI request will ask for, contract terms, performance metrics, decision logic and searchable transcripts, can be pulled quickly, while the vendor's genuine trade secrets are stored and labelled separately. FOI-readiness is an architecture and records-management decision made before go-live, not a task handed to an FOI officer once a request has already arrived.

In practice that means a short, concrete checklist. First, contract for data return: a clause that guarantees the authority can retrieve recordings, transcripts and logs on demand and in a usable format, because section 3(2)(b) puts vendor-held data in scope whether or not you can easily get it. Second, log what you will be asked for: containment rates, error rates, escalation rules and complaint counts, in a place your own team controls. Third, separate the disclosable operational record from the exempt technical configuration, so a routine request does not force a trade secret decision. Fourth, keep transcripts searchable and redactable rather than as raw audio. Fifth, write down which decisions the AI makes, because that is one of the first things a serious requester will ask.

The same separation logic underpins our AI operating model consulting, where governance, records and disclosure workflows are designed together rather than retrofitted. For a public authority, the operating model is not a nicety; it is the difference between a system you can be transparent about and one that becomes a standing FOI liability.

None of this removes the duty, and it is worth being blunt about the limit of what a supplier can do. Dilr.ai can help a public authority design a voice AI deployment that is answerable to freedom of information; it cannot discharge the authority's statutory duty, and no vendor can. The obligation to respond, to apply exemptions correctly and to meet the deadline stays with the authority. What good design buys you is the ability to meet that obligation without a scramble, and the confidence that when a request lands you can find, redact and release the right records inside twenty working days. That is the work our AI execution office does alongside public sector teams: turning a compliance requirement into a repeatable process.

What is the best FOI posture for a public authority deploying voice AI in 2026?

The best posture is the lightest deployment that still meets your service goals, built so every record it creates is retrievable and every exemption decision is clean. For a public authority, Dilr.ai judges FOI-readiness on three criteria: can you retrieve vendor-held data on demand, can you separate disclosable operational records from exempt trade secrets, and do you keep transcripts searchable and redactable. A low-volume authority may be better served by a well-signposted human line.

That last point is the honest concession. If your authority handles a small, predictable volume of calls, a full voice AI deployment may expand your FOI surface faster than it improves your service, and a simple, well-logged human line with clear call recording can be the more defensible choice. Voice AI earns its place where call volume is high, the tasks are narrow and repetitive, and the records discipline is already good enough to answer for the system.

On platforms, be clear-eyed. Self-serve tools such as Vapi, Retell AI and Synthflow are built for fast developer deployment and put the entire records and disclosure burden on you. Managed platforms such as PolyAI and our own Dilr Voice can build retrievability, logging and separation into the deployment, which is what a public authority actually needs, but the duty still sits with the authority whichever you choose. The right question is not which vendor is best in the abstract, but which one lets you meet a twenty-working-day deadline without depending on anyone's goodwill. That is the question our approach to placing AI inside public institutions is designed to answer, and the one a short scoping conversation settles before you sign.

Does freedom of information apply to a private company that runs a voice AI line?

No. Freedom of information binds public authorities listed in Schedule 1, not private companies, so a business running its own voice AI line is not directly caught. But there is an exception: if that company holds information on behalf of a public authority, under contract to run its line, that information is reachable through the authority under section 3(2)(b). Supplying the public sector pulls your data into scope even though the Act does not bind you directly.

Is the position different in Scotland?

Yes. Scotland runs a separate freedom of information regime under the Freedom of Information (Scotland) Act 2002, enforced by the Scottish Information Commissioner rather than the ICO. The general right of access and public sector focus are similar, but the statute is distinct and its section numbers and some exemptions differ. A Scottish public authority should work from FOISA and its own guidance rather than assume the Freedom of Information Act 2000 sections in this guide apply.

Deploying voice AI in a public body? See Dilr Voice in action, book an AI placement diagnostic, read our DATS methodology, or see our approach to placing AI inside public institutions.

Written by the Dilr.ai engineering team, practitioners who ship enterprise and public sector AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.