When an organisation ships its first serious AI product, nobody is sure whether securing the model is the machine learning team's job or the security team's job, and the gaps between the two are where poisoned data, leaked API keys and over-privileged agents slip through. The ML engineer builds, trains, deploys and runs models; the AI security engineer makes sure those models and the systems around them cannot be abused. The roles share tools, pipelines and vocabulary, and a growing number of people move from one to the other. This guide draws the boundary: what each role owns, where they overlap, the skills and certifications behind each, how to move between them, and the team design mistakes that leave AI systems unprotected. It is written for engineers choosing a direction and for managers writing job descriptions and responsibility matrices. For the full profile of the security role, including AI threat catalogues and routes in, see the AI Security Engineer Career Guide; this page focuses on the comparison.
Key takeaways
- Different questions, same system. The ML engineer asks whether the model works, scales and stays accurate; the AI security engineer asks how it can be made to misbehave, leak or be misused, and what limits the damage.
- Ownership splits by outcome, not by artefact. Both touch the training pipeline, the model registry and the serving endpoint; the ML engineer owns their function, the security engineer owns the threat model and the controls that constrain them.
- The overlap is where incidents happen. Data provenance, model supply chain, evaluation, credentials for AI workloads and agent tool permissions need named owners on both sides.
- Certifications point in different directions. ML engineer credentials come mostly from cloud providers and test building and operating models; AI security credentials are newer and lean towards management and governance.
- The move works in both directions. ML engineers bring model intuition that most security staff lack; security engineers bring threat modelling and incident handling that most ML teams lack. Each must deliberately learn the other half.
The short answer and the comparison table
An ML engineer is a software engineer specialised in turning data and models into reliable production systems: feature pipelines, training jobs, evaluation, deployment, monitoring and retraining. An AI security engineer is a security engineer specialised in systems that build, host or call models: threat modelling AI features, adversarial testing, guardrails, credential and access design for AI workloads, and AI incident response. If your work is judged on model quality, latency and cost, you are doing ML engineering. If it is judged on what cannot happen, you are doing AI security.
| Dimension | ML engineer | AI security engineer |
|---|---|---|
| Primary goal | Models that are accurate, fast, affordable and maintainable in production | AI systems that resist abuse, protect data and fail safely |
| Measured on | Model metrics, serving latency, uptime, training cost, release cadence | Findings fixed before release, attack resistance in testing, incidents contained, control coverage |
| Typical artefacts | Feature pipelines, training code, model cards, deployment manifests, dashboards | Threat models, test suites, guardrail policies, access designs, incident runbooks |
| Core knowledge | Statistics, ML algorithms, data engineering, distributed training, serving infrastructure | Application, cloud and identity security, adversarial ML, AI threat catalogues |
| Reference frameworks | Provider ML architecture guidance, internal model governance | OWASP Top 10 for LLM Applications 2025, MITRE ATLAS, NIST AI 100-2 E2025, NIST AI RMF |
| Default view of model output | A prediction to evaluate for quality | Untrusted input to everything downstream |
| Reports to | Engineering, data or AI platform leadership | Security leadership, sometimes with a dotted line to the AI platform |
| On-call for | Model degradation, pipeline failures, serving outages | Prompt injection, data leakage, credential misuse, model tampering |
What each role owns
ML engineer responsibilities
- Data and features: building ingestion and feature pipelines, versioning datasets, handling labelling and data quality.
- Training and evaluation: selecting architectures, fine-tuning foundation models, running experiments and evaluating against quality metrics and fairness criteria.
- Deployment and serving: packaging models, managing the model registry, building inference endpoints, scaling GPU capacity and controlling cost.
- Operations: monitoring drift and performance, retraining, rollback of bad model versions. Google's Professional Machine Learning Engineer exam describes this scope as architecting AI solutions, collaborating on data and models, scaling prototypes, serving and scaling models, automating pipelines and monitoring AI solutions.
AI security engineer responsibilities
- Threat modelling: mapping how untrusted content reaches the context window or training set, what tools an agent can call and what data a retrieval pipeline can return. See the AI Agent Threat Modelling Guide.
- Adversarial testing: prompt injection, jailbreak, extraction and poisoning tests before and after release. See the AI Red Teaming Guide.
- Controls: guardrails, output handling, rate limits, tenant separation in vector stores, signing and scanning of model artefacts.
- Identity for AI workloads: scoping model API keys, service accounts for training jobs, agent tokens and connector permissions.
- Detection and response: deciding what to log for prompts, tool calls and retrievals, and running AI incidents with the SOC.
Where the roles overlap: a responsibility matrix
The NCSC's Guidelines for secure AI system development (version 1.0, November 2023) organise security across four lifecycle areas, secure design, secure development, secure deployment and secure operation and maintenance, and urge data scientists, developers, managers and risk owners to read them. Every one of those areas needs both roles. The matrix below uses R for responsible (does the work) and A for accountable (signs off), and is a starting point to adapt, not a standard.
| Activity | ML engineer | AI security engineer | Typical threat (OWASP LLM 2025 / ATLAS) |
|---|---|---|---|
| Dataset sourcing and provenance records | R, A | Reviews provenance rules, tests for poisoning | LLM04 Data and Model Poisoning; AML.T0020 Training Data Poisoning |
| Third-party model and package intake | R (selection) | A (approval rules, scanning) | LLM03 Supply Chain; AML.T0010 Supply Chain Compromise |
| Model registry write access | R (operates) | A (access design, review) | AML.T0018 Manipulate AI Model |
| Prompt and system prompt design | R | Reviews for secrets and leakage | LLM07 System Prompt Leakage |
| Retrieval and vector store permissions | R (build) | A (segregation model) | LLM08 Vector and Embedding Weaknesses; LLM02 Sensitive Information Disclosure |
| Agent tool scopes and credentials | R (integration) | A (least privilege, approvals) | LLM06 Excessive Agency; LLM01 Prompt Injection; AML.T0051 LLM Prompt Injection |
| Quality evaluation | R, A | Adds adversarial cases to the suite | AML.T0015 Evade AI Model |
| Inference API quotas and abuse limits | R (implements) | A (thresholds, monitoring) | LLM10 Unbounded Consumption; AML.T0024 Exfiltration via AI Inference API |
| Output handling in downstream code | R | A (secure coding rules, testing) | LLM05 Improper Output Handling |
| AI incident response | R (model rollback, retraining) | A (triage, containment, evidence) | All of the above |
Two rules keep the matrix honest. First, the person accountable for a control should not be the only person able to change it: if ML engineers both operate and approve registry access, the registry has no independent owner. Second, every row needs a named individual, not a team, or it becomes the gap described in the failure patterns below. See the MLOps Security Guide for pipeline controls and the Model Supply Chain Guide for intake.
Skills compared
| Skill area | ML engineer depth | AI security engineer depth |
|---|---|---|
| Python and ML frameworks | Expert: training loops, data loaders, performance tuning | Working: read and modify pipelines, write test harnesses |
| Statistics and evaluation | Expert: metrics, validation design, significance | Working: enough to judge non-deterministic test results and attack success rates |
| MLOps and serving | Expert: pipelines, registries, GPU scheduling, autoscaling | Working: know where artefacts, credentials and logs live |
| Threat modelling | Awareness | Expert: data flow, trust boundaries, abuse cases for AI features |
| Adversarial ML | Awareness to working | Expert: poisoning, evasion, extraction, prompt injection |
| Application and API security | Awareness | Expert: authentication, authorisation, input and output handling |
| Cloud IAM and secrets | Working: enough to run jobs | Expert: least-privilege roles, workload identity, key scoping |
| Incident response | Working: rollback, retraining | Expert: triage, containment, evidence, notification |
| Governance and regulation | Awareness of model documentation duties | Working: NIST AI RMF 1.0 functions (Govern, Map, Measure, Manage) and the Generative AI Profile, NIST AI 600-1 |
The table shows why neither role substitutes for the other. An ML engineer with awareness-level threat modelling will miss indirect prompt injection through retrieved documents; a security engineer with awareness-level ML will misread a 3 per cent jailbreak success rate as noise or as catastrophe. NIST AI 100-2 E2025, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, is a useful shared vocabulary for both.
Certifications for each path
Facts below were checked on the certifying bodies' pages in November 2026. Fees and formats change, so confirm before booking. Providers are listed alphabetically; order is not a ranking.
| Certification | Body | Path | Format from the official page |
|---|---|---|---|
| AWS Certified Machine Learning Engineer Associate | Amazon Web Services | ML engineer | MLA-C02 (in beta from 29 September 2026): 85 questions, 170 minutes, USD 75 beta price; MLA-C01 (65 questions, 130 minutes, USD 150) closed in English on 28 September 2026. Intended candidates have about a year of ML engineering and AWS experience |
| GIAC Machine Learning Engineer (GMLE) | GIAC | Bridge: ML skills for security practitioners | 82 questions, 3 hours, 65 per cent pass mark; Python, statistics, supervised and unsupervised learning, deep learning |
| Professional Machine Learning Engineer | Google Cloud | ML engineer | 50 to 60 questions, 2 hours, USD 200; 3 or more years' industry experience recommended; valid for 2 years |
| AIGP | IAPP | AI governance | Governance and law focus. See the IAPP AIGP (AI Governance Professional) Guide |
| AAISM | ISACA | AI security management | Aimed at experienced security managers; prerequisites in the ISACA AAISM and AAIA AI Certifications Guide |
Microsoft Learn shows its Azure AI Engineer Associate certification and renewal assessment as retired as of November 2026, so check each provider's current list before planning. For an ML engineer moving towards security, GMLE is less relevant than a security foundation; for a security engineer moving towards ML, GMLE or a cloud ML engineer associate exam proves the ML half. Hiring panels for both roles still weigh a portfolio, such as a threat model of a real RAG system or a reproducible evaluation harness, above any single certificate.
Career paths and moving between the roles
From ML engineer to AI security engineer
- Start inside your own pipeline. Threat model the system you already run: who can write to the training bucket, the registry and the serving configuration, and which credentials the jobs hold.
- Learn the security foundation. Authentication and authorisation, secure coding, cloud IAM and incident handling. The Application Security Engineer Career Guide lists the baseline.
- Learn to attack. Work through the OWASP LLM Top 10 and MITRE ATLAS case studies against a test deployment you own.
- Take a hybrid assignment. Join reviews of AI features, then own the adversarial evaluation suite.
From security engineer to AI security engineer
- Build a model end to end. Fine-tune a small model, build a retrieval pipeline and deploy an endpoint, so pipelines and registries stop being abstractions.
- Learn evaluation. Non-deterministic outputs need repeated trials and success rates, not single pass or fail results.
- Pair with an ML engineer. Shadow a release cycle and agree the responsibility matrix together.
Progression
ML engineers usually progress to senior or staff ML engineer, ML platform lead or applied research. AI security engineers progress to lead AI security engineer, AI red team lead or security architect for AI platforms. The paths cross at AI platform architecture, where one person designs both the serving platform and its controls. See the AI Red Teamer Career Guide for the offensive branch.
Team design by organisation size
- Small organisation, one AI product: no dedicated AI security engineer. An application security engineer covers AI features with a documented checklist, and one ML engineer is named as security champion.
- Mid-size, several AI products: one or two AI security engineers inside the security team, embedded in AI product reviews, with a shared responsibility matrix.
- Large enterprise or model provider: separate AI red team, AI platform security and AI governance functions, with ML platform teams owning secure defaults in shared tooling.
Worked scenario: an agent launch without clear ownership
A bank's ML team builds a customer service agent that reads account notes and can raise refunds through an internal API. The ML engineers evaluate answer quality and latency. The security team reviews the web front end and passes it. Nobody reviews the agent's service account, which was created with the refund API's full scope. In red teaming before launch, an indirect prompt injection hidden in a customer note makes the agent raise a refund. The fix is not more model tuning: the AI security engineer scopes the service account to read-only plus a refund action capped by amount and requiring human approval, and adds injection cases to the ML team's evaluation suite. The responsibility matrix gains a row: agent tool scopes, ML engineer responsible, AI security engineer accountable. See the AI Agent Identity vs Service Account.
Common failure patterns in team design
- Security reviews the wrapper, not the model path. The web application passes review while retrieval, tool calls and training data flows are never threat modelled.
- ML engineers hold unreviewed tier 0 credentials. Training jobs and notebooks run with broad cloud roles and long-lived API keys because nobody owns identity for AI workloads.
- Title inflation. An ML engineer is renamed AI security engineer without security training, or a security analyst is given the title without ML exposure; either way one half of the role is missing.
- Evaluation without adversarial cases. Quality suites measure helpfulness only, so a release that is easier to jailbreak ships as an improvement.
- No AI incident runbook. When a prompt injection or data leak happens, the SOC cannot read the logs and the ML team cannot run containment.
- Red team findings with no owner. Findings go to a shared channel and are never fixed because the matrix names a team, not a person.
Detection and measurement
Measure the partnership, not just each role:
- Percentage of AI features with a threat model signed off before release.
- Percentage of model releases whose evaluation suite includes adversarial test cases.
- Median time from AI red team finding to fix in production.
- Percentage of AI workload credentials (API keys, service accounts, agent tokens) with a named owner and reviewed scope.
- Number of responsibility matrix rows with a named individual on both sides.
Framework mapping
| Framework | Reference | Relevance to the role split |
|---|---|---|
| NIST CSF 2.0 | GV.RR-02 | Roles, responsibilities and authorities for cybersecurity risk are established and enforced |
| NIST CSF 2.0 | GV.RR-04; PR.AT-02 | Security in HR practices; training for specialised roles such as ML engineers |
| NIST SP 800-53 Rev. 5 | SA-8; SA-11 | Security engineering principles and developer testing, including adversarial evaluation |
| NIST SP 800-53 Rev. 5 | SR-3; RA-3; AT-3 | Model and data supply chain, AI risk assessment, role-based training |
| NIST AI RMF 1.0 | Govern, Map, Measure, Manage | Govern assigns roles; Map and Measure involve both engineers |
| OWASP Top 10 for LLM Applications 2025 | LLM01 to LLM10 | Shared threat list for the responsibility matrix |
| MITRE ATLAS | AML.T0051, AML.T0020, AML.T0010, AML.T0018 | Techniques both roles should recognise |
Practitioner checklist
- Write separate job descriptions with distinct success measures for ML engineers and AI security engineers.
- Agree a responsibility matrix for every AI lifecycle activity with named individuals, not teams.
- Separate operation from approval for model registry and training data write access.
- Give every AI workload credential an owner, a scope review and a rotation schedule.
- Add adversarial cases to the standard evaluation suite and block releases that regress.
- Write an AI incident runbook covering model rollback, credential revocation and log sources.
- Fund cross-training: ML engineers learn threat modelling, security engineers build and deploy a model.
- Review the matrix after each AI red team exercise and each incident.
Standards and references
- NCSC: Guidelines for secure AI system development
- NIST: AI 100-2 E2025, Adversarial Machine Learning
- NIST: AI Risk Management Framework
- OWASP: Top 10 for LLM Applications 2025
- MITRE: ATLAS
- AWS: Certified Machine Learning Engineer Associate
- GIAC: Machine Learning Engineer (GMLE)
- Google Cloud: Professional Machine Learning Engineer
Related NHI Mgmt Group resources: Cybersecurity Careers Guide, MITRE ATLAS Guide, Adversarial ML Taxonomy Guide, LLM Security Guide.