AI roles and responsibilities, from data scientist to AI auditor

Why this matters

A security control is only as good as the person responsible for it. In a traditional application estate the roles are well understood: developers write code, operations run it, security reviews it, audit checks the reviews. AI systems add work that does not map neatly onto those roles. Somebody curates the training data, somebody decides when a model is good enough, somebody watches for drift, somebody translates a regulation into a pipeline gate. When nobody has been given those jobs explicitly, they fall between teams, and the gap is usually found during an incident.

For a security professional, knowing the roles matters in three practical ways. It tells you who to work with on a given control: data poisoning defences live with the data engineer, not the data scientist. It tells you who to hold accountable when a control is missing. And it tells you which combinations of access are dangerous, because the separation-of-duties problems in AI are new versions of old ones.

Job titles vary between organisations, and in a small team one person may hold several of these roles. The titles below are the common ones; what matters for the exam is the responsibility each describes, not the name on someone's contract.

The exam angle: scenarios describe a task or a failure and ask who should own it, or describe one person holding too many responsibilities and ask what the risk is.

The lesson

The builders: data scientist, data engineer, machine learning engineer and AI architect

These roles design the AI system and produce the model and data it runs on.

Data scientist. Explores data, frames the problem, chooses and trains models, engineers features and evaluates results. The data scientist decides whether a model is accurate and fit for its stated purpose. Security concerns centre on what they handle: they often work with large extracts of sensitive data in notebooks and experimental environments, which are weaker than production. Minimisation and masking from lesson 14 apply to their workspace as much as to the live system.

Data engineer. Builds and runs the pipelines that collect, clean, transform and store data for training and retrieval. The data engineer owns data quality, lineage and the integrity of what reaches training. That makes this role the front line against data poisoning: provenance checks, validation rules, anomaly detection on incoming data and access control on the stores, as lessons 4 and 18 described, are their engineering work.

Machine learning engineer. Turns a model into production software: reproducible training pipelines, packaging, serving infrastructure, performance optimisation and the integration of the model into an application. Where the data scientist asks whether the model is right, the ML engineer asks whether it runs reliably, quickly and repeatably. They control the training code and the serving path, both of which an attacker would like to alter.

AI architect. Designs the AI system as a whole: which model or models, whether to fine-tune or use retrieval, how the model connects to data sources, tools and users, and where the controls sit. The architect makes the decisions that are expensive to reverse, such as whether an agent gets write access to a system at all, and so is the person a security architect most needs to reach early.

The operators: platform engineer and MLOps engineer

These roles keep AI systems running, and they hold the most standing access.

Platform engineer. Builds and runs the shared infrastructure that AI teams build on: compute and accelerator capacity, container platforms, the model gateway, networking, secrets management and identity integration. A well-designed platform makes the secure path the default for every team, which is why the platform engineer is often the most effective security partner in the building. The flip side is concentration: the platform's administrators can reach everything hosted on it.

MLOps engineer. Applies DevOps practice to models: the CI/CD pipeline for training and deployment, the model registry, automated evaluation gates, monitoring for drift and degradation, and rollback. Lesson 27's pipeline is largely the MLOps engineer's system. They hold write access to the registry and the deployment path, so the integrity of what reaches production depends on how that access is controlled.

The guardians: AI security architect, AI governance engineer, AI risk analyst and AI auditor

These roles protect, govern, assess and verify. They differ in what they produce.

AI security architect. Designs the security of AI systems: threat-modelling them with methods such as those from lesson 8, specifying controls (gateways, guardrails, access scoping, encryption, monitoring), reviewing architectures before they are built and setting the security standards the AI CoE from lesson 28 publishes. Their output is a design and a set of requirements.

AI governance engineer. Turns governance requirements into working mechanisms. Where a policy says every AI system must be registered, evaluated before release and documented, the governance engineer builds the inventory automation, the approval workflow, the pipeline checks that block an unregistered model, the evidence collection and the model documentation templates. Their output is governance that runs by itself rather than relying on people remembering it.

