Most class projects end when the assignment is done.

This one did the opposite.

I was taking an AI product management class, and the brief was simple enough: use AI tools to design, build, and deploy a working app. It was meant to be practical. Pick a problem, make something real, and show that you could move from idea to execution.

I could have chosen something safe and generic. A scheduling helper. A simple productivity tool. A tidy little workflow app that would meet the requirement and be easy to explain.

Instead, I picked a question I had already been thinking about:

How do you talk about data sovereignty in a way that goes beyond a region label on a dashboard?

That question turned into a sandbox project I called GeoGuard.

The app was useful. Building it taught me things. But the app is not really the story.

The story is what the exercise exposed.

Once I started trying to turn this topic into something concrete, I ran into a distinction that I think a lot of companies still blur together.

We are reasonably good at talking about where systems live.

We are much less prepared to prove where traffic actually went.

That gap matters more than people admit.

The Class Project Was Just The Entry Point

On paper, the class assignment was about AI-assisted building. In practice, it became a forcing function. It pushed me to stop discussing this issue in the abstract and start asking what a real tool would need to say, show, and justify.

That changed the kind of questions I asked.

Not "What would sound right in a slide deck?"

Not "What answer would make the conversation go away?"

But "What could I responsibly claim if someone asked me to prove it?"

That is a very different standard.

It is one thing to say a workload is hosted in a specific region. It is another thing to demonstrate, with confidence, where data moved while that workload was being used, what boundaries it may have crossed, and what evidence supports the claim.

For a lot of teams, those still get treated like the same problem. They are not.

Where The Conversation Usually Breaks Down

This is where I think many enterprise conversations become too simple.

Someone says:

• "The workload is in-region."
• "The data stays in-country."
• "We picked the compliant cloud region."

Those statements are not useless. In many cases, they are part of a good answer. But they are often treated as if they are the whole answer.

They usually address where something is hosted or stored.

They do not automatically answer questions like:

• What path did traffic take?
• What jurisdictions did it pass through?
• What systems handled it along the way?
• What proof could you provide if a customer, auditor, or regulator asked for more than intent?

That is the part that stayed with me after the class project.

The deeper issue is not whether teams care. Many do. The issue is that the evidence standard is harder than the planning standard.

It is relatively easy to choose a region. It is much harder to prove the full story of movement.

Building The App Made The Limits Obvious

That was the most valuable part of the project for me.

The moment you try to build even a rough tool around boundaries, traffic, and evidence, the comfortable shortcuts disappear.

You have to decide what the tool can actually support.

You have to ask:

• What can the available data really tell me?
• What is a strong signal versus a weak hint?
• Where does confidence end and guesswork begin?
• What would I be comfortable putting in front of someone who wants evidence, not marketing language?

That last question matters a lot.

One of the fastest ways to lose trust on a topic like this is to overstate what you can prove. If the evidence only supports a partial answer, then a responsible system should say so. It should not pretend uncertainty has disappeared just because the interface looks polished.

The class project made that impossible to ignore.

What started as an assignment quickly became a reminder that architecture intent and evidence-backed proof are not the same thing. Good intentions are still important. Smart design decisions still matter. But if the claim is about where data actually traveled, then the standard has to be higher.

The Bigger Lesson Was Not About AI

The assignment was framed around AI, and AI absolutely helped with speed.

It helped me move faster from rough idea to functioning prototype. It made it easier to explore the shape of the problem, test assumptions, and get something working without spending weeks on setup.

But the bigger lesson was not "AI makes building easier."

It was that once building gets easier, weak assumptions get exposed faster.

That is a good thing.

When the cost of prototyping drops, you can stop hiding behind theory. You can take the big statement, the half-formed idea, or the comfortable industry phrase and see whether it survives contact with an actual product, actual inputs, and actual edge cases.

That is what happened here.

I started with a class requirement.

I ended up with a sharper question than the one I began with.

Why This Matters Beyond A Classroom Project

This is not just an academic issue, and it is not just a niche concern for specialists.

If you work anywhere near cloud, security, compliance, enterprise architecture, or customer trust, this gap is going to keep showing up.

Customers want clearer answers. Regulators want stronger accountability. Internal teams want to reduce risk without pretending certainty where there is none.

That means the conversation has to mature.

It is not enough to say where the workload lives and assume that settles everything. In many situations, that is only the opening answer. The harder and more important follow-up is whether you can show what happened in transit, what you know, what you do not know, and how strong your evidence really is.

That is the conversation I want to keep exploring.

GeoGuard will keep showing up, but mostly as a lab instrument. It helped me surface the problem, not solve it once and for all. The app was the setup. The real story is the gap it revealed between storage and movement, between confidence and proof, and between saying something should stay within a boundary and demonstrating what actually happened.

That is the thread I am pulling on next.

The next post will start with the distinction that sits underneath all of this:

Data residency is not the same thing as data in transit.