Exploring Data Science & AI Roles - Understanding Key Responsibilities

Who should read it?

Business leaders, hiring managers, aspiring data professionals, and technical readers who need a map of the role landscape

Intro

Somewhere right now a hiring manager is writing a job ad for a single person who will clean data, build pipelines, train models, deploy them to the cloud, explain the results to the board, understand the business domain deeply, and keep everything compliant. Several programming languages and frameworks, multiple database systems, years of experience in everything.

To make it crystal clear: THESE PEOPLE DO NOT EXIST.

This is usually diagnosed as a recruiting problem. It is not. It is a team-design problem: 1 job ad to cover 5 different jobs. A data or AI initiative rarely fails because 1 person lacked a longer tool list. It fails because important work was unowned. Nobody was responsible for data quality, or for operating the model after launch, or for asking whether the result solves a real business problem. The practical question is therefore not "Which title should we hire?" but "Which work must be done, who owns it, and what changes as the initiative matures?"

Start with responsibilities, not job titles

Strip away titles and any data or AI effort has the same end-to-end flow:

1. Choose a valuable problem.
2. Understand the domain and the data.
3. Acquire, clean, and move data.
4. Analyze and model.
5. Build a usable product or service.
6. Operate it reliably.
7. Monitor quality, risk, and business impact.
8. Help the organization use the result.

Every role in this article is a claim on one or more of these steps. The team's basic functions (following Jacquelyn Nolis) as supporting data-driven decisions, improving products through data, and keeping data flowing through the company. That framing is deliberately broader than any one job description, because the same flow can be covered by three people in a small company or thirty in a bank.

The core roles

Product owner or business lead

This person selects which problems are worth solving, owns the outcome, and keeps the work connected to users and business priorities. Data scientists, who often come from technical or scientific backgrounds, need someone to make the context explicit: their work exists to support business goals, and someone must articulate those goals and shield the team from unclear or inflated ones.

The product owner is NOT a project manager.

Their artifact is the decision about what is worth doing at all.

Business analyst and data analyst

Analysts clarify the question, investigate what happened and why, define useful measures, and communicate findings. Distinguish data analysts from business analysts.

• Data analyst
  • More technical: database skills, business intelligence tools, descriptive and diagnostic analysis
    
• Business analysts
  • More domain-oriented: processes, requirements, context

In pratice, the boundary blurs. Employees with other profiles are increasingly retrained into analyst roles through upskilling, which makes this role the most reachable entry point for internal development. The artifact is the answered question: "What is happening, and what does it mean?".

Data scientist

The data scientist applies statistical and machine learning methods to answer predictive or prescriptive questions: "What will happen?", and "What should we do?". Data scientists can be sorted into generalist and specialist profiles and, by background, into 4 "tribes": business, academic, engineering, and data. The distinction matters for hiring: a use case that needs careful statistics wants a different person than one that needs a production system. In a first data science project, the standard setup is a data scientist, a data engineer, and domain expertise. The data scientist's artifact is a validated model or analysis that answers the question.

Data engineer

The data engineer makes reliable data available: connecting sources, building pipelines and ELT/ETL processes, automating, and testing, which in practice also means checking data quality. Why this role earns its salary so fast, because it is often assumed that 60- 80% of a data scientist's work is data preparation. Every hour an engineer removes from that burden buys back an hour of actual modeling. The data engineer's artifact is trustworthy, reachable data.

Big data engineer

The big data engineer is the data engineer at scale, and the distinction is worth naming because the skill sets diverge. Where the data engineer connects sources and builds pipelines, the big data engineer handles volume and velocity that break ordinary tools: distributed processing frameworks like Hadoop and Spark, streaming systems like Kafka and Flink, and cluster platforms such as EMR and Databricks. A warning about tool-first thinking: it applies in both directions: most teams overestimate how much scale they need, and some underestimate it. The practical staffing signal: hire or grow this profile when pipelines slow down or costs spike, not before. The artifact is infrastructure that stays fast and affordable as data grows.

Data architect or software architect

Architects decide how the pieces fit: "Which sources are needed?", "How are they connect?", "Where does data live?", and "How do systems interact?", so that 10 local solutions do not quietly become an accidental, incoherent enterprise architecture. Software architects are expensive senior people needed in bursts, at the start of projects, and the recommendation for small and mid-sized companies is to hire them externally until the workload justifies a full-time seat. The best architecture is the one that delivers business value, not the most elegant one, and decisions should be documented because the rationale outlives the individuals. The artifact is the design and its reasoning.

