Skip to content

L7.1.2 — Securing the AI lifecycle stage-by-stage

Type: Theory · Duration: ~5 min · Status: Mandatory Module: Module 7 — Securing the AI Pipeline (MLSecOps & Defenses) Framework tags: NIST AI RMF (all functions across all stages)

Learning objectives

  1. Map specific security controls onto each of the six AI lifecycle stages from M1.4.
  2. Identify which stage the application team controls vs negotiates with vendors.

Core content

Module 1.4 introduced the six AI lifecycle stages: Data, Train, Eval, Deploy, Monitor, Fine-tune. This lesson maps specific security controls onto each.

Stage 1: Data

Controls (mostly vendor-side; application teams influence via procurement): - Data provenance tracking — every dataset row has a documented source. - Dedup pipelines — reduces verbatim memorization (Module 5). - Filtering for harmful content — toxicity, CSAM, PII filters at ingestion. - Eval-set isolation — held-out test sets never re-enter training (prevents contamination).

For application teams: ask vendors for documentation of these controls. Increasingly available in model cards / system cards.

Stage 2: Train

Controls (vendor-side for foundation models; application-side for fine-tunes): - Differential privacy (DP-SGD) for sensitive data (Module 5). - Backdoor scanning on the resulting model — emerging tooling. - Training-pipeline integrity — locked dependencies, immutable build environment, audit logs. - Reproducibility — same data + code + seeds reproduce the same model.

Stage 3: Eval

Controls (jointly vendor + application): - Standard accuracy benchmarks — task-relevant. - Safety / robustness benchmarks — adversarial robustness (PGD/AutoAttack, TextAttack), jailbreak resistance, refusal rates on harmful prompts. - Domain-specific benchmarks — legal, medical, etc. if relevant. - Independent re-evaluation — application teams should run their own eval on candidate models (Module 4 L4.4.3), not just trust vendor claims.

Stage 4: Deploy

Controls (application-team-owned): - Guardrails — runtime filters on input and output (L7.3 lessons). - Structured output — JSON schemas, function calling (L7.3.2). - Authorization-aware tool calls — for agents (L3.4.2). - Rate limits + tiered access — extraction defense (L5.4.2). - Vector DB access control — if RAG (L5.3.2). - Per-tenant query monitoring — anomaly detection (L5.4.2).

Stage 5: Monitor

Controls (application-team-owned): - Prompt/response logging with retention policy (L7.4.1). - PII redaction on logs (L7.4.2). - Drift detection — input distribution shifts, output anomalies. - Abuse detection — jailbreak patterns, extraction signals. - Cost monitoring — token spend, DoS detection. - AI-specific incident telemetry — feeding into the IR pipeline.

Stage 6: Fine-tune / re-train

Controls (application-team-owned, with vendor for some patterns): - Fine-tune data audit (L4.3.1). - DP-SGD on fine-tune for sensitive data. - Post-fine-tune safety eval — alignment-regression check. - Adapter signing & provenance — for shipped LoRA adapters. - Re-training trigger criteria — incident-driven, drift-driven, scheduled.

What the application team owns vs negotiates

Stage Application team owns Negotiates with vendor
Data (fine-tune data only) All foundation data
Train (fine-tune training only) All foundation training
Eval Independent re-eval; standing eval suite Vendor's published evals
Deploy Everything —
Monitor Everything —
Fine-tune Everything (when you fine-tune) —

The bold rows are what an AI security engineer in an application team focuses on day-to-day. The unbolded rows are negotiated via procurement, contractual representations, and vendor security reviews (Module 8 covers).

The 2026 reality

Few application teams in 2026 do all of this. The labs in M7 cover the controls most worth implementing first: - L7.7: runtime guardrails (deploy stage). - L7.8: red-team eval in CI (eval stage). - L7.9: prompt/response logging with PII redaction (monitor stage).

If you ship those three, you're ahead of most production AI products on AI-specific defensive posture. Module 8 covers the governance layer that surrounds this engineering work.

Real-world example

The "Microsoft SDL for AI" (referenced in L7.1.1) and Anthropic's Responsible Scaling Policy both publish their AI-lifecycle controls at this level of granularity. Both are useful references when you're designing your own AI-SDLC controls. The Anthropic RSP, in particular, maps to NIST AI RMF — read alongside.

Key terms

  • AI lifecycle stage controls — the per-stage list above.
  • Negotiated controls — controls implemented by vendor, reviewed by application team.
  • Owned controls — controls the application team implements directly.

References

  • L1.4 (the six-stage lifecycle).
  • Microsoft SDL for AI, Anthropic Responsible Scaling Policy.
  • NIST AI RMF function-by-function mapping.

