Shadow IT and unapproved AI tools at universities: how to find, triage and approve them

Every university runs software that central IT has never reviewed: free AI assistants, browser extensions, survey tools paid for from a grant, transcription bots that join meetings. This guide explains why that happens, what the GDPR and NIS2 risks are, how to find the tools with the admin consoles you already own, and how to build an approval process that researchers will actually use.

Published 9 October 2026 · Sources checked 9 October 2026

Also available in: Svenska · Nederlands · Norsk · Suomi · Dansk · Français · Español · Português

1. What is shadow IT, and what is shadow AI?

Shadow IT is software, cloud services or hardware used for university work without passing through the institution's normal review by IT, information security, data protection and procurement. Shadow AI is the part of it that involves AI services: chatbots, writing assistants, meeting bots, transcription, translation and literature tools. Neither term implies bad intent. Most shadow IT starts because someone needed to get a job done.

A research group at the University of Maryland, Baltimore County, which studied shadow IT in higher education through a case study and a survey of IT professionals, describes it as software or hardware in a system or network that lies outside the responsible IT unit's usual review process. The same work lists possible susceptibility factors for related security incidents, including the degree of IT decentralisation and the institution's attitude towards shadow IT.

In a European university, typical examples include:

• a lecturer using a free AI quiz generator with a class list;
• a research group running interviews through a consumer transcription app;
• a department paying for an online survey tool on a purchase card;
• a "sign in with Microsoft" or "sign in with Google" app that a member of staff granted access to their mailbox, calendar or files;
• a browser extension that reads every page the user opens in order to correct grammar or summarise text;
• an AI meeting assistant that joins online meetings and records them.

2. Why shadow IT is endemic in universities

Universities are among the most decentralised organisations in Europe. That is a strength for research and teaching, and the reason why a central approval process will always lag behind what people use.

• Academic freedom and local autonomy. Researchers choose their own methods and tools, and faculties and departments often have their own IT staff and budgets.
• Grant-funded purchases. Research projects buy services from project funds, sometimes through a purchase card or personal expense claim, which may never reach central procurement or the data protection officer.
• Free tiers. Many tools are free for individuals. No purchase means no procurement step, yet the GDPR obligations follow the data, not the invoice.
• Browser extensions and add-ins. They install in seconds, often need broad permissions to read page content, and are invisible to traditional software inventories.
• OAuth consent. In Microsoft Entra ID, Microsoft's documentation states that by default "all users are allowed to consent to applications for permissions that don't require administrator consent". A user can therefore connect a third-party app to their own mailbox without anyone else seeing it.
• AI assistants. Generative AI arrived faster than procurement cycles. Universities responded with guidance and institutional services, but consumer tools remain one browser tab away.
• Visiting researchers, students and external partners. They bring their own tools and accounts, and collaboration across institutions means data flows through services that no single university approved.

Validemic's analysis Shadow IT is also a signal. When many people use the same unapproved tool, it usually means the institution does not offer an acceptable alternative, or the approval process is too slow or too hard to find. Treat discovery results as a list of unmet needs as well as a list of risks.

3. The risks: GDPR, transfers, AI training, security, accessibility, licences, NIS2

The risk is not that unapproved tools are always worse than approved ones. It is that nobody has checked, so nobody can show that the obligations below are met.

GDPR controller duties (Art. 24, 28 and 32)

When staff use a tool for university work, the university is normally the controller for that processing. Article 24 GDPR requires the controller to implement appropriate technical and organisational measures and to be able to demonstrate that processing complies with the Regulation. Article 28(1) says the controller "shall use only processors providing sufficient guarantees", and Article 28(3) requires a written agreement with each processor. Article 32 requires security appropriate to the risk. A free tool accepted with a click-through consumer licence usually has no Article 28 agreement with the university at all, and a record of processing activities (Art. 30) that does not list the tool is incomplete. Our GDPR law page sets out these articles in full.

The Dutch data protection authority (Autoriteit Persoonsgegevens, AP) has drawn the practical conclusion for AI chatbots. In its warning of 6 August 2024 it said: "Often, employees use the chatbots on their own initiative and contrary to the agreements made with the employer." If personal data were entered in that situation, the AP said this means there is a data breach; where chatbot use is organisational policy, "it is not a data breach, but often not permitted by law". Breaches may have to be notified within 72 hours (Art. 33). See our guide to data breach response at universities.

