Answer
In practice this starts with the material that already exists but never gets read: job scheduler comments, incident tickets, change logs, RPG and COBOL program headers, and the tribal notes an admin keeps in a text file because nothing else captures the exceptions. A useful pilot picks one subsystem, one application, or one recurring support pattern and asks the AI tool to summarize, index, or answer questions against that material rather than trying to absorb the entire IT department at once. The narrower the scope, the easier it is to catch when the tool gets something wrong.
The main pitfall is treating the generated summary as the new source of truth instead of a pointer back to the original. Documentation drifts on IBM i systems that have been modified for twenty years by people who no longer work there, so any AI layer needs a way to flag when its source material is outdated or contradicted by newer changes. Buyers should ask vendors how the tool handles conflicting documentation, whether it cites where an answer came from, and whether subject matter experts can correct and retrain it over time. A tool that just generates confident prose with no traceable source is a liability in an environment where the wrong assumption about a job dependency or file layout can take down a production run.