Your First AI Hire Will Mostly Do Data Work

You are hiring an AI engineer to build AI. Unless your data is ready, you are hiring a data engineer with a more expensive title, and the AI work waits.

The job description says models, agents, and production features. The first backlog often says something else: locate the right tables, resolve customer IDs, clarify who can access the data, and determine whether an answer is correct. Those are necessary tasks, but they can consume the time you hired someone to spend building AI.

This is not a case against hiring an AI engineer. It is a case for preparing the work around that hire. When data readiness and feature development move together, your first AI project has a much better chance of reaching actual users instead of becoming another demonstration that never leaves a laptop.

Why First AI Projects Stall

A first AI initiative can look like a model-selection problem. The real blockers often appear earlier: scattered source data, uncertain access, inconsistent business definitions, and no agreed way to judge the output.

The Data Exists, But Not In A Usable Form

A customer question may require records from the CRM, billing platform, help desk, and warehouse. Each system has a useful part of the answer, yet none contains the complete picture. A model cannot repair a missing join or settle a disputed definition merely by sounding confident.

An engineer who expected to build retrieval, tools, and application logic ends up tracing identifiers, decoding old SQL, documenting fields, and finding out which source is authoritative. If the business has not done that work, AI development waits behind data engineering.

Permissions Are Unclear

Being technically able to retrieve a document is not the same as being authorized to show it. Internal policies, personnel records, customer contracts, and financial reports may share a storage system but require different access rules.

Permissions should be defined at the source, enforced in retrieval and application access, and tested with users who have different roles. Otherwise, an internal assistant can expose information its user was never meant to see. This is a design requirement, not a prompt-writing exercise.

Nobody Can Say What A Good Answer Looks Like

“Make the assistant accurate” is not an acceptance test. The team needs actual questions, trusted answers, approved source documents, and examples of when the system should say it does not know.

This is consistent with NIST guidance on measuring AI systems, which emphasizes documented test sets, metrics, and evaluation methods. If the team cannot evaluate an answer before launch, it will struggle to recognize regressions afterward.

The Business Owner Is Missing

An engineer can make a prototype run. They cannot decide which policy is current, whether a revenue total is authoritative, or whether the result changes how work gets done. Those decisions belong to a named business owner who will use the system, review mistakes, and approve its scope.

The Four-Point AI Readiness Check

Before opening another requisition or approving a proof of concept, test one real use case against four practical requirements. Give each requirement a score from zero to two, then inspect the gaps.

Scoring: 0 = absent or unknown; 1 = partially in place; 2 = working and verified. Total possible score: 8.

How to read your score: A score of 0–3 suggests the foundation needs attention before a serious build. At 4–6, narrow the pilot and close the specific gaps in parallel. At 7–8, the use case is better positioned for a controlled pilot. This is a planning heuristic, not a predictive industry benchmark.

A high score does not replace security review, tests, or business sign-off. It simply reduces the number of unknowns your first AI hire inherits.

Ask For Evidence, Not Optimism

For accessible data, ask someone to produce the necessary records and explain their meaning. For permissions, test what two different user roles can actually retrieve. For evaluation, ask for real questions with approved answers. For ownership, name the person who will review the tool every week.

If any of these requests triggers a long chain of “we need to find out,” the project has discovered its actual starting point. That is useful information before you commit to a broad AI roadmap.

Pick A First AI Project That Ships

The strongest first project answers a question people already ask, uses information available today, and makes a wrong response easy to catch. It also has a clear, measurable definition of success.

Start With A Repeated Internal Question

An internal assistant over approved policies, operating procedures, or reports is a sensible first candidate. People already need the answers, the material has identifiable owners, and employees can review a cited response before acting on it.

Keep the initial knowledge base narrow. Give the assistant an explicit document set, show its sources, restrict access by role, and allow “I cannot verify that” as a valid response. A smaller assistant with reliable answers creates more trust than a broad one that guesses.

Put Self-Service Questions On Trusted Warehouse Data

Another candidate is self-service analytics over a few signed-off metrics: current orders, inventory by location, or weekly service volume. The important step is not connecting a language model to every table. It is establishing which definitions are approved and what filters are allowed.

If your data work is still split between business reasoning and implementation, read Two Brains, One Pipeline: AI-Assisted Data Work. The distinction matters here: the business decides what the measure means; engineering implements and tests it.

Define Success Before Building The Interface

Choose a few observable measures: whether answers cite the right source, whether the system correctly declines unsupported questions, how often users need escalation, and whether the workflow saves a real manual step. Record examples of acceptable and unacceptable responses before choosing a model or framework.

For retrieval-based assistants, Microsoft’s RAG evaluation guidance distinguishes retrieval quality, groundedness, relevance, and completeness. That separation is helpful because a wrong answer can come from retrieving the wrong document, misusing a correct document, or failing to answer the actual question.

Keep The Cost of A Wrong Answer Low

Start where a human can review the output before money, permissions, customer status, or regulated decisions change. Early systems should suggest or explain, not silently execute consequential actions. This lets the team learn from failures without turning an experiment into a production incident.

