Generative AI Readiness

Generative AI readiness begins with an output the business can define and judge. Before asking whether a model can write, summarise or create an image, establish what the output may claim, which sources may support it, who can accept it and what happens when the evidence is incomplete. These prerequisites determine whether a useful experiment can be conducted and what a later pilot could responsibly permit.

The assessment is particularly important when fluent output is easy to produce but correctness is difficult to recognise. A product paragraph can sound convincing while changing a material property. A summary can omit an exception that changes the decision. A generated image can suggest a feature that does not exist. Readiness therefore concerns the evidence and workflow around generation as well as access to a capable model.

Define the permitted output before preparing prompts

Write an output boundary in business terms. Identify the audience, purpose, required facts, optional explanation and prohibited commitments. Distinguish a private exploratory draft from approved material intended for customers or operational use. An experiment that measures whether a model can organise information is different from a pilot that allows its text to influence a buyer or an employee's actions.

For each output component, specify the authority it needs. A product name may come from the catalogue owner. A material composition may come from an approved specification. A performance claim may require a separate approved evidence source. A persuasive sentence cannot supply evidence that the organisation does not possess.

Also define what an incomplete but acceptable result looks like. The system may need to leave a field blank, identify conflicting sources or ask a human to clarify. If evaluators reward only polished completeness, they may penalise the behaviour that preserves the business boundary. A readiness review should expose that incentive before the first demonstration is judged.

The NIST Generative AI Profile identifies risks associated with generative systems and proposes risk-management actions. It is a voluntary companion to the AI RMF, not a product approval. The output contracts and tests below are original examples of how to examine prerequisites for a specific business use.

Workwear product cards: a bounded illustrative use

Imagine a distributor that wants draft bilingual product cards for industrial workwear. The inputs include a catalogue record, a fabric specification, an approved care label and a product photograph. A product specialist approves the final material. The proposed assistant may organise supported information and suggest wording; it may not invent protective performance, certification, stock availability or a guarantee.

The first readiness question is whether those sources refer to the same product variant. A photograph might show a previous pocket arrangement. A fabric sheet might apply to one colour or manufacturing revision. A catalogue entry might describe the range rather than the exact garment. Combining them into a convincing card would not resolve their different scopes.

Define the intended card at a field level: product identifier, variant, composition, approved care information, supported description and open questions. Separate source-backed facts from optional editorial language. The product specialist must be able to see where each material statement came from without reconstructing the input bundle manually.

For example, a current label may specify one care instruction while an older brochure says something different. The correct experiment is not to see which instruction the model prefers. First determine the applicable source and how its precedence will be represented. If the conflict cannot be resolved, the expected output should preserve the uncertainty and withhold an unsupported instruction.

Build a source-to-output contract

Illustrative source contract for a workwear product card

Output element	Required supporting material	Behaviour when support is missing
Product and variant identity	Approved identifier and variant relationship	Stop the card or request clarification rather than merge variants
Fabric composition	Applicable specification with a known revision	Leave the statement unresolved; do not infer composition from the image
Care information	Authoritative label or approved care source for that variant	Flag the gap or conflict for the product specialist
Performance or certification claim	Approved evidence that covers the exact claimed scope	Exclude the claim until its basis is established
Editorial description	Supported facts and agreed language constraints	Use restrained wording that does not add a new factual promise

This contract is not a substitute for professional product review. It makes the information requirements visible so the assessment can establish whether the proposed trial is meaningful. It also helps procurement distinguish a model demonstration from an application that can preserve source identity and present evidence to a reviewer.

Record which source combinations are permitted. More documents do not always improve the answer if the additional material concerns another variant or an obsolete instruction. A controlled retrieval approach may help supply relevant sources, but RAG readiness remains a separate investigation into corpus meaning, access and retrieval behaviour. Retrieval alone does not establish that the final statement is supported.

Design evaluation cases before judging the demonstration

Create cases that represent the claims the intended pilot must handle. Include ordinary complete inputs, missing required support and conflicting source material. Include Arabic and English if both are in scope. For image-assisted work, distinguish information that can be observed visually from information that requires a specification or another authoritative source.

