{"id":226905,"date":"2026-07-21T09:48:30","date_gmt":"2026-07-21T09:48:30","guid":{"rendered":"https:\/\/www.9senses.ai\/?page_id=226905"},"modified":"2026-08-27T08:16:50","modified_gmt":"2026-08-27T08:16:50","slug":"testing","status":"publish","type":"page","link":"https:\/\/www.9senses.ai\/de\/testing\/","title":{"rendered":"AI Testing"},"content":{"rendered":"\n
\n
\n
\n

AI testing does not end at go-live<\/p>\n<\/div><\/div>\n<\/div>\n<\/div>\n

\n
\n

AI Testing<\/h1><\/div><\/div>\n

AI systems cannot be tested like conventional software and signed off once.<\/p>\n

Their outputs are probabilistic, their environment changes, and acceptable performance depends on the use case and its risks.<\/p>\n

Testing therefore has to establish what acceptable performance means, test it independently, and keep validating it throughout operation.<\/p>\n

Our approach is informed by established AI testing and risk-management practice, including ISO\/IEC TS 42119-2:2025, ISO\/IEC 25059, ISO\/IEC 23894, and the NIST AI Risk Management Framework.<\/p>\n<\/div><\/div>\n<\/div>\n

\n
Vector map \u2014 small<\/div>
Vector map \u2014 small<\/div>[ninesenses_vectormap #3]<\/code>
Max height: 230px. Preview on the live page.<\/div><\/div><\/div><\/div><\/code>
Max height: 230px. Preview on the live page.<\/div><\/div><\/div><\/div><\/div><\/div>\n<\/div>\n<\/div>\n<\/div>\n
\n
\n
\n

Four principles of AI testing<\/h2>\n<\/div><\/div>\n<\/div>\n<\/div>\n
\n
\n

Define success before you build<\/h3>

Testing starts with the use case, not the finished system. Define what the AI needs to achieve, how reliably it has to achieve it, and which failures are unacceptable.<\/p>\n<\/div><\/div><\/div><\/div>\n

3<\/span><\/span><\/div>\n<\/div>\n
\n

Build evidence, not demos<\/h3>

A few good outputs show that an AI can work. They do not show that it works reliably. A proper test architecture separates development from independent validation and deliberately challenges the system beyond the cases it was built around.<\/p>\n<\/div><\/div><\/div><\/div>\n

3<\/span><\/span><\/div>\n<\/div>\n
\n

Release is a baseline<\/h3>

Go-live establishes how the system performed at release. It does not prove that it will continue to perform that way. Regression testing catches deliberate changes. Recurring validation catches the changes nobody deliberately made.<\/p>\n<\/div><\/div><\/div><\/div>\n

3<\/span><\/span><\/div>\n<\/div>\n
\n

Test the tester<\/h3>

Automation makes continuous testing possible. But the AI doing the testing has to be tested too. Human review provides an independent check on the evaluator itself.<\/p>\n<\/div><\/div><\/div><\/div>\n

3<\/span><\/span><\/div>\n<\/div>\n<\/div>\n<\/div>\n
\n
\n
\n

AI rarely has a simple right-or-wrong output.<\/p>\n

Testing therefore starts by translating the intended use and its risks into measurable acceptance criteria: required performance, acceptable error rates, failure behaviour and, where appropriate, probabilistic thresholds.<\/p>\n

The depth of testing should follow the consequences of failure. An internal knowledge assistant and a system supporting consequential decisions should not face the same test regime.<\/p>\n

This risk-based approach is central to ISO\/IEC TS 42119-2. ISO\/IEC 25059 provides a quality model for AI systems, while ISO\/IEC 23894 addresses AI-specific risk management.<\/p>\n

If success cannot be defined, it cannot be tested.<\/strong><\/p>\n<\/div><\/div>\n<\/div>\n

\n

Without a definition of success<\/h3>\n

Testing falls back on impressions. Results get argued rather than measured, and \u201cgood enough\u201d is settled after the fact.<\/p>\n

Test depth also stops tracking risk: a low-stakes assistant and a system behind consequential decisions end up with the same shallow check.<\/p>\n<\/div><\/div>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n
\n

Development teams need tests they can see and use continuously.<\/p>\n

But once a system has repeatedly been optimised against the same cases, those cases become weaker evidence of its actual performance.<\/p>\n

A robust test architecture therefore separates:<\/p>\n