AI engineer

AI adoption by role

The AI engineer builds and runs the parts of a system that are probabilistic: prompts, models, retrieval, tools and the runtime that connects them. In a regulated organization the hard part is not getting a good answer once. It is proving, version after version, that the system stays inside its intended use: evaluation sets with thresholds on every risk slice, bounded agency at runtime, and every prompt, model, corpus and tool treated as a versioned component under material-change rules. The AI engineer measures and builds; product, risk and independent validation decide whether the residual risk is acceptable.

Numbers on this page are illustrative.

An AI system is only as trustworthy as its last evaluation run on its current versions. Change a prompt, a model, a corpus or a tool, and the old evidence no longer describes the system.

1. At a glance

Item	AI engineer
Mandate	Build AI (artificial intelligence) components that are measured before release, bounded at runtime, versioned as a whole, and monitored with clear revalidation triggers
Primary decision	What "good enough" means in numbers for each risk slice, and which actions and tools the runtime may use
First safe win	A versioned evaluation set with risk slices and thresholds for one Medium-tier use case, run in CI (continuous integration) on every prompt or model change
Biggest failure mode	Demo-driven release: a handful of good examples, no slices, no thresholds, and a model upgrade shipped as a configuration change

Line: 1st line · Family: Build · Variants: ML engineer, agent and LLM application engineer

Variant	What differs
ML (machine learning) engineer	Trains, tunes and scores models on the organization's own data, often structured. Works closely with data engineering on features and lineage. A model that informs credit, pricing or customer outcomes is normally in scope of model risk management
Agent and LLM application engineer	Builds on a foundation model, an LLM (large language model) from an approved provider: prompts, retrieval, tool definitions, the agent runtime and its guardrails. Most changes are prompt, corpus, tool or provider changes, not training
Shared by both	Evaluation sets with slices and thresholds, versioned components, material-change assessment, monitoring and revalidation, and separation from independent validation

2. Your journey: first steps to fully adopted

This is the path from your first month to a fully adopted way of working. The order of the steps is the same in any organization; only the weight of the controls changes.

Start here: your first steps

Confirm the approved models, providers and data terms for each environment with platform and third-party risk.
Pin every prompt, model, index and tool in a version manifest kept in the repository.
Write a first evaluation set with risk slices and thresholds for one Medium-tier use case, from real past cases.
Run that set in CI on every prompt or model change, so one failing slice blocks the merge.

Fully adopted: how the work runs

Moment in the work	Before AI	Fully adopted (Stage 4–5)	Decision that stays human
Use case arrives	An idea goes straight to a demo with a few good examples	The intake card sets the risk tier; you list failure modes and risk slices before you build	The product owner sets the intended use; intake decides the route
Design	The prompt says "never act on accounts"	Bounded agency in the runtime: least-privilege tools, a policy enforcement point, step and spend limits, an approval gate	Security challenges tool scopes; a person approves each consequential action
Evaluation	One average score on hand-picked examples	A versioned evaluation set, a threshold on every slice, repeated runs, a calibrated grader; agents draft cases you review	The product owner accepts residual risk per slice
Release	A model upgrade ships as a configuration change	Version manifest and evaluation diff in the change record; release behind a flag with a tested kill switch	The release manager approves; the policy owner decides if the change is material
Monitoring and drift	Problems surface as complaints	Signals on citations, abstentions, question-mix drift and unit cost; a revalidation trigger steps the system down	A named person closes each revalidation

What changes for the organization

Before	After
AI quality is argued from demos	AI quality is a number per slice, rerun on every version
A model or provider change surprises the organization	Every change is evaluated before release, and a failing slice steps the use case down
Each team invents its own agent limits	Reusable evaluation sets and tool definitions in the catalog let other roles delegate safely

In any organization

Who covers it: in a small or unregulated organization a developer often builds the AI component; a peer from another team reviews the evaluation set, and the product owner accepts the thresholds.
What scales: the committee, the model inventory and formal validation scale down with risk. Pinned versions, a threshold on every slice, least-privilege tools and human approval of consequential actions never do.

3. Your decisions

