Generative AI becomes far more useful when it can work with company documents: contracts, customer records, policies, reports, tickets, financial notes, project files, and internal knowledge bases.

It also becomes harder to control.

A general-purpose chatbot answers questions using the context a user gives it. A document-connected AI system can search internal repositories, retrieve sensitive files, combine information from several sources, and sometimes act through connected tools.

At that point, accuracy is only one part of the risk. The company also needs to know:

• What can the AI see?
• What can it reveal?
• What can it change or trigger?
• Can the company reconstruct what happened later?

An AI policy will not answer those questions on its own. Neither will a vendor promise that company data is not used for model training.

Both have a place. But neither replaces permission design, logging, retention rules, human approval, and a controlled rollout.

Before AI becomes part of everyday document work, the control model needs to be tested as carefully as the product itself.

Why document-connected GenAI changes the risk

Most companies already restrict access to documents in some way. Finance files sit behind role-based permissions. Legal teams limit access to contracts. CRM records are visible only to certain groups. Some files are covered by contractual, regulatory, or internal policy requirements.

Generative AI sits on top of those existing systems.

The model may not store documents like a traditional database, but the application around it still retrieves files, passes excerpts into prompts, produces summaries, and may connect to other tools. If the underlying permissions are too broad, AI makes an old access problem much easier to exploit—sometimes without anyone realizing there was a problem in the first place.

The OWASP Top 10 for LLM Applications includes prompt injection, sensitive information disclosure, improper output handling, and excessive agency. These are not limited to a model producing a bad answer. They cover systems that expose protected information or take actions because the model was manipulated, given too much access, or trusted without enough review.

In practical terms, AI becomes a new interface into documents and workflows that may never have been designed for this kind of retrieval.

The same question appears when AI agents work with customer records, contracts, and billing data: access matters as much as output quality.

A policy is not a control model

Many companies begin with acceptable-use rules. They define which AI tools employees may use, what data should never be pasted into public systems, and who may run experiments.

Those rules are necessary, but they are easy to outgrow.

Once people find a tool that saves time, experiments become habits. Someone uploads a contract for summarization. A team connects an app to its document repository. Another employee uses a public tool because the approved option is slow or unclear. Soon, the company has AI use that exists in practice but not in its governance model.

Training and reminders cannot carry the whole load. The rollout needs enforceable answers to questions such as:

• Which tools and connectors are approved?
• Which repositories may they access?
• Which capabilities are available to each user group?
• Which document classes are excluded?
• Which actions need human approval?
• What is logged, who reviews it, and how long is it kept?
• What should a user do when an answer is incomplete, uncertain, or high-risk?

That is rollout design. It turns an AI policy into a system people can actually follow.

Start with permissions, not prompts

AI projects often begin with prompt design: how should people phrase better questions?

For sensitive documents, the first question should be more basic: what should the system be allowed to retrieve at all?

OWASP recommends least-privilege access, with the model limited to the permissions needed for its intended task. Before deployment, the team needs to map how document access works in reality:

• Which files are open to everyone inside the company?
• Which are restricted by team, role, location, seniority, or project?
• Which contain customer, employee, financial, contractual, legal, or strategic information?
• Which repositories are organized and permissioned well enough to connect?
• Which should remain outside the first rollout?

This is often the moment when an AI project turns into an information-management project.

Documents may be spread across shared drives, personal folders, CRM notes, chat exports, and old project spaces. Access rights may have accumulated over years. A former project member can still open a folder. A broadly shared link bypasses the restriction everyone assumes is in place. A confidential file has no sensitivity label.

Connecting AI does not create those weaknesses, but it can make them much easier to find and use.

A sensible rule is simple: do not give AI broad access to document systems the company cannot already govern clearly.

“We do not train on your data” is only one answer

Vendor privacy commitments matter. Microsoft, for example, states that prompts, responses, and data accessed through Microsoft Graph are not used to train foundation LLMs. Its Microsoft Copilot privacy documentation also says that Copilot surfaces organizational data a user already has permission to view.

That addresses one concern: whether company data becomes training material for the underlying models.

It does not tell the company whether its own permissions are correct.

If a user already has excessive access, an assistant that faithfully follows those permissions may still show them too much. A mislabeled file may be treated as ordinary content. Weak logging can make it difficult to reconstruct the prompt, the retrieved sources, and the resulting answer. Unclear retention rules can leave the company with a new trail of stored prompts and outputs it has not planned to manage.

The assessment therefore has two parts.

Vendor and platform controls cover data-use commitments, tenant isolation, encryption, retention options, admin settings, compliance documentation, and available logs.

