The AI Readiness Checklist

Thirty-five questions for CTOs and engineering managers assessing an AI-agent initiative before committing to delivery. They cover the use case, data, architecture, team, governance, security, cost, and operating model. Free, no sign-up, and printable.

Mark each statement yes, no, or unknown. Use the pattern to structure a discussion; this is a heuristic guide, not a validated maturity model, certification, or automatic go/no-go decision.

Discuss your results – 30 min Agentic AI Engineering

1. Use case & business value

A technically capable model cannot rescue a use case without an owner, measurable value, and a defined response when the output is wrong.

  • We can name the specific business process the AI should improve – and the person who owns that process has asked for it
  • We know what the process costs today (time, money, or errors), so we can measure whether AI actually improved it
  • The task involves judgement over unstructured input – not something a rule engine or a batch job would solve cheaper
  • We have defined what “good enough” means: an acceptable error rate, and what happens when the AI is wrong
  • Someone with budget authority sponsors this – it is not a side project justified by “the board wants AI”

2. Data & API readiness

The value and risk of an agent depend on the data it can read and the actions it is authorised to take.

  • The knowledge the AI needs exists in machine-readable form – not only in people’s heads, PDFs of scans, or a wiki nobody maintains
  • We know where that data lives, who owns it, and whether we are allowed to use it for this purpose
  • The systems the agent should act on expose APIs – the actions are not locked behind UIs, batch files, or manual steps
  • Those APIs have authentication and authorisation that can distinguish an agent from a human user
  • We could retrieve relevant, current documents for a given question – the prerequisite for any RAG approach – without a separate data-foundation programme first

3. Architecture readiness

Agents act on your systems. Existing boundaries, interfaces, and controls shape what they can do and how failures can be contained.

  • Our estate has module or service boundaries an agent’s permissions could follow – it is not one tangle where every access is an all-or-nothing decision
  • Business operations are exposed as well-defined, idempotent-where-possible interfaces the agent can call – with validation on the receiving side
  • We can run a realistic non-production environment where an agent can be tested against real workflows without touching production data
  • We use a supported combination of JDK, Spring Boot, and Spring AI versions, with a defined upgrade path for the lifetime of the agent
  • We have an integration seam for AI components – adding one does not mean forking the architecture or building a separate stack beside it

4. Team skills & AI-assisted development

The team responsible after launch needs the skills and capacity to evaluate, monitor, and improve the agent.

  • Knowledge is shared across the team: more than one engineer has built something with LLM APIs, embeddings, or an agent framework beyond a tutorial
  • The team understands that LLM output is probabilistic and designs for verification, not for trust
  • Developers already use AI-assisted development tools with review discipline – AI output goes through the same quality gates as human code
  • We have testing discipline to build on and can maintain representative datasets, repeatable evaluations, and acceptance criteria for agent behaviour
  • There is a plan for who operates, monitors, and improves the agent after go-live – it is not finished at the demo

5. Governance, risk & compliance

The EU AI Act is in force, but duties and application dates depend on the organisation’s role, the use case, and its risk classification. It can also apply to a Swiss organisation where a system is placed on the EU market or its output is used in the EU. Use the European Commission guidance and qualified legal or data-protection advice; this checklist is not a legal assessment.

  • Where the EU AI Act applies, we have identified our role, the relevant risk classification, the applicable dates, and the obligations that follow
  • Someone is accountable for AI decisions in production – a name, not a committee to be formed later
  • We know which data may legally be sent to which model provider – and whether we need EU hosting, a Swiss provider, or local models
  • Human-in-the-loop checkpoints are defined: which agent actions require approval, and who gives it
  • We can reconstruct the inputs, model outputs, tool calls, approvals, and system responses that led to an outcome, while recognising that an LLM’s internal reasoning is not fully explainable

6. Security

An agent is a new attack surface: it reads untrusted input and holds credentials to act.

  • We treat prompt injection as an attack class: anything the agent reads – documents, emails, web content – is untrusted input
  • The agent gets its own least-privilege identity and credentials – it does not act with a human’s or a service account’s broad permissions
  • Destructive or irreversible actions are technically gated – rate limits, approval steps, allow-lists – not just discouraged in the prompt
  • Secrets, personal data, and confidential context are filtered before they are sent to a model provider
  • Our existing security practices (dependency scanning, access reviews, incident response) extend to the AI components – they are not exempt because they are new

7. Cost & operations

Pilot economics rarely predict production economics. Volume, retries, model routing, latency targets, and fallback behaviour need explicit assumptions.

  • We can estimate cost per task – tokens, calls, retries – and what that means at production volume, not demo volume
  • Model routing reflects an explicit cost-and-quality trade-off: lower-cost models for simpler steps and more capable models where the evidence justifies them
  • We have observability the operations team can use – latency, error rates, token spend, and quality metrics per agent step
  • There is a defined fallback when the model provider is down, slow, or degraded – the business process does not simply stop
  • Someone reviews AI spend at an agreed cadence against the value delivered – with the authority to turn things off

Interpreting the pattern

Do not treat the total as a verdict. Review the evidence behind each answer, pay attention to unknowns, and start with the sections that could block safe operation or measurable business value.

  • Few gaps: validate before building

    Confirm the strongest use case with representative data, explicit acceptance criteria, and the people who will operate it. A fixed-scope discovery can test those assumptions before a larger commitment.

  • Several gaps: address the weakest areas

    Prioritise the gaps that affect value, permissions, data quality, evaluation, security, or ownership. Some can be resolved during discovery; others belong on the engineering roadmap before implementation.

  • Many gaps or unknowns: establish foundations

    Clarify the use case and ownership before selecting technology. Work on boundaries, APIs, tests, observability, and governance can still improve the wider system even if you decide not to build an agent. Start with application modernisation or an architecture review.

Gaps in team skills may point to our Spring AI & Embabel training or developer coaching. Gaps in data, architecture, or security need owners and an engineering plan before implementation.

Want a second opinion on your answers?

Book 30 minutes with Patrick and review the evidence behind your weakest sections. We will help you identify the next practical step, including when more foundation work should come before an agent build.

Book a 30-min call Agentic AI Engineering