The 9 AI Security Roles and What Each Does in a Typical Week

Hero image for The 9 AI Security Roles and What Each Does in a Typical Week
PC Drama
6 views

When a prompt-injection alert fires before anyone has had their Monday morning cup of coffee, who steps up to take responsibility for this alert? That alert was supposed to be logged and escalated by procedure. Whether it was comes down to nine jobs that most org charts smear into one box marked "the AI team."

I separate those nine AI security roles by what each one delivers and what a typical week looks like, from the data engineer who feeds the models to the auditor who checks nobody skipped a step.

Five roles form a delivery line, each handing finished work to the next:

  • Data engineer delivers usable data.
  • Data scientist turns it into a model prototype.
  • ML engineer turns the prototype into a production service.
  • MLOps engineer automates its testing, release, and monitoring.
  • Platform engineer provides the shared infrastructure it all runs on.

The other four never sit at the end of the line. The AI architect designs how the pieces fit before and during the build. The AI risk analyst, AI governance engineer, and AI auditor work across the whole lifecycle, assessing risk, building policy into the pipeline, and checking results while models are designed, shipped, and running.

RoleDeliversWorks with
Data engineer Clean, labeled datasets and their pipelines Data scientists, platform engineers
Data scientist Analysis and a prototype that proves an approach works Data engineers, ML engineers, stakeholders
ML engineer Production software that runs a model and returns predictions Data scientists, MLOps engineers
MLOps engineer An automated lifecycle: test, version, deploy, monitor ML engineers, platform engineers
Platform engineer Shared infrastructure and guardrails every team builds on All of the AI teams
AI architect The blueprint for how components and data flows fit Engineering leads, security
AI risk analyst Risk assessments, mitigations, and tracked indicators Product teams, governance, leadership
AI governance engineer Policy enforced automatically: approvals, evidence, retention MLOps engineers, risk analysts, auditors
AI auditor Independent findings on whether policy was followed Everyone, independently

The data side: from raw feed to running model

Link to section: The data side: from raw feed to running model

Three roles carry an idea from a messy data dump to a service that answers in production.

A labeled network patch panel on a workbench with two cables unplugged mid-repair and a cable tester alongside
The raw feed before anyone models it: bundled, labeled, two wires pulled for repair.

Data engineer. The raw feed is messy. We ran SELECT COUNT(*), COUNT(DISTINCT ip_address) FROM blocked_access_attempts against our own site and got 6,352 probe attempts from 434 distinct IPs between December 2025 and April 2026. A data engineer dedupes, labels, and quality-checks exactly that noise before a model sees it. For an owner, the takeaway is plain: the person cleaning the data decides what the model can later catch.

A top-down desk of printed log sheets and hand-sketched histograms with a brass magnifier loupe resting on one page
Months of logs become one framed question worth modeling.

Data scientist. Frames a problem buried in months of authentication logs, tests which features predict account takeover, builds baseline models in a notebook, and hands the working prototype across the desk.

"Deploying to production means you're halfway there."

Andrew Ng founder of DeepLearning.AI, at the Scale Transform conference, as reported by Roboflow

A single rack-mount inference server opened on a workbench exposing copper heatsinks and memory modules
The notebook, now a service with its dependencies pinned and scanned.

Machine learning engineer. Containerizes the prototype, pins and scans its dependencies, and wraps it in an authenticated API that refuses to ship a version whose accuracy or latency slipped.

Running the models: automation and the platform

Link to section: Running the models: automation and the platform

A model that returns a prediction is not finished. Keeping it correct is the other half of the job.

A macro of an industrial automation control panel with lit cycle buttons and a rollback lever mid-throw
Every model change versioned and tested, and a lever to take it back.

MLOps engineer. When an incident is declared, this is who can name the exact model version that was live, then roll back the one that failed its evaluation and retune the alerts.

A wide view down a dim data-center cold aisle, GPU racks receding into the dark with status lights along the floor
The shared floor every AI team rents space on.

Platform engineer. Keeps isolated GPU workspaces, compute quotas, a patched secrets manager, and project templates where logging and access control arrive switched on.