International transfers

Many free tools are run from outside the European Economic Area. Chapter V of the GDPR (from Art. 44) allows transfers only with a transfer tool such as an adequacy decision or standard contractual clauses. An individual who signs up for a consumer service does not put those in place on the university's behalf. Our EU-US Data Privacy Framework guide and the transfer mechanism tool explain the options.

AI training on uploaded data

The AP warned that "Most companies behind the chatbots store all data entered", often without the person entering it realising this. The University of Copenhagen told employees in May 2024 that most generative AI tools store user input and use it to develop their underlying models, and asked staff to use only the institutionally licensed tool. Oxford's AI centre notes that consumer versions require users to monitor the vendor's policy and opt out of training themselves. Plan tiers matter: education and enterprise plans often have different training and retention terms from free plans. Our fact sheets on ChatGPT, Grammarly, Otter.ai, DeepSeek and Microsoft Copilot set out what each vendor documents publicly, by plan.

Security

Unreviewed apps with OAuth access to mailboxes or files are an attack path. Microsoft's own documentation on Defender for Cloud Apps notes that OAuth apps "often behave unnoticed" while holding extensive permissions to data in other apps. Browser extensions can read and change page content, including pages of university systems. Self-built tools are a risk too: the UMBC case study found typical vulnerabilities such as cross-site scripting and SQL injection in an internally built grants management system.

Accessibility

Public universities are generally public sector bodies for the purposes of Directive (EU) 2016/2102 on the accessibility of public sector websites and mobile applications. A tool a lecturer requires all students to use, but that nobody checked for accessibility, can exclude disabled students. See our page on the Web Accessibility Directive.

Licence breaches

Consumer terms are written for individuals. They may limit use to non-commercial or personal purposes, give the vendor broad rights over uploaded content, or forbid uploading material the user does not own. Staff who upload licensed library content, unpublished manuscripts or other people's data may breach the licence or the rights of the authors. Utrecht University's conditions for unapproved AI tools, for example, ask staff not to upload copyright-protected, confidential or proprietary material, or recorded interviews.

NIS2 supply chain duties, where in scope

NIS2 (Directive (EU) 2022/2555) lets Member States bring education institutions into scope, "in particular where they carry out critical research activities" (Art. 2(5)(b)), and research organisations can be in scope in their own right. In-scope entities must take risk-management measures including "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers" (Art. 21(2)(d)), as well as asset management. Services that nobody knows about cannot be covered by those measures. Whether your university is in scope depends on national transposition; our NIS2 guide for universities and the NIS2 law page cover the country position.

AI Act: AI literacy

Under the EU AI Act, as amended by Regulation (EU) 2026/1744, deployers must take measures to support the AI literacy of staff who use AI systems (Art. 4). An institution that does not know which AI systems staff use will find that duty hard to meet. See our AI Act guide for universities.

4. What regulators and sector bodies say

No European data protection authority has issued a rule specific to university shadow IT, but several have published guidance on generative AI that applies directly.

The Swedish national guidelines cover areas beyond data protection, including procurement and labour law, which is a useful reminder that a shadow AI response is not only a data protection project. For the other national authorities, check their AI pages directly; our Nordic AI services guide covers the shared services that national research and education networks offer.

5. How to find shadow IT: seven discovery techniques

Discovery does not need a new product to start. Most universities already hold the data in their identity platform, finance system and network logs. Combine several sources, because each one sees only part of the picture.

Technique 1: OAuth app consent audit in Microsoft Entra ID

In Microsoft Entra ID, every third-party app that a user or administrator has granted access to appears as an enterprise application with its permissions. Microsoft's guide to reviewing permissions granted to enterprise applications explains how to see admin consent and user consent per app. Note one limit: permissions granted by users cannot be revoked from the User consent tab in the portal; Microsoft points to Microsoft Graph or PowerShell for that.

