EverythingAI Insights

How to connect AI to company data without giving it access to everything

hello@everythingai.me (Tanner Rusher) — Tue, 15 Sep 2026 00:00:00 GMT

The request is almost always the same sentence. “We want an assistant that can answer questions about our business.” The next sentence is where projects succeed or stall: what is it allowed to read?

There are two easy answers and both are wrong. Give the assistant broad access and you have created a data exposure problem with a chat interface. Give it nothing and you have created a more elaborate way to paste text into a box, which is the manual work the project was meant to remove.

The useful answer is narrower and more concrete. Connect the assistant to a defined set of sources, carry the requesting user’s existing permissions through to retrieval, and keep consequential actions behind a person.

Start from an approved source list, not a data lake

Every connection should be a decision someone made on purpose. Write down which systems the assistant may read, what each one contributes, and who owns it. A workable first list is short: an internal knowledge base, a document library, a ticketing or case system, a customer relationship management system, or a single line-of-business application.

Then write down what is excluded and why. Payroll records, protected health information, personnel files, and legal matter files are common exclusions, and the reason is usually a retention or disclosure rule rather than a technical limitation.

A source list does two things. It bounds what a review has to cover, and it gives you a place to record additions later instead of quietly widening access.

Carry the user’s permissions through to retrieval

The most important design decision is who the assistant acts as when it reads. There are three patterns, and they behave very differently.

Pattern	How it reads	Trade-off
Permission-aware retrieval	As the requesting user, with their existing access	Correct by construction; more work to build
Service identity with scoped access	As one application identity, reading a defined source set	Simpler; every user of the assistant can reach everything that identity can
Unscoped application access	As a broad identity, filtered afterward	Fast to prototype; the highest-risk option

The first pattern is the one to aim for. When the assistant searches on behalf of the person asking, and the underlying system enforces that person’s permissions, then a user cannot receive an answer built from documents they are not allowed to open. The security boundary stays in the system that already owns it, and access reviews follow the access reviews you already run.

The second pattern is legitimate when the source set is genuinely shared, such as published internal documentation or a product catalog. Be explicit about it. If the assistant uses one service identity, then anyone who can ask the assistant can reach whatever that identity can reach, and that needs to be an intentional decision rather than a side effect.

The third pattern is where most incidents come from. An over-privileged service account, an index built from everything, and filtering applied somewhere after retrieval. It reads well in a demo and badly in a review.

Retrieval scope is not the only boundary

Permissions answer “what may this person see.” They do not answer what the assistant should carry into a prompt, what it may write back, or what gets retained afterward.

Minimize context. Retrieve what the question needs rather than whole documents when the answer needs a paragraph. Less context is easier to reason about and cheaper to run.
Separate read from write. Reading approved sources and changing records of record are different risk levels. Start with reads and drafts.
Keep secrets out of prompts. Credentials, connection strings, and API keys belong in the application’s configuration or a managed identity, never inside a prompt or a shared template.
Retain deliberately. Decide what the assistant logs, how long it is kept, and who can read the logs. Logs frequently contain the sensitive material the access rules were protecting.
Test the boundary. Make a user who lacks access try to retrieve a protected document. If the attempt succeeds, the design has a gap regardless of what the diagram says.

Keep people in the loop where mistakes are expensive

A permission-aware assistant can still be wrong. It can summarize inaccurately, cite an outdated revision, or act on an instruction that was never authorized for it. The control for that is not a better prompt. It is deciding in advance which actions need a person.

A practical split:

Read and summarize: low consequence, no approval needed beyond existing access rules.
Draft: a person reviews and sends it. The assistant never sends on its own.
Change a record, spend money, or contact someone outside the organization: a named person authorizes it, and the authorization is recorded.

This is also where an assistant earns trust. People accept a tool that drafts well and hands control back. They do not accept one that quietly commits them to something.

Logging, testing, and rollback

Every connected workflow needs an answer to three operational questions. What is recorded about each interaction, so a problem can be reconstructed later? How is the workflow tested before it runs on real work? And how do you turn it off or reverse what it did?

For a first implementation, the honest answers can be short. A structured log of request, sources retrieved, and outcome. A small set of evaluation cases that must keep passing. A documented switch that disables the workflow, and a way to correct or withdraw an action it already took. What matters is that the answers exist before the workflow touches anything that matters.

What this costs you

Permission-aware retrieval is more work than connecting an over-privileged account. There is configuration in the identity provider, sometimes an application registration per source, and testing that mirrors real access differences. Expect the first workflow to take longer than a demo did.

