There is a moment in AI adoption where enthusiasm meets an incident: a credential in a prompt, generated code committed without review, tooling acting outside its lane. Policy then gets written in the incident's shadow — restrictive and reactive. The alternative is boring and effective: write a small set of guardrails first.
The rulebook
My own baseline — the governance layer every one of my projects inherits — is a small set of documents. An engineering standard defines structure and conventions so AI output is consistent and reviewable. An AI workflow standard defines how tasks are specified, what must be human-verified, and how decisions are recorded. A security rulebook defines the hard lines: where secrets live, what environments tooling can touch, and what is off-limits regardless of convenience.
The important property is that these documents are the source of truth for the tooling itself, so following them is the default path rather than a review-time correction.
Separation of environments
Working across an employer's environment and personal projects makes one rule non-negotiable: separation. Office work, office machines, office data; personal projects, personal infrastructure. Alongside the technical boundary sits the practical one — respecting employment terms and keeping independent work clearly independent.
Why it matters most when you are small
Guardrails sound like ceremony, but they matter most for a solo operator. A large company can absorb sloppy AI usage through redundancy; one person has no such buffer. Discipline is what lets a single developer credibly build systems worth trusting — and it is exactly the part that is tedious enough that most people skip it.
AI tooling is coming to every operational workflow. The people who benefit will not be the ones who adopted it first, but the ones whose rules were strong enough to let it run safely.