Useful AI removes friction you can name
Summarising feedback, suggesting tags, finding relevant content and helping an administrator draft a report can save time. The benefit is clearest when a person remains able to check the source, change the result and decide what happens next.
Start with a task, not the letters AI. Describe who does the work today, what makes it slow, what a good result looks like and which mistakes would matter. If a feature cannot improve that process in a way you can observe, it is not yet a business case.
The good: assistance with a visible source
Lower-risk uses help a person interpret or prepare information without quietly changing the system of record. Search that cites approved learning, summaries linked to the original feedback, draft descriptions, suggested metadata and administrator query support can all be valuable when the evidence remains visible.
The quality test is simple: can the user see where the answer came from, correct it easily and continue without trusting a black box? Good assistance shortens a task while preserving judgement.
- Show the source content used to produce an answer
- Make suggestions editable before anything is published
- Separate approved organisational knowledge from open web content
- Record which model or feature produced a material output
- Give users a clear route to report an incorrect result
The bad: automation without an operating model
An assistant that reads approved content and proposes an answer is different from one that assigns training, changes a record or decides whether somebody is compliant. Once a feature can write to the platform, trigger a workflow or influence a formal decision, permissions and failure handling become part of the design.
Do not accept 'a human is in the loop' as a complete control. Establish which human, at what point, with what information, and whether they can genuinely stop or reverse the action. A confirmation button is not meaningful oversight if the person cannot inspect the evidence.
Ask vendors questions that produce evidence
Broad questions such as 'Is our data secure?' invite broad reassurance. Ask the supplier to trace one realistic request from the user's prompt to the final record. You should be able to understand the data involved, the model boundary, retention, permissions, audit history and recovery path.
- What exact data is sent to the model, and where is it processed?
- Can our prompts, files or outputs be used to train another model?
- Which sources can the answer use, and can the user inspect them?
- What can the feature change without approval?
- How are permissions inherited from the LMS?
- What is logged, how long is it retained, and who can review it?
- What happens when the model, integration or source is unavailable?
Pilot the real process, not a polished example
Choose a bounded use case with real users and representative content. Record the current time, error rate and user experience before enabling the feature. During the pilot, sample outputs for accuracy, source quality, inappropriate disclosure and inconsistent behaviour across roles.
Decide the stopping conditions in advance. If the feature cannot keep restricted content restricted, cannot show a dependable source or creates more checking than it removes, pause it. A small pilot is valuable precisely because it makes saying no inexpensive.
Buy the outcome, not the label
Ask the vendor to demonstrate the feature against your process and measure what it removes. Compare that outcome with simpler options: better search, cleaner metadata, a revised workflow or an ordinary integration may solve the same problem with less risk and cost.
AI can make a learning platform more useful, but the label itself proves nothing. The right feature has a named user, a measurable benefit, visible evidence, appropriate permissions and an owner who knows what to do when it is wrong.