Observability. Our client finished their demo with the prospect, and we were ready for security and compliance, but they started here instead.

Observability belongs in the first architecture.

What does an enterprise architecture team actually ask when you put something new in front of them for the first time?

I got the answer again recently, sitting with the architecture group at a company north of ten billion dollars in an engagement we are now proceeding with, and the answer arrived before the demo did. The first substantive question in the room was about the boundary - how the connectors work, and how they control what information leaves their estate - and it came from the director whose mandate this year is driving AI adoption. The person in the room who wanted the technology most was the person who asked about egress first, and I think that ordering tells you almost everything about how enterprise AI is bought right now.

The Approach

Before anyone opened a screen, the three people on the other side described their own remits, and taken together those descriptions read as a requirements document.

The executive who runs central IT told us that in the context of AI, his responsibility is enterprise AI governance and observability - those two words, joined, as a single function. The principal enterprise architect reporting to him described his live initiatives as containerization, multi-cloud architecture, and the AI governance work around security and visibility. The director in the architecture team wanted to measure the value the business is getting from the tools it has already bought.

Governance and observability now sit inside the same job description at large enterprises, and that one organizational fact explains more about how these decisions get made than any budget cycle does. When the same person owns whether you are allowed to run and whether anyone can see what you did, those two questions get asked as one question, and the architecture has to answer them as one answer.

The question set

Here is what they asked, in roughly the order they asked it:

How do the connectors work, and how do we control what information leaves our estate?

How are the integrations set up, what kind of logs do you produce, and how are you gaining that access?

What level of access do you need to each platform, and where does that data get stored?

Does this run on an individual basis, or at service account level?

How is that score calculated, and what makes it only eighty-nine percent confidence?

How do you handle a system you have no integration for, and how do you keep up as those systems expand what they expose?

Six questions, and every one of them is an observability question. The feature set went almost entirely undiscussed, and the capability itself was accepted quickly once it was seen. What consumed the room was the boundary and the trail - what crosses the line, under whose identity, leaving what record, stored where.

I have come to treat that list as the real specification, because it is the same list every time, asked in slightly different words by people who have never met each other.

Explainability is an observability problem

The question I keep thinking about is the fifth one. A derived number appeared on screen, and the immediate response was to ask how it was calculated and why the confidence sat at eighty-nine rather than higher.

That is an observability question pointed at the reasoning rather than at the network, and it is the one most teams are unprepared for. An enterprise architect looking at a computed output needs to see the inputs, the weighting and the method, in plain terms, on demand. The answer that day was a weighted blend of six named behavioral signals with the formula visible in the interface, and I would argue that answer is what kept the meeting moving. A number that can show its own derivation survives review. A number that arrives as an assertion becomes the thing procurement stalls on for a quarter.

If your product computes anything, treat the derivation as a logged, inspectable artifact with the same seriousness you treat an audit event.

Telemetry is a maintained surface

The last question in that set deserves more attention than it usually gets. A major model provider had expanded its available telemetry fields the day before that meeting, and the architects wanted to know how a vendor keeps pace when the systems being measured change what they expose on a weekly basis.

Integrations are usually designed as a fixed set and shipped as a feature list. What the enterprise is actually buying is a maintained surface - field-level selection they control, a way to add a source they have that you have never seen, and a version story for when a provider doubles its available signals overnight. Design the connector layer as something that gets extended by configuration rather than by release, and that entire line of questioning turns into a short answer.

Why the sandbox is the right first structure

We proposed a controlled pilot inside their own cloud tenant, on a defined population, and the response was immediate agreement followed by two refinements - name the target population precisely, and define how it gets controlled.

That is the shape I would now design toward before anyone asks for it. A pilot inside the customer's own tenant converts every abstract security question into an observable fact: the identity the workload runs under, the destinations it is permitted to reach, the log stream it emits, the storage location and retention of anything it holds. The architecture conversation that gets deferred until legal paper is in place becomes concrete the moment there is a running boundary to point at, and the evidence a governance function needs to approve a wider deployment gets produced by the pilot itself rather than assembled afterward from memory.

Building to the sandbox also disciplines the engineering. When you know the first deployment lands inside somebody else's estate, under their identity model, emitting to their observability stack, you make different decisions at the first line of architecture - open telemetry standards over proprietary logging, declared egress over ambient network access, service-level identity over borrowed credentials, and derived outputs that carry their own provenance.

The broader shift

Every AI capability sold into a regulated enterprise from here forward will be evaluated by a function whose charter is governance and observability together, and that function decides on evidence rather than on demonstration. The demo earns the meeting. The trail earns the deployment.

What I expect to see over the next several cycles is a widening gap between products that treated observability as a shipping release and products that treated it as the first architectural commitment. The first group spends its sales cycle retrofitting, answering questions in slide decks that should have been answered in log streams, and losing months to security review it could have spent in production. The second group walks into the room with the answers already running.