AI
Grounded AI for support teams
Useful AI retrieves the right cases, respects access and shows its evidence.
I became interested in AI for support because the recurring problem was not a lack of documentation. It was finding the right fragment of trustworthy knowledge, for the right customer and product version, while a case was still active.
A fluent answer can still be operationally dangerous
Generic language models are very good at producing plausible steps. Support engineers need verified steps. If the answer cannot point back to the case, runbook or product note that supports it, the engineer must treat it as a suggestion rather than guidance.
My early support-assistant design used retrieval over curated Jira and Confluence material. The goal was not an autonomous agent. It was to reduce search time while keeping the evidence beside the answer.
Access control belongs in retrieval
In enterprise support, knowledge is not one public corpus. Customer data, internal investigations and restricted operational notes have different audiences. Filtering after generation is too late; tenant and role boundaries must constrain what can be retrieved in the first place.
This is also why I care about open-weight models and deployment options. Regulated firms will ask where prompts go, how data is retained and whether the inference layer can move. Those questions are architecture requirements, not procurement footnotes.
Measure assisted decisions, not impressive demos
I would evaluate an assistant on citation quality, retrieval precision, time to useful evidence and the rate at which engineers accept or correct suggestions. A beautiful answer with the wrong source is a failure.
The right ambition is modest but valuable: help a skilled person reach a defensible decision faster. Once that works reliably, automation can expand.