Notes from rolling out AI assistant capabilities inside an existing enterprise, framed as general principles. The recurring thesis: trust is earned at the deployment boundary, not declared at the model layer. Start deterministic, prove the model works on the narrow case, and only expand autonomy as the trust evidence accumulates.
Deterministic before generative
The first version of an AI assistant inside an organization should answer a small number of well-defined questions with high reliability, not gesture at being able to answer anything. The narrow surface is where trust gets established. Three questions answered with near-perfect reliability beat thirty answered at 80%.
Paper before pilots
The agreements come before the activation, not after the proof of concept. The right contracts wherever regulated data is anywhere near the system, data processing agreements with every vendor in the chain, and a clear answer to “where does this prompt actually go” in writing. None of this is exciting work, and all of it is cheaper to do before the first user types a real question into the box. A pilot that has to be paused for legal review reads as a failure to the organization, even when the technology worked.
Clean the data before you activate
An assistant inherits whatever it reads. Stale documentation, duplicate records, files exposed to the wrong people, fields nobody has maintained since the last migration — all of it becomes raw material for confident, wrong answers. The unglamorous pre-activation pass matters more than model choice: archive what is dead, fix ownership and access on what is live, and decide explicitly which sources the assistant is allowed to treat as truth. Activation is the deadline that finally forces that cleanup; use it.
Earned autonomy, not granted autonomy
Each expansion of what the assistant is allowed to do (more question types, looser inputs, deeper integrations) should be tied to evidence from the previous, narrower scope. The default is “no” until the system has proven the smaller version works.
Cultural intervention, disguised as technology
The hardest part of rolling out AI in an organization isn’t the model. It’s the existing relationships, the fragmentation between teams, and the unspoken assumptions about who owns which information. The technology rollout is often where those issues finally have to be confronted.
Audit, audit, audit
Every action the assistant takes, every answer, every triggered workflow, has to be inspectable after the fact. People trust the assistant only when they can verify what it actually did.
Public discourse on enterprise AI tends to swing between “fully autonomous agents are around the corner” and “AI doesn’t work in real organizations.” Both reads miss the operational middle, where most of the actual work lives. This page is where I put down the principles I keep running into, and it will keep refining as the work continues.