Rules Before the Build

Picture the usual way a regulated firm adds automation. Someone buys a chat tool or a texting system, sets it up, and turns it on. A few months later, a partner or compliance officer asks what the system has been saying to prospects, and nobody is quite sure.

That order is backward. Most software is sold with the compliance question left to the buyer. In a regulated field, the rules decide what a system is allowed to say, store, and automate. Adding them after launch usually means rebuilding. This module covers what it looks like when the rules come at the start, as general education only. Your own counsel or compliance officer always has the final word.

Rules are constraints, not a document

The core idea of this module is compliance-tuned scripting. It is not a policy binder handed over at the end of a project. It is a set of constraints applied at the start, and those constraints shape three things:

• The script, meaning what the system says and refuses to say
• The data model, meaning which information goes where
• What automation may do without a human, meaning where the system must stop and hand off

When the rules shape those three things from day one, the system is built to fit them. When the rules arrive later, they get bolted on as disclaimers, and disclaimers do not change what the system actually does.

A simple test of any provider is whether they read your rules before they build. For a law firm, that means reading the Bar rules before writing a line of code. If a provider says that, ask them to show you how it changed the build.

Which rules actually bind your firm

The starting step is identifying which regime actually examines your firm. Depending on your field, that may be:

• The state bar, and which of its rules apply
• HIPAA, and whether a BAA, a business associate agreement, is required
• The SEC or FINRA
• Fair housing
• Some combination of these

Many owners assume they already know which rules apply. Often they know the main one but miss a second. Multi-jurisdiction practices carry more than one set of rules, and that changes the build itself rather than adding one more disclaimer to it.

An accounting and wealth example

Think about a firm that offers both tax preparation and investment advice to the same families. The owner may think of the firm as one practice. The rules see more than one. Advisory work brings in SEC or FINRA considerations, and client data handling brings in its own obligations.

A system scoped only for the tax side might happily send a message that is fine for an accountant but a problem for an adviser. Identifying every regime before the build is what prevents that. It also tells the provider which questions to bring to your compliance officer before anything goes live.

What this is not

It is important to be clear about the limits, because this is where many vendors overstate.

Compliance-aware engineering is not legal advice. A provider who builds to the rules is not your counsel. A careful provider builds to the rules as they read them, documents what they did, and expects your Bar counsel, compliance officer, or privacy lawyer to review it.

No vendor can certify that your firm is compliant. If a provider offers that, treat it as a warning sign. Only your own advisers can judge your firm's full picture.

Scripting cannot fix a non-compliant offer. If the underlying business practice is the problem, better scripting only makes it harder to notice. The fix has to happen in the practice itself.

Where the AI fits

Most systems in this course use AI-assisted tools for intake, follow-up, and replies. In a regulated firm, those tools work inside the limits set at the start. They gather facts, book time, and hand off to people. They do not give advice, quote fees, or decide when a rule applies. A person does that.

This is also why rules must come at the start. An AI tool that was never told where the lines are has no way to stay behind them.

Questions to ask before anything is built

• Which regimes did you identify for our firm, and how did you decide?
• How did those rules change the script, the data, and the handoffs?
• Who at our firm reviews the result before launch?
• What will you document, and where will we keep it?
• What are you not able to promise us?

A provider who answers these plainly, including the last one, is taking the rules seriously.

The takeaway

In a regulated firm, the rules come before the build. Identify every regime that binds you, let those rules shape the script, the data, and the handoffs, and treat the result as engineering that your own counsel or compliance officer reviews. No vendor can certify compliance, and no script can fix a practice that is the problem. The next lesson looks at the specific guardrails that turn rules into system behavior.

Go deeper:

• Compliance-Tuned Scripting