Statistician

The statistician is the classical neighbor of the data scientist, and the one role that existed long before "data science" was a word. Where the data scientist answers a business question with whatever mix of methods works, the statistician owns the rigor underneath: experimental design, hypothesis testing, uncertainty, and the honest statement of what a result does and does not prove. The tool lineage shows the age: R, SPSS, SAS, and Excel predate the deep learning stack by decades. When you need a clinical trial designed, an A/B test interpreted correctly, or a survey weighted so its conclusions survive scrutiny, this is the role.

Statisticians are NOT failed data scientists.

The artifact is statistically sound inference, not a deployed system.

Research scientist

The research scientist extends the methods themselves rather than applying them: new model architectures, new training techniques, published results. The working stack (PyTorch, JAX, experiment tracking with tools like Weights and Biases) exists to support reproducible experiments, and the natural output is the paper, the method, or the capability the rest of the team builds on. This is the rarest and most specialized role on the list. Hiring a research profile to answer a business question produces elegant papers and unshipped products. Reserve it for organizations doing genuine frontier work, or for labs attached to product teams with a research charter. The artifact is new capability, not a shipped feature.

ML engineer

Once a model must run continuously, someone owns the peculiarities of machine learning operation: the data underneath changes over time, model performance drifts, parameters stop being valid. The ML engineer combines skills of the data scientist and the software engineer and takes responsibility for deployment, performance, retraining, and model monitoring.

Common misunderstanding: a model is not software that gets finished.

It is software that decays. The artifact is a model that keeps working.

DevOps or MLOps engineer

Where the ML engineer owns the model, the DevOps or MLOps engineer owns the boundary between development and operation: environments, infrastructure, automation, testing, and release processes. Data scientists feel at home in the development world and often forget that, unlike a slide deck or a project report, software needs permanent maintenance and operation once it exists. DevOps engineers build the environments in which new features can be developed, tested, and deployed safely. This machinery of production is covered in The Model Works on My Machine: DevOps and MLOps. The point here is the staffing signal: if your initiative is "a product that must not break", then this role is mandatory.

AI engineer

The AI engineer integrates AI models into products and workflows: the application layer around the model, the user experience, the plumbing between model and product. This title is newer and less standardized than the others, and treat it as a role in the implementation team rather than a fixed job description. The distinction that matters: research scientists push the frontier of methods; software engineers build general systems; AI engineers connect models to real users and workflows. The artifact is a product that uses a model well, not the model itself.

Model risk, security, and compliance specialists

Model risk managers systematically capture and assess the risks of models in development and in production: security gaps when models touch customers or confidential data, results drifting in unwelcome directions, compliance with privacy rules, appropriateness of communication (the chatbot example is vivid: models trained on customer-generated data can be manipulated from outside, and the results, in extreme cases, are chatbots reproducing hateful content). The artifact is the documented risk assessment and the review that says: this model may, or may not, operate in this way.

Domain expert

The domain expert is a subject matter expert and supplies the context without which data is just numbers: "What doe the values mean?", "Which features make sense?", "Is a models result plausible?". Every data science project includes a business and data understanding phase, and if the team lacks access to business knowledge, domain experts inside the team can fill the gap and keep development speed up. The combination of domain expert and analyst is ideal, because such a person can run their own analyses. The artifact is correct interpretation.

Roles that are often confused

A quick field guide. The rule for each pair: look at the primary question and the artifact.

• Data analyst vs. data scientist
  • The analyst answers: "What happened and why?" (descriptive, diagnostic)
  • The data scientist answers: "What will happen and what should we do?" (predictive, prescriptive).
• Data engineer vs. ML engineer
  • The data engineer's artifact is reliable data
  • The ML engineer's artifact is a model that stays healthy in operation.
• ML engineer vs. AI engineer
  • The ML engineer owns model operation (deployment, drift, retraining) and thinks in monitoring dashboards
  • The AI engineer owns model integration into a product and its workflows and thinks in user flows.
• Data architect vs. software architect
  • The data architect designs how information flows and where it lives
  • The software architect designs how systems and components interact. Overlapping skills, different centers of gravity, and in smaller organizations one external consultant can cover both at project start.
