Technical due diligence for AI projects evaluates five areas that traditional software due diligence misses: data pipeline reliability and data quality, model performance under production conditions (not just benchmark accuracy), model governance and versioning, infrastructure costs at scale, and the gap between demo performance and production performance. Over 85% of enterprise AI projects never reach production. Due diligence that only checks model accuracy will miss the warning signs.
Standard software acquisitions have mature checklists. Code quality, test coverage, architecture review, security audit, scalability assessment. These still apply to AI projects, but they cover maybe 40% of the real risk. The other 60% lives in the data, the model lifecycle, and the gap between what the demo shows and what production delivers.
Why is AI due diligence different from standard software due diligence?
Standard software is deterministic. Given the same input, it produces the same output. AI systems are probabilistic. The same input can produce different outputs depending on the model version, the training data it was built on, and even the inference infrastructure running it.
This means AI adds four risk categories that traditional software due diligence does not cover:
- Data dependency. The model is only as good as its training data. If the data source degrades, changes format, or becomes unavailable, the model degrades with it. There is no code fix for bad data.
- Model degradation. Accuracy drops over time without retraining because the real world changes. A model trained on 2024 customer behaviour will underperform on 2026 customer behaviour. This is called model drift, and every production AI system experiences it.
- Infrastructure cost scaling. GPU and compute costs can increase 10x with user growth. A system that costs $2,000/month to run at demo scale can cost $20,000/month at production scale. Cost projections based on demo usage are almost always wrong.
- The demo-to-production gap. A model that performs well on curated, clean test data often fails on the messy, inconsistent data that real users and real business processes generate. This is the single largest source of post-acquisition disappointment in AI deals.
What should you ask about the data pipeline?
The data pipeline is the foundation of every AI system. If the pipeline is fragile, the model is fragile. No amount of model sophistication compensates for unreliable data.
Ask these questions and evaluate the answers against the standards below:
- Where does training data come from? A good answer names specific sources, APIs, databases, or data vendors. A red flag is "various sources" or an inability to list them.
- How is data cleaned and validated? Look for automated validation rules, schema enforcement, and anomaly detection. Manual cleaning by a single data engineer is a single point of failure.
- What is the data freshness cadence? Daily, weekly, monthly? How long can the model run on stale data before performance degrades? Ask for evidence, not estimates.
- Is there data lineage tracking? Can the team trace any model prediction back to the specific training data that influenced it? Lineage tracking is required for regulatory compliance in financial services, healthcare, and insurance.
- What happens when a data source changes format or goes offline? Ask for the incident response plan. If there is no documented plan, the team has never dealt with this scenario, which means they have never operated the system long enough for it to break.
- How is PII handled? Look for data masking, encryption at rest and in transit, access controls, and documented retention policies. Ask about GDPR, CCPA, or industry-specific data regulations.
- What is the data volume and storage cost trajectory? Storage costs scale with data retention. A system that stores every inference input for retraining can see storage costs grow faster than compute costs.
What should you ask about model performance?
Model accuracy reported on test data is the number most AI companies lead with. It is also the least useful number for due diligence. Test data is curated, balanced, and clean. Production data is none of these.
The questions that matter:
- What is the accuracy on production data, not test data? Ask for production logs showing accuracy over the last 90 days. If these logs do not exist, the team is not monitoring model performance in production.
- How does performance vary across different input types, geographies, or user segments? A model that performs well on US English text may fail on UK English, accented speech, or non-standard inputs. Ask for segment-level performance breakdowns.
- What is the latency at p50 and p99? The p50 (median) number tells you the typical user experience. The p99 tells you the worst-case experience for 1 in 100 requests. If p99 latency is over 5 seconds for a real-time application, the system has a scaling problem.
- What happens when the model is uncertain? Does the system have a confidence threshold below which it escalates to human review? If not, the model is making low-confidence decisions with no safety net.
- Has accuracy trended up, down, or flat over the last 6 months? A downward trend indicates model drift. A flat trend with no retraining could mean the team got lucky, or it could mean the data distribution has not changed yet. Ask what will happen when it does.
What should you ask about model governance?
Model governance determines whether the AI system can be maintained, audited, and improved after acquisition. Without governance, you are buying a black box that will degrade over time with no documented way to fix it.
Question | Good answer | Red flag |
|---|---|---|
How are model versions tracked? | Git-tracked model registry (MLflow, Weights & Biases, or equivalent) with versioned artifacts, hyperparameters, and training data references | Models saved as files on a shared drive with names like "model_v2_final_FINAL.pkl" |
Is there A/B testing for model updates? | Canary or shadow deployments where new models run alongside production models with traffic splitting and statistical comparison | New models replace old models directly in production with no comparison period |
Can you roll back to a previous model version? | One-command rollback with automated health checks that trigger rollback if metrics degrade | No rollback procedure documented. Previous models not retained. |
Is there bias monitoring? | Automated fairness metrics across protected categories, reviewed quarterly with documented results | "We haven't had any bias complaints" or no monitoring at all |
What is the retraining schedule? | Automated retraining triggered by drift detection metrics, with manual review before promotion to production | "We retrain when we notice performance dropping" with no automated detection |
Is there an audit trail? | Every model decision logged with input, output, confidence score, model version, and timestamp. Queryable and retained per compliance requirements. | No logging, or logs retained for less than 30 days, or only aggregate metrics stored |
What should you ask about production infrastructure?
Infrastructure costs for AI systems behave differently from traditional SaaS. A standard web application scales roughly linearly with users. An AI system's compute costs can scale exponentially depending on model size, inference frequency, and whether the system uses real-time inference or batch processing.
The infrastructure questions:
- What are the current GPU/compute costs per month? Get the actual invoice, not an estimate. Compare it to the revenue the AI system generates. If compute costs are 40%+ of AI-attributed revenue, the unit economics may not hold at scale.
- What is the cost projection at 10x current usage? Ask the team to model this. If they have not modelled it, that is a red flag on its own. GPU costs do not scale linearly, and reserved instance pricing changes the math significantly.
- Is auto-scaling configured and tested? Ask when the system last auto-scaled in production. If the answer is never, ask what happens during a traffic spike. A system that has never been tested under load will fail under load.
- What monitoring and alerting is in place? Look for model-specific monitoring (accuracy, latency, throughput) in addition to standard infrastructure monitoring (CPU, memory, disk). AI systems need both layers.
- How long does it take from model update to production deployment? Under one hour is good. Over one day means the deployment pipeline has manual steps or approval bottlenecks. Over one week means there is no deployment pipeline.
- What is the disaster recovery plan for model serving? If the primary inference server goes down, how long until a backup is serving requests? Ask for the documented RTO (recovery time objective) and when it was last tested.
What are the red flags that the AI is a demo, not a production system?
The difference between a demo and a production AI system is the difference between a concept car and a vehicle you can drive to work. Demos are built to impress. Production systems are built to survive. Here are the signals that tell them apart:
- No monitoring dashboard for model performance. If the team cannot show you a live dashboard with accuracy, latency, and throughput metrics, the system is not being monitored in production. This is the single fastest disqualifier.
- Training data has not been refreshed in 6+ months. A production AI system retrains regularly because the world changes. A demo was trained once and never updated.
- No documented process for model retraining. Ask: "Walk me through how you retrain the model." If the answer involves one person running a Jupyter notebook on their laptop, this is not production infrastructure.
- "Accuracy" numbers come from the test set, not production logs. Test set accuracy tells you how the model performed on curated data during development. Production accuracy tells you how it performs on real data from real users. These numbers are almost never the same.
- The data scientist who built the model is the only person who can deploy it. If one person holds all the knowledge needed to train, deploy, and debug the model, you are acquiring a single point of failure. Ask about documentation, runbooks, and whether anyone else on the team has deployed a model update.
- The system only works on the demo dataset. Ask to run the model on a new, unseen dataset during due diligence. If the team resists or the performance drops significantly, the model is overfit to its training data.
- No error handling for edge cases. Ask: "What happens when the model receives an input it has never seen before?" A production system has graceful degradation (fallback to rules, human escalation, or a safe default). A demo crashes or returns nonsense.
How Madgeek approaches AI system architecture
Madgeek builds production AI systems with monitoring, retraining pipelines, and graceful degradation from day one. The architecture decisions that matter for due diligence (model versioning, confidence thresholds, automated drift detection) are part of the initial system design, not afterthoughts.
The call quality AI system deployed for an operations team (scaling from 50 to 80+ agents in 3 months) includes continuous accuracy monitoring and automated retraining triggers. When accuracy on any call category drops below the threshold, the system flags the category, queues new training data, and alerts the operations team. The model does not silently degrade.
If you are evaluating an AI acquisition or investment and need a technical review of the system architecture, data pipeline, and production readiness, Madgeek runs technical due diligence assessments that cover every area in this checklist. For a deeper look at why enterprise AI projects fail, read our resource on enterprise AI projects that failed and the patterns behind them. To explore how we build AI software for production environments, start with a scoped discovery call.
Written by
Abhijit Das
CEO
Building AI tools for businesses from legacy to new age SaaS startups
LinkedIn ↗Need a team to build this for your business?