Build, Buy, or Steward
The decision is not just whether to build or buy. It is who will own the architecture, controls, maintenance, and exit over time.
Photo: Ron Lach / Pexels
Buy when a governed product meets the requirement. Build when a differentiated workflow and internal capability justify custom ownership. Steward when the family wants a tailored, portable environment but needs a long-term technical and governance partner to operate it alongside the office.
Choose the operating model before the model provider.
Model performance changes quickly. The slower and more consequential decisions concern data ownership, integrations, permissions, review, maintenance, staffing, and exit.
A purchase can be the disciplined choice when the work is common and bounded. A custom build can be justified when the family has unusual data, workflow, or deployment requirements and the team to maintain them. Stewardship sits between those options: a tailored control layer owned for the family and maintained with outside expertise.
Three paths, three different burdens.
| Decision factor | Buy | Build | Steward |
|---|---|---|---|
| Time to initial use | Usually shortest. | Usually longest. | Between the two; begin with a bounded deployment. |
| Customization | Within the product’s controls and integrations. | Highest potential flexibility. | Tailored architecture with a controlled scope. |
| Internal burden | Administration, policy, vendor oversight, and user support. | Architecture, engineering, security, evaluations, support, and continuity. | Shared duties documented between office and steward. |
| Vendor dependence | Concentrated in the product. | Can shift to key developers, cloud services, and model providers. | Reduced through portability requirements and documented handoff. |
| Best fit | Common, low-to-moderate risk workflows. | Distinctive needs plus durable internal capability. | Sensitive or integrated workflows where family control matters but a full internal AI team is not practical. |
Buy unless a requirement earns the complexity.
Custom architecture should answer a specific control or workflow need. Prestige, vague privacy concerns, or the desire to “own a model” are not enough.
Buying is usually sufficient when:
- The work uses non-sensitive or well-classified information.
- The required retention, identity, and admin controls exist in the product.
- No privileged connection to core systems is needed.
- Outputs are reviewed before they influence a material decision.
- The office accepts the provider’s roadmap and exit terms.
Custom or stewarded architecture earns consideration when:
- Information must remain inside a defined technical or jurisdictional boundary.
- Permissions must reflect trusts, entities, generations, advisers, and temporary duties.
- The system needs governed access across several family-controlled sources.
- Agents will interact with consequential workflows.
- Model, provider, and integration portability are explicit requirements.
Ownership requires evidence.
Ask for the data map, source code or configuration rights, credential ownership, infrastructure accounts, evaluation set, architecture record, backups, and handoff procedure. A custom interface alone does not create independence.
Define the duties that continue after launch.
- Maintain the data-flow and dependency map.
- Review access, vendors, models, and integrations when they change.
- Run a fixed evaluation set before production updates.
- Monitor incidents, vulnerabilities, and consequential agent actions.
- Test backup, export, rollback, and provider exit.
- Document decisions for the family, advisers, and successors.
PwC frames family-office adoption in stages from enablement to scaling and longer-term reinvention. That progression works only if the operating burden grows deliberately. Citi also describes build, buy, and outsourcing as practical family-office choices rather than assuming one default.
Use the ChatGPT Enterprise comparison to judge a specific buy option. Use the private AI architecture guide to define the controls a tailored environment would need.
Questions family offices ask before deciding.
Should a family office build its own AI model?
Usually not as a first step. Most offices gain more from governing data, retrieval, permissions, integrations, and model choice than from training a proprietary base model.
What does AI stewardship mean?
It is ongoing responsibility for architecture, controls, evaluations, updates, documentation, and exit planning, performed with the family office rather than delivered as a one-time build.
Is buying enterprise AI less secure than building?
Not necessarily. A well-governed enterprise product can be safer than a poorly maintained custom system. Compare the required controls, data flows, operating capability, and consequences.
What internal staff does a custom system require?
At minimum, named business, technical, security, legal or privacy, and review owners. Engineering and operations may be internal or stewarded, but accountability cannot be outsourced vaguely.
How should a family office test vendor independence?
Run a documented export, identify replacement dependencies, confirm credential and account ownership, restore from backup, and estimate how the priority workflow would continue without the provider.
References used for this guide.
- Citi, “AI in the Family Office,” May 11, 2026
- PwC, “How AI is reshaping the modern family office,” June 8, 2026
- NIST, AI Risk Management Framework
Published 2026-07-12. Review product terms, legal duties, and security requirements against the family office’s current facts before implementation.
Continue the decision.
Define the boundary before choosing the tool.
A private briefing starts with the family’s information, risk, team, and first practical use case.
Request a private briefing