Heidelberg AI Curriculum

18books at this level

A Self-Hosted Assistant Your Team Can Use Safely

Start Open WebUI with Heidelberg AI Desk on one machine, connect a local model or a provider key, and learn where every prompt goes. Then do the Level 4 part: decide who can reach the assistant, how accounts are approved, and which data it may see, before colleagues log in.

Outcome: A one-page assistant record (model and where prompts go, who can reach it, how accounts are approved, who administers it, allowed data classes, backups) plus Open WebUI running on one machine with a non-admin test account; it passes when the test account can chat but can't open the Admin Panel, sign-up is off, and a colleague answers three paste questions correctly from the record alone.

Integrator20 minLast edited: Oct 12, 2026

T03-L0402

Release Prompt Changes Through Review, Tests and a Way Back

When a prompt feeds a real database or a real inbox, every change is a release. Put the prompt and its tests in a repository on your code server, let every change pass an automatic test run and a named reviewer, release by tag, and roll back in minutes.

Outcome: A prompt repository with one released change: the pull request with its automatic test run and approval, the release tag recorded in production outputs, and a rehearsed rollback. It passes when a colleague rolls production back to the previous tag from the README alone in under ten minutes, and IT has confirmed the access list in writing.

Integrator22 minLast edited: Sep 23, 2026

T04-L0403

Connect an Assistant to Real Documents Without Widening Anyone's Access

An assistant connected to your document system can show anyone what they could open but never found, or what they should never see. Choose how access is decided, clean up the sources first, connect with the least access, and prove with two test accounts that a restricted document stays hidden.

Outcome: A permission test record for one connected source: the access model and why, the sign-offs, two ordinary test accounts, a marker document and the results for the authorised account, the outside account and a removed member. It passes when the outside account surfaces no marker, title, snippet or citation anywhere, the shared control works for both, and removal took effect within the stated window.

Integrator20 minLast edited: Sep 23, 2026

T05-L0404

Make an Automation Safe to Fail Before It Touches Real Systems

Your n8n automation now sends mail or writes into a real system. Put a duplicate guard in front of every step you can't undo, retry only what is safe to repeat, give failures a reader, let the workflow stop itself, and get a service account from IT that can do nothing more than the job.

Outcome: One n8n workflow that writes to a real system, with a failure test sheet and a takeover page; it passes when all five injected failures (double run, revoked login, empty input, timeout on the irreversible step, three failures in a row) end where the sheet says, IT and the data owner have signed, and a deputy takes over by hand from the page alone.

Integrator22 minLast edited: Sep 23, 2026

T06-L0405

Put Your Team App on the Organisation's Own Database, and Prove You Can Restore It

Move a team app's data out of the app builder into a self-hosted Supabase, the open-source PostgreSQL platform, that your IT runs. Enforce who sees which rows with row-level security, give every person, program and assistant its own narrow login, back up off the server, and restore into an empty database.

Outcome: A restore record and a role test sheet for a team app whose data lives in a Supabase your organisation runs; it passes when the restored copy, built from the off-server backup into an empty database, gives the same answers to every line of the role test sheet, no admin key appears in the app, and IT and the data owner have signed.

Integrator22 minLast edited: Sep 23, 2026

T07-L0406

Connect an Agent to a Real Mailbox Without Handing It the Keys

Let an agent work on a real mailbox or business system while it holds no credentials itself: two small scripts hold one narrow key, IT limits it to one mailbox, a gate checks every draft, a person sends. Test it with planted instructions, prove what the key can't do, and know how to switch it off.

Outcome: A connection record for one agent working on a real mailbox or business system: the access granted and the denials proved, the gate rules, a before-and-after run of at least three planted-instruction tests, the sign-offs, and a tested switch-off. It passes when every planted instruction ends as a draft for a person or a refusal, and IT has signed.

Integrator22 minLast edited: Sep 23, 2026

T08-L0407

Use OpenCode Desktop on Your Organisation's Real Repositories

Set up OpenCode Desktop for work: the approved model, sharing off, and permissions that keep secrets and pushes out of the assistant's reach. Then deliver every AI-assisted change on a branch, as a pull request a second person reviews, into a protected main branch, with credentials IT issues for the job.

Outcome: One merged pull request in a real team repository, made with OpenCode, plus a one-page repository record. It passes when main rejects a direct push, a second person approved the pull request against the spec, the secret scan and tests ran before the push, and the record names the account, its access and the undo.

Integrator27 minLast edited: Oct 18, 2026

T09-L0408

Transcribe Recordings That Must Stay in the Building

Run Whisper on a workstation your organisation controls when recordings may not leave it: check that the model fits and is fast enough, get the data protection officer and IT to sign the data route, give the job the smallest access that works, and keep a tested way to stop, delete and undo.

Outcome: A signed one-page data route plus a working local transcription setup; it passes when the test clips pass the check with the local model, fit and speed are measured on your own hardware, the job account is shown to be unable to read outside its folder, one approved real recording has a reviewed transcript, and a colleague has run the stop-and-delete procedure from the run sheet.

Integrator23 minLast edited: Oct 12, 2026

T10-L0409

Connect Your Analysis to a Live System, and Stop Bad Data Before It Reaches Anyone

Move a rerunnable analysis from copied files to a live database: a read-only account that sees one view, quality checks that stop the run before any output, only the fields the task needs (and fewer still for any AI model), a schedule that can't overlap, and a last good result that stays when a check fails.

