AI at work: context, control and your own analytical skills

Every impressive AI release brings back a familiar question: do we still need data analysts? I understand the reaction. When a tool produces a report in moments, it is hard to ignore the work that used to go into making one. My attention, though, goes to the whole process around that report.

The biggest change in my own work came from connecting tools, knowledge and tasks. GitHub, Linear and Notion helped me organise the context my models work with. At the same time, I noticed a trap: I could produce more material while understanding less of it. Both sides matter when I decide how to use AI professionally.

A demonstration and a company’s daily work have different constraints

Online, it can feel as though everyone already uses sophisticated agents. Yet Eurostat reported for 2025 that 20% of EU enterprises and 8.4% of Polish enterprises used AI technologies. These figures concern surveyed enterprises with at least 10 employees. They do not describe every business or the share of workers using AI, and using some AI does not mean automating an entire operation.

I take a limited conclusion from those figures: technical capability and adoption inside a particular department need separate assessment. They do not let me calculate the probability of losing a job. They do help me stop treating a polished demonstration as a description of every workplace.

I remember an experience from my analytical work at Lufthansa. The company had an extensive technology stack. In one department, however, I saw someone comparing items on two sheets of paper. The explanation was that computer results needed an independent manual check. That scene stayed with me because change can move at different speeds within one organisation.

With AI, I therefore ask practical questions. Which tools are approved? Which data can they access? Does the model have documentation, or only a single attachment? Who accepts its work? Those answers determine what I can sensibly delegate. A demonstration cannot answer questions about the rules and limitations of my actual workplace.

Write down the context you usually carry in your head

If I explain my work from scratch in every conversation, I spend attention repeating myself. I start with documents instead: what I do, what I want to achieve, which definitions I use and what I currently do not know. Project descriptions, definitions and decisions belong in distinct, findable places. Then I can point a task at the relevant material.

In my setup, a private GitHub repository and Markdown files play an important role. I can read and maintain those documents myself, then make them available to an AI tool within its capabilities. Linear organises tasks, while Notion holds another part of my knowledge. I would not turn those names into a mandatory shopping list. The important question is where the authoritative version of each piece of information lives.

Git adds history. The Pro Git documentation explains how to inspect commits and the changes they contain. I can revisit an earlier definition and see what changed. That is useful when reports prepared at different times rely on different assumptions.

Creating a repository does not automatically connect a model to it. The tool needs access, and I need to specify the relevant files and, where useful, the history to inspect. A private repository also gives me no automatic permission to upload employer data. For practice at home, I use my own material or a fictional project. Context should support my work within the rules that apply to it.

I also distinguish current decisions from old proposals. In a fictional project, I would keep the approved customer definition separate from ideas for changing it. If I cannot tell which document applies, I should not expect a model to guess. Naming the authoritative source is part of assigning the work.

Delegate a bounded task with an acceptance criterion

Once knowledge is organised, I can delegate more than an isolated question. I still need to describe the outcome. “Sort out the analysis” leaves too much room for assumptions. I prefer to name the problem, sources, constraints and evidence I expect before accepting the result. Those boundaries also tell me when to stop or narrow the task.

Consider a fictional example. I need to compare two descriptions of the same report. I ask AI to identify differences in definitions, name the source document for each difference and list unresolved questions separately. I am not asking it to rebuild the report yet. First, I want to establish whether the descriptions even refer to the same metric.

When I use several agents, I separate their responsibilities. One can prepare a proposal while another looks for contradictions in the source material. Their answers still come back through me. Similar recommendations are no substitute for checking the underlying document. Conflicting recommendations mean I need to resolve an assumption, rather than hold a vote between models.

A task should remain understandable after I close the conversation. I want to see what we used, what was accepted and what happens next. Otherwise, I can end up with an impressive collection of chats that I have to rummage through the following morning. Making a task recoverable is part of doing analytical work properly.

Keep the fundamentals you need to assess the work

I see a problem with delegating every small action simply because I can. If I know how to filter a dataset or prepare a straightforward comparison, sometimes I will do it myself. When choosing a method, I include the time spent explaining the task, waiting, reading and correcting. Generation time alone tells me very little.

I do not have a universal benchmark proving that manual work always wins for a particular task. My point is to preserve a meaningful choice. If I can no longer understand my own spreadsheet without assistance, I will struggle to assess a generated spreadsheet too. I explore that issue further in analytical fundamentals in the AI era.

I separate two goals. Sometimes I want to complete a familiar operation quickly. Sometimes I want to learn how to do it. For learning, I ask for an explanation, write down the assumptions myself and try to reconstruct the approach. Receiving a finished file does not demonstrate that I have acquired the skill I intended to practise.

Fundamentals let me ask better questions. What does a row represent? Where did this number come from? What did we exclude? At what point does the comparison stop being meaningful? Someone needs those answers regardless of who wrote the formula. I would rather practise asking them than measure my development by the number of prompts I send.

Build understanding as the work progresses

A particularly deceptive situation looks like this: I give AI a database schema, notes, messages and a long email. It returns a substantial document with a proposed solution. Everything looks organised. Then someone asks me to explain the recommendation, and I start searching through the same document. The output exists, but my understanding has fallen behind.

I therefore divide work into pieces I can evaluate. First, I want to understand the question. Then the sources and assumptions. After that come the analytical approach and the recommendation. At each stage, I write down in my own words what I know and what I still cannot claim. This exposes gaps before I assemble the final report.

Confidence is an unreliable shortcut here. The NIST generative AI profile discusses both confabulation, where incorrect content is presented convincingly, and excessive reliance on automated systems. I treat that as a reminder to check evidence and assumptions even when an answer reads fluently.

My practical check is simple: can I explain what we calculated and why without looking at the generated answer? If I cannot, I return to that specific part. I might ask for a shorter explanation or split the problem further. Another large batch of text rarely solves the problem of not having understood the previous batch.

In the fictional report comparison, I would pause at one discrepancy and read both descriptions myself. If I still cannot resolve it, I record a question for the report owner. Closing a task is no reason to pretend an unresolved assumption has become certain.

Keep responsibility for relationships and direction

At work, people rely on me for something. I establish the purpose of an assignment with them, then return with a result. If several people separately use AI, they may receive recommendations based on different information. We still need to agree on definitions and goals. Producing another document does not create that agreement by itself.

In my KajoData work, bringing more collaborators into a process also creates a need to coordinate as people. I want to stay involved in the flow of information. I need to know what I promised, what we checked and which limitation travels with the result. Those details matter when someone decides whether to trust the next analysis.

For a first step, I suggest a small experiment. Choose one recurring task whose output you can assess. Record its purpose, approved sources and acceptance criterion. Prepare a short context document, then note the corrections needed after the work is done. Evaluate the entire process, including the time spent understanding the response.

Finally, bring it back to your own direction. Are you learning the skills you want to have? Is AI helping you answer business questions more clearly? I want well-organised tools and a working understanding of the problem. One manageable task is enough to begin, without waiting for the next major release.

Set a point to revisit the experiment, perhaps in a month. I would look at which context I repeatedly had to supply and which results remained difficult to assess. That identifies a document to improve or a skill to practise before I add another agent to the process.