AI implementation lead — tasks, one by one

Deciding what to try first

The binding input is not knowledge of the tools, it is knowledge of this company: which step is actually the bottleneck, whose numbers move if it changes, and who will be angry. That information mostly is not written down anywhere, so it cannot be retrieved — it has to be collected by someone who can walk around and ask.

Hard to automate is not the same as durable. This whole role exists because a transition is under way; when the tools become ordinary the way spreadsheets did, choosing what to automate becomes part of running a function rather than a function of its own. The safety here is the safety of scaffolding.

Checking it on this company's own work

Evaluation tooling has become genuinely good and much of the scoring can be run automatically. What does not automate is deciding what counts as correct for this company, which is a business judgement wearing a technical costume — two firms doing the same task can have different thresholds for the same error.

A good evaluation tells you the tool works on the cases you thought to collect. It says nothing about the cases nobody thought of, and those are where the expensive failures live — so a passing score is a reason to start watching, not a reason to stop.

Wiring it into what is already there

Writing the integration code is one of the things these tools are best at, so the build got much cheaper. Knowing which of the four systems holds the authoritative version of a record, and which field is quietly lying, did not — that knowledge lives in people who have been at the company for years.

Cheap integration is why pilots multiply and why most of them are still running as pilots. Being able to connect a tool in an afternoon does not establish that anyone changed how they work, and the two get reported as the same milestone.

Deciding what it may do unsupervised

This is an allocation of liability, not a configuration task. Deciding that a tool may commit the company to a price, a date or an apology is a decision about who answers for it — and a system cannot authorise its own authority.

Guardrails being human work does not mean they get written. In most companies nobody has been given this task, so the boundary is settled by default — by whoever configured the tool — and that default is invisible until something goes out that should not have.

Getting people to actually use it

Adoption fails for reasons people will not put in a survey: it makes someone look slower, it removes the part of the job they liked, it is one click further from where they already are. Finding that out requires trust, and acting on it requires authority to change the process.

This is the task most likely to be cut, because it is slow and produces no artefact. A company that buys the tools and skips this gets the licence cost and the pilot, and reports both as progress.

Being there when it gets something wrong

Every public rollback this site records has this shape: the technical failure was recoverable and the accountability gap was not. Someone has to own the outcome in front of a customer or a regulator, and ownership is the one thing that cannot be delegated to the system that caused it.

Carrying the blame is not the same as holding the authority. This role often answers for decisions it cannot overrule — the budget, the vendor, the deadline were all set elsewhere — and that combination is the most common reason people leave it.