Ten things organisations bring me in for. Some are strategy and architecture, some are hands-on modelling, and some are leading the teams that has to keep the result running after I leave. Each one lists when you would call me, what I actually do, what lands on your desk at the end, and the condition that makes the whole area not worth hiring anyone for.
AI strategy and enterprise architecture
When you call me inYou have pilots that impress in a demo and nothing that survives contact with security, procurement, or a second team trying to build on it.
I set the direction and the shape: reference architectures, standards, security patterns and landing zones, the review gates a solution has to clear before production, and the serving layer that lets business applications reach a model through a stable, secured contract. I do the arithmetic that decides hardware and hosting before anyone signs, so the cost of running the thing is a number rather than a surprise. Then I take the options, the cost and the risk into the room where the funding decision actually gets made, in the language that room uses.
What you getA reference architecture with the standards and review gates that go with it, a multi-year roadmap tied to business priorities, and a cost and capacity model your vendor can be held to.
Not worth doing ifNobody owns the platform after I leave. Standards without a named owner become documentation, and documentation does not stop the next isolated pilot.
Assistants that answer from your own documents
When you call me inThe assistant answers from your policies, contracts or records, and it is confidently wrong often enough that nobody trusts it any more.
I treat search as the main system rather than a preprocessing step: how documents get split, what metadata rides along with each piece, combining keyword matching with meaning-based matching, re-ranking what comes back, and instrumenting how often the right source was found at all. Where the rules change over time, the answer has to be the rule that was in force on the date asked about, with the clause cited so a person can verify it in seconds rather than trusting a paraphrase.
What you getA retrieval scorecard that separates “never found it” from “found it and answered badly”, the chunking and metadata design behind it, and the fixes ranked by what each one buys.
Not worth doing ifNobody will label which documents were relevant. Without that, every quality number is inferred from the final answer and the search step stays invisible.
Agents that know when to stop
When you call me inYou want the system to take actions rather than just answer questions, and nobody can tell you what it will do on the day it is wrong.
A planner that decomposes a request into typed tasks, specialist agents underneath it, a typed contract on every tool the agent can reach, step and token budgets, cycle detection, and a fallback ladder that narrows the answer and then hands to a person rather than inventing something. Anything the agent retrieves is treated as untrusted input, with injection containment, tool allowlists, output filtering and exfiltration checks kept in the regression suite rather than run once at launch.
What you getAn agent design with its tool contracts, budgets and escalation path written down, plus the red-team suite that runs on every change instead of on launch day.
Not worth doing ifThe task has no clean handoff to a human. An agent with nowhere safe to fail is a liability whatever its accuracy.
Models beyond the chatbot
When you call me inThe decision that actually costs you money is a forecast, a risk score or a triage call, and a language model is not the answer to it.
Most of the value in a large organisation is still ordinary machine learning done properly. Demand forecasting reconciled across item, site and network so the plans add up. Fraud and risk scoring under extreme class imbalance, measured at a fixed alert budget because analyst capacity is the binding constraint. Duration and return to work as a survival problem with competing risks kept separate. Document understanding over mixed correspondence, with human review on anything that drives a payment. Recommenders, ranking, and the sequence models underneath extraction.
What you getA model that fits the decision it feeds, a metric chosen to match what somebody actually does with the output, and backtesting that does not flatter whoever picked the split.
Not worth doing ifThe decision it feeds is not really made on the number. A model attached to a process nobody is willing to change is an expensive report.
Confidence you can act on
When you call me inNobody can tell you which of the system’s answers are safe to use without a person checking them first.
I measure whether the stated confidence matches reality, correct it where it does not, and set the threshold where sending a case to a person is cheaper than getting it wrong. Where a hard guarantee is needed, conformal prediction puts a provable error rate on the system without assuming the model is any good.
What you getA measured calibration report, a threshold policy with the cost arithmetic behind it, and a routing rule your operations team can actually run.
Not worth doing ifThe calibration set stops resembling production. Everything here assumes the future looks like the sample you measured, and a quiet shift in the data invalidates the whole apparatus without raising an alarm.
Evaluation that can fail
When you call me inThe demo works, the metrics look good, and the system keeps embarrassing you in front of real users.
Building evaluation sets from failures you have actually seen rather than from convenient examples. Error taxonomies, results broken out by segment, hard cases held separately from representative ones, model-graded scoring checked against human raters instead of trusted on faith, significance testing on every claimed improvement, and the whole suite wired into the build so a prompt change cannot quietly cost you recall.
What you getAn evaluation set built from your real failures, with a named owner, and a reporting format that makes a regression impossible to miss.
Not worth doing ifNobody is willing to own the labelling. Evaluation is a data-collection problem wearing a metrics costume, and it stalls the moment annotation has no owner.
Data that can leave the building
When you call me inYou need to use sensitive data, or publish something derived from it, and nobody is willing to sign off.
Deciding what crosses a boundary, and proving it. Detecting personal information and measuring how often the detector misses, irreversible redaction, differential privacy for aggregate releases, budget accounting across a whole query workload, and re-identification risk assessment. Alongside it, the governance a reviewer asks for: subgroup performance testing, explanations an assessor can act on, data residency, lineage, and model risk controls built into the first diagram rather than the week before launch.
What you getA written threat model, a measured detection error profile, a privacy budget with a ledger against it, and the fairness and explainability evidence a reviewer will ask for.
Not worth doing ifThe threat model is unstated. Detection rates, noise levels, and budgets are all meaningless until someone writes down who the adversary is and what they already know.
From pilot to production, and staying there
When you call me inThe model works on somebody’s laptop, and every release since has depended on that person being available.
Model and prompt registries, versioned data, automated evaluation gates a release has to clear before promotion, pipelines across development, test and production, and a rollback path that does not depend on anyone being awake. Then the monitoring that tells you it is still working: answer quality, retrieval quality, drift on the inputs, latency, failure rates and cost per interaction, reported as numbers rather than opinions.
What you getA repeatable, auditable deployment path, the monitoring that sits on top of it, and an incident runbook for the day a model starts drifting.
Not worth doing ifThe organisation cannot yet deploy ordinary software reliably. Machine learning operations built on broken software operations inherits every one of those problems and adds several of its own.
Data platforms your models can stand on
When you call me inEvery model project starts with six weeks of finding, cleaning and arguing about the data, and the argument never gets settled the same way twice.
Before there is a model there has to be a platform. Lakehouse and warehouse design, streaming and batch pipelines, feature stores, vector stores, and the multi-cloud and event-driven integration underneath all of it. Then the part most programmes skip: who owns which dataset, what a consumer is entitled to assume about it, where it came from, and what happens the day it changes. I have led data architecture teams through exactly this, and cut the path from raw event to usable training set from days to hours, which is what makes frequent model refreshes possible at all.
What you getA target data architecture with data contracts, lineage and ownership named against each domain, and pipelines a second team can build on without asking you first.
Not worth doing ifThe organisation will not agree on who owns a dataset. Every technical fix downstream of that question is temporary, and you will be back inside a year.
Teams, practices and labs
When you call me inYou have people doing artificial intelligence work and no practice around them, or you need somebody to lead the group while it is still being built.
I have built machine learning, data and architecture practices from nothing inside large organisations, led data science teams, data architecture teams and engineering teams, and run a corporate research lab where results had to be publishable and also had to ship. In practice that means the operating model, the intake and prioritisation path, the decision forums, hiring and mentoring, and the enablement sessions that leave a client able to run the thing without me. It also means saying no to the proposals that were never going to work, early, in front of the people who proposed them.
What you getA working operating model with named owners, a prioritised pipeline of work that is genuinely deliverable, and a team that does not need me in the room.
Not worth doing ifLeadership wants the capability without the authority to change how decisions get made. A practice that cannot decline a bad request is a queue, not a capability.
Connect on LinkedIn