The data and AI role landscape

⏱ 30 min

Hook

Two people both hold the title "data scientist" at companies down the street from each other. One spends the week writing SQL and building dashboards for a marketing team. The other trains recommendation models and never opens a BI tool. Same title, different jobs, different skills, different next employers. If you aim your study at the title, you will hit one of them by accident. Aim at the work, and you can choose.

Concept

Job titles in data and AI are unreliable. They vary by company size, by country, by which team happened to be hiring, and by fashion. What does not vary is ownership — the specific outcome a person is on the hook for. When you learn to read roles by ownership instead of by title, the landscape stops being a word cloud and becomes a map you can navigate.

Here are the five core roles this course uses as anchors. Real jobs blend them, but almost every data or AI position is mostly one of these.

A data analyst owns insight from data that is already prepared. They answer business questions — which regions are shrinking, why churn rose last month — using SQL, a BI tool, and spreadsheets. Their day is queries, charts, and conversations with stakeholders. They are measured on whether decisions get made better and faster because of their work.

An analytics engineer owns the trusted, modeled data layer analysts build on. This is the newer role sitting between analyst and data engineer. They take raw tables and turn them into clean, documented, tested models — usually with SQL and a transformation framework like dbt — so that "revenue" means the same thing on every dashboard. Their day is writing transformation code, testing it, and maintaining the definitions the whole company trusts.

A data engineer owns the pipelines and platforms that move data reliably. They build the systems that get data from source applications into the warehouse or lakehouse, on time and correct, at volume. Their day is pipeline code, orchestration, storage decisions, and debugging why a job that worked yesterday broke overnight. They are measured on reliability and freshness, not on insight.

An ML/AI engineer owns models and the applications built around them. This spans two flavors that share a spine: the classical ML engineer who trains and ships predictive models, and the AI engineer who builds applications on top of large language models — a large language model (LLM) is a model trained to generate and reason over text. Their day is data preparation, model or prompt iteration, evaluation, and wiring the model into a product. They are measured on whether the model actually works against a metric, not against a demo.

An MLOps engineer owns keeping models and data systems running in production. They version models, automate deployment, monitor for drift and cost, and build the reproducibility scaffolding around everything above. Their day is infrastructure-as-code, CI/CD, observability, and incident response for systems that quietly rot when data shifts. They are measured on uptime, cost, and how fast a broken model gets caught.

The single most useful way to hold these apart is the direction each role faces. Analysts and analytics engineers face the business; data engineers and MLOps engineers face the system; ML/AI engineers face the model. The table below sharpens the contrast.

Role	Owns	A typical day	Typical stack
Data analyst	Insight from prepared data	Queries, dashboards, stakeholder questions	SQL, a BI tool, spreadsheets
Analytics engineer	The trusted modeled data layer	Writing and testing transformation models	SQL, dbt, the warehouse, Git
Data engineer	Reliable pipelines and platforms	Pipeline code, orchestration, debugging jobs	Python, SQL, Spark, an orchestrator, cloud storage
ML/AI engineer	Models and model-backed apps	Data prep, model or prompt iteration, evaluation	Python, ML or LLM libraries, notebooks, APIs
MLOps engineer	Models and systems in production	Deployment automation, monitoring, incidents	Containers, CI/CD, monitoring, infrastructure-as-code

note

Two names you will see that are not separate roles here: "data scientist" is a company-specific blend, usually analyst-plus-modeling or ML-engineer-lite, and "agent engineer" is an emerging specialization of the AI engineer focused on tool-using autonomous systems. Read both by their ownership, not their label.

🧠 Knowledge check

1. A job posting asks you to "ensure revenue is defined consistently across all dashboards by building tested SQL models on top of raw warehouse tables." Which role does the work described most clearly match?

a) Data analystb) Analytics engineerc) MLOps engineerd) ML/AI engineer

2. Why is reading a role by its title alone a poor way to plan your study?

a) Titles are always exaggerated to sound more seniorb) The same title maps to different ownership and skills across companiesc) Titles are legally standardized, so they reveal nothing newd) Companies rarely put the real title in the posting

Worked example

Let me read one confusing posting the way you will learn to. A mid-size retail company advertises a "Data Scientist II" role. The title suggests modeling. The body tells a different story.

The responsibilities list, paraphrased: "Partner with the merchandising team to answer questions about category performance. Build and maintain the weekly executive dashboard. Define and document core business metrics so reporting is consistent. Occasionally prototype a forecasting model for demand planning."

I ignore the title and sort each duty by ownership. "Answer questions for merchandising" faces the business — that is analyst work. "Build and maintain the dashboard" is analyst work too. "Define and document core metrics so reporting is consistent" is analytics-engineer ownership — the trusted layer. "Occasionally prototype a forecasting model" is a light ML task, but the word occasionally tells me it is a small slice, not the center of gravity.

Weighing the duties, this "Data Scientist" role is roughly two-thirds analyst, one-third analytics engineer, and a sliver of ML. If I want to train models all day, this posting is a trap despite its title. If I want to be the analyst who also owns metric definitions, it is a strong fit — and now I know exactly which skills to bring: SQL fluency, a BI tool, metric modeling, and just enough forecasting to prototype. The title told me almost nothing; the ownership told me everything.

Hands-on

Now you do the same sorting, on roles instead of a single posting. This is a written reflection, not a coding task — keep a document or notebook open and write your answers out. Working memory is not enough; the value is in committing to words.

Work through these four prompts in order:

1. List the five roles from memory. Without scrolling up, write the five core roles and one phrase for what each owns. Then check yourself against the table and fix anything you missed. The point is to surface what did not stick.
2. Name the direction each faces. For each role, write whether it faces the business, the system, or the model. If two feel identical to you, write one sentence on what separates them.
3. Place a role you have seen. Think of one real job title you have encountered — from a friend, a posting, or your current workplace. Write its title, then the ownership breakdown, in the style of the worked example: what fraction of it is analyst, analytics engineer, data engineer, ML/AI, or MLOps.
4. Write your first instinct. In two or three sentences, note which of the five roles you are most drawn to right now and why. This is a starting hypothesis, not a commitment — you will test it in the next lesson.

You are done when your document has all four written out: the five roles from memory with corrections, a direction for each, one real title decomposed by ownership, and a two-to-three sentence first instinct. If any prompt is still in your head and not on the page, it is not finished.

Recap

• You can name the five core data and AI roles and state what each one owns.
• You can describe the day-to-day and typical stack for each role instead of guessing from the title.
• You can sort a confusing posting by ownership and estimate its real center of gravity, the way the worked example decomposed a "Data Scientist" role.
• You have a first instinct about which role fits you, ready to test.

Next up: matching yourself to a target role — turning that instinct into an honest skills inventory and a ranked list of the gaps that actually matter.

🧠 Knowledge check

1. You want to work on the model itself — training, evaluation, and shipping it inside a product. Which role faces that work most directly?

a) Data analystb) Analytics engineerc) ML/AI engineerd) Data engineer

2. A team keeps losing a trained model to silent failures when incoming data shifts, and nobody notices for days. Whose ownership is closing that gap?

a) The data analyst who reads the dashboardb) The MLOps engineer who monitors and deploys modelsc) The analytics engineer who defines metricsd) The ML engineer who first trained the model

📌 Key takeaways

• Titles vary; ownership is the stable signal you plan your study against. - The five anchor roles are data analyst, analytics engineer, data engineer, ML/AI engineer, and MLOps engineer. - Analysts and analytics engineers face the business, data and MLOps engineers face the system, and ML/AI engineers face the model. - Decompose any confusing posting into fractions of these roles to find its real center of gravity.