Heyno acts on behalf of real businesses, answering calls, sending mail, and moving quotes and invoices. Learn how we engage on the rules for assistants that act.
How we think about assistants that act on a business’s behalf.
Human control
High-stakes actions require a person’s approval by default, the way Heyno already works.
Data ownership
A business’s data is its own. It never trains a model without consent.
Transparency
People should be told when they are talking to an assistant, and every action should leave a trail.
Security by default
Credentials stay in the vault; connected tools get scoped, revocable access.
Portability
Businesses should be able to run on their own hardware and leave with their data intact.
Our priorities
Rules that keep people in control and hold assistants accountable.
Disclosure for automated conversations
People should know when an assistant is answering, on any channel.
Priority
People should know when an assistant is answering
Disclosure is the cheapest protection there is, and the one most easily written badly. A rule that only covers one channel just moves the problem.
Every channel, not just voice: If a rule covers a phone call it should cover chat, mail and messaging too. Otherwise the undisclosed path is simply the one everyone uses.
At the start, not on request: Disclosure that arrives only when somebody thinks to ask is not disclosure. It belongs at the opening of the conversation.
Written so a small operator can comply: A five-person contractor should be able to read the rule once and know what to do. Complexity is a tax that only large companies can pay.
Money, commitments, and messages that leave the building should pass a person.
Priority
Some actions should always wait for a person
The line worth drawing is not around a tool but around an effect. Anything that reaches outside the conversation deserves a person on it.
Define it by effect, not by feature: Rules written against particular product features go stale in a year. Rules written against consequences do not.
The approval has to be informed: Approving means seeing what will be sent, to whom, and on whose behalf, not clicking through a summary.
Keep the record: Who approved what, and when, should survive the conversation. It is the only way to answer the question afterwards.
Data protection for small businesses
Protections should not depend on having a legal department.
Priority
Protection should not require a legal department
Most of the businesses using assistants have no counsel and no compliance officer. Rules written for enterprises quietly exclude them.
Defaults over rights: A right nobody exercises protects nobody. The safe setting should be the one that ships.
Leaving should be cheap: Portability is a protection, not a feature. If moving your records out is expensive, every other promise is weaker than it looks.
One page, not forty: Terms that take a lawyer to read are a barrier disguised as transparency.
Regulated and public-sector buyers should be able to run models inside their own walls.
Priority
Some work cannot leave the building
Privileged material, records under a statutory duty, anything a regulator may ask about: for that work, where the system runs is the whole question.
Running on your own hardware should be possible: Buyers with a real constraint should be able to run US-developed open-weight models on hardware they own, inside their own network.
Procurement should not assume a cloud: Rules that presume a hosted service quietly rule out the buyers with the strictest obligations.
A property of the deployment, not a promise in a contract: If the data never leaves, that is verifiable. A commitment that it will be handled carefully is not.
The people whose work changes first deserve a say in how it changes.
Priority
The people whose work changes first deserve a say
Front-office work is where assistants land first: answering, scheduling, quoting, chasing. That makes it the place where the transition is decided in practice.
Consult the people doing the work: The person answering the phone knows which parts of the job are worth keeping. Designing around them rather than with them wastes that.
Redeployment before displacement: The realistic outcome in a small business is a changed role, not a removed one. Policy should assume that and support it.
Be honest about what changes: Overstating what an assistant can do sets up the people who have to live with it to be blamed when it cannot.
Sharing what we learn from real deployments with the bodies writing the rules.
Approach
Bring evidence from real deployments
Rules for assistants are being written now, largely without data from the businesses that actually run them. We think the useful contribution is evidence rather than opinion.
Say what we see: What breaks, how often, and under what conditions, including the cases that make us look bad.
Argue from the small end: Most published input comes from companies with policy teams. The constraints of a ten-person business rarely reach the page.
No claim we have not measured: If we cannot show the method behind a number, we do not bring the number.
Arguing for rules that a ten-person company can actually comply with.
Approach
Rules a ten-person company can comply with
Compliance cost is regressive. The same obligation that a large company absorbs into an existing team can be the reason a small one stops using a tool.
Proportionate obligations: Duties that scale with the size of the operator, not a flat rule set at enterprise scale.
Plain-language requirements: If meeting a rule requires interpreting it, small operators will guess, and guess wrong.
Do not mistake silence for consent: Small businesses are rarely in the room when these rules are drafted. Their absence is not agreement.
