AI in enterprise software runs about 90% hype and 10% genuinely useful, and my goal was to find that 10% rather than ship something that would look impressive in a demo and then quietly go unused. The starting point was talking directly to factory managers and department heads about what actually slowed them down, rather than guessing at what an AI feature "should" look like. That conversation-first approach is the most important thing a team can do when adding AI features, and it's also the step most teams skip — they start from the technology ("we have an LLM, what can we do?") rather than from the problem. The answers were consistent: finding information in the system was slow, data entry was repetitive, and catching anomalies required manual dashboard monitoring.

We set a hard rule: every AI feature would ship with a clear "non-AI fallback" that users could switch to. That rule forced us to think about each feature as an enhancement to an existing workflow rather than a replacement, which kept the AI features accountable to the same standard as the rest of the system. If the AI feature was good, users would use it; if it wasn't, they'd fall back and we'd know the feature wasn't pulling its weight. That accountability is what separates a real AI feature from a vanity AI feature — the vanity feature has no fallback, so its lack of usage can't be measured.

RAG-powered Q&A was the most visible win. Users can ask natural-language questions about their data — "show me orders that are overdue this month" — and the system translates that into a structured query, retrieves relevant records, and generates a response with citations back to the underlying data. The citation feature is what made this trustworthy — without it, the LLM's output is just an unverified claim, and enterprise users are rightly skeptical. With it, the user can click through to the actual records and confirm the answer is grounded in real data, which turns the LLM from a potential source of misinformation into a time-saving search assistant.

Smart form prefill was the most quantifiable win. Based on historical entry patterns, the system suggests likely values as a user starts typing. It sounds minor, but it saved each data entry operator roughly 2 hours per day. The implementation was deliberately conservative: only suggest when confidence is high, and the user can always ignore the suggestion. Anomaly detection was the most operationally impactful win — simple statistical models (rolling averages, standard-deviation thresholds) flag production metrics that deviate from historical patterns, and a sudden drop in line efficiency triggers an automatic notification to the production manager instead of waiting for someone to spot it on a dashboard.

Fully automated report generation sounded like an obvious win but the output was never quite right. Users preferred templates with manual overrides over fully generated reports, because the AI versions landed around 80% correct — accurate in structure but with enough small errors that someone had to review the whole thing anyway, defeating the time savings. An 80% correct report that has to be fully reviewed is arguably worse than a template the user fills in themselves, because reading every word to find the 20% that's wrong is more cognitively demanding than writing from scratch. The deeper problem is that reports in enterprise contexts aren't just data aggregations — they're communications from one person to another, and audience expectations matter in ways hard to capture in a prompt.

The lesson: any AI feature in an enterprise context needs a clear, easy "human override" control, without exception. If users can't quickly correct the AI's output when it's wrong, they will stop trusting the feature entirely and route around it, no matter how good the underlying model is on average. Trust is built slowly and lost quickly, and a single bad experience — an AI-generated report that goes out with an embarrassing error — can sour a user on the entire feature category for months. Designing for the failure case, not just the success case, is what separates a feature that survives in production from one that gets quietly disabled after the launch buzz fades.