Google's famous paper "Hidden Technical Debt in Machine Learning Systems" identified that ML code is a tiny fraction of a real-world ML system. The surrounding infrastructure — data collection, feature engineering, monitoring, configuration, serving — is where technical debt accumulates. And it accumulates fast.
Most enterprise AI deployments are 2-4 years old and already drowning in debt they don't recognize. Here's how to identify and manage it.
Types of ML Technical Debt
Data Debt
- Undocumented data dependencies: Model depends on data sources that nobody documented. When the source changes, the model breaks and nobody knows why.
- Unstable data pipelines: Feature pipelines that were "temporary" two years ago, running on someone's cron job, processing data through undocumented transformations
- Training-serving skew: Features computed differently in training vs. serving. The model trained on one data distribution and infers on another.
- Stale features: Features that were predictive when the model was built but have lost relevance. They add complexity without adding value.
- Data version chaos: No record of which data version trained which model. Can't reproduce past results. Can't audit data lineage.
Model Debt
- Notebook-to-production gap: Models developed in notebooks, then manually translated to production code. The translation introduces bugs.
- Undocumented models: No model cards, no documentation of training data, performance characteristics, or known limitations
- Dead models: Models deployed and forgotten that still consume resources but nobody uses or monitors
- Entangled models: Multiple models sharing features, data pipelines, or infrastructure where changing one breaks others
- Configuration debt: Model behavior controlled by dozens of configuration parameters that nobody fully understands
Infrastructure Debt
- Snowflake infrastructure: Each model deployed with bespoke infrastructure. No shared platform, no common patterns.
- Manual deployments: Model updates deployed manually. No CI/CD, no automated testing, no rollback capability.
- Missing monitoring: Models running in production with no performance monitoring, no drift detection, no alerting
- Orphaned resources: GPU instances, storage, and compute provisioned for experiments that ended months ago
Governance Debt
- No model inventory: Nobody knows how many models are in production, what they do, or who's responsible for them
- Missing audit trails: No logs of model decisions, no evidence of validation, no compliance documentation
- Outdated risk assessments: Risk assessments done at deployment time, never updated as the model and data change
- Regulatory exposure: Models that may classify as high-risk under AI Act but haven't been assessed
Measuring ML Technical Debt
Debt Indicators
- Time to deploy a new model: If it takes months, infrastructure debt is high
- Time to retrain an existing model: If retraining requires heroic effort, pipeline debt is high
- Number of undocumented models: Models in production without model cards or documentation
- Monitoring coverage: Percentage of production models with active performance monitoring
- Incident recovery time: How long to recover from a model incident — longer times indicate infrastructure and process debt
- Team bus factor: How many people understand each model well enough to maintain it? Bus factor of 1 = critical debt
Kubernetes Recipes
A practical guide for container orchestration and deployment by Grzegorz Stencel & Luca Berton (Apress).
Watch on Skillshare →Debt Reduction Strategy
Phase 1: Inventory and Triage (Months 1-2)
- Create a complete inventory of all ML models in production
- Document owner, purpose, data dependencies, and monitoring status for each
- Classify debt severity: critical (regulatory risk, no monitoring), high (no documentation, manual deployment), medium (suboptimal infrastructure), low (cosmetic)
- Identify and decommission dead models
Phase 2: Foundation Building (Months 2-6)
- Deploy shared ML platform infrastructure (even minimal: model registry + CI/CD + monitoring)
- Establish model documentation standard (model cards) and backfill for critical models
- Implement monitoring for all production models
- Automate deployment for the most frequently updated models
Phase 3: Systematic Reduction (Months 6-12)
- Migrate models to shared platform incrementally
- Standardize data pipelines and feature engineering
- Implement data versioning and lineage tracking
- Complete governance documentation for regulatory compliance
Phase 4: Sustainability (Ongoing)
- Allocate 20% of ML team capacity to debt reduction — permanently
- Include debt assessment in every model deployment review
- Track debt metrics alongside delivery metrics
- Quarterly debt review and reprioritization
The 20% Rule
Allocate 20% of ML engineering capacity to technical debt reduction — every sprint, every quarter, non-negotiable. Without this discipline, debt accumulates faster than you can pay it down. The interest on ML technical debt is model failures, compliance gaps, and teams that spend all their time maintaining and none building.
Luca Berton