Let’s talk about what’s next

Whether you're working through a challenge or ready to move on something new, we're ready.

Looking to join the team?

Find your next challenge

Please enter a name

Please enter a company

Please enter an email

Please enter a valid email

Please enter a phone

Please enter a valid phone

Please tell us about your challenge or opportunity

Start a conversation

Thanks

Your message has been sent.
We will get back to you within 1–2 business days.

Something went wrong while sending. Please try again, or email us at info@parserdigital.com.

Insights

AI’s Value Depends on the Engineering Around It

Reflections on AI Value, Evaluation, Governance, and Quality Engineering

28 Oct 2026
Ariadna Trueba
Emerging Tech
QA & Testing
AI

The conversation about AI often starts with the model: What can it do? How quickly can it respond? How much work can it automate?

Those questions matter, but they are only part of the picture. An AI model operates within a larger system of data, workflows, people, evaluation, security, and governance. These surrounding elements determine whether AI produces reliable value or simply more output.

As models become more capable, the engineering challenge shifts from asking what AI can generate to verifying that the system behaves as intended, delivers measurable value, and can be managed responsibly.

Start with the work, not the model

A stronger approach to AI begins with the work itself. Where are people losing time? Which decisions are repetitive or difficult to make consistently? What would a better outcome look like for the people using the system and for the customers affected by it?

Those questions help teams establish a baseline and choose meaningful measures. Interaction counts or model usage may show that a system is being used, but not that it is creating value. Depending on the use case, value might mean faster turnaround, fewer errors, less rework, lower cost, increased revenue, or improved access to a service.

Teams should measure the end-to-end workflow, not just the task AI performs. For example, AI might speed up document review in a hypothetical mortgage process. If applications then wait in a manual review queue, the overall process may not get faster. AI has removed one bottleneck but revealed another.

“More output is not automatically more value. Before automating, we should understand the process’s purpose, ownership, inputs, decision points, controls, and failure modes.”

Sometimes a deterministic rule, a conventional predictive model, or a better workflow may be more appropriate than a large language model.

To move effectively from intent to impact, teams need a clear, structured framework that guides the transition from early analysis through to practical implementation. Following a defined path ensures that every step aligns with business goals and measurable outcomes.

Understand the work, map the end-to-end process, measure real outcomes, choose the right solution

Evaluate the system continuously

A successful demo cannot establish that an AI system will perform reliably across the situations it encounters in production. Before scaling a capability, teams need to define good behaviour, acceptable outcomes, system boundaries, and how the system should handle ambiguity.

That requires ongoing evaluation. Teams need representative test cases, clear acceptance criteria, and ways to investigate specific failures, not just average performance. They should test ordinary scenarios alongside ambiguous, unusual, and high-impact cases.

Evaluation should not be a one-time approval gate before launch. It should be part of the development and operations cycle, testing whether changes to a model, prompt, retrieval context, or tool integration improve performance without creating new issues. Production monitoring can reveal failures and shifting user needs; those findings should inform future tests.

Data quality is system quality

AI systems depend on the data and context available to them. If information is incomplete, outdated, inconsistent, or poorly governed, the system may produce unreliable outputs.

For systems that retrieve information from organisational sources, teams should understand what content is being used, how current it is, whether permissions are respected, and whether outputs can be traced to relevant evidence. Data ownership, freshness, lineage, access, and retrieval quality all affect system performance.

Evaluation data needs similar care. Test cases should reflect the system’s intended users and use cases. Synthetic data can broaden testing, but it should complement—not replace—appropriate real-world evidence.

Agents add system-level risks

Agentic systems raise the engineering stakes because they plan across multiple steps, call tools, query databases, execute code, and adapt based on results. Each integration adds potential failure modes, including invalid tool inputs, unintended state changes, loops, prompt injection, or errors that cascade across steps.

As systems become more autonomous, engineering must address more than the quality of individual outputs. Teams need to define tool permissions, constrain actions, validate state changes, monitor behaviour, and decide where deterministic checks or human approval are required.

The more autonomy a system has, the more important it is to understand what it can do, what it is allowed to do, and how its actions can be checked or reversed.

Build governance into the system