Outcome: A scheduled pipeline reading a live source through a read-only account; it passes when a deliberately corrupted copy of the source makes the run stop with a clear message and leaves the last accepted output unchanged, a write attempt with the pipeline's account is refused, the data owner and IT have signed the field list, and a colleague can rerun a stopped week from the run sheet.

Integrator20 minLast edited: Sep 23, 2026

T11-L0410

Put Your Team's Assistant on a Server Colleagues Can Reach

Move a self-hosted assistant from one computer to a server the whole team can reach: one HTTPS address, a firewall that lets nothing else in, the model port closed, named accounts, backups you have restored, and an update you can undo. IT and the data protection officer sign off before the first colleague logs in.

Outcome: A server record for your team's assistant, plus a second-device test: it passes when the HTTPS address works from a colleague's computer, the Open WebUI and model ports don't answer from there, a restore from last night's backup has worked on another machine, and IT (plus the data protection officer if chats hold personal data) has signed the record.

Integrator23 minLast edited: Sep 23, 2026

T12-L0411

Lock Down a Self-Hosted AI Service Before Real Data Goes In

Before real records reach a self-hosted assistant or workflow, check it from the outside in five steps, give it a service account that can only do its job, keep secrets out of files and Git, limit where it can send data, and prove a restore works, keys included. Every finding gets a fix, a date and IT's signature.

Outcome: A dated five-step audit of a self-hosted AI service: every finding with its fix, who fixed it and the retest result, plus one denied-access test and one restore test. It passes when every step has a result, no finding is open without a named person and a date, and IT has signed.

Integrator20 minLast edited: Sep 23, 2026

T13-L0412

Roll Out an AI Assistant to a Whole Department, With Access, Cost and Consent Settled First

Take an AI assistant from a successful pilot to a whole department: seats by role, costed with the time it takes; oversharing fixed before it's switched on; the data protection officer and works council agreed; and waves with support, an objection route and a way back.

Outcome: A rollout plan and the results of its first wave; it passes when every seat is tied to a named role and task, the cost includes people's time, the oversharing check and its fixes are recorded, the DPO and the works or staff council have signed, access is removable by one group change, and after wave one the plan shows accepted outcomes, unused seats and every objection with its answer.

Integrator19 minLast edited: Sep 23, 2026

T14-L0413

Build a Read-Only Connector for a System Your Assistant Can't Reach Yet

When the system your team needs has no connector, build one: a small MCP server with one read-only tool, a key that can only read, the fewest fields the task needs, and six tests including a write attempt that must fail. IT and the system's administrator agree before colleagues connect it.

Outcome: A working read-only connector with its README and a test sheet of six cases; it passes when all six give the expected result, a write attempt through the same key is refused by the system itself, a colleague's run shows only what their own access allows, and the system's administrator has agreed in writing.

Integrator18 minLast edited: Sep 23, 2026

T15-L0414

Set Up AI for a Whole Research Group

Give your research group one AI setup instead of nine private ones: an agreed assistant on known terms, a map of the group's data and who can see it, three paste rules, a shared AI-use log that feeds methods sections, and an onboarding hour for the next PhD student. Reviewed and signed by the PI.

Outcome: A one-page group AI-use policy plus a data map (each data source, its class, the tools allowed, who has access), reviewed and signed by the PI with a review date; it passes when every data source the group uses appears in the map and a new member can answer three paste questions from the policy alone.

Integrator20 minLast edited: Sep 23, 2026

T16-L0415

Replace a Tool Without Losing Your Work

Move a team from one AI tool to another without losing work, access rules or a way back: list everything the old tool holds, decide what moves, what is rebuilt, archived or dropped, re-test the real jobs in the new tool, revoke every old key, and switch in stages with a rollback you have tried.

Outcome: A migration record for one team (inventory with a decision per item, re-test results in the new tool, cutover plan with rollback trigger, list of revoked keys and closed accounts, sign-offs); it passes when a pilot user completes the team's three most important jobs in the new tool without the old one, the rollback was tried on copies, and every credential the old tool used is accounted for.

Integrator17 minLast edited: Sep 23, 2026

T17-L0416

Run a Pilot with Real Users and Real Data

Test a solution on real work before your lab or company depends on it. Set the pilot's scope, success criteria and data permissions before day one, keep a way back, measure what matters, and end with a written go, change or stop decision that follows rules you set in advance.

Outcome: A pilot plan and a results note for a real pilot, which pass when the criteria and decision rule are dated before the start, data permissions are confirmed in writing, every criterion (including harm) has a measured result, and the go, change or stop decision follows the rule and is signed by the person who decides.

Integrator18 minLast edited: Sep 23, 2026

T19-L0417

Check Every Change Automatically, Release Versions and Tell the Lab

Run an automatic check on every pull request with Gitea Actions, make it required so a failing change cannot be merged, keep the chat address as a secret, and publish numbered releases that announce themselves in the lab chat.

Outcome: A repository where a required automatic check runs on every pull request, one pull request was blocked by it and fixed, and publishing release v1.0 posted a message in the chat using the secret address.

Integrator18 minLast edited: Sep 25, 2026

T20-L0418

Set Up a Harness So a Mistake Stays Small: Container, Rules, Keys and Network

Keep an unattended coding agent small with four layers: a container that sees only the project, a network that reaches only the model gateway, a narrow expiring key, and harness rules for honest mistakes. Includes a five-action safety probe.

Outcome: The four promises with their layers, the two probe rows (before and after), and the practice task result in the final set-up. Passes when the after-row shows internet and writing outside blocked, no promise depends on a harness rule alone, the key expires and is limited to one model, and a colleague can rerun the probe.

Integrator14 minLast edited: Oct 18, 2026