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.

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.

The time it nearly stopped us

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.

The uncomfortable general lesson

he 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.

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

Keep Reading