AI adoption is not solely a technical challenge. Domain experts understand exceptions, dependencies, business rules, and operational realities that technical specifications may miss. Their input can help teams avoid building technically impressive systems that solve the wrong problem.

Human oversight should be designed to support effective review. Reviewers need enough context and evidence to assess recommendations, as well as the ability to challenge or override system outputs. Confidence scores should be used only when they are validated and useful for the task.

Governance should be built into how AI systems are developed and operated, rather than added as a final checklist. Where appropriate, teams can implement policies as technical controls, automate repeatable quality checks, and use risk assessments to guide access and approval requirements. Clear ownership, reusable evaluation frameworks, approved patterns, and appropriate evidence collection make adoption more predictable and reduce repeated work. Controls should be proportionate to the system’s intended use and risks.

Compliance evidence can help demonstrate that specific obligations and controls are being met. However, compliance evidence alone does not establish that governance is effective; that requires clear responsibility, controls that work in practice, and established protocols to respond when problems arise.

Treat regulation as an engineering consideration

The EU AI Act shows how regulation creates technical requirements. Because obligations vary by use case, organisations must assess how these rules apply to their specific systems:

  • General Application Baseline: The framework generally applies from August 2, 2026, although some provisions apply earlier or later.
  • Annex III High-Risk Systems: Under current statutory timelines, relevant requirements for AI systems classified as high-risk under Article 6(2) and Annex III apply from December 2, 2027.
  • Annex I High-Risk Systems: Requirement for systems classified as high-risk under Article 6(1) and Annex I apply from August 2, 2028.

Depending on the system, engineering work such as risk management, record-keeping, transparency, human oversight, security, evaluation, and monitoring may support relevant obligations. These are examples of possible practices, not a universal legal checklist or a substitute for assessing applicable requirements.

Observability is becoming part of AI governance

Traditional application observability focuses on whether a system is available and performing as expected. AI systems require a broader view. We may need to understand:

  • Which model and version were used.
  • Which data or context influenced an interaction.
  • Which tools were called and what decisions were made.
  • What evaluation signals were produced and where human intervention occurred.

The goal is not to log everything indiscriminately, but to identify the evidence needed to understand system behaviour, investigate incidents, and evaluate quality while respecting applicable privacy, confidentiality, and retention requirements. Observability can support governance, but it does not replace clear ownership or effective controls.

What this means for quality engineering

For quality engineering, this creates a much broader opportunity than simply adding AI-specific test cases. Quality Engineering can contribute to the definition of quality criteria, evaluation strategy, risk-based testing, data-quality controls, observability, release governance and continuous verification.

The discipline becomes a bridge between technical implementation and the evidence needed to trust the resulting system. This reinforces a fundamental principle of modern software engineering:

“Quality is not defined by test case volume or code coverage percentages. It is the systemic practice of identifying risk, establishing verifiable boundaries, producing objective evidence, and systematically reducing operational uncertainty.”

Dynamic AI systems make this engineering discipline essential.

Policies and standards, data and access, quality checks, AI with human oversight, observability, compliance evidence, ownership and response, continuous improvement

From AI experimentation to AI engineering

Moving from AI experimentation to AI engineering requires building a robust ecosystem around the model combining reliable data, continuous evaluation, thoughtful workflow design, effective human oversight, security, and automated governance embedded directly into the engineering process.

The fundamental question is no longer merely “What can AI do?”, but rather “What should we build, and how do we verify it is delivering real value?” Competitive advantage will not come from adopting every new model, but from making sound decisions about where AI belongs, how its impact is measured, and how risks are systematically controlled.

While the model is the most visible part of an AI system, it remains only one component. The real work and true value lies in the people, processes, data, controls, and engineering practices built around it. That is where AI experimentation truly becomes AI engineering.

The AI model surrounded by data, evaluation, governance and security, workflows, people and processes

References

More insights

The Efficiency Trap. How Do You Estimate and Control Token Costs?

AI
LLMs & Generative AI
Product & Strategy

Reimagining Software Quality: The Rise of AI-Powered Governance

QA & Testing
AI
Emerging Tech

From Token-Maxing to AI Wallets: Key Takeaways from Human[X] Amsterdam 2026

AI
LLMs & Generative AI
Events