Technical Due Diligence for AI in Production: Questions That Reveal Real Readiness

This post is part of the AI in Production series, a five-part examination of what it takes to deploy AI successfully inside complex operational environments. The series is written for both business and technical leaders, with content that speaks to both where they converge and where their priorities diverge. Post 5 of 5.

The previous post in this series gave business leaders a framework for evaluating AI initiatives at the organizational level. This post is the technical counterpart: a set of questions for technical leaders evaluating whether an AI initiative is architected for production performance.

These questions apply to internal proposals, vendor solutions, and existing deployments under review. Strong answers demonstrate clarity across execution, data integrity, governance, and operational sustainability. When answers rely on informal process, manual oversight, or undocumented behavior, production performance degrades under load.

Execution architecture

Does the AI execute in-line within workflows or operate as a sidecar service?

In-line AI operates directly within the transaction path, where decisions execute as part of the workflow itself. This approach reduces latency and enables automation at scale, but requires rigorous failure mode design. Sidecar AI operates as an advisory or enrichment service, introducing less blast radius risk but often creating human bottlenecks and slower value capture. Integration choice determines reliability characteristics, recovery complexity, and performance ceilings.

How are decisions translated into system actions across ERP, CRM, TMS, or other operational systems?

The path from inference to action across system boundaries is where execution fragility concentrates. Each integration point requires explicit handling of state, failure, and retry behavior.

How is workflow state tracked across multi-step processes?

Multi-step workflows that span systems require explicit state tracking. Without it, partial executions create orphaned transactions, inconsistent data, and recovery scenarios that require manual intervention to resolve.

How are retries, idempotency, and rollback handled in distributed environments?

Distributed systems fail in partial, unpredictable ways. Execution layers must guarantee that retries do not duplicate financial or operational actions. Billing entries, shipment triggers, and allocation updates require idempotency guarantees that survive infrastructure failures.

How are human approval thresholds enforced at defined boundaries?

Human oversight operates most effectively at defined thresholds rather than at every decision. Execution layers should enforce confidence-based routing, approval triggers tied to financial exposure, and audit capture at escalation points. The boundary between automation and human review must be explicit, testable, and adjustable without redeployment complexity.

Data contracts and integrity

Are schemas versioned and governed through explicit data contracts?

Data producers and consumers must operate against explicit, versioned contracts. Schema drift, where upstream changes silently alter what downstream systems receive, is a leading cause of silent model degradation in production.

What freshness and completeness SLAs apply to decision-critical inputs?

Every AI-dependent workflow has a latency budget. Pricing data that is six hours stale in a market that moves hourly produces decisions based on a reality that no longer exists. Freshness requirements must be defined per workflow and enforced at the pipeline level.

How is lineage captured from input source to final action?

When an AI decision produces an unexpected outcome, teams must be able to trace backward from the decision to the data that informed it. Without lineage, root-cause analysis becomes guesswork and auditability becomes aspirational.

How is input drift detected and escalated?

Input distributions shift over time through seasonality, behavior change, vendor updates, or market dynamics. Pipelines require monitoring that detects when incoming data deviates meaningfully from what models were trained on, with escalation paths that trigger before downstream impact accumulates.

How are breaking changes in upstream systems managed?

Upstream systems change. The question is whether those changes propagate silently into AI behavior or surface through coordinated evolution strategies that protect downstream decision quality.

Observability and performance monitoring

What service level objectives govern latency and throughput?

Production AI requires defined performance envelopes. Without explicit SLOs, degradation is invisible until it has already affected operational outcomes.

How are model confidence distributions monitored over time?

Confidence score distributions, feature and input drift, output distribution shifts, override frequency, and escalation rate are the signals that reveal whether model behavior is stable or drifting. Ground truth feedback loops that connect predictions to outcomes provide the most reliable long-term signal.

What signals trigger automated rollback versus human escalation?

Alerting philosophy matters as much as instrumentation. Observability systems must distinguish between conditions that trigger automated rollback, conditions that require human review, and conditions that fall within acceptable operating variance. Treating every anomaly as a human escalation creates alert fatigue and slows response to genuine degradation.