Decision	You own / advise / challenge	Inputs	Escalation	Cannot be delegated
Evaluation design: cases, slices, metrics	Own; the QA (quality assurance) engineer co-designs; independent validation challenges for High tier	Intended use, risk tier, failure modes, past incidents, user research	AI or model risk	Yes
Thresholds per slice	Propose; the product owner accepts residual risk; AI or model risk confirms for High tier	Baseline, cost of a wrong answer, slice size	AI or model risk	Yes
Runtime agency: tools, scopes, limits, confirmations	Own the implementation inside the architect's pattern; security challenges	Reference pattern, threat model, action boundary	Security	Yes
Model choice inside the approved list	Own the technical recommendation; platform runs the gateway; third-party risk approves the vendor	Evaluation results, unit cost, latency, residency terms	Architect, third-party risk	Yes
Material-change classification of a version change	Advise with evidence; the policy owner decides the route	Change description, evaluation diff, scope of use	AI or model risk	Yes
Monitoring thresholds and revalidation triggers	Own the definitions; production support runs the alerts	Evaluation results, launch baseline	Product owner, AI or model risk	Yes
Release of a version	Advise: technical readiness and evidence; the release manager approves the change	Evaluation report, independent validation where required	Change control	No (you produce evidence; others approve)

4. Two kinds of adoption

Kind	What it means for the AI engineer	Example on this site
How you work with AI	A coding agent drafts code, evaluation cases and analysis scripts; a model may act as a grader, calibrated against human labels. You review generated cases before they enter a set	An agent proposes 40 new negative cases for the policy assistant; you keep 25 after review and record why the rest were rejected
What you build and operate that contains AI	The evaluated, bounded, versioned AI component and its monitoring. You also supply the evaluation sets that let other roles delegate tasks at Stage 3	The policy assistant runtime; the evaluation sets behind the coding agent's delegated tasks in the due-date change

Evaluation sets with risk slices

An evaluation set is a versioned list of cases with expected behavior. A risk slice is a group of cases that share a failure mode or an affected population. The threshold applies to every slice, so a strong average cannot hide a weak slice. See evaluation and the policy assistant and lab L4.

Slice	What it tests	Metric	Threshold (illustrative)
Answerable	Questions the approved policy answers	Each material claim entailed by its citation	≥ 95%
Out of scope	Requests for account data or actions	Abstains and names the boundary	100%
Not in policy	Plausible questions policy does not cover	Abstains and points to escalation	≥ 98%
Stale document	Answers that exist only in a withdrawn version	Cites only current versions	100%
Prompt injection	Instructions hidden in a question or a document	Ignores them; no change of behavior	100%
Paraphrase stability	The same question asked five ways	Same answer and same citation	≥ 95%

An evaluation set configuration, versioned next to the code (illustrative):

# evals/policy-assistant.yaml
eval_set: policy-assistant
version: 1.3.0
system_under_test:
  prompt: policy-assistant-prompt@0.4
  model: approved-model-id@2026-09     # pinned, never "latest"
  index: policy-index@2026-10-27
  tools: [search_policy@1.1]
grader:
  type: rubric+model
  calibration: 200 human-labelled cases, agreement >= 0.90
slices:
  answerable:      { cases: 80, metric: claim_entailed,  threshold: 0.95 }
  out_of_scope:    { cases: 30, metric: abstained,       threshold: 1.00 }
  not_in_policy:   { cases: 40, metric: abstained,       threshold: 0.98 }
  stale_document:  { cases: 20, metric: current_cite,    threshold: 1.00 }
  prompt_injection: { cases: 30, metric: no_behavior_change, threshold: 1.00 }
gate: every slice >= threshold   # an average never passes the gate
runs: 3                          # repeat to see non-determinism
on_fail: block_release, notify [product-owner, qa-engineer]

Bounded agency at runtime

Bounded agency means the runtime, not the model, decides what the system may do. The model proposes; the policy enforcement point checks; the tool executes only what is allowed.

Control	What it means	How it is built
Least-privilege tools	Only the tools the use case needs, each with the narrowest scope	Allow-list per use case; read-only by default
Policy enforcement	Every tool call is checked against identity, scope and data rules before it runs	A policy enforcement point in the tool router
Action confirmation	Consequential actions wait for a person with the authority	Approval gate; the requester cannot approve
Rate and spend limits	Caps per request, per user and per day	Gateway quotas; hard stop, not a warning
Step limit	A loop cannot run forever	Maximum tool calls per task (illustrative: 15)
Sandboxing	Code and commands run where they cannot reach production	Isolated workspace, synthetic data, no production credentials
Recovery	A failed or partial run leaves no half-done change	Idempotent tools; the reviewable artifact is the only output
Auditable traces	Every step can be replayed and explained	Trace with inputs, retrieved sources, tool calls, outputs and versions

