Generative AI Adoption for Enterprise Architects: A Practical Readiness Checklist

Generative AI adoption decisions are made at the application level, not the organisation level. An enterprise can have a board-approved AI strategy, a funded programme, and a capable team — and still deploy generative AI against applications that cannot support it in production. The decision that determines whether a generative AI deployment succeeds is the one made before any code is written: is this specific application structurally ready to support a generative AI system operating inside it?

This checklist is a practical instrument for enterprise architects making that decision. It covers the five structural dimensions that predict production success, with specific questions for each dimension, the red-flag patterns that indicate a blocking gap, and the remediation investments that address each gap most efficiently. It can be completed in thirty to forty-five minutes per application using information the application team already has.

Dimension 1 — API Surface and Architecture

This is the first and most immediately blocking dimension. A generative AI system interacts with enterprise applications through programmatic calls. If the application has no machine-callable interface, the generative AI system cannot reach it — and no amount of readiness in the other dimensions compensates for this gap.

• Does the application expose a versioned REST, GraphQL, or gRPC API that external systems call in production today? (Not: is an API available in principle. Does any other production system actually call it?)
• Are API responses synchronous and low-latency (under two seconds for standard operations)? Generative AI reasoning loops require timely responses — APIs that return job IDs for asynchronous polling break the reasoning sequence.
• Is business logic separated from the presentation layer? Can the rules governing the application's decisions be invoked independently of the UI?
• Is the API versioned, with breaking changes communicated in advance? Generative AI integrations that break silently on every API update are not viable in production.
• Does the application require a browser session or CSRF token to be called? If yes, it cannot be called from an AI runtime without an RPA shim.

Red flag: the only way to trigger a business process in this application is through a browser. This is a hard blocker — not a risk to mitigate, but a prerequisite to remediate before generative AI deployment is attempted.

Remediation priority: build a thin API layer that exposes the application's core business operations as synchronous, authenticated endpoints. This does not require a full service-oriented architecture rewrite — a facade layer over the existing system is sufficient for initial generative AI integration and typically takes four to eight weeks for a capable team.

Dimension 2 — Data Ownership and Runtime Accessibility

Generative AI systems reason over data at the moment of decision. They need data that is current, authoritative, and accessible without manual mediation. Applications that are downstream consumers of shared data, or that can only expose their data through a UI, fail this dimension regardless of how good the data quality is in isolation.

• Does this application own its primary data, with a clearly defined schema and a single authoritative source of truth? Or is it a downstream consumer of data owned by another system?
• Can the application's data be read programmatically by an external system at runtime — not through a UI, not through a batch export, but through an API or direct database access with appropriate authorisation?
• If a generative AI system writes a decision back to this application's data store, will that write be reflected immediately in subsequent reads? Or is there a replication lag, caching layer, or eventual-consistency model that could cause the AI to act on its own stale output?
• Are the entities in this application's data model documented — field definitions, ownership, update cadence? A generative AI system cannot reason correctly over a schema it has no documentation for.
• Does the application have data quality controls — validation on write, referential integrity, constraint enforcement — that prevent corrupted data from entering the store the AI reads from?

Red flag: the application draws its data from a downstream copy of a central data warehouse, updated on a nightly batch. Write-back goes to the warehouse, not the application — meaning there is a twenty-four-hour lag between the AI writing a decision and that decision being visible in the AI's next read. This pattern creates systematic data integrity failures within days of production deployment.

Remediation priority: establish authoritative data ownership for the entities the generative AI use case depends on. This may involve moving the relevant data out of a shared warehouse into the application's own store, establishing clear write-authority boundaries, or implementing a cache-invalidation mechanism. This is typically the highest-effort remediation in the five dimensions.

Dimension 3 — Integration Pattern Maturity

Generative AI systems do not operate in isolation — they coordinate across multiple enterprise applications in a single reasoning sequence. The stability and maturity of each application's integration patterns determines whether the AI can rely on them under variable call patterns and across application updates.

• How many external production systems call this application's API today? An API called by zero other systems has no proven reliability under real load.
• Has the API contract been stable over the past twelve months, or has it changed in breaking ways without advance notice?
• Does the application publish an OpenAPI specification or equivalent machine-readable contract that a generative AI system could use to understand the available operations and their parameters?
• Does the application emit structured events — webhooks, message queue events, or change-data-capture streams — that a generative AI system could subscribe to rather than polling?
• Are there authentication mechanisms — API keys, OAuth client credentials, service accounts — that a non-human caller can use to authenticate without a user session?