An illustrative design might combine five product variants, three source conditions and two output languages. That produces thirty case configurations. The three conditions could be complete applicable sources, a conflict between current and older care material, and absent support for a requested performance claim. These are proposed test fixtures, not a measured sample of the distributor's live catalogue.

Specify the expected behaviour for each configuration. The complete-source case should preserve the supported facts. The conflict case should follow the established precedence or flag unresolved ambiguity. The unsupported-claim case should withhold the claim. A single “quality” score would hide these different requirements, so record their outcomes separately.

Define the unit of evaluation. Thirty configurations do not represent thirty independent products, because languages and source conditions reuse product facts. Repeated generations can reveal variation, but their dependence and selection must be recognised. Do not convert a small designed test into a claim that the application is safe for every catalogue item.

Keep a part of the evaluation material outside prompt development. If every difficult case is repeatedly used to tune instructions, the resulting improvement may describe familiarity with those cases rather than broader behaviour. The assessment should establish who maintains evaluation examples and what later evidence is required before expanding scope.

Separate factual support, presentation and business usefulness

A draft can be factually supported but difficult for its intended audience to use. Another can be clear and persuasive while adding an unsupported benefit. Treat those as different evaluation dimensions. Establish a minimum factual and authority boundary first, then compare presentation and usefulness among outputs that respect it.

For the workwear example, reviewers might inspect whether every material property is supported, whether conditions and exceptions are preserved, whether variant identity remains stable and whether Arabic communicates the same claim as English. They can separately judge readability, organisation and appropriate commercial tone. Good tone should not compensate for an invented certification.

Business usefulness needs a baseline. Compare the proposed workflow with the current preparation process using equivalent input conditions and acceptance criteria. Include the effort needed to assemble sources, inspect claims and correct drafts. A faster generation step does not establish a faster accepted product-card process if reviewers must perform additional reconstruction.

Do not assume that any disagreement is a model defect. Reviewers may lack a shared interpretation of the source or the permitted claim. Resolve that disagreement and preserve its effect on the evaluation. Otherwise, a model could be criticised for an ambiguity that the business has not yet decided how to handle.

Make bilingual acceptance about meaning

Arabic readiness requires more than displaying Arabic script. Preserve negation, qualifications, units, variant names and the distinction between a supported property and an attractive promise. A term approved in English may need a carefully reviewed Arabic equivalent rather than a literal translation or a stronger marketing phrase.

In the illustrative card, a statement limited to a particular condition must retain that condition in both languages. An Arabic sentence that sounds smoother but broadens the claim should fail the relevant criterion. Establish a bilingual glossary for consequential terms and record who is authorised to resolve a disputed meaning.

Evaluate the languages independently as well as together. A strong English result does not establish Arabic performance, and translation of a flawed English draft can reproduce the same error fluently. Include source bundles where the authoritative information is Arabic, English or legitimately bilingual. Bilingual evidence and source conflicts addresses how to determine which source meaning should prevail.

Reviewers need enough source-language competence for the task. A person who can read the generated Arabic may still be unable to judge a technical qualification in the original specification. Use the AI skills readiness guide to define the actual verification tasks and demonstrate that the assigned people can perform them.

Check multimodal and formatting boundaries explicitly

If photographs are part of the proposed input, record what they may contribute. A photograph can help identify a visible feature under suitable conditions, but it cannot establish an unseen material composition or a documented certification. Image cropping, resolution and variant labelling can also change what the system receives. Inspect those inputs instead of treating “image support” as a complete capability.

If the output includes a generated illustration, separate it from the evidence photograph. Decide whether an illustration is allowed, how it will be labelled and which product features must not be invented. A synthetic visual should not become the authoritative record used to validate its own caption. The required review depends on the actual use and its consequences.

Formatting is another distinct condition. The application may need to preserve a table, a unit, a product code or a warning. A readable answer in a chat window does not prove that an exported card or connected application retains those elements. Include the real intended output format in a later acceptance exercise.

These issues do not require every readiness assessment to build a complete application. They require the assessment to identify which behaviours can be examined now and which need a bounded experiment. Record that distinction in the proposed next step so a source review is not mistaken for end-to-end validation.

Verify the environment and information-handling arrangement

Establish the approved account or environment, the people allowed to submit material and the information categories permitted in the trial. Inspect the relevant service terms and configuration with the appropriate owners. Do not infer that a personal account, an enterprise account and a supplier-operated environment have identical arrangements.