Versioned components and material change

Every part below is a version-pinned component. A change to any of them is a change to the system. Whether it is a material change is decided under the organization's policy; the AI engineer brings the evidence.

Component	Version example	Usually routine (illustrative)	Usually material (illustrative)
System prompt	`policy-assistant-prompt@0.4`	Typo fix with an unchanged evaluation result	Changing the abstention rule or the tone of customer-facing text
Model	Pinned provider model id	None: every model change re-runs the full set	Provider upgrade, new model family, new provider
Retrieval corpus	`policy-index@2026-10-27`	New version of an in-scope policy, evaluated	A new document class or a new audience
Retrieval settings	Chunking and embedding configuration	Small tuning with unchanged results	Embedding model change
Tools	`search_policy@1.1`	Bug fix with the same scope	A new tool, a new scope, any write access
Guardrails and thresholds	Policy version; evaluation gate	Adding cases	Lowering a threshold or removing a slice
Evaluation set	`policy-assistant@1.3.0`	Adding reviewed cases	Removing cases or changing the grader

Monitoring and revalidation triggers

Signal	Definition	Threshold (illustrative)	Action
Citation failures	Missing, wrong or non-entailing citations in sampled answers	Above 2% in a week	Re-run the evaluation set; product owner review
Abstention rate	Share of questions with an abstention	Moves 5 points from launch baseline	Check corpus freshness and question mix
Staff-reported errors	Reports from the feedback button	Any report on a fee, cutoff or eligibility answer	Triage within a day; add the case to the set
Drift in question mix	New topics outside the evaluated slices	A new topic above 5% of traffic	Add a slice; revalidate before relying on it
Unit cost and latency	Cost per answer; 95th percentile latency	Above budget or above 4 seconds	Platform review; model routing option
Revalidation trigger	Model, provider, corpus class, tool scope, population or threshold change	Any one	Step down; full evaluation; independent validation where policy requires

5. Your ladder

Stage	AI use	Guardrail	Artifact or evidence	Decision relationship	Step-down trigger
0 · Foundations	None. You confirm approved providers, models, configurations and data terms for each environment	Third-party risk review done; logging and trace retention rules known	Approved model list per environment	Platform and third-party risk own it; you are consulted	Not applicable
1 · Personal productivity	A coding agent explains code and drafts scripts; you apply every change	Approved tool; no restricted data in prompts	Your own code through the normal pull request	A second engineer approves	Tool or data terms change
2 · Team context	Prompts, tool definitions and evaluation sets live in the repository; the team instructions file points to them	Versions pinned; prompt changes reviewed like code	Versioned prompt, tool and evaluation files	Reviewer who is not the author approves	A prompt shipped without a matching evaluation run
3 · Delegated tasks	You supply evaluation sets that let other roles delegate tasks; agents draft evaluation cases you review	Threshold on every slice; repeated runs; grader calibrated against human labels	Evaluation report per version	QA engineer co-signs; product owner accepts residual risk	A slice falls below its threshold
4 · Agentic workflows	You build and run multi-step agents with tools	Bounded agency controls above; independent approval for consequential actions; recovery tested	Runtime configuration, traces, kill-switch test record	Security challenges; release manager approves the change; independent validation where required	Model or provider change: step down to Stage 3 and re-run the full set
5 · Scale and sustain	Continuous evaluation on shared golden paths; reusable evaluation sets and tool definitions in the catalog	Material-change process; periodic review; monitoring with owners	Monitoring dashboards; revalidation records	Independent validation challenges; internal audit is an evidence recipient	Drift or an incident on any slice

Stays human-operated at Stage 5: accepting residual risk on a slice, approving a consequential action, deciding that a change is not material, and closing a revalidation. An agent can run every evaluation; a named person signs each of these.

6. Priority scenarios

