AI as a tool in my workflow — and a feature I’ll add to a project when it’s genuinely the right call.

I should say this plainly: I’m not an AI consultancy. I’m a traditional webmaster — the kind who handles CMS updates, accessibility remediation, HIPAA-aware intake forms, ongoing site care, and the unglamorous engineering that keeps a web presence healthy. AI is something I use as a tool inside that practice, not something I sell as a separate service line.

What that means in practice: I use AI assistants every day in my own workflow. They help me move faster on code review, content drafting, accessibility checks, and the kind of grunt work that used to take a long Friday afternoon. That hands-on usage is why I have a working sense of where these systems are useful, where they fail, and what they actually cost — which is why I’m cautious about putting them in client projects.

When clients ask about adding AI to their site or application, the first question I ask is whether AI is the right tool. Sometimes the honest answer is that what they need is a better form, a cleaner data model, or a small workflow change — not an LLM. I’ll tell you that rather than quietly building something impressive that doesn’t help. When AI is the right answer, I scope it as a feature inside a normal engagement, with the same accessibility, security, and (where relevant) HIPAA rigor as everything else.

Start with the data question, not the model

Before I pick a model, I map the data. What information does this feature need access to? Where does it live? Who is allowed to see it? What’s the sensitivity class — public, internal, PII, PHI? Can it leave your environment, and under what terms? The answers here dictate everything downstream. A healthcare intake assistant and a public FAQ bot look similar on the surface; their data diagrams are completely different projects.

Choose models deliberately

Frontier models (Claude, GPT, Gemini) are the default for quality, but they send data to a vendor and carry per-token costs. Smaller open-source models (Llama, Mistral, and their specialized descendants) can be self-hosted for full data control, at the cost of more infrastructure work. The right choice depends on data sensitivity, latency requirements, volume economics, and whether a BAA is needed. I don’t have a favorite vendor — I have a decision framework, and I walk through it with you.

Ground everything in your sources

Letting a model respond from its training data is how you get confident-sounding fabrications. For production use, I prefer retrieval from your actual content and source references where possible, rather than letting a model answer from general training data alone. This is more work up front, but it makes review, correction, and user trust much easier.

Log inputs, outputs, and uncertainties

AI interactions should produce an audit trail appropriate to the context — without unnecessarily storing sensitive content in logs. For regulated workflows, logging and retention need to be designed with your compliance team. For lower-risk workflows, practical logging still makes debugging and review far easier.

Test for failure modes before shipping

An AI feature is not ready to ship the first time it produces a plausible answer. Before release I run it against adversarial inputs, out-of-distribution queries, prompt-injection attempts, ambiguous inputs where the right answer is “I don’t know,” and content that should trigger a refusal or escalation. The evaluation isn’t perfect — no AI evaluation is — but it’s designed to catch the failure modes that are embarrassing, harmful, or legally significant.

Keep humans in the loop where stakes are real

For clinical triage, benefits determinations, legal drafting, and similarly consequential workflows, the right architecture is usually AI-assisted rather than AI-automated. The model drafts; a qualified human approves. This is slower than full automation and dramatically safer — and it’s almost always the shape compliance, liability, and user trust require anyway.

AI does not have its own separate compliance regime. It inherits the regime of whatever data it touches. If PHI is in the pipeline, the workflow needs HIPAA review. If it’s a consumer-facing interface, accessibility law applies. If the model is making consequential decisions about people, there’s an increasing body of AI-specific law layered on top. I am a web practice, not a law firm — but these are the frameworks I work inside, and the ones your counsel will want to know I’ve considered.