Where does your data go, and what can the AI touch? Tool access as a boundary.

In short: The data question is really two questions. Where processing happens is your vendor’s answer. What the system may touch is yours to design, per tool, with read and write kept apart.

As soon as things get concrete and an AI operator is meant to do real work, this question arrives reliably. It is the last hurdle before a decision, and it is a fair one.

It does contain two very different questions that almost always get mixed together. The first is: where is my data processed, and by whom? The second is: what is this system actually allowed to touch inside my company? The first is a vendor question. The second is a design question, and it belongs to you.

Where your data sits is answered by your provider. How much damage is possible is answered by your own architecture.

The vendor question: important, but not your only lever

The first question deserves diligence: who processes, on what legal basis, for how long, and what happens to what you put in. That is the review every company runs on every service provider, and AI services are held to the same standard as anything else.

Rocket Routine OS is deliberately built provider-agnostic here. The language model is the execution engine inside the system, not the product. Which provider runs underneath is the client's choice, and that choice can be changed without the governance above it changing. That matters because it keeps you independent: your governance does not hang on one vendor's terms.

What I am deliberately not doing here is giving you a compliance answer. Hosting, data processing agreements and the actual legal assessment belong in a contract, not in a blog post.

The real question: what can the system touch?

The second question gets asked less and decides more. Even with flawless processing, the risk is unchanged if an operator can reach everywhere inside the company.

That is what the Role Contract is for. One of its eight mandatory components is the tool access policy: read and write boundaries, defined per tool, on the least-privilege principle. Not "has access to our systems", but per system and per direction.

The distinction between reading and writing is the most important cut in this whole topic. An operator that may read a source can derive something wrong from it, and that surfaces in quality confirmation. An operator that may write changes the state of your company. So write access is the exception that gets justified, not the default.

Read access produces bad drafts. Write access produces facts. Only one of those has to be undone.

The principle runs all the way into the roles. A Knowledge Persona has read access to exactly one assigned knowledge source, no write access, no decision rights. It speaks, it does not decide.

The most common mistake in practice is not recklessness but convenience. Granting account-level access takes five minutes; scoping a clean slice takes half an hour. So the operator gets the whole mailbox instead of a folder, the whole drive instead of a project. That half hour is the cheapest insurance in the entire undertaking, because it bounds the damage before there is any. And it only has to be spent once per role.

Access is a stage, not a switch

The same thing holds here as for responsibility generally: access is not granted on day one, it is earned. Through the Adoption Levels the room to act grows with measured quality, and it shrinks again when the evidence weakens.

That makes the access question answerable without deciding it once and forever. You start with reading and drafting, watch across several runs whether the quality meets the standard, and only then widen the scope. Doing it the other way round, starting with full access, is not governance. It is luck.

Company 0: the concrete cut

For our content operator it looks like this. It may read the knowledge base and the editorial calendar. It may write drafts, in two languages, a full set every week. It may not publish.

Write access to the CMS only opens once a human has reviewed and approved the text. That is not a matter of trust, it is the construction, and it is the reason a mistake in this operation costs a paragraph rather than a publicly visible false statement.

The cut is instructive because it shows how narrow access can be without making the role useless. The operator produces an entire week of output. It still cannot put any of it into the world.

What this means for you

If you want to settle the access question for your company, a four-column table is enough, and you do not need anyone external for it:

• Which system? One row per tool, not "our IT".
• Read or write? And if write, why is read not enough?
• Which slice? A folder, a project, a calendar, not the whole account.
• Who notices if something wrong gets written, and how fast?

Those four columns are a tool access policy. If you can fill them in for your first role, the data question suddenly gets much smaller, because the possible damage was bounded in advance. And if you cannot fill them in, that is the real answer to whether you are ready.

Frequently Asked Questions

What is a tool access policy?

A mandatory part of the Role Contract: read and write boundaries, defined per tool, on the least-privilege principle. Not "has access to our systems", but set per system and per direction.

Why does the difference between read and write access matter so much?

An operator with read access can draw a wrong conclusion, and quality checks catch that. An operator with write access changes the state of your company. That is why write access is the justified exception rather than the default.

Where is my data processed with an AI Operator?

Your vendor answers that, not the operating system. Rocket Routine OS is deliberately provider-agnostic: the client decides which language model runs underneath, and that decision can change without the governance above it changing.

How do I start setting access boundaries?

With a four-column table: which system, read or write, which slice, and who notices if something wrong gets written. If you can fill it in for your first role, you have a tool access policy.

Want to build this in your own company?

Rocket Routine OS is the operating system behind these articles: roles, decisions and routines that hold up when AI does part of the work. It is not public yet. Join the waitlist and you get access first — plus a fortnightly, honest account of what is working and what is not. Join the waitlist