Product updates
Zero data retention for AI in fullhall
Zero data retention is now required for every AI request in fullhall. The rule applies to the model provider handling the request, including any backup provider we use. It went live on 22 September.
Bishal Sapkota · Founder, fullhall
· 3 min read
Choosing who handles the request
If you ask the assistant to turn a few notes into an event description, those notes go to a model to get an answer. Choosing who handles that request is my responsibility as the person building the app.
I want that choice to be easy to explain. fullhall now sends AI requests only to endpoints with a zero data retention policy. If none of our approved providers can meet that requirement, the request stops.
What zero data retention means here
Zero data retention, usually shortened to ZDR, concerns what a model provider keeps after processing a request. Under a ZDR policy, the provider does not retain the prompts or responses, including for model training.
Retention and training are separate questions. A provider can rule out training while still keeping request content for other purposes. We now require ZDR on every request through OpenRouter, which routes requests to the companies running the model.
OpenRouter classifies individual endpoints by their policies. Its ZDR definition permits in-memory prompt caching. The OpenRouter ZDR documentation explains that scope and how the routing restriction works.
Source: OpenRouter ZDR documentation
The same rule applies to backup providers
We have moved the assistant to DeepSeek V4.1 Flash. Requests go through OpenRouter with DeepInfra first, then Fireworks and Together as backups.
Those names are an allowed list. fullhall also requires the selected endpoint to qualify for ZDR and denies routing to providers that collect request data. A provider appearing on the list is not enough on its own.
That matters when something goes wrong. If DeepInfra is unavailable, OpenRouter can try an eligible endpoint at Fireworks or Together. It cannot keep looking beyond that list for somewhere else to send the request.
If none can handle it under our rules, you will get a failed request. That is a trade-off I am comfortable making. Provider availability should not quietly change the retention policy for your request.
What stays in fullhall
Your assistant conversation history still stays in fullhall so you can return to it. The event description and page content you save remain part of your event.
The ZDR requirement covers the external model endpoints processing AI requests. It does not delete your records from fullhall or change how saved conversations work.
It also does not specify the country where a model runs. This update makes no Australia-only processing claim.
Already in use
The restriction lives in the shared code used to create every AI request, so assistant steps and retries use the same policy. We tested the outgoing requests and checked that rejected routing could not trigger an unrestricted retry. We also ran a synthetic request in production to confirm the deployed model could answer under these rules, without sending customer content.
There is nothing to switch on in your organisation. The next time you use the assistant to work on an event page, these requirements apply automatically.
Product update released on 22 September 2026. Provider policy documentation reviewed on the same date.
Keep a good thing going.
Volunteering · 4 min read
Volunteer workload: make the next event a smaller ask
Committee life · 4 min read