Your Staff Will Start Building Their Own AI Tools

NewEdge Capital Group said this week that it is putting Claude-powered tools directly into advisors' hands for work like portfolio analysis, meeting preparation, and prospecting, with compliance and data-security controls around them. To be accurate about it: those tools were built internally and provided to the field, not improvised by every advisor. It is also a company deployment story rather than independent research, so hold it lightly. The reason it is worth noticing is the direction it points. Once people get meaningful access to a capable system, the conversation tends to move from can we buy something for this to could we make this easier ourselves.

The rollout model quietly changed

For thirty years, adopting business software meant somebody chose a product, configured it, trained people, and handed it over to be used as designed. The shape of the tool was fixed before anybody touched it. AI breaks that sequence, because the tool can be reshaped by whoever is holding it, and the reshaping takes minutes rather than a project. What you are actually rolling out is a capability, and capabilities behave differently from products. They spread sideways, they get used for things nobody planned, and their value shows up in places the person who approved the budget was not looking.

Why this favours small businesses

This is genuinely better news for a thirty-person company than for a large one. Custom software was usually out of economic reach: a tool that saved one team four hours a week could rarely justify a development budget, a vendor engagement, or a place in an implementation queue. That constraint is now much weaker. The person who understands the quoting process can often shape something that fits the quoting process without a formal specification or a long wait. The best ideas about what to automate have always sat with the people doing the work, and this is the first time they can act on them directly rather than filing a request.

It is shadow IT, and that is not a reason to stop it

Let us name it honestly: this is the same shape as shadow IT, which businesses have spent two decades trying to suppress. The difference is the balance. Traditional shadow IT often meant unmanaged subscriptions, fragmented data, and duplicate spend, with limited strategic upside. This creates comparable risks alongside something genuinely valuable, which is tools that fit the work precisely because the person doing the work made them. Clamping down loses the upside and, in practice, drives the activity somewhere you cannot see, which is the worst of both. The productive response is to make the safe path the easy one, the same argument behind managing rather than banning shadow AI.

Minimum guardrail	What it prevents
A written line on data	Customer information in unvetted tools
Review before consequential output	A homemade tool sending a wrong number
A register of what exists	Depending on something nobody can explain

Treat that as the floor for low-risk internal work rather than a complete control system. The moment a homemade tool holds credentials, connects to another system, takes an action on its own, or touches regulated data, it needs more: restricted access, a log of what it did, and someone signing off before it goes live. Governance should scale with consequence, and most of what people build will sit comfortably at the bottom of that scale.

The risk nobody plans for

It is not a data breach, though that gets the attention. It is dependency without ownership. Someone builds something useful, the team comes to rely on it, and then that person moves to a different role or leaves. Nobody else knows how it works, whether it is still correct, or what assumptions are baked into it. That is the old spreadsheet problem arriving much faster, because building is now so cheap that far more of these things exist. A register naming each tool and one accountable person handles most of it, which is the same accountability principle behind knowing who can explain AI-produced work.

Access is the variable you control

The detail worth taking from the NewEdge story is not the tools themselves, since those were built internally. It is that the firm chose direct access for the field rather than a restricted trial. Narrow pilots produce narrow results, because someone using a tool for two hours a week under supervision never reaches the point of asking what else could this do. That is not a training failure, it is a dosage one. If your AI programme has produced polite indifference, the cause is often that nobody has been given enough access, for long enough, to get past the novelty and into the useful part.

Write the page before you widen the door

None of this needs to be complicated to start. One page covering what data may go into these tools, what always needs a human check, and how to note down what you built, understood as a starting point for low-risk internal use rather than a finished policy. Then widen access and see what people make. Most of it will be small and unremarkable and a few things will be genuinely valuable, and you will not be able to predict which in advance. That is the same management layer that the majority of small businesses are currently missing, as we covered in using AI versus managing it, and it is cheaper to write before the building starts than after.

Frequently Asked Questions

What happened?

NewEdge Capital Group said it is giving field advisors direct access to Claude-powered tools for portfolio analysis, meeting preparation, and prospecting, with compliance and data-security controls around their use. Worth being precise: those tools were built internally and handed to the field, rather than improvised by individual advisors. It is a company deployment story rather than independent research, so read it as one firm’s experience. The useful part is the direction it points, because access changes behaviour. Give people enough room to work with a capable system and they start noticing workflows they could reshape themselves.

Why does that matter for a smaller business?

Because it changes what an AI rollout is. The traditional model is that somebody selects a tool, configures it, and hands it to staff who use it as designed. When the tool can be shaped by whoever is holding it, the useful ideas come from people who understand the work rather than from whoever runs technology. That is genuinely good news for small businesses, who never had the budget for custom software. It also means the thing you are rolling out is a capability, not a product, and capabilities need different management from products.

Is this not just shadow IT with a new name?

It is the same shape and a different balance of risk and reward. Shadow IT was people signing up for unapproved software, which mostly created security exposure and duplicate spending. This produces those risks plus something valuable: tools that fit the work exactly, built by the person who does it. The mistake is treating it purely as a threat and clamping down, because that loses the upside and drives it underground anyway. The better response is to make the good path easy and the risky path obvious.

What guardrails actually matter?

Three, as a practical minimum for low-risk internal work. First, a clear line on data: what may be put into these tools and what may not, particularly customer information. Second, accountable human review before release for anything that reaches a customer, changes a record, triggers an external action, or informs a financial, legal, regulatory, or safety-sensitive decision. Third, a register of what has been built and who owns it, so the business is not depending on something nobody can explain after that person leaves. Scale up from there by risk: anything with credentials, external integrations, automated actions, or regulated data needs access controls, logging, and an explicit approval gate as well.

What is the biggest risk people miss?

Dependency without ownership. Someone builds a tool that quietly becomes essential, the whole team relies on it, and then that person changes role or leaves. Nobody else knows how it works, whether it is still correct, or what it assumes. That is not an AI problem, it is the classic spreadsheet problem arriving faster, because AI makes building so easy that far more of these tools now exist. A one-line register naming each tool and its owner solves most of it, and costs almost nothing to maintain.