Read → Draft → Stage → Write

In short

“Should we connect AI to SharePoint?” is not one question. It is four, and they carry very different risk. The useful move is to classify the proposed integration before designing it, because each level needs everything the level below it needed and then more. Most disagreements about AI risk inside a business turn out to be disagreements about which level someone had in mind.

The four levels

Read

The system finds, retrieves or summarises information the person asking is already entitled to see. Summarising a project folder, answering a question from a policy library, pulling the last three status reports.

Read does not add write capability, but the integration identity and its permissions still need review. Confirm the retention position and stores in scope before enabling it.

The one trap is that read is only as safe as the permissions underneath it. A system that respects existing permissions faithfully will faithfully surface anything that was over-shared years ago and forgotten.

Draft

The system produces a proposed document, reply or answer for a person to accept, edit or reject. A drafted proposal, a suggested response, a first pass at a report.

Nothing changes in a business system at this level. The accountability question is the live one: the person who sends it owns it, and that needs saying out loud rather than assuming. Drafting can still become a deliverable if nobody sets the expectation for review.

Stage

The system prepares a change and stops, leaving it staged for a person to release. A queued CRM update, a prepared ledger entry, a pending record change.

This is where the design work starts in earnest. A staging step is only a control if there is a real queue, a named person who owns it, enough information presented for the decision to be meaningful, and an audit trail of what was released and by whom. A queue that one person clears at the end of the week without reading is not a control. It is a delay with extra steps.

Write

The system creates, changes, sends or executes on its own authority. No person in the path at the moment it happens.

The bar here is different in kind, not degree: least-privilege access scoped to exactly what the workflow needs, testing that covers the failure cases and not just the happy path, a rollback that has actually been run, a named operational owner, and an escalation path for when it goes wrong at 4pm on a Friday. A write-capable workflow should be defined narrowly and assessed against those controls before it proceeds.

Why classify first

The level sets the controls, design work and operational responsibility required before an integration proceeds. A read use and a write use therefore need different review questions and acceptance checks.

Without the classification step, a proposed read integration can expand into a write-capable workflow before its controls and owner are agreed. Naming the level in the first conversation keeps the scope and acceptance checks explicit.

It also makes the “not yet” answer available. Deciding to stay at draft for six months while permissions are cleaned up is a legitimate architectural decision, and it is much easier to make before anyone has built anything.

On “a human is in the loop”

This phrase does a lot of unearned work. It is a control only when the person in the loop has real information and real authority before the change happens.

If the system does the substantive analysis and a person clears a staged change without the context to disagree, the human is in the loop in the diagram and nowhere in the decision. That distinction matters for reasons beyond good practice: where a decision materially affects someone, a nominal review step does not necessarily change how that decision is treated.

Practitioner checklist

• Write down which of the four levels the proposed integration sits at.
• For read, audit the permissions on the source before enabling anything.
• For draft, state in writing who owns the output once it is sent.
• For stage, design the queue: owner, information presented, audit trail, and what happens when it backs up.
• For write, require least privilege, negative testing, a rehearsed rollback, a named owner and an escalation path.
• Check whether a capability you already own does the job before building one.

The pattern

Classify before you design. The level sets the control, design and acceptance checks, and the review may conclude that Read or Draft is the appropriate boundary for the proposed use.

Next step