Holiday Extras Rolled AI Out to Every Team. The Durable Part Is Who Owns the Packages.

OpenAI's customer story on Holiday Extras, dated November 12, 2026, reports a company-wide ChatGPT Enterprise rollout with roughly 500 hours a week returned and about $500,000 annualized, plus an engineering model in which domain experts build while engineers own packages, security controls and workflows. This edition retrieved localized editions of that page, not the English original, so figures are reported as company-stated and no quotation is reproduced. The analysis treats the operating model as the transferable claim and tests it against CISA's Secure by Design and Secure by Demand guidance, NIST's Cybersecurity Framework and SP 800-218, and OWASP's verification standard. Three delegation models, four questions, a 30-day check and what remains unestablished. No independent outcome is asserted.

A travel company says its AI rollout returns about 500 hours a week. The more useful sentence in the vendor's write-up is about who owns the code those hours produce.

One is a benefit claim. The other is a governance arrangement, and only one of them survives contact with an audit.

What this edition could verify

Three limits belong at the top.

First, the Holiday Extras account is vendor marketing about the vendor's own product, published November 12, 2026. For this edition it was retrieved in localized editions rather than the English original, so the figures below are reported as the company states them and no sentence is reproduced as a verbatim quotation.

Second, no audit, contract, pricing page or independent measurement accompanied the account. Every number here is company-stated.

Third, the verification framework, the delegation models, the questions and the 30-day check are this publication's analysis.

What the account reports

Holiday Extras is described as a European travel-extras business operating for more than 40 years, serving airport parking, hotels, lounges and travel insurance customers. ChatGPT Enterprise was rolled out across the company, not to a pilot group.

The headline figure is roughly 500 hours a week returned across the business, which the account values at about $500,000 annualized.

The supporting measures, all company-stated: 95% of respondents said they use the tool weekly; 92% said they saved more than two hours a week; code debugging time fell by 75%; SQL queries were written about 80% faster for staff who already knew SQL; and about 30% of customer-service requests are now handled by an AI bot before reaching a person, with NPS moving from roughly 60 to roughly 70.

Those are the numbers a board will hear. They are also the numbers no third party checked.

The sentence that carries the lesson

The arrangement described is the part worth copying: non-technical staff build inside foundations engineers maintain, and engineers retain ownership of packages, security controls and development workflows.

Read that as a division of labor, not a feature. Domain experts bring what they know about customers; engineers own the seams where an application can hurt you.

The account is explicit that the goal was to put the technology in employees' hands, with engineers supplying the packaging that makes experimentation practical rather than chaotic.

That is a governance posture wearing a productivity headline, and it is the half most programs skip, because the first part demos well and the second is a budget line nobody shows.

What CISA asks of a producer

If your operations team now ships software, the question of who counts as the producer stops being rhetorical.

CISA is direct: "Every technology provider must take ownership at the executive level to ensure their products are secure by design." Commissioning the code does not transfer the obligation.

The agency's framing also supplies the buyer's half. Its Secure by Design page notes that the initial joint guidance describes "what software manufacturers can do to make their products safer, and ways customers can evaluate those products."

That second clause is the one that lands in a procurement file. The Secure by Demand guide is described as "concise and usable by any customer of software during procurement discussions with third party resellers or service providers." Not a certification — a question set that survives contact with a vendor's legal team.

Applied internally, the logic turns awkward. The entity commissioning an employee-facing application is the manufacturer of that application, whatever the org chart says.

Where code quality actually lives

NIST publishes SP 800-218, the Secure Software Development Framework, described in its own abstract as a core set of high-level secure software development practices that can be integrated into each development lifecycle.

NIST's Cybersecurity Framework sits above it, described by the Institute as "Helping organizations to better understand and improve their management of cybersecurity risk." Guidance again, and explicitly not certification.

OWASP's Application Security Verification Standard supplies the third leg: a published set of verification requirements a team can test against rather than argue about, and one its own project page says can be used as a metric, as guidance and during procurement.

None of those documents reviews generated code for you. What they do is give you a vocabulary for the review path, which is the artifact most AI-assisted programs lack.

Three ways to delegate building, and what each costs

This section is analysis. The vendor account supplies one arrangement, not a menu.

Governed packages. Domain experts build inside boundaries engineers define and maintain. The cost is upfront: someone writes and owns the packages, the review path and the security posture. The benefit is that operational expertise converts into software without the review queue becoming the bottleneck.

Centralized engineering. AI assists engineers; everyone else files requests. The cost is latency and translation loss, and the failure mode is a backlog that quietly teaches the business not to ask.

