A university buying a chatbot is not really buying a chatbot. The IT lead running the project has to get a recommendation through a data protection officer, a procurement office and often a deployment review board, and the thing that decides the outcome is the quality of the file, not the quality of the demo.
Most GDPR chatbot guidance is written for a company. Two of its standard answers break in a university, and one of them breaks in a way that fails a review outright.
A few terms first, because the rest of this depends on them. GDPR is the General Data Protection Regulation. A controller decides why and how personal data is processed, which here is the institution; a processor acts on the controller's instructions, which is the chatbot vendor. A DPA, or Data Processing Agreement, is the contract Article 28 requires between them, and a DPO is the data protection officer, mandatory for public authorities under Article 37.
Three more. A DPIA, or data protection impact assessment, is the documented risk assessment Article 35 requires before high-risk processing begins. A DSAR is a data subject access request, a person exercising rights over their own data. SCCs are Standard Contractual Clauses, the European Commission's template terms that make transfers outside the EU lawful.
iShort answer
Two things make a university deployment different. Most EU universities are public authorities, and the final sentence of Article 6(1) removes legitimate interests from public authorities acting in performance of their tasks, so the lawful basis every commercial chatbot guide recommends is unavailable and Article 6(1)(e) public task takes its place. And a student-facing chatbot meets several of the EDPB's high-risk criteria at once, so a DPIA is the expected outcome rather than a judgement call. Age thresholds under Article 8 vary by member state between 13 and 16, so an institution recruiting across the Union spans several. On hosting, SiteGPT processes in the United States under SCCs with Article 27 representatives in the EU and UK, and has no EU residency option and no documented SSO, both of which are procurement blockers at some institutions and not at others.
Five gates, and the evidence each one needs in the file. Note who owns each: the vendor can supply two of the five, and the rest are institutional documents nobody can produce for you.
Lawful basis
Owner: the institution, with the DPO. Evidence: a written determination naming Article 6(1)(e) public task and the national law grounding it, or 6(1)(f) with a balancing test if the institution is private. Source: your own statutes and governing legislation.
Minors
Owner: the institution. Evidence: which member state thresholds apply to your applicant population, and confirmation that Article 8 is engaged only where consent is the basis. Source: Article 8 plus the national implementing law of each relevant state.
DPIA
Owner: the institution, signed off by the DPO. Evidence: an assessment against the nine EDPB criteria, and a prior consultation decision under Article 36 if high residual risk remains. Source: WP248 rev.01, endorsed by the EDPB.
DPA and transfers
Owner: the vendor supplies, the institution signs. Evidence: an executed Article 28 contract, the subprocessor list, the transfer mechanism, and a transfer impact assessment you write. Source: the vendor's legal pages, verified rather than described.
Retention and rights
Owner: shared. Evidence: a retention period written into the contract rather than left at a product default, plus a tested process for finding a named person's conversations. Source: Article 5(1)(e) and Articles 15 to 21.
Key takeaways
| The review board asks | The short answer |
|---|---|
| Can the institution use legitimate interests? | Not if it is a public authority acting in its public task. Article 6(1) removes that basis. |
| What lawful basis instead? | Article 6(1)(e), public task, grounded in the national law that constitutes the institution. |
| What age can a student consent at? | It varies. Article 8 defaults to 16 and lets member states go as low as 13. |
| Is a DPIA required? | Almost certainly. A student chatbot meets several EDPB high-risk criteria at once. |
| Does GDPR require EU hosting? | No. Chapter V requires a valid transfer mechanism, and SCCs are the standard one. |
| Where does SiteGPT process data? | The United States. The subprocessor list names no EU-based subprocessor. |
| Does SiteGPT do Shibboleth or Keycloak SSO? | Not in the published docs. Role-based access for invited members is what is documented. |
What is different about a student-facing chatbot
The population is the first difference. A commercial chatbot talks to self-selected adult visitors, while a university assistant talks to applicants who may be under 18, current students in a position of dependence on the institution, and occasionally parents asking on someone else's behalf.
The second difference is the subject matter. Student services questions do not stay on the safe side of the line: accommodation, hardship funds, disability support, counselling waiting times and visa status all arrive in the same chat window as questions about library opening hours.
The third is the institution's legal character. Most EU universities are public authorities under national law, and GDPR treats public authorities differently in at least three places that matter here: the lawful basis available to them, the mandatory DPO under Article 37(1)(a), and the supervisory authority's power to require prior consultation.
The fourth difference is scale in a specific sense. A mid-sized university runs a single website that serves prospective students, current students, researchers, alumni and staff, so one widget deployed once touches several distinct groups with different expectations and different lawful bases behind them.
That is worth writing down early, because a DPIA that treats all chatbot users as one undifferentiated category tends to come back from the DPO.
Who is the controller, and where the institution's obligations begin
The institution is the controller and the vendor is the processor. Article 4(7) attaches controllership to whoever determines the purposes and means of the processing, and the university decides that the chatbot exists, what content it is trained on and what it is for.
This is not usually contested, but two variants of it cause real problems in practice.
Departmental deployments. A faculty that buys a chatbot on a departmental card is still binding the institution as controller. The obligations land on the university regardless of which budget paid, which is the strongest argument for a central register of these tools before the first one is discovered during an audit.
Vendor use of conversation content. A processor may act only on documented instructions. If the vendor's terms reserve a right to use conversation content to improve its own models or products, the vendor is acting as a controller for that purpose, and the arrangement no longer matches the contract the institution signed.
Obligations begin at the point of collection, which is earlier than most project plans assume. The privacy notice, the lawful basis determination and the DPIA all have to exist before the widget goes live on a page a student can reach, not before the formal launch announcement, and a pilot with real students is a live deployment for these purposes.
One further point specific to public authorities. Article 37(1)(a) makes a DPO mandatory, and Article 39 gives that person a defined advisory role in the DPIA. Involving the DPO after the vendor is chosen is the most common sequencing error in these projects, and it is expensive because the lawful basis analysis can invalidate a shortlist.
Lawful basis in an education setting
Article 6 lists six bases. Three are plausible for a student-facing chatbot, and which one applies turns on what kind of institution you are.
Public task, Article 6(1)(e). This is the normal answer for a public university. The wording covers processing "necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller", and it has to be grounded in Union or member state law, which for a university is generally the legislation or charter constituting it and defining its educational mission.
Legitimate interests, Article 6(1)(f), and why it is often unavailable. The final sentence of Article 6(1) states plainly that "point (f) of the first subparagraph shall not apply to processing carried out by public authorities in the performance of their tasks." A public university answering student queries is performing its tasks. Private institutions, business schools and university spin-out companies are in a different position and can rely on legitimate interests with a documented balancing test.
Consent, Article 6(1)(a). Consent is weaker here than in a commercial setting, not stronger. It has to be freely given, and the imbalance between an institution and a student who depends on it for assessment, accommodation and progression makes freely given hard to establish for anything core to the service.
| Basis | When it fits a university chatbot | The trap |
|---|---|---|
| Public task, Art 6(1)(e) | The default for a public institution answering student and applicant questions | The task has to be grounded in national law, so name the instrument rather than asserting the label |
| Legitimate interests, Art 6(1)(f) | Private institutions, spin-outs, and commercial arms of a university | Unavailable to public authorities in their tasks, which is the single most copied mistake in this area |
| Consent, Art 6(1)(a) | Separate purposes layered on top, such as recruitment marketing to prospective students | The institutional power imbalance undermines freely given, and consent has to be withdrawable without breaking the service |
Two consequences follow for the file. If the basis is public task, a data subject has a right to object under Article 21(1) and a right to restriction, but not a right to erasure on the same footing as they would have under consent, so the rights section of the privacy notice differs from the commercial template. And where the chatbot handles special category data, which for a student services deployment realistically includes health and disability information, Article 9 requires a separate condition on top of the Article 6 basis.
Minors, and why the age threshold depends on the member state
There is no single EU age of consent for data processing, and any vendor or guide that quotes one is wrong.
Article 8 sets the default at 16, and then allows that "Member States may provide by law for a lower age for those purposes provided that such lower age is not below 13 years." The result is a spread across the Union, and an institution recruiting internationally is exposed to several thresholds at once rather than one.
The more useful point is that Article 8 is narrower than its reputation. It applies where consent under Article 6(1)(a) is the lawful basis, in relation to information society services offered directly to a child. A public university relying on public task is not operating the Article 8 age gate at all.
That is a relief in one direction and not in the other. Three obligations survive regardless of the basis:
- Article 12 clarity. Information addressed to a child must be in clear and plain language the child can understand. An applicant-facing chatbot notice written for a procurement lawyer does not meet this.
- Heightened risk weighting. Children are named in the EDPB criteria as vulnerable data subjects, which feeds directly into the DPIA conclusion in the next section.
- Recital 38 caution on marketing. The special protection for children applies particularly to marketing and profiling, which is the boundary a recruitment-oriented chatbot is closest to crossing.
Practically, an admissions or open-day assistant is the deployment most likely to reach under-18s, and a chatbot inside an authenticated student portal is the least likely. Splitting the two, rather than running one widget everywhere, is often the simplest way to keep the minors analysis contained.
Do you need a DPIA, and how to decide
Article 35 requires a DPIA where processing is "likely to result in a high risk to the rights and freedoms of natural persons". The operative guidance is WP248 rev.01, endorsed by the EDPB at its first plenary in May 2018, which sets out nine criteria and a working rule that meeting two or more indicates a DPIA is required.
Run a student-facing chatbot against them and the count is rarely one.
| EDPB criterion | Does a university chatbot meet it? |
|---|---|
| Data concerning vulnerable data subjects | Yes. Students are in a relationship of dependence, and applicants may be children. Both are named categories. |
| Data processed on a large scale | Usually. A single widget on the main institutional site reaches the whole applicant and student population. |
| Innovative use of new technology | Usually. Generative AI over institutional content is treated as innovative use by supervisory authorities today. |
| Sensitive data or data of a highly personal nature | Often. Wellbeing, disability, hardship and health queries arrive whether or not the scope invites them. |
| Evaluation or scoring | Only if the assistant profiles or ranks. A pure information assistant does not. |
| Automated decision-making with legal or significant effect | No, for an information assistant. Yes if it starts triaging applications or eligibility. |
| Systematic monitoring | Not normally. A chatbot answering questions is not monitoring a publicly accessible area. |
| Matching or combining datasets | Only where the assistant is joined to student records or the CRM. |
| Preventing data subjects from exercising a right or using a service | No, provided a human route stays open alongside the assistant. |
Three or four of the nine is a typical result before any integration is added, so treat the DPIA as the expected outcome. Deciding it is not required is a legitimate conclusion in narrow cases, but under Article 5(2) accountability the reasoning has to be written down either way, and the version that is never written is the one an auditor finds.
2 of 9
The EDPB's working rule is that meeting two or more of the nine high-risk criteria indicates a DPIA is required, though it is explicitly not a strict threshold and one criterion can be enough. A student-facing chatbot commonly meets three or four before it is connected to anything.
Source: WP248 rev.01, endorsed by the EDPBTwo further steps belong in the file. Article 35(2) requires that the DPO's advice be sought, which for a public institution means a named person and a dated record rather than a general awareness. And Article 36 requires prior consultation with the supervisory authority where the DPIA indicates high residual risk that mitigation does not bring down, so decide explicitly whether that threshold is crossed instead of leaving the question unasked.
Supervisory authorities have started publishing directly on this. The Bavarian data protection commissioner issued orientation guidance on data protection in AI projects in Bavarian public administration, dated 9 July 2026 and addressed to public bodies, alongside a short practice paper specifically on deploying an LLM-backed chatbot. It is a regional document rather than an EU-wide one, and a Bavarian public university falls squarely within its audience, so it is worth reading before writing the DPIA even where it does not bind you.
The procurement pack, DPA, subprocessors, transfers, retention
The procurement pack is where the review board's questions become documents. Four go in it, and only two of them come from the vendor.
The DPA. Article 28 requires a contract governing the processor, covering subject matter and duration, the nature and purpose, the types of personal data, security measures under Article 32, subprocessor authorisation, assistance with data subject rights, and deletion or return at the end. What each clause has to say, and the wording that should stop a purchase, is covered clause by clause in what to look for in a chatbot DPA.
The subprocessor list. Read it for which companies appear, what each does, and which country each operates in, then check it is published rather than available on request. A public list is one the vendor has to keep accurate.
The transfer documentation. The mechanism is the vendor's to state and the transfer impact assessment is yours to write. Ask for the inputs rather than the conclusion: encryption in transit and at rest, access controls, and the vendor's policy on government access requests.
The retention schedule. Conversation transcripts accumulate quietly and university retention schedules are usually written for student records rather than chat logs. Set the period deliberately, write it into the contract instead of accepting a product default, and confirm separately how captured contact details are governed, since lead records routinely outlive every rule written for conversations.
How SiteGPT sits against this. The security page states that a Data Processing Agreement is available for Enterprise customers for GDPR compliance, and the DPA page states the agreement binds only when signed by both parties. Institutions not on Enterprise contact support rather than relying on a self-generated document.
One honest gap is worth naming in the same breath, because a university legal team will find it. SiteGPT publishes its standard HIPAA BAA in full so counsel can read it before a sales conversation, and the DPA text is not published the same way. If your review process needs counsel to read the contract before a shortlist is set, ask for the text early rather than late.
What to ask about hosting, and how to assess a vendor that processes in the US
EU hosting is the loudest claim in this market and the least precise. It is genuinely valuable, and it is not what the regulation requires.
Chapter V permits transfers to third countries where appropriate safeguards are in place, and the European Commission's Standard Contractual Clauses are the standard safeguard. EU hosting removes the transfer analysis rather than satisfying a separate requirement, so a procurement rule that screens on the map alone will reject lawful vendors while admitting arrangements it has not examined.
The precise questions are these:
- Where is conversation content stored, and where is it processed? These can differ, and the second one is where the AI subprocessors sit.
- Which subprocessors see conversation content, and in which countries? An EU-hosted front end calling a US model provider is a transfer.
- What is the transfer mechanism, per recipient? SCCs, an adequacy decision, or Data Privacy Framework certification for that specific company.
- Is there an Article 27 representative in the EU? It is mandatory for non-EU organisations offering services into the Union and frequently skipped.
- Is content used to train models, and are zero-retention endpoints used at the AI layer?
Article 27
SiteGPT has appointed representatives in both regions: Prighter EU Rep GmbH in Vienna under Article 27 GDPR, and Prighter Ltd in London under Article 27 UK GDPR. This is a hard requirement for non-EU organisations offering services into the EU and one of the most commonly missed, so it is worth checking for every vendor on a shortlist.
Source: SiteGPT privacy policyThe honest position on SiteGPT. There is no EU data residency and no regional hosting option. The published subprocessor list names no EU-based subprocessor: Convex and Pinecone run in the United States on AWS, OpenAI and Cohere are United States, Cloudflare is listed as Global, and Paddle is United Kingdom. The privacy policy states that transfers relating to EU, EEA and UK residents rely on the European Commission's Standard Contractual Clauses and, where the provider is certified, the EU-U.S. Data Privacy Framework.
If your institution's rules impose EU-only storage as a hard requirement, that decides it, and vendors built for European higher education meet it in ways worth acknowledging plainly. StudiAssist, for example, states exclusive EU-based hosting, individual DPAs and technical and organisational measures, and says student chat content is never stored. That is a real advantage for an institution whose procurement rules are written that way.
It is also worth applying the same scrutiny to vendors that market EU hosting less precisely. Tidio's GDPR page states that data is mainly processed within the EEA and on servers located there, then notes that Tidio LLC is a US-based entity and that some data may be transferred from the EEA or the UK and processed in the United States, relying on SCCs, the UK IDTA and the EU-US Data Privacy Framework. That is a defensible arrangement, and it is not the same claim as EU-only processing.
On the certification wording. SiteGPT's security page states "Certified compliant with EU General Data Protection Regulation by DPLMC International". Treat that as a third-party attestation and supporting evidence, here and with every vendor, because a formal certification under Articles 42 and 43 requires a body accredited by a supervisory authority or a national accreditation body and almost no vendor on a typical shortlist holds one. The load-bearing items for the file are the signed DPA, the transfer mechanism, the subprocessor list, the Article 27 representatives, and the SOC 2 Type II report, which was completed with zero exceptions noted across all tested controls.
Integration realities, SSO, the VLE, and the service desk
This is the section where a compliance-clean vendor can still fail the deployment, and where the difference between a general-purpose product and one built for higher education shows up.
Single sign-on. Vendors selling into European universities lead with Shibboleth and Keycloak because federated identity is the assumed baseline for anything touching a logged-in student. SiteGPT does not publish support for it. The documented access model is role-based access for invited team members, with scoped bearer tokens and an OAuth device flow for the API and CLI, and there is no documented SAML, OIDC, Shibboleth or Keycloak integration. Treat that as unmet and confirm the current position directly rather than inferring it.
The scope of the gap depends on the deployment. For a public information assistant on the prospectus and student services pages, which is unauthenticated by design and the most common first project, SSO is not in the path. For a personalised assistant inside an authenticated portal, it is a blocker.
The VLE. There is no native Moodle, Canvas or Blackboard integration. What exists instead is content ingestion from websites and sitemaps, file uploads, and connected sources including SharePoint, Google Drive, OneDrive, Dropbox, Box, Notion, Confluence and GitBook, which covers the way most institutional handbooks, policies and regulations are actually stored. Public course catalogue pages and a policy repository are usually the bulk of what an assistant needs, and both are reachable.
The service desk. Live integrations relevant to a university helpdesk include Zendesk, Freshdesk and Freshchat, Slack, Crisp, Google Chat, Zoho SalesIQ and Messenger, plus a WordPress plugin for institutional sites. Intercom, WhatsApp and HubSpot are announced rather than live, so exclude them from an evaluation until they ship.
Escalation to a human. Handoff is on-demand: a student asks for a person and the team is notified, rather than the system inferring distress from sentiment. For a student services deployment that distinction belongs in the DPIA, because a review board will ask what happens when a wellbeing question arrives and the honest answer is that the routing rules and the staffed hours are the control, not the model.
Where the fit is strong. Content coverage is the differentiator that survives this section: ingestion from more sources than most competitors, auto-sync that keeps answers current as regulations and deadlines change through the academic year, 95+ languages for an international student body, and full control of branding so the assistant reads as institutional rather than bolted on.
Pros
- Transfer mechanism is stated publicly: SCCs, plus the EU-U.S. Data Privacy Framework where the specific provider is certified
- Article 27 representatives appointed in both the EU (Prighter EU Rep GmbH, Vienna) and the UK (Prighter Ltd, London)
- Subprocessor list is public and specific, naming each company, its function and its country
- Content ingestion covers where universities actually keep policies: SharePoint, Google Drive, OneDrive, Confluence, GitBook, Notion, plus sitemaps and file uploads
- Auto-sync keeps answers current across an academic year of changing deadlines and regulations, and 95+ languages suit an international intake
- SOC 2 Type II completed with zero exceptions noted, with reports available through the trust portal for Enterprise
Cons
- No EU data residency and no regional hosting option, which is a hard blocker where procurement rules require EU-only storage
- No documented SSO: no SAML, OIDC, Shibboleth or Keycloak, against competitors that treat federated login as standard for education
- No native VLE integration for Moodle, Canvas or Blackboard; content comes in through crawling, uploads and cloud storage instead
- The DPA is executed for Enterprise customers, and the DPA text is not published for counsel to pre-read the way the standard BAA is
- GDPR compliance rests on a third-party attestation by DPLMC International rather than an accredited certification under Articles 42 and 43
- Nothing scans training content for personal data, so reviewing handbooks and policy documents before ingestion is an institutional task
A checklist for the deployment review board
| Scenario | Best pick | Why |
|---|---|---|
| Lawful basis determined in writing, DPO consulted | Before procurement | Article 6. For a public institution this is normally 6(1)(e) public task naming the national law that grounds it, because 6(1)(f) is withheld from public authorities in their tasks. Doing this after the shortlist can invalidate the shortlist. |
| DPIA completed against the nine EDPB criteria | Before launch | Article 35. A student-facing assistant commonly meets three or four criteria, so plan for the assessment. Record the Article 36 prior consultation decision explicitly rather than leaving it unasked. |
| Minors analysis covering every relevant member state | Before launch | Article 8 defaults to 16 and permits national floors as low as 13. Confirm whether consent is even the basis, and hold the Article 12 plain-language duty regardless. |
| Scope decision on which topics the assistant answers | Before launch | Keeps Article 9 special category data out of the assistant by design. Route counselling, disability assessment and safeguarding to humans, and write the routing rule into the DPIA. |
| DPA signed by both parties | Before launch | Article 28. A generated but unsigned document is not an executed contract, and the processing is non-compliant until it is. |
| Transfer mechanism identified per recipient, TIA written | Before launch | Chapter V plus Schrems II. Name the mechanism for each subprocessor rather than the arrangement as a whole, and confirm the Article 27 representative exists. |
| Privacy notice updated and linked from the widget itself | Before launch | Articles 13 and 14. Name the vendor as a recipient, state the safeguard, give the retention period, and list rights, including the Article 21(1) objection right that comes with public task. |
| Retention set contractually, DSAR search tested by person | Before launch | Article 5(1)(e) and Articles 15 to 21. Test a search naming a student rather than a conversation ID, and confirm captured contact records are covered by a rule too. |
| AI disclosure visible in the interface | Before launch | AI Act Article 50 requires making clear that a person is interacting with an AI system. Cheap to implement and conspicuous when missing. |
| Training content reviewed for personal data before ingestion | Before launch | Anything the assistant retrieves from, a student can reach indirectly. Staff contact sheets and case examples hide inside policy documents, and nothing scans for them automatically. |
One note on the AI Act, because review boards now ask. A chatbot that answers questions about deadlines, accommodation and course structure is not high-risk under Annex III. What Annex III captures in education is AI used to determine access or admission, to evaluate learning outcomes, to assess the appropriate level of education, and to monitor or detect prohibited behaviour during tests. The Article 50 transparency obligation applies to the assistant either way, and the risk to manage is scope drift, because the same deployment moves into Annex III territory the moment it starts triaging applications or assessing eligibility.
Best forEU institutions that can evaluate a transfer mechanism on its merits rather than screening on hosting location, and whose first deployment is a public information assistant across institutional content rather than a personalised assistant behind federated login.
For the layer beneath this post, start with what GDPR actually requires of a website chatbot and then what to look for in a chatbot DPA.
Frequently asked questions
Can a public university rely on legitimate interests for a student chatbot? Usually not. The final sentence of Article 6(1) states that point (f) does not apply to processing carried out by public authorities in the performance of their tasks. Most EU universities are public authorities under national law, so the lawful basis that fits a commercial support chatbot is unavailable to them for their core activity. The normal basis is Article 6(1)(e), performance of a task carried out in the public interest, which has to be grounded in Union or member state law. Private institutions and university spin-outs are in a different position and can rely on legitimate interests with a documented balancing test.
What age can a student consent at under GDPR? There is no single EU age. Article 8 sets 16 as the default and allows member states to legislate a lower age, provided it is not below 13, so the threshold varies across the Union and an institution recruiting internationally will span several. Article 8 is also narrower than it looks: it applies where consent under Article 6(1)(a) is the lawful basis for an information society service offered directly to a child. A university relying on public task is not applying the Article 8 age gate, though the Article 12 duty to communicate in clear and plain language a child can understand still applies to anything an applicant reads.
Does a university chatbot need a DPIA? Normally yes. Article 35 requires one where processing is likely to result in a high risk, and the WP248 rev.01 criteria endorsed by the EDPB give nine indicators with a rule of thumb that two or more point to a DPIA. A student-facing chatbot typically meets several at once: data concerning vulnerable data subjects, processing on a large scale, and innovative use of a new technology. Where the service touches wellbeing, disability or health queries, sensitive data or data of a highly personal nature is added to that list. Treat the DPIA as the expected outcome and document the reasoning if the conclusion is that one is not needed.
Does GDPR require a university chatbot to be hosted in the EU? No. Chapter V permits transfers to third countries where appropriate safeguards are in place, and Standard Contractual Clauses are the standard safeguard. EU hosting removes the transfer analysis rather than satisfying a separate legal requirement, which is why vendors selling into education lead with it. A procurement rule that screens on hosting location alone will reject lawful vendors and can still admit an unlawful arrangement, because a vendor hosting in Frankfurt with an unexamined US subprocessor has the same problem in a less visible place.
Does SiteGPT offer EU hosting for universities? No. The published subprocessor list names no EU-based subprocessor: Convex and Pinecone run in the United States on AWS, OpenAI and Cohere are United States, Cloudflare is listed as Global, and Paddle is United Kingdom. Transfers relating to EU, EEA and UK residents rely on the European Commission's Standard Contractual Clauses plus the EU-U.S. Data Privacy Framework where the specific provider is certified, and Article 27 representatives are appointed in both the EU and the UK. If the institution's procurement rules impose EU-only storage as a hard requirement, SiteGPT does not meet it and vendors built for the European education market, such as StudiAssist, genuinely do.
Does SiteGPT support SSO with Shibboleth, Keycloak or SAML? Not in the published documentation. The documented access model is role-based access for invited team members, plus scoped bearer tokens and an OAuth device flow for the API and CLI. There is no documented SAML, OIDC, Shibboleth or Keycloak integration, so an institution that requires federated staff login through its identity provider should treat that as unmet and confirm the current position with SiteGPT rather than inferring it. This matters mainly for staff administering the chatbot, since a public information chatbot for prospective students is normally unauthenticated by design.
Is a student information chatbot high-risk under the EU AI Act? Generally no, but the neighbouring uses are. Annex III classifies AI systems used to determine access or admission to educational institutions, to evaluate learning outcomes, to assess the appropriate level of education, and to monitor or detect prohibited behaviour during tests as high-risk. A chatbot that answers questions about deadlines, accommodation and course structure sits outside that list. It still falls under the Article 50 transparency obligation to make clear that a person is interacting with an AI system, and the scope of a deployment can drift into Annex III if the same assistant starts triaging applications.
Who is the controller for a university chatbot, the institution or the vendor? The institution is the controller and the vendor is the processor, in essentially every deployment of this kind. The university decides why the chatbot exists and what it is trained on, which is what determines controllership under Article 4(7), and a decision by a faculty rather than a central IT team does not move that responsibility to the vendor. The practical consequence is that the DPIA, the lawful basis, the privacy notice and the transfer impact assessment are all institutional documents that no vendor can supply. Watch for a vendor whose terms reserve the right to process conversation content for its own product improvement, because that is a processor stepping outside documented instructions.
Sources
- GDPR Article 6 for the lawful bases, including 6(1)(e) public task and the final sentence withholding point (f) from public authorities, read 12 August 2026
- GDPR Article 8 for the age of 16, the national floor of 13, and the limitation of the article to consent-based information society services
- GDPR Article 9 for the separate condition required for special category data
- GDPR Article 28 for the required contents of a processor contract
- GDPR Article 35 and Article 36 for the DPIA and prior consultation
- GDPR Article 37 for the mandatory DPO where processing is carried out by a public authority
- GDPR Chapter V for transfers of personal data to third countries
- EDPB endorsed WP29 guidelines on DPIA, WP248 rev.01, for the nine high-risk criteria and the two-criteria working rule
- Bayerischer Landesbeauftragter für den Datenschutz for orientation guidance on data protection in AI projects in Bavarian public administration, dated 9 July 2026, and the short practice paper on deploying an LLM-backed chatbot
- EU AI Act Annex III for the education uses classified as high-risk, and Article 50 for the transparency obligation
- SiteGPT privacy policy for the SCC and Data Privacy Framework wording and the Article 27 representatives, verified 12 August 2026
- SiteGPT subprocessor list for every subprocessor and its stated country, verified 12 August 2026
- SiteGPT security page for the SOC 2 Type II result, the role-based access wording, and the GDPR wording quoted above, verified 12 August 2026
- SiteGPT documentation for the documented access model and the absence of any SSO, SAML, OIDC, Shibboleth or Keycloak integration, verified 12 August 2026
- StudiAssist for its stated EU-based hosting, DPAs and technical and organisational measures, and SSO with Keycloak and Shibboleth, read 12 August 2026
- Tidio GDPR page for its statement that processing is mainly within the EEA while some data may be transferred to the United States under SCCs, the UK IDTA and the Data Privacy Framework, read 12 August 2026
Last updated: August 2026. All SiteGPT legal, security and documentation pages were read directly on 12 August 2026.