AI Can Make Your Family Office Smaller. It Should Not Make It More Fragile.

Imagine an operations manager building a tool that eliminates hours of reporting work.

It connects the accounting and investment systems, reconciles records overnight and flags exceptions before anyone arrives in the morning.

The team gets time back. The family gets better information.

Then ask a different question:

"What happens if the person who built it leaves?"

That is where the conversation about AI in family offices becomes more interesting—and more consequential.

Not simply what a small team can now build.

But whether the office can understand, govern and maintain what it increasingly depends on.

The most useful innovation may come from the people doing the work

An October article by FOTechHub in Family Capital describes family offices moving well beyond chatbot experimentation.

Its examples include an accounting manager who taught himself to code and built an internal ERP over five years, and a non-coder who developed a document-extraction workflow and now has 20 automation flows running in production. Other examples cover K-1 aggregation, capital-call collection and investment reporting.¹

These are anonymous, practitioner-reported examples—not a representative survey or an independent audit of results.

Still, they point to something important.

The people closest to operational friction often know exactly what needs fixing.

They know which spreadsheet everyone quietly distrusts. Which report takes half a day. Which investment statement requires manual repair before it can enter the accounting system.

AI-assisted development gives those people more ways to act on that knowledge.

But we should also distinguish AI from the broader engineering around it. A custom ERP built over five years is not evidence that a coding agent can recreate an institutional operating platform over a weekend.

The opportunity is real. So is the work beneath it.

A successful workaround can become tomorrow's critical dependency

My concern is not that operations professionals are building tools.

It is that a useful experiment can become essential before anyone formally decides to support it.

A script becomes the reconciliation process.

A low-code workflow becomes the document intake system.

A generated report becomes the version the family expects every quarter.

At that point, "it works" is no longer a sufficient acceptance test.

I would want to know:

• Who owns the workflow?
• Where are its code, configuration and credentials held?
• What testing happens before a change?
• How are failures detected?
• Who can maintain it besides its creator?
• What is the fallback when it stops?

FOTechHub itself identifies code review and accountability for AI-written software as emerging governance questions.¹

That is the transition firms need to manage: from individual ingenuity to institutional capability.

Goldman is drawing boundaries—not abandoning AI

This is why the recent Goldman Sachs story deserves a careful reading.

Bloomberg reported on 2 November that Goldman restricted access to Claude Code and Microsoft's GitHub coding tools for most bankers and traders, limiting access primarily to engineers. Quantitative strategists working across trading, research and software engineering were reportedly exempt. The reporting links the decision to productivity and risk considerations.²

That does not establish that Goldman rejected AI, identified a particular data-architecture failure or reached a verdict on Claude for Financial Advisors.

A restriction on coding tools is not a product review of an advisor-facing assistant.

The relevant lesson for a smaller wealth-management business is narrower:

The ability to create software does not automatically establish the authority to deploy it.

Family offices do not need Goldman's organisational structure.

But they do need their own answer to who can build, approve, change and operate systems that touch sensitive information or consequential workflows.

Connections are not the same as agreement

In the LinkedIn discussion shared alongside the Goldman story, Robert Sofia argues that financial institutions need more than a capable model connected to applications. Jud Mackrill sharpens the point: the question is what the model is connected to.

I agree with the architectural concern, with one qualification.

Connecting several systems does not inevitably produce contradictory answers. Equally, putting data into a warehouse does not automatically make those answers trustworthy.

The real issue is whether the firm has established consistent identities, definitions and rules.

Consider a family-office question:

"How much liquidity can we deploy without affecting next quarter's commitments?"

Before generating an answer, the system needs to establish:

• Which people, trusts and entities are included?
• Which accounts belong to each?
• What counts as available liquidity?
• Which commitments are confirmed?
• What date does each balance represent?
• Who is permitted to see the underlying information?

This is where an ontology becomes useful: a shared definition of the business's entities and relationships.

But I would not describe those relationships as "resolved once" and finished.

Ownership changes. Trust arrangements evolve. Accounts move. Authorities expire.

The requirement is a maintained record—not a one-time cleanup.

Smaller teams still need to understand complex structures

Tomas Hurcik's LinkedIn post captures the operating-model question with the phrase "$80 million is the new $500 million."

I would treat that as a provocation, not a verified economic threshold for establishing a family office.

His more useful point is that technology can reduce the labour required without simplifying the underlying ownership structure.

A small team may still oversee property-level entities, trusts, direct investments and cross-border arrangements.

My takeaway is straightforward:

Reducing headcount does not reduce the need for institutional memory.

Imagine an investment held through an SPV owned by a trust.

A portfolio record may describe the investment. Legal records establish ownership. Accounting records show activity. Signed documents support authority.

An AI-generated explanation should not flatten those different records into one confident narrative without preserving their meaning and evidence.

For a lean office, that distinction becomes more important—not less.

Build the workflow. Institutionalise the knowledge.

I would approach AI adoption through three connected responsibilities.

1. Establish the facts

Start with the records needed for the chosen workflow.

Resolve relevant entities, identify authoritative sources, define reconciliation rules and preserve dates and supporting evidence.

This does not require a firm-wide transformation before the first useful deployment.

It requires enough governed information to support the task responsibly.

2. Define the permitted action

Reading a document, preparing a draft, posting an accounting entry and initiating a payment are different levels of authority.

FOTechHub reports a common boundary among participating offices: actions that send, pay, post or delete generally require a person. It also describes an implementation that automatically posts reconciled items and flags exceptions—underlining why firms need precise, workflow-specific policies rather than slogans.¹

My preference is explicit permissions, approval thresholds and exception handling, enforced outside the model wherever possible.

3. Make the process transferable

Document the logic. Assign an owner. Test changes. Monitor failures. Maintain a fallback.

Measure review time and exception rates alongside hours saved.

And ask whether another competent colleague could operate the process without calling its creator.

That is a more demanding test than a successful demonstration.

It is also a better definition of production readiness.

Build versus buy is really about what you want to maintain

Family Capital's article argues that process re-engineering costs—not just software prices—are a major influence on build-versus-buy decisions.¹

That resonates.

But preserving an existing process is not always the right objective. Sometimes the process itself needs changing.

I would evaluate three costs together:

• The cost of adapting the office to the software.
• The cost of building and maintaining a custom solution.
• The cost of continuing with a flawed process.

For wealthtech providers, this creates an opportunity beyond selling another AI interface.

Help firms retain control of their information, preserve business meaning and operate workflows that remain understandable when employees, applications or models change.

Model flexibility is valuable. It does not eliminate the need to retest behaviour and controls when a model changes.

Start small—but do not stay informal

The most encouraging lesson from the early adopters is that progress can begin with one operational problem.

Not a grand transformation programme.

Not an enterprise-wide AI launch.

One problem, a clear owner and a measurable result.

But the first successful workflow should establish a pattern the office can safely repeat.

The real advantage is not how many automations a family office can accumulate.

It is continuity: the ability to keep operating accurately when the person, model or vendor behind a workflow changes.

That is what turns a smaller team into a stronger institution—rather than a more fragile one.

References

1. Family Capital / FOTechHub — "How Family Offices Are Using AI — and What the Early Adopters Have Already Built," 28 October 2026
2. Bloomberg — "Goldman Restricts Traders and Bankers From Using Some AI Tools," 2 November 2026