This website uses cookies

Read our Privacy policy and Terms of use for more information.

Every AI product ships with a story about how carefully it was built. Almost none of them publish the checklist, because the checklist is where you find out what was skipped.

Here is ours. Fifteen points, run before an AI-assisted product goes in front of a person. It is the operating version of a shorter idea: vet before you adopt, disclose what the model did, verify before it reaches anyone.

The fifteen

  1. Data minimisation — what actually reaches the model, and what never does.

  2. Provider data-use terms — training on inputs, retention, region. Read, not assumed.

  3. Usage cap and billing alert — a ceiling on spend, and an alarm when something changes.

  4. Secrets — no key in the frontend, none in a prompt, none in a log.

  5. Fit for purpose, and the top three failure modes — named in advance, with mitigations.

  6. Abuse and prompt injection — what happens when the input is hostile.

  7. "AI-assisted" label and limits — disclosed before the first interaction, not in a footer.

  8. Not financial or legal advice — where the boundary sits, in the words that matter.

  9. Privacy notice, consent and deletion — including a route a person can actually use.

  10. Affiliate and sponsorship disclosure — anywhere a recommendation could pay us.

  11. Honest framing of maturity — "early", "rough edges", and a feedback route that exists.

  12. Human review of risky outputs — the model drafts, a qualified person decides.

  13. Fact and recency checks — no number published that nobody verified.

  14. Logging and a feedback channel — an error nobody can report is one you learn about from silence.

  15. Rollback and a stop plan — tested, with a named owner.

Download it as a working PDF → — with what to look for and what evidence to sight against each one.

What happens when the gate finds something?

Our discovery product went through this gate against a hard regulatory deadline — the EU AI Act's transparency duty, which applied on 2 August 2026.

The gate found reds. The disclosure layer went live with a day to spare.

And while checking it, we found our own backend had been dead for days and nobody knew. The billing account had closed, the service had stopped, and the product showed every visitor a message blaming their internet connection. Diagnosing it meant going to the server. Nothing in the product could have told us.

Point 3 on that list is usage cap and billing alert. It was open at the time. It is the control that tells you when the other fourteen break, and we had not set it.

Why do checklists fail even when they are good?

The gate did not fail because it was a bad gate. It failed because a control that had been written down had not been switched on — and there is no version of a checklist that catches that on your behalf.

The only defence is running it against yourself, on a date, and publishing what it says. That is why this is here, and why the last one we ran returned a NO-GO.

Points 12 and 13 — human review of risky outputs, and facts nobody verified — are also the two that decide whether a person is safe to put on this work. That is a separate interview, and not the one most teams run.

Related

TL;DR: The 15-point gate is the checklist we run before an AI-assisted product goes in front of a person — data minimisation, provider data-use terms, spend caps, prompt injection, disclosure, human review of risky outputs, and a tested rollback with a named owner. Its own lesson is that a control written down but never switched on will not catch itself: ours passed the gate on paper while the billing alert that would have flagged a dead backend sat unset.

Not legal, security or financial advice — a practitioner's instrument, and one that ages. Re-verify before relying on it. Governed performance.