How are decision-level metrics connected to margin or cost outcomes?

Business observability connects technical performance to economic results including margin per transaction, cost per decision, exception rate, cycle time, and sustained throughput. Without direct linkage between decisions and financial outcomes, teams optimize for technical metrics while margin drifts.

How is distributed tracing implemented across inference and execution?

True production observability requires distributed tracing that links source inputs, model inference, execution actions, and downstream financial outcomes. When a deviation occurs, teams must be able to determine whether the source is data quality, model behavior, execution logic, or downstream system response.

Governance and control

How are confidence thresholds calibrated relative to financial exposure?

Confidence scores carry meaning only in context. A routing decision with limited financial exposure requires different tolerance than a high-value billing adjustment. Governance systems must calibrate thresholds to financial risk rather than applying uniform confidence floors across decision types.

How are business rules versioned and conflict-resolved?

Business constraints evolve through pricing policies, compliance requirements, risk tolerances, and contractual limits. When these rules remain embedded in application logic or informal documentation, updates require engineering cycles and introduce regression risk. Rules as code allow business logic to evolve with appropriate version control and conflict resolution.

What audit artifacts are retained for decision reconstruction?

When decisions carry material impact, organizations must be able to reconstruct inputs used, rules applied, confidence levels, overrides triggered, and final actions executed. Auditability depends on capturing this information at decision time. Reconstruction from logs after the fact is unreliable.

How are escalation paths automated when thresholds are breached?

Governance requires explicit escalation pathways. When AI behavior falls outside defined tolerances—through confidence degradation, input drift, or business metric deviation—the system must respond through automated intervention rather than relying on manual detection.

How are regulatory compliance requirements integrated into execution logic?

Compliance constraints that live outside the system create audit exposure. Regulatory requirements must be encoded into execution logic with the same version control and auditability applied to other governance rules.

Lifecycle and operational discipline

How are model, prompt, rule, and threshold versions managed?

Every production decision component requires version control: models, prompts, rule configurations, threshold definitions, and orchestration logic. Promotion from development to production requires validation gates. Without version discipline, diagnosing production incidents becomes unreliable and rollback becomes high-risk.

What validation gates precede production promotion?

Production confidence emerges from controlled exposure. Effective strategies include shadow deployments that process production data without executing actions, controlled rollouts to defined traffic segments, integration testing across service boundaries, regression testing to protect existing behavior, and fault-injection testing to validate degradation logic.

How are batch, real-time, and agentic workloads handled differently?

Each workload type imposes distinct operational demands. Batch systems require scheduled retraining pipelines, validation checks prior to promotion, and clear rollback to previous versions. Real-time systems require tight service level objectives, canary releases, and deterministic fallback logic within defined latency thresholds. Agentic systems extend further, requiring action-rate limits, financial caps, context and memory management, kill-switch controls, and cross-agent conflict resolution protocols.

What testing strategies validate behavior under stress conditions?

Systems fail. The question is whether they fail gracefully or in ways that require manual recovery. Testing for stress conditions, including bad inputs, latency spikes, partial outages, and cascading failures, is as important as testing for the expected case.

How is cost-per-decision monitored and optimized over time?

Every AI-driven action carries inference, orchestration, and infrastructure cost. Cost-per-decision analysis evaluates inference expense, orchestration overhead, monitoring cost, and downstream execution impact. Runtime systems should support differentiated routing, applying lightweight models to routine high-volume decisions and reserving more capable models for complex cases that warrant the expense.

What knowledge transfer plan ensures long-term maintainability?

Vendor expertise that exits at project close represents a slow-motion failure. What internal teams need to own, operate, and extend the system should be defined before the engagement begins and built into the delivery plan.

How to use these questions

These questions evaluate architectural readiness, not implementation completeness. An initiative at an early stage won't have answers to every question, but it should have a clear plan for each. Gaps that are acknowledged and sequenced are manageable. Gaps that are undiscovered or deferred without a plan become the failure modes that surface under production load.

AI initiatives reach durable scale when these questions have clear, architectural answers. That clarity, across execution, data integrity, governance, observability, and operational discipline, is what separates AI that performs in production from AI that performs in a demo.