1. Export the list of enterprise applications with delegated permissions, the number of users who consented, and the publisher.
2. Flag apps with access to mail, files, calendars or the directory, apps from unverified publishers, and apps with many users.
3. Change the user consent setting. Microsoft recommends allowing user consent "only for applications that have been published by a verified publisher", and its built-in policy limits this further to permissions you classify as low impact (see Configure how users consent to applications).
4. Turn on the admin consent workflow, so that users who cannot consent can send a request. Microsoft describes it as sending the request by email to admins designated as reviewers, who act on it, after which the user is notified. This becomes the front door to your fast lane.

Changing consent settings only affects future consents; Microsoft notes that existing grants remain unchanged, so the audit and the policy change are both needed.

Technique 2: third-party app access in Google Workspace

Google Workspace administrators manage third-party apps under API controls. Google's help page Control which apps access Google Workspace data describes an accessed apps list showing apps that have accessed Google data, with user counts and requested services, and four access levels for each app: Trusted, Limited, Specific Google data, and Blocked. Administrators can also set what happens to unconfigured apps, restrict high-risk scopes for services such as Gmail and Drive, and let users request access to an app, which then appears for review. Education editions have separate settings for users under 18. Google notes that accessed-app data can take 24 to 48 hours to appear.

Technique 3: single sign-on logs

Sign-in logs from Entra ID, Google or the institution's own identity provider show which service providers people authenticate to, including services connected through identity federation. SSO logs only show tools that use institutional login, so they will not reveal free tools used with personal accounts, but they do show tools used with a university email address on a vendor's own login page when combined with the OAuth audit.

Technique 4: expense and purchase-card data

Ask finance for a yearly extract of card transactions and expense claims with merchant names that look like software subscriptions. Group by vendor and by cost centre. This is often the only way to find paid services bought from research grants. It also tells you who to talk to, because each transaction has a named card holder or claimant.

Technique 5: DNS, proxy and CASB

Aggregated DNS or web proxy logs show which cloud services are reached from the campus network. A cloud access security broker (CASB) adds a catalogue and risk ratings. Microsoft describes Defender for Cloud Apps as using network traffic and an app catalogue to identify apps in use, and evaluating discovered apps against "more than 90 risk indicators". Other CASB products work in similar ways. University networks are open and many people work off campus, so treat this as a sample rather than a complete inventory.

Network and log analysis is processing of staff and student personal data in its own right. Use aggregated data where possible, limit access, set a retention period, inform staff in the privacy notice, and involve the DPO and, where relevant, employee representatives before you start. Our DPIA screening tool helps decide whether a DPIA is needed for the monitoring itself.

Technique 6: ask people

A short, anonymous-by-default survey to departments and research groups often finds tools no log will show: desktop software, tools used on personal devices, and services used by external partners in a project. Ask three questions: which tools do you use for teaching, research and administration that are not on the approved list; what data goes into them; and what would you need from the university to stop using them. Repeat it each year.

Technique 7: browser extension management

On managed devices, browser policies show and control extensions. Microsoft's guide to managing Microsoft Edge extensions with group policies describes ExtensionInstallBlocklist and ExtensionInstallAllowlist (block all with "*" and then allow listed extensions), ExtensionSettings to block extensions that request particular permissions, and runtime_blocked_hosts to stop extensions reading or changing specific sites, such as your student information system. Adding an installed extension to the blocklist disables it without uninstalling it. Chrome offers equivalent policies.

Validemic's analysis A sensible first step is not to block all extensions, which would disrupt research and teaching, but to use runtime_blocked_hosts to keep extensions away from the systems that hold the most sensitive data (student records, HR, finance, health research platforms) and to build an allowlist from what discovery shows is actually used.

Reviewing a vendor right now? Validemic checks the vendor's documents against GDPR and the EU AI Act and cites every finding. Try the demo workspace

6. A triage model by data and integration

Once you have a list, you need to decide where to spend review effort. Two questions do most of the work: what is the most sensitive data the tool will touch, and how deeply does it integrate with university systems? Use your institution's existing information classification where you have one (many universities use three or four classes, for example public, internal, confidential and strictly confidential or "red").

The decision times are planning targets, not legal requirements. Add two modifiers. AI features that generate content about people, evaluate students or make recommendations move a tool up one tier, because the role analysis, training use and AI Act position need checking. A tool that many people already use moves up the queue, because the exposure already exists.

