When you sell into regulated industries - healthcare, financial services, automotive, education - your customer's compliance team will ask for your architecture diagram. The real question is which one you give them.

Most AI startups own two architectures whether they admit it or not. There is the one on the pitch-deck slide: event streaming, a purpose-built vector database, a dedicated recommendation service, a streaming consent pipeline. And there is the one actually deployed: a leaner stack that does the same jobs with fewer moving parts. A few weeks ago I argued that engineering teams should write both versions of that story into the PRD and keep the gap honest. This is the same discipline pointed in the opposite direction - at the buyer's compliance desk instead of your own roadmap.

Get the two confused in front of a regulated buyer and you lose either way. Send the north-star diagram and you are now defending a system you have not built; every probing follow-up lands on infrastructure that does not exist yet, and the audit either stalls or catches you over-promising. Send nothing and you look like a vendor who cannot describe its own data handling. The honest, winning move is to separate the two artifacts on purpose and lead with the one that answers the question in front of you.

The compliance team's actual question

Buyers' security and privacy reviewers are not grading your ambition. They are answering three questions on behalf of their own organization, and all three are about the present tense:

Where does our data physically live? Which region, which provider, which database, and is it isolated from other customers or pooled?

Who can see it? Not just which humans and which roles, but - and this is the new part - which model context. When their records flow into a prompt, what leaves their tenant boundary and what does not?

What controls are enforced right now? Consent capture, retention limits, deletion on request, access logging. Enforced today, in the running system, not scheduled for a future sprint.

Notice that none of these is answered by a diagram of where you are going. They are answered by a diagram of where you are. The normative architecture is the wrong document for this conversation, and handing it over is not generosity - it is a category error that turns a fifteen-minute review into a three-week interrogation of vaporware.

How the split lets you answer honestly

The shipped/normative separation solves a problem that is as much psychological as it is technical. Founders resist showing the current-state architecture because it looks less impressive than the vision. So they show the vision, and then spend the audit walking it back one caveat at a time. That backpedaling is what reads as under-secured - not the architecture itself.

When you commit to the current-state diagram as the artifact of record for compliance, the dynamic inverts. You are no longer defending a promise. You are describing a fact. "Here is exactly where your data sits today, here is exactly who touches it, here is exactly what is enforced." Precise beats impressive in a security review every time, because the reviewer's job is to find the gap between what you claim and what you run. Close that gap to zero by only claiming what you run, and there is nothing left to find.

This also protects your roadmap. The normative architecture is competitive information - it signals where the product is heading and how you intend to scale. You do not owe that to every buyer's third-party risk vendor. Keeping it as a separate artifact means you can share the current-state picture freely and reserve the forward-looking one for the moments it actually matters.

The three diagrams every B2B AI vendor needs

Concretely, current-state transparency is three diagrams, each answering one of the buyer's three questions.

The first is the current data flow. Where records enter, where they are stored, where they are processed, where they leave. For an AI product this has to show the retrieval path explicitly: raw data lands in Postgres, embeddings live in the same instance under pgvector, and the model receives a scoped, tenant-filtered context assembled at query time. If a reviewer cannot trace a single record from ingestion to model prompt on your diagram, the diagram is not finished.

The second is the current control plane. Who authorizes what, and where that authorization is enforced. The load-bearing detail for regulated buyers is that authorization happens server-side on every request, scoped by tenant, and never trusts a client-supplied token to decide what a user may read. Multi-tenancy is a property of this diagram, not a footnote - every query, every embedding lookup, every inference carries the organization boundary with it.

The third is current consent enforcement. This is the one traditional software vendors underbuild and AI vendors cannot afford to. It shows how a consent decision - captured once - propagates to every downstream use: which processing is permitted, which modeling is permitted, what happens when a user withdraws, and how the system proves after the fact that it honored the choice. In an AI product, a missing consent check is not a UI bug; it is an unlawful processing event with an audit trail that now works against you.

The fourth diagram, and when to share it

The normative architecture is the fourth diagram, and it has a place - just not this one. Share it when a buyer asks the forward-looking question directly: "where is this going as we scale," "what does your architecture look like at ten times this volume," "what is on your security roadmap." That is a strategic conversation with a sophisticated counterparty, and the normative diagram is exactly the right answer there. The discipline is simply not to volunteer it as the answer to a current-state question, where it creates risk instead of confidence.

Diagrams are necessary, documents are the proof

Diagrams describe the system. Documents prove you operate it. Any serious AI vendor selling into regulated industries should ship with seven of them: a Privacy Policy, a Data Processing Addendum, an AI Governance Program, an AI Impact Assessment, an ADMT (automated decision-making technology) consumer notice, an Incident Response Plan, and a Data Retention Schedule. Together they turn "we take security seriously" into a set of artifacts a reviewer can actually read, and they answer the questions a diagram cannot - how long you keep data, what you do when something breaks, and how you govern the model itself.

"Just give them a SOC 2"

The common objection is that a SOC 2 report should end this whole conversation. It does not, and it was never designed to. SOC 2 attests that you defined a set of controls and operated them over a period. That is necessary, and mature buyers will ask for it. But a SOC 2 report says almost nothing about the questions that are specific to an AI system: what crosses the LLM context boundary, how vector storage is isolated per tenant, whether cross-tenant leakage is structurally impossible or merely unlikely. A modern AI vendor questionnaire exists precisely because SOC 2 stops short of those questions. Treat the report as table stakes and the architecture diagrams as the actual answer.

The checklist

If you want to get ahead of the questionnaire, here is what a compliance team is really asking for:

A current-state data-flow diagram that traces one record from ingestion to model prompt.
A statement of data residency: region, provider, and tenant isolation model.
Server-side, tenant-scoped authorization - described, not assumed.
An explicit account of what does and does not enter the model context.
Consent capture, propagation, withdrawal, and proof of enforcement.
A data retention schedule with real timelines and a deletion path.
The seven governance documents, ready to send, not "in progress."

Build these once and the security review stops being the thing that stalls your deals and starts being the thing that closes them.

What is the hardest compliance question a buyer has ever put to you? I collect the good ones - they tend to become the next diagram.

Bryan Guy, J.D. is the Founder and CEO of DataBillity, Inc. (dba Billity AI), building multi-tenant, retrieval-first AI infrastructure for regulated industries.

Hashtags for the article: #DataArchitecture #AIGovernance #MultiTenant #PrivacyTech #AIEngineering #DataInfrastructure

Shipped vs. Normative: The Architecture Answer Regulated Buyers Actually Need