Almost nobody in this trade hands you anything in writing about the AI inside the thing they sold you. You are told it is powered by AI on the way in, and then nothing. So we wrote a sheet that answers the six questions a sensible person would ask, and the plan is that it goes out with every build.
Where this has actually got to
This has not gone out with a delivery yet. The sheet below is written and agreed between the two of us; no client has received one attached to a real job. We are publishing it now because committing to something in public is how it stops being a good intention, but it would be a small lie to describe it as something we already do. When the first one ships with a build, this box goes and the page says so instead.
Most of what we build is ordinary software with one or two steps that use a model. The sheet marks which steps those are, because "it is AI" is usually true of about a tenth of the thing and people reasonably want to know which tenth.
Named, with the provider. If it changes later — because a better one arrives, or one gets retired — that is a change we tell you about rather than one you find out about.
Exactly which fields go to the provider, which stay on your side, and what is kept afterwards. Where a job can be built so nothing sensitive leaves at all, the sheet says that is what we did.
Every build has a line it will not cross on its own. The sheet writes that line down: what gets flagged, what waits for a person, and what simply stops.
Not a disclaimer — the actual failure modes we found while testing it, and what we did about each one. A system nobody can describe the failures of has not been tested hard enough.
You are, and the sheet says so plainly. Nothing we build makes a decision you are not allowed to overrule, and in the jobs where being wrong is expensive it will not act without you.
Sooner or later a customer, an insurer, an auditor or somebody's legal team will ask what the AI in your business actually does with their data. If the honest answer is that you would have to ring your developer and hope he remembers, that is a problem you bought along with the software.
The other reason is narrower and more selfish. Writing this down forces us to have decided it. You cannot fill in “what it does when it is not sure” on a system where nobody chose, and the sheet has already changed how we scope a job.
It is the same instinct as publishing how we count: the claims worth making are the ones somebody could check.
What it is not
Not a terms-and-conditions page
It is one side of A4 in the same plain English as everything else we hand over, and it is about your build specifically rather than about us in general.
Not a compliance product
We are not selling it, it is not an add-on, and it does not cost anything. It goes in the handover pack with the instructions.
Not a promise nothing will go wrong
Half of it is about what will go wrong. A sheet that claimed otherwise would be the thing it is meant to replace.