In government and healthcare, the stakes are different. It is not a customer name, but a national ID number, a benefits file, or a patient record. This is data of the highest sensitivity, and the rules are strict to match. The BIO and NEN 7510 set those requirements. Neither mentions AI, but both apply the moment a staff member puts such data into an AI tool.
BIO and NEN 7510 in short
The BIO (Baseline Informatiebeveiliging Overheid) is the shared information security baseline for Dutch central government, municipalities, provinces, and water authorities. NEN 7510 is the Dutch standard for information security in healthcare, complemented by NEN 7512 and NEN 7513 for trust in electronic communication and logging of access to patient records. Both are based on ISO 27001 and translate it to their sector.
The common thread: sensitive data must be carefully classified, protected, and processed only by those allowed to, in an environment suited for it.
Why AI adds risk here
Citizen and patient data is often special-category personal data, such as health data, with extra protection under the GDPR. The AI risk is familiar: a staff member wants to help quickly and pastes too much context into a chatbot. The Dutch data protection authority described a case at a municipality where, in a one-month sample, CVs, care files, and internal reports turned out to have been put into a chatbot. That is exactly the scenario the BIO and NEN 7510 aim to prevent.
The problem is rarely bad intent. It is a useful question with too much traceable data, in a tool that was not approved for that purpose.
The measures that count here
- Classification. Citizen and patient data belongs in the highest sensitivity class. That settles it: such data may not enter a public or personal AI tool.
- Acceptable use. The AI policy must make explicit what is not allowed: no patient, case, or citizen data in unapproved tools. See enforcing an AI policy.
- Awareness. Staff must know which data never belongs in a prompt. See what you can and cannot share with AI.
- Data minimisation. Often the task works without the traceable data: improving a letter does not need a real national ID or a real diagnosis.
- DPIA. For special-category data and high risk, a DPIA is often required.
Banning alone does not work
The reflex in sensitive sectors is to ban AI. But a ban moves the use to personal phones and accounts, where there is no visibility at all. That creates shadow AI, precisely in the environment where the data is most sensitive. The more durable route is to enable safe use and make the risk visible at the moment it arises.
How BeeSensible fits government and healthcare
BeeSensible highlights sensitive data while someone types in browser-based AI tools, so it can be removed, replaced, or masked before the prompt is sent. For government and healthcare, that is a concrete way to apply classification, awareness, and data leakage prevention at the moment it counts.
An example from healthcare: a staff member wants to rewrite a referral letter and pastes a passage with a name, date of birth, and diagnosis. The sensitive data gets a highlight. The staff member replaces it with placeholders, has the letter improved, and the patient data does not leave the organisation. An example in government: a national ID and a case number in a draft are highlighted and removed before the text goes to an AI tool.
An administrator sees, at an aggregate level, where the risks sit, without reading the content of personal chats. That supports the demonstrability the BIO and NEN 7510 ask for.
The infrastructure BeeSensible runs on is ISO 27001 certified; BeeSensible itself is not. BeeSensible does not replace your BIO or NEN 7510 work, but it makes the most important measure workable in a sector where the data gets no second chance.
Further reading: Compliance and AI and GDPR and AI measures.