Map the material that the workflow actually handles: source files, prompts, retrieved excerpts, outputs, review comments and logs. Ask which components retain each category and who can access it. The purpose is to identify the relevant decision and evidence owner, not to declare compliance merely because a region or privacy setting appears in a product brochure.

Protect the evaluation material as well. A test set can contain confidential specifications or licensed content even when it excludes personal data. An assessor should use permitted material and record any masking or substitution that changes the test's realism. Synthetic examples can test mechanics while leaving questions about the real source population unresolved.

For a restricted initial experiment, it may be reasonable to use an approved source bundle and a manual review process. A later connected pilot requires evidence for live access, updates and the operating path. Make the difference explicit rather than assuming that controls demonstrated in an isolated exercise already exist in the intended production workflow.

Keep authority and review separate from fluent drafting

Assign a person who can accept factual claims, a person who can accept commercial use and an owner of the publishing or downstream action. These responsibilities may sit with one person in a small team, but the decisions remain distinct. The model's ability to draft a claim does not grant any of those authorities.

Show the reviewer the evidence required to make the decision. A generated statement labelled “verified” is not proof that the supporting source was inspected. Record material corrections and unresolved disagreements, and test whether the reviewer can withhold acceptance without disrupting the entire workflow.

When the intended use is a marketing campaign, the output also needs approved offer positioning, buyer context and channel authority. AI readiness for marketing content examines that broader commercial preparation. The product-card example here focuses on the narrower question of whether grounded generative output can be defined and judged before broader execution is considered.

Check whether the review process can detect a plausible error

A review step is credible only when the reviewer can see what would make a draft unacceptable. For the workwear cards, give the reviewer the relevant source revision, product variant and claim rules alongside the output. A fluent sentence saying that a jacket meets a protective standard may look ordinary among accurate descriptions. If the reviewer has only a marketing brief, the missing evidence may be invisible. The assessment should identify that visibility gap before the team counts review as an effective control.

Use a small, controlled reviewer exercise with deliberately labelled test material. Prepare one supported card, one card with an unsupported performance claim and one with a subtle change in washing temperature. Ask the reviewer to identify the affected statement, locate the deciding evidence and record the disposition. This tests whether the proposed role, materials and instructions support the work. It is not a covert employee assessment, and the test cards must remain outside public publishing channels.

Record disagreement rather than resolving it by seniority alone. If two reviewers interpret the same care instruction differently, the next task may be to clarify the source or acceptance wording. If both miss a fabricated certification, a longer prompt is unlikely to be the whole answer; the evidence display and review assignment need attention. A readiness conclusion should distinguish a reviewer who has not yet been trained from a process that withholds the necessary information.

Finally, define the evidence that an approved draft actually passed review. A comment that the copy looks good does not establish factual acceptance, Arabic acceptance and permission to publish. A short decision record can capture these separately without introducing a complex platform. Later software can implement the chosen workflow, but the assessment must first establish that the underlying decisions are intelligible and achievable.

Turn the assessment into a proportionate next experiment

List the uncertainties the next experiment should resolve. Some concern the source bundle; others concern model behaviour, reviewer performance or output-format preservation. Assign each uncertainty a test, an owner and a decision consequence. Avoid a demonstration whose success is defined only by whether participants like the resulting text.

A useful experiment brief identifies the model and configuration to be recorded, the protected evaluation cases, the expected behaviour categories and the circumstances that stop the exercise. It also states what conclusions cannot follow from the result. The readiness-versus-proof-of-concept guide clarifies how the readiness work enables this experiment without pre-judging it.

Prioritise unresolved conditions that prevent meaningful evaluation. If source precedence is unknown, settling it may be more useful than trying another prompt. If reviewers cannot agree on acceptable claims, refine the decision criteria. If the source path cannot preserve variant identity, repair that path before treating an apparent model error as the central problem.

Open for AI's enterprise data and AI readiness assessment can examine these prerequisites for a defined generative workflow. For a generative AI readiness discussion, bring one permitted source bundle, an example of the desired output, and a description of who will accept it. Those materials support a concrete decision about what to verify next and how narrowly to begin.