Red flag: the application's only integrations are point-to-point database connections established years ago by specific teams, with no published API contract and no authentication mechanism designed for machine callers. Every new integration requires a bespoke arrangement with the application team. This pattern does not scale to generative AI deployment.

Remediation priority: publish an OpenAPI specification for the existing API surface and implement a service account authentication model. These are low-effort investments — typically one to two weeks — that immediately improve the application's viability as a generative AI integration target.

Dimension 4 — Team Deployment Capability

Generative AI behaviour in production requires iteration. The first deployment will not be the final deployment — outputs will need tuning, thresholds will need adjustment, edge cases will surface that staging did not predict. The team maintaining the application must be able to respond to production feedback on a timeline measured in days, not quarters.

• How many times did this team deploy a change to production in the past four weeks? Teams that deploy fewer than four times per month in this window will struggle to keep pace with the iteration cycle that production generative AI requires.
• Does the team have automated integration tests that can validate a deployment within thirty minutes of merge? Manual regression testing gates are incompatible with rapid iteration.
• Is the application instrumented with observability tooling — distributed tracing, structured logging, error rate dashboards — that makes generative AI behaviour visible in production?
• Does the team have the ability to roll back a production deployment within one hour if generative AI output becomes unacceptable?
• Has anyone on the team worked with a generative AI or automation integration in a production context previously?

Red flag: the team operates a quarterly release cycle managed by a central release management function, with a change advisory board approval required for every production deployment. This is not a criticism of the team — it is a structural constraint that makes rapid generative AI iteration impossible until the deployment process is reformed.

Remediation priority: establish a CD pipeline that allows the team to deploy independently to production, with automated tests as the quality gate rather than a manual approval process. This is a DevOps transformation investment — it takes longer than the other remediations but benefits every application the team maintains, not just the one targeted for generative AI.

Dimension 5 — Process Documentation and Escalation Paths

Generative AI systems will encounter cases they cannot handle. This is not a failure of the model — it is the expected behaviour of any system operating at the boundary of its training distribution. What matters is not whether the AI encounters uncertainty, but whether the application has a defined path for what happens next.

• Are the business rules that govern this application's decisions documented in a form that an engineer who did not build the system can read and understand? Or do they exist only in the institutional memory of specific senior employees?
• Does the application have a defined exception workflow — an approval queue, a human review step, a case management system — that handles transactions the automated process cannot complete?
• Are compliance or regulatory constraints that govern this application's decisions explicitly documented? Generative AI systems that encounter undocumented regulatory constraints in production create compliance exposure.
• Is there a defined threshold — a confidence level, a transaction value, a customer tier — at which the AI should escalate to a human rather than acting autonomously?
• Does the team have a documented incident response process for AI-generated output that causes an unacceptable outcome?

Red flag: when an exception occurs in this application's business process, the current resolution method is an email to a distribution list that someone checks when they remember. There is no SLA, no tracking, no defined ownership. A generative AI system that escalates into this process will create untracked exceptions at a rate the email-based process cannot absorb.

Remediation priority: model the exception workflow explicitly — a queue, a ticketing system, an approval step — before deploying generative AI. This is typically the fastest remediation: a well-defined exception process can be implemented in days and produces organisational benefits independent of the AI deployment.

Scoring and interpreting the checklist results

After completing the checklist for each application, assign a RAG status to each dimension: Green if the dimension has no significant gaps, Amber if there are gaps that are remediable within three months, Red if there are fundamental gaps that require a longer investment. The dimension RAG statuses translate directly to a readiness tier:

• All five dimensions Green — Ready tier. Generative AI deployment is viable with standard risk management. Proceed.
• One or two dimensions Amber, none Red — Emerging tier. Targeted remediation in the Amber dimensions over three to six months unlocks full generative AI capability. Deploy in narrow scope while remediating.
• Any dimension Red — Not Ready for the specific use cases that depend on the failing dimension. Remediate the Red dimensions before expanding the generative AI deployment scope.
• Architecture dimension Red — Hard blocker regardless of other dimension ratings. No generative AI deployment pattern is viable without a machine-callable interface.

For a scored, weighted assessment that goes beyond the checklist RAG status — producing a composite Migration Readiness Score across all five dimensions with AI-generated dimension analysis and remediation priorities — NextAI Foundry (nextaifoundry.com) provides a 25-question structured intake per application. The first application is assessed at no cost.