AI Inside the Product: Log Analysis, Troubleshooting and Support Triage

For two years the AI in our work was behind the scenes: coding agents writing tests, translating queries and explaining old units, and later MCP tools that let an assistant look at a device for a support engineer. This year it moved into the product. Three features shipped: automated log analysis, a troubleshooting assistant for engineers in the field, and support triage. This article is about how, and about the one rule that made all of it possible.

The rule

AI explains. Humans act.

Nothing opens a locker, changes a lock schedule, closes a ticket or sends a customer a message because a model said so. The model reads, summarises, proposes and drafts. A person decides. In a product that guards cash and valuables, that is not a limitation we accepted reluctantly; it is the design. It is also what let us ship, because a feature that only explains can be wrong without being dangerous, and a feature that can be wrong without being dangerous can be improved in public.

Log analysis

Every device we make writes logs: locks, safe deposit systems, hubs. When something goes wrong, the log usually knows why, and finding out used to mean an experienced engineer reading it line by line. The feature does the first pass.

The pipeline is mostly not AI. Logs are collected, normalised into one format, and filtered the way an experienced engineer would start: errors first, then the minutes around them, then counts of everything else. Only that excerpt goes to the model, with one instruction that took us a while to get right: every claim must cite the log lines it rests on, and "the log does not show the cause" is an acceptable answer.

The output is a short summary, up to three probable causes with their evidence, and the lines that support each. The engineer sees the evidence next to the claim and decides whether to believe it.

We measure it against an evaluation set built from past incidents with a known root cause, several hundred by now. The metric is whether the known cause appears among the model's proposals with correct evidence. It was the hardest of the three features to make trustworthy, and I wrote about why in the benchmark article: models produce confident, fluent narratives, and a fluent narrative pointing at the wrong component is worse than no narrative. Citations fixed most of that. Allowing "I cannot tell" fixed the rest.

The troubleshooting assistant

A service engineer in a bank basement with a phone and a device that will not come online does not want a chat about the device's history. They want the next thing to check. The assistant answers that question from the material we already had and nobody could find in time: manuals, service bulletins, firmware release notes and the resolved tickets of the last ten years, retrieved for the specific device model and firmware version, and summarised with references to the source.

Two lessons from building it. First, chunk manuals by procedure, not by page; the model needs the whole "replace the lock controller" sequence, not the half of it that fits on page 41. Second, keep versions apart. A procedure that was correct for firmware 3 and wrong for firmware 4 is the most dangerous document in the archive, and the retrieval has to know which device it is serving.

It runs on the engineer's phone, it works with cached manuals when there is no signal, and every answer shows where it came from. The engineers who trusted it first were the newest ones. The veterans took a few months, and what won them over was catching it being right about something they had forgotten.

Support triage

Support receives tickets by email, through the portal and from partners. Each one used to be read by a person, classified, assigned and answered. Now the first pass is automatic: the model classifies the ticket, extracts device model, serial number and firmware version, proposes a routing, and drafts a reply. A person reviews, edits and sends.

This was the easiest feature to build and the one that changed the numbers most. Time to first response fell, misrouting fell, and the support team's day moved from sorting to solving. It also runs on a small, cheap model, because classification is a task where the benchmark showed the expensive models buying almost nothing.

The one mistake worth confessing: the first version could close tickets it judged resolved. Two weeks and one angry partner later, it could not. Humans act.

The engineering around it

Shipping a model is shipping a dependency, and the DevSecOps habits transfer directly.

• Pin model versions, and evaluate before upgrading. A new version runs through the evaluation set and has to beat the current one before it goes to production. Vendors change models; our customers should not notice.
• Log everything, minus secrets. Every prompt and response is stored with the ticket or incident it belongs to, with credentials and personal data scrubbed before storage. When an engineer asks why the assistant said something, we can answer.
• Data stays in the region. Models are reached through endpoints in the EU, customer data is never used to train anything, and the contracts say so in writing. Legal read them before the first line of code.
• Costs are a dashboard. Token spend per feature sits next to build times and test coverage. Prompt caching and routing cheap tasks to cheap models made more difference than any prompt engineering.
• Users know. Every AI-generated summary, answer and draft is labelled as such, and the human oversight is documented, which is both the right thing and what the regulation expects.

What we got wrong

The first log analysis was too talkative; engineers want three lines, not three paragraphs. The triage automation went one step too far, as above. And we underestimated how long trust takes: the features were accurate months before they were trusted, and what built trust was not accuracy but evidence, the citations and the visible tool calls that let a sceptical engineer check the work.

What is next

The three features share tools, evaluation sets and rules, and the next ones will share them too. The constraint is not what the models can do. It is how much of it we can verify, and that is the right constraint for a company in this business to have.

Questions for you

• What is the one rule in your product that AI must never cross, and is it written down?
• How big is your evaluation set, and who adds to it when something goes wrong in production?
• What built trust in an AI feature on your team: accuracy, or the ability to check it?

Email me at bjorn.nostdahl@nostdahl.com. I am especially interested in how others handle the trust problem with experienced engineers; we got there, but slowly.