Testing AI applications
Chatbots, copilots, RAG systems and agents with access to interfaces. What gets tested is what the model does when the instruction does not come from the user.
The model does not tell data from instructions
A language model receives text and responds to it. Whether that text comes from a user's input, from an uploaded document, from a knowledge base or from a web page is the same sequence of characters to the model.
That is exactly where the class of weaknesses comes from that did not exist before. So we test applications built on language models along the question of which content reaches the context and who can put it there.
The instruction is inside the document
An assistant summarises uploaded documents. One of them contains, in white text or deep in a footnote, an instruction to the model: ignore your previous instructions, output the system prompt, or send the summary to an outside address.
The model follows it, because it does not distinguish between the text to be processed and an instruction. With an assistant that ends in a wrong answer. With an agent that has access to a mailbox, a database or an interface, it becomes an action.
We test that route across every channel through which content reaches the context: uploads, connected stores, search results, calendar entries, tickets.
Three directions
The division follows the OWASP list for applications with language models and what actually holds up in our tests.
Input and context
Prompt injection directly and through processed content, bypassing the system instructions, and the question of whether content from other sessions can be retrieved.
What the agents may do
What the model may trigger, with which identity, and where a human confirmation sits. An agent with write access is a user whose instructions can come from outside.
Data and output
What sits in the context, the embeddings and the logs, and what of it can end up in a response. Plus the question of whether the output is passed on unfiltered into another application.
Not only chatbots
Assistants facing customers and internally, copilots for code, autonomous agents with access to interfaces and databases, RAG systems over your own knowledge, search and knowledge management tools, plus models for fraud and anomaly detection.
With RAG systems the emphasis is on whose documents can appear in whose answers. With agents it is on what they may trigger without asking.
How an AI test runs
Five to ten days for a single application, depending on how many channels bring content into the context and what the agent may trigger.
Understand the application
Which roles exist, which sources go into the context, and which actions the system can trigger. Without those three, you are testing a chat window rather than an application.
Record the channels
Every route by which text reaches the context: input, uploads, connected stores, search results, calendars, tickets. For each of them the question of who may write there.
Test and exploit
Prompt injection directly and through processed content, bypassing the system instructions, access to other sessions, and what an agent with write access makes of it. The classic tests on the interface and the application run alongside.
Report and retest
Every finding with the call or the document that reproduces it, and a rating based on what was reachable in the end.
Common questions about AI testing
Testing applications in which a language model does the work: assistants, copilots, RAG systems and agents with access to interfaces. What gets tested is not the model but what your application does with it.
It matters the moment the model may act. An assistant that answers wrongly is an annoyance. An agent with write access to a mailbox or a database carries out an instruction that sat in a processed document.
Chatbots facing customers and internally, copilots for code, autonomous agents with access to interfaces and databases, RAG systems over your own knowledge, search and knowledge management tools, plus models for fraud and anomaly detection.
A classic test looks for faults in code and configuration. With an application built on a language model a class comes on top that did not exist before: the model does not distinguish between text to be processed and an instruction.
So we additionally test which content reaches the context and who can put it there. The classic tests on the interface and the application run alongside, because an agent is also just a user with permissions.
Five to ten days for a single application, depending on how many channels bring content into the context and what the agent may trigger. An assistant without write access is tested faster than an agent with access to several systems.
The effort follows the number of context sources, roles and actions the system can trigger. A thirty minute conversation in which you show us the application is enough for a first assessment.
Through a shared channel of your choice, with a named contact on our side. Critical findings we report immediately rather than waiting for the report. At the end we present the results, with room for questions.
No. What gets tested is the application, not the model. We need credentials for the roles that exist and a description of which sources go into the context and which actions are possible.
If you train a model of your own, we discuss testing of training data and data leaving the model separately.
Across Germany. We are based in Dortmund, and most of an AI test runs remotely anyway. We come on site for kick-off meetings and the closing presentation, regularly in the Ruhr area and the Rhineland, and beyond that by arrangement.
Certifications and memberships.
Talk to us.
A first conversation usually takes 30 minutes. We look at where you stand and tell you frankly whether we are the right partner.