Stop reading the model's answer. Make it fill a form.
Most teams still use AI the way you would use a very fast writer. You ask a question, it returns a paragraph, and a person reads the paragraph and types the useful parts into a system. That works, and it is also the weakest possible way to wire a language model into a process, because every step after the model, the reading, the interpreting, the re-keying, is unstructured, unlogged and error-prone.
Structured outputs invert that. Instead of asking for prose, you hand the model a schema, a precise definition of the fields you want and their types, and the model is forced to return data that fits it. Not asked nicely to return JSON. Forced. Every major provider now ships the same mechanism, and for anyone building AI into regulated work it changes the unit of an AI answer from text a human interprets to data a system can check.
It is not the most talked-about capability of the year. It might be the most useful one for turning an AI demo into something you can actually govern.
What actually shipped
The mechanism is now standard across the frontier providers, and they describe it in almost identical terms.
OpenAI's documentation says Structured Outputs is a feature that ensures the model will always generate responses that adhere to your supplied JSON Schema, and draws the line against the older approach: while both JSON mode and Structured Outputs produce valid JSON, only Structured Outputs ensure schema adherence. Anthropic, launching the feature on the Claude Developer Platform in November 2025, describes it as guaranteeing your response matches the exact structure you define, without any impact to model performance. Its documentation explains the how: structured outputs work by compiling your JSON schemas into a grammar that constrains Claude's output. Google's Gemini and Microsoft's Azure OpenAI offering ship the same capability, with Microsoft's docs contrasting it against the older JSON mode, which guaranteed valid JSON but could not ensure strict adherence to the supplied schema.
The shared idea under all of it is constrained decoding. A model generates text one token at a time, and normally any token is allowed. When you attach a schema, the platform compiles it into a grammar and only permits tokens that keep the output valid against your structure. The model is not trying to remember to produce good JSON. It is mechanically prevented from producing anything else. That is why the guarantee is strong in a way that a prompt saying please return JSON never was.
This is not an experimental corner of the platforms, either. Microsoft's Azure OpenAI documentation, updated in June 2026, lists structured outputs as a supported capability across its current and older production models, and OpenAI has framed it as the production default for reliable JSON since 2024. In other words, this is a stable, enterprise-grade feature you can build a compliance workflow on, not a preview that might change under you. The capability has quietly become table stakes while the attention went to model releases.
What it actually means
The significance is not that you get JSON. It is that the boundary between the model and your system becomes a contract.
When an AI answer is prose, the integration is a person. Someone reads the output, decides what it means, and moves the values into the next system by hand or with brittle text parsing. Every one of those steps can fail silently, and none of them is logged. When the answer is a schema-constrained object, the model becomes a component with a defined output type. You can pass it straight into code, enforce validation rules on each field, store exactly what came out, and trace it. The AI stops being a chat you copy from and becomes a data-extraction function you can test.
For a whole class of regulated tasks, that is the difference between a clever demo and a defensible pipeline. Pulling the key dates and amounts out of a claim. Extracting the obligations from a contract into a register. Turning a messy incident note into structured fields for a risk system. Classifying a document against a fixed taxonomy. All of these are extraction problems, and all of them are far safer when the output is typed and checkable rather than free text a person retypes.
Anyone wiring AI into a repeatable process should care about this, but two groups most of all. Developers and technical teams building AI features get a reliability primitive that removes a whole category of parsing bugs. And GRC, compliance and operations leads get something they rarely get from AI: an output they can govern, because a schema is a specification you can point an auditor at, and a validated field is evidence in a way a paragraph never is. If your AI use case is essentially getting structured facts out of unstructured documents, and in regulated work most of them are, this is the feature that makes it defensible.
Take the contract-to-register case concretely. The prose approach asks the model to summarise a contract's obligations, and a person reads the summary and copies clauses, dates and owners into a spreadsheet, with all the transcription risk that carries. The structured approach defines a schema, obligation description as a string, due date as a date, responsible party as a string, source clause as a reference, and the model returns a list of objects that fit it exactly. Now the register can be populated programmatically, each field can be checked by rule, and there is a logged record of precisely what the model extracted from which document. The task did not get smarter. It got auditable, and that is what a regulator or an internal auditor actually asks to see.
The caveat that keeps you honest
Here is the mistake that will bite the teams who adopt this carelessly: believing that because the output is valid, it is correct. It is not the same thing, and the vendors say so plainly.
Google's documentation is the bluntest. Even when the output is syntactically correct JSON, it says, always validate values in your application, and it tells developers to implement robust error handling for schema-compliant but semantically incorrect outputs. In other words, the model can hand you a perfectly structured object in which a field is simply wrong. Anthropic's docs note the same class of gap, that there are scenarios where the output may not match your schema at all, notably when the model refuses on safety grounds, so a refusal has to be detected rather than parsed as data.
The clean way to hold it in your head: structured outputs eliminate format failures, not factual ones. The old failure mode was the model returns something you cannot parse. The new failure mode is the model returns something you can parse that is wrong, and it looks trustworthy precisely because it is well formed. A wrong value in a tidy schema is more dangerous than a garbled paragraph, because the garbled paragraph announces that it needs checking and the tidy object does not.
The Australian angle: this is where APP 10 lives
For Australian regulated work, that caveat is not a footnote, it maps directly onto a legal duty.
The OAIC's guidance on commercially available AI products is direct. APP 10 requires entities to take reasonable steps to ensure the personal information they collect is accurate, up to date and complete. The guidance says a human user should be responsible for verifying the accuracy of any personal information obtained through AI and be able to overturn decisions, and it tells organisations to treat AI outputs as statistically informed guesses. A schema does not change any of that. It makes the guess arrive in a tidy box.
So the right architecture puts the two jobs in the right place. The schema handles structure, so your pipeline is auditable and your fields are type-safe. The human handles truth, verifying the values that matter before they reach a decision, which is exactly the reasonable step APP 10 asks for. Structured outputs do not remove the human verification step. They make it clearer, because now there is a defined set of fields to check rather than a paragraph to re-read, and a clean record of what the model actually produced.
The hype check
Two things get oversold here, and both are worth naming.
The first is the word guarantee. Schema compliance is very strong but not absolute. Refusals, enum casing edge cases and provider limits all mean a small fraction of responses will not conform, so you still write error handling. Treat the guarantee as a reliable floor, not a promise you can skip validating.
The second is the implication that structured outputs make AI safe to trust unattended. They do the opposite of that, honestly read. By making the output look finished, they raise the temptation to skip the human check, which is exactly when a well-formed wrong value slips through. The capability makes your pipeline cleaner and more auditable. It does not make the model right, and reading it as a licence to remove the person is the failure mode to guard against.
What to do this week
- Find one extraction task you run on prose. Look for a place where AI already produces text that a person reads and re-keys into a system: dates and amounts from a document, obligations into a register, fields from a note. That is your first candidate.
- Write the schema, and make it strict. Define the fields and types, mark every field required, and set additionalProperties to false so the model cannot invent fields. Keep it flat and focused, within the roughly 100-property and five-level-nesting ceilings the providers document, so the grammar stays clean.
- Add the value checks the schema will not do. For each field that matters, write an application-level validation: ranges, allowed values, cross-field consistency. The schema guarantees the field exists and is the right type. Your code guarantees the value is plausible.
- Keep the human on the values. Design the review so a person verifies the fields that carry consequence, and log both the model's output and the human's confirmation. For anything touching personal information, that is your APP 10 reasonable step, made concrete.
- Handle the refusal case. Detect when the model declined rather than answered, using the stop reason, so a refusal never gets silently treated as empty data.
Structured outputs are the least glamorous upgrade you can make to an AI system and one of the most consequential. They turn the model from a writer you interpret into a component you can check, which is the whole game in regulated work. Just remember what they guarantee. The shape is handled. The truth is still yours to verify, and that is the part no schema will ever do for you.
TheAICommand. Intelligence, At Your Command.
