An application should reject AI-generated data when it violates business rules, conflicts with trusted records, or lacks enough evidence—even if it passes a JSON schema. Treat the output as untrusted input: validate its shape and meaning before it can update records or trigger actions, and send consequential ambiguity to human review.
A valid shape is not a valid business record
An application should reject AI-generated data whenever it fails the rules of the task, even if the response is valid JSON and contains every expected field. A schema can confirm that a field is a string or a date; it cannot, by itself, establish that the date is plausible, that two fields agree, or that the source supports the value.
Treat generated output as untrusted input. Parse it, validate it against explicit business rules, and keep it out of authoritative records until it passes. If the task affects money, access, compliance, or customer commitments, route uncertain cases to a person rather than trying to make the output fit.
Find the failure modes a schema cannot see
Suppose an AI extracts a service request into fields for customer, requested date, equipment type, and urgency. The response may have all four fields in the right format yet assign an urgency not supported by the text, pair a customer with the wrong account, or turn an unclear date into a confident specific day.
List the ways each field can be wrong in context. Check allowed values, ranges, relationships between fields, and whether the source actually contains the evidence. A date may need to be in an acceptable window; an account identifier may need to exist and belong to the supplied customer; a required field may need to remain unknown when the source is silent.
Use layers of validation
Start with parsing and structural checks: required keys, expected types, permitted enum values, and limits on text length. Reject malformed responses and unexpected fields if downstream code could mistake them for meaningful data. Do not coerce a value quietly—for example, turning an invalid date into a default date can create a record that looks trustworthy.
Then apply domain and relationship checks using trusted application data. Confirm that referenced identifiers exist, that values fall within allowed ranges, and that dependent fields are consistent. Where the application needs evidence, require a source excerpt or reference and check that it supports the proposed value; the presence of a citation alone does not prove the claim.
Finally, assess whether the result is complete enough for the next action. A record can pass every deterministic rule and still be ambiguous. Define that case as a review or rejection outcome, not as permission to proceed.
Make rejection safe and recoverable
Validation should happen before a generated value updates a customer record, triggers an email, schedules work, or changes permissions. Keep the raw response separate from the validated representation, and commit changes only after all required checks pass. If multiple database writes form one business action, use a transaction where appropriate so a failure does not leave a partial update.
Return a useful internal failure category—such as missing field, invalid reference, conflicting values, or insufficient evidence—without exposing sensitive prompts or customer data in general logs. Decide whether to retry, request clarification, or send the item for review. Retrying is useful for transient technical failures; it is not a remedy for a consistent business-rule failure, and repeated attempts should not create duplicate side effects.
Choose review based on the consequence of error
Human review is appropriate when the input is ambiguous, the output conflicts with trusted data, the model cannot provide adequate evidence, or an incorrect value could cause material harm. Give reviewers the original source, proposed values, validation warnings, and a way to correct or reject the result. Avoid presenting an unverified suggestion as an already completed decision.
For low-risk, reversible tasks, a team may allow validated values to continue automatically while keeping an audit trail and a correction path. That is a business decision, not a capability guaranteed by the model. If a process does not benefit from generated interpretation, or a standard form and deterministic rules solve it more reliably, adding AI and its review burden may be unnecessary.
Test beyond neat examples
Build tests around the source material and the failure modes, not only around the model’s expected format. Include missing information, conflicting dates, unsupported identifiers, extra fields, unusual but valid values, and outputs that look plausible while violating a domain rule. Also test an unavailable provider, a timeout, and a response that cannot be parsed.
A useful verification step is to replay representative inputs through the full path: generation, parsing, validation, review or rejection, and persistence. Confirm that rejected data does not change authoritative records or trigger downstream actions, that reviewers can resolve exceptions, and that logs provide enough diagnostic context without retaining more sensitive material than the workflow needs.
Before accepting AI-generated data
- Define required fields, allowed values, and cross-field rules from the business task—not just the output format.
- Reject missing, contradictory, out-of-range, or unsupported values instead of silently filling them.
- Keep model output separate from trusted records until validation and any required human review are complete.
- Record a safe failure reason and retain enough request context to investigate, without exposing sensitive data in logs.
- Test valid, malformed, ambiguous, and plausible-but-wrong outputs, including cases where the source lacks necessary information.
Questions about this approach
Is schema validation enough to trust AI output?
A schema checks structure and basic types, such as whether a field is a string or a date. Business validation checks whether that value is permitted, consistent with related fields, supported by the source, and safe for the intended action.
What should the application do with a missing or ambiguous field?
Do not silently replace the value with a default or guess. Mark it invalid or unknown, preserve the source context needed to investigate, and route it for clarification or review if the field is required to continue.
When should a person review generated data?
Use review when uncertainty remains after deterministic checks or when an incorrect value could cause significant harm. For low-risk, reversible work, validated automation may be reasonable if the team can audit and correct its results.
For help applying this approach, explore our AI Development & LLM Integration services.
Discuss your project with Full Blown Studio
Tell us what needs to work better and what you have tried. Discuss your project, email bob@fullblown.com, or call (661) 429-0940.
