Artificial intelligence is now part of the product and operating story for a growing number of software businesses. It appears in workflow automation, recommendations, analytics, summarisation, support tooling, and increasingly in agent-style features that do more than simply surface information. For investors and acquirers, that changes the diligence question. The issue is no longer just whether a company has an AI narrative. It is whether the business is genuinely ready to deploy, govern, and scale AI features without introducing avoidable product, technical, or regulatory risk.
That is why artificial intelligence readiness should be treated as a diligence topic in its own right. It sits across technical due diligence and product due diligence. Technical diligence tests whether the underlying platform, data estate, controls, and operating environment are strong enough to support AI safely. Product diligence tests whether the AI use cases are credible, whether they improve the product in meaningful ways, and whether the organisation can turn them into reliable customer value.
If those questions are skipped, investors can end up funding an AI roadmap that looks strategically attractive but is poorly controlled in practice. Weak data quality, unclear ownership, limited explainability, brittle integrations, or immature monitoring can turn an AI feature set from a differentiator into a source of risk. Readiness therefore matters not just for innovation, but for investment quality.
What AI readiness means in due diligence
Artificial intelligence readiness is not a single technical score or a binary conclusion. In diligence, it is the practical assessment of whether a business has the data foundations, product discipline, control environment, and operating maturity needed to use AI responsibly and effectively.
That review usually needs to cover several linked questions:
- What data the AI features rely on, and whether that data is governed well enough to trust the outputs
- How models are selected, trained, versioned, evaluated, and monitored
- Whether the product experience explains AI-driven actions clearly enough for customers and internal teams
- Whether automated decisions have suitable human oversight, escalation paths, and auditability
- Whether the company is building AI where it creates real product value, rather than where it simply sounds marketable
The important point is that AI readiness is not only about technical capability. A company can ship working models and still be weak on governance, data handling, operating controls, or product design. In a diligence context, those weaknesses matter because they can affect reliability, regulatory exposure, customer trust, and the realism of the growth plan.
Data governance is usually the first practical test
Most AI diligence questions become data governance questions very quickly. If the underlying data is inconsistent, poorly classified, overexposed, or insufficiently documented, the AI layer will inherit those weaknesses. For investors, that makes data governance one of the clearest indicators of whether AI ambition is grounded in operational reality.
In practice, this means understanding what data enters the system, where it is stored, which systems can access it, and how it is controlled across the product estate. Businesses using AI in workflow-heavy software often have customer data moving across multiple services, integrations, and user roles. That makes lineage, access control, retention, and minimisation materially important.
Where personal data or employee data is involved, governance also needs to stand up to a privacy and compliance review. That does not mean a diligence workstream becomes a substitute for legal advice. It does mean investors should test whether the business has thought clearly about consent, retention, data handling boundaries, and the exposure created by model inputs and outputs. If the AI feature depends on broad access to sensitive operational data, that should be explicit in the risk picture.
Weak governance often shows up in predictable ways:
- Unclear ownership of source data and training inputs
- Inconsistent schemas or poor data quality controls
- Little confidence in retention and deletion policies
- Over-permissive access for internal users, vendors, or automated agents
- Limited visibility into which integrations receive or expose sensitive records
Those problems are not theoretical. They tend to translate directly into model error, unreliable output quality, customer concern, and harder remediation later.
Model lifecycle, technical debt, and monitoring matter more than the demo
A polished AI demo tells you very little about the quality of the model lifecycle behind it. In diligence, investors need to understand whether the business has a credible operating approach for selecting, updating, testing, and monitoring AI features over time.
That includes basic questions such as:
- What models or third-party AI services are being used
- How prompts, model versions, and evaluation criteria are managed
- Whether training or fine-tuning data is documented properly
- How output quality is measured after release
- What happens when models drift, degrade, or produce unreliable results
Technical debt is also relevant here. AI features often get layered into an existing application quickly, especially when a business is under commercial pressure to respond to market demand. That can create fragmented pipelines, duplicated logic, brittle prompt orchestration, or opaque dependencies on external model providers. None of those issues are necessarily fatal, but they do affect scale risk, support burden, and the amount of engineering work required to make the AI roadmap sustainable.
From an investment perspective, the key question is not whether every AI system is perfect. It is whether the company has a defensible path to keeping those systems reliable as customer usage, data volume, and commercial expectations grow.
AI agents and automated actions change the risk profile
The diligence bar rises again when AI is not just producing content or summarising information, but taking actions inside the product. Agent-style features, automated approvals, triage logic, recommendation engines, or operational assistants can create real efficiency, but they also introduce a more direct control risk.
Once AI starts influencing workflows rather than simply supporting them, investors should look more closely at:
- Permissions and role boundaries for automated actors
- The quality of audit trails around automated actions
- How easily human users can review, override, or escalate AI-driven outcomes
- Whether the product distinguishes clearly between recommendations and decisions
- Which decisions are too sensitive to automate without explicit review
This is where explainability becomes important. Customers and internal operators do not always need deep model transparency, but they do need enough context to understand why the system acted as it did and whether it can be trusted. If the product creates high-impact outcomes without clear rationale or escalation paths, that should be treated as a real diligence concern.
Generative AI features need product design discipline, not just technical access
Many businesses can now add generative AI features quickly. The harder question is whether those features actually improve the product in a controlled way. Product due diligence therefore needs to ask not just whether the AI works, but whether the feature design is sensible for real users.
Strong AI product design usually shows a few common characteristics:
- The user understands where AI is being used and what it is meant to do
- The feature is placed inside a genuine workflow rather than bolted on as novelty
- High-impact outputs are reviewable before they affect customers or operations
- The interface sets expectations clearly around confidence, limitations, and user control
- AI is solving a meaningful friction point, not simply generating more content for its own sake
This is where product due diligence complements technical due diligence. Technical review can confirm whether controls and integrations are sensible. Product review tests whether the AI use case is coherent, whether it fits the broader roadmap, and whether the business is likely to create real customer value rather than feature noise.
Integrations, incident response, and operating controls still matter
AI readiness is rarely contained within a single product module. The risk often sits at the boundary between systems: calendars, HR platforms, collaboration tools, data warehouses, support platforms, CRM workflows, or payroll systems. As soon as AI features depend on exchanged data, external APIs, or event-driven workflows, the diligence review needs to widen.
Investors should usually test:
- Whether integrations expose more data than is necessary for the AI use case
- Whether outbound notifications or summaries risk leaking sensitive information
- Whether the business can trace where inputs came from and where outputs were sent
- Whether there are alerting thresholds for anomalous behaviour, failure, or drift
- Whether incident response plans cover AI-specific failure modes as well as broader security events
This matters because AI issues rarely arrive labelled as “AI issues”. They often show up as customer complaints, workflow errors, unexpected approvals, data leakage, or operational confusion. A business that cannot monitor and respond to those problems quickly is carrying more risk than its AI roadmap may suggest.
What investors should ask for as evidence
The most useful AI diligence is evidence-led. Good management teams should be able to explain not just what they are building, but how they are controlling it and how they know it is working.
Typical evidence requests might include:
- 1System and data flow diagrams showing where AI inputs and outputs sit
- 2Access controls, role models, and audit-log examples for AI-relevant workflows
- 3Model inventory, prompt management, or vendor dependency records where applicable
- 4Documentation for retention, deletion, privacy review, and data-handling boundaries
- 5Monitoring dashboards or alerting examples tied to model performance or output quality
- 6Product analytics showing adoption, usage depth, or impact for AI-enabled workflows
- 7Roadmap artefacts showing how AI initiatives are prioritised and sequenced
The aim is not to turn diligence into a research project. It is to establish whether the AI story is supported by enough operational substance to justify confidence.
How FoundationState would frame AI readiness in diligence
FoundationState would usually assess AI readiness as a cross-cutting topic rather than as an isolated innovation review.
Within technical due diligence, the focus would be on platform foundations, data architecture, security posture, governance controls, integration boundaries, monitoring, and operational resilience. The question is whether the underlying estate can support AI safely and sustainably.
Within product due diligence, the focus would be on use-case quality, roadmap realism, workflow fit, delivery discipline, and whether AI meaningfully improves the product proposition. The question is whether AI is being applied in a way that strengthens the commercial case rather than weakening it.
That distinction matters. A business may have an attractive AI roadmap but weak data discipline. Equally, it may have reasonable technical controls but a poor product rationale for where AI is being used. Investors usually need both perspectives to understand whether AI is a source of upside, risk, or both.
Conclusion
Artificial intelligence readiness is now a practical diligence question for technology-led businesses. It is no longer enough to ask whether the company has AI features or an AI strategy. The more important question is whether the business has the data governance, model discipline, product design maturity, and operating controls to use AI responsibly at scale.
For investors and acquirers, that makes AI readiness relevant to both technical due diligence and product due diligence. Technical diligence tests whether the estate can support the AI layer. Product diligence tests whether the AI layer actually deserves to be backed.
Where those answers are strong, AI can reinforce the investment thesis. Where they are weak, the same AI roadmap can become a source of delivery, governance, and customer risk. That is why AI readiness should be treated as a formal diligence topic rather than as a side conversation attached to the product demo.
