Service
Picking one job a business actually does, working out whether a machine can do part of it reliably, and putting a person in the loop where the consequences warrant one.
Almost nobody wants AI. They want one specific job to stop eating their week.
The conversation almost always starts the same way. Somebody has been told their business should be using AI, they have watched a demonstration that looked impressive, and they cannot work out what any of it would actually do on a Tuesday morning in a business with four staff and a phone that keeps ringing.
So, the first question here is never which model to use. It is which job is costing you the most time or the most mistakes right now. Usually it turns out to be something specific and unglamorous: the same twelve questions answered by email every week, quotes retyped from one system into another, enquiries that sit unanswered until somebody gets to the inbox, or a monthly report assembled by hand from three places.
Those are workable problems. Once one of them is named, it becomes possible to say whether a machine can do part of it reliably, what it would still get wrong, and whether setting it up repays the effort. Sometimes a spreadsheet and a changed process would fix it faster, and that is what you get told.
The dividing line is what a wrong answer costs.
These systems are good at work that is repetitive, tolerant of a mistake that a person will catch, and based on text you already have. Drafting a reply that somebody reads before it is sent. Sorting incoming enquiries so the urgent ones surface first. Pulling the same fields out of documents that arrive in slightly different shapes every time. Turning a long recording into a summary that a person then corrects.
They are poor at work where being confidently wrong is expensive and nobody is checking. Anything quoting a price that becomes a commitment. Anything making a claim about what your business can legally do. Anything touching customer records where an invented detail becomes a permanent one. The failure mode matters more than the task here. These systems do not stop when they are stuck, they produce something plausible, so an unchecked mistake looks exactly like a correct answer.
That is why human approval is designed in from the start, before anything has gone wrong. The point is not distrust of the tool. It is that a review step costs a few seconds and an unnoticed error can cost a customer.
There is now a state law covering this, and it applies to the business deploying the system.
The Texas Responsible Artificial Intelligence Governance Act took effect on 1 January 2026. It sets out prohibitions and some disclosure duties, covering harmful, misleading and discriminatory uses, and it has particular things to say about biometric data. Which duties apply depends on the use case and on who is deploying the system, and in most of these projects that is you.
Alongside it, the ordinary rules have not gone anywhere. Advertising claims still have to be supportable, and the Federal Trade Commission has already acted against a company over unsupported claims about the accuracy of an AI product. Privacy, employment, health and children's data rules apply by context as they always did.
None of this is legal advice and nothing on this page should be read as it. What it means practically is that the use case gets chosen with the question already asked: does this touch consumers directly, sensitive data, biometrics, hiring, or health. Where the answer is yes, that is a conversation to have with a lawyer before anything is built, and it is better raised at the start than discovered later. No provider can make you compliant.
Four stages, deliberately narrow at the start, because a bounded thing that works beats a broad thing that half works.
One workflow, described end to end as it actually happens now. The process document usually says something else. What triggers it, who touches it, how long it takes, and what going wrong looks like. Then a written definition of what an acceptable result would be, agreed before anything is built, because otherwise the test at the end becomes a matter of impression. Usually one to two weeks.
What information the system would need to reach, what it would keep, and where it must not go. This is where the uncomfortable questions get asked about customer records, whose accounts hold what, and what happens to anything sent to a third-party service. It is also where a use case sometimes gets narrowed, because the version that stays inside safe boundaries is the version worth building.
A small working version, run against real examples from your own business including the awkward ones, with the results checked by somebody who knows what a right answer looks like. The failures are as informative as the successes and they get written down. Knowing where a thing breaks is what makes it safe to rely on everywhere else.
Deployment with the human review point built in where the consequences warrant one, plus documentation of what was set up, what it can reach, and how to turn it off. Then monitoring after launch, because these systems drift as the underlying tools change and as the work they are handling changes shape. Ongoing, reviewed as agreed.
Accounts and documents in your name, and enough written down that somebody else could take it over.
The job as it actually runs today, end to end, which is usually useful on its own regardless of what gets automated.
What the system reaches, what it retains, and what it is not allowed near, agreed before anything is built.
A bounded working version, with the results of the real-case testing including the cases where it failed.
What was set up, in whose accounts, how it is monitored, and how to stop it without breaking anything else.
AI tools are used here, on research, on drafting, and on the repetitive parts of building a site.
The tools do not do the thinking. Decisions about what a page should say, which facts are true, what a business may claim, and whether a thing is worth building are made by people and checked by people. Anything published under a client's name is read by a person who is accountable for it.
The second of these surprises people most often.
The answers tell you more than any demonstration will.
Which single workflow are we starting with, and why that one? A list of everything that could be automated is not an answer to this.
What data will this reach, and what will it keep? The answer should name systems and records.
Where does a person approve something before it takes effect? If the answer is nowhere, ask what happens when the system is confidently wrong, because it will be.
Who owns the accounts, the keys and the work product? The answer should be you, and it should be true on the day the relationship ends as well as during it.
What is not guaranteed? Every system has a limit, and a useful proposal names it.
The same work, delivered locally across these areas.
Usually not, and the starting point is one job, not a strategy. A four-person business that stops retyping the same information between two systems has got real time back. A plan to become an AI-driven company has not, and the second is how most of the money gets wasted.
Sometimes, and it is one component of a plan. It earns its place when the same questions arrive constantly and the answers are stable. It is a poor idea when the questions are varied and a wrong answer commits you to something, because a confident wrong answer on your own site is worse than no answer.
No provider can make you compliant, and this page is not legal advice. What can be done is to choose the use case with the question asked up front, keep the data boundaries documented, and flag when a use case touches consumers, sensitive data, biometrics, hiring or health, which are the areas where a lawyer should be involved.
It will, and the design assumes it. That is why one workflow is chosen at a time, why it is tested against real awkward cases before it goes anywhere near a customer, and why a person approves the output wherever a mistake would cost something. The failures found in testing are written down and handed over with everything else.
Usually not. Most of the useful work sits between systems you already run. Replacement is a much larger project and it should be justified on its own terms, not carried in on the back of an automation.
Not by volume. Google's policies treat mass-produced low-value pages as spam whether a person or a machine wrote them, and the risk lands on your site. The tools can help produce useful material faster; they do not change what makes a page worth showing.
Tell us the single task that eats the most time in your week, and roughly how often it happens. That is enough to say whether it is a sensible candidate, whether a change of process would fix it more cheaply, and what would have to be true about your data before anything got built.
