Direct answer: before a UK airline, travel agent, OTA or tour operator lets an **AI assistant or agent complete an air sale, issue a confirmation, or hand a passenger a PNR**, the booking path must already be able to **receive, record, confirm and forward a PRM (persons with reduced mobility / disabled persons) assistance request** — including IATA special service request (SSR) codes where used, free-text needs beyond the code, and a non-digital channel — under Assimilated Regulation (EC) No 1107/2006 Article 6 and the CAA’s Airline Accessibility Guidance (CAP 2990). An agent that books the seat and forgets the wheelchair, DPNA note or 48-hour pre-notification clock is not a clever concierge. It is a rights and ops failure at the gate.
That is the operator question Kaize is answering here. We are a UK AI product studio for travel and hospitality. This is not legal advice and not a substitute for reading the live Regulation or CAP 2990. It is a **control-stack** article for product and commercial leaders: what must already be true before an AI is allowed to **complete a UK air sale**. It sits beside — and does not replace — our Equality Act / WCAG booking-UI controls (those are about the interface being usable) and our API / authority-to-carry boarding stack (those are about travel documents and carrier permission to board). This article is about **assistance notification and pre-notification** so the airport and operating carrier actually receive the request.
What Article 6 actually requires at the point of sale
Article 6 of Assimilated Regulation (EC) No 1107/2006 is blunt: air carriers, their agents and tour operators **shall take all measures necessary** for the receipt, at **all their points of sale in the United Kingdom**, including sale by telephone and via the Internet, of notifications of the need for assistance made by disabled persons or persons with reduced mobility. The CAA restates this in CAP 2990 (§21) and ties it to onward transmission: requests must be passed to airports and the operating carrier within **36 hours** of published departure when the passenger notified **outside 48 hours**, or **as soon as possible** when notification falls inside 48 hours.
For an AI booking path that means three product facts, not a policy PDF in Confluence:
- Every AI-owned sales channel that can complete a UK air booking is a **point of sale** — chat, voice, agent tool, NDC wrapper, package builder — and must be able to **receive** an assistance notification, not only sell a seat.
- The path must support **prompting** the passenger (or agent acting for them) to declare assistance needs before confirmation, not after the PNR is sealed.
- Something downstream must be able to **confirm** the request was noted and **forward** it on the Regulation’s clock — an LLM paraphrase in the transcript is not a PAL/CAL handoff.
The five gates before AI may complete the air sale
Gate 1 — Assistance capture exists on the same path that can confirm
CAP 2990 (§23) treats it as best practice to offer assistance booking **inside** the website/app booking flow with pre-set choices mapped to **IATA SSR codes**, plus free text beyond the code — and insists the ability to request assistance **must not** be only through that channel. Telephone (or equivalent) must remain available so people can explain needs. If your AI is the primary sales path, Gate 1 fails unless (a) SSR + free-text capture is in the agent tool, and (b) a human/phone/email fallback is reachable without abandoning the booking.
Gate 2 — Codes are not enough; DPNA and free text are first-class
The CAA (CAP 2990 §26, echoing ECAC Doc 30 Annex 5-H) expects travel agents and carriers to prompt for assistance, use a staff checklist where humans are involved, explain assistance types in passenger-friendly language, and **include DPNA** because people with non-visible disabilities may not map themselves to wheelchair codes. DPNA **always** needs extra information. An AI that only offers WCHR/WCHS/WCHC checkboxes, or that invents a free-text summary the passenger never confirmed, fails Gate 2.
Gate 3 — Pre-notification clock is product logic, not a FAQ
Passengers are asked to request assistance when booking or at least **48 hours** before departure so airports can prepare (CAA: arranging special assistance). The carrier/agent still has onward transmission duties inside/outside that window (CAP 2990 §21). Before AI confirms, the system must know: was assistance requested; when; is the departure inside 48 hours; who owns the forward to airport/operating carrier. Selling a same-day ticket while silently dropping the SSR is a Gate 3 failure.
Gate 4 — Confirmation back to the passenger is mandatory design
CAP 2990 (§26) expects confirmation that the assistance request has been **noted and passed on**, in a medium suited to the passenger. An AI chat that says “all set” without a durable confirmation artefact (email, accessible message, booking record flag the ops desk can see) is theatre. Gate 4 requires the confirmation channel to be addressable from the same booking identity the AI just created.
Gate 5 — Tour operator / agent network is in scope, not only the airline app
Article 6 binds **agents and tour operators**, not only the operating carrier’s own website. CAP 2990 (§25) says airlines should proactively engage their tour-operator and travel-agent networks so assistance data is gathered correctly. If Kaize (or any vendor) ships an AI sales agent into an ATOL holder’s package flow, Gate 5 fails unless that agent writes assistance data into the same handoff the airline and airport already trust — not a parallel spreadsheet the AI “remembers.”
What this is not (duplicate fence)
- Not Equality Act / WCAG UI accessibility — that article is about whether disabled people can use the booking UI; CAP 2990 even notes EA 2010 reasonable-adjustment rules do not apply to matters governed by 1107, while WCAG still matters for the website. Different control stack.
- Not API / authority-to-carry — document and boarding-permission checks.
- Not UK261 disruption notifications — care and rights after disruption.
- Not medical clearance policy design — CAP 2990 covers access and medical clearance separately; do not let an AI invent medical refusals.
A practical control stack for AI air-sale agents
Evidence anchors (read these, do not invent outcomes)
- Assimilated Regulation (EC) No 1107/2006 — Article 6 points of sale; airport assistance duties; Annexes on assistance scope.
- CAP 2990 Airline Accessibility Guidance (CAA, Aug 2024) — pre-journey requesting assistance, IATA codes, DPNA, tour-operator engagement, confirmation.
- CAA: How to access help and support / arranging special assistance — passenger-facing 48-hour guidance and booking channels.
- IATA SSR / Passenger Accessibility materials referenced by CAP 2990 — use as code vocabulary, not as a substitute for free-text needs.
What Kaize will and will not automate
Kaize builds AI product for travel and hospitality operators. We will help design **capture, prompt, confirm, clock and handoff** controls so an assistant cannot complete a UK air sale while assistance data is missing. We will not claim a chat model “is CAP 2990 compliant,” invent passenger outcomes, or replace airline–airport PAL/CAL operational systems. The human and systems of record stay accountable; the AI stays behind the gate.
If you are wiring an AI agent into UK air or package sales and want a control review against Article 6 / CAP 2990 pre-notification — not a brand rewrite — discuss a project with Kaize.