Disclaimer: This presentation reflects the views of the individual speakers only. It does not represent the views, positions, or endorsements of SAP or HanaHaus. The event was hosted to foster open dialogue and knowledge-sharing within the AI and technology community, and any opinions, tools, or approaches discussed are shared for informational and discussion purposes only. 

The AI Masterclass: Impossible to Replace — Event Recap 

The event was hosted by Katherine (Katya) Ivahno and Irina Grak, two speakers with business and finance backgrounds rather than technical ones. Katya led the first talk on how to stay valuable in an AI-driven workplace. Irina followed with a talk on low-quality "AI slop" and how to avoid producing it. 

Are You in the Red Zone? 

Katya Ivahno (speaker)

Katya opened with a simple risk map for job automation: red for high risk, yellow for "watch closely," green for relatively safe. She joked that anyone solidly in the red zone probably wouldn't have shown up to a talk like this. 

She then pointed to past waves of automation panic, like bank tellers after ATMs arrived, or translators and interpreters as machine translation improved. In several of those cases, employment in the field grew over the following decade instead of collapsing. Her point: predictions of total job elimination tend to overshoot. What actually happens looks more like tasks shifting than jobs disappearing. 

She also cited a statistic that's become one of the most repeated data points in AI discourse: roughly 99 out of 100 corporate AI pilot programs fail to produce meaningful results.* That figure is a useful counterweight to the idea that AI adoption is smooth or inevitable. Most organizations are still struggling to get AI projects past the demo stage. 

The Three-Question Test for What AI Should Touch 

Katya offered a simple filter for deciding whether a task is a good candidate for automation: 

  1. Is it rule-based, with a clear, repeatable structure? 

  1. Can AI produce a genuinely good first draft? 

  1. Would it hold up on both counts? 

If a task clears all three, it's a reasonable candidate to automate or delegate. If it doesn't, keep a human in the loop, not because AI can't attempt it, but because attempting a task and being trusted to do it unsupervised are different bars. 

A Ladder of AI Skills, Mapped to Career Level 

The talk's clearest structural idea was matching how you use AI to where you sit on the career ladder: 

  • Early career: be persistent. Katherine's example was an engineer who kept iterating on a math problem the model initially got wrong, running dozens of attempts until it worked. 

  • Manager level: get specific. Give the model a role, like "act as a financial analyst" or "act as a critical editor," and precise requirements, the same way you'd brief a new hire. 

  • Director level: add competitive and market context, and push for output on a timeline of days rather than months, since AI defaults to generic answers unless you force specificity. 

  • Executive level: the job shifts from solving problems to identifying the right problem to solve. Katherine's advice was to reverse-engineer the model's assumptions. If you ask for a vacation itinerary and get something generic, that's a sign you haven't given it enough to work with. 

Build Yourself a "Skill File" 

Katya's most practical suggestion: build reusable instruction sets, or "skill files," that capture how your team works, so any AI tool has consistent context instead of starting from zero. This is partly about efficiency and partly about career insurance. A documented skill file signals initiative, and it works as institutional knowledge that keeps a process running while you're out sick or on vacation. 

She compared this to the aviation industry's use of simplified, standardized English in maintenance manuals, written so technicians anywhere in the world can follow instructions without ambiguity.* The takeaway for prompting AI: skip the vague, polite hedging and write plain, specific instructions instead. 

Part Two: The AI Slop Problem 

Irina Grak (speaker)

Irina Grak took over for the second half, and the energy in the room picked up. Her subject: the now-common feeling that AI-generated work looks fine on the surface but reads as hollow. 

She opened with an audience game, asking people to name telltale signs of AI writing. The room got most of them quickly: 

  • Em dashes 

  • Buzzwords like "delve" and "tapestry" 

  • Everything packaged into three tidy takeaways 

  • Leftover phrases like "let me know if you'd like another version of this" 

  • Unnecessary length 

  • Heavy jargon 

  • Emoji overuse, especially at the start of a message 

The game wasn't just for laughs. It set up her real point: once people start recognizing AI's fingerprints, they extend that skepticism to the substance of the work, not just the style. She described a conversation with her boss, who was frustrated with the team's reports and decks but couldn't say exactly why. The data was accurate and the formatting followed brand guidelines, but something about it still felt untrustworthy. That reaction, repeated across a team, becomes a real cost: people start discounting work simply because it smells automated, regardless of whether it's good. 

She used the term "slop drawer" for someone who produces volumes of unreviewed AI output and hands it off as finished work: polished on top, with no real substance underneath. 

Five Questions Before You Hit Send 

Irina's checklist for reviewing anything AI helped produce: 

  1. Why is this on the page? If an element doesn't add value, cut it. 

  1. Who is the audience? The same content needs different framing depending on who's reading it. 

  1. What's your personal voice or style? A recognizable point of view is what turns "AI made this" into "I made this, faster." 

  1. What do you know that the AI doesn't? Give it the specific context it can't guess, without dumping in months of unfiltered background. 

  1. What would you have added from scratch? Treat the AI's draft as a competent first attempt, not a finished product, and layer your own judgment on top. 

Her closing point: the tools aren't the problem. Unreviewed output is. Review your work before it goes out. 

From the Q&A 

  • On data security: both speakers said they use enterprise-licensed AI accounts for the added data protection, including keeping company data out of model training. They noted this isn't legal advice and varies by vendor, license tier, and industry. 

  • On regulated industries: finance and legal face real compliance constraints and tend to be cautious about external AI tools, though both noted there's still room to use AI on internal, non-sensitive analysis. 

  • On developing a personal voice: one attendee mentioned hearing that some people feed a model tens of thousands of words of their own writing to build a usable voice profile. Katherine and Irina didn't cite a specific number, but agreed that more real writing samples produce a closer match to your actual voice. 

  • On concrete use cases: examples included small custom tools for automating spreadsheet reconciliation, cutting a multi-day process down to minutes, and using AI for visual polish on investor decks. 

The Bigger Picture 

The throughline of the day: AI isn't likely to take your job outright. The real risk is that careless use produces work nobody trusts, while specific, well-reviewed, distinctly voiced work makes you harder to replace. As Katya and Irina put it, the point was never really the tool itself. It's staying curious, being specific, and reviewing your own work before sending it out. 

*Fact-check 

  • "99 out of 100 companies fail" / low AI pilot success rates: This closely tracks a real, widely cited 2025 MIT NANDA study, "The GenAI Divide: State of AI in Business 2025," which found a 95% failure rate for enterprise AI pilots, based on interviews and analysis of hundreds of deployments. The report attributes the failures to organizational integration issues, not model quality. Katherine's "99%" rounds up slightly but is directionally accurate. 

  • Simplified English in aircraft manuals: Real and verifiable, but not AI-related in origin. ASD-STE100 Simplified Technical English was developed in the early 1980s to help non-native English speakers understand maintenance manuals. It's a decades-old aviation standard, not a recent AI-driven shift. 

Disclosure: This post was written with the assistance of AI, based on a recording of the event transcript.  

Comment