--- title: AI Readiness Checklist: 20 Questions Before You Build (2026) description: AI readiness checklist for teams planning their first AI project: 20 questions across strategy, data, infrastructure, governance and operations, with two hard blockers that override any score. url: /blog/ai-readiness-checklist.html --- [Blog](/blog/index.html) Web3 & blockchain # AI Readiness Checklist: 20 Questions Before You Build (2026) Nov 4, 2026 · 8 min read Avinya LabsEngineering team Link: https://www.linkedin.com/sharing/share-offsite/?url=https://avinyalabs.co/ai-readiness-checklist/ Link: https://x.com/intent/post?url=https://avinyalabs.co/ai-readiness-checklist/ Short answer AI readiness comes down to two hard blockers and five areas. The blockers are: no legal access to the data the system needs, and no named business owner accountable for the outcome. If either is missing, no score matters. The five areas to assess are strategy and use-case clarity, data quality and governance, infrastructure and integration, talent and change management, and governance including regulatory mapping. Most teams are partial across all five areas; the goal is to identify the one gap most likely to stall the first project. AI Readiness Checklist ## Two questions that override everything else Most AI readiness checklists are scored assessments. You answer 20 or 40 questions, add up the points, and land in a band: low, moderate, or high readiness. The problem with this approach is that some gaps are not gradable. They are blockers. No score compensates for them. Before working through the 20 questions below, check these two first. If either answer is no, the project should stop until it is resolved. **Blocker 1: Does your team have legal access to the data the system needs to work?** Not moral access, not intended access. Legal access, documented. If the system needs customer emails, do you have consent terms that cover using them for AI? If it needs documents from a third-party provider, does your contract allow it? If the answer is unclear, it is no. **Blocker 2: Is there a named business owner who is accountable for the outcome?** Not an IT sponsor, not a committee. One person whose job includes whether this project succeeds or fails. AI projects without a named owner drift into pilot purgatory. The score on everything else does not matter if no one is accountable. ## Area 1: Strategy and use case (5 questions) **Q1. Is there a specific business problem this system is solving, written down in one sentence?** "We want to use AI" is not a problem. "Our contract review team spends 40% of their time extracting key dates from PDFs that could be extracted automatically" is a problem. If you cannot state the problem in one sentence, the project is not ready. **Q2. Is there a measurable baseline to compare against?** If the system is meant to reduce review time by 40%, do you know what the current review time is? If it is meant to reduce error rates, do you know the current error rate? A system without a measurable baseline cannot be evaluated after launch. **Q3. Have you confirmed that the problem is best solved by AI rather than a simpler tool?** Many problems that look like AI problems are actually search problems, workflow problems, or missing-API problems. A good answer here is that you considered alternatives and AI won on a specific criterion, not that AI was assumed from the start. **Q4. Is there a defined scope for the first version?** The first build should cover one workflow with one user type. If the scope includes multiple workflows, multiple user roles, and multiple integration points, it is not a first version. It is a full platform. Scope to something you can ship and learn from in 8 to 12 weeks. **Q5. Is there an executive sponsor with budget authority?** Not influence. Budget authority. Someone who can approve spend on the build, on the ongoing inference cost, and on the post-launch iteration cycle. Projects that require a committee decision for every invoice do not ship. ## Area 2: Data quality and governance (5 questions) **Q6. Is the data the system needs accessible in a machine-readable format?** PDFs that have never been OCR'd, data locked in a legacy system with no API, and spreadsheets maintained manually by one person are all data access problems. A yes here means the data is queryable, not just theoretically available. **Q7. Is the data labelled or annotatable for the specific task?** For a classification system, do you have examples of correctly classified inputs? For a document extraction system, do you have examples of correctly extracted fields? If not, budget time and cost for labelling before the build starts, not after. **Q8. Is there a documented data governance policy that covers AI use?** This includes who can access what, how long data is retained, and what happens when a user asks for their data to be deleted. For generative AI systems, deletion is not just the source document: it may include embeddings, cached outputs, and fine-tuning examples. **Q9. Has the data been reviewed for quality issues that would affect the system?** Missing fields, inconsistent formats, duplicate records, and data from a time period that does not reflect current conditions are all issues that surface after the build starts rather than before. A data profiling exercise before the architecture is designed saves time. **Q10. Is there a process for keeping the data current after launch?** A system trained on data from two years ago that is never updated drifts from reality. Know how the data pipeline works in production, not just at build time. ## Area 3: Infrastructure and integration (4 questions) **Q11. Can the system connect to the data sources and downstream tools it needs?** This means API access, authentication, and permissions confirmed in writing, not assumed. The most common cause of a delayed build is an integration that was assumed to be straightforward but required security review, vendor approval, or contract amendment. **Q12. Is there a staging environment where the system can be tested with real data?** A system tested only on synthetic data behaves differently in production. A staging environment with a representative sample of real data is a minimum requirement for a system that processes operational data. **Q13. Is the infrastructure sufficient to serve the system under expected load?** For a generative AI system, expected load in tokens per minute, not just requests per second. Know the latency your users will tolerate, and confirm that the model tier you are using can meet it at your expected query volume. **Q14. Is there a rollback plan if the system behaves unexpectedly after launch?** This means a defined process for disabling the AI component and reverting to the manual process, not a general incident response plan. The rollback should be operable by the business team, not only by an engineer. Planning Web3 development? Talk to the team that has shipped it for real businesses. [Book a call](https://calendly.com/abbylester/30-mins-meeting) [Web3 development](/service-pages/service-web3-development.html) ## Area 4: Talent and change management (3 questions) **Q15. Is there an engineer on the project who has built and shipped an AI system before?** Experience with AI tools is not the same as experience building production AI. The specific skills that matter are model evaluation, prompt engineering for reliability, and operations including monitoring and rollback. If this skill is not in-house, budget for a studio or specialist contractor. **Q16. Do the users who will interact with the system know it is coming and have input into how it works?** AI systems imposed on users fail faster than ones co-designed with them. User resistance is the most common reason a technically sound pilot does not reach production. The users who will interact with the output daily are also the best source of edge cases. **Q17. Is there a plan for what happens when the system is wrong?** Every AI system makes mistakes. The question is whether there is a defined process for a user to flag an error, what happens to that flag, and who is responsible for reviewing and correcting it. A system with no error-correction process erodes trust quickly. ## Area 5: Governance and regulatory mapping (3 questions) **Q18. Have you identified the regulatory requirements that apply to this system in your market?** For EU deployments, the EU AI Act classifies systems by risk tier. For financial services, healthcare, and legal applications, additional sector-specific rules apply. This is not a legal review: it is a checklist item to confirm that someone has identified which rules apply before the architecture is designed, not after. **Q19. Are there defined performance thresholds below which the system should not go live?** This is different from a success metric. A success metric says what good looks like. A go-live threshold says what unacceptable looks like. For a system that makes decisions affecting people, the go-live threshold should be agreed and documented before the build starts, not benchmarked against whatever the system achieves. **Q20. Is there a monitoring plan for the system after launch, including drift detection?** Model performance degrades over time as inputs change. A monitoring plan includes what metrics are tracked, at what frequency, who reviews them, and what the escalation process is when a metric falls below threshold. A system without a monitoring plan is not production-ready, it is a pilot that has not yet been evaluated. ## How to use this checklist Score one point for each yes. A score of 18 to 20 means the project is well-positioned to start. A score of 14 to 17 means there are gaps to close in parallel with early scoping. A score below 14 means there is at least one structural gap that is likely to stall the project. The score is a guide, not a gate. The two blockers above override any score. And a low score in one area, such as data quality, is more serious than a low score distributed evenly across all five areas, because data quality problems compound once the build has started. Our [AI readiness assessment](/service-pages/service-consulting-ai-readiness.html) works through these questions with your team in a structured workshop, identifies the gaps most likely to stall your first project, and produces a prioritised action plan. See also our [AI readiness assessment tool](/tools/ai-readiness-assessment-tool.html) for a quick self-scored version. ## Related work - [**~70% faster document prep** Workflow automation platform](/case-studies/ai-workflow-automation.html) - [**Document intelligence** AI document processing system](/case-studies/enterprise-document-intelligence.html) ## From our work - [**~40% less manual effort**AI agent platform](/case-studies/enterprise-ai-agent-platform.html) - [**>80% less manual review**AI document intelligence](/case-studies/enterprise-document-intelligence.html) Related: [AI readiness assessment](/service-pages/service-consulting-ai-readiness.html) ## Frequently asked questions ### What is an AI readiness assessment? An AI readiness assessment is a structured review of a business's current state across the areas that determine whether an AI project will succeed: strategy clarity, data quality, infrastructure, talent, and governance. The output is a gap map and a prioritised list of actions to close the gaps most likely to stall the first project. It is usually done before a build starts, not during. ### How long does an AI readiness assessment take? A focused assessment covering the five areas above typically takes one to two weeks: a half-day workshop with the project team, a week of review and profiling, and a written report with prioritised recommendations. A broader organisational readiness assessment covering multiple departments takes three to four weeks. ### What is the most common gap in AI readiness assessments? Data access. Teams typically discover that the data the system needs is not in a machine-readable format, is locked in a legacy system, or requires legal review before it can be used. Data access problems that surface after the build starts are expensive. Data access problems identified before the build starts are addressable in days or weeks. ### What is the difference between AI readiness and AI maturity? AI readiness is a pre-project assessment: is this team ready to start this specific project? AI maturity is an organisational assessment: how advanced is this organisation's overall AI capability? Readiness is binary and project-specific. Maturity is continuous and organisation-wide. Most businesses need a readiness assessment before a first project; maturity assessments are more useful after several projects have been completed. ### Should we do an AI readiness assessment before every project? For a first project, yes. For subsequent projects at the same organisation, a lighter check covering the two blockers and the data-access question is usually sufficient, because the structural capabilities are already in place. A full reassessment makes sense when the organisation moves into a new domain, a new regulatory environment, or a significantly different technology tier, such as from a rules-based system to agentic AI. ## Keep reading. Nov 4, 2026 Web3 & blockchain ### Technical Due Diligence Checklist for AI Startups (2026) Technical due diligence on an AI startup is different from DD on a standard SaaS company. The questions are the same in structure: does the technology work, is it... Read more Link: /blog/technical-due-diligence-checklist-ai-startups.html Nov 3, 2026 Web3 & blockchain ### MVP Development Cost for Funded Startups: What You Get at Each Budget (2026) Most MVP cost guides are written for someone who does not know what they are building yet. This one is for a funded startup: you have capital, you have a product idea... Read more Link: /blog/mvp-development-cost-funded-startup.html Nov 3, 2026 Web3 & blockchain ### AI in Banking: Use Cases That Work in Production (2026) Banks and fintechs have been running AI pilots for years. Most of the production deployments that hold up to scrutiny cluster around four areas: fraud and transaction... Read more Link: /blog/ai-in-banking.html ## Tell us what's slowing the team down. Or [book a call](https://calendly.com/abbylester/30-mins-meeting) · [contact@avinyalabs.co](mailto:contact@avinyalabs.co)