7. A fast-lane approval process

The fast lane exists to make the approved route faster than the unapproved one for most requests. It works only if it is easy to find, asks for little, and gives an answer quickly.

1. One front door. A single short form, linked from the IT service portal, the AI guidance pages and the admin consent workflow message. Utrecht University's AI tool questionnaire, by comparison, takes about 30 minutes to complete.
2. Check for an existing answer. Before any review, check the three lists. If the tool is already approved, or an approved alternative fits, answer the same day.
3. Triage. Apply the data and integration matrix. Record the tier and the reason.
4. Collect vendor evidence once. For Tier 1, the public terms, privacy notice and settings are usually enough. For Tier 2 and above, ask the vendor for the DPA, subprocessor list, transfer mechanism and security evidence. Our free vendor questionnaire builder generates a questionnaire scaled to the tier.
5. Decide with conditions. Most fast-lane outcomes are "approved with conditions": institutional login only, training switched off, no personal data beyond user accounts, named course or project only, review in 12 months.
6. Publish the result. Add the tool to the right list so the next person gets an instant answer. Update the record of processing activities (see our ROPA template).
7. Monitor. Conditions are only as good as the vendor's terms. Watch for subprocessor and policy changes, and re-check when the vendor adds AI features. Our free subprocessor alerts tool can help.

Clarify who decides. At Utrecht, the faculty that uses an approved tool pays for it, usually by buying directly from the supplier. At Cambridge, licensed GenAI tools beyond the central ones are not prohibited but "must be procured in accordance with any applicable procurement policy or process", and the department carries the risk. Both models work if they are written down.

8. Approved, approved with conditions, not approved

The lists are the most visible output of the process and the main tool for changing behaviour. Utrecht University uses exactly three outcomes for AI tools in education: approved, approved with conditions, and disapproved. Approved tools may be used under their terms and the conditions attached to the approval.

Keep the "not approved" list short and factual. A long list of banned tools invites people to look for the next one that is not on it. A short list with clear alternatives does more. For a picture of what other institutions approve, see AI tools approved at European universities, and for policy wording, our AI policy template for universities.

9. How European universities do it

The pages below show the main building blocks in practice: an institutional alternative, data rules tied to classification, a statement on unapproved tools, and a route to request review. They were checked on 9 October 2026.

Validemic's analysis The pattern is consistent across countries: offer a good institutional option first, tie data rules to the existing classification, and say plainly what is not allowed. The part that is published least often is the request route for anything else. Utrecht is a good example of publishing the route, the questionnaire and the possible outcomes.

10. Talking to researchers and teachers

Most shadow IT is created by people trying to do their work well. Communication that treats them as the problem tends to drive use further out of sight. A few principles help:

• Lead with the alternative. "Use UU AI-Chat, Aalto AI Assistant or GPT UiO for this" is more useful than "do not use ChatGPT". Every "not approved" entry should name an alternative.
• Make the rules about data, not brands. The AP's advice is that organisations should make clear to employees which data they are and are not allowed to enter. Rules tied to data classes stay valid when new tools appear.
• Offer a no-blame review. Invite departments to report tools they already use, and review them without consequences for the people who reported them. Discovery data is far more useful when people cooperate.
• Answer fast. Publish a target time for fast-lane decisions and report against it.
• Explain the reason in one sentence. "The free plan uses your input for training and has no data processing agreement" is understood; "not compliant" is not.
• Use existing channels. Research support, the library, teaching and learning centres and faculty IT staff are trusted by academics. Brief them first.
• Connect to research processes. Ask about tools in the data management plan and ethics application, so that tool review happens before data collection, not after.

Training also supports the AI Act duty to take measures for AI literacy. Our GDPR and AI tools in research guide is written for researchers and can be shared directly.

11. Metrics that show progress

Choose a small number of measures you can collect from systems you already have. Report trends, not single numbers.

12. A 90-day plan

This plan assumes a small team with time from IT security, the DPO office and procurement. Adjust the scope to your size.