Company controls cover identity, document permissions, sensitivity labels, approved use cases, review steps, audit ownership, and escalation.

One layer cannot compensate for a failure in the other.

If nobody can reconstruct the interaction, the system is not auditable

When AI touches sensitive documents, the company should be able to answer a few ordinary questions after the fact:

• Who used the system?
• Which documents or sources did it access?
• What did the user ask?
• What response did the system produce?
• Was that response copied, shared, exported, or used in a decision?
• Did a person approve any action that followed?
• How long are prompts, retrieved context, and outputs retained?

Without that record, the company is governing by assumption.

Auditability also gives different teams something concrete to agree on. Business teams want faster access to information. Security and compliance teams need accountability. Leadership needs evidence that the system is useful without creating hidden exposure.

The level of review should match the consequence of the task. A search across low-risk policy pages may need basic interaction logs. A system that summarizes contracts, retrieves customer records, or supports legal and financial decisions needs stronger records and clearer review ownership.

These controls also help teams find the source of a failure. Was the document outdated? Did retrieval miss the right clause? Did the user have access they should not have had? Was an action approved without checking the source? Without logs, those questions become guesswork.

For a wider review of these risks, see AI Agent Security Gaps You Need to Fix.

Keep people in control of high-risk actions

Document-connected AI often starts with search and summarization. Then the requests grow: draft a response, update the CRM, create a ticket, route an approval, send a message, or change a record.

This is where permission to read becomes permission to act.

OWASP describes excessive agency as a system having too much functionality, permission, or autonomy. Its guidance calls for human approval before high-risk actions.

That boundary needs to be designed into the workflow. For example:

• AI may summarize a policy, but a person approves any policy change.
• AI may draft a customer response, but the account owner sends it.
• AI may extract contract clauses, but legal or commercial owners verify them before a decision.
• AI may suggest a CRM update, but changes to sensitive account data require review.

The aim is not to insert an approval into every small task. It is to add friction where an error could affect a customer, a contract, money, regulated data, or a live system.

Pre-rollout checklist for sensitive document access

Before connecting generative AI to internal documents, validate these ten areas.

1. Document scope

Name the repositories, folders, systems, and knowledge bases included in the first release. Leave out sources that are disorganized, over-permissioned, or too sensitive for an early rollout.

2. User access

Confirm that the AI respects existing permissions, then test whether those permissions still reflect the user’s role. A technically correct permission model can still preserve years of bad access decisions.

3. Sensitive-data boundaries

Identify content that contains customer data, employee records, contracts, financial information, credentials, regulated information, or commercially sensitive plans. Decide what is allowed, restricted, and excluded.

4. Approved tools and connectors

Give employees a managed route for document work. A ban without a usable approved option usually pushes the same activity into tools the company cannot see.

5. Prompt, retrieval, and output logs

Decide which interactions are recorded, who may review them, and how they will be used during an investigation. Avoid collecting data simply because the platform allows it; every new log also needs protection.

6. Retention

Set rules for prompts, uploaded files, retrieved context, generated outputs, and conversation history. Retention should match the sensitivity and purpose of the use case.

7. Human approval

Mark the points where a person must review the result: external communication, legal or financial decisions, customer-facing updates, system changes, or work involving regulated data.

8. Escalation and fallback

Give users a clear route when the answer is incomplete, contradictory, or risky. They should know when to check the source, ask a subject-matter owner, or stop the workflow.

9. Pilot boundaries

Start with one defined use case, a small user group, and measurable criteria. Expand access only after the control model works with real users and real documents.

10. Ownership

Assign named responsibility across the business, IT, security, and any relevant compliance function. Shared involvement is useful. Shared accountability with no owner is not.

A safer rollout starts smaller than the ambition

Secure enterprise GenAI is not mainly a tool-selection exercise. The work begins with the workflow and the information around it.

A practical sequence is to map the document task, classify the data, review access rights, choose the approved tools, design logging and approval points, and then run a narrow pilot. Expansion comes after the team can show what the system retrieves, how it behaves, and where it still fails.

This planning creates value before a full build begins. It may reveal that a repository needs cleanup, permissions need repair, or a proof of concept is enough for now. That is useful evidence, especially when the alternative is connecting a production system to data the company does not fully understand.

For Itera Research, this work sits across Discovery, workflow mapping, proof-of-concept design, integration planning, and implementation. The question is not simply whether a company can connect generative AI to its documents. It is whether that connection improves the work while keeping sensitive information under control.

A company is ready when it can prove three things: the system sees only what it should, can do only what it should, and leaves enough evidence to explain what happened.