We sell an AI and automation service, so treat the following as an attempt to be useful rather than impressive.
Where it earns its place
Classification with a human backstop. Routing support tickets, tagging content, flagging probable duplicates. The cost of being wrong is one extra click, and volume is high enough that even 85% accuracy saves real hours.
Extraction from unstructured input. Pulling line items out of supplier PDFs that arrive in nine different layouts. The alternative is a person retyping, which is neither cheaper nor more accurate.
First drafts of throwaway text. Alt text, meta descriptions, seed copy for a page that a human will rewrite anyway.
Where it does not
Anything where being confidently wrong is expensive. Pricing, stock availability, medical or legal statements, anything a customer will act on without checking. A deterministic rule that fails loudly beats a model that fails plausibly.
Work you cannot check. If nobody on the team can tell whether the output is right, you have not automated a task — you have removed your ability to know it is broken.
Problems that are actually data problems. Most "we need AI to predict demand" conversations end at "your stock data is entered inconsistently across three systems." Fix that and a much simpler model works.
Cost per call is an architectural constraint
These features are priced per use, which makes them the only part of a product whose running cost scales directly with how popular it is. That has to be designed for, not discovered in a monthly invoice.
In practice: cache aggressively, because the same forty support questions get asked repeatedly and answering them from a cache is both free and faster. Put a hard cap on spend per account and per day. Choose the smallest model that passes your accuracy bar rather than the best one available. And define what the feature does when the budget is exhausted or the provider is down, because "nothing happens and the page hangs" is the default and it is never the right answer.
Arabic changes the arithmetic
Two things differ, and both are easy to miss when a proof of concept is built in English.
Quality is generally behind — noticeably so for dialect and handwriting, less so for formal written Arabic — which moves the accuracy threshold and therefore how much human review the workflow needs. And cost per request is usually higher for the same text, because Arabic script tends to consume more tokens than the equivalent English. A feature that is comfortably economic in English can be marginal in Arabic, so both get measured on real data before anything is promised.
Where the effort actually goes
The demo takes days. What takes the remaining time is everything around it: getting the source documents into a state worth indexing, defining the confidence threshold, building the review queue and the screen someone fixes rejected items in, logging every decision so a dispute can be answered, and monitoring accuracy after launch rather than trusting a launch-day benchmark.
If a proposal you have received is mostly about the model, it is a proposal for the easy part.
The question to ask first
Before adding a model, ask what happens when it is wrong on a Tuesday afternoon and nobody notices for a week. If the honest answer is serious, you need a rule, a review step, or both — not a better prompt.