Where Your AI Runs Decides Who Sees Your Data

Every demo of an AI feature answers the same question: look what it can do. Almost none of them answer the question your security team will ask first: when someone types that prompt, where does the data go?

It is the right question. A prompt about your portfolio is not an abstract query. It carries land agreements, permit timelines, risk exposure, counterparty names — the information a developer least wants loose.

Before an AI feature is a feature, it is a data flow. Something leaves your system, travels somewhere, is processed on someone’s infrastructure, and comes back. The feature is what you see in the demo. The flow is what your security review has to approve.

Where your AI runs decides who sees your data.

This post explains the architecture decisions behind Navorda’s AI — and the questions we think you should ask any vendor that added AI to their platform, including us.

Every AI Feature Is a New Destination for Your Data

When a platform “adds AI”, your data acquires a new destination. Usually that destination is a third-party API on the public internet: the platform takes your records, wraps them in a prompt, and sends them to an external AI service.

There is nothing inherently wrong with that pattern — much of the software industry runs on it. But it changes the answer to “who can see my data”, and most vendors answer the follow-up questions with a policy page: a paragraph about the provider’s terms, a link to someone else’s privacy commitments.

Policies matter. But policies are promises, and promises can change with a terms update. The durable answer to a data-flow question is architectural: the flow either exists or it does not.

That is the standard we applied to Navorda’s AI: make the answer to “where does my data go” boring.

In-Region by Architecture: Bedrock in Frankfurt

Navorda’s data lives on AWS in Frankfurt, Germany (eu-central-1) — encrypted at rest and in transit, with hard multi-tenant isolation enforced at the data-access layer on every query.

Navorda AI — which continuously read your governed data and flag missing information, silent delays and growing exposure — run on AWS Bedrock in the same region.

That one sentence does a lot of work. It means the prompt never crosses the public internet to a third-party AI endpoint. Same cloud, same region, same security perimeter. The AI comes to where the data already is, instead of the data traveling to where the AI is.

For a European developer answering a GDPR-driven vendor questionnaire, this is the difference between a paragraph of explanation and a single line: the data stays in Frankfurt.

The full security posture — residency, encryption, identity, auditability →

IAM Roles, Not API Keys

The second question after “where does it run” should be “how does it authenticate”.

Most AI integrations authenticate with API keys — long-lived secrets that have to be stored somewhere, rotated by someone, and that keep working for whoever holds a copy. API keys leak. They get pasted into repositories, shared in chats, forgotten in configuration files. An AI integration built on a stored key is one leaked string away from someone else’s access.

Navorda’s Bedrock access uses AWS IAM roles instead: short-lived, scoped credentials issued by the cloud itself. There is no stored AI key to steal, because there is no stored AI key.

The same discipline runs through the rest of the platform. User sessions are 15-minute access tokens with rotating refresh tokens and reuse detection. The deployment pipeline authenticates to AWS through OIDC federation — no long-lived cloud credentials there either.

None of this appears in a product demo. All of it appears in an incident post-mortem — on one side of the story or the other.

Your Data Is Not the Training Set

The question every buyer now asks: does the AI train on my data?

For Navorda the answer is no, and — again — the reason is structural rather than contractual. Per AWS Bedrock’s standard commitment, prompts and outputs are not used to train foundation models and are not shared with model providers.

Your permit strategy in a prompt does not become part of anyone’s model. Your risk register does not improve a competitor’s autocomplete.

This is worth pressing any vendor on, because the honest answer depends entirely on which AI service sits behind their feature and on what terms. “We take privacy seriously” is not an answer. “Here is the inference provider, here is where it runs, here is its training commitment” is.

The Rule Engine Decides. The AI Explains.

There is a second kind of AI risk that gets less attention than data flows: decisions you cannot reconstruct.

If a model decides which projects are at risk, you inherit its failure modes — hallucinated urgency, missed signals, answers that change between runs. And when the board asks why a project was flagged, “the model said so” is not an answer a governance process can accept.

Navorda splits the job. Risk and deviation detection is a deterministic rule engine — transparent rules over governed data, the same input producing the same finding every time. The AI layer sits on top and does what language models are genuinely good at: turning findings into readable explanations and suggested mitigations.

Nothing about your portfolio is decided in a black box.

That boundary is a privacy property too, not just an explainability one. An AI that only explains needs less authority, less data and less trust than an AI that decides.

External AI on Your Terms

Everything above covers the AI inside Navorda. There is a second path: connecting your own AI — Claude, ChatGPT, or any MCP-compatible assistant — to your Navorda workspace.

That path has its own security architecture: the Navorda MCP Connector is read-only as a permanent product invariant, authorized per user with OAuth 2.1, disabled per organization until an admin enables it, and landowner PII is structurally excluded from every response.

Connect Claude or ChatGPT to your portfolio — read-only by architecture →

Bedrock inside, MCP outside — the corporate AI strategy argument →

Five Questions to Ask Any AI-Enabled Vendor

If you are evaluating any platform with AI features — Navorda included — these five questions separate architecture from marketing:

1. Where does inference run? In your cloud region, or across the public internet to a third-party endpoint?
2. Is my data training data? And whose commitment guarantees that — the vendor’s policy, or the infrastructure’s terms?
3. How does the AI authenticate? Stored API keys, or short-lived cloud-issued credentials?
4. Can the AI write? Or is it read-only by architecture, not by configuration?
5. Who decided? When something is flagged, can the vendor show you the rule — or only the model’s output?

A vendor with good answers will enjoy the conversation. A vendor without them will send you a policy page.

AI privacy sounds like a compliance topic. Architecturally, it is three decisions: a location (where inference runs), a credential model (how it authenticates), and a role boundary (what the AI is allowed to do).

Navorda’s answers: in-region on AWS Bedrock in Frankfurt; IAM roles, not stored keys; the rules decide, the AI explains — and external assistants read but never write. Your security team is welcome to test those answers against ours.

See it against your own portfolio — take the five-minute Corporate Distance Assessment →