Most AI initiatives start with a model conversation — which one, which provider, which context window. The conversation that actually determines whether the system survives contact with production is different: where does this component sit in the existing architecture, and what does it own?
An AI capability that reaches directly into production databases, or that has no defined failure behaviour when the model call errors or times out, is not integrated — it is inserted. The difference shows up months later, when nobody can explain why a downstream service occasionally receives malformed data.
Treat the model call as an external dependency, not an internal function
A model call has the latency and failure profile of a network call to a third party, because that is what it is — even when it is your own infrastructure. It needs a timeout, a retry policy that does not retry non-idempotent side effects, and a defined behaviour for what the caller does when the model is unavailable or returns something unexpected.
In practice. Wrap every model call behind an interface your application code depends on, not the vendor SDK directly. Provider swaps and evaluation-driven prompt changes then touch one file, not every call site.
Give the AI component a narrow, explicit contract
The components on either side of an AI capability should not need to know how it decided anything — only what it is allowed to return, and what it does when it cannot decide. A summarisation service that sometimes returns a summary and sometimes returns a paragraph of hedging is not a service with a contract; it is a function with a mood.
- Define the output schema and validate against it before anything downstream sees the result.
- Decide explicitly what "I don't know" looks like, and make it a valid, expected response — not an exception path nobody tested.
- Keep business rules (who is allowed to see what, what counts as a valid answer) outside the model call, where they are auditable.
The integration boundary is where reliability is won or lost
Model quality determines how good an answer can be. The architecture around it determines whether a bad answer stays contained, whether a slow response degrades gracefully, and whether the rest of the system keeps working when the AI component does not. Most production incidents in AI-enabled systems trace back to the boundary, not the model.
References
Architecture review checklists used in AFC engagements are available on request.