Using company knowledge with AI means giving a defined task access to relevant, permitted material and making the result checkable. It does not mean uploading every company file. Start with a small source set, record who owns it and test current, missing, conflicting and inaccessible information before relying on the answer.
The useful outcome might be a faster route to an approved policy, a better prepared client-work draft or a more consistent internal handover. AI can help people find and prepare information; your business still needs to decide which information governs the work.
Start with the question the team needs to answer
“Use our knowledge” leaves too much unspecified. Choose a task such as preparing an internal answer to an order-status question or drafting a section from approved service material. Name the person who will check it and the action that follows.
Separate general company knowledge from information authorised for this task. A past proposal may be useful evidence of wording, while its price or client-specific advice may be inappropriate for reuse. Permission to read a folder does not establish permission to apply every statement in it to a new situation.
Before adding a retrieval system, ask whether the team would benefit from a clearer index, an approved template or a maintained policy page. Those can be useful improvements in their own right.
Create a small source register
Use this as an editable working table. A document can have several versions; record which one governs the task rather than assuming the newest upload is correct.
If columns don't fit, scroll sideways. Keyboard: focus the table and use the arrow keys.
| Field | What to record |
|---|---|
| Source and location | Exact document, record or collection the task needs |
| Owner | Person responsible for correctness and updates |
| Authority | Approved policy, working draft, historical example or another stated status |
| Current version | Version, effective date and replacement rule |
| Permitted users | Roles and people who may access it for this purpose |
| Permitted processing | What may be sent to which provider or connected application |
| Useful reference | How a reviewer can find the passage or record used |
| Refresh method | Who updates or reconnects it and when |
| Missing or disputed source | What the workflow should show and who resolves it |
An empty field is a prompt for a decision. If two departments disagree about the governing policy, preserve that uncertainty. A more fluent answer should not settle an unresolved business decision.
Choose a proportionate access route
There are several possible arrangements. The names and availability of product features change; choose on the task and verify the current plan and configuration.
If columns don't fit, scroll sideways. Keyboard: focus the table and use the arrow keys.
| Route | Useful when | What needs checking |
|---|---|---|
| Selected files supplied for a task | A person controls a small, relatively stable source set | Permission, versions, manual updates and where copies remain |
| A reusable workspace configuration | People repeat a similar task with maintained instructions and sources | Ownership, sharing, source upkeep and operator review |
| A supported connection to a source system | The task needs information held in an existing application | Provider support, authentication, permissions, refresh behaviour and action limits |
| A separately built retrieval workflow | The work needs specific selection, traceability or integration beyond a suitable existing feature | Build scope, access controls, tests, running cost and maintenance |
Do not assume the last route is the best. Compare a supported feature with a custom build on the same cases. The guide to subscriptions, reusable configurations and API builds explains where that boundary often sits.
Check access using the actual roles
For a supported connection, distinguish enabling the connection from authorising each person's access. Anthropic's connector guidance describes organisation enablement and authentication arrangements that depend on the plan and configuration. Check the current setup rather than assuming that an enabled connector exposes the same material to everyone.
Test with an operator, a reviewer and a role that should not receive a source. Include a revoked-access case where appropriate. Define what happens if the source application is unavailable or access changes. Reading a record and writing to a record need separate decisions.
OpenAI's business-data commitments describe its default handling of business data. They do not grant permission to process a client's documents or settle what a third-party application does. Check the parties, purpose, retention and contractual obligations for the proposed arrangement.
A fictional policy-answer test
The following is an illustrative design exercise, not a client system or a tested product result.
A business wants an internal assistant to prepare a response to delivery-policy questions. The customer lead remains responsible for the reply.
If columns don't fit, scroll sideways. Keyboard: focus the table and use the arrow keys.
| Test case | Expected behaviour to write before testing |
|---|---|
| Current policy contains the answer | Prepare a draft and show the relevant current passage |
| Policy does not cover the request | Identify the gap and refer the exception to the customer lead |
| Old and current policies conflict | Use the approved governing version or hold if authority cannot be established |
| Operator lacks access to the source | Explain the access limitation without disclosing restricted content |
| Customer requests a new promise | Leave the commitment for the authorised person |
The test is about the complete arrangement: source selection, instructions, permissions, preparation and review. A citation that points to an old policy can make a wrong answer look more credible. Opening the reference and checking its authority is part of the review.
Ready for a person to decide. The draft has its source beside it. The customer lead checks the wording, edits it and decides what to send.
Read both paths
Complete information: customer request and approved policy → prepared draft with source → customer lead reviews → ready to send if approved.
Conflicting policy: customer request and conflicting sources → draft withheld → policy owner resolves the source → draft is prepared again for human review.
A fictional teaching example, not a client result or a live ChatGPT or Claude session. The handover does not send a message automatically.
Measure retrieval and answer quality separately
If a result fails, identify where. Did the task receive the wrong source? Did it miss an available passage? Did it interpret a correct passage incorrectly? Did the reviewer lack enough context to decide? These failures suggest different corrections.
Record the source version, question, retrieved material, draft, reviewer decision and changes. Keep only the records necessary for the agreed purpose, under the applicable retention arrangement. Do not build a new archive of sensitive material just to make a demonstration look auditable.
Assess the full task as well as the answer. If people spend more time checking references and correcting drafts than they previously spent finding the answer, the arrangement needs improvement. Use the measurement guide to compare the work fairly.
Give knowledge upkeep an owner
Agree how policies, templates and permissions change after launch. Keep a small regression pack for the task and rerun affected cases when a source, instruction, connection or provider behaviour changes. Preserve a way to pause the arrangement and use the current manual process.
Our ChatGPT + Claude Implementation service can help establish a useful source set, access boundary and review method. The next step is a free 25-minute Fit Call. Detailed investigation, configuration or a connected build is scoped separately once the task is clear.