AI risk analyst. Identifies, assesses and tracks AI risks: running impact assessments on proposed uses, scoring risks on the organisation's scale, recommending treatments, maintaining AI entries on the risk register and following up on accepted risks. The analyst does not accept risk. They make sure the owner who does accept it understands what they are accepting.

AI auditor. Provides independent assurance that AI controls exist and work. The auditor tests rather than takes on trust: samples approvals to see whether they followed the procedure, re-runs evaluations, checks that logs are complete, compares the inventory with what discovery finds, and reports to a body above the teams being audited. Independence is what makes the role valuable: an auditor who helped design the controls is reviewing their own work.

Separation of duties between the people who build, run and judge a model

Separation of duties prevents one person, or one compromised account, from both making a harmful change and hiding it. The AI versions of the principle:

• The builder does not approve their own model for release. The data scientist who trained a model has every incentive to find it good enough. Release approval sits with someone else, against thresholds set in advance.
• Whoever trains the model does not control the evaluation set. If the trainer can see or edit the held-out evaluation data, scores can be improved by tuning to the test, deliberately or not. The evaluation set is held by the MLOps or governance function, with access logged.
• Whoever can deploy cannot alter the logs. The MLOps engineer with registry and deployment rights should not be able to edit or delete the record of what was deployed and when.
• Data curation and model approval are separate. A data engineer who can insert training data and also approve the resulting model could poison it without any second person seeing.
• Risk is accepted by its owner, not by its builder or its analyst. The business owner accepts residual risk; the analyst advises; the builder fixes.
• Assurance is independent of everything it assures. The auditor reports outside the teams and outside the CoE.

In a small organisation where one person holds several of these roles, the answer is compensating controls rather than pretending the separation exists: peer review by someone outside the project, immutable logging of every deployment and evaluation, automated gates that the individual cannot bypass, and periodic independent review, perhaps by an external party.

The same principle applies to automation. An agent or pipeline that holds a builder's rights and an approver's rights at once is a single point of failure whether a person or a model operates it, as lessons 26 and 27 noted.

Matching a responsibility in a scenario to the role that holds it

Scenario questions often describe a task and ask who should own it. Work from what the task produces:

• Poisoned records entered a training set through an unvalidated feed: data engineer, who owns ingestion and validation.
• A model's accuracy dropped in production over several months unnoticed: MLOps engineer, who owns drift monitoring.
• A new RAG design gives the model direct access to every document store: AI architect for the design, AI security architect for the review that should have caught it.
• The policy requires model registration, but unregistered models keep reaching production: AI governance engineer, who builds the gate that enforces it.
• The board wants to know whether AI controls actually operate: AI auditor.
• A proposed hiring-screening tool needs its risks assessed and scored: AI risk analyst, with the decision left to the business owner.
• Teams keep hosting models on unpatched, inconsistently configured infrastructure: platform engineer, who owns the shared platform.
• A model performs well on the test set but its features leak the answer: data scientist, who owns model design and validity.
• Training runs cannot be reproduced and the serving code differs from what was tested: machine learning engineer.

Two traps recur. The first is choosing the most senior or most security-titled role when the question asks who performs the work: the AI security architect designs controls but does not usually run the drift monitor. The second is choosing a builder when the question asks who verifies: verification belongs to someone independent, and an answer that has the builder checking their own work is wrong because of the separation, whatever their skill.

A short worked scenario

A retailer's support chatbot starts recommending a competitor's products. The investigation finds that a scraped product-review feed, added to the retrieval index three weeks earlier, contained planted text. Walk the roles:

• The data engineer added the feed without the provenance and validation checks that other sources pass through. That is the immediate control gap.
• The AI architect designed retrieval so that any indexed source carries the same trust, with no separation between curated and scraped content.
• The MLOps engineer had behavioural monitoring in place, but no alert on a shift in which brands the bot mentioned, so three weeks passed.
• The AI governance engineer had built a re-approval trigger for new models, but not for new data sources, so the feed never reached review.
• The AI risk analyst should now score the incident, record it against the risk register and propose treatments; the business owner of the chatbot decides which to fund.
• The AI auditor later checks whether the new data-source procedure is being followed, by sampling sources added since.

Notice that no single role failed alone. Governance structure is what turns four partial gaps into one owned remediation plan.