Before AI Reads Your Business Files: A Data-Permission Checklist for MSMEs

An AI assistant that drafts product descriptions needs different information from one that answers finance questions. Giving both access to the same shared drive is a poor starting point.

For Indian MSMEs, a practical approach to AI data permissions for MSMEs starts with three questions: what information may the assistant use, for which task, and on whose behalf? Answer these before connecting business files—not after evaluating the first impressive response.

This checklist is recommended pre-pilot guidance. It does not establish that every product supports these controls, or that completing it provides legal clearance.

1. Define one task and its minimum data requirement

Write a single sentence: “The assistant may help [named team] perform [specific task] using [approved documents].” Avoid broad purposes such as “improve operations” or “answer anything about the business”; they make access decisions difficult to test.

Hypothetical example: A marketplace seller wants help drafting listing copy. The pilot could use approved product specifications, packaging instructions and brand guidelines. It need not include supplier bank details, customer order exports, marketplace credentials or employee records.

Define the allowed output too: draft copy for internal review, rather than automatic publication. For the first pilot, consider excluding actions such as sending messages, changing listings or updating accounts. Read-only access limits modification risk; it does not prevent confidential information from appearing in an answer.

Record: the task, intended users, document owner, allowed outputs and prohibited actions.

2. Create an explicit document allowlist

An allowlist names the files or folders the assistant may access. Prefer a dedicated pilot folder containing reviewed material to an entire connected drive with exclusions added afterwards. Verify that the connector can actually stay within that boundary.

Use a register like this:

These are suggested starting decisions, not universal classifications. A finance task needs a different boundary from a marketing task.

Decide who may add or replace files. A reviewed folder can stop being a reviewed dataset if additions bypass the owner. Check attachments, scanned pages, comments and hidden spreadsheet tabs—not just filenames. If the tool cannot restrict access to the approved collection, use a smaller reviewed upload or keep the pilot synthetic.

3. Separate permitted documents from restricted fields

A useful document may contain information the assistant does not need. Review fields as well as files.

Consider excluding these unless necessary for the defined task:

• Personal identifiers: customer names, phone numbers, delivery addresses, Aadhaar or PAN details.
• Financial details: bank account information, payment details, employee compensation and customer credit terms.
• Commercially sensitive fields: supplier rates, negotiated margins, unreleased prices and contract concessions.
• Secrets: passwords, API keys, access tokens and recovery codes. Keep these outside the pilot dataset.

Telling an assistant “ignore the bank details” is not a substitute for removing access to them.

Prefer a reviewed copy containing only permitted fields. Inspect the exported file itself, including hidden content and metadata where relevant. If a vendor offers masking or field-level controls, ask where those controls operate: before upload, during indexing, or only when displaying an answer. Do not treat hidden output as proof that the underlying data was excluded from processing.

Use synthetic data when the pilot only needs to test a workflow.

4. Review access for each named user

Microsoft’s Copilot security guidance explains that Copilot operates within existing permissions and access controls, and identifies oversharing as a risk. The practical lesson is to review inherited permissions before adding AI search or summarisation. This evidence concerns Microsoft Copilot; other assistants require their own checks.

For each pilot user, establish:

• Which approved documents may this person retrieve?
• Does access come through direct sharing, group membership, a broadly accessible link or a connector account?
• Are former employees, agencies or temporary staff still included?
• Does the assistant search as the individual user or through a shared service identity?
• Who can see conversation history, generated reports and exported answers?
• Who can upload files, add connectors or change settings?

Use named accounts rather than shared logins, and assign responsibility for adding and removing users. Record both the person and the identity used by the connector. If user separation cannot be verified, restrict the pilot to material every participant is permitted to see.

5. Ask retention questions across the full data flow

“How long do you keep our files?” is not enough. Ask the vendor to distinguish source documents, uploaded copies, extracted text, search indexes, prompts, answers, logs and backups.

Request written answers:

1. What is stored, and where? Identify relevant hosting locations, subprocessors and third-party connectors.
2. Which retention settings apply to our exact plan? Separate defaults from settings an administrator must configure.
3. What happens after deletion or disconnection? Which copies remain, why and for how long?
4. What survives account closure? Include backups, support records and audit logs.
5. Can legal holds or other retention obligations override deletion? Ask which exceptions apply.
6. How can we verify the configuration and deletion process? Request documentation or available administrative records.

Microsoft’s Copilot data-protection architecture documentation describes retention and deletion behaviour governed by configured Microsoft Purview retention policies. That supports checking the actual configuration—not assuming immediate deletion or a universal retention period.

Set an internal pilot end date and cleanup owner. Distinguish your requested deletion deadline from what the vendor contractually supports. Treat revoking future access and deleting stored material as separate items to verify.

6. Check the vendor, plan and connector—not just the brand

Ask for evidence relevant to the product tier and deployment you intend to use. A statement about one offering may not answer questions about another.

Save answers and configuration details with the pilot record, including the plan name and review date. Mark unanswered items as unknown, not as assurances. If an unknown affects confidential-data access, keep that data out pending clarification.

Where personal or confidential information is involved, arrange an appropriate review of applicable Indian legal and contractual obligations. Neither this checklist nor a security certification settles every permission question.

7. Test boundaries before using live business data

Use synthetic material first. Test what the assistant must not retrieve, not only what it should answer. For each test, record the user, setup, expected outcome, actual outcome and any follow-up needed.

• User separation: Give two named test users different document permissions. Ask each for information available only to the other.
• Field exclusion: Create a synthetic source sheet containing a clearly recognisable restricted value. Connect only its reviewed copy with that field removed, then check that the value is not retrievable.
• Revocation: Remove access to a test file and retry retrieval, accounting for any documented synchronisation delay. Separately inspect existing conversation history.
• Output sharing: Check who can open shared conversations and exported answers.
• Document instructions: Put a harmless instruction in a test document asking the assistant to reveal a separate restricted synthetic file. Check that document text does not override access boundaries.
• Disconnection: Revoke the connector and verify what stops working and what stored material remains.

Do not place real confidential information into the tool merely to test whether it leaks. Inspect both answers and cited sources. A refusal is not sufficient if its citation still exposes a restricted file.

A successful test is evidence of the behaviour tested, not proof of complete security. If a boundary fails, stop, narrow the scope or correct the configuration, then retest before introducing live data.

A copyable pre-pilot decision record

• [ ] One task, allowed outputs and prohibited actions are documented.
• [ ] Approved files or folders have named owners and an update process.
• [ ] Restricted fields have been removed or their exclusion verified.
• [ ] Named users, groups and connector identities have been reviewed.
• [ ] Vendor answers cover training, human access, retention and deletion.
• [ ] Permission, sharing and revocation tests have recorded outcomes.
• [ ] A named owner can stop the pilot and revoke access.
• [ ] A review date and cleanup responsibilities are assigned.

Proceed narrowly when the necessary boundaries are understood and tested. Use synthetic data only while material questions remain unanswered. Pause if the tool requires broad access you cannot constrain or exposes one user’s restricted material to another.

Before connecting your first folder, have the business owner and the person managing accounts complete this record together. The goal is a clearly bounded pilot—not the largest possible collection of connected files.