AI tools I actually use in consulting practice
At every digital transformation conference these days, AI gets mentioned at least fifty times. But most presentations are about what AI can do, not what it is actually useful for in practice. Here is my experience with the tools that genuinely save me time, and with the ones where I expected more.
I have been working with AI tools since the start of their wider availability — since the launch of ChatGPT, and before that experimenting with GPT-J and similar models. The last 2 years, however, are when these tools became usable in production for consulting work. Before that, they were toys with interesting potential; today they are an everyday working tool.
One important caveat upfront: the claims in this article are valid for the day I wrote it. AI moves so fast that the next day everything may look different. Specific tools, models, and even approaches can shift significantly within a short horizon. Treat this text as a snapshot, not a fixed point.
What I genuinely use
A large part of my work is documents — proposals, contracts, audit reports, functional specifications. On top of that: workshop preparation, writing reports, and client communication. AI helps me in all those areas, but the specific choice of tool depends on the type of task and the sensitivity of the data.
The models that form my daily backbone
Anthropic Claude is my primary choice for more demanding analytical work. It conducts itself responsibly and thoughtfully, sticks to the brief, and offers solid contractual guarantees on data. For most of my tasks — from structured summaries of long documents to suggested revisions of texts — it is the tool I use every day.
Mistral, especially via the API, is my second frequent tool. Its European origin and similarly trustworthy data-handling profile make it a good choice for more sensitive situations where I want to stay within a European regulatory frame.
Document preparation and analysis
Before meeting a new client, I typically receive 40–80 pages of background materials — vendor contracts, existing IT strategy documents, annual reports. Previously I spent an evening reading them. Now I do a first pass with AI and get a structured summary of key points and questions. The meeting then starts at a different level.
Where it works: Claude for longer and more complex documents; Mistral for more sensitive texts.
Where it does not work: Precise paragraph numbering, conclusions from poorly structured scans, comparing multiple versions of the same document.
Writing and editing
Reports, recommendations, executive summaries — these are the daily output of my work. AI helps me in a few specific situations:
- Restructuring — I have written 2,000 words in an illogical order; AI suggests a better structure
- Translation and localisation — professional translation of an English report into Czech (and back) without a translator
- Formatting — converting informal meeting notes into a structured document
Where it does not work: I do not send sensitive client information to AI without an agreed data processing arrangement. I always review outputs — AI occasionally produces confidently stated nonsense.
Meeting preparation and facilitation
Before a client workshop I need to prepare relevant questions, scenarios, and illustrative examples. AI helps me generate starting points — not as final output, but as a foundation for my own preparation.
After a meeting: transcribing recordings into structured notes. I expected more here, but the result is usable if the recording quality is good.
Enterprise-grade implementations at clients
In projects at clients I usually pick different tools than I do for my own consulting work. The reason is simple: the client needs the data to stay in their environment, auditable and contractually protected. I most often go down two paths.
Gemini API and Azure OpenAI API. The main reason is not model quality but the fact that clients have these in their own tenant and have contractually guaranteed (or at least promised) data security. The choice between them depends on the client’s cloud ecosystem and the requirements on geographic data placement. A client on Google Workspace typically goes the Gemini route; a client on Microsoft 365 goes the Azure route.
In both cases I try to follow the principle that infrastructure follows the client’s existing setup. Standing up a new environment dedicated to AI where the client already has an established cloud usually does not make sense.
Local models
Local models are remarkably interesting. It is surprising how much they can handle:
- Routine tasks
- Quick exploration of data and documents
- Configuration changes (in response to shifting conditions)
In this area there is a choice of several models. I focus on European and global ones, particularly open-weight models:
- GPT-OSS
- Mistral
- Gemma
Local deployment is also the only viable option when working with sensitive data, or when the client does not want their information travelling through the cloud. I fully respect that decision, and these are often the more interesting cases. A solution working with customer contract data, financial statements or healthcare documentation simply has no business being in the cloud.
The cost of getting started in this space is much lower today than it used to be. Renting a server with a GPU capable of running a 30B parameter model is available in the lower tens of thousands of CZK per month — accessible for most mid-sized firms.
Where I expected more
Generating structured data from spreadsheets and exports. If the input data is not clean and consistent, AI does not help — garbage in, garbage out applies more than ever.
Fully agentic end-to-end automation. Agentic tools are improving rapidly, but they still need more supervision than they save in time. In some narrow scenarios it already makes sense; in most processes inside a company, not yet.
Reverse-engineering of applications. No, AI will not save a project that wants to take an unmaintained legacy application and produce “the same thing, only better”. Without knowledge of intent and context, the result looks like a copy but breaks at the first edge case.
How to approach AI adoption in a company
The most common mistake: a company buys an AI tool licence, sends employees an email saying “you now have AI,” and waits for productivity gains. The result: 10% of people use it for real; the rest ignore it or do not know where to start.
What must not happen: you buy AI and then start figuring out what it could be used for so that the spend is not wasted. Conscious adoption means the opposite order. First identify where AI brings real added value in your process; then choose the specific tool. Preparing your people should precede the deployment, not follow it.
What works better:
- Identify 2–3 specific repeating processes where there is a clear opportunity
- Train 3–5 people who have genuine motivation to experiment
- Collect experience after 4–6 weeks, then decide about broader rollout
AI adoption is not an IT project — it is a change in working habits. That requires time and ongoing support, not a one-time deployment. I have written more about the most common pitfalls separately — pitfalls of AI in companies →.
Summary
AI saves me roughly a day of work per week when I use it consciously and on tasks where it makes sense. That is not a revolution, but it is a meaningful saving on tasks that used to be a necessary evil. The key is knowing where it makes sense and being sceptical about everything else.
If you want to identify where AI makes sense for your company specifically — I am happy to look at your concrete situation.