Platform configuration. Buy a product and configure it. The cost is the ceiling: the workflow you cannot express is the workflow you do not get, and the vendor's roadmap becomes your release calendar.

The first model is the most demanding, because it asks engineers to spend time on foundations whose payoff is other people's velocity — the hardest work to defend in a budget cycle.

What grounded has to mean for an embedded assistant

Once non-engineers build with AI, the failure mode shifts from a bad deploy to a confident wrong answer inside a workflow nobody audited.

A grounded assistant is one whose output can be traced to the source it used. If a routing decision, a summary or a draft cannot be tied back to the record that produced it, the review path has nothing to review.

That makes retrieval and provenance features of the review path, not features of the demo. CISA's language maps cleanly onto this: logging and transparency belong in the product, not bolted on after an incident.

Four questions before the first handoff

Who owns the package the output lands in? A named engineer, a documented interface and a review path. If the answer is "whoever built it," you have delegated the security boundary too.
What does a reviewer actually see? Not the diff alone — the intent, the data it reads, and the test that would have caught the failure.
How is a bad release reversed, and by whom, without stopping the queue? A weekly cadence only works if rollback is boring.
Which published requirement is this change checked against? If the answer is a feeling, pick a standard before the backlog grows.

A 30-day check

Days 1 to 5. Pick one workflow a domain expert currently runs in a spreadsheet. Write down what "correct" means before anyone builds anything.
Days 6 to 12. Name the engineer who owns the package boundary and the interface the output must cross.
Days 13 to 18. Define the review artifact: what a reviewer must see, in what format, in how many minutes.
Days 19 to 25. Choose the standard you will verify against and the log that proves it. A claim without either is decoration.
Days 26 to 30. Run one reversal drill. Time it. Write down who pulled the switch.

What remains unestablished

How the 500 hours a week and the roughly $500,000 annualized figure were measured, over what period, and against what baseline.
Whether the 75% debugging reduction and 80% SQL speed-up are controlled measurements or staff estimates.
What the review path looked like in practice: who approved what, how often, and what was rejected.
Whether non-engineers shipped code that engineers reviewed before release, or whether anything bypassed the package boundary.
Whether generated code was verified against any published requirement set, and which one.
How provenance was recorded for automated customer-service answers, and whether a third party could audit it.
Whether the cadence changes held beyond the first months, and what the arrangement costs in engineering time and review capacity.
Whether any other organization has reproduced the model, and what happened when it tried.
Market data. None was reviewed, so no stock movements or valuations are reported.

Evidence notes and limits

OpenAI's customer story on Holiday Extras, dated November 12, 2026, is the source for the company description, the company-wide ChatGPT Enterprise rollout, the roughly 500 hours a week and roughly $500,000 annualized figures, the 95% weekly-usage and 92% time-saved survey results, the 75% debugging and 80% SQL figures, the share of customer-service requests handled by an AI bot before reaching a person, the reported NPS movement, and the described division of labor in which staff build while engineers maintain packages, security controls and workflows. For this edition it was retrieved in localized editions rather than the English original, so figures are reported as company-stated and nothing is presented as a verbatim quotation. It is vendor material describing a customer.

CISA's Secure by Design page is cited for the quoted statement that every technology provider must take ownership at the executive level to ensure products are secure by design; for the quoted statement that CISA's initial joint guidance describes what software manufacturers can do to make their products safer "and ways customers can evaluate those products"; and for the quoted description of the Secure by Demand guide as concise and usable by any customer of software during procurement discussions with third party resellers or service providers. It is guidance and advocacy, not a regulation or a certification.

NIST's Cybersecurity Framework page is cited for its self-description as helping organizations better understand and improve their management of cybersecurity risk, with the accompanying point that this is guidance rather than certification. NIST's SP 800-218, the Secure Software Development Framework, is cited for its own description as a core set of high-level secure software development practices that can be integrated into each development lifecycle; no specific practice, control or result is attributed to it here.

OWASP's Application Security Verification Standard project page is cited for its description as a framework of security requirements for designing, developing and testing applications, and for its stated uses as a metric, as guidance and during procurement. No specific requirement number, control or audit result is asserted.

No audit, independent benchmark, contract, pricing page or third-party measurement was reviewed. The three delegation models, the provenance argument, the four questions and the 30-day check are this publication's analysis. Nothing here establishes that any organization reduced cost, improved quality or gained customers.

The advertisement above is separate from this analysis and is not a source for any claim in it.