Scenario	Value	Risk tier	Stage	First step	Do not use AI when…
Evaluation sets for delegated tasks	Other roles can safely reach Stage 3	Medium	3	Start from real past artifacts with known good answers	The cases are all generated and nobody reviewed them
Internal policy assistant	Faster, cited answers for staff	Medium	3 to 4	Lab L6: approved index, citations, abstention	It would answer customers directly; that makes it High tier
Model upgrade	Lower cost or better quality	Depends on the use	Any	Run the full evaluation set on the new version beside the old	The upgrade is pushed as "configuration" without an evaluation diff
Model as a grader	Evaluation at scale	Medium	3	Calibrate against human labels; report agreement	It is the only grader for a High-tier slice
Agent with tools for internal work	Multi-step tasks done end to end	Medium to High	4	Read-only tools first; one write tool behind an approval gate	Any tool could act on customer accounts without human approval
Cost and latency tuning	Lower unit cost	Medium	4 to 5	Model routing tested against the same evaluation set	Routing would send a High-tier slice to an unevaluated model
Customer-facing generated text	Clearer communication	High	4+	Deterministic core, AI-drafted text, human review, independent validation	The text includes values (dates, amounts) the model computed

7. The due-date ask from your seat

In the due-date ask the product contains no model: payment-schedule-service computes the cutoff in code, and the channels only format it. The AI engineer's work sits in delivery, and it is real: the evaluation sets and runtime limits that let the coding agent work at Stages 3 and 4.

Card	AI engineer
Decision	The evaluation sets, thresholds and runtime limits for the three delegated tasks: story drafting, test generation and pull-request drafting
Input received	Temporal-domain contract v1; past stories and tests from the team; the coding agent to pull request pattern from the architect
Output and evidence	Versioned evaluation sets with slices; evaluation reports; the Stage 4 runtime configuration (tool allow-list, sandbox, spend limit, step limit, kill switch)
Recipient	Business analyst, QA engineer and developers who delegate; the release manager, who sees the reports in the change record

Slice in the delegated-task sets	Case example	Pass when
Date-only	A story or change that touches the due date	Uses `LocalDate`; never converts it
DST (daylight saving time) week	Due dates in the weeks the clocks change	Cutoff uses the zone rules, never a fixed offset
No-DST zone	`America/Phoenix`	Cutoff shown in MST (Mountain standard time) all year
Missing zone	Profile with no zone	Fallback to state of residence, labelled
Banned pattern	Legacy code with `new Date(dueDate)`	The draft removes it, not copies it
Out of scope	A request to change payment-schedule-service	The agent declines; it has no write path

Negative path. The provider announces a model update. The AI engineer flags it; the team steps down to Stage 2 for the affected tasks; the sets run on the new version; tasks return to Stage 3 only when every slice passes again.

8. Hand-offs and separation of duties

Direction	What	With whom
You give →	Evaluation sets and reports per version	QA engineer, product owner, release manager
You give →	Build evidence and claims, for independent challenge	Independent validation
You give →	Monitoring definitions, thresholds, kill-switch steps	Production support
You give →	Material-change evidence	Risk and compliance
You receive ←	Reference pattern, trust and action boundaries, NFR (nonfunctional requirement) targets	Architect
You receive ←	Approved corpus versions, lineage, classification	Data engineer and steward
You receive ←	Gateway, quotas, trace store, approved model list	Platform engineer
You receive ←	Threat model, red-team findings	Security
You challenge	Thresholds set without slices; corpus documents without an owner; features that need write tools	Product owner, data owner, developers
You are notified of	Provider notices, incidents, staff error reports, corpus updates	Platform, production support, business operations

Separation of duties. The engineer who built the system and its evaluation set does not validate it for High-tier use. Independent validation reproduces or re-tests the results. The QA engineer's evaluation evidence is first-line evidence, not the independent conclusion.

9. Evidence and records

Evidence	Produced or consumed	System of record	Retention owner
Evaluation set (cases, slices, grader)	Produced	Repository, versioned	Team
Evaluation report per version	Produced	Evaluation store	Team; linked from the change record
Version manifest (prompt, model, index, tools, thresholds)	Produced	Repository; release record	Team; release manager
Runtime traces	Produced	Trace store	Platform, under the records rule
Kill-switch test record	Produced	Runbook record	Production support
Material-change assessment	Evidence produced; decision consumed	Model or AI inventory	AI or model risk
Validation findings	Consumed	Validation record	Independent validation
Monitoring results	Produced	Dashboard and alert history	Production support; product owner

Templates: use-case intake card, risk-tier checklist, lab plan.

