{"id":81940,"date":"2026-09-01T13:31:01","date_gmt":"2026-09-01T08:01:01","guid":{"rendered":"https:\/\/2thenew.online\/blog\/?p=81940"},"modified":"2026-09-09T10:44:09","modified_gmt":"2026-09-09T05:14:09","slug":"when-the-ba-becomes-the-ai-trainer","status":"publish","type":"post","link":"https:\/\/2thenew.online\/blog\/when-the-ba-becomes-the-ai-trainer\/","title":{"rendered":"When the BA Became the AI Trainer \u2014 Without Anyone Telling Them"},"content":{"rendered":"

\"AI\"<\/a><\/p>\n

Introduction<\/strong>
\nWe talk a lot about how AI is changing the way we work. But here is something we do not talk about enough \u2014 how the Business Analyst’s role is quietly changing because of AI, often without anyone formally saying so.<\/p>\n

No one updated the job description. No one sent a circular. But somewhere between the first AI pilot and the third AI project that did not quite deliver what was promised, BAs started picking up a responsibility that was never officially handed to them: making sure the AI actually understands the business.<\/p>\n

I have spoken to several BA teams over the past few months. Most of them are still thinking of themselves as AI users \u2014 people who use the tool, review the output, maybe write a prompt here and there. Very few have stopped to ask: “Wait, am I also the one who is supposed to train this thing?”<\/p>\n

The answer, more often than not, is yes.<\/p>\n

Why a Smart AI Still Gets It Wrong<\/strong>
\nAI models today are genuinely impressive. They have processed more text than any of us could read in ten lifetimes. But here is the problem \u2014 they have not read your organisation’s documents. They do not know what your team means by “material risk.” They do not understand the difference between a clause your legal team will accept and one that is a red flag. They have no idea how your product team names things internally.<\/p>\n

This gap between what AI knows generally and what it needs to know specifically for your business \u2014 that is what fine-tuning addresses. Fine-tuning is basically retraining the AI on your organisation’s data so it starts understanding your context, your language, your rules.<\/p>\n

And the results are worth it. A 2024 PwC study found that organisations using fine-tuned AI models saw a 37% improvement in output accuracy compared to those using generic models.<\/p>\n

But here is the real question: who decides what goes into that training data?<\/p>\n

That is not a technology question. That is a business question. And business questions are the BA’s territory.<\/p>\n

Three Ways BAs Are Already Training AI \u2014 They Just Don’t Know It<\/strong>
\nThis is the part that surprises most people. The activities are not new. BAs are already doing them. The difference now is that these activities directly shape how well the AI performs.<\/p>\n

1. Deciding what the AI should learn from<\/strong><\/p>\n

When a team wants to fine-tune an AI for, say, reviewing contracts \u2014 someone has to decide which contracts to include. Which ones represent good examples? Which clauses are red flags versus acceptable terms? What does “standard” look like in this company, not just in the industry textbook?<\/p>\n

Engineers can build the pipeline. They cannot answer those questions. Only someone who has worked closely with the business can. That is the BA.<\/p>\n

But here is something that often gets overlooked \u2014 and it is just as important as choosing the right documents. Not every document can or should be uploaded to an AI tool. Before any client-specific document, internal policy, or confidential data goes into a system, proper approvals need to be in place. Uploading the wrong document can expose your organisation to serious legal risk. This is not a technicality \u2014 it is a real responsibility that falls on whoever is curating the training data.<\/p>\n

Two things every BA should remember before feeding documents into any AI system:<\/p>\n

Always take prior approval from the relevant stakeholders \u2014 legal, compliance, or client \u2014 before uploading any document that is not clearly internal and non-sensitive.
\nAlways use paid, enterprise-grade AI tools for this work. Free or open-source tools often do not offer the data privacy guarantees that organisations need. Your client’s data should never go into a public or unverified system.
\nChoosing what to include is only half the job. Making sure you are doing it safely and legally is the other half.<\/p>\n

2. Writing instructions that the AI can actually follow<\/strong><\/p>\n

Writing a good prompt for an AI is not very different from writing a good requirement. Both require you to be specific, remove ambiguity, and think about what could go wrong if the instruction is misunderstood.<\/p>\n

Compare these two:<\/p>\n

“Summarise the compliance report.”
\n“Summarise the compliance report in three sections \u2014 key obligations, open risks, and recommended actions. Write it in plain language for a non-legal reader.”
\nThe second one gets a useful output. The first one gets something technically correct but practically useless. BAs do this kind of thinking every single day when writing acceptance criteria. Prompt engineering is just that skill applied to AI.<\/p>\n

3. Checking whether the output is actually good<\/strong><\/p>\n

Once the AI produces something, someone needs to evaluate it \u2014 not just for grammar or format, but for whether it would actually be useful to the person who needs it. Does it capture the right level of detail? Would a senior stakeholder trust this? Is something important missing?<\/p>\n

That judgment comes from domain knowledge and business understanding. It is exactly what a good BA brings to the table.<\/p>\n

A Real Example<\/strong>
\nA finance team once deployed an AI tool to generate regulatory compliance summaries from internal policy documents. The technical setup was solid \u2014 the right pipeline, properly indexed documents, everything in order.<\/p>\n

But the outputs kept missing important details. Summaries that looked fine on the surface but had gaps that would have created real compliance problems if acted upon.<\/p>\n

The BA’s involvement changed everything. She defined which documents were actually relevant. She developed the prompt template. She reviewed the first 50 AI-generated summaries, flagged the patterns that were off, and worked with the team to refine the approach.<\/p>\n

Six weeks later, the compliance team had a tool they could actually rely on. The technology did not change. The BA’s contribution made the difference.<\/p>\n

Key Takeaways for BAs<\/strong>
\n1. Recognise that your domain knowledge is the missing ingredient in most AI implementations. The AI is only as good as what it is taught, and you are the one who knows what it needs to learn.<\/p>\n

2. Prompt engineering is requirement writing. Do not let the technical-sounding name put you off. If you can write a clear acceptance criterion, you can write an effective AI prompt.<\/p>\n

3. Get involved early, not just at the review stage. The BA who shapes the training data and the prompt templates will have far more impact than the one who reviews outputs at the end.<\/p>\n

4. You do not need to become a data scientist. The skills you already have \u2014 eliciting requirements, managing ambiguity, validating outcomes \u2014 are exactly the skills AI projects need from you right now.<\/p>\n

5. Treat document governance as seriously as requirement gathering. Know what you are uploading, get the right approvals, and always work within secure, enterprise-approved tools.<\/p>\n

Final Thoughts<\/strong>
\nThe enterprise AI market is expected to grow from around $5 billion in 2025 to over $32 billion by 2032. Every single one of those implementations will need someone who understands the business well enough to define what a good AI output actually looks like.<\/p>\n

That person is the BA.<\/strong><\/p>\n

AI projects do not usually fail because the technology is wrong. They fail because no one with enough business context was involved early enough to tell the AI what “correct” means for that organisation. That has always been the BA’s job \u2014 helping systems and teams understand business reality clearly.<\/p>\n

It still is. The system is just different now.<\/p>\n","protected":false},"excerpt":{"rendered":"

Introduction We talk a lot about how AI is changing the way we work. But here is something we do not talk about enough \u2014 how the Business Analyst’s role is quietly changing because of AI, often without anyone formally saying so. No one updated the job description. No one sent a circular. But somewhere […]<\/p>\n","protected":false},"author":489,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":3,"footnotes":""},"categories":[5869],"tags":[5405,5733,8850],"class_list":["post-81940","post","type-post","status-publish","format-standard","hentry","category-ba","tag-businessanalysis","tag-genai","tag-skills"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t