Specifying and Procuring Enterprise AI: Five Practitioner Briefings

Counts differ because each database indexes a different set of publications. We treat OpenAlex as the canonical count; Google Scholar is not shown (no API, and crawling it violates its ToS).

Five briefings for people specifying, commissioning and measuring AI systems inside regulated organisations, where the deployment has to satisfy risk, audit and procurement rather than only a demonstration. Contents How To Write An AI Requirements Specification. Why specifications that describe a capability produce demonstrations, and specifications that describe a decision produce systems. What belongs in one, and the measurement clause almost every specification omits. Why Your AI Proof Of Concept Never Reached Production. The consistent reasons pilots succeed and then stall: built to impress rather than to run, no departmental owner, no agreed baseline, and a security review that happened last. Who Owns The Model You Fine Tuned. Base model licence, derived weights and training data can end up with three different owners. The derived weights encode how an organisation works and are the item most often left unaddressed in the contract. When Not To Build A Bespoke AI System. Four tests that separate the narrow set of cases warranting a bespoke build from the far larger number that should buy a product: process specificity, volume, whether the constraint is real, and ownership. How To Measure Whether AI Actually Saved Time. Why almost every reported saving is unverifiable, what a defensible measurement requires, and why measuring four axes beats reporting one blended number. Author: Micky Irons, Mickai LTD, United Kingdom. Originally published at mickai.co.uk.