Bygild is a small studio. AI is part of every working day here: code gets written with it, drafts get shaped by it, research goes through it. That is not unusual anymore. What is still unusual is having anything written down about it.
The reason to write it down is not fear of the EU AI Act. It is that the question has started arriving from the buying side. Client procurement teams now ask suppliers what AI they use, what data goes into it, and what controls sit around it, and "we have nothing written down" reads as a risk regardless of how careful you actually are. Deals stall on unanswered questionnaires, not on statutes.
So we did the exercise on ourselves and wrote the Bygild AI acceptable-use policy, mapped against the EU AI Act's risk tiers and cross-checked against the NIST AI Risk Management Framework and ISO/IEC 42001. Here is what the exercise actually involves, because it is smaller than the framework names make it sound.
Start with a register, not a policy
The first document is not rules. It is an inventory: what AI systems are used, by whom, for what, with what data. Ours is short. A coding assistant used daily on client builds. Drafting and research tools. That is broadly it, and writing it down took an afternoon.
The register matters more than the policy prose, for the same reason an asset register matters more than a security policy. You cannot govern what you have not listed, and every questionnaire you will ever receive starts by asking what you use.
Classify against the risk tiers
The EU AI Act sorts uses of AI by risk. Prohibited practices at the top, high-risk uses below that, then limited-risk uses with transparency duties, then minimal risk. The useful discipline for a small firm is realising the classification exercise is mostly about what you are not doing.
A studio using AI to write code and draft documents sits in minimal-risk territory. What would change that is the nature of the use, not the volume: AI making decisions about people, evaluating them, screening them, or touching biometric identification moves up the tiers fast. Knowing where those lines are is what lets you say, in writing, that your use stays below them.
Then the rules follow from the classification
Once the register and the tiers exist, the actual policy is short and concrete. Ours comes down to a handful of commitments. A human reviews and signs off anything client-facing before it ships. Client personal data does not go into a model without an agreement that covers it, and special category data does not go in at all. Client work is not used to train anything. Where AI contributes to a deliverable, we can say so plainly if asked.
None of that restricts how useful the tools are. It restricts the failure modes.
What surprised us
Two things. First, how much of the value is in the artefact existing at all: a written policy answers procurement questions in minutes that would otherwise stall a deal for weeks. Second, how little of the work is legal. Most of it is honest inventory and a few decisions about where the lines sit, which is design work, not law.
The usual disclaimer matters here: Bygild builds evidence systems and infrastructure. This is not legal advice, and a policy is not a substitute for advice where the stakes need it.
If you run a small firm that uses AI daily
Start with the register. One page, four columns: the tool, who uses it, what for, what data touches it. Everything else builds on that page: the classification, the rules, the questionnaire answers. The firms that struggle with AI questions from clients are rarely doing anything wrong. They just have nothing written down, and in procurement, nothing written down is indistinguishable from nothing considered.