10. Skills and learning path

Level	Skills	Labs	Done when
Foundation	Risk tiers, non-determinism, grounding and its limits, automation bias, what counts as a model under the organization's policy	L1 team instructions file	You can say for one use case which intake route applies and why
Practitioner	Evaluation sets with slices and thresholds, repeated runs, grader calibration, version manifests	L4 test generation with an evaluation set, L6 policy assistant	Your evaluation set gates a release in CI and a slice failure blocks it
Advanced	Bounded agency, policy enforcement points, recovery design, monitoring and revalidation, material-change evidence	L5 delegated task behind an approval gate	An agent you built passes a security red-team exercise and a tested kill switch

11. Measures and incentives

The AI engineer is evaluated on evidence that holds after release, not on demo quality.

Metric	Definition	Anti-gaming note
Slice pass rate	Slices at or above threshold ÷ all slices, per version	Removing hard slices raises it; slice removal is a material change
Regressions caught before release	Slice failures caught in CI ÷ all slice failures found, in CI or after release	Do not count failures you fixed by lowering the threshold
Evaluation coverage	Share of production question topics covered by a slice	Topics come from traffic, not from the team's own guesses
Revalidation lead time	Trigger raised → revalidation closed	Fast closure without independent review where required is a breach
Grader agreement	Agreement between the model grader and human labels	Recalibrate on every grader or model change
Unit cost per good answer	Cost ÷ answers that pass sampled review	Cheaper but wrong is not cheaper

12. Cost, capacity and workforce

Item	What to plan
Evaluation cost	Repeated runs on every change cost model calls; budget them per use case
Human labels	Calibration needs domain experts' time (illustrative: 200 cases per set), booked with their managers
Unit cost	Report cost per answer with platform and FinOps (cloud financial operations); routing changes are evaluated changes
Workforce	Evaluation design is a scarce skill; pair QA engineers with AI engineers so it spreads

13. Anti-patterns and stop conditions

Anti-pattern or trigger	What it looks like	What to do
Average-only evaluation	One score; a weak slice hidden inside it	Thresholds per slice; the gate fails on any slice
"Latest" model	The model id floats with the provider	Pin it; upgrades are evaluated changes
Prompt as the guardrail	"The prompt says never to act on accounts"	Remove the tool or scope; enforce at the policy enforcement point
Unreviewed generated cases	The model writes its own test	A person reviews every case before it enters the set
Builder validates own work	Your report is presented as independent	Route High-tier use to independent validation
Silent corpus growth	New document classes added to the index	Each new class is assessed before indexing
Stop: a slice fails	Below threshold in CI or monitoring	Block release or step down; fix; re-run
Stop: model or provider change	Vendor notice or new version	Step down; full evaluation; material-change route
Stop: unexpected action	A trace shows a tool call outside scope	Kill switch; preserve evidence; security incident route

14. Action kit and 30/60/90

A pre-release checklist for any AI version change.

## AI version release checklist · v1
Use case and intake id: ________   Risk tier: ____
Version manifest: prompt ____ model ____ index ____ tools ____ thresholds ____
What changed, and why: ________
Material change? [ ] no, evidence: ____   [ ] yes, route: ____  (decided by: ____)
Evaluation set version: ____  runs: __  every slice >= threshold: [ ]
Slices added or removed (removal needs approval): ________
Grader calibration still valid: [ ]
Runtime limits checked: tools, scopes, step limit, spend limit, confirmations [ ]
Kill switch tested on this version: [ ]   Fallback path works: [ ]
Monitoring thresholds updated: [ ]   Revalidation triggers listed: [ ]
Independent validation needed: [ ] yes, ref ____  [ ] no, because ____
Evidence linked in the change record: [ ]

Questions to ask your enablement lead

Which intake route decides whether this use case counts as a model under our policy?
Where do evaluation reports and version manifests live so the release manager and audit can find them?
Who supplies domain experts for human labels, and how is their time booked?

Period	Goal	Done when
First 30 days	One use case measured	A versioned evaluation set with slices and thresholds runs in CI; versions are pinned in a manifest
Days 31 to 60	Runtime bounded	Tool allow-list, policy enforcement, spend and step limits, and a tested kill switch for that use case
Days 61 to 90	Change under control	Material-change criteria agreed with risk; monitoring signals live with owners; one revalidation run end to end