Turning On an AI Tool Is a Scoping Decision

he AI conversation and the compliance conversation usually happen in different rooms.

In one room, somebody is evaluating platforms, running a pilot, counting license costs, and fielding requests from people who want access. In the other, somebody is maintaining a document that defines exactly where regulated information is allowed to live. Whether that document is a system security plan, a HIPAA risk analysis, or a PCI scope diagram, the problem is the same. Those two rooms need to talk before the pilot goes wide, and in most organizations they talk afterward.

Here is the mechanic that makes it matter.

Under NIST SP 800-171, your assessment scope is defined by where controlled unclassified information is stored, processed, or transmitted. Everything inside that line has to meet 110 requirements. Everything outside it does not. Scoping is the single highest-leverage decision in the whole framework, because it determines how much of your environment you are on the hook for.

An AI assistant sitting by itself, with no connection to anything, is a chat window. It is also nearly useless, which is why nobody leaves it that way. The value shows up when you connect it: to the document library, the file shares, the ticketing system, the data warehouse, the mailbox. Every one of those connections is a path along which controlled information can reach the tool.

So the moment you wire an enterprise AI platform into your content, you have made a scoping decision. The only question is whether you made it deliberately.

The setting everyone asks about is the wrong setting

The first question in most AI vendor reviews is whether the vendor trains on your data. It is a reasonable question and the answer is almost always no for enterprise tiers.

It is also the smaller issue. Training is about what the vendor does with the data. Scope is about where the data is, which jurisdiction's rules apply to the infrastructure holding it, and whether that infrastructure carries the authorization your contract requires. A vendor can be entirely honest about not training on your content while hosting it somewhere that puts you out of compliance.

For defense contractors this gets sharp fast, because the accredited environments and the good AI tooling have not converged. Plenty of capable platforms are unavailable in the government cloud, or available there a year behind, or available with the integrations stripped out. That gap creates real pressure to put controlled work into the commercial tenant because that is where the tool people actually want to use lives.

The answer is a boundary you draw on purpose: the AI capability on one side, the controlled information on the other, and a technical barrier between them rather than an instruction.

Same mechanic, different rulebook

I have been writing this from inside 800-171 because that is the environment I work in, and because it defines scope more explicitly than most frameworks do. The mechanic generalizes to every regime that draws a line around a category of data.

Under HIPAA, a vendor whose system processes protected health information is a business associate, which requires an agreement in place before the connection exists. Wire an AI assistant into a system holding ePHI and you have created that relationship, whether or not anyone signed anything. Some enterprise AI vendors will execute a BAA at certain tiers. Several will not, and finding that out after the pilot is an expensive sequence.

PCI DSS is the closest structural parallel. The cardholder data environment is a defined scope, and systems connected to it fall inside that scope. Connecting an AI tool to a system that touches cardholder data pulls the tool in, along with the requirements attached.

Privacy regimes get at it differently but arrive at the same place. Connecting an AI platform to systems holding personal data creates a new processing activity, with questions attached about purpose, retention, cross-border transfer, and what has to appear in your processing records.

Different rulebooks, same underlying question: what did this tool just get access to, and which rules follow the data into it.

Policy is not the control

Most organizations address this with a line in an acceptable use policy telling employees not to put controlled information into AI tools.

That is a control implemented by several hundred people remembering something under deadline pressure. Technical enforcement is a control. Tenant separation, connector restrictions, data loss prevention on the paths that matter, conditional access on the tools themselves. Those hold when somebody is tired at 6pm and the tool is right there.

Write the policy anyway, because you need it and an assessor will ask for it. Then build the thing that makes the policy true.

Three questions before the pilot goes wide

What can this tool reach? Not what it is licensed for. What it is actually connected to, today, and what a user can connect it to without asking.

Where does the content live and process? Which cloud, which region, which authorization. Get it from the vendor's compliance documentation rather than the sales conversation.

Which side of the boundary is this on, and how is that enforced? If the answer involves the word "should," you have a policy where you need a control.

Answer those before deployment and the AI program and the compliance program stay in the same building. Answer them after, and you will be rewriting a scoping document to describe something that already happened.