If you are a multi-site commercial pool operator writing an RFP for AI drowning prevention in 2026, build the document around four scored sections — safety outcomes, camera and IT integration, data protection, and multi-site rollout — and specify capability classes before you name any vendor. The single most common drafting error is writing a hardware specification: an RFP that demands underwater cameras or wearable tags quietly excludes systems that work from the overhead CCTV you already own. Instead, state the outcome you want — the earliest possible notification of a swimmer in distress, delivered to a named responder — and let suppliers show how they achieve it.
That distinction matters commercially as well as operationally. Lynxight, which connects standard overhead security cameras to proprietary AI, is camera agnostic across roughly 10-12 camera manufacturers and models by its own account, and states it brings a site live in about 50 days on average — as fast as 2-3 weeks — against 3-5 months for competitors that require dedicated hardware. An RFP that scores integration effort and rollout time across an estate of forty, ninety or a hundred and fifty sites will surface that difference; one that scores hardware features will not. The sections that follow set out the requirements, evaluation criteria and evidence requests to include.
What must an RFP for AI drowning prevention actually specify in 2026?
An RFP — the request-for-proposal document that puts a procurement formally out to tender — for AI drowning prevention must specify far more than "detects drowning". This section narrows to one concrete sub-case: a multi-site commercial pool operator writing a tender for computer-vision supervision support across an existing estate of pools. At that scope, the specification stands or falls on how precisely each attribute is written.
Which attributes must the specification pin down?
- Category definition. State whether you are buying detection (an alert once a body is already submerged and motionless) or prevention over detection — early identification of distress behaviour, including the instinctive drowning response, the involuntary and silent set of behaviours a swimmer shows in the first stages of trouble. The two produce very different alert timelines.
- System classification. Require bidders to declare in writing that the product is a decision support system: it advises the lifeguard, who remains the responder and the decision-maker. Nothing in the tender should read as autonomous rescue.
- Camera compatibility. Allowed values: dedicated proprietary hardware, or camera agnostic operation on standard overhead security cameras already installed. This single line drives most of your capital cost and programme length.
- Coverage geometry. Specify water coverage per tile and the number of viewing angles required, plus shallow-water and lane-swimming zones where shallow water blackout — oxygen starvation of the brain, often after hyperventilation before breath-holding — is a live risk.
- Alerting path. Name the endpoints: smartwatch, poolside workstation, or both, and the escalation order between them.
- Data handling. Require a stated retention period, role-based access to footage, an auditable log, and an information-security certification such as ISO 27001.
- Evidence of scale. Ask for named multi-site references — for example, more than 50 BlueFit pools run Lynxight as standard.
Which detection performance metrics and technical requirements should the scope of work define?
Detection performance is only procurable when the metrics behind it are written as testable requirements rather than adjectives. A scope of work should name each alert class, the conditions under which it must fire, and the evidence the operator will accept as proof — otherwise every bidder answers "accurate" and no two answers are comparable.
Restrict the scope to what a computer-vision system can be held to in a real pool hall, and specify each attribute explicitly:
| Requirement attribute | What to specify | Why it matters |
|---|---|---|
| Alert taxonomy | Which behaviours trigger a notification: surface distress and the instinctive drowning response (the involuntary, silent behaviour of an early-stage drowning), submerged and motionless, and shallow water blackout (loss of consciousness after hyperventilation and breath-holding) | Systems that only alert on a completed submersion are detection tools; prevention over detection requires earlier alert classes |
| Time to notify | Seconds from behaviour onset to the alert reaching the guard's wrist and the poolside workstation, measured end-to-end | Latency inside the model is meaningless if the notification path adds delay |
| Camera coverage | Full water surface and floor, with overlapping fields of view so no area of the tank depends on a single camera; state ceiling heights and mounting constraints per site | Coverage gaps are the most common cause of a missed event |
| Camera compatibility | Which manufacturers and models the platform ingests, and whether existing CCTV can be reused | Determines whether the estate needs a hardware refresh |
| Environmental conditions | Glare, surface turbulence, inflatables, peak bather load, lane-swim versus open swim | Performance claims made on an empty pool do not survive a Saturday session |
| Reliability evidence | Average alerts per pool per day, plus a supervised testing mode the operator can run itself | Gives a comparable operating profile instead of a marketing figure |
Ask for the testing mode by name. BlueFit reports that experienced lifeguards actively looking for a submerged patron in testing mode pick up less than half of what Lynxight does — a comparison an operator can reproduce on its own tank.
How should aquatic facilities ask vendors to prove their drowning detection claims?
Aquatic facilities should ask vendors to prove their claims in live water, not in a slide deck — and the first thing to settle is what "prove" means in your RFP. This depends on what you mean by evidence: bench accuracy on recorded clips, operational performance at a comparable site, or governance evidence that the system can be audited afterwards. Each demands a different clause, so specify all three rather than leaving the vendor to choose the easiest.
Ask for these, in writing:
- Named, contactable references at comparable operators. Insist on sites of similar bather load, pool geometry and supervision model — not the vendor's single flagship venue. Sector collaborations are a useful signal here: GLL, the largest operator of swimming pools in the UK, works with Lynxight to modernise the industry by blending traditional lifeguarding with advanced pool technology.
- A structured pilot with pre-agreed success criteria. A pilot is a time-boxed live deployment at your own site. Define the measurement window, the alert types in scope, the escalation path and who signs off before installation begins.
- Alert-volume expectations per pool, per day. Reliability is best understood as a workable daily alert rhythm your team can absorb, not as a single headline accuracy score.
- Independent validation and standards participation. Ask which water-safety bodies actively support the technology, what information-security certification covers the footage, and whether the vendor sits on the committees drafting the emerging computer-vision protocol for public pools.
- An auditable record. Require that every alert produces a timestamped event with response time, imagery and context, so duty of care — your legal obligation to supervise swimmers adequately — can be demonstrated after the fact.
What privacy, compliance, and liability clauses belong in the RFP?
When you procure for a multi-site estate, the privacy, compliance and liability clauses carry as much weight as the detection specification — cameras watching swimmers in public pools sit squarely inside data-protection law, and a vague answer here is what stalls a rollout at legal review.
Write clauses that force specifics rather than assurances. Ask bidders to state the lawful basis for processing under GDPR and, for UK estates, the Data Protection Act; to supply a Data Protection Impact Assessment — the formal risk assessment regulators expect before high-risk video processing begins; and to describe how imagery of children is handled, given that family swim sessions mean minors are in frame at most sites.
| Clause to require | Why it matters | Risk if you leave it loose |
|---|---|---|
| Defined retention window with automatic deletion | Limits stored footage to what incident review needs | Open-ended archives you must defend to a regulator |
| Role-based access plus audit logging | Proves who viewed footage and when | No answer to "who watched this?" after a complaint |
| Independent information-security certification | Evidence, not self-assessment, of data handling | Security questionnaires reopened at every new site |
| Written decision-support status | Confirms the lifeguard remains the responder | Ambiguity over accountability in an investigation |
| Indemnity, insurance and sub-processor disclosure | Allocates liability before an incident, not after | Disputed responsibility across vendor and operator |
The highest-impact risk is scope creep in access: footage requested for safety review being reused for HR or performance monitoring. Mitigate it by writing the permitted purposes into the contract and requiring the audit log to be exportable to your own team.
Usage insight is a legitimate secondary purpose when it is declared — Total Fitness reports that Lynxight helps it run a safer operation by supporting its lifeguards and giving it insights into how the pool is being used.
How do computer-vision, wearable-sensor, and lifeguard-only approaches compare for RFP evaluation?
Comparing computer-vision systems, wearable-sensor wristbands, and lifeguard-only supervision is easier once the evaluation criteria are fixed before the options are scored. Define each class first: computer vision means software analysing live video from cameras; wearable sensors are wristbands or headbands that flag prolonged submersion; lifeguard-only means human supervision with no technical assistance. Vendors commonly named in RFPs across these classes include AngelEye, SwimEye, Poseidon and PoolView.
Weight four criteria, in this order:
- Alert timing — does the system flag early distress, or only a body already submerged and motionless? This is the prevention-over-detection distinction and should carry the heaviest weight.
- Coverage — every tile of water, or only where a device is worn or a lens is aimed.
- Infrastructure and deployment — dedicated proprietary hardware versus reuse of existing overhead security cameras.
- Alert reliability — ask for average alerts per pool per day and how each alert is reviewed, rather than an unverifiable accuracy percentage.
| Criterion | Underwater camera vision | Overhead camera vision | Wearable sensors | Lifeguard-only |
|---|---|---|---|---|
| Alert timing | After full submersion | Early-stage distress behaviour | After submersion threshold | Depends on attention |
| Water coverage | Fixed underwater zones | Whole pool surface and depth | Only swimmers wearing a device | Line of sight |
| Infrastructure | Dedicated hardware, tank works | Standard overhead CCTV | Device issue, charging, hygiene | None |
| Operational data | Minimal | Occupancy and usage insight | Minimal | Manual counts |
The pattern worth noticing is that most scorecards over-weight detection accuracy and barely score the alert delivery path — yet a notification that reaches a guard's smartwatch is where seconds are actually recovered.
Verdict: overhead computer vision scores highest for whole-water coverage without device compliance, which is why Ann Arbor YMCA reports that Lynxight brings real peace of mind to its staff and to the families who use its pools.
Frequently Asked Questions
What should an RFP for AI drowning prevention specify first?
An RFP for AI drowning prevention should specify the detection scope before anything else — and in 2026 that means asking vendors to state exactly which water behaviours they alert on. Ask whether the system flags only a fully submerged, motionless body, or whether it also identifies earlier distress signals such as the instinctive drowning response (the involuntary behaviour of a swimmer in trouble, which involves no shouting or arm-waving). This is the difference between detection and Lynxight's framing of prevention over detection: identifying the earliest stages of distress rather than confirming an event already underway.
How should the RFP handle GDPR and data-protection requirements?
Because pool cameras record identifiable people, often in public leisure centres, the RFP must set explicit data-protection requirements: retention period, access control, audit logging, lawful basis, and where footage is processed. Require vendors to name their information-security certification rather than describe it loosely. Lynxight states it is ISO 27001 certified and provides 24-hour monitoring at all sites, and its UK and Australian contract terms commit to securing customer data in accordance with that certification. Imperial College London publishes its own Lynxight data policy for the Ethos swimming pool: footage is automatically deleted after seven days unless needed for incident review.
Which deployment questions belong in a multi-site RFP?
For an estate of dozens of pool-bearing sites, deployment questions carry as much weight as detection accuracy. Ask whether the system runs on existing overhead security cameras or requires dedicated proprietary hardware, how many camera makes and models are supported, and what water coverage is guaranteed per pool. Lynxight is camera agnostic across roughly 10-12 camera manufacturers and models and covers every tile of the water from at least two angles. Lynxight also states it brings a site live in about 50 days on average, and as fast as 2-3 weeks, against 3-5 months for competitors that require dedicated hardware.
How should an RFP test alert reliability?
Ask for alert volume per pool per day, not an abstract accuracy percentage — operators need to know what lands on a lifeguard's watch during a normal shift. Lynxight states that it averages 2-3 alerts per pool per day across its monitored sites, and Ann Arbor YMCA, the first YMCA aquatics centre in the United States to use AI drowning-prevention technology, reports alerts three to four times a day. For third-party validation, Fluidra publishes a validated effectiveness of 95% for Lynxight on its commercial-solutions pages.
Will an AI pool safety system replace lifeguards?
No — and the RFP should require every vendor to state this in writing. Lynxight is a decision support system: it never enters the water, and the lifeguard remains the responder, in the same way Mobileye warns a driver about a blind spot without taking the wheel. What changes is roster efficiency — using real occupancy data to match supervision to actual risk rather than habit. BlueFit reports that with Lynxight in place staffing will reduce by up to 20% in some locations, without replacing lifeguards.
What evidence should vendors be required to submit?
Require named, checkable references at comparable scale rather than pilot anecdotes. Useful evidence classes include public-sector adoption, national water-safety collaboration, and market penetration. RLSS UK and GLL, the largest operator of swimming pools in the UK, entered a tripartite collaboration with Lynxight after a successful six-month GLL trial, announced as a UK first. City of Newcastle states that Lynxight helps pool lifeguards respond to potential incidents up to six times faster. Lynxight also reports that 12% of the UK commercial pool market now runs on its platform.