Quiz items

  1. Q: Which lifecycle stages does the application team typically own end-to-end? A: Deploy, Monitor, Fine-tune. The earlier stages (Data, Train, Eval upstream) are negotiated with the vendor.
  2. Q: Name three Deploy-stage controls. A: Any three of: guardrails on input/output; structured output; authorization-aware tool calls; rate limits + tiered access; vector DB access control; per-tenant query monitoring.
  3. Q: What are the three controls Module 7's labs cover? A: Runtime guardrails (L7.7); red-team eval in CI (L7.8); prompt/response logging with PII redaction (L7.9).

Video script (~600 words, ~4.5 min)

[SLIDE 1 — Title]

Securing the AI lifecycle stage-by-stage. Five minutes. Module 1.4 introduced the six AI lifecycle stages. This lesson maps specific security controls onto each.

[SLIDE 2 — Stage 1: Data]

Stage 1: Data. Mostly vendor-side controls. Data provenance tracking — every dataset row has a documented source. Dedup pipelines — reduces verbatim memorization. Filtering for harmful content — toxicity, CSAM, PII filters at ingestion. Eval-set isolation — held-out test sets never re-enter training. For application teams: ask vendors for documentation of these controls. Increasingly available in model and system cards.

[SLIDE 3 — Stage 2: Train]

Stage 2: Train. Differential privacy for sensitive data — Module 5. Backdoor scanning on the resulting model — emerging tooling. Training-pipeline integrity — locked dependencies, immutable build environment, audit logs. Reproducibility — same data, code, seeds reproduce the same model.

[SLIDE 4 — Stage 3: Eval]

Stage 3: Eval. Standard accuracy benchmarks. Safety and robustness benchmarks — PGD, AutoAttack, TextAttack, jailbreak resistance, refusal rates. Domain-specific benchmarks if relevant. Independent re-evaluation — application teams should run their own eval, not just trust vendor claims. Module 4 L4.4.3 covered this.

[SLIDE 5 — Stage 4: Deploy]

Stage 4: Deploy. Application-team-owned end-to-end. Guardrails on input and output. Structured output — JSON schemas, function calling. Authorization-aware tool calls for agents. Rate limits and tiered access for extraction defense. Vector DB access control for RAG. Per-tenant query monitoring. The lessons in L7.3 deep-dive most of these.

[SLIDE 6 — Stage 5: Monitor]

Stage 5: Monitor. Application-team-owned. Prompt and response logging with retention policy. PII redaction on logs. Drift detection. Abuse detection — jailbreak patterns, extraction signals. Cost monitoring. AI-specific incident telemetry feeding into the IR pipeline. L7.4 lessons deep-dive.

[SLIDE 7 — Stage 6: Fine-tune]

Stage 6: Fine-tune. Application-team-owned when you fine-tune. Fine-tune data audit. DP-SGD on fine-tune for sensitive data. Post-fine-tune safety eval — alignment-regression check. Adapter signing and provenance. Re-training trigger criteria — incident-driven, drift-driven, scheduled.

[SLIDE 8 — Owned vs negotiated]

What the application team owns vs negotiates. Data: foundation data is negotiated; fine-tune data is owned. Train: same split. Eval: vendor's evals negotiated, your own independent eval owned. Deploy, Monitor, Fine-tune: all owned. The bolded rows are what an AI security engineer in an application team focuses on day-to-day. Earlier stages are negotiated via procurement, contractual representations, vendor security reviews. Module 8 covers.

[SLIDE 9 — 2026 reality + up next]

Few application teams in twenty-twenty-six do all of this. The labs in M7 cover the controls most worth implementing first. L7.7 runtime guardrails — deploy stage. L7.8 red-team eval in CI — eval stage. L7.9 prompt/response logging with PII redaction — monitor stage. Ship those three and you're ahead of most production AI products.

Next: model governance, signing, provenance. Five minutes. See you there.

Slide outline

  1. Title — "Securing the AI lifecycle stage-by-stage".
  2. Stage 1: Data — four-control card.
  3. Stage 2: Train — same shape.
  4. Stage 3: Eval — same shape.
  5. Stage 4: Deploy — same shape (highlight: "application-team-owned").
  6. Stage 5: Monitor — same shape.
  7. Stage 6: Fine-tune — same shape.
  8. Owned vs negotiated — the table from the lesson body with bolded ownership rows.
  9. 2026 reality + up next — three-lab callout: L7.7/L7.8/L7.9.

Production notes

  • Recording: ~4.5 min. Cap 5.
  • Slide 8 (owned vs negotiated) is the reference learners will save.