After 90 days, the work becomes routine: the request form feeds the fast lane, discovery runs monthly, and the lists are reviewed at least yearly. Revoking existing consents and migrating users off not approved tools takes longer and should follow once an alternative is in place.

Sources

1. Regulation (EU) 2016/679 (GDPR), Articles 24, 28, 30, 32, 33 and 44 (retrieved 9 October 2026).
2. Directive (EU) 2022/2555 (NIS2), Articles 2(5) and 21 (retrieved 9 October 2026).
3. Regulation (EU) 2024/1689 (AI Act), Article 4, and Regulation (EU) 2026/1744 (Digital Omnibus on AI) (retrieved 9 October 2026).
4. Directive (EU) 2016/2102 on the accessibility of public sector websites and mobile applications (retrieved 9 October 2026).
5. Autoriteit Persoonsgegevens: Caution: use of AI chatbot may lead to data breaches, 6 August 2024 (retrieved 9 October 2026).
6. IMY: GDPR vid användning av generativ AI, IMY-2024-9162, 5 February 2025 (retrieved 9 October 2026).
7. IMY: National guidelines for generative AI in public administration are launched (retrieved 9 October 2026).
8. CNIL: IA, la CNIL finalise ses recommandations sur le développement des systèmes d'IA, 22 July 2025 (retrieved 9 October 2026).
9. Jisc: Generative AI, a primer, updated 1 February 2024 (retrieved 9 October 2026).
10. Microsoft Learn: Configure the admin consent workflow (retrieved 9 October 2026).
11. Microsoft Learn: Configure how users consent to applications (retrieved 9 October 2026).
12. Microsoft Learn: Review permissions granted to enterprise applications (retrieved 9 October 2026).
13. Google Workspace Admin Help: Control which apps access Google Workspace data (retrieved 9 October 2026).
14. Microsoft Learn: Overview of Microsoft Defender for Cloud Apps (retrieved 9 October 2026).
15. Microsoft Learn: Use group policies to manage Microsoft Edge extensions (retrieved 9 October 2026).
16. UMBC Cyber Defense Lab: Shadow IT in Higher Education: Survey and Case Study for Cybersecurity, 2021 (retrieved 9 October 2026).
17. Trinity College: Higher Education Community Vendor Assessment Toolkit (HECVAT) (retrieved 9 October 2026).
18. Utrecht University: Allow-listing process for AI tools (retrieved 9 October 2026).
19. Utrecht University: Conditions of use of AI tools by teachers and educational support staff (retrieved 9 October 2026).
20. Utrecht University: AI platforms at UU (retrieved 9 October 2026).
21. University of Oxford AI Competency Centre: GenAI tool features (retrieved 9 October 2026).
22. University of Cambridge: Data protection guidance on AI (retrieved 9 October 2026).
23. University of Edinburgh: Generative AI guidance for staff (retrieved 9 October 2026).
24. University of St Andrews: Approved AI software (retrieved 9 October 2026).
25. University of Reading: Generative AI and AI meeting assistants (retrieved 9 October 2026).
26. University of Helsinki: Generative artificial intelligence at the University (retrieved 9 October 2026).
27. Aalto University: Aalto AI Assistant (retrieved 9 October 2026).
28. University of Amsterdam: UvA AI Chat (retrieved 9 October 2026).
29. Uppsala University: AI tool for students (retrieved 9 October 2026).
30. KTH Royal Institute of Technology: AI services (retrieved 9 October 2026).
31. University of Oslo: GPT UiO and red data (retrieved 9 October 2026).
32. University of Copenhagen: Three guidelines and a new tool for using AI, 8 May 2024 (retrieved 9 October 2026).
33. Aarhus University: Microsoft 365 for students (retrieved 9 October 2026).

About this page

Sources checked on 9 October 2026. We read the Microsoft and Google administrator documentation, the data protection authority pages and the university pages listed above; the EU legal texts are cited from the Official Journal versions. University pages change often, so check the current version before relying on a detail. Where we give our own interpretation, it is labelled as Validemic's analysis. Decision times in the triage section are planning targets, not legal requirements. This page is general information, not legal advice; national law, works council agreements and your institution's own policies may add requirements, particularly for monitoring staff use of IT. If you spot an error or want to suggest another university example, please contact us and we will correct it.