Seeing where an AI setup sits on the spectrum instantly reveals its governance implications
Private AI for your org: buy, build & govern
The data-residency spectrum and the governance checklist for an institution
1Overview
A decision framework for where an institution’s AI is allowed to run — not a product, a process you run once per use case.
A discipline, not a tool: how a research team, an SME, or an institute like EMBL Heidelberg decides where AI is allowed to run, and what to check before committing. Walks the data-residency spectrum end to end — laptop-local, a self-hosted GPU, an EU-managed workspace (Langdock, Mistral Le Chat Enterprise, Aleph Alpha PhariaAI), or a public API — then the governance checklist that actually decides the fit: who is the data controller, is there a signed DPA/AVV, does it meet GDPR and the EU AI Act, where does the data physically sit, and can access be audited.
Laptop-local → self-hosted GPU → EU-managed SaaS (Langdock) → public API — each step trades control for convenience.
Data controller · DPA/AVV in place · GDPR + EU AI Act fit · physical data location · auditable access — run all five before you commit.
Buy (Langdock, Mistral Enterprise) ships in days with a signed DPA; build (self-hosted Open WebUI) costs more setup time but gives full control — University of Freiburg runs the build path institution-wide.
2Lessons 7
2.1 Map AI setups onto a data‑residency spectrum
The data‑residency spectrum lets you place any AI deployment on a line from fully local to fully external, highlighting where the data lives and which governance rules apply.
Position four typical AI configurations on the spectrum to compare their trade‑offs
Show me a data-residency spectrum chart placing these AI setups: Laptop-local (Ollama or LM Studio), Self-hosted GPU (Open WebUI on our institute’s GPU server), EU-managed SaaS (Langdock or Mistral Enterprise), Public API (ChatGPT free tier).Enter the prompt in the private‑ai‑governance interface and hit Generate. Verify that each setup appears positioned along a single line from fully local on the left to public cloud on the right.
- Identify the Laptop‑local configuration and record its characteristics
- Identify the Self‑hosted GPU configuration and record its characteristics
- Identify the EU‑managed SaaS configuration and record its characteristics
- Identify the Public API configuration and record its characteristics
- You'll see Four distinct setups displayed side by side, each showing where the data resides
- Takeaway Convenience rises and control falls as you move from laptop‑local to public API
- Check Which end of the spectrum would you place a free ChatGPT account on and why?
2.2 Map your organization’s AI deployment options onto the data‑residency spectrum
A simple spreadsheet that places each possible AI setup on a scale from fully local to public cloud.
You will produce a visual map showing where laptop‑local, self‑hosted GPU, EU‑managed workspaces and public APIs sit relative to data residency.
- Open a new spreadsheet and create four columns labeled: “Setup”, “Physical location of data”, “Control over hardware”, “Compliance implications”.
- Enter the four setups described in the chapter – laptop‑local, self‑hosted GPU, EU‑managed workspace (e.g., Langdock, Mistral Le Chat Enterprise, Aleph Alpha PhariaAI), and public API.
- For each row fill the columns using information from the material: e.g., “Physical location of data” is “your device”, “your own server”, “EU data centre”, or “provider’s cloud”.
- Add a fifth column “Risk level (GDPR/EU AI Act)” and mark “low”, “medium”, or “high” based on whether the setup requires a Data Processing Agreement, GDPR audit, or falls under high‑risk AI provisions in the AI Act.
- You'll see A completed table that clearly positions each deployment option along the residency spectrum and highlights its compliance burden.
- Takeaway Visualizing data residency helps you quickly compare technical control with regulatory exposure.
2.3 Run a governance checklist on an AI tool
The governance checklist comprises five key questions that data‑protection offices use to decide whether an AI service can be used under GDPR and the EU AI Act.
Do this first Map AI setups onto a data‑residency spectrum
Apply the five‑point checklist to an AI tool your team already uses
Using the private‑ai‑governance interface, select **Run Checklist**, enter the name of the AI tool your team uses (e.g., ‘ChatAssist’), and click **Start** to generate a compliance report covering the five governance questions.Paste the prompt into the Command Input field on the main dashboard of private‑ai‑governance, then press Enter. Watch for any unanswered items in the generated report—they indicate red flags.
- Determine who acts as the data controller for the AI service
- Verify that a signed Data Processing Agreement or AVV is in place
- Confirm compliance with both GDPR and the EU AI Act requirements
- Locate the exact physical data storage region of the service
- Check that access logs can be audited and retention periods are documented
- You'll see A concise list of yes/no answers for each of the five items, ready in under ten minutes
- Takeaway Check controller, DPA, GDPR + EU AI Act compliance, data location and auditability before any tool handles institutional data
- Check Which of the five checklist items is hardest to answer for a free consumer chatbot account and why?
- Cost Running this checklist costs nothing but the ten minutes it takes to read a vendor's security/DPA page — far cheaper than the compliance review after a bad rollout.
2.4 Run the EU AI Act compliance checker on a chosen AI setup
An online questionnaire that returns a quick assessment of obligations under the EU AI Act.
You will obtain a summary of which articles of the AI Act apply to your selected deployment option.
- Visit the AI Act website (artificialintelligenceact.eu) and locate the “Compliance Checker” link mentioned in the homepage description.
- Start the checker and answer the ten‑question survey with details from the spreadsheet you built in Lesson 1 (e.g., data location, risk category).
- Submit the answers and record the resulting list of obligations – note any references to high‑risk system requirements or GPAI provisions.
- Copy the output into a new sheet tab titled “Compliance results” and annotate which items will need further action (e.g., DPA, impact assessment).
- You'll see A concise report listing relevant AI Act articles (such as Chapter III high‑risk rules or Chapter V GPAI obligations) for the chosen setup.
- Takeaway The checker turns abstract legal text into concrete action items tied to your deployment choice.
2.5 Choose between buying or building a private AI solution
Do this first Map AI setups onto a data‑residency spectrum·Run a governance checklist on an AI tool
Select the deployment approach that satisfies your organisation's compliance checklist
Run the private‑ai‑governance tool to assess the ‘Buy’ scenario (Langdock on Azure EU) and the ‘Build’ scenario (self‑hosted Open WebUI), generating a compliance checklist report for each.Paste the command into the private-ai-governance console and press Run. Verify that the output shows a completed five‑point checklist for both options, with each item marked as passed.
- Map the data controller and processor roles for each option
- Compare the Data Processing Agreements and compliance evidence against internal policies
- Evaluate deployment location, audit capabilities and total cost for both the hosted service and a self‑hosted stack
- You'll see A chosen option that meets all five checklist items for data residency and governance
- Takeaway Buy reduces setup effort while adding vendor reliance; build gives full control but requires ongoing maintenance
- Check For a small lab with no dedicated IT staff, which path clears the governance checklist faster and what does it give up to get there?
2.6 Complete a GDPR governance checklist for the selected AI tool
A step‑by‑step list of GDPR artefacts required before deploying an AI system that processes personal data.
You will produce a set of documented GDPR controls ready for audit, including a Data Processing Agreement and a rights‑exercise procedure.
- Open the “GDPR compliance checklist” page on gdpr.eu and copy its bullet list into a new document titled “GDPR Checklist –
”. - For each item (e.g., DPA, privacy notice, record of processing activities) indicate whether it is already satisfied by your deployment choice or needs creation.
- Draft a simple Data Processing Agreement template using the example provided on gdpr.eu and fill in the parties (your organization and the AI provider).
- Create a one‑page “Right to Erasure” procedure that describes how you will delete personal data from the AI system upon request, referencing the GDPR right to be forgotten.
- Save all artefacts in a folder named “Governance‑
”.
- You'll see A complete folder containing a filled DPA, a privacy notice draft, and a documented erasure workflow ready for internal review.
- Takeaway Systematically ticking GDPR items ensures that data‑privacy obligations are met before any AI model is put into service.
2.7 Choose between buying an EU‑managed SaaS or building a self‑hosted Open WebUI solution
A decision matrix that weighs the governance results, cost, and technical effort of two concrete private‑AI options.
You will produce a short recommendation report stating which option best satisfies your organization’s residency and compliance requirements.
- Create a new spreadsheet tab called “Buy vs Build”. List the two alternatives: “EU‑managed SaaS (e.g., Langdock)” and “Self‑hosted Open WebUI”.
- Add rows for criteria derived from previous lessons: data residency, GDPR/DPA need, AI Act high‑risk obligations, hardware control, maintenance effort, and auditability.
- Populate each cell with the findings you recorded in Lessons 1‑4 (e.g., SaaS scores “EU data centre” and already provides a DPA; self‑hosted scores “your server” but requires you to draft a DPA).
- Score each criterion on a 1–5 scale, sum the totals, and write a one‑paragraph recommendation explaining why the higher‑scoring option aligns with your governance checklist.
- Export the sheet as PDF and name it “Private‑AI Decision Report”.
- You'll see A quantified comparison table and a concise report recommending either the EU‑managed SaaS or the self‑hosted solution based on concrete compliance evidence.
- Takeaway Structured decision matrices turn governance checklists into actionable procurement choices.
3You’ll know it worked 5 checkable outcomes in this chapter
- ✓A clear, documented name of the controller (your organization or the vendor) is provided on the vendor's security page
- ✓The vendor's compliance page includes a downloadable or viewable signed DPA/AVV
- ✓The vendor provides a concrete region name rather than a generic "cloud" answer
- ✓The vendor contract file shows a signed DPA attachment and the internal checklist displays an entry reading “DPA: none needed”
- ✓Vendor settings display “location = EU” for the bought option, and the provisioning details list your selected EU region for the built deployment
4FAQ, Tips & How-to 17
one problem, one solution, one action
Need an EU‑based AI SaaS with no admin work
Using an EU-based SaaS gives zero operational overhead while providing contractual data protection
A public AI API provides immediate convenience but offers the least control over where data goes
Unsure who is legally accountable for your AI data
Identify the legal entity that must be named under GDPR before using any AI tool
Vendor needs to be a processor, not a controller
Ensure a Data Processing Agreement (or AVV) exists so the vendor can be used as a processor, not an uncontrolled controller
Know the exact geographic region of storage to assess jurisdictional risks
Need proof of who accessed data and for how long
Require logs that prove who accessed what data and for how long, enabling post-hoc compliance verification
Need a compliant EU AI workspace
Buying a vendor-hosted EU workspace lets you satisfy compliance checks quickly by leveraging the vendor's existing certifications
Need a private AI chat interface you control
Building your own Open WebUI deployment gives you full control over data location, audit logs and compliance responsibilities
Identifying who the data controller is clarifies legal responsibility for personal data handling
Not sure if a data‑processing agreement is required
A DPA defines the contractual obligations for data protection between controller and processor
Need to prove personal data stays in the right jurisdiction
Specifying data residency ensures that personal data stays within the required jurisdiction
I need to prove compliance and spot issues
Having audit mechanisms lets you prove ongoing compliance and detect issues
How can I see where my AI deployment sits on the local‑to‑cloud spectrum?
Draw a horizontal line that represents the spectrum from fully local to public cloud, then place your four common setups along it as described in the lesson. This single‑line view instantly shows the governance implications of each placement.
What should I look for to ensure an EU‑based SaaS has no admin work and complies with data protection?
Choose a managed AI workspace that runs in the EU and comes with a signed Data Processing Agreement (DPA). The vendor’s security or compliance documentation will confirm the service is hosted in the EU and provides contractual data protection.
Who is legally accountable for personal data when I use an AI tool?
The data controller is the party named under GDPR that decides why and how personal data is processed. Look for a clear statement naming the data controller in the vendor’s security or compliance documents, or set yourself as the controller if you build the solution.
How can I verify audit logs and where my data is stored?
Ask the vendor for the exact cloud region name (e.g., EU or US) to assess jurisdictional risk, and confirm they provide searchable query logs that record who accessed what data and for how long. These logs should be exportable for compliance audits.
The same set on /recipes, filtered by tool and role.
5Videos 2
The buy-vs-build chapter made concrete: one founder's actual private stack, days old.
The compliance half of 'private AI for your org' — why governance is a requirement, not a preference.
6FAQ 4
How can I see where my AI deployment sits on the local‑to‑cloud spectrum?
Draw a horizontal line that represents the spectrum from fully local to public cloud, then place your four common setups along it as described in the lesson. This single‑line view instantly shows the governance implications of each placement.
What should I look for to ensure an EU‑based SaaS has no admin work and complies with data protection?
Choose a managed AI workspace that runs in the EU and comes with a signed Data Processing Agreement (DPA). The vendor’s security or compliance documentation will confirm the service is hosted in the EU and provides contractual data protection.
Who is legally accountable for personal data when I use an AI tool?
The data controller is the party named under GDPR that decides why and how personal data is processed. Look for a clear statement naming the data controller in the vendor’s security or compliance documents, or set yourself as the controller if you build the solution.
How can I verify audit logs and where my data is stored?
Ask the vendor for the exact cloud region name (e.g., EU or US) to assess jurisdictional risk, and confirm they provide searchable query logs that record who accessed what data and for how long. These logs should be exportable for compliance audits.
7Glossary 15 terms
Show the 15 terms
SaaS- Software‑as‑a‑Service means you use an application that runs on the provider’s servers instead of installing it yourself.
EU‑based AI SaaS- An AI service hosted in Europe, which helps meet European data‑protection rules.
Data Processing Agreement (DPA)- A legal contract that spells out how a vendor will handle personal data on behalf of the organization that owns it.
AVV- Another name for a Data Processing Agreement used in German‑language contracts.
GDPR- The European Union law that sets rules for protecting personal data of people in the EU.
AI Act- A proposed EU regulation that will set safety and transparency standards for AI systems.
data controller- The person or organization that decides why and how personal data is processed.
processor- A party that processes personal data on behalf of the data controller, following their instructions.
ISO 27001- An international certification showing a company follows recognized information‑security management practices.
SOC 2 Type II- A report that verifies a service provider’s controls for security, availability, and privacy over time.
Open WebUI- An open‑source web interface you can install to talk with an AI model on your own server.
Ollama- Software that lets you run local AI models on a machine, often used together with Open WebUI.
vLLM- A fast engine for serving large language models locally or in the cloud.
GPU server- A computer equipped with graphics‑processing units that accelerate AI model calculations.
audit logs- Records that show who accessed data, what they did, and when it happened, useful for compliance checks.
8See also
💬 Discuss this chapter
Ask, share, or report — over on the Heidelberg AI community forum.