The Architecture · Spring 2026

Part 3 of 3. Also in the series: What Every Family Office AI Vendor Is Leaving Out and First Principles of Governance.

What this document is

Every AI vendor sounds similar on the surface. These questions are designed to find out what is underneath. They demand evidence, not explanations. Ask them in the room. Listen to what the vendor produces — or fails to.

The eleven questions

Question 01

Show me a single trust in your system. Where do its terms live — in the document, or in fields someone typed?

What this surfaces

Whether the governing instrument is the architecture the system operates on, or strings typed into fields about the instrument. A vendor whose trusts are records with fields will show you a tab with trustee names and effective dates. A vendor whose trusts are part of the operative architecture will show you the document itself, with its operative provisions made visible to every action that depends on them.

Listen forThe CRM-derived product reveals itself in thirty seconds with a Beneficiaries tab and a Trustees field. The document-management product reveals itself by opening a PDF in a folder. The architectural answer shows you the document with its provisions surfaced — the discretionary standards, the powers, the limitations — and tells you how those provisions govern every authority check the system performs.

The dodge to watch for: "We store the trust document and extract key data points into structured fields." That answer describes a database with attached documents. It does not describe a governance layer.

Question 02

Walk me through an assignment of an asset — say, an LLC interest moving from one trust to another — or an allonge to a family note. Show me what happens in your system.

What this surfaces

Whether the system captures ownership as architecture, with full provenance preserved across every transfer, or holds ownership as a field that can be edited. An assignment changes ownership, which changes authority, which changes financial reporting, which changes tax position. A vendor whose system handles this as a field edit will lose at least one of those cascades or have two that persist in different data silos, with nothing connecting them as one fiduciary event. The architectural test is whether the prior owner persists in an archived state, the transfer document links prior to new, and the new owner is captured as a consequence of the transfer. Every intra-family transfer adds to the chain; none of it gets overwritten.

Listen forThe product with an Assets tab will let the vendor edit the owner field and save — and the prior owner is gone. The document-management product will let them upload the assignment PDF as a separate file with no structural connection to either the prior owner or the new owner. Neither captures the chain. The architectural answer executes the assignment as a governed action with the full provenance preserved — the prior owner, the transfer document, the new owner — linked as one operative chain. The downstream consequences (authority chain update, financial reattribution, audit record) are captured as part of the same operation.

The dodge to watch for: "We have a workflow for asset transfers that updates the relevant records." Ask what happens to the prior owner. Ask how someone reconstructs the ownership history of one asset across three decades of intra-family transfers. The architectural failure surfaces in what is lost when the field is updated.

Question 03

If I revoke a trustee's authority on a specific entity, what happens to their access to documents and data tomorrow morning — and where in your system was that change made?

What this surfaces

Whether the dismissed trustee's contributions to the operative record stay with the office, or walk out the door with the trustee. The architectural test is what happens to the documents, decisions, authorities, and reasoning the trustee participated in. In a fragmented stack, critical records live in the trustee's email, the trustee's notes, the trustee's shared drive, the trustee's memory — and the office has to negotiate, request, or reconstruct what should have been operative all along. In the operative architecture, the trustee's access is cut off the moment authority is revoked, and every document, decision, authority, and reasoning the trustee captured remains intact as part of the office's record.

Listen forThe architectural answer describes what stays. The trustee's contributions are part of the operative record. The office does not lose history because a trustee was dismissed. The new trustee inherits the captured authority chain, the decision history, the reasoning behind exceptions — not a folder of PDFs the office had to chase down.

The dodge to watch for: "We have role-based access control that revokes permissions immediately." Cutting off access is the easy part. The architectural question is what the office keeps when access is cut off. A vendor whose answer focuses on the permissions change rather than the captured operative record is describing IT administration, not fiduciary architecture.

Question 04

Pick one decision your client made last quarter. Show me, in one record, the decision, the authority that allowed it, the reasoning, the wire that executed it, the financial statement entry, and any tax consequence.

What this surfaces

Whether the system captures the full chain from decision to tax consequence as one governed record. This is the integration question made falsifiable. A stack with decisions in one system, wires in another, financial entries in a third, and tax in a fourth cannot answer this in one record. A stack with a governance layer underneath can.

