Evaluating AI powered applications: A new frontier for M&A software due diligence

AI footprint: Understanding what AI really does

The first step in evaluating an AI-enabled application is to clarify the true nature and extent of the AI capabilities embedded in the product. Many companies promote themselves as “AI-driven” for marketing purposes even when the actual usage of AI is minimal. But investors don’t want to pay a premium for a trivial implementation. Others rely heavily on complex models that may be deeply intertwined with core business functionality.

Understanding the AI footprint begins with identifying the specific tasks the AI performs in the application. Applications can utilize text generation, classification, summarization, or decision support capabilities. Or they may rely on predictive models trained on proprietary datasets. A clear architecture diagram is often the best way to understand where AI appears in the system, how it interacts with other components, and whether it operates as a core capability or as an auxiliary feature.

Equally important is the method of implementation. It matters whether the products use self‑hosted machine learning models that the company trains, deploys, and maintains internally, or depend on third-party large language models provided through APIs by vendors such as OpenAI, Anthropic, Google, or Mistral. Each pathway creates a different set of technical constraints, contractual obligations, cost structures, scalability considerations, and risk exposures.

Ultimately, the AI footprint determines both the depth and the direction of the diligence that follows. This foundational understanding informs how to evaluate the risk pillars in a meaningful way.

Legal risk: Navigating compliance, data rights, and liability

AI introduces significant legal complexities in addition to those that accompany the traditional software landscape. Because AI systems routinely process sensitive information and generate content in unpredictable ways, data protection, intellectual property rights, and emerging regulatory frameworks are a challenge.

Data privacy is often the most immediate concern. If personal, confidential, or regulated data is included in prompts, logs, or training datasets, the target company may inadvertently run afoul of GDPR, HIPAA, or FINRA requirements, or the EU AI Act. This risk is especially pronounced when companies send data to external LLM providers without proper anonymization or without understanding the provider’s retention and training policies.

Intellectual property concerns are equally important. AI‑generated outputs may incorporate elements from copyrighted training data, raising questions about ownership, licensing, and potential infringement. Self‑hosted models, too, must be backed by clear documentation of dataset licensing, training‑data provenance, and model ownership. Companies that use pretrained models sourced from public repositories without verifying their licenses or usage restrictions may face substantial exposure.

Liability is another area where AI changes the landscape. AI-enabled systems can produce misleading, harmful, or defamatory content. They can make automated decisions that impact customers’ financial or personal well‑being, and they can hallucinate authoritative-sounding but incorrect information. Without a solid process for reviewing outputs, mitigating harmful behaviors, or responding to incidents, companies risk both legal claims and reputational damage.

Acquisition targets relying on AI should understand all this. A company with weak documentation, unclear dataflow visibility, missing model source information, or no incident response history is likely also lacking in broader governance practices—an important red flag for any acquirer.

Quality risk: Evaluating reliability, accuracy, scalability, and cost

Quality assurance looks fundamentally different in AI-enabled systems than in traditional software. Deterministic software behaves consistently when given the same input, but AI systems behave probabilistically, producing outputs shaped by modeling assumptions, training data, and model updates. As a result, classical QA processes are insufficient on their own.

Evaluating quality in AI systems begins with understanding how the target company ensures output accuracy. Companies using LLMs should maintain prompt libraries, evaluation frameworks, and grading methodologies for assessing responses. Teams should not rely on anecdotal testing or developer intuition. For self‑hosted ML systems, model cards, performance reports, and clear documentation of training datasets demonstrate maturity and reliability.

Reliability and latency are also critical. LLM-as-a-service implementations are vulnerable to rate limiting, quotas, and provider downtime—factors that can directly impact user experience, especially at scale. Self-hosted ML models, meanwhile, depend on internal infrastructure, monitoring, and incident response. Without evidence of load testing, monitoring systems, and scaling plans, it is difficult to trust operational readiness.

Scalability and cost are tightly related. Token-based LLM pricing can escalate rapidly as usage grows, while ML models running on GPU infrastructure can incur substantial compute costs. A strong diligence process examines whether the target company has realistic cost projections, optimization strategies, and architecture choices that support long-term economic viability.

When a company lacks systematic testing, does not monitor reliability, or cannot explain the cost dynamics of its AI workloads, it signals operational immaturity that could undermine both performance and profitability post-acquisition.

Security risk: Protecting data, models and supply chains

AI introduces an entirely new class of security threats, many of which cannot be mitigated by traditional cybersecurity practices alone. Because AI models consume and generate data in unconventional ways, attackers can exploit behaviors unique to AI systems.

One of the most common risks is data leakage. If prompts are not properly sanitized, users may inadvertently send confidential or sensitive information directly into an LLM provider’s infrastructure. Without strict anonymization and encrypted logging, companies can expose themselves to compliance violations and data breaches.

A security concern with LLMs is prompt injections. Because LLMs cannot inherently distinguish between system instructions and user input, malicious actors can craft prompts that override guardrails, gain access to internal data, and trigger unintended actions. This vulnerability requires explicit defensive design, which many early stage companies lack.

For self‑hosted ML systems, new risks emerge around model security. Unencrypted model artifacts can be stolen, reverse‑engineered, or tampered with. Training data can be poisoned, altering model behavior in subtle but dangerous ways. Pretrained models downloaded from public sources can contain hidden backdoors or malicious code, making supply chain integrity a central concern.

A strong security posture includes documented access controls, model verification, signed datasets, penetration‑testing results, secure credential management, and clear provenance for all model components. A weak security posture, by contrast, often includes plaintext model files, missing audit logs, unverified datasets, exposed API keys, and no structured response to adversarial threats.