build log 001
The evaluator caught a bug I had trusted.
My tests were green. An adversarial pass found a real fail-closed bypass, I fixed it, and the evaluator attacked the fix again.
Read the build log →about · niceley ai consulting
You shouldn’t have to trade client trust for useful AI.
I’m Brian Niceley. I help small firms turn sensitive, repetitive work into private AI capability they own, understand, and can run without sending the work to someone else’s cloud.
No sales handoff. The person you speak with is the person who scopes, builds, tests, trains, and supports the installation.
the transformation
The goal is not “AI installed.” It is trusted work moving again.
Before
- ×Sensitive work gets no AI help because pasting it into a chatbot is not an acceptable risk.
- ×Drafting, transcription, and document search consume hours that should belong to clients—or to you.
- ×The capability depends on subscriptions, changing policies, and infrastructure you cannot inspect.
After
- ✓One real workflow runs on a machine in your office, with the internet unplugged if that is the boundary you need.
- ✓Actions, limits, and failures leave receipts your team can open instead of assurances they must take on faith.
- ✓You own the equipment, know how to operate it, and decide whether ongoing care is useful.
You do not need to become an AI engineer. You need a useful system with a boundary you can explain and an operator you can trust.
the mission
Make owning your AI as normal as owning your filing cabinet.
Small firms should be able to benefit from AI without surrendering the information that makes their work sensitive in the first place. My mission is to turn privacy from a vendor promise into a property of the installation: the work stays on hardware you control.
That mission is why I keep the practice deliberately small. Niceley AI Consulting LLC is one person, based in Northern Kentucky. There is nobody between the conversation and the work—and nobody to blame when a detail gets lost in a handoff.
the approach
Built like field work: inspect the conditions, do the job, prove it holds.
I spent decades in the trades before software. The useful lesson was not toughness or nostalgia. It was accountability: a system has to work in the conditions where the customer will actually depend on it.
01
Start with the job, not the model.
We identify one recurring task, the data it touches, the quality floor, and what must never happen. You leave intake with a written plan whether or not you hire me.
02
Build the boundary into the system.
Permissions, review gates, local storage, and useful logs are part of the installation—not policy language added after the fact.
03
Make the proof survive me.
An independent evaluator attacks the guarantees. We run the unplug test together. You get training, a runbook, and a system designed to keep working without a permanent dependency on me.
The rule behind it all: the person who does the work doesn’t get to grade their own work. That is why every build gets an independent, adversarial evaluation before I call it done.
values in practice
The standard is simple enough to say—and strict enough to cost me work.
- ✓
Custody over promises
Your privacy should come from where the work runs, not from hoping a vendor's policy never changes.
- ✓
Evidence over confidence
A claim is not finished until there is something you can inspect: a test, a log, a receipt, or a working system.
- ✓
Stop safely
When the system is uncertain or a boundary is crossed, it should block and explain instead of improvising.
- ✓
Candor over closing
Cloud or hybrid is the honest answer for some jobs. If yours is one of them, I will say so before you spend money.
I am more interested in a durable fit than an easy yes. If the best recommendation is to keep your current process, use a cloud model, or wait for the technology to improve, that is the recommendation you will get.
credibility you can inspect
Belief should be earned one receipt at a time.
I have built for regulated data, shipped systems that cross the boundary between software and the physical world, and learned to treat consent, review gates, quiet logs, and reproducible failures as engineering requirements. Here are three places to check the claim.
local AI control plane
Newport OS makes agent behavior inspectable.
Fail-closed permissions, governed writes, honest model attribution, and action receipts are designed into the control plane.
Inspect the project →working systems
The practice reaches beyond demos.
The work includes a delivered residential automation installation, a public local text-to-speech engine, and private-agent infrastructure in active hardening.
See the work →your first step
Bring me the task you do not trust to the cloud.
Tell me what keeps repeating, what information it touches, and where that information cannot go. I will respond with questions, not a pitch. You leave the first conversation with a written next step—even if that step is not hiring me.
Brian replies personally · usually within one business day