Listen forThis is the question every controller already knows the answer to for their current stack — "it does not work like that, we would have to pull it from four places." The vendor who can produce the artifact has the architecture. The vendor who explains why it would take a few days to assemble does not.

The dodge to watch for: "We integrate with our clients' accounting and tax systems so the data flows through." Data flow is not the same as one record. The question demands a single artifact that contains the decision and its full chain of consequences as one governed object, not a synthesized report assembled from multiple systems.

Question 05

Your senior administrator retires next month after fifteen years. What in your system makes her successor's first ninety days different from any successor's first ninety days?

What this surfaces

Whether what the retiring administrator knows lives in the system or only in her head. After fifteen years, she has carried the reasoning behind exceptions, the history of prior decisions, the family-specific patterns. The question is whether her successor inherits any of it, or starts from zero.

Listen forThe non-architectural answer is some combination of search, notes, and document storage — "the new administrator can search across all the documents and notes." Search is not architecture. The architectural answer describes what the successor inherits structurally: the decision history attached to the trust, the reasoning attached to the provision, the exception logic attached to the beneficiary class, all surfacing automatically when the situation recurs.

The dodge to watch for: "We make sure all the institutional knowledge gets documented in the system." The question is not whether documentation is possible; it is whether the architecture preserves the operative knowledge so it surfaces when the situation recurs. Documented-but-buried knowledge fails this test.

Question 06

When your AI agent recommends an action — a distribution, a wire, a filing — what does the human who approves it see, and what gets recorded?

What this surfaces

Whether the human approving the action sees what the AI based the recommendation on, or only the recommendation itself. The supervision the law requires can only be done against evidence.

