Every AI vendor selling to a regulated organization says the same sentence in the conversation about data protection: with our architecture, you are compliant. The technical half is usually true. The problem is that compliance is not a property of the software, it is a decision about the processing.
This piece sits here in the series because running in the client's own environment turns part of the legal question into an engineering question, and because it is worth separating what that shift reaches from what stays with the organization.
The difference between reducing surface and being compliant
Processing inside your own infrastructure takes one class of problem off the table, not all of them. The exception comes before the advantage. The opening piece in this series already covered what happens to a flow pointed at an external provider. What belongs here is the rest of that sentence: the exit does not only change the network route, it changes the legal framing of that processing. That stretch of the work now involves a third party, with its own contract, with a purpose that has to be covered, and, if the processing happens in another country, with a cross-border transfer rule attached. In many cases the exit is the right call, with content that is not confidential, on a task where model quality decides the result, with a provider legal has already cleared. What it does not do is move that processing out of your accountability.
With that said, two questions change in nature. Cross-border transfer now depends on where the client's infrastructure sits, and not on the route the vendor picked. The list of who touches the data can now be compiled from the inside, instead of depending on what the vendor declares. Both are questions the organization can answer on its own.
None of that makes the processing legitimate. An organization can process inside its own walls exactly the data it would not be allowed to process anywhere. Data protection law does not start by asking where the server is. Whether the regime is the LGPD, the GDPR or another, it starts with the purpose of the processing, and architecture does not answer for purpose. If a vendor's answer claims the decision is already made, that is a sales pitch.
What remains the organization's work
A piece that stopped at the previous section would be advertising. There are at least three fronts that installing in the client's environment does not resolve, and one of them exists precisely because the installation happens there.
Authorization. Purpose, authorization and minimization come before the software. Running in your own environment does not authorize processing what could not be processed anywhere. The question is who authorized each body of content, not who managed to index it.
Life cycle. Retention, deletion and responding to requests from data subjects remain the organization's obligation, and they get harder with AI in the middle. The question is what happens to whatever was derived from the document, the passage that entered an index, the vector that represents that text, the history of the conversation that quoted the content. No vendor answers that by installing something.
Running the infrastructure. The duty to put security measures in place, and to answer for them, stays with the organization when the infrastructure is the organization's own. Part of what a cloud vendor used to evidence through reports and certifications now has to be evidenced by you, from your own environment. An organization without an infrastructure team can end up with worse protection than a well run third party environment would have given it, and it remains the party answerable for that protection. What running it costs as routine work is the subject of the third piece in this series. Here the point is narrower: installing in your own environment moves the responsibility, it does not remove it.
When the demand comes from outside the organization
Someone asks about those fronts, and not always the team that bought the system. In the public sector the question of how a decision was made arrives before the question of how good the answer is, and it arrives from outside the project, from an oversight body, from internal audit, from the citizen whose request was denied. That adds requirements to the ones about quality, it does not replace them. Beyond knowing whether the answer is good, the agency needs to know whether every query leaves a record and which body of material supported a specific output.
Neither of those can be settled after the fact. They surface with the project already in production, when answering means reconstructing what nobody recorded. That is why they belong to the design stage, and the design stage closes before the proof of concept opens.
What to ask before the proof of concept
These questions apply to any vendor, ourselves included:
- Which data leaves my environment in normal operation, which leaves by my own choice, and how do I see that difference before approving it?
- If I have to delete one person's data, what happens to the indexes, the vectors and the histories derived from it?
- Can I show afterwards which body of material supported a specific answer and who had access to it?
- At what point does a person have to approve before the system produces an effect on someone?
- What on this list comes installed, and what remains my own design work?
The fifth is the one that does the most damage to a sales presentation, because the honest answer to it tends to be long.
What the architecture changes about the question
Running in the client's environment moves the legal question, it does not answer it. Where the question used to be what the vendor does with the data, it becomes what the organization decided to process, for what purpose, and with what record. It is a better question, because the party obliged to answer it also holds the means to do so. It is not an easier one, and the architecture decides it for nobody.
Along with that control comes the work that used to be bundled into a cloud vendor's contract. You take on roles that belonged to someone else, and you take on the cost of keeping them. The fifth piece in this series deals with that cost and with the billing model it imposes. The sixth deals with what keeps running when the contract ends.