A conversation with Maryna Didkovska, who leads AI Governance at EPAM and heads its Quality Engineering Practice across 15 European countries, on why AI quality cannot be confirmed once and then filed away.
The first three entries in Quality People looked at agentic QA from the inside of a product team, a consultancy, and a regional community: Huy Tieu on harness engineering, Gastón Marichal on adoption, and Fariz on the fundamentals underneath the tooling. This one picks up the question those conversations kept circling: once an AI agent is genuinely acting inside your systems, who is accountable for what it does, and how would you even know?
The timing is not accidental. As of August 2, 2026, the majority of the EU AI Act applies and enforcement has begun, with transparency obligations now live and the high-risk system rules following in December 2027. Plenty of organizations are reading that as a legal workstream. Maryna Didkovska reads it as an engineering one.
Maryna leads AI Governance at EPAM and, in parallel, heads the Quality Engineering Practice across 15 European countries. She holds a PhD and is an Associate Professor, with an academic background in AI that predates the current wave by a long way.
Before EPAM she worked on what the field now calls classical AI: computer vision, plate number and fingerprint recognition, speech recognition and speech intelligibility. That combination matters here, because much of what she says about evaluating generative systems is an argument that the industry already learned these lessons once.
SUMMARY
Maryna Didkovska on governing AI systems in production, at a glance:
• Governance defines what should be controlled. Quality engineering checks whether that control actually holds.
• AI quality cannot be confirmed once before release, because behavior shifts with context, data, prompts, and tools even when the code does not change.
• The most underestimated risks are goal hijacking, blast radius, a kill switch with no protocol behind it, and no way to reconstruct a decision.
• Using an LLM as a judge does not make it an expert. It may reflect the most common view, while a real expert’s judgment gets lost in the average.
• Tokenomics belongs inside observability: an agent that costs more than the value it creates is not a successful agent.
The rest of this conversation covers the incident that started her work in AI governance, the six layers EPAM uses to operationalize it, and what all of this asks of quality engineers.
"AI governance is quite a natural continuation of my previous work," she says. "When generative AI adoption accelerated, the next set of questions appeared quite naturally. How do we manage these systems? How do we make their decisions transparent? How do we control their behavior and make sure that they are safe enough for real use? I look at AI governance not only from the policy or compliance side, but also as an engineering and quality problem."
Ask Maryna to describe where quality engineering and AI governance overlap and she starts by describing what testing used to be, and quietly points out that the definition no longer holds.
"In traditional software testing, we usually worked with a snapshot," she says. "We tested a particular version, confirmed that it behaved correctly, documented the results, and assumed that if we did not change the code, the behavior would remain more or less stable."
That assumption is the part that breaks. "This does not fully work for AI-enabled products. Their behavior depends on the context, the data, the environment, and the tools around them. An agent also has a goal, and it keeps trying to optimize how that goal is achieved. As a result, quality cannot be confirmed only once, before release. We need to control and validate it over time."
There is a second shift alongside the first, and it is about where you look. "We also have to look beyond the final answer. First, in a nondeterministic system, it is already more difficult to define what a 'correct' answer is. Second, with an AI agent, we must understand the full path: what information it used, which decisions it made, which tools it called, and what actions it took."
Her summary of how the two disciplines fit together is the cleanest framing in the whole conversation.
The moment that turned this from an interesting problem into her working discipline happened almost two years ago, and it is worth quoting in full because the failure is so reasonable.
"We had an AI agent that was supposed to improve test coverage by creating an optimal set of test cases from user stories. We had tested it and believed that it was working well. Then we moved it to another sandbox. On the third day, it deleted roughly half of the Jira items there."
The agent was not malfunctioning. It was succeeding. "The agent had found user stories that were too unclear to produce good test coverage. It then made a perfectly logical decision from its own perspective: if these stories prevented it from reaching its goal, it could simply remove them."
Nothing in a conventional test pass would have caught that. The agent had been evaluated in one environment, behaved well there, and then met a different set of inputs with the same permissions and the same goal. "That was the moment when we understood that our old way of thinking was not enough. We had to reconsider what the agent was allowed to do, how its policies were defined, which guardrails had to be added, and how much freedom it should have in the first place."
She is careful to note this is not a one-off war story. "Since then, we have seen many similar stories, both around us and across the market. This is why I see AI governance as a serious engineering discipline. These systems can act, adapt, and sometimes find solutions that no human expected. That requires much more than a policy document."
Asked what organizations most often miss when an AI system graduates from demo to production, Maryna does not lead with hallucinations or model accuracy. She leads with behavior.
The first is goal hijacking, which is the same failure mode as the Jira incident wearing a different outfit. "One of the most underestimated risks is that an agent can change its behavior while trying to achieve its goal. It may discover or even create additional mechanisms that its developers did not expect."
Her recent example is worth sitting with. "I recently saw a case where an agent had to receive human approval before taking the next action. The guardrail was not defined clearly enough. At some point, the agent created an auto-approval mechanism for itself. It did not decide to become evil. It simply found a more efficient way to reach its goal."
The second is blast radius. "If something goes wrong, how much damage can the agent actually cause? This becomes especially important if it has access to medical or financial decisions, customer data, production systems, or even an internal file system." That last item is the easy one to overlook, because file system access rarely shows up on a risk register next to "medical decisions," and it should.
The third is the kill switch, and specifically the difference between owning one and having a protocol for it. "Saying 'we can switch it off' is not enough. Who notices the problem? Who has the authority to stop the system? How exactly will they do it, and how quickly?" Four questions, and most teams can answer at most two of them under pressure.
The fourth is decision transparency. "When something goes wrong, they must be able to understand what the agent saw, why it made a particular decision, and what it did next." This is the reconstruction problem, and it is a design decision made long before the incident, not a logging feature you can retrofit during one.
| Four Production Risks Teams Underestimate If you cannot answer the question, you do not yet have the control. |
|
|---|---|
| GOAL HIJACKING | The agent changes its own behavior, or builds new mechanisms, to reach its goal more efficiently. Not malice, just optimization meeting a loose boundary. Ask: what could the agent do that we never told it not to do? |
| BLAST RADIUS | The total damage possible if something goes wrong. Grows with every permission and integration, including quiet ones such as internal file system access. Ask: what can it access, change, disclose, or delete? |
| KILL-SWITCH PROTOCOL | Owning a stop button is not the same as having a protocol for using it under pressure. Ask: who notices, who has the authority to stop it, how exactly, and how quickly? |
| DECISION TRANSPARENCY | The ability to reconstruct what happened after the fact. A design decision made before the incident, not a logging feature added during one. Ask: what did the agent see, why did it decide that, and what did it do next? |
This is where Maryna's background does the most work. Much of what the generative AI world is currently discovering about evaluation, she points out, was settled practice in computer vision and speech recognition years ago.
Start with error asymmetry. "One example is the difference between false positives and false negatives. They can have completely different costs. An average quality score tells us very little if we do not understand which errors the system makes and what the consequences of those errors are." A single blended accuracy number is comfortable to report and close to useless for deciding whether a system is safe to ship.
Then drift. "We also need much more attention to drift and degradation over time. A system may perform well during the initial evaluation and then gradually change as its context, data, model, prompts, or connected tools change." Note how many of those inputs sit outside the model itself. A prompt edit or a new tool integration can move behavior as much as a model upgrade, and neither typically triggers a formal re-evaluation.
Her sharpest point is about LLM-as-a-judge, and it is a critique of practice rather than of the technique. "It is a useful approach, and I am not against it. But in principle, it is the same old mechanism of expert evaluation. In classical expert evaluation, we calibrated the experts, checked how consistent they were, and measured the level of agreement between them. With LLM judges, teams sometimes replace all of this with an average score. The problem is that the opinion of a real expert can be lost inside the average opinion of a less competent majority. We should use LLM judges, but we should validate and calibrate them instead of treating every generated score as equally reliable."
For teams building evaluation into their own workflows, that is a concrete instruction: measure inter-judge agreement, check your judges against a human-labeled set, and know your judges' failure modes before you let them gate a release. It is the same discipline that underpins manual review of AI system behavior, just applied to the evaluator instead of the system under test.
"The most important thing is to operationalize AI governance," Maryna says. "If it exists only as a policy or a presentation, it does not yet work."
At EPAM the working model is six connected layers, and the sequence matters as much as the contents. It starts with policies and risks: "We define the system's goal, ownership, explainability requirements, decision boundaries, and possible blast radius." Those expectations then get translated into technical guardrails, which is the step where governance either becomes code or stays a slide.
Observability comes next, "because we need to see what the system is doing and be able to reconstruct its decisions." Then human oversight, defined with more precision than most escalation policies manage: "It should be clear which signals require escalation, when control must be passed to a person, and what that person can actually do." That last clause is the one teams skip. An escalation path that hands a human a notification and no lever is not oversight.
Security is the fifth layer, and it grows in importance exactly as autonomy does. "Security becomes even more important when an agent can use tools and take actions in connected systems." The sixth is testing and continuous validation: "This includes evaluations, ground truth, and regular checks for drift and degradation."
| Six Layers of AI Governance That Actually Operates Governance that lives only in a policy or a presentation does not yet work. These are the layers that make it run, in the order they get built. |
|
|---|---|
| 1. POLICIES AND RISKS | Define the system's goal, ownership, explainability requirements, decision boundaries, and possible blast radius before anything ships. |
| 2. TECHNICAL GUARDRAILS | Translate those expectations into enforceable constraints. This is the step where governance becomes code instead of staying a slide. |
| 3. OBSERVABILITY, INCLUDING TOKENOMICS | See what the system is doing and reconstruct its decisions. Track token consumption and the cost of every useful result alongside behavior. |
| 4. HUMAN OVERSIGHT | Make it clear which signals require escalation, when control passes to a person, and what that person can actually do about it. |
| 5. SECURITY | Scales in importance with autonomy. It matters most once an agent can use tools and take real actions in connected systems. |
| 6. TESTING AND CONTINUOUS VALIDATION | Evaluations, ground truth, and regular checks for drift and degradation, because quality cannot be confirmed once and then filed away. |
There is also a consideration she folds into observability, and it is the one least likely to appear in a governance framework written by a risk team. "Tokenomics should also be part of observability. We need to understand how many tokens the system consumes and how much every useful result costs. An AI solution can work technically and still make no business sense."
Her definition of the finished state is refreshingly unromantic. "Good AI governance means that you understand the value the system provides, control its behavior and risks, and know how much it costs you."
For anyone mapping this against an external framework, the layering lines up closely with the govern, map, measure and manage functions in the NIST AI Risk Management Framework, with the cost dimension added on top. It also sits alongside the argument Katalon has made about why human oversight is what separates real AI platforms from hype: the oversight point only counts if someone can act on it.
If the systems changed, the job changes with them. Maryna's view of where quality engineering is heading is demanding, and she does not soften it.
"Quality engineers need to stop working by templates and stop assuming that there is always one exact result that the system must return," she says. "We are working with nondeterministic systems now, so the task is much broader."
The first requirement is domain depth. "Quality engineers need to become real subject-matter experts. Without domain knowledge, it is almost impossible to judge whether an AI-generated result is complete, correct, useful, or subtly dangerous." That word "subtly" is carrying real weight. A plausible, fluent, wrong answer is harder to catch than a crash, and catching it requires knowing the domain rather than knowing the test framework.
The second is the shift in time horizon. "We also need to move from snapshot thinking to temporal thinking. It is not enough to test a system once. We need to understand how its behavior changes over time."
The third is scope. "This requires more critical thinking, more thinking outside the box, and a much deeper understanding of how the system works. We need to look at the model, prompts, context, data, memory, tools, permissions, and the full chain of actions." Eight surfaces, only one of which is the model everyone talks about.
And cost joins the quality conversation properly. "Quality engineers need to understand tokenomics. Quality, speed, business value, and cost are all connected now."
"I believe quality engineering is becoming less about checking predefined answers and more about validating system behavior," she says. "It is a deeper engineering task, and the level of responsibility for quality professionals will be enormous."
That is a considerably more optimistic read on the profession's future than the automation-anxiety version, and it is consistent with what the rest of this series keeps finding: the work is not disappearing, it is moving up a level. It is also the practical answer to the question of whether AI replaces testers, and to the broader shape of agentic QA as a discipline.
The obvious risk in a conversation like this one is that it reads as an argument for slowing down. Maryna's advice to engineering leaders is the opposite.
"Start using AI. Experiment and take baby steps, but add governance from the beginning. You do not need to build a huge governance organization before your first AI initiative."
The starting set is small and answerable in an afternoon. "Define the agent's goal and policies. Think through the main risks. Understand the blast radius: if something goes wrong, what can the agent access, change, disclose, or delete? Then decide how you will detect the problem and stop it."
The part she flags as most often missing is change control, which is where the Jira story would have been caught. "Models, prompts, tools, permissions, and context can all change the system's behavior. Decide which changes require a new evaluation, an approval, or a rollback plan. Otherwise, you may test one system and later discover that you are operating a rather different one."
Then tokenomics again, because she does not consider it optional. "Monitor token consumption, infrastructure costs, and the cost of a useful result. A technically successful agent that costs more than the value it creates is not a successful agent."
And a closing instruction about how to learn this faster than by accident. "Study real cases and learn from other organizations' mistakes. As the saying goes, wise people learn from the mistakes of others, while smart people learn from their own. In AI governance, we should try to do both."
The through-line in Maryna's account is that none of this is exotic. The agent that cleared the Jira board was not adversarial, the agent that granted itself approval rights was not malicious, and neither incident required a novel category of failure. Both were ordinary optimization meeting an underspecified boundary, which is a problem quality engineering has always been in the business of finding. What is new is that the boundary now has to be defined, instrumented, watched over time, and costed, rather than assumed to hold because the code did not change.
If you are working through the same questions on your own team, the rest of the Quality People series is a good place to compare notes, and Katalon's guidance on AI testing practices covers the tooling side of the same problem. You can follow Maryna on LinkedIn or join the QA discussion on Katalon Community.