Runtime
When a Website Should Call an AI API
Most marketing pages should never call a model at request time. Some product moments should.
Call an API only if the answer cannot be prebuilt
If the content is known at build time, generate the HTML then. A model call on every page view adds latency, cost, and a new outage mode.
Good request-time uses are personal to the input: classifying an inquiry, drafting a reply for staff, or answering from a closed set of documents the visitor selected.
Put a ceiling on it
Every live integration needs a timeout, a maximum input size, and a monthly cost expectation. Open-ended chat on a public page fails all three.
We would rather refuse a huge prompt than let a form become an unbounded bill.
Failure is a design state
The page must say what happened and offer the non-AI path: a normal form, a phone number, a static FAQ.
If the feature is useless without the model, it is probably the wrong feature for this site.
Continue
Editorial Control Over Model Drafts
How to keep GPT, Gemini, Grok, and Claude drafts inside a review process so the published site stays accurate and on-voice.
Read →Accessibility Still Comes First
Why GPT, Gemini, Grok, and Claude features must meet the same WCAG 2.2 AA bar as the rest of an Alaska website.
Read →Performance When AI Features Are Added
How to add GPT, Gemini, Grok, or Claude features without wrecking Core Web Vitals or shipping a chat SDK on every page.
Read →