In return, the security model stays where the organization already manages it, and the assistant does not become a new place where data accumulates. That is a much smaller surface to review, and a much easier one to explain to whoever asks how it works.

Where to start

Pick one workflow where the friction is obvious and the sources are known. Write down the approved source list, the identity the assistant will use, the actions that require approval, and the way the workflow is turned off. Then build the smallest version that respects all four.

If you want that boundary designed before anything is connected, the AI Opportunity Assessment is where to define it, and a controlled example workflow shows the shape of the result. If you would rather start with a conversation about your own systems and constraints, get in touch.

Why buying an AI subscription is not the same as implementing AI

hello@everythingai.me (Tanner Rusher) — Tue, 15 Sep 2026 00:00:00 GMT

Most organizations that ask EverythingAI for help have already bought something. A Microsoft 365 Copilot license, a ChatGPT or Claude team plan, or an AI feature bundled into a line-of-business application. The purchase went through, the seats are assigned, and the expected change in how work gets done has not happened.

That gap is normal, and it is not a training problem or a tooling problem. Buying a subscription gives you access to a capable model. Implementing AI means deciding which work should change, giving the model the right context under the right permissions, and making the result something your team can rely on. Those are different activities, and only the first one is a purchase.

What a subscription actually gives you

An AI subscription is capacity. You get a model, a chat interface, and a set of limits on how much you can use it. Depending on the product, you may also get an assistant embedded in the tools you already use.

That is genuinely useful, and it is enough for a category of work: drafting a first version of a document, summarizing something you paste in, explaining a concept, cleaning up a message. The model helps because a person is supplying the context from their own head and taking the output onward themselves.

The subscription does not know your customers, your pricing rules, your approval thresholds, your record structure, or which systems hold the current version of anything. It has no standing access to your files, and in most configurations it should not. It also cannot take an action in a business system, which is usually where the saved time would come from.

Where the work actually starts

Implementation begins with a different question. Not “what can this model do” but “which workflow, owned by which role, should produce a different result, and how would we know it worked.”

Answering that question produces a short list of decisions:

The workflow. One specific process with a clear trigger, a clear owner, and a visible outcome.
The evidence. Which sources must the model read to do this well, and who is already allowed to see them.
The boundary. What the model may read, what it may write, and what stays with a person.
The failure path. What happens when the output is wrong, incomplete, or unavailable.
The measurement. What changes for the team if this works.

None of those decisions come from the license. They come from looking at real work with the people who do it.

Why permissions decide the shape of the solution

The most common reason a pilot stalls is access. A promising workflow usually depends on information that lives in several places, with different owners, different retention rules, and different sensitivities.

There are two lazy answers and both are wrong. The first is to give the assistant broad access so it can find anything it might need. That converts a productivity project into a data exposure project and it usually fails review for good reason. The second is to give it nothing and paste context in by hand, which recreates the manual work the project was meant to remove.

The workable answer sits in between and is more specific. Scope the assistant to named sources. Carry the requesting user’s existing permissions through to retrieval, so a person can only reach what they could already reach. Keep credentials out of prompts and out of shared configuration. Require human authorization for actions with consequences, such as sending a message externally, changing a record of record, or committing money.

What implementation adds that the license does not

Subscription	Implementation
A model and a chat interface	A workflow connected to specific systems
Context a person pastes in	Retrieval from approved sources, permissions intact
Output a person copies somewhere	An action, or a draft a person approves
No record of what happened	Logging, error handling, and a rollback path
Usage growth depends on habit	Change measured against agreed success criteria

The right-hand column is engineering work. It is also the only column that changes how much time the workflow takes.

What good looks like at the end

A finished implementation is boring in the way good infrastructure is boring. The assistant reads from sources it is allowed to read. It answers or drafts consistently enough that people trust it for the narrow job it was given. When it is unsure, it says so, or it routes to a person. When it fails, somebody notices, and the failure is recoverable.

It also comes with the things an auditor or a new employee would need: a written description of what the workflow does, which identities it uses, what is logged, and who is responsible for the outcome.

Where to start

Do not start with the tool. Start with two or three workflows where the friction is obvious, the people involved can describe the rules, and the outcome can be measured. Then evaluate whether AI belongs in each one, what access it would need, and what a controlled first version would take.

That evaluation is what an AI Opportunity Assessment is for. It produces a prioritized recommendation and a roadmap you can act on, including the honest answer that a particular workflow should stay manual.

If you already own licenses and they are not changing anything, the missing piece is usually not another subscription. It is the workflow, the access boundary, and the decision about where a person stays in the loop.