Glean AI and the EU AI Act: A Deployer's Compliance Guide
Glean is enterprise RAG search over your own data, almost always minimal risk under the EU AI Act. The real exposure is permission-mirroring and access control.
A 700-person SaaS company connects Glean across Slack, Google Drive, Jira and Confluence so staff can ask a question and get an answer drawn from their own documents. Is that a high-risk AI system under the EU AI Act? Almost never. Internal enterprise knowledge search is not a listed high-risk category, and for the vast majority of deployers a Glean deployment sits at minimal risk.
That does not mean zero obligation or zero risk. The duties are short — Article 4 AI literacy and an inventory entry — and the real exposure is somewhere most compliance checklists never look: permission-mirroring and access control. Glean's compliance story is data governance, not the high-risk obligation stack.
Is Glean high-risk under the EU AI Act? Almost never
Glean is an enterprise search and retrieval-augmented generation (RAG) assistant. It indexes your own company data — Slack threads, Drive files, Confluence pages, support tickets, wikis — and answers questions by retrieving from that index and synthesising a response. It does not make decisions about people; it surfaces and summarises documents you already hold.
The EU AI Act does not classify tools by name. Under Article 6 and Annex III of Regulation (EU) 2024/1689, a system is high-risk only when its intended purpose falls into a listed category — biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, justice. Internal knowledge search is not among them; there is no Annex III line for "answering questions over your own wiki."
Set your expectation honestly. For the typical deployer, internal Glean use is minimal risk under the Act — no conformity assessment, no Annex IV technical documentation, no EU-database registration. Most general-purpose business AI behaves the same way: productivity assistants, search and RAG tools, internal routing. The realistic duties for that class are Article 4 AI literacy, Article 50 transparency only where output reaches third parties, and data governance.
One upstream note: Glean is built on general-purpose AI (GPAI) models supplied by a model provider, and the Chapter V obligations on those models — Articles 51–55 — sit with that provider.
The real exposure: permission-mirroring and access control
Glean's central design promise is that it inherits and mirrors each user's existing source-system permissions: if you cannot open a document in Drive, Glean will not show it to you. The catch is scale. A unified RAG index surfaces everything a user is nominally entitled to see — instantly, including content they were never expected to find. A document buried fourteen folders deep that nobody has opened in years is just another retrievable source. The permission was always there; the index makes it reachable.
That turns over-broad or stale permissions into an immediate problem. A legacy "all-staff" share on a SharePoint folder, an open-link Drive document, a Confluence space with inherited group access — each becomes a confidentiality exposure the moment a unified index sits on top of it. The permissions were dormant; Glean wakes them.
This is not an AI Act high-risk trigger. It is a data governance and security exposure under GDPR Article 5(1)(f) (integrity and confidentiality) and Article 32 (security of processing) — the dominant practical risk for this tool class.
Pre-deployment hygiene
- Audit and tighten source-permission scopes before you connect a system, not after.
- Remove stale shares, orphaned open links and legacy all-staff folders.
- Confirm the index respects source access-control lists in real time, so a permission change propagates rather than serving a cached entitlement.
- Re-run the check after any large content migration, when permissions drift.
The leakage vectors themselves — prompt exposure, retention, training reuse — are covered in the dedicated data-leakage analysis. Confidentiality of enterprise data is the theme; access control is the lever.
Vendor due diligence
Where Glean processes personal data on your behalf, confirm a no-training-on-customer-data commitment, a GDPR Article 28 Data Processing Agreement, and EU data residency or an EU-adequate transfer where processing happens outside the EEA. These are contractual checks, not AI Act conformity steps — but non-negotiable before you index personal data.
Glean risk classification at a glance
The table maps five typical Glean use patterns against the likely EU AI Act tier and governing provision — and shows the one edge that breaks the minimal-risk pattern.
| Use pattern | Likely tier | Governing provision |
|---|---|---|
| Internal knowledge search / Q&A over company docs | Minimal risk | No mandatory stack; data governance + Article 4 apply |
| AI-generated answers or summaries shown only to internal staff | Minimal risk | Article 50 not engaged — output stays internal |
| Glean output surfaced to external parties (customer portal, partner answers) | Limited risk for that path | Article 50 transparency engaged for the external output |
| Glean output wired into a decision about a person (e.g. recruitment screening) | High-risk workflow | Annex III point 4 — the workflow, not the search tool |
| Glean used purely to retrieve and cite source documents | Minimal risk | No Annex III category; data governance applies |
The stand-alone high-risk obligations under Article 6(2) do not attach to internal search — only to a high-risk workflow engineered on top, and even then it is the workflow that is classified, not the retrieval engine.
What you actually owe as a Glean deployer
The obligation set for a normal internal deployment is short, and over-engineering it wastes effort better spent on access control.
Article 4 AI literacy
In force since 2 February 2025. Ensure staff who use Glean understand its capabilities and limits: that answers are synthesised from indexed sources, that retrieval can be incomplete or wrong, and that an answer needs verification against the underlying document before anyone relies on it. This means your people know what the tool is and is not — not a certification programme.
Inventory and record the classification
Enter Glean in your AI register with the vendor, the intended internal use, the minimal-risk determination and the date. Article 26 sets baseline deployer diligence — use the system per instructions, maintain oversight — and recording the classification is the trail even for a minimal-risk tool.
Article 50 transparency — only where output leaves the building
Article 50 applies where AI output reaches third parties or could be mistaken for human-authored or interactive content. Internal answers shown to your own staff do not trigger a labelling duty; wire Glean into a customer-facing portal or partner answers, and you label the output for that path only. For purely internal search — the normal case — there is no disclosure notice to add.
Data governance and access control
This is the substantive workstream: permission audits, least-privilege source connectors, logging and retention review, and a confidentiality policy for sensitive repositories.
Worked example
Meridian Cloud, a 700-person EU B2B SaaS company, connects Glean across Slack, Google Drive, Jira and Confluence. Classification lands at minimal risk — internal knowledge search, no Annex III category. The binding work is a permission audit, which finds a legacy "all-staff" Drive folder of HR documents — signed offer letters, a salary band sheet — locked down before go-live. They run a 20-minute Article 4 module for all 700 staff, add a register entry with the minimal-risk finding and date, and sign a Glean DPA with EU data residency confirmed. No high-risk stack, no Fundamental Rights Impact Assessment — the dominant deliverable was a folder nobody knew was open.
The 'high-risk' edge cases — and the timeline that governs them
Glean only approaches high-risk if a deployer wires its output into an Annex III decision — for example employment screening under Annex III point 4 (4(a) recruitment, 4(b) in-employment). Even then it is the screening workflow that is classified high-risk, not the search tool underneath it.
If you build such a workflow, Article 25 matters: a deployer becomes a provider — inheriting provider obligations — if it puts its name on a high-risk system, makes a substantial modification, or repurposes a system so it becomes high-risk. Pointing Glean's retrieval at a decision about a person is exactly that kind of repurposing; internal search is not.
On timing, the stand-alone Annex III high-risk obligations under Article 6(2) now apply from 2 December 2027, deferred from the original 2 August 2026 by the Digital Omnibus — adopted by the European Parliament (16 June 2026) and the Council (29 June 2026), entering into force on Official Journal publication expected before 2 August 2026. The deferral is a set of fixed calendar dates, not a "stop-the-clock" mechanism.
For a normal internal Glean deployment, none of these deadlines apply: the only live, in-force duties remain Article 4 AI literacy (since 2 February 2025) and data governance.
How Confir helps
Add Glean to your inventory and Confir's classification engine asks how you use it — role, data sources, who sees the output — then maps the internal-search use to the correct tier. For the normal case it returns minimal risk, surfaces the short real obligation set (Article 4 literacy, a register entry, the data-governance workstream), and produces a dated, auditable classification record. Describe wiring output into an Annex III decision, and it flags the Article 25 role shift instead.
The engine is deterministic and rule-based — no model inference, no hallucination. The same intake produces the same finding, and the rule that fired is written in plain language so any reviewer can check why Glean landed where it did.
Frequently asked questions
Is Glean AI high-risk under the EU AI Act?
Almost never. The EU AI Act classifies systems by intended purpose, not by product name, and internal enterprise knowledge search is not an Annex III high-risk category (Article 6, Annex III). For the typical deployer using Glean to search and answer questions over its own Slack, Drive and wiki content, the deployment is minimal risk — no high-risk obligation stack attaches. The realistic duties are Article 4 AI literacy and data governance, not the full high-risk compliance regime.
What does Glean's permission-mirroring actually mean for compliance?
Glean inherits each user's existing source-system permissions, so it only shows people what they could already access. The compliance catch is scale: a unified index surfaces everything a user is nominally entitled to see, instantly. If your Drive or SharePoint permissions are stale or over-broad, Glean will surface documents nobody expected staff to find. That is not an AI Act high-risk trigger — it is a data governance and GDPR Article 5(1)(f) and Article 32 security exposure, the dominant practical risk for this tool class.
Do I need to do anything under the EU AI Act before deploying Glean?
Yes, but the list is short. Provide Article 4 AI literacy so staff understand Glean's answers are synthesised and need verification (in force since 2 February 2025). Record Glean in your AI register with its intended internal use and minimal-risk classification as baseline Article 26 deployer diligence. Run a source-permission audit before enabling it broadly. None of the high-risk obligations apply to normal internal search — do not over-engineer compliance for a minimal-risk tool.
Does Article 50 transparency apply to Glean?
Only where Glean's AI output reaches third parties or could be mistaken for human-authored or interactive content. Internal answers shown to your own staff do not engage Article 50. If you wire Glean into a customer-facing portal or partner-facing answers, label the AI-generated output for that path. For purely internal knowledge search — the normal case — Article 50 is not triggered, and you do not need a disclosure notice on staff search results.
Who handles the GPAI obligations for the models behind Glean?
The general-purpose AI model provider does, not you. Chapter V obligations (Articles 51–55) — technical documentation, downstream information, copyright policy, training-data summary — sit with the model provider and have applied since 2 August 2025. As a deployer of the Glean application you are a deployer under Article 26, not a GPAI provider, so you benefit from upstream compliance without inheriting those provider duties.
Could using Glean ever make my organisation a provider of a high-risk system?
Only if you build a high-risk workflow on top of it. Under Article 25 a deployer becomes a provider if it puts its name on a high-risk system, makes a substantial modification, or repurposes a system so it becomes high-risk. Internal search does not do this. But if you wired Glean's output directly into, say, recruitment screening (Annex III point 4), that workflow could become high-risk and you could take on provider obligations. For normal knowledge search, this does not arise.
When are the high-risk deadlines, and do they affect Glean?
For normal internal Glean use they do not — there is no high-risk obligation to meet. If you engineered a stand-alone Annex III workflow on top, obligations now apply from 2 December 2027, deferred from the original 2 August 2026 by the Digital Omnibus, adopted by the European Parliament and the Council in June 2026 and entering into force on Official Journal publication expected before 2 August 2026.
Related guides
- build your EU AI Act AI inventory
- Microsoft 365 Copilot risk and deployer duties
- AI data-leakage risk and controls
- detect and govern shadow AI
- Article 50 transparency requirements
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 14-day free trial.
Start free trial →