Notifications
Clear all
Topic starter
19/08/2026 4:08 pm
TL;DR: AI systems need a developer stack built around data management, model versioning, testing, deployment, and monitoring because traditional software tooling does not cover model opacity, data drift, or performance degradation, according to Fiddler. The governance challenge is that AI quality depends on lifecycle controls that must be operationalised, not assumed.
NHIMG editorial — based on content published by Fiddler: AI Needs a New Developer Stack
By the numbers:
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
Questions worth separating out
Q: How should teams govern AI models moving from training to production?
A: Teams should treat model promotion as a governed change, not a routine deployment.
Q: Why do AI systems need monitoring beyond normal application observability?
A: Because model behaviour can degrade even when the software stack looks healthy.
Q: What do security and platform teams get wrong about AI release management?
A: They often assume that code validation is enough.
Practitioner guidance
- Define a model lifecycle control set Map data preparation, training, evaluation, deployment, and monitoring to named control owners so each stage has an accountable review point.
- Require reproducible dataset snapshots Store the exact training dataset version and feature set with each model release so you can recreate outcomes and investigate regressions.
- Separate validation gates by test type Use canary tests for dependency readiness, unit tests for data and code quality, and A/B tests for business impact before broad rollout.
What's in the full article
Fiddler's full blog post covers the implementation detail this post intentionally leaves for the source:
- Practical examples of model-centric debugging and interpretability workflows for data scientists
- The specific monitoring categories Fiddler uses for feature, performance, ops, and bias signals
- How model versioning and dataset snapshots support reproducibility across release cycles
- The developer-tooling implications of moving from conventional SDLC to ML lifecycle management
👉 Read Fiddler's analysis of the AI developer stack and model lifecycle controls →
AI development stacks: what practitioners need to govern now?
Explore further
19/08/2026 4:41 pm
AI engineering now behaves like a governance discipline, not just a development practice. The article shows that machine learning introduces a lifecycle of data, experimentation, deployment, and monitoring that conventional software pipelines do not manage well. That shifts the control problem from code review to lineage, reproducibility, and runtime assurance. For security and platform teams, the question is not whether AI needs a new stack but whether the stack includes enforceable governance checkpoints.
A question worth separating out:
Q: How do organisations know if an AI system has drifted beyond its mandate?
A: Organisations know an AI system has drifted when its behaviour remains technically permitted but no longer matches the intended purpose, scope, or business outcome. The most useful signals are expanded tool use, new workflow paths, and actions that still pass policy checks while exceeding the original mandate.
👉 Read our full editorial: AI development stacks need new controls for data, testing and monitoring