The build-line roles, week by week
Role A typical week might include
Data engineer Fix a failed nightly job pulling threat feeds and trace the schema errors that broke it; write a new ingestion job that dedupes, labels, and quality-checks a source; add an alert so a poisoned feed is caught before a model; meet the data scientist about the next dataset's fields.
Data scientist Explore months of authentication logs to frame the problem; test which features, like login timing and device changes, predict account takeover; build and compare baseline models in a notebook; present findings and hand the prototype to the ML engineer.
ML engineer Containerize the notebook, pinning and scanning its dependencies; build an authenticated inference API with input validation; write load and regression tests that block a version if accuracy or latency slips; fix a latency issue and ship the new model version.
MLOps engineer Maintain the CI/CD pipeline where every model or prompt change is versioned and tested; orchestrate a scheduled retraining run against the evaluation suite; use lineage records to answer which version was live during an incident; roll back a failed deployment and tune monitoring alerts.
Platform engineer Maintain isolated GPU workspaces and compute quotas; patch the secrets manager and tighten network policy around training data; improve templates so logging and access control come by default; onboard a new team and troubleshoot their first workspaces.

Design and oversight: the four that never leave

Link to section: Design and oversight: the four that never leave

These four are not a checkpoint at the very end. They touch the work while it is designed, shipped, and running.

A printed system-architecture blueprint pinned to a drafting table with a ruler, a drafting pen, and a small 3D-printed block model
Where the pieces get drawn before anyone builds them.

AI architect. Runs the week on design reviews and written decisions: a retrieval index, an AI gateway, scoped tokens only, and data flows arranged so raw credentials can never reach the model.

A macro of a brass balance scale on a desk, one pan holding printed memos and the other a single warning placard
What could go wrong, weighed against what it costs to prevent.

AI risk analyst. Assesses a customer-email generator for hallucinated claims and data leakage, recommends human review and output filtering, then writes the assessment an approval rides on.

An open immutable-records binder on an office shelf with a rubber approval stamp resting on a signed release form and a locked steel box behind
Policy that runs itself, so a release cannot skip the paperwork.

AI governance engineer. Wires the registry so every production promotion opens an approval ticket, files results and training-data lineage to an immutable store, and fixes the gate that let one deployment slip past review.

A clipboard with a hand-ticked checklist on a bare desk, a pen across it, a magnifier over one line, and a sealed evidence envelope
The one role that verifies instead of builds.

AI auditor. Verifies, does not build. Samples ten deployments for signed risk assessments, confirms alerts were triaged in time, and checks that last month's prompt-injection incident was escalated by procedure.

The oversight roles, week by week
Role A typical week might include
AI architect Design how a new document assistant fits: retrieval index, AI gateway, scoped tokens only; review data flows so raw credentials never reach the model; choose model-serving and integration patterns and write the decisions down; sit in design reviews before teams build.
AI risk analyst Assess a proposed email generator for hallucinated claims, brand damage, and data leakage; recommend human review and output filtering; review the risk dashboard for drifting indicators like complaint rates and filter hits; write the assessment an approval decision depends on.
AI governance engineer Wire the registry so every production promotion opens an approval ticket; automate evidence collection, evaluation results plus a training-data lineage snapshot per release; write each record to an immutable store meeting retention policy; fix an approval gate that let a deployment skip review.
AI auditor Sample ten deployments and check each has a signed risk assessment; verify monitoring alerts were triaged within the required time; check last month's prompt-injection incident was logged and escalated by procedure; write the findings up for leadership and the teams involved.

At a smaller company, one person covers two or three of these. Separate them by what they deliver, not by the job posting. The data engineer and the platform engineer can be the same hire. The auditor cannot also be the governance engineer, because the auditor's entire value is checking work they did not build.

How many people do I need to cover these nine AI security roles?

Fewer than nine. At a small company one engineer often covers the whole build line, and a single person may hold risk and governance together. The one split worth protecting is the auditor, who has to sit outside the roles that build and approve, or the independent check stops being independent.

What is the difference between an ML engineer and an MLOps engineer?

The ML engineer turns a data scientist's prototype into a running service: the container, the API, the tests. The MLOps engineer automates everything around that service across many models: the CI/CD pipeline, versioning, retraining runs, and the monitoring that catches drift. One ships the model; the other keeps a fleet of them from drifting.

Why keep the AI auditor separate from the AI governance engineer?

The governance engineer builds the controls, the approval gates and the evidence store. The auditor checks whether those controls held. If one person does both, nobody independent is verifying the work, which is the exact gap an auditor exists to close.

Where does this nine-role model come from?

The role definitions are drawn from the SECAI study deck we maintain. The continuous nature of the oversight roles follows the Govern function of the NIST AI Risk Management Framework, and the auditor's independent-assurance posture follows ISACA's AI audit guidance. The build-line roles map cleanly onto AWS's Well-Architected Machine Learning Lens.

The nine-role split is a teaching model, not a hiring mandate. Real teams combine the boxes; combine them by deliverable, and keep the auditor apart.

Sources: SECAI study deck, NIST AI RMF, ISACA AI resources, AWS Well-Architected ML Lens, Roboflow: Andrew Ng at Scale Transform

Related Articles