Listen forThe vendor whose answer is "the human sees a clean approval screen" is describing the band-note problem — looks governed in the interface, ungoverned behind it. The architectural answer describes what the human sees (the proposed action, the authority basis, the reasoning, the relevant context) and what gets recorded (the action, the authority, the reasoning, the human's confirmation) as one contemporaneous record built in the moment of approval.

The dodge to watch for: "Every AI action requires human approval before execution." Approval is not the test. The test is what the human is approving against, and what the record looks like Monday morning when someone asks how the action was authorized.

Question 07

When your AI agent pulls data from another system or sends data to one, what does the audit trail look like? Show me one from last week.

What this surfaces

Whether every cross-agent communication gets recorded as a fiduciary action, or whether those calls are plumbing the governance layer never sees.

Listen forThe vendor whose answer is "our integrations are secure and authenticated" is describing technical safeguards, not architectural governance. The architectural answer produces the actual record — the agent's call, the data exchanged, the authority basis, the timestamp — as one auditable artifact.

The dodge to watch for: "We log all API calls in our infrastructure." System logs are not fiduciary records. The test is whether the call appears in the governance layer with its authority context, not in a log file the system administrator can pull on request.

Question 08

Your lawyer calls Friday at seven p.m. A trustee action has to happen by Monday. Your CFO is in Italy. Walk me through how that gets done in your system, and what the record looks like Monday morning.

What this surfaces

Three tests in one scenario. Whether the documents and authority chain are actually loaded as architecture, not just stored as files. Whether the system can produce a defensible trustee action under time pressure with the CFO remote. Whether the record gets built in the moment of action, or reconstructed after.

Listen forThe CRM-derived product will describe a workflow involving email exchanges, document attachments, and manual reconciliation Monday morning. The document-management product will describe DocuSign integration and folder organization. The architectural answer describes what the system already knows (the governing documents, the authority chain, the history), what happens in the moment (the action is surfaced with its authority basis for the CFO's confirmation from her phone), and what the record looks like Monday (the trustee action, the authority, the reasoning, the confirmation, and any cascade through downstream systems — all captured as one governed record).

The dodge to watch for: "Our mobile interface supports remote approvals." Mobile approval is the headline feature. The architectural test is what the CFO is approving against and what the record contains. A confirmation against an emailed PDF is not the same as a confirmation against the operative architecture the system already holds.

Question 09

Name three other systems in your client's family office stack — accounting, reporting, document automation, tax. Where do they get the family's entity structure from?

What this surfaces

Whether every tool in the stack reads from the governance layer, or whether each tool maintains its own version of the family's legal structure. The vendor who answers "we integrate with the client's accounting system" is describing parallel sources of truth synchronized by integration plumbing. The architectural answer is different: the other systems read from the governance layer for the family's structure, with the governance layer as the single source.

Listen forThis question surfaces what integration actually means. Bucket 1 vendors integrate by moving data between parallel versions of the structure. The architectural answer gives every system in the stack the same source. Reconciling parallel sources is not integration; it is maintenance overhead disguised as integration.

The dodge to watch for: "We have certified integrations with all the major family office platforms." Certified integrations are still parallel sources of truth that must be kept in sync. The architectural question is whether the other systems read from the governance layer, not whether they exchange data with it.

Question 10

If we adopt your AI architecture and discover in three years it was the wrong choice, what does it cost us to transition? Be specific.

What this surfaces

Whether the architectural decision is reversible. Earlier generations of vendor lock-in meant moving spreadsheets, contacts, and document archives. AI-era lock-in is different. The operative record produced inside an AI architecture — the decisions made, the reasoning captured, the institutional knowledge accumulated — cannot be cleanly extracted to a different architecture. Every year inside the wrong choice makes the transition cost higher.

Listen forThe vendor whose answer is "you can export your data" is describing data portability, not architectural portability. The architectural answer addresses what the family loses in a transition — the captured reasoning, the structured authority chains, the years of institutional knowledge built inside the vendor's specific implementation — and whether any of it survives the move.

The dodge to watch for: "Data portability is a standard feature." Data is not architecture. The question is whether the family's operative record — captured reasoning, structured authority, accumulated institutional knowledge — moves intact, or stays behind.

Question 11

What AI model does your system actually run on? If it is your own model, tell me how it was trained and what is in the training data. If it is a third-party model — Claude, GPT, Gemini, or another — show me the data processing agreement and the specific enterprise terms that govern training-data exclusion and retention.

What this surfaces

Which architectural pattern the vendor occupies, and whether they have done the work the fiduciary's duty of care requires. Some vendors use proprietary models trained on industry data — privacy risk is contained but the system cannot reason at the level a foundation model can, and the architecture's intelligence is bounded by what the vendor's training data contains. Some vendors use a foundation model under enterprise terms that exclude customer data from training — privacy is documented and verifiable, and the model's reasoning is constrained by the operative architecture the vendor has built. Some vendors use a foundation model without enterprise terms, with customer data potentially used to train future models, or have not examined the question. The fiduciary needs to know which.

Listen forThe vendor who runs a proprietary model will say "we do not use third-party AI services" or "your data never leaves our firewalls." Ask what their model can and cannot reason about, and how it handles questions outside its training distribution. The proprietary-model architecture is privacy-safe and reasoning-limited; the trade-off is real and the fiduciary should understand it.

The vendor who runs a foundation model under enterprise terms will produce the data processing agreement, name the specific training-data exclusion clauses, and confirm the retention period. The architectural answer is documented and verifiable.

The vendor who runs a foundation model without enterprise terms — or who cannot say which model they run on, or who has not examined the question — has not done the work. The dodge to watch for: "We're SOC 2 compliant and ISO certified." Certifications describe security at the vendor's application layer; they do not address what the foundation model provider does with the data the vendor's application sends. The fiduciary needs the actual terms, not the certification language.

How to use this document

Print it. Bring it to the next vendor meeting. Ask the questions exactly as written.

Three of the eleven questions are typically enough to surface the architecture of a vendor's offering. Questions 01, 04, and 08 are the highest-yield in a single meeting. They demand concrete evidence that vendors cannot produce on the fly. The other eight are available when needed.

The vendor who passes these tests will welcome them. The vendor who fails will deflect — to features, capabilities, roadmap items, or the offer to follow up with the technical team. The deflection itself is the answer.

This document completes a trilogy. What Every Family Office AI Vendor Is Leaving Out assessed the May 2026 market. First Principles of Governance articulated the architectural framework. Eleven Questions for Every Family Office AI Vendor converts the framework into operational use.

Register for the Roundtable