What Not To Start With

A striking demo is not necessarily the right first production system. Save expansive or high-risk automation for when data access, evaluation, ownership, and operational controls are already established and tested.

- Autonomous customer-facing agents: Do not begin with a system that can issue refunds, change accounts, or make binding promises without adequate review, limits, and rollback procedures.

- Projects dependent on missing data: If the required event, document, or relationship is not captured today, a new model will not create a reliable historical record.

- High-stakes answers without expert review: Avoid workflows where a plausible error could create significant legal, financial, safety, or compliance consequences.

- An assistant for everything: An undefined, enterprise-wide question-answering tool is difficult to secure, evaluate, and maintain. Begin with one team and one bounded information domain.

These are not permanent exclusions. They are reasons to sequence capability and controls instead of asking a first hire to build the most difficult system first.

How To Make Your First AI Hire Productive Fast

Once the first use case is bounded, organize delivery so the engineer can build the feature while data and business owners resolve dependencies. Parallel preparation matters more than a longer list of AI tools.

Run The Data Track And AI Track Together

The data track inventories sources, resolves identifiers, documents definitions, checks freshness, and implements access rules. The AI track builds retrieval or tool calls, prepares the interface, records failure behavior, and runs an evaluation harness. Both tracks work toward the same approved questions and expected answers.

This division is not a license for separate silos. The two tracks should review the same examples, agree on what changed, and make dependencies visible. Otherwise, model development races ahead of a data layer it cannot safely use.

Give The Hire An Evaluation Set On Day One

Start with questions collected from actual users, not polished examples invented for a demo. Include simple questions, ambiguous questions, outdated documents, missing information, and requests a particular role must not answer. For each item, record the approved answer, source, and expected refusal or escalation behavior.

Run the set after meaningful changes to data, retrieval, prompts, and application logic. A change that produces more fluent output but worsens groundedness should not pass simply because the demonstration feels better.

Make Ownership And Access Explicit

A named business owner should approve the use case, trusted sources, operating limits, and acceptance criteria. A technical owner should approve permissions, logging, deployment design, and monitoring.

The first AI engineer can then concentrate on implementation without becoming the unofficial policy authority for every department.

Let AI Accelerate The Drafting, Not The Decisions

The delivery advantage is not that an agent can generate more code. It is that repetitive work becomes cheaper to prepare and easier to check while architectural and business decisions remain accountable.

- AI handles the reading and first draft. Existing SQL, document structures, report definitions, and application code can be summarized and turned into reviewable starting points.

- A senior architect makes the calls. One accountable lead settles data grain, naming, structure, dependencies, and trade-offs instead of sending decisions through repeated handoffs.

- Quality gates catch mistakes early. Specifications, test cases, access checks, and review criteria are applied before changes are accepted or deployed.

- Scope stays close to actual usage. Start with the questions, reports, and workflows that real users depend on rather than rebuilding every possible integration.

I use my proprietary agentic AI software factory to organize approved specifications, produce implementation drafts, run checks, and preserve review evidence. It does not decide who may see sensitive data, what business measures mean, or whether an answer is acceptable. Those remain human decisions.

Enable The Team, Not Just The Specialist

The first AI feature will need people in operations, support, finance, or another business function to use it and report errors. Give them a simple review process: flag a wrong answer, identify the expected source, and decide whether the content, retrieval, or business rule needs correction.

If AI knowledge remains with one employee, every change becomes a queue for that person. Shared definitions, documented evaluations, and a business feedback loop turn the first use case into a reusable way of working.

The Data Layer Is The Long Pole

The AI part of a first AI project is rarely the slow part. The data is. Getting the data layer and evaluation set right in parallel lets the first useful feature reach people sooner and remain trustworthy.

I have spent more than 20 years building data and software systems. At Avalara, I grew a data organization from one person to 24, worked with petabyte-scale Snowflake environments, and helped enable more than 2,000 data and analytics users. Those are experience credentials, not a claim that every AI pilot follows the same timeline.

What that experience changes is the order of work. Instead of hiring someone and hoping a useful application emerges from disconnected systems, I would start with the decisions the business needs answered, identify the smallest trusted data slice, and build tests before scaling access.

The same principle applies to modernization: What An AI-Assisted Warehouse Refactor Looks Like shows how inventory, business definitions, and validation can precede broad replacement work. The first AI hire benefits from that same discipline.

Your first AI engineer should spend time on retrieval, application behavior, evaluation, and production workflows, not spend the entire first assignment discovering what your numbers mean. The difference is rarely a smarter job posting. It is a more deliberate starting point.

For hiring teams still preparing the data foundation, the previous article in this series, Before Your First Data Engineer Starts, addresses the groundwork a new data hire should inherit.

Score The Foundation Before You Hire

A first AI project does not need a perfect enterprise data platform. It needs one useful question, the data required to answer it, enforceable permissions, an evaluation set, and a business owner who will keep using the result.

Score yourself on the four checks, then book a free strategy call at onshore.consulting.