How to start your AI practice

Your company already uses AI, whether you decided to or not. Someone on your team pastes customer text into a chatbot. Another uses an AI feature inside software you already pay for. A third bought a tool on a company card. None of this is a practice. It is a pile of experiments, and it grows without anyone owning it.

That is how most companies start, and it is why most of them stall. The tools are easy to buy. The hard part is deciding what AI should touch, who checks its work, and what happens when it is wrong. Without answers to those three questions, each new tool adds risk faster than it adds help.

Small companies assume a practice is for large companies. It is not. A practice is not a department. It is the owners, rules, tools, skills, and measurements that stay in place after the first pilot ends. A small company needs a smaller version of those things, not none of them (IBM, 2024).

Companies with an IT team make a different mistake. They hand AI to IT and call it an IT project. Then every request waits in the same queue, and the business teams that were supposed to benefit stop asking. Companies with no IT team make the opposite mistake. They wait for someone technical to arrive before they start, and meanwhile the experiments pile up anyway.

What an AI practice is

I believe the fix is boring, and that is why it works. A practice is a standing capability, not a project. A project ends. A practice stays: someone owns it, the rules are written down, the team knows how to check AI output, and someone measures whether it helped.

This post is about the practice inside your company. It is not about starting a firm that sells AI services. That is a different topic, and it needs a different post.

AI-first is a question, not a shopping list. It means your team asks, for each piece of work, how AI could help, and then checks whether it should. The second half matters as much as the first. AI is not right for every task, and a practice needs a way to say no (Rework, 2026).

The check I use has four parts: what is at stake if the output is wrong, whether a person can verify the output, what data the AI would see, and who answers for the result. If the stakes are high and no one can verify the output, do not use AI for that task. Saying no there protects the company.

How I start one with a team

When I start with a team, I do not start with tools. I start with an owner and an inventory. The owner is one named person who keeps the practice alive after the first pilot. The inventory lists every AI tool and feature already in use, including the ones nobody approved. Most teams are surprised by that list.

Then we pick one workflow, not five. Usually it is a painful, repetitive piece of work that the team already measures, or can start measuring. We write down the baseline first: how long it takes now, and how often it goes wrong. Without a baseline, you cannot tell later whether AI helped or just felt modern.

We run that workflow as a pilot with guardrails: a person reviews the output, the AI only sees data it is allowed to see, and we record what changed. At a date we set in advance, we decide: keep it, fix it, or stop it. A practice needs that decision date, or pilots run forever.

I have done this with teams that had an IT department and with teams that had none. The steps stay the same. What changes is who does each step, and how much help you buy.

Start with one workflow

Pick the workflow first and the tool second. Choose work that is repetitive, that has an answer someone can check, and that matters enough to measure. If no one can check the output and the cost of being wrong is high, skip it for now and pick another workflow.

Name one owner. This is the person who keeps the list of tools, updates the runbook, and calls the decision meeting. In a small company, that person often does other jobs too. That is fine. What fails is a practice owned by everyone, which means owned by no one.

Write down the rules before you scale: which tools are approved, what data AI may not see, and who reviews output before it reaches a customer or a decision. Put it on one page. A one-page policy that people actually read beats a long document that no one opens.

Check the tool before you trust it. Features matter less than data handling: does the vendor train on your inputs, where does your data live, how long is it kept, who owns what you create, and what happens when the model changes. If the vendor cannot answer those questions, do not put sensitive work through the tool.

Verify the output every time it matters. A person who knows the work should verify AI output against the source material, not against whether it sounds right. AI output often sounds right when it is wrong. Keep that review in place until accuracy holds steady, and keep monitoring after that, because models drift and outputs change over time.

Governance is part of the practice, not a separate project (Microsoft, n.d.). The inventory, the approved-tools list, and the review rules are governance. If you operate in Colorado, the Colorado AI Act readiness work belongs here too: knowing which systems you run and what they decide, and keeping a human in review for consequential decisions.

Redesign the workflow around the new step. If you bolt AI onto an unchanged process, you keep the old delays and add a new tool to maintain. Change who does what, what gets checked, and where the output goes. Then write it down as a runbook, so the learning survives when someone leaves or the tool changes.

Train people in their real work, not in a classroom. Show the team how to use the chosen tool on their own tasks, name champions who help others, and update the runbook when the tool changes. A single training day fades. A champion on each team and a runbook that stays current do not.

If you have an IT team

Give IT the platform, the security rules, and the data standards, not every use case. Let business teams bring problems and own the results of their pilots. Audit the team's skills first, then redesign roles around the new work. If AI becomes one more queue in IT, the business will go around IT, and the shadow inventory will grow again.

If you have no IT team

Start with AI already inside software you own, then one assistant for a business task, then a no-code automation. Buy code help only for a fixed, defined piece of work, and keep the account, the checks, and the runbook in house. You do not need an IT department to run a practice. You need an owner, a policy, and a runbook (Bhattacharya, n.d.).

Measure, then decide

Measure against the baseline you wrote down: time saved, errors, and whether the team actually uses the tool. Then make the decision you scheduled: keep it, fix it, or stop it. A stopped pilot still teaches the practice what not to scale.

Then pick the next workflow and repeat the same steps, because that repetition is the practice: one owner, one workflow at a time, rules written down, output checked, results measured. Over time, that is how a company, tech or not, large or small, builds a way of working with AI that holds up.

Conclusion

A practice gives a company a repeatable way to answer the same questions every time AI comes up: should we use it here, who checks it, and did it help. Tools will change, and models will change, and the questions will stay the same.

Start small on purpose. One owner, one workflow, one baseline, one decision date. When that workflow is decided, pick the next one and run the same steps. The practice grows one decided workflow at a time, and the runbook grows with it.

The work is not glamorous, and it does not need a large team. It needs an owner, written rules, checked output, and measured results, kept up after the first pilot ends.

References

Bhattacharya, S. (n.d.). How to implement AI in a small business with no tech team. https://sagnikbhattacharya.com/blog/implement-ai-with-no-tech-team

IBM. (2024, December 16). What is an AI center of excellence? IBM Think. https://www.ibm.com/think/topics/ai-center-of-excellence

Microsoft. (n.d.). AI strategy for business transformation. https://www.microsoft.com/en-us/ai/ai-101/strategy

Rework. (2026, June 12). Building an AI-first culture. https://resources.rework.com/guides/ai-team-readiness/building-ai-first-culture