“Circuit” by Yuri Samoilov is licensed under CC BY 2.0.
What We Actually Assess in an AI Readiness Review (From Dozens of Portfolio Companies).
There is a version of AI readiness assessment that involves sending a maturity questionnaire to the CTO, collecting the responses, plotting the results on a spider chart, and producing a report that confirms the company is either "early stage" or "developing." That version is not particularly useful.
After conducting AI readiness assessments across dozens of portfolio companies, for PE firms, VC investors, and operating partners managing technology-intensive portfolios, we have a clear view of what a genuinely useful assessment looks like and where the standard approach consistently falls short.
This is not a framework document; for the strategic case and the seven dimensions, see our AI readiness assessment guide. What follows is a window into how we think about these assessments and what patterns we see. The full methodology, the diagnostic sequences, the scoring calibration from dozens of engagements, the experience of CTOs who have built the AI systems they now assess, is what makes the difference between a useful assessment and an expensive questionnaire.
What Most AI Assessments Get Wrong
Before describing what we assess, the common failure modes are worth stating directly. These are patterns we see regularly in assessments commissioned from firms that treat AI readiness as a survey exercise rather than an expert evaluation.
Taking AI claims at face value. A company that says "we use AI across the business" might have a genuine AI capability embedded in its core product, or it might have installed a chatbot plugin and added "AI-powered" to its marketing. These are different things. Most assessment frameworks do not have the technical depth to distinguish them because the assessors have never built the systems they are evaluating.
Ignoring the perception gap. In a randomised controlled trial by METR, experienced developers using AI tools believed they were 20 per cent faster but were actually 19 per cent slower. Self-reported productivity data is unreliable. An assessment that asks "how much faster are your developers with AI tools?" and records the answer without verification is not measuring productivity - it is measuring confidence.
Applying a uniform standard. A seed-stage company with fifteen engineers and no AI tooling is in a different position from a Series C business with two hundred engineers and the same gap. The first is unremarkable. The second is a finding. Assessments that apply the same absolute standard to both are not rigorous; they are using a checklist.
Separating readiness from vulnerability. Most AI assessments look inward: does the company have AI capability? The more important question for investors is whether the company needs AI capability, and how urgently. A company in a market where AI-native competitors are emerging has a different readiness requirement from one in a stable market. The assessment needs to evaluate both.
“A company that says 'we use AI across the business' might have genuine AI capability embedded in its core product, or it might have installed a chatbot plugin and added 'AI-powered' to its marketing. Most assessment frameworks cannot distinguish the two.”
How We Actually Work
An AI readiness assessment runs over two to four weeks per company. The structure follows a deliberate sequence: we move from orientation to investigation to synthesis, and at every stage we are testing claims against evidence rather than collecting self-reported data.
Week one: orientation and hypothesis formation. We review available documentation: architecture diagrams, system inventories, data infrastructure, team structure, existing AI usage, and any previous AI strategy documents. We identify the areas of highest likely gap between claims and reality given the company's sector, stage, and competitive position. We form working hypotheses about where the material findings will be. These hypotheses are usually right. When they are wrong, it is because the company is better than expected, not worse, a pattern that tells us something about how AI capability is distributed across organisations.
Weeks two to three: deep investigation. We conduct structured interviews with the CTO, senior engineers, the product leader, data team, and (where relevant) the security and compliance team. We review the actual systems directly: not through a questionnaire, but by examining code repositories, deployment pipelines, data infrastructure, AI tool configurations, and security posture. We assess the engineering team's AI capability in practice, not just in description: how they use AI tools, whether they have structured practices or individual habits, whether the productivity gains they claim can be evidenced.
We also conduct the competitive vulnerability assessment in parallel. This is research-intensive: mapping AI-native competitors, assessing pricing model exposure, evaluating whether the company's market position is defensible as AI reshapes the sector. This is product strategy work, not technology assessment, and it requires a different lens.
Final week: synthesis and deliverables. We produce a scored assessment across all seven dimensions, a prioritised AI impact plan with quantified financial projections, a 90-day execution plan with named owners and acceptance criteria, and a board-ready summary. Every finding is connected to a commercial implication and a recommended action.
What the Data Shows
Across dozens of portfolio company assessments, certain patterns appear consistently enough to be instructive.
The Most Common Findings
Shadow AI is near-universal and unmanaged. The majority of companies we assess have employees using consumer AI tools, ChatGPT, Claude, Gemini, for work tasks without any data processing agreement, security review, or management visibility. Customer support agents pasting ticket contents into consumer AI tools is the single most common finding. Engineering teams using AI coding assistants that send code to external servers without the CTO's knowledge is the second.
This is a finding we see so consistently that its presence is not, in itself, alarming. What we are assessing is the severity of the exposure and the company's awareness. A company that has catalogued its AI tool usage, put data processing agreements in place, and established an acceptable use policy is in a fundamentally different position from one that does not know the problem exists. Both may be at Level 1 on our AI security framework, but the trajectory is different, and trajectory matters as much as state.
AI strategy documents are vague. The majority of AI strategies we review describe goals in general terms, like "leverage AI to improve operational efficiency," without naming a specific use case, a responsible team, a measurable target, or a delivery date. This is the single most reliable indicator that AI adoption will not progress beyond experimentation. A company that cannot articulate what it is building, for whom, and by when has not done the work required to succeed.
Data foundations are the most expensive gap. When a company's data is not ready for AI (poor quality, inconsistent governance, no lineage, inadequate privacy controls) the remediation timeline is measured in quarters, not weeks. This is different from most technology findings, where the fix is a matter of prioritisation and engineering effort. Data problems are structural: they require changes to processes, tooling, and often organisational behaviour. Companies consistently underestimate both the severity and the cost of addressing data gaps.
Engineering AI capability is concentrated, not distributed. Where engineering teams are using AI tools effectively, the capability is almost always concentrated in one or two individuals who have taught themselves and developed personal workflows. There are no shared practices, no team-level standards, no way for a new team member to adopt the same approach. This creates two problems: the team is capturing a fraction of the available productivity gain, and the capability is a key person risk.
This is where the AI development maturity spectrum is most useful as an assessment tool. A team at Level 1 (reactive prompting, accepting all output) is capturing perhaps 20 per cent of available value. A team at Level 3 (context engineering, shared specifications, repeatable workflows) is capturing 80 per cent. The investment to move from Level 1 to Level 3 is primarily training and practice: weeks, not months. It is consistently one of the highest-leverage recommendations we make.
The Least Common Findings
Genuinely unfixable AI gaps are rare. Fewer than one in ten findings represent gaps that cannot be addressed within twelve months. The majority are a matter of structured adoption: training, process, tooling decisions, and governance. The framing of "AI-ready" or "AI-unready" misses the more useful question: what would it cost and how long would it take to get this company to the level of AI capability that serves the investment thesis?
Catastrophic AI security breaches are uncommon so far. Given the prevalence of unmanaged shadow AI, actual breaches attributable to AI tool usage are rarer than the underlying risk profile would predict. This does not make the risk less real; it makes it more insidious, because the absence of a past incident is frequently used to justify inaction. The risk profile is deteriorating: the volume of data flowing through unmanaged AI tools is increasing every month, and the regulatory environment is tightening.
How We Think About What We Find
The question is never simply "is this company AI-ready or not?" That framing is as unhelpful for AI assessment as "pass or fail" is for technology due diligence.
The useful questions are: is this finding material to the investment thesis? Is it normal for a company at this stage and in this sector, or is it genuinely unusual? How much would it cost to address? How long would it take? Does the team have the capability to fix it, or would remediation require external support?
Our actual assessment methodology is more granular than what follows, but a simplified version of the approach might look like this. We evaluate each dimension through two lenses:
Lens 1 - What did we find? A simplified scale might be: the company has no meaningful AI usage in this area, the company is experimenting but has not reached production, or the company has AI in production with measurable impact. In practice, our assessments are more nuanced, but the principle is the same: findings need to be specific enough to drive commercial decisions.
Lens 2: How mature is this for the stage? A simplified scale might be: Above expectations, On Par, or Below expectations, always calibrated to the company's size, sector, funding stage, and competitive environment. A B2B SaaS company with two hundred engineers and zero AI tooling adoption in 2026 is Below expectations. A fifteen-person seed-stage company in the same position is On Par. A company in a market where AI-native competitors are actively taking share needs to be assessed against a higher standard than one in a stable market.
The combination matters. A finding might be "experimenting only" (not yet in production) but On Par for the stage (the company is early and the market is not yet pressuring AI adoption). That context changes the urgency entirely. Our assessments go considerably deeper than this simplified framing, but the principle of evaluating both what exists and what should exist at this stage runs through everything we do.
“A B2B SaaS company with two hundred engineers and zero AI tooling adoption in 2026 is Below expectations. A fifteen-person seed-stage company in the same position is On Par. The same finding, two different conclusions.”
The Vulnerability Lens
Most AI readiness assessments look only inward. We look outward as well, because a company's AI readiness requirements are shaped by its competitive environment.
The vulnerability assessment evaluates five areas:
Business model disruption. Is the company's core revenue model exposed to AI disruption? Seat-based SaaS pricing is particularly vulnerable: AI enables outcome-based or usage-based alternatives that undercut the economics. A company generating £10 million in ARR from per-seat licensing needs to understand what happens when a competitor offers the same outcome at a fraction of the cost by replacing human workflows with AI agents.
Competitive dynamics. Are AI-native entrants emerging? Are incumbents embedding AI in ways that erode the company's differentiation? The research here is sector-specific and cannot be done generically - it requires understanding the company's specific market position, customer base, and competitive moat.
Customer and market sensitivity. Are customers beginning to expect AI-powered features, lower prices, or greater automation? In some markets this shift is already happening. In others it is not yet material. The answer determines how urgently the company needs to move.
Regulatory exposure. The EU AI Act, GDPR's evolving interpretation of AI processing, sector-specific regulations (particularly in healthcare and financial services): the regulatory environment is tightening. A company that has not assessed its exposure is accumulating risk.
Operational risk. Model drift, hallucination in production, LLM security vulnerabilities, vendor concentration: the risks specific to AI systems in production. A company relying on a single AI vendor for a critical business function has a concentration risk that most boards have not considered.
The vulnerability that matters most - and the one that most assessments overlook entirely - is whether the people in the organisation have the capability to understand, adopt, and lead AI changes. Where those human capabilities are absent, even modest competitive shifts become existential. Technology can be acquired. Capability cannot be bought on a vendor's invoice.
What Separates Useful AI Assessment from Expensive Questionnaires
The difference comes down to three things.
Practitioner depth. The assessor should be able to look at a company's AI implementation and tell you whether it is genuinely differentiated, whether it is a thin integration layer, whether the data foundations can support the roadmap, and whether the team can execute. That requires hands-on experience building and deploying AI systems, not advisory experience, not theoretical knowledge, not a maturity framework. Ask the assessor what production AI systems they have personally built. If the answer involves only theoretical knowledge or managing teams, the assessment will struggle to distinguish genuine capability from marketing.
Commercial connection. Every finding should connect to a commercial implication. "Data quality is poor" is not actionable. "Data quality gaps in customer records will prevent the planned AI-driven upselling initiative from reaching production, delaying an estimated £800,000 annual revenue uplift by six to nine months" is actionable. The assessment needs to speak the language of investment committees, not technology teams.
Actionability. A report that scores dimensions without proposing remediation requires the investor to commission additional work. The assessment should produce a 12-month impact plan and a 90-day execution plan: what to do first, who does it, how much it costs, and how to measure whether it is working. That is not a supplement to the assessment. It is the point of the assessment.
Related Reading
- AI Readiness Assessment: What Investors Should Actually Measure, the strategic case and the seven dimensions
- AI Due Diligence: What You Need to Know - AI assessment within technology due diligence
- What Is Vibe Coding? And Why It's Not Enough, the AI development maturity spectrum used in assessment
- How Mid-Market CEOs Can Deploy AI at Speed, the five-level AI security framework
- The AI Diligence Gap - why PE firms need systematic AI assessment
- What We Actually Assess in Technology Due Diligence, our approach to technology DD, the same rigour applied to AI
- AI Enablement Services: strategy, assessment, training, and implementation
- AI Bootcamp - intensive AI training for engineering teams
Frequently Asked Questions
References
- METR. Measuring the Impact of Early 2025 AI on Experienced Open-Source Developer Productivity. METR (2025).
- Peng, S., Kalliamvakou, E., Cihon, P., Demirer, M.. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. MIT / Microsoft Research (2023).
- European Parliament. EU Artificial Intelligence Act. Official Journal of the European Union (2024).
- McKinsey & Company. The State of AI in 2025. McKinsey Global Survey (2025).
- ICO. Guidance on AI and Data Protection. Information Commissioner's Office (2024).
Need an AI readiness assessment from practitioners?
We assess AI readiness across PE and VC portfolios: not with questionnaires, but by reviewing systems, code, and capability directly. Scored, quantified, and delivered by CTOs who build with AI daily.