• Data scientist vs. research scientist
  • The data scientist serves a business question under real-world constraints
  • The research scientist extends the methods themselves. Hiring a research profile for a business problem produces elegant papers and unshipped products.
• Business analyst vs. product owner
  • The analyst clarifies questions and requirements and informs about the "what?"
  • The product owner decides priorities and owns the outcome

Small team versus growing organization

Yes, in a small company one person can fill several roles. A product owner can take on development tasks; data scientists can do data engineering. Flexibility matters more than rigid role boundaries early on. But the work still has to be divided sensibly and explicitly, because combining roles is fine only when the responsibilities remain named.

A maturity-based map:

• First use case: a product or business owner, one versatile data practitioner, domain expertise, and access to IT support for data provisioning. Start with 2-5 data scientists who can cover many tasks.
• Several use cases: add a dedicated data engineer (the 60-80% makes the return on this hire quick), an analyst, and a technical lead. Formalize ownership of data quality and delivery. Integrate data engineers directly into the data science team once complexity grows.
• Production AI: add ML engineering or MLOps capability, operational monitoring, and security or risk review. This is the point where the initiative stops being a project and becomes an operated product.
• Large or regulated organization: add architecture (external architects until full utilization is guaranteed), model risk management, governance, data stewardship, and platform capability.

Two structural notes

Placement matters as much as headcount: data teams can sit centralized (one department, easy knowledge sharing), distributed in business units (close to the domain), or hybrid (satellite data scientists in business areas, centrally networked).

Growth needs structure: following the Rule of 3 and 10, one person organizes themselves, 3 need an agreed division of responsibility, 10 is still a manageable team, and beyond that you should form several smaller teams, because the number of communication paths grows faster than the headcount. For multi-team organizations have a look at the "team of teams" model after Stanley McChrystal: shared responsibility in decentralized teams with networked individuals.

The handoffs that determine success

Role boundaries are collaboration boundaries, not walls. 5 handoffs decide most outcomes:

1. Domain expert & analyst define the question. A precisely framed question is the cheapest quality insurance in the process.
2. Data engineer & data scientist agree on what "usable data" means: formats, quality thresholds, freshness, documented meaning.
3. Data scientist & ML engineer define the model contract: inputs, outputs, expected performance, retraining triggers, and what happens when the model degrades.
4. Product owner & technical team define value and acceptance criteria, so that "works" has a shared meaning before launch.
5. Risk & engineering make safe operation part of delivery, not a review bolted on afterward.

Hiring and development without cargo-cult titles

Two hiring lessons on competencies and culture:

First, on overstuffed job ads: asking for too much scares off applicants, and in most cases the person hired does not match the full profile anyway, so the extra requirements filter out good people while excluding nobody who was going to fail. Recruiters (and selection software) also overweight straight-line careers, which is a bias problem in a field whose degree programs are young and whose skill paths are winding. Focus on few but important skills.

Second, on where capability comes from: the war for talent makes external recruiting slower and more expensive every year, which turns upskilling and reskilling from HR vocabulary into core strategy. Upskilling deepens or extends existing employees' qualifications; reskilling moves people from adjacent fields into new roles. The often decisive success factor is data literacy across the organization: the more colleagues in the business departments can think along with data science, the likelier implementation becomes, because the use cases and the knowledge about the data itself live in those departments. This is the citizen data science idea, with a clear limit: not everyone should become a data scientist, but everyone who consumes analyses needs enough literacy to question them.

Culture is the container for all of it. Company culture is the biggest factor in choosing a new employer. Choose an environment of learning, autonomy, meaningful work, experimentation and failure culture.

A practical role-design checklist

Before the next hire, answer these questions:

1. "What outcome are we trying to improve?"
2. "Which decisions and deliverables are required to get there?"
3. "Which responsibilities in the flow above are currently unowned?"
4. "Which capabilities can one person safely combine, and which cannot share a head (e.g. builder and independent risk reviewer)?"
5. "What must be production-ready and monitored, and who owns that after launch?"
6. "What risk and compliance work is mandatory for our industry and our data?"
7. "Where is the domain knowledge located, and can the team reach it when it matters?"
8. "What knowledge must be shared (documentation, pairing, redundancy) to avoid a bus factor of one?"

If the answers are honest, the org chart that emerges will rarely match the job ad. It will be smaller, more explicit, and much more likely to ship.