Choose only sources you may use in a public assistant

Separate access from permission

A document might be readable through an existing team account yet unsuitable for a public assistant. Before importing, identify who owns it, what readers may see and whether the selected processing route is approved. Avoid customer records, private tickets, credentials and internal notes in this public-documentation workflow. This guide is an operational checklist, not a legal opinion about a particular document or jurisdiction.

Use a public-only pilot when possible

A small collection of approved public help articles is easier to inspect than a mixed library of public and private material. Record the exact URLs rather than granting a broad drive connection for convenience. If the project genuinely needs private content, stop and design its access model separately. A public embed is not an acceptable shortcut for testing permissions intended for an internal assistant.

Inspect examples as carefully as prose

Documentation examples can contain real email addresses, sample tokens or copied customer details even when the main article is intended for publication. Review code blocks, screenshots and attachments before import. Replace sensitive examples in the source through the normal publishing process, then verify the updated copy. Do not rely on a chatbot instruction to keep a secret that should never have entered the source collection.

Keep a removal path

Know how to exclude a source and verify that it is no longer used for answers. Retain a minimal record of the removal decision without duplicating the sensitive content. Test the boundary using harmless synthetic examples, not actual secrets. If permission remains unclear, hold that source and continue with approved material; a missing answer is preferable to an unauthorized disclosure dressed up as helpful documentation.

• Mark each source as approved public, excluded private or unresolved permission; do not turn an unresolved row into an automatic import.