Section 1
Most of the rules that bind you are not AI rules
Founders look for the AI statute and miss the point. If your automation makes a lending decision, financial regulation already applies. If it screens candidates, employment law already applies. If it handles health information, that regime already applies. If it tells a customer something untrue about your product, consumer protection law already applies, and the fact that a model wrote the sentence is not a defence. The practical consequence: your regulatory exposure is determined by what the automation decides, not by what technology it uses. Map your automations against the decisions they influence, and the applicable regimes usually become obvious without a lawyer. Then hire the lawyer for the two that are genuinely unclear.
Section 2
Your obligations follow your role in the chain
The same system carries different duties depending on where you sit. If you build a model and sell it, you owe one set of things. If you buy a tool and point it at your customers, you owe another. Most small companies are deployers, and deployers carry the obligations that actually bite: telling people an automated system was involved, keeping a human in the loop where it matters, being able to explain a decision, and honouring a request to have it reviewed. Deployer status also means you inherit your vendor's problems without inheriting their information. If their model provider changes a policy or a sub-processor, your compliance position moves and nobody sends you an email about it.
Section 3
Documentation is the compliance artefact
Regulators do not audit intentions. They ask for records. The set that covers most regimes is short and dull. A register of automated systems: what each one does, what data it touches, who owns it, what it can decide alone. A record of the assessment you did before deploying anything high risk, including what you considered and rejected. Logs of decisions and escalations, retained long enough to investigate a complaint. Evidence of testing, including the cases where the system performed badly. A record of what you told users and when. None of this requires a compliance team. It requires a spreadsheet that somebody updates, and a rule that a system cannot go live until its row is filled in. This is the same discipline that prevents the operational failures described in [Common Challenges in Implementing AI Automation (and How to Solve Them)](/blog/common-challenges-in-implementing-ai-automation-and-how-to-solve-them).
Section 4
Jurisdiction follows the customer
The tempting shortcut is to comply with the rules of the country you are incorporated in. That is not how most of these regimes work. Data protection and consumer protection obligations commonly attach to where the affected person is, not where your servers or your directors are. For a company selling across borders, this means the strictest applicable regime effectively sets the floor for the product, unless you are prepared to run genuinely separate versions. Most small teams should not attempt separate versions. Build to the strictest regime you serve, and treat that as a product decision rather than a legal one.
Section 5
Use contracts as the fastest control
NIST frames AI risk management around trustworthiness, design, evaluation, and use, and the fastest way for a small company to import that discipline is through the vendor contract. You will not out-engineer a large platform's data practices. You can require them in writing. Ask for and paper: whether your data trains their models, retention periods for prompts and outputs, the list of sub-processors and notice before it changes, the regions data is processed in, incident notification timelines, audit or evidence rights, and export on exit. Where a vendor will not commit, that is information. Price the risk or choose differently. On the other side, put the same discipline into your customer contracts, so an automated decision you make is covered by terms your customer actually agreed to. The reputational half of this is covered in [AI Automation and Job Displacement: What Founders Should Know](/blog/ai-automation-and-job-displacement-what-founders-should-know).
Section 6
What to track
Useful indicators here are not model metrics. Track the share of live automations with a completed register entry, the age of the oldest un-reviewed high-risk system, the number of decisions made without a retrievable log, time to answer a data subject or complaint request, and the count of vendors whose terms you have never actually read. Review quarterly, not annually. The regulatory surface moves faster than most annual cycles, and the cheapest moment to fix a gap is before somebody outside the company finds it. On saying all this publicly without overstating it, see [Storytelling in the Age of AI and Automation](/blog/storytelling-in-the-age-of-ai-and-automation).