AI implementation lead
The person inside a company who has to make the tools actually land: choosing what to try first, checking whether it works on this company's own work, deciding what it is allowed to do unsupervised, and being there when it gets something wrong.
This is not a probability of losing your job. It combines how much of the role's task load is exposed to automation with how far adoption has actually gone — useful for comparing occupations on one consistent basis, and for nothing else.
The person accountable for AI adoption inside a company that buys and applies these tools — not a model researcher and not the engineer building the product a company sells. Common titles are head of AI, AI lead, transformation lead, sometimes a one-person function reporting to the founder. Confidence is low and the reason is unusual: this occupation is young enough that there is little published evidence about it, and almost everything written about it is written by people selling AI adoption services.
What is actually changing#
The unit of analysis is the task, not the job title. A role is not replaced — its task mix shifts.
Deciding what to try first
Still human-led≈ Platform inferenceLooking at everything the company does, and picking the one or two places where a tool would actually change a number — rather than the places that demo well.
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
Being augmented≈ Platform inferenceTaking real cases from your own business — not the vendor's demo — running the tool on them, and counting how often it is right, wrong, and confidently wrong.
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
Being augmented≈ Platform inferenceConnecting the tool to the systems the company already runs on, so the output lands where the work actually happens instead of in a separate window nobody opens.
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
Still human-led✓ Evidence-backedWriting down which actions the system takes alone, which need a person, what it must never send, and what happens when it is unsure.
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
Still human-led≈ Platform inferenceSitting with the people whose work it changes, finding out why they went back to the old way, and fixing the reason rather than reminding them again.
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
Still human-led≈ Platform inferenceWorking out what happened, telling whoever was affected, deciding whether to switch it off, and saying what changes so it does not happen the same way twice.
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.
Which technologies matter here#
Four separate signals. They are deliberately not added together — a job exposed to two technologies is not twice as exposed.
How it got here#
The index is not a static number. This is where it would have sat at each capability checkpoint since ChatGPT — reconstructed, and labelled as such.
● 2 verified events for this occupation, plotted at the date it happened — the parts of the line near a marker are anchored to something checkable.
The one curve on this site where the occupation barely existed at the left-hand edge, so the early points describe today's work projected backwards rather than a job anyone held in 2022 — worth saying plainly, because a reconstructed line looks equally confident either way. It is low and nearly flat because almost every task here is judgement inside one specific company: what to try first, what the tool may do unsupervised, why people went back to the old way. The gentle rise is evaluation tooling and code generation taking over parts of testing and integration. Read the low number as a description of the work, not a statement about the headcount: this function is funded as a transition cost, and the risk to it is the transition ending, which no automation index measures.
A flat line is not a forecast of safety. It says which tasks automation has reached so far — the occupations that moved least here are the ones where the constraint is physical or regulatory, and both of those can change.
Recent changes#
The EU, and only for deployers of high-risk AI systems — the companies that buy and use them, not the providers that build them. What it establishes is that giving a specific person the competence, training and authority to oversee such a system is a legal obligation in the EU rather than a management choice. Article 26(5) further requires deployers to monitor operation and, on finding a risk, to inform the provider and the market surveillance authority without undue delay. What it does not establish: the law does not say who that person must be and does not require a dedicated post — a company may spread the duty across function heads. Attaching it to this occupation is our inference about where it lands in practice. Article 6(1) and its corresponding obligations are deferred to 2 August 2027 and are outside this record.
Regulation, subsidy or public procurement is requiring or funding adoption — the mirror of a constraint. It shows adoption is being required, not that it has happened, so one mandate is never enough on its own; two independent ones are.
The United States federal executive branch only, not private employers. What it establishes is that this role is required to exist by rule rather than created at each organisation's discretion. Three things need saying. First, the memorandum rescinds and replaces 2024's M-24-10 and deliberately redefines the role: it describes the Chief AI Officer as a champion of adoption rather than a layer of oversight, so this record supports the adoption-driving side of the job, not the gatekeeping side. Second, it requires an agency to identify an officer — not a headcount, a budget or a team; an agency may name its existing chief information officer. Third, a rule requiring a post to exist and that post actually doing the work are two different layers, and this site records it at the policy layer, where one record changes no task judgement on its own.
Regulation, subsidy or public procurement is requiring or funding adoption — the mirror of a constraint. It shows adoption is being required, not that it has happened, so one mandate is never enough on its own; two independent ones are.
What this means for you#
There is no established path into this job, which cuts both ways: nobody can say you are unqualified, and nobody can tell you what qualifies you. What people are actually hired on is evidence that they have made one thing land end to end in a real organisation — a before number, an after number, and an honest account of what broke. One such story beats any certificate, and certificates are what most of the market is selling.
Your leverage is that you know where this company's work actually breaks, which no vendor and no model has. The risk is structural rather than technical: this function is funded as a transition cost, and transition budgets end. The people who stay are the ones who moved from running the programme to owning a number the business already cares about.
Your options#
Four directions, each with its real constraints and one thing you can test this week. Continuing as you are is a legitimate choice — it just has to be a chosen one.
Attach yourself to a number that predates you
Programme budgets get cut in the year after the excitement. A function measured on cycle time, conversion or cost per order is measured on something the business cared about before AI arrived and will care about after.
Owning a real number means owning it when it goes the wrong way for reasons outside your control, and it usually means giving up the comfortable position of advising rather than delivering.
Name the one number your work should move, then find out who owned that number before you existed. Go and ask them whether they think you are helping. Their answer, not your dashboard, is where your funding comes from next year.
Write down the boundary nobody has written
In most companies what the tools may do unsupervised has been decided by default, by whoever configured them. Turning that into a written, agreed policy is unglamorous, it is the thing that prevents the incident, and it is a deliverable with your name on it.
It forces disagreements into the open, which is why it gets postponed. You need someone senior to sign it, and asking for that signature is asking them to accept the risk explicitly rather than implicitly.
List every action your tools currently take without a person in the loop. Not what the policy says — what they actually do today. If the list surprises anyone in the room, the boundary was never set, it was inherited.
Move into the function you were helping
You have spent a year learning how one function actually works, in more detail than most people in it. Operations, finance and customer service all now need someone who understands both the work and the systems, and those seats are permanent in a way a transformation programme is not.
You give up the interesting breadth for one domain, and you will be managed by someone who has been in it longer. The first year you are a specialist in the tools and a novice in the work.
Pick the function whose problems you have enjoyed most this year and ask its head one question: if this programme ended tomorrow, what would you still want done? Whatever they name is the permanent job hiding inside your temporary one.
Do it from the outside, for many companies
The pattern knowledge you build — which sequence works, where pilots die, what the second year looks like — is worth more across ten companies than inside one, and most companies will never hire a full-time version of this role.
The market for this advice is crowded with people who have never delivered anything, which means you will be priced against them until you can show outcomes. And you lose the thing that made you effective: being inside, where people tell you the truth.
Write the one-page account of the last thing you shipped: the number before, the number after, what broke, and what you would do differently. If you cannot fill the page with specifics, you are not ready to sell the pattern — and writing it is how you find that out cheaply.
Common questions#
Both, and which one it is at a given company is worth checking before you take it. It is a real job where it owns a budget and a number the business already tracked. It is a title where it owns a programme, a tool inventory and a steering meeting. The second version is funded as a transition cost, and transition costs end.
This role's clock is different from every other page on this site: the risk is not that a machine does it, it is that the transition finishes and the function dissolves back into the departments it was helping. The signal is where your budget line sits. If it is a project or programme line, ask each year whether it renewed and by how much. If it moved into a department's operating budget, the job has become permanent — and that move, not any announcement, is the thing to watch.
Enough to tell a real evaluation from a demo, and to know when a vendor's answer is evasive. Beyond that, the scarce input is knowledge of this company — which step is the real bottleneck, whose numbers move, who will resist — and that is collected by walking around, not by reading documentation. The common failure is a technically strong lead who automates the step that was easiest to automate rather than the one that mattered.
Because the index measures how much of the work automation is taking over, and almost none of this job's work is. That is not the same as safe, and the page says so on every task: this role exists because a transition is under way. Read the low number as a description of the work, not as a promise about the headcount — those are different questions, and this site keeps them apart on purpose.
Ask for one thing: a case where it did not work, and what they did next. Anyone who has actually put tools into a working business has that story, because the first attempt usually fails on something nobody predicted. A vendor who only has successes has either not shipped or is not telling you about the part you most need to hear.
Method and sources#
- Assessment date
- 2026-09-11
- Basis of the task judgements
- 1 evidence-backed · 5 platform inference · 0 not enough evidence
- Verified events
- 2