Privacy

Applies to everything we run

Who we are

AlfaGov Ltd, Ormeau Baths, Belfast. We are a supplier to government, not part of government. For questions about this page, or to make a request about your own data, write to john@alfagov.ai.

Where it runs

Our products run on Microsoft Azure in the UK South region. Inference runs through Azure AI Foundry on regional model deployments, so prompts and the text they generate stay in the United Kingdom. We do not transfer product data outside the UK. We do not use customer content to train models.

Who processes what

Where you are a customer, you are the controller of the programme material you put into a product and we are the processor. The terms of that are in the contract, not on this page. Microsoft is our sub-processor for hosting and inference. Where a development partner needs access to an environment, that access is governed by contract, is limited to what the work requires, and is not open-ended. The current list of sub-processors forms part of the contract and we will provide it on request.

Your rights

Under UK data protection law you can ask what personal data we hold about you, have it corrected, ask for it to be deleted, or object to how it is handled. Write to the address above and we will respond within one month. If you are not satisfied you can complain to the Information Commissioner’s Office.

What we hold ourselves to, and what we do not yet

We hold Cyber Essentials. We do not hold ISO 27001 or ISO 42001, and we will not imply otherwise. Access to Azure resources is by managed identity rather than stored keys and passwords, data-plane resources sit behind private endpoints, and every AI-assisted output is logged against the prompt version that produced it. None of that is a certification, and a buyer should treat it as a description rather than an assurance.

The products

This covers the strategic case product and the products in development. Sign-in uses Microsoft Entra ID, so we hold the identifier, name and email address your organisation’s directory releases to us, and nothing else about you as a person.

What the product holds is whatever your programme puts into it: the documents you upload and the text extracted from them, the conversations you have with the facilitation exercises, the case material produced, and a log of each AI call made on your behalf. Programme documents routinely contain named officials, commercial detail and options that have not been announced. Treat what you upload accordingly, and apply your own classification rules — we do not currently hold a security classification that would let us say a product is suitable for material above OFFICIAL.

One field deserves naming because it is the one most likely to catch a DPIA. Follow-up tasks have an “assigned to” field that is free text, so it is capable of holding a colleague’s name. If you put a third party’s details there, you are the controller for that, and you should be satisfied you have a basis for it.

Deleting a case deletes its documents, conversations, extracted text and generated material. The call log survives with the case reference removed, because an audit trail that can be edited by the person it audits is not an audit trail. We do not yet operate a time-based retention schedule; retention is set in the contract. If you need a specific retention or deletion commitment, ask for it and we will put it in writing rather than leave you to infer it from this page.

This site

alfagov.ai is a set of static pages. There is no account to create and nothing here asks you for a name or an email address. There is no analytics script and no tracking script — we do not know who reads this site or what they read on it.

Nora

Nora, the bereavement prototype, holds a conversation against a session cookie rather than against you. The conversation is not linked to your name, your email address, or any other identifier — only to that cookie, in your browser. You can clear it from within the conversation at any time; look for “Finish and clear this conversation” on Nora’s page.

Nora never contacts anyone on your behalf. She drafts; you send.

The planning agent, when you install it

The P3 planning agent is not something we run for you. You install it in your own Microsoft 365 tenant, under your own app registration, signed in as your own delegated user. That makes you the data controller for what it writes.

It needs a server, and you are the one who stands it up. The agent is a Copilot plugin pointed at an address you choose — the PLANNING_AGENT_URL in the app package you build — and that address has to be a running Next.js application you host. There is no version of this where no server is involved. When a teacher signs in, Microsoft issues an access token, and that server receives it and calls Microsoft Graph with it to read and write on the teacher’s behalf. Every read and every write goes through it.

The point is not that the token avoids a server. It is whose server it is. That one is yours: your infrastructure, your app registration, your tenant. AlfaGov does not run it and receives nothing from it — no token, and nothing from anyone’s OneDrive or calendar. We publish the source; you run it.

What it can reach is fixed and narrow. It requests four delegated Microsoft Graph scopes — User.Read, Calendars.ReadWrite, Files.ReadWrite and offline_access — and every scope is delegated, never application: none of them ends in .All, so the agent can only reach what the signed-in teacher can already reach, never another person’s mailbox, calendar or files.

Every outbound request the agent makes is checked against an allowlist of exactly two Graph paths: the teacher’s own calendar and their own OneDrive. Anything else — sending mail, reading another user, touching a group, forwarding a calendar event — fails against that allowlist rather than relying on review to catch it.

Calendar events the agent creates carry no attendees, because an event with an attendee makes Microsoft send that person an invitation. The agent never contacts anyone; it drafts a week of lessons for the teacher to review, and only the teacher decides what gets written.

It holds no pupil data of any kind — no name, no work, no response, no attainment, no need, no characteristic — and there is no field in it for one.

One limit belongs here too, because it shapes what a teacher might type into it. The agent’s safeguarding check is a keyword filter: it catches direct statements and misses indirect disclosure, and it points to your own designated teacher rather than handling anything itself. It is a floor, not a safeguard. The case study sets out the rest.

What happens to the token

One of the four scopes is offline_access, which asks Microsoft for a refresh token — a credential that keeps working after the access token expires, until it is revoked or itself expires. A data protection officer is right to ask where that lives. Here is what the code actually establishes, and where it establishes nothing.

The prototype does not store either token. It has no token store, no database, and no cache — search the source and there is nowhere for a token to be written. The sign-in route’s own callback page says as much on screen: it reports whether a refresh token was issued and confirms it has not been kept. The token arrives with each request, is used for that request, and is gone when the process has finished with it. Nothing survives a restart.

That is a property of a prototype, not a retention policy, and it cuts both ways: because nothing is stored, the agent cannot act between conversations, and there is no long-lived credential sitting in a store waiting to be stolen. If you build on this and add storage so it can, where that credential lives and how long it is kept becomes your decision to make and your policy to write. We have not made it for you.

There is a gap in how the agent reads that token, and it is named rather than papered over. It has two routes — one that drafts a week and one that writes it — and neither verifies the token's signature. Both decode it without checking who signed it, read the identity claim out of it, and trust it for nothing else. A hosted service would check that signature against the tenant’s signing keys before anything else happened. Neither route does.

What that gap reaches is different on each. On the drafting route the claim keys a per-teacher rate limit, so a forged token could reset someone’s own quota — a spend problem rather than a data one. On the writing route it decides only whether to answer at all: the token itself is passed to Microsoft Graph unchanged, and Graph validates the signature, audience and expiry properly. A forged token is refused there, so nothing is written to anyone’s OneDrive or calendar. Every actual read and write goes through that same check, so what the agent can reach stays what is set out above.

Ending access does not depend on any of that. Revoking consent in Microsoft Entra, or removing the app registration, ends what the agent can reach — immediately for anything new, and for existing tokens as Microsoft’s own revocation takes effect. Because every scope is delegated, revoking a teacher’s consent ends it for that teacher; removing the registration ends it for everyone. The kill switch is separate and blunter: an environment variable pauses the agent without touching consent at all.