AI does not get "installed" in a pool — it gets introduced in clear steps: first measure, then validate, then digitise the plant, then put an AI assistant on top — running locally, so the data never leaves the building. The path below comes from a real project for a municipal family pool (indoor + outdoor) and transfers one-to-one to hotel and wellness pools, because a hotel pool has the same trades: circulation, filtration, heating, ventilation, hot water.
The inquiry — "we want to actively steer"
It starts with the operator's question, not a product. The operator wanted to steer energy actively — run the heat producers as a controllable load on the pool's own PV — and to know whether an AI's economics hold up against real measured data. So AI's first job here was not steering but validation: does what the calculator promises hold on the real plant? For a hotel it's the same opening question — couple pool/spa energy to PV or CHP and cut costs provably.
Measure before you steer
First we measure, not estimate. A calibrated main meter went on the grid connection, plus the network operator's 15-minute load profile. That gives the real consumption pattern across day, week and year (electricity and gas separately), including PV. Only this profile shows when the pool draws power, when PV delivers and where the expensive peaks sit. No steering without measurement.
Validate the AI against reality
The figures an economics AI assumes — heat-pump COP, heat recovery from ventilation and backwash water, "zero grid draw" via PV — are checked against the measurements. Typical finding: manufacturer best-points (COP "up to 22") are not annual figures; the real range is lower. The result is a defensible statement the operator can carry to management — instead of a pretty but unverified calculation.
Add mobile metering where it counts
Where fixed meters are missing, a mobile metering set is added: compact WLAN/network energy meters capture individual loads — circulation pumps, variable-speed drives, ventilation. In the project these fed a local time-series database and then the analysis, revealing which pump draws what and which flexible load can shift into cheap, sunny midday hours. A mobile heat meter completes the heat side.
Digitise the plant — plans and photos become searchable
A pool holds a lot of knowledge in folders: controls and wiring diagrams (~650 pages in the project). These are scanned and made searchable page by page. Then the plant in pictures: 150+ photos and short videos of the real equipment were analysed by a vision AI — it recognises manufacturer and type on the nameplates (pumps, air handlers, drives, heat exchangers). Where a cabinet label is legible, the photo is even linked to the matching wiring-plan page.
The AI plant assistant (RAG)
On top of this plant memory sits an AI assistant: the operator asks in plain language — "which BMS data points does the exchanger charge pump have?", "where is the wiring plan of the filter pumps?", "PV output over the last 24 hours?" — and gets a cited answer in seconds (a click opens the plan or document at the right page) and, where relevant, the matching photo. Crucially, the assistant invents nothing — it answers only from the real project documents and readings.
Run it locally — data sovereignty
The assistant runs on the operator's own local infrastructure. For a municipality that is decisive: the pool's operating data never leaves the building, there is no cloud dependency and no hand-off to external AI providers. As the data grows, the whole AI can be placed as a local unit in the town hall or the pool — the AI computes on site, the data stays in the community.
Today — what the operator has
The result is a live dashboard (sensors, weather, day-ahead price, heat/hot water) plus the AI plant assistant that connects plans, photos and readings. The path: inquiry → measure → validate → meter mobile → digitise → AI assistant → run locally.
Same path for hotels & wellness
A hotel or wellness pool has the same trades as a municipal pool. The same path — measure, validate, digitise, AI assistant, run locally — lowers the energy cost of pool, sauna, ventilation and hot water, without touching guest or booking data (those stay separate).
Data protection, woven in — not bolted on
The whole path works with technical data (energy, plant and meter readings, nameplate photos), which are generally not personal data under Art. 4(1) GDPR — as long as they do not allow conclusions about individuals. Personal data appears only with add-ons (video of people, visitor counting, guest or staff data), which are kept strictly separate. Local processing satisfies data protection by design (Art. 25) and security (Art. 32) and substantially reduces third-country transfers (Art. 44 ff.). The controller (municipality or hotel) always remains responsible (Art. 4(7)). Whether a Data Protection Impact Assessment is needed (Art. 35) depends on scope — usually not for pure energy/plant AI, usually yes for video or visitor analytics. The AI assistant is made recognisable as AI (Art. 50 AI Act). This is general information, not legal advice — involve your data protection officer.
1 · Who operates the facility?
2 · Do you already have interval metering (load profile)?
3 · Any video or visitor analytics of people in public areas?
4 · Where should the AI run?
Note: This wizard is a rule-based planning aid, not legal advice, and does not use AI to generate its output. The controller assesses each case with its data protection officer. Legal status 2026-07-16 · GDPR (EU 2016/679), EU AI Act (EU 2024/1689).