AI rules are being written in several jurisdictions at once, and the coverage of that process is far more dramatic than its effect on a normal client project. Underneath the argument, the recurring requirements are fairly consistent, and most are things a careful team would want to do anyway. Specific obligations depend on your jurisdiction and use case, and the detail is still moving, so take proper legal advice for anything high-stakes and treat this as a map rather than a ruling.
The recurring themes across every regime
- Disclosure: people should know when they are interacting with an automated system, and when content was generated.
- Risk tiering: obligations scale with consequence, and hiring, credit, education, health and safety uses attract more.
- Human review: consequential decisions need a route to a person who can overturn them.
- Data provenance: you should be able to say what a system was trained on or grounded in.
- Record keeping: enough logging to reconstruct why a given output occurred, months later.
- Accuracy and testing: evidence that you evaluated the system rather than assuming it works.
Notice that none of these are about model architecture. They are about process and evidence, which is why the work lands on the team building the product rather than on whoever trained the model.
How the main regimes differ in shape
The European approach is a single horizontal law that classifies systems by risk and attaches duties to each tier, with obligations phasing in over several years and guidance still being issued. The United States has no equivalent single statute; instead there is a growing patchwork of state laws plus existing sectoral regulators applying old rules to new tools, which means the question is usually "which regulator already governs this industry" rather than "what does the AI law say". Several other jurisdictions sit between the two. Nepal does not currently have a dedicated AI statute, so for local clients the binding constraints are contractual and sectoral rather than statutory, and for exported work the client's home regime is what matters.
The practical consequence for a small agency is simple: you inherit your client's obligations through the contract. A Nepali team building for an EU or US customer is not usually the regulated party, but the customer will push their requirements down to you, and those requirements will arrive as a questionnaire rather than as a citation.
What that means in practice
For the overwhelming majority of client work, which is summarising, drafting, classifying and retrieving, compliance means a visible label, a logged trail of inputs and outputs, a documented escalation path and a clear statement about what happens to customer data. All four are about a week of work if you plan them in, and an unpleasant retrofit if you do not. The retrofit is unpleasant specifically because logging cannot be applied backwards: you cannot produce records for the six months before you started keeping them.
Log what the system was asked and what it answered. Every later question depends on that record.
The vendor terms flow straight through to your client
Model providers set their own terms on training, retention, regions and acceptable use, and those terms bind whoever built on them. Read the ones you rely on and write down four answers: whether inputs are used for training, how long they are retained, which region processes them, and what the provider prohibits. Then check the answers against what your client has promised their own customers, because that is where the mismatch usually surfaces. Data residency is the clause that catches people out most often, since a client with a residency commitment cannot use an endpoint in the wrong region regardless of how good the model is.
The contract question clients forget
Who is responsible when the output is wrong? That belongs in writing, before launch, alongside what the system may not be used for. Set out the intended use, the excluded uses, who reviews outputs, what the client is responsible for supplying, and what happens when a user complains. An acceptable-use clause naming excluded purposes protects both sides: it gives you a defensible position, and it gives the client something to point at internally when somebody proposes using the summarisation tool to make hiring decisions.
The documentation pack, which is smaller than it sounds
One page per AI feature answers most of what any auditor, buyer or regulator asks. Write it while you build, keep it in the repository beside the code, and update it when the feature changes.
- What the feature does, in plain language, and the decision it supports.
- What data goes in, where it is processed, and how long anything is retained.
- Which model and version, which vendor, and whether inputs are used for training.
- How it was evaluated: the test set, the measures, and the known failure modes.
- Who reviews outputs, and how a user escalates to a person.
- What it must not be used for.
Evaluation is the requirement that has teeth
Every regime, in different words, asks you to show the system was tested for the purpose it is used for. That means a fixed set of examples you own, expected outputs, a score you record on each release, and a note of where it fails. Without one you cannot answer the accuracy question, you cannot tell whether a model update broke something, and you have no defensible position if an output causes harm. This is the same discipline described in shipping AI features that users trust, which is not a coincidence: the regulatory ask and the engineering good practice have converged.
Disclosure that is useful rather than defensive
A disclosure notice exists to change what the user does, not to protect you in a dispute, so write it as an instruction rather than a disclaimer. "Answers are generated from our documentation and can be wrong. Check anything that affects a payment, and ask for a person here" is more useful than a paragraph of legal text nobody finishes. Put it where the output appears, not in a policy page. Cite sources inline where the answer came from your own documents, since a link the user can open does more for trust than any wording, and it also gives your support team something to check against when a complaint arrives.
The design consequence
Regulation mostly pushes in the direction good engineering was already going: narrower scope, visible confidence, an easy path to a human, and honesty about limitations in the interface rather than in a footnote. Teams that build that way find compliance is largely documentation of what they already do, and teams that do not find it is a rebuild. Privacy obligations sit underneath all of it, and the ground covered in US privacy laws for small product teams applies to AI features exactly as it does to any other feature handling personal data.
We build the label, the log, the escalation path and the evaluation set into every AI feature as standard on our AI and machine learning work. It is cheaper as a default than as a response to a questionnaire, and it makes selling to overseas clients materially easier, which is the point that persuades most owners faster than the compliance argument does.
Abishek Bimali
Founder & Engineer
Abishek founded SiteCraft Innovation and leads its engineering. He writes about building web and mobile products that hold up in production, for teams in Nepal and abroad.
