You Need One AI Builder on Staff. Here’s How to Grow One

In almost every organization I assess, there’s one engineer who has been quietly building AI automation on their own time. A script that summarizes the overnight tickets. A flow that drafts replies to common requests. Nobody asked them to. They just found it useful.

That person is your most valuable AI asset and, right now, one of your bigger AI risks. Their work runs on personal credentials and stops the day they leave. The fix isn’t to shut them down. It’s to upskill that engineer into your AI automation builder, with the time, support, and guardrails the role needs. Here’s how I’d do it.

Why one builder matters more than another license

Licensed assistants cover generic productivity well: drafting, summarizing, searching. The use cases that change how a department works are usually specific to your processes and your systems. Those need someone who can connect AI to your ticketing system, your CRM, or your document store, and build something that fits the way your people actually work.

You can hire consultants for that, and sometimes you should. But consultants leave, and the knowledge of how your systems fit together leaves with them. One internal builder who knows your environment is a multiplier on every AI dollar you spend. For a mid-size IT team, one is enough to start.

Here’s how the assessment asks the question, and the 0 to 4 ladder I score it against:

K3. Does anyone on staff build with AI (APIs, automations, agents)?

0. No
1. Individuals experiment on their own time
2. A few people have built internal tools or automations
3. A named person or small team owns AI builds
4. A team builds with engineering discipline: testing, version control, monitoring

Levels 1 and 2 are common, and they’re a good sign: the interest exists. The jump to level 3 is organizational, not technical. Someone is named, given time, and made accountable for AI builds, instead of doing them on the side.

Who to pick

The best candidate often isn’t your strongest developer. Look for someone who:

• Already automates things without being asked, in any language or tool.
• Understands business processes, not just systems. They know why the finance team does month-end the way it does.
• Is trusted with system access, because this role will need it.
• Can explain their work to people who don’t care how it works, only whether it does.
• Is curious about failure, and tests what happens when things go wrong instead of demoing only the happy path.

In mid-size teams, this is often a systems engineer, a senior service desk analyst who scripts, or a business analyst with some coding. Title matters much less than habits.

What they need to learn

The skills stack for a first AI builder is narrower than people expect:

1. One scripting language, usually Python or PowerShell, well enough to call APIs and handle data.
2. APIs and authentication: service identities, scopes, secrets in a vault. The rules are in APIs before agents.
3. Calling a model through an API, including asking for structured output that other code can use reliably.
4. Grounding answers in your documents, so the model answers from your content rather than general knowledge.
5. Your low-code automation platform, if you have one. Much useful AI work is a model call inside an existing workflow.
6. Testing AI output: a set of sample inputs with known good answers, run every time something changes.
7. Cost awareness, so an experiment doesn’t produce a surprise bill. See managing usage-based AI spend.

An associate-level certification on your cloud platform can give this learning some structure, and it pairs well with a real build. Which AI certification your IT team should get first covers which one.

The asset: a 90-day builder plan

Days 1 to 30: foundations and a first build

• Protect at least one day a week for the role. Put it on the calendar and defend it.
• Give them a governed sandbox: a separate cloud account or subscription with a budget and logging, as described in cloud readiness for AI workloads.
• First build, read-only and low-risk: summarize a queue of tickets, or answer questions from a small set of internal documents.

Days 31 to 60: a real use case with a real owner

• Pick one item from your AI use-case register with a named business owner.
• Capture baseline numbers before building: how long the task takes today, how often, and how often it goes wrong.
• Build it read-only first. Put the output in front of the business owner weekly.

Days 61 to 90: harden and hand over

• Move the code, prompts, and configuration into version control.
• Write the test set: twenty or thirty realistic inputs with expected results.
• Turn on logging and write a one-page runbook: how to stop it, how to check what it did, who to call.
• Document it well enough that someone else could run it.
• Demo the result and the before-and-after numbers to leadership.

At day 90 you have a named builder, one production-ready tool, and the working habits of level 3.

What to protect your builder from

Becoming the AI help desk. Once people know someone “does AI,” every question lands on them. Route user support to the service desk and keep the builder building.

Becoming a single point of failure. Documentation, version control, and a second person who can at least restart things. The day the builder takes a vacation shouldn’t be the day the automation breaks unnoticed.

Building without a business owner. A tool nobody in the business asked for won’t be used, however clever it is. Every build needs someone outside IT who wants it; the reasons are in why IT-only pilots stall.

Pressure to add write access too soon. Leadership sees a read-only prototype and asks why it can’t just do the task. Hold the line until it has run reliably and has a human approval step for anything consequential.

From one builder to level 4

Level 4 is a small team with engineering discipline: a shared repository, code review, automated tests, and monitoring for everything in production. You get there by adding a second person, pairing them with the first, and making review mandatory. Two people reviewing each other’s work is the smallest unit of engineering discipline, and it’s usually the moment AI builds stop being a side project.

Mistakes I see at this stage

Picking the loudest enthusiast. Enthusiasm matters, but judgment matters more. Pick the person who tests their work.

No protected time. “Build AI tools in your spare time” keeps you at level 1 indefinitely.

Letting builds run in personal accounts. Everything moves to governed accounts and service identities before it’s used for real work.

Measuring the builder on volume. Five half-finished tools are worth less than one that’s documented, tested, and used every day. Judge the role on adoption and measured results, not on how many things got started.

Where does your team actually stand?

Building with AI is one of 24 questions in the AI Readiness assessment, which covers six dimensions: data, security, infrastructure, skills, use cases, and governance. The free version is 10 questions and gives you a score in a few minutes.

Get your free AI Readiness Score →

Want to see what the full assessment covers first? Flip through a complete 38-page sample report.

Related guides

• APIs Before Agents: Giving AI Access to Your Systems Safely
• Budgets and Alerts for Usage-Based AI Spend
• Which AI Certification Should Your IT Team Get First?
• Cloud Readiness for AI Workloads: What Actually Matters
• Turn Your Painful-Process List Into an AI Use-Case Register