What work on the Product Backlog might the Nexus Integration perform?

I'm curious as to why you associate potential work done by the Nexus Integration Team with work that is performed outside the regular planning and review session. The NIT is a standing team. It may be a unique team or it may be made up of members of the Scrum Teams that are part of the Nexus. They work within the exact same Sprint cadence as the other members of the other Scrum Teams that form the Nexus. There may be Product Backlog Items that are cross-cutting from the other Scrum Teams and is best served by being taken to Done by the Nexus Integration Team.

The Nexus Guide states that the Nexus Integration Team "might perform work from the Product Backlog". What does this mean?

The Nexus Guide says: "The Nexus Integration Team is accountable for ensuring that a 'Done' Integrated Increment (the combined work completed by a Nexus) is produced at least once every Sprint. The Scrum Teams are responsible for delivering 'Done' Increments of potentially releasable products, as prescribed in Scrum."

If it transpires that the Development Teams in the Nexus are unable to deliver a "Done" increment as planned, the NIT may have to perform relevant parts of the work in order to provide integration assurance. 

There may be Product Backlog Items that are cross-cutting from the other Scrum Teams and is best served by being taken to Done by the Nexus Integration Team.

If so, then I am missing the documentation on this. Where can I find it? I couldn't find any reference that states the work how the NIT takes PBIs to done. Are they planned within the regular Nexus Sprint Planning, or are they determined on demand when any of the individual SCRUM teams need them?

In any case, when they would address cross-cutting concerns I would expect them to belong to the same overarching Nexus Sprint Goal as the teams are working towards. Is this right? Or are they also allowed to work ahead? If the latter is the case, I would find it strange because they could basically be doing work that is not part of a potentially releasable increment right?

If it transpires that the Development Teams in the Nexus are unable to deliver a "Done" increment as planned, the NIT may have to perform relevant parts of the work in order to provide integration assurance. 

Ok so does your answer imply they assist working towards the same Nexus Sprint Goal by performing any of the integration work planned for the individual Scrum teams? So, basically the NIT is responsible for coaching and assisting, but only when things don't head into the right direction they can provide support. Is that how I should see it?

If so, then I am missing the documentation on this. Where can I find it? I couldn't find any reference that states the work how the NIT takes PBIs to done.

Why do you need specific documentation? Scrum and Nexus are frameworks - they don't address every single concern that may arise when applying them, but they provide guidance. If you also consider the Scrum Values or go even deeper to the underlying values and principles of Agile Software Development and lean, you can make reasonable conclusions about some possible good approaches that would satisfy these fundamental values and principles. Of course, there are also organizational contexts to consider that would impact what options make sense to choose from for your team(s).

In any case, when they would address cross-cutting concerns I would expect them to belong to the same overarching Nexus Sprint Goal as the teams are working towards. Is this right? Or are they also allowed to work ahead? If the latter is the case, I would find it strange because they could basically be doing work that is not part of a potentially releasable increment right?

I would agree with you. The Nexus Integration Team should be supporting the Scrum Teams in the Nexus as they work toward the Nexus Sprint Goal and ensuing that there is a Done and potentially releasable increment at the end of the Nexus's Sprint. I wouldn't encourage working ahead, except in the context of refinement, which is looking at Product Backlog Items that may be pulled into a future Sprint.