Practice
AI and automation that survive an audit
A language model is an excellent generator of proposals and a poor place to make decisions. We build systems where AI proposes, deterministic code rules, and a person approves anything that leaves the organisation.

How we look at it
Most failed AI deployments are not caused by a weak model but by three unanswered questions: who carries the consequence of an error, where the quality gate sits, and what it costs at production volume. We start there, because those answers determine the architecture, not the choice of model provider, which will change its pricing or retire a version within the year anyway. We also know from our own invoices that a pilot always looks cheap: regenerating one of our analytical artifacts costs about sixteen million tokens, and we knew that number before deciding to run it on a schedule, not after the bill.
What we have built
We built a company AI hub with six in-house MCP servers, CRM, mail and calendar, ERP, document search, per-user memory, and a WhatsApp gateway that joins one number to five applications: HMAC signature verification, deduplication in Redis, routing by command and session. The cost of every query is visible in the observability layer via OpenTelemetry; a cheap model classifies and filters, an expensive one only synthesises, and repeated questions are caught by a semantic cache on embeddings. In a system verifying label compliance against FEDIAF requirements and EU law, five reliability layers operate, confidence scoring, an independent second reading of the numbers with cross-comparison, thresholds computed deterministically in code, escalation to a human, a fixed test set, and four of the five are not the model. A shelf-exposure audit turned 2,827 photographs from seven markets and 54 retail chains into 26,864 product observations, 86 percent with a price read. Supplier price-list validation cut 8–12 hours of manual work to a few machine minutes plus 15–30 minutes of review, we report both numbers, because they are only true together. In production planning the decision-maker is a constraint solver, not a model. In a recruitment system there are no automatic rejections: every score carries a rationale and a source quotation, and the whole design targets the EU AI Act's requirements for high-risk systems, with a DPIA and defined retention.
What follows
What emerges is a system you can show an auditor and a regulator: the rationale for every suggestion on record, personal data redacted before it reaches a model, and a known unit cost. It costs more at the design stage and demos less impressively, but it does not have to